Noções básicas de re-estaca

Dado algum ativo X, denotamos por [X] o ativo re-apostado, ou seja, um ativo "boxing" X tal que parte ou a totalidade de X pode ser capturada por alguma parte dada alguma condição arbitrária.

O exemplo básico apresentado pela EigenLayer é o de um estacador solitário que volta a estacar o seu ETH atual em jogo. Para o fazer, o estacador solitário atualiza o seu endereço de levantamento para o endereço de um Pod EigenLayer. EigenPods são contratos inteligentes que rastreiam quais serviços o staker solo se inscreveu para garantir com sua estaca. O EigenPod acaba se tornando o proprietário do ativo soETH, enquanto credita o staker solo com uma representação re-estacada de seu ETH estacado.

A propriedade do ativo soETH em nossa estrutura denota o “primeiro direito” sobre o ETH retirado do protocolo Ethereum, ou seja, possui uma reivindicação mais sênior do que qualquer outro participante na cadeia. Quando o staker solo decide retirar seu ETH do protocolo Ethereum, o ETH retirado é filtrado através do contrato EigenPod, verificando se o staker solo tem permissão para resgatar a quantia total de soETH ou não (veremos mais tarde quando isso pode não ser o caso). Com nossos balanços:

Tornamos cada passo explícito no seguinte:

1. O staker a solo deposita o seu ETH no protocolo Ethereum, recebendo uma posição virtual de soETH do protocolo Ethereum.
2. O staker solo deposita virtualmente o seu soETH na EigenLayer, definindo o seu endereço de levantamento para o endereço do pod da EigenLayer. Em troca, o staker solo recebe uma posição virtual [soETH] da EigenLayer, o que lhes permite eventualmente reverter a ordem das operações.

Desequilíbrios de saldo

Podemos já fazer algumas observações interessantes a partir dos balanços acima. A primeira é que o protocolo Ethereum não tem nenhuma conceção de [soETH], uma vez que isso não está aparecendo em seu próprio balanço. Esta questão foi debatida em "Desagregando a PBS: Rumo a compromissos de proponente reforçados por protocolo (PEPC)Um validador punido pela EigenLayer ainda mantém um saldo completo de estaca no balanço do protocolo Ethereum, o que pode induzir a riscos morais e desequilíbrios de recompensa (um validador na verdade meio estacado ainda recebe recompensas completas do protocolo Ethereum). Detalhamos o cenário de punição nos seguintes balanços, fornecendo números arbitrários para ilustrar o problema:

Este problema é resolvido assim que a EigenLayer reporta fielmente o corte da EigenLayer de um validador ao protocolo Ethereum, reequilibrando as folhas. Isto é possível comEIP-7002: Saídas desencadeáveis da camada de execução, embora em um nível básico, uma vez que o gatilho binário simplesmente sai do validador, mas o middleware EigenLayer ou o EigenPod ainda são necessários para acionar o sinal para o protocolo Ethereum PoS. Esta ação está nos interesses da EigenLayer porque a contabilidade adequada beneficia os serviços que são seguros via EigenLayer e também aumenta, em última análise, a confiança dos operadores e re-stakers na execução fiel da plataforma.

Um gatilho mais fino poderia forçar uma retirada parcial do saldo do validador do consenso do Ethereum, sem sair completamente do validador. Isso é desejável para os serviços EigenLayer que desejam penalizar os validadores parcialmente, sem acionar uma saída. Note que nem o EIP-7002 nem as retiradas parciais acionadas pela camada de execução estão disponíveis na mainnet do Ethereum hoje. Note também que @mikeneuder/eip-7251-faq">MaxEB (removing the 32 ETH cap on a single validator’s principal at stake) would combine nicely with partial withdrawals, removing an additional incentive for validators to stay dis-aggregated (running many 32 ETH-validators instead of a single 2048 ETH-validator for instance).

Sem esta funcionalidade de retirada parcial, há um incentivo adicional para manter a contabilidade da EigenLayer separada da contabilidade do protocolo Ethereum, o que, como mencionamos acima, pode introduzir desalinhamentos. A seguir, representamos um validador penalizado em 8 ETH pela EigenLayer, o que não retira o validador de suas funções de consenso (o saldo de ejeção é de 16 ETH):

AVS reivindicações

Pode-se perguntar para onde vão os 8 [soETH] no exemplo anterior. Esta decisão é deixada para os Serviços Validados Ativamente (AVS) alimentados pela EigenLayer. Um AVS é um serviço que exige alguma estaca como garantia. A presença da estaca permite ao serviço fazer um compromisso credível com algum desempenho, uma vez que a estaca pode ser cortada se o serviço não for realizado corretamente.

O validador de re-estaca inscreve-se nos AVSs através do seu EigenPod. Quando o fazem, o EigenPod cunha novas reivindicações que são oferecidas aos AVSs, representando o colateral atualmente detido sob o EigenPod. Agora devemos fazer a distinção entre dois tipos de reivindicações:

1. AVS alega: Usamos [soETH] para denotar essas reivindicações, enfatizando que são derivadas do valor do ativo entre colchetes [ ].
2. Reivindicação de re-estaca: Agora usaremos [soETH]* para enfatizar a qualidade especial desta reivindicação, que é resgatada apenas pelo re-estacador depois que todas as reivindicações AVS forem resolvidas. Em outras palavras, a reivindicação do re-estacador tem a menor antiguidade, resgatando os ativos restantes uma vez que todas as outras reivindicações AVS forem resolvidas.

1. O staker solo re-estaca.
   1. Assim, o ETH é colocado sob o controle do EigenPod.
   2. [soETH]* é recebido pelo re-estacador individual, uma reivindicação pelos seus ativos re-estacados.
2. O apostador a solo cria uma nova reivindicação, [soETH] a partir do seu EigenPod.
3. A reivindicação é dada como garantia ao AVS.
   1. [soETH] é transferido para o AVS.
   2. O re-staker é dado o recibo avs.[soETH].

Uma vez que o validador atue contrariamente aos objetivos do AVS (por exemplo, desencadeando uma condição de penalização do AVS), o AVS pode decidir, por exemplo, queimar a reivindicação do validador pelo seu ETH em estaca, ou manter a estaca como receita para o AVS. Ilustramos esta segunda opção a seguir, assumindo que o protocolo Ethereum simplesmente credita 8 ETH ao EigenPod como uma retirada parcial após o relatório de penalização do EigenLayer, após o qual o EigenLayer o transfere para o AVS:

1. O AVS reduz o colateral do re-estacador solitário.
   1. A garantia do AVS consiste em 32 [soETH]. Uma vez que o corte é reportado, o AVS remove 8 [soETH] da garantia e reporta o corte ao EigenPod, que também diminui as suas responsabilidades em 8 [soETH].
   2. O AVS já não credita 32 avs. [soETH] ao re-estacador a solo, diminuindo esta reivindicação em 8 avs. [soETH].
   3. Depois de ter sido reduzido pelo AVS, o EigenPod diminui a reivindicação do solo re-estacador em 8 [soETH]*.
2. O EigenPod relata o slashing ao protocolo Ethereum, desencadeando a retirada de 8 ETH.
   1. A reivindicação de ativos em jogo no protocolo Ethereum desce para 24 soETH.
   2. Um levantamento parcial de 8 ETH é processado, e o EigenPod recebe os 8 ETH previamente bloqueados no protocolo Ethereum.
3. O EigenPod encaminha a penalidade de 8 ETH para o AVS, que está livre para dispor dela como desejar.

Re-re-re-re-…-Estaca

O recurso (e risco) oferecido pela EigenLayer é a capacidade de um re-apostador continuar a fazer novos compromissos que prometem honrar. Em outras palavras, depois que a aposta é re-apostada, a aposta re-apostada pode ser re-apostada novamente, e novamente, e novamente... Mais praticamente, o re-apostador faz novos compromissos ao se inscrever em mais serviços através de seu EigenPod.

Para alcançar plena generalidade, e em antecipação das secções seguintes onde ativos diferentes de soETH são re-estacados, designamos por $X$ o ativo que é re-estacado pelo re-estacador. Vamos ver como o re-estacamento múltiplo funciona:

Denotamos por [X]p o ativo X re-estacado p vezes. Por agora, esta é uma definição simples, mas vamos dar algumas pistas sobre algumas das propriedades desses ativos depois de detalhar os passos destes balanços. O EigenPod é capaz de imprimir esses passivos à vontade, forjando novos ativos sempre que o re-estacador se compromete com novas AVSs.

1. O re-estacador coloca o ativo X sob controle do EigenPod. Este ato é um compromisso por parte do re-estacador de que, caso não consigam fornecer os serviços para os quais se inscreveram, parte ou todo o ativo X poderá ser retirado deles. A reivindicação [X]* é recebida para representar esse compromisso.
2. Detalhamos aqui o compromisso re-staker de proteger a cadeia Y.
   1. O re-staker obtém um primeiro ativo re-staked [X]¹ entrando no AVS "Securing chain Y".
   2. O re-estacador estaca [X]¹ sob a cadeia Y, recebendo soY.[X]¹ (uma reivindicação pelo seu estaca + recompensas - penalidades). A cadeia Y deve “compreender” que um ativo re-estacado atualmente garante o seu protocolo, ou seja, deve estar confiante de que há algo em jogo para alguém.
3. Detalhamos aqui o re-staker comprometido em garantir a cadeia Z.
   1. O re-estacador obtém um ativo re-estacado [X]² ao entrar na AVS 'Chain Z' de segurança.
   2. O re-staker estaca [X]² sob a cadeia Z, recebendo soZ.[X]² (um pedido de estaca + recompensas - penalidades). A cadeia Z deve “entender” que um ativo re-estacado atualmente garante seu protocolo, ou seja, deve ter confiança de que há algo em jogo para alguém.

Com base nos balanços acima, abordamos agora algumas questões. Observamos que a cadeia Y recebe [X]¹, enquanto a cadeia Z recebe [X]². Estes ativos são do mesmo tipo e poderíamos dizer que ambos recebem ativos do tipo [X]?

A resposta seria não se houvesse uma hierarquia de reivindicações AVS. Imagine um cenário em que o re-estacador comete infrações passíveis de punição em ambas as cadeias ao mesmo tempo, e ambas as cadeias desejam punir todo o colateral. Podemos então pensar em dois casos:

1. Caso 1: Os AVSs, aqui os mecanismos de consenso das cadeias Y e Z, simplesmente queimam os tokens que são cortados, que é o que a maioria dos protocolos de PoS faz. Quando os tokens são queimados, então a hierarquia das reivindicações não importa realmente: Se ambas as cadeias Y e Z quisessem cortar o re-estacador por 32 ETH, tudo o que conseguem é queimar o mesmo colateral duas vezes.
   1. Nota: Anders chama a isto de "spree-staking", re-staking várias vezes sem hierarquia de reivindicação 😊
2. Caso 2: Os AVSs querem receber os tokens que estão em jogo, para por exemplo, compensar alguma parte que foi prejudicada. Um exemplo aqui é MEV-Boost+, o operador AVS é o proponente do bloco, que se compromete a não mexer com o conteúdo do bloco recebido no claro e, se o fizer, compromete-se a compensar o construtor e o relé pela bagunça. Neste caso, suponha que vários AVSs resgatem suas reivindicações ao mesmo tempo após desvios paralelos pelo mesmo re-staker, e não há o suficiente em jogo para cobrir todas as reivindicações. Em seguida, a questão da antiguidade do sinistro ou da distribuição dos pagamentos torna-se relevante.

Desagregação de AVSs

Na secção anterior, introduzimos AVSs, que são os serviços que o validador de re-estaca se compromete a fornecer. O compromisso é garantido através da EigenLayer, que assume a propriedade da estaca do validador de re-estaca e resolve as reclamações feitas pelos AVSs.

Mas o que é exatamente um AVS? Assim como separamos acima os protocolos LST e os operadores LST, faz sentido discutir aqui esses dois papéis funcionais separadamente, e atribuir-lhes diferentes ativos e reivindicações.

Em resumo, o AVS exige garantias para oferecer um serviço, por exemplo, um AVS faz a alegação credível de que um ataque ao AVS resultará na perda de uma fração das garantias atualmente detidas pelo AVS. O AVS é assim visto aqui como um protocolo que envolve operadores para um serviço. Em seguida, desambiguamos duas formas pelas quais os re-stakers podem interagir com o AVS:

1. Re-estacas como operadores AVS: O AVS incorpora um protocolo que procura operadores para funcionar e os operadores de nó que reestacam seu soETH tornam-se operadores do protocolo AVS.
2. Re-stakers como fornecedores de capital para um operador AVS: Neste caso, um operador AVS aceita ativos (re-)estacados para desempenhar a sua função de operador em nome dos delegadores que fornecem o capital. O re-estacador delega então os seus ativos re-estacados ao operador AVS, que executa alguma função em nome do re-estacador.

Nas seções acima, identificamos o validador re-estacador como o fornecedor de capital (sua própria participação é re-estacada) e o operador AVS (espera-se que forneçam algum serviço). No entanto, podemos considerar uma construção diferente, onde o validador re-estacador não opera o AVS sozinho, delegando essa função a algum operador. Isso poderia permitir que os estacadores individuais competissem em rendimento com Provedores de Serviço de Estaca Integrada (SSPs)/operadores. O exemplo a seguir apresenta uma situação em que um único operador de AVS valida em algumas cadeias Y e Z, em nome de um re-estacador. Partimos do pressuposto de que todas as reivindicações AVS são do mesmo tipo [X] (sem hierarquia de reivindicação).

1. O re-staker coloca o ativo X sob controle do EigenPod. Este ato é um compromisso do re-staker de que, caso não consigam fornecer os serviços para os quais se inscreveram, parte ou todo o ativo X pode ser retirado deles. O pedido [X]* é recebido para representar este compromisso.
2. Detalhamos aqui o re-staker comprometendo-se a proteger a cadeia Y, delegando as tarefas de validação ao operador AVS.
   1. O re-estacador obtém um ativo re-estacado [X] ao entrar na cadeia de segurança AVS Y.
   2. O re-aplicador dá o ativo re-aplicado [X] a um operador AVS, obtendo o “recibo” noY.[X].
   3. O operador AVS estaca [X] sob a cadeia Y, recebendo soY.[X] (uma reivindicação para sua estaca + recompensas - penalidades). A cadeia Y deve "entender" que um ativo reestacado atualmente garante seu protocolo, ou seja, deve ter confiança de que há algo em jogo para alguém.
3. Detalhamos aqui o re-estacador comprometendo-se a assegurar a cadeia Z, delegando as funções de validação ao operador AVS.
   1. O re-apostador obtém um ativo re-apostado [X] ao entrar na AVS "Assegurando a cadeia Y".
   2. O re-estacador dá o ativo re-estacado [X] a um operador AVS, obtendo o “recibo” noZ.[X].
   3. O operador AVS estaca [X] sob a cadeia Z, recebendo soZ.[X] (um pedido de sua estaca + recompensas - penalidades). A cadeia Z deve “entender” que um ativo re-estacado atualmente garante seu protocolo, ou seja, deve estar confiante de que há algo em jogo para alguém.

Neste paradigma, recuperamos construções familiares. Nenhum ativo é recebido pelo re-staker, já sugerindo a possibilidade de liquefação de tais posições. Vamos discutir estas construções avançadas no próximo post, mas antes de o fazer, mencionemos a pesquisa em curso sobre "PBS para AVS" como uma abordagem para reduzir a centralização do operador.

Debaixo do Estrutura de Delegação Otimista (ODF)proposto por Drew Van der Werff (ver tambémPalestra recente de workshop de Criptoeconomia da 0xKydo na Colômbia) um restaker é capaz de contratar a operação dos AVSs em que se inscreve em um mercado aberto de “co-processadores”. Os co-processadores podem ser identificados com a função de “construtor” do PBS, uma entidade especializada capaz de executar operações potencialmente intensivas, que são inacessíveis a entidades pouco sofisticadas ou limitadas computacionalmente, como os solo stakers. Os co-processadores apresentam propostas aos restakers, num mecanismo de leilão de aquisição, permitindo ao restaker determinar o operador mais lucrativo. Para garantir ainda mais o desempenho, os co-processadores são participantes com garantia, abrindo-se para perder sua garantia se apresentarem uma peça de trabalho provavelmente inválida durante o curso de suas operações.

Aviso legal：

1. Este artigo foi reimpresso de [ espelho], Todos os direitos de autor pertencem ao autor original [o preço da agência]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipa e eles vão tratar do assunto prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.