Mudanças no protocolo e no pool de apostas que poderiam melhorar a descentralização e reduzir a sobrecarga do consenso

Agradecimentos especiais a Mike Neuder, Justin Drake e outros pelos comentários e análises. Veja também: postagens anteriores sobre temas semelhantes de<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 parcela de apostas emergentes em duas camadas. Por piquetagem de duas camadas, quero dizer aqui um modelo de piquetagem onde há duas classes de participantes:

1. Operadores de nós, que administram nós e oferecem sua reputação ou algum valor fixo de capital próprio como garantia
2. Delegantes, que depositam alguma quantidade de ETH, sem compromisso mínimo e sem exigência estrita de participar de qualquer outra forma além de trazer suas garantias

Este emergente staking de dois níveis surge através das ações de uma grande parte dos stakers que participam em pools de staking que oferecem tokens de staking líquidos (LSTs), por exemplo. Piscina de foguetes e Lido.

O status quo tem duas falhas principais:

• Risco de centralização em operadores de nós. Os mecanismos de escolha de operadores de nós em pools de piquetagem existentes ou não são muito descentralizados ou apresentam outras falhas.
• Carga desnecessária da camada de consenso. O Ethereum L1 verifica aproximadamente 800.000 assinaturas por época e com<a href="https://notes.ethereum.org/ @vbuterin /single_slot_finality">single finalidade do slot que pode aumentar para 800.000 por slot. Esta é uma carga grande. Além disso, devido à grande parcela de staking líquido, a rede não está obtendo todos os benefícios de assumir esta carga. Se a rede puder ser aceitavelmente descentralizada e segura sem exigir que cada staker assine em cada slot, então poderemos confiar muito mais nessa solução e reduzir o número de assinaturas por slot para, por exemplo. 10.000.

Esta postagem descreverá possíveis soluções para esses dois problemas. Ele assumirá particularmente o seguinte ângulo: suponha que tomemos como certo que a maior parte do capital é detida por pessoas que não estão dispostas a administrar pessoalmente nós de staking em sua forma atual, assinando mensagens em cada slot e bloqueando seus depósitos e sujeitando-os a cortes. . Que outro papel podem desempenhar que contribua significativamente para a descentralização e segurança da rede?

Como funciona o staking em duas camadas hoje?

Os dois pools de piquetagem descentralizados mais populares da atualidade, Lido e RocketPool, estão criando ecossistemas emergentes de piquetagem 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, de forma eficaz pelos titulares de LDO
• Delegadores: pessoas segurando stETH. stETH é criado quando alguém deposita ETH no sistema de contrato inteligente Lido, o que permite que os operadores de nós façam staking (mas, porque aretirada as credenciais estão vinculadas a um endereço ETH de contrato inteligente, elas não podem tomá-lo para si mesmas)

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

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

O papel dos delegadores

Nesses sistemas (ou em novos sistemas habilitados por possíveis mudanças futuras de protocolo), uma questão importante a ser feita é: da perspectiva do protocolo, qual é o sentido de ter delegadores?

Para ver por que a questão é significativa, consideremos o seguinte mundo. A mudança de protocolo proposta nesta postagem recente, de limitar as penalidades de redução a 2 ETH, foi implementada. Rocket Pool reduz o depósito do operador do nó para 2 ETH em resposta. A participação de mercado do Rocket Pool aumenta para 100% (não apenas entre os stakers, 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).

Suponhamos que os detentores 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%. Suponhamos também que a oferta total de ETH seja de 100 milhões.

Veja como funciona a matemática. Para evitar lidar com capitalização, analisaremos os retornos diários em vez dos 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 apostados é limitada a 6,25 milhões. Além disso, o retorno do operador do nó diminuiu para 1%. Vamos fazer as contas:

Agora, consideremos as duas situações do ponto de vista do custo de ataque. No primeiro caso, os atacantes não se inscreveriam como delegadores: os delegadores não têm poder, portanto não faz sentido. Conseqüentemente, eles investiriam todo o seu ETH para se inscreverem como operadores de nós. Para chegar a 1/3 de toda a aposta, eles precisariam investir 2,08 milhões de ETH (o que, para ser justo, ainda é bastante! por exemplo. veja<a href="https://notes.ethereum.org/ @vbuterin /single_slot_finality#Idea-1-super-committees">isto discussão sobre supercomitês, uma proposta de escalonamento de piquetagem que também teria diminuído o custo do ataque para um valor semelhante). No segundo caso, os invasores apenas apostariam e, para chegar a 1/3 de toda a aposta, precisariam investir… 2,08 milhões de ETH.

Tanto do ponto de vista económico da estaca como do custo do ataque, o resultado final em ambos os casos é exactamente o mesmo. A participação do fornecimento total de ETH detido por um operador de nó aumenta 0,00256% por dia, e a participação do fornecimento total de ETH detido por um operador que não é de 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 inútil de Rube Goldberg: poderíamos muito bem eliminar o intermediário e reduzir drasticamente as recompensas de aposta e limitar o total de ETH apostado a 6,25 milhões.

O objetivo deste argumento não é defender a redução das recompensas de aposta em 4x e o limite do total de ETH apostado em 6,25 milhões. Em vez disso, trata-se de apontar uma propriedade fundamental que um sistema de staking que funcione bem deve ter: nomeadamente, os delegadores devem estar a fazer algo que realmente importa. Além disso, não há problema se os delegantes forem motivados a agir corretamente, em grande parte, pela pressão e pelo altruísmo da comunidade; afinal, essa é a principal força que motiva as pessoas a apostar em 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).

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

Vejo duas classes de respostas:

• Seleção de delegados: os delegados podem escolher a quais operadores de nó delegarão sua aposta. Os operadores de nós teriam um “peso” no consenso que é proporcional à aposta total que lhes foi delegada. A seleção de delegados já existe hoje de forma limitada, no sentido de que os titulares de rETH ou stETH podem retirar seus ETH e mudar para um pool diferente, mas a disponibilidade prática da escolha de delegados poderia ser bastante melhorada.
• Participação de consenso: os delegantes poderiam ter a opção de assumir um papel a desempenhar no consenso, que seria “mais leve” do que a aposta total e não estaria sujeito a longos períodos de retirada e redução de risco, 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 manter um ERC20 e não fazer mais nada, mas alguns aceitariam a opção.

Expandindo 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 em pools
• Mais competição entre pools
• Delegação consagrada

A votação dentro dos pools realmente não existe hoje: no Rocket Pool, qualquer um pode se tornar um operador de nó, e no Lido, são os detentores de LDO que votam, não os detentores de ETH. Lido tem uma proposta de governança dupla LDO + stETH, que daria aos detentores de stETH uma palavra a dizer no sentido de que eles poderiam ativar um gadget que bloqueia novos votos e, portanto, impede que operadores de nós sejam adicionados ou removidos. Dito isto, isto é limitado e poderia ser muito mais forte.

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

Podemos melhorar as duas primeiras questões limitando a redução das sanções a um valor menor, por exemplo. 2 ou 4 ETH. O ETH restante (não cortável) poderia então ser depositado com segurança e retirado instantaneamente, tornando um LST baseado nesse ETH conversível bidirecional com ETH, mesmo para os pools menores. Poderíamos melhorar a terceira questão criando um contrato central de emissão para LSTs - algo semelhante ao ERC-4337 e ERC-6900 para carteiras, de modo que possamos garantir que qualquer token de staking emitido através desse contrato é seguro. Os aplicativos (por exemplo, uma versão do RAI que suporta ETH apostado) poderiam ser fortemente encorajados a apoiar todos os tokens de piquetagem emitidos através deste registro.

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

Todas essas ideias são uma melhoria em relação ao status quo, mas há um limite para o benefício que elas podem proporcionar. A governança da votação simbólica é uma droga e, em última análise, qualquer forma de seleção de delegados não incentivada é apenas um tipo de votação simbólica; esta tem sido minha principal fonte de desconforto com a prova de participação delegada desde o início. Portanto, parece valioso pensar também em permitir formas mais fortes de participação consensual.

Participação de consenso

Existem limites para a abordagem atual de staking individual, mesmo sem levar em conta as questões atuais em torno do staking líquido. Assumindo a finalidade de slot único, nossas melhores estimativas sugerem um limite de aproximadamente 100 mil – 1 milhão de assinaturas BLS que podem ser processadas por slot, e isso pressupõe um aumento significativo no tempo de slot. Mesmo se usarmos SNARKs recursivos para agregar assinaturas, a responsabilidade de assinatura (para fins de redução) requer que um campo de bits de quem participou esteja disponível para cada assinatura. Se o Ethereum se tornar uma rede em escala global, então mesmo o uso de full danksharding para armazenar os bitfields não seria suficiente: 16 MB por slot suportariam apenas cerca de 64 milhões de stakers.

Aqui, também sob essa perspectiva, há valor em dividir o staking em uma camada de maior complexidade, que atua em todos os slots, mas talvez tenha apenas 10.000 participantes, e uma camada de menor complexidade que só é convocada para participar ocasionalmente. O nível de menor complexidade poderia ser totalmente isento de cortes ou poderia dar aleatoriamente aos seus participantes oportunidades de temporariamente (ou seja, para alguns slots) depositam e ficam sujeitos a cortes.

Na prática, isso poderia ser implementado<a href="https://notes.ethereum.org/ @mikeneuder /eip-7251-faq">aumentando o limite de saldo do validador e, posteriormente, implementar um limite de saldo (por exemplo. 2048 ETH) para determinar quais validadores existentes entram no nível de complexidade mais alta ou mais baixa.

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

• Em cada slot, 10.000 pequenos apostadores são escolhidos aleatoriamente e eles podem assinar o que acham que é o principal desse slot. Uma regra de escolha de fork LMD GHOST é executada usando os small-stakers como entrada. Se a escolha do fork acionado pelo pequeno staker e a escolha do fork acionada pelo operador do nó divergirem, o cliente do usuário não aceita nenhum bloco como finalizado e exibe 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 disposto a servir como pequeno apostador pela próxima hora. Para que uma mensagem (bloco ou atestado) de um nó seja contada, tanto o nó quanto um delegador selecionado aleatoriamente devem assinar.
• Um delegador pode enviar uma transação declarando à rede que está online e disposto a servir como pequeno apostador pela próxima hora. A cada época, 10 delegadores aleatórios são escolhidos como provedores de listas de inclusão e mais 10.000 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 provedor 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 (i) contenha as transações nessa lista de inclusão ou (ii) contenha votos de 1/2 dos escolhidos eleitores mostrando que a lista de inclusão não está disponível.

Todas essas funções de pequena participação têm em comum o fato de não envolverem participação ativa em cada slot, não serem cortáveis (e, portanto, apresentarem risco de gerenciamento de chave muito baixo) e serem muito “leves”, no sentido de que nem mesmo exigem um nó completo para ser executado. Verificar apenas a camada de consenso seria suficiente. Conseqüentemente, eles poderiam ser implementados por meio de aplicativos ou plug-ins de navegador que são em sua maioria passivos e têm sobrecarga computacional, requisitos de hardware ou requisitos de conhecimento técnico muito baixos, tudo sem sequer assumir avanços técnicos como ZK-EVMs.

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

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

Conclusões

Se bem feitos, ajustes no design de estaqueamento podem resolver dois coelhos com uma cajadada só:

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

Para muitas dessas soluções, existem diferentes camadas de abstração onde a solução para o problema poderia residir: poderes concedidos aos usuários dentro de um protocolo de pool de piquetagem, escolha do usuário entre protocolos de pool de piquetagem e consagração no protocolo. Esta escolha deve ser considerada cuidadosamente, e a consagração mínima viável, minimizando a complexidade do protocolo e o nível de mudança na economia do protocolo e, ao mesmo tempo, atingindo o objetivo desejado, é geralmente a melhor opção.

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [ <a href="https://notes.ethereum.org/@vbuterin/stake_2023_10"> notes.ethereum.org ]. Todos os direitos autorais pertencem ao autor original [notes.ethereum.org]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos 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 do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.