Agradecimentos especiais a Mike Neuder, Justin Drake e outros pelo feedback e revisão. Veja também: posts anteriores sobre temas semelhantes por < a href= " https://notes.ethereum.org/@mikeneuder /goldilocks" > Mike Neuder, Dankrad Feist e arixon.eth.

O status quo do Ethereum pode ser descrito como incluindo uma grande parte do staking emergente de duas camadas. Por staking em duas camadas, quero dizer aqui um modelo de staking onde existem duas classes de participantes:

1. Operadores de nós, que gerem nós e colocam a sua reputação ou algum montante fixo de capital próprio como garantia
2. Delegadores, que colocam alguma quantidade de ETH, sem compromisso mínimo e sem exigência estrita de participar de qualquer outra forma além de trazer a sua garantia

Este staking emergente de duas camadas surge através das ações de uma grande parcela de stakers que participam em pools de staking que oferecem tokens de staking líquidos (LSTs), por exemplo. Rocket Pool e Lido.

O status quo tem duas falhas principais:

• Risco de centralização em operadores de nós. Os mecanismos para escolher operadores de nós em pools de staking existentes ou não são muito descentralizados ou têm outras falhas.
• Carga desnecessária da camada de consenso. O Ethereum L1 verifica ~800.000 assinaturas por época, e com < a href= " https://notes.ethereum.org/ @vbuterin /single_slot_finality " > único finalidade de slot que pode aumentar para 800.000 por slot. Isto é uma carga grande. Além disso, devido à grande parte do liquid staking, a rede não está a obter todos os benefícios de assumir esta carga. Se a rede puder ser tornada aceitavelmente descentralizada e segura sem exigir que cada estaker assine em cada slot, poderemos apoiar-nos muito mais nessa solução e reduzir o número de assinaturas por slot para, por exemplo, 10.000.

Este post irá descrever possíveis soluções para ambos os problemas. Tomará particularmente o seguinte ângulo: suponha que tomamos como um dado adquirido que a maior parte do capital é detida por pessoas que não estão dispostas a executar pessoalmente nós de staking na sua forma atual, assinando mensagens em todos os slots e bloqueando os seus depósitos e sujeitando-os a cortes. Que outro papel podem ter que contribua significativamente para a descentralização e segurança da rede?

Como funciona o staking de duas camadas hoje?

Os dois pools de staking descentralizados mais populares hoje, Lido e RocketPool, estão ambos a criar ecossistemas emergentes de estaqueamento de duas camadas. No caso do Lido, os níveis são:

• Operadores de nós: estes são escolhidos por votação no Lido DAO, tão eficazmente pelos titulares de LDO
• Delegadores: pessoas que detêm STETH. stETH é criado quando alguém deposita ETH no sistema de contrato inteligente Lido, o que permite que os operadores de nós o estaquem (mas, porque o < a href= " https://notes.ethereum.org/@launchpad/withdrawals-faq " > levantamento as credenciais estão vinculadas a um endereço ETH de contrato inteligente, não podem levá-lo para si)

No caso do Rocket Pool, os níveis são:

• Operadores de nós: qualquer pessoa pode tornar-se um operador de nó enviando um depósito de 8 ETH, mais uma quantidade de tokens RPL
• Delegadores: pessoas que detêm o eTh. O ReTH é criado quando alguém deposita ETH no sistema de contrato inteligente Rocket Pool, que permite aos operadores de nós colocá-lo (mas não tomá-lo para si)

O papel dos delegadores

Nestes sistemas (ou novos sistemas habilitados por potenciais futuras alterações de protocolo), uma pergunta-chave a fazer é: da perspectiva do protocolo, qual é o sentido de ter delegadores?

Para ver porque é que a pergunta é significativa, vamos considerar o seguinte mundo. A alteração de protocolo proposta neste post recente, de limitar as penalidades de corte a 2 ETH, está implementada. O Rocket Pool reduz o depósito do operador do nó para 2 ETH em resposta. A quota de mercado do Rocket Pool aumenta para 100% (não apenas entre os participantes, mas também entre os detentores de ETH: à medida que o ReTH se torna livre de risco, quase todos os detentores de ETH tornam-se detentores de RETH ou operadores de nós).

Vamos supor que os titulares de ReTH obtenham um retorno de 3% (incluindo recompensas no protocolo e taxas de prioridade + MEV) e os operadores de nós obtenham um retorno de 4%. Vamos também supor que a oferta total de ETH seja de 100 milhões.

Veja como a matemática funciona. Para evitar lidar com a composição, analisaremos os retornos diários em vez de anuais, para que os termos de segunda ordem se tornem pequenos o suficiente para serem ignoráveis:

Agora, vamos considerar um mundo diferente. O Rocket Pool não existe. O depósito mínimo de cada apostador é reduzido para 2 ETH e a quantidade total de ETH apostada é limitada a 6.25M. Além disso, o retorno do operador do nó é reduzido para 1%. Vamos fazer as contas:

Agora, vamos considerar as duas situações do ponto de vista do custo do ataque. No primeiro caso, os atacantes não se inscreveriam como delegadores: os delegadores não têm poder, então não faz sentido. Por isso, eles colocariam toda a sua ETH para se inscreverem como operadores de nós. Para chegar a 1/3 de toda a aposta, teriam de colocar 2.08M ETH (o que, para ser justo, ainda é bastante! por exemplo. ver < a href= " https://notes.ethereum.org/@vbuterin/single_slot_finality #Idea -1-super-comittees " > isto discussão sobre supercomités, uma proposta de escalonamento de aposta que também teria diminuído o custo do ataque para um valor semelhante). No segundo caso, os atacantes apenas estariam e, para chegar a 1/3 de toda a aposta, precisariam de colocar... 2.08M ETH.

Do ponto de vista da economia de jogo e da perspectiva do custo do ataque, o resultado final em ambos os casos é exatamente o mesmo. A parte da oferta total de ETH detida por um operador de nó aumenta 0,00256% ao dia, e a parte da oferta total de ETH detida por um operador não nó diminui 0,00017% por dia. O custo do ataque é de 2.08 milhões de ETH. Portanto, parece que neste modelo a delegação se torna uma máquina Rube Goldberg inútil: podemos muito bem eliminar o intermediário e reduzir drasticamente as recompensas de staking e limitar o total de ETH apostado a 6.25M.

O objetivo deste argumento não é defender a redução das recompensas de staking em 4x e limitar o total de ETH apostado a 6.25 milhões. Em vez disso, é para apontar uma propriedade chave que um sistema de staking que funcione bem deve ter: ou seja, os delegadores devem estar a fazer algo que realmente importa. Além disso, não há problema se os delegadores estiverem motivados a agir corretamente em grande medida pela pressão da comunidade e pelo altruísmo; afinal de contas, essa é a principal força que está a motivar as pessoas a participarem de formas descentralizadas que aumentam a segurança (mas com maior esforço) em vez de formas centralizadas que ameaçam a segurança (mas com menor esforço) hoje.

Se os delegadores podem ter um papel significativo, qual pode ser esse papel?

Vejo duas classes de respostas:

• Seleção de delegados: os delegados podem escolher a que operadores de nó delegam a sua participação. Os operadores de nós teriam um “peso” em consenso que é proporcional à participação total delegada a eles. A seleção de delegados já existe de forma limitada hoje, no sentido de que os titulares de ReTH ou STETH podem retirar o seu ETH e mudar para um pool diferente, mas a disponibilidade prática da escolha do delegado pode ser bastante melhorada.
• Participação consensual: os delegadores poderiam ter a opção de assumir um papel a desempenhar no consenso, que seria “mais leve” do que o “full staking” e não sujeito a longos períodos de retirada e risco de corte, mas ainda funcionaria como uma verificação dos operadores de nós. Muitos delegadores não gostariam de fazer isso e prefeririam a interface mais simples de todas de segurar um ERC20 e não fazer mais nada, mas alguns aceitariam a opção.

Expandir os poderes de seleção de delegados

Existem três maneiras de expandir os poderes de seleção de delegados:

• Melhores ferramentas de votação dentro de piscinas
• Mais concorrência entre piscinas
• Delegação consagrada

Votar dentro de pools não existe realmente hoje: no Rocket Pool, qualquer pessoa pode se tornar um operador de nós, e no Lido, são os detentores de LDO que votam, não os titulares de ETH. O Lido tem uma proposta para a dupla governação LDO+STeTH, o que daria aos titulares de STeTH uma palavra a dizer no sentido de que poderiam ativar um gadget que bloqueia novos votos e, portanto, bloqueia os operadores de nós de serem adicionados ou removidos. Dito isto, isso é limitado e pode ser muito mais forte.

A competição entre piscinas existe hoje, mas é fraca. O principal desafio é que os tokens de staking pools mais pequenos são (i) menos líquidos, (ii) mais difíceis de confiar e (iii) menos suportados pelas aplicações.

Podemos melhorar as duas primeiras questões ao reduzir as penalidades a um valor menor, por exemplo, 2 ou 4 ETH. A ETH restante (não cortável) poderia então ser depositada e retirada com segurança instantaneamente, tornando um LST baseado naquele ETH conversível bidirecional com ETH mesmo para os grupos mais pequenos. Poderíamos melhorar a terceira questão criando um contrato central de emissão para LSTs - um pouco semelhante ao ERC-4337 e ao ERC-6900 para carteiras, de modo que possamos garantir que qualquer token de staking emitido através desse contrato é seguro. As aplicações (por exemplo, uma versão do RAI que suporta ETH estaqueada) poderiam ser fortemente encorajadas a suportar todos os tokens de staking emitidos através deste registo.

A delegação consagrada atualmente não existe no protocolo, mas poderia potencialmente ser introduzida. Envolveria uma lógica semelhante às ideias acima, mas implementada a nível do protocolo. Veja este post para prós e contras de consagrar as coisas.

Todas estas ideias são uma melhoria em relação ao status quo, mas há um limite para o benefício que podem proporcionar. A governança da votação por token é péssima e, em última análise, qualquer forma de seleção de delegados sem incentivo é apenas um tipo de votação de token; esta tem sido a minha principal fonte de desconforto com a prova de participação delegada desde o início. Por isso, parece valioso pensar também em permitir formas mais fortes de participação consensual.

Participação consensual

Existem limites para a abordagem atual do staking solo, mesmo sem ter em conta os problemas atuais em torno do liquido staking. Assumindo a finalidade de slot único, as nossas melhores estimativas sugerem um limite de ~ 100k - 1M assinaturas BLS que poderiam ser processadas por slot, e isso pressupõe um aumento significativo no tempo do slot. Mesmo se usarmos SNARKs recursivos para agregar assinaturas, assinar a responsabilidade (para fins de corte) exige que um campo de bits de quem participou esteja disponível para cada assinatura. Se o Ethereum se tornar uma rede à escala global, mesmo de alguma forma usar o danksharding completo para armazenar os campos de bits não seria suficiente: 16 MB por slot suportariam apenas ~ 64 milhões de stakers.

Aqui, também dessa perspectiva, há valor em dividir o staking em um nível cortável de maior complexidade, que atua em todos os slots mas talvez só tenha 10.000 participantes, e um nível de menor complexidade que só é chamado para participar ocasionalmente. O nível de complexidade mais baixa pode estar isento de cortar completamente, ou pode dar aos seus participantes oportunidades de temporariamente (ou seja. por alguns slots) depositar e ficar sujeito a cortes.

Na prática, isto poderia ser implementado por < a href= " https://notes.ethereum.org/@mikeneuder/eip-7251-faq " > raising o limite do saldo do validador e, posteriormente, a implementação de um limiar de saldo (ex. 2048 ETH) para determinar quais validadores existentes entram no nível de complexidade superior versus inferior.

Aqui estão algumas ideias de como estas pequenas funções poderiam funcionar:

• Em cada slot, 10000 pequenos estakers são escolhidos aleatoriamente e podem assinar o que acham que é o chefe desse slot. Uma regra de escolha de garfo LMD GHOST é executada usando os pequenos estacadores como entrada. Se a escolha de bifurcação acionada por pequenos estaker e a escolha de bifurcação orientada pelo operador do nó alguma vez divergirem, o cliente do utilizador não aceita nenhum bloco como finalizado e apresenta um erro. Isso força a comunidade a mediar a situação.
• Um delegador pode enviar uma transação declarando à rede que está online e está disposto a servir como um pequeno participante na próxima hora. Para uma mensagem (bloco ou atestado) de um nó para contar, tanto o nó como um delegador selecionado aleatoriamente devem assinar.
• Um delegador pode enviar uma transação declarando à rede que está online e está disposto a servir como um pequeno participante na próxima hora. A cada época, 10 delegadores aleatórios são escolhidos como fornecedores de lista de inclusão, e mais 10000 são escolhidos como eleitores. Estes são escolhidos k slots com antecedência e recebem uma janela de k-slot para publicar uma mensagem na cadeia confirmando que estão online. Cada fornecedor de lista de inclusão escolhido confirmado pode publicar uma lista de inclusão, e um bloco é inválido, a menos que para cada lista de inclusão, ou (i) contém as transações nessa lista de inclusão, ou (ii) contém votos de 1/2 dos eleitores escolhidos mostrando que a lista de inclusão não está disponível.

Todas essas funções de pequena participação têm em comum que não envolvem a participação ativa em cada slot, não são cortáveis (e, portanto, têm um risco de gerenciamento de chaves muito baixo) e são muito “leves” no sentido de que nem precisam de um nó completo para serem executadas. Verificar apenas a camada de consenso seria suficiente. Assim, podem ser implementados através de aplicações ou plugins de navegador que são na sua maioria passivos e têm sobrecarga computacional muito baixa, requisitos de hardware ou requisitos de know-how técnico, tudo sem sequer assumir avanços técnicos como zk-EVMs.

Estas funções de pequena participação também têm um objetivo comum: evitam que uma maioria de 51% dos operadores de nós se envolvam em censura de transações. O primeiro e o segundo também impedem a maioria de se envolver na reversão final. O terceiro concentra-se mais diretamente na censura, embora seja mais vulnerável à possibilidade de uma maioria de operadores de nós também optar por censurar as mensagens de confirmação do fornecedor da lista de inclusão.

Estas ideias foram escritas a partir da perspectiva de uma solução de staking de duas camadas consagrada implementada no protocolo, mas também poderiam ser implementadas como funcionalidades de staking pool. Aqui estão algumas ideias concretas de implementação:

Conclusões

Se bem feito, ajustes no design do staking podem resolver dois coelhos com uma cajadada só:

1. Dê às pessoas que não têm os recursos ou a capacidade de fazer uma aposta única hoje uma oportunidade de participar no staking que mantém mais poder nas suas mãos: tanto (i) o poder de escolher quais nós estão a suportar como (ii) o poder de participar ativamente no consenso de alguma forma que é mais leve do que a operação de nó de aposta total mas ainda significativo. Nem todos os participantes teriam uma ou ambas as opções, mas qualquer uma que fizesse melhoraria significativamente as coisas em relação ao status quo.
2. Reduza o número de assinaturas que a camada de consenso do Ethereum precisa processar em cada slot, mesmo num regime de finalidade de slot único, para um número menor como ~10.000. Isso também ajudaria na descentralização, tornando muito mais fácil para todos executarem um nó de validação.

Para muitas destas soluções, existem diferentes camadas de abstração onde a solução para o problema pode viver: poderes concedidos aos utilizadores dentro de um protocolo de staking pool, escolha do utilizador entre protocolos de staking pool e consagração no protocolo. Esta escolha deve ser considerada com cuidado, e a consagração mínima viável, minimizando a complexidade do protocolo e o nível de alteração da economia do protocolo enquanto ainda atinge o objetivo desejado, é geralmente o melhor.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de [< a href= " https://notes.ethereum.org/@vbuterin /staking_2023_10 " > notes.ethereum.org]. Todos os direitos de autor pertencem ao autor original [notes.ethereum.org]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.