Noções básicas de restaking

Dado algum ativo X, denotamos por [X] o ativo re-staked, ou seja, um ativo que "empacota" X de forma que parte ou todo o X possa ser capturado por alguma parte dada alguma condição arbitrária.

O exemplo básico introduzido pela EigenLayer é o de um staker solo reestacando seu ETH atual em jogo. Para fazer isso, o staker solo atualiza seu endereço de retirada 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 participação. O EigenPod se torna o proprietário do ativo soETH, enquanto credita o staker solo com uma representação reestacada de seu ETH apostado.

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 passa pelo contrato EigenPod, verificando se o staker solo tem permissão para resgatar a quantidade total de soETH ou não (veremos mais tarde quando isso pode não ser o caso). Com nossos balanços:

Nós tornamos explícito cada passo a seguir:

1. O staker solo deposita seu ETH no protocolo Ethereum, recebendo uma posição virtual de soETH do protocolo Ethereum.
2. O apostador solo deposita virtualmente seu soETH na EigenLayer, definindo seu endereço de saque como o endereço do pod EigenLayer. Em troca, o apostador solo recebe uma posição virtual [soETH] da EigenLayer, o que lhe permite, eventualmente, executar a ordem das operações ao contrário.

Saldo desequilibrado

Já podemos fazer algumas observações interessantes a partir dos balanços acima. A primeira é que o protocolo Ethereum não tem absolutamente nenhuma concepção de [soETH], pois isso não está aparecendo em seu próprio balanço. Esse problema foi discutido em “Desagregando a PBS: Rumo a compromissos de proponente reforçados por protocolo (PEPC)Um validador punido pela EigenLayer ainda possui um saldo completo de staking na planilha de balanço do protocolo Ethereum, o que pode induzir riscos morais e desequilíbrios de recompensas (um validador na verdade meio-staked ainda recebe recompensas completas do protocolo Ethereum). Detalhamos o cenário de punição nas seguintes planilhas de balanço, fornecendo números arbitrários para ilustrar o problema:

Este problema é resolvido assim que EigenLayer relata fielmente o corte do EigenLayer de um validador para o protocolo Ethereum, reequilibrando as folhas. Isso é possível comEIP-7002: Saídas acioná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 de PoS do Ethereum. Essa ação está nos interesses da EigenLayer porque a contabilidade adequada beneficia os serviços que são garantidos via EigenLayer e também aumenta, em última instância, a confiança dos operadores e dos re-stakers na execução fiel da plataforma.

Um gatilho mais fino poderia forçar uma retirada parcial do saldo do validador do consenso 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 (removendo o limite de 32 ETH no principal de um único validador em jogo) se combinaria bem com retiradas parciais, removendo um incentivo adicional para os validadores permanecerem desagregados (executando muitos validadores de 32 ETH em vez de um único validador de 2048 ETH, por exemplo).

Falta desta função de retirada parcial, existe um incentivo adicional para manter a contabilidade da EigenLayer separada da contabilidade do protocolo Ethereum, o que, como observamos acima, pode introduzir desalinhamentos. A seguir, representamos um validador punido em 8 ETH pela EigenLayer, que não retira o validador de suas funções de consenso (o saldo de expulsão é de 16 ETH):

AVS alega

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

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

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

1. O staker solo re-stakes.
   1. Então, o ETH é colocado sob o controle do EigenPod.
   2. [soETH]* é recebido pelo re-stake solo, uma reivindicação por seus ativos reestacados.
2. O staker solo cunha uma nova reivindicação, [soETH] do seu EigenPod.
3. A reivindicação é dada como garantia para o AVS.
   1. [soETH] é transferido para o AVS.
   2. O re-staker recebe o recibo avs.[soETH].

Uma vez que o validador age contrariamente aos objetivos do AVS (por exemplo, desencadeando uma condição de corte do AVS), o AVS pode decidir, por exemplo, queimar a reivindicação do validador para seus ETH em jogo, ou manter a aposta como receita para o AVS. Ilustramos essa 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 corte da EigenLayer, após o qual a EigenLayer transfere para o AVS:

1. O AVS reduz o colateral do re-staker solo.
   1. A garantia do AVS consiste em 32 [soETH]. Uma vez que o corte é relatado, o AVS remove 8 [soETH] da garantia e relata o corte ao EigenPod, que também diminui suas responsabilidades em 8 [soETH].
   2. O AVS não credita mais 32 avs.[soETH] para o re-staker solo, diminuindo essa reivindicação em 8 avs.[soETH].
   3. Depois de ser reduzido pela AVS, o EigenPod diminui a reivindicação do re-empilhador solo em 8 [soETH]*.
2. O EigenPod relata o slashing para o protocolo Ethereum, desencadeando a retirada de 8 ETH.
   1. A reivindicação de ativos em jogo no protocolo Ethereum diminui para 24 soETH.
   2. Um saque parcial de 8 ETH é processado, e o EigenPod recebe os 8 ETH previamente bloqueados no protocolo Ethereum.
3. O EigenPod repassa a penalidade de 8 ETH para o AVS, que está livre para dispor dela como quiser.

Re-re-re-re-…-staking

O recurso (e risco) oferecido pelo EigenLayer é a capacidade de um re-staker continuar entrando em novos compromissos que eles prometem honrar. Em outras palavras, depois que a estaca é reapostada, a estaca reapostada pode ser reapostada novamente, e de novo, e de novo... De forma mais prática, o re-staker entra em novos compromissos ao assinar mais serviços por meio de seu EigenPod.

Para alcançar plena generalidade e antecipando as seções seguintes onde ativos diferentes de soETH são reestacados, denotamos por $X$ o ativo que é reestacado pelo reestacador. Vamos ver como o reestaque múltiplo funciona:

Denotamos por [X]p o ativo X re-estacado p vezes. Por enquanto, esta é uma definição simples, mas vamos dar algumas dicas sobre algumas das propriedades desses ativos após detalhar as etapas desses balanços. O EigenPod é capaz de imprimir esses passivos a qualquer momento, forjando novos ativos sempre que o re-estacador se comprometer com novos AVSs.

1. O re-staker coloca o ativo X sob controle do EigenPod. Este ato é um compromisso do re-staker de que, caso não forneçam os serviços para os quais se inscreveram, parte ou todo o ativo X pode ser retirado deles. A reivindicação [X]* é recebida para representar este compromisso.
2. Detalhamos aqui o re-staker comprometendo-se a garantir a cadeia Y.
   1. O re-staker obtém um primeiro ativo re-staked [X]¹ ao entrar na cadeia de segurança AVS Y.
   2. O re-staker faz staking de [X]¹ sob a cadeia Y, recebendo assim [X]¹ (uma reivindicação por sua staking + recompensas - penalidades). A cadeia Y deve “entender” que um ativo re-staked atualmente garante seu protocolo, ou seja, deve estar confiante de que há algo em jogo para alguém.
3. Detalhamos aqui o re-staker comprometendo-se a garantir a cadeia Z.
   1. O re-estacador obtém um ativo re-estacado [X]² ao entrar na cadeia de segurança AVS "Securing chain Z".
   2. O re-staker aposta [X]² sob a cadeia Z, recebendo soZ.[X]² (uma reivindicação pelo seu investimento + recompensas - penalidades). A cadeia Z deve “entender” que um ativo re-apostado 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, agora abordamos algumas questões. Observamos que a cadeia Y recebe [X]¹, enquanto a cadeia Z recebe [X]². Esses 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 de AVS. Imagine um cenário em que o re-empilhador comete infrações passíveis de corte em ambas as cadeias ao mesmo tempo, e ambas as cadeias desejam cortar o colateral inteiro. Podemos então pensar em dois casos:

1. Caso 1: Os AVSs, aqui mecanismos de consenso das cadeias Y e Z, simplesmente queimam os tokens que são confiscados, que é o que a maioria dos protocolos PoS fazem. Quando os tokens são queimados, então a hierarquia de reivindicações não importa realmente: Se as duas cadeias Y e Z quisessem confiscar o re-staker por 32 ETH, tudo o que conseguem é queimar o mesmo colateral duas vezes.
   1. Nota: Anders chama isso de 'spree-staking', re-staking várias vezes sem hierarquia de reivindicação 😊
2. Caso 2: Os AVSs querem receber os tokens em jogo, por exemplo, para 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 nos conteúdos do bloco recebidos de forma clara e, se o fizer, se compromete a compensar o construtor e o relé pela confusão. Neste caso, suponha que vários AVSs resgatem suas reivindicações ao mesmo tempo, seguindo desvios paralelos pelo mesmo re-empilhador, e não haja o suficiente em jogo para cobrir todas as reivindicações. Então, a questão da senioridade da reivindicação ou distribuição dos pagamentos torna-se relevante.

Desagregando AVSs

Na seção anterior, apresentamos AVSs, que são os serviços que o validador de restaking se compromete a fornecer. O compromisso é garantido via EigenLayer, que assume a propriedade da participação do validador de restaking e resolve as reivindicações feitas pelos AVSs.

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

Em resumo, o AVS exige garantia para oferecer um serviço, por exemplo, um AVS afirma credível que um ataque ao AVS resultará na perda de alguma fração da garantia atualmente mantida pelo AVS. O AVS é visto aqui como um protocolo que envolve operadores para um serviço. Em seguida, desambiguamos duas maneiras pelas quais os re-stakers podem interagir com o AVS:

1. Re-stakers como operadores AVS: O AVS incorpora um protocolo que busca operadores para funcionar, e os operadores de nó que reavaliarem seu soETH se tornam operadores para o próprio protocolo AVS.
2. Re-stakers como provedores de capital para um operador AVS: Neste caso, um operador AVS aceita ativos (re-)stakeados para desempenhar sua função de operador em nome dos delegadores que fornecem o capital. O re-staker então delega seus ativos re-stakeados ao operador AVS, que executa alguma função em nome do re-staker.

Nas seções acima, identificamos o validador re-staker como o provedor de capital (seu próprio stake é re-staked) e o operador do AVS (espera-se que eles mesmos forneçam algum serviço). No entanto, podemos considerar uma construção diferente, onde o validador re-staker não opera o AVS por si próprio, em vez disso, delegando essa função a algum operador. Isso poderia permitir que os stakers solos competissem em rendimento com os Provedores de Serviço de Staking (SSPs)/operadores integrados. 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-staker. Fazemos a suposição 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 falhem em fornecer os serviços para os quais se inscreveram, parte ou todo o ativo X pode ser retirado deles. A reivindicação [X]* é recebida para representar este compromisso.
2. Detalhamos aqui o re-staker comprometendo-se a garantir a cadeia Y, delegando as responsabilidades de validação ao operador AVS.
   1. O re-staker obtém um ativo re-staked [X] ao entrar na cadeia de segurança AVS "Securing chain Y".
   2. O re-staker dá o ativo re-staked [X] a um operador AVS, obtendo o "recibo" noY.[X].
   3. O operador AVS aposta [X] na cadeia Y, recebendo soY.[X] (uma reivindicação por sua aposta + recompensas - penalidades). A cadeia Y deve “entender” que um ativo re-apostado atualmente garante seu protocolo, ou seja, deve ter confiança de que há algo em jogo para alguém.
3. Detalhamos aqui o re-staker comprometendo-se a assegurar a cadeia Z, delegando as funções de validação ao operador AVS.
   1. O re-staker obtém um ativo re-stakeado [X] ao entrar na AVS 'Chain Y' de segurança.
   2. O re-staker dá o ativo re-staked [X] a um operador AVS, obtendo o “recibo” noZ.[X].
   3. O operador do AVS aposta [X] sob a cadeia Z, recebendo soZ.[X] (uma reivindicação por sua aposta + recompensas - penalidades). A cadeia Z deve “entender” que um ativo re-apostado atualmente garante seu protocolo, ou seja, deve ter confiança de que há algo em jogo para alguém.

Neste paradigma, recuperamos construções familiares. E nenhum ativo é recebido pelo re-estaker, já sugerindo a possibilidade de liquefação de tais posições. Discutiremos essas construções avançadas no próximo post, mas antes de fazê-lo, mencionamos a pesquisa em andamento sobre "PBS para AVS" como uma abordagem para reduzir a centralização do operador.

Sob oEstrutura de Delegação Otimista (ODF)proposto por Drew Van der Werff (ver também A recent talk at the Cryptoeconomics workshop at Columbia by 0xKydo) Um re-staker é capaz de contratar a operação dos AVSs aos quais se inscreve em um mercado aberto de “co-processadores”. Os co-processadores podem ser identificados com o papel de “construtor” do PBS, uma entidade especializada capaz de executar operações potencialmente intensivas, às quais entidades não sofisticadas ou limitadas computacionalmente, como os stakers individuais, não têm acesso. Os co-processadores enviam propostas aos re-stakers, em um mecanismo de leilão de aquisições, permitindo ao re-staker determinar o operador mais lucrativo. Para garantir ainda mais o desempenho, os co-processadores são participantes vinculados, expondo-se à perda de sua garantia se enviarem um trabalho provavelmente inválido durante o curso de suas operações.

Aviso Legal：

1. Este artigo é reproduzido a partir de [Gateespelho], Todos os direitos autorais pertencem ao autor original [o preço da agência]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Isenção de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem aconselhamento 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.