Escrito por: Vitalik Buterin
Compilado por: bayemon.eth, ChainCatcher
Pode-se dizer que o atual status de desenvolvimento do Ethereum inclui um grande número de apostas de duas camadas. A aposta de duas camadas mencionada aqui refere-se a um modelo de apostas com dois tipos de participantes.
Operador de Nó: Opera um nó e usa sua própria reputação ou uma certa quantia de seu próprio capital como garantia.
Agente Delegador: Os agentes prometem uma determinada quantia de Ethereum, sem valor mínimo e sem restrições adicionais sobre outros métodos de participação que não sejam garantias.
Esta aposta dupla emergente é gerada através da forte participação em pools de apostas que fornecem liquidez para tokens de apostas (LST). (Tanto Rocket Pool quanto Lido possuem este modelo).
No entanto, o staking duplo atual tem duas falhas:
Risco de centralização dos operadores de nó: hoje, o mecanismo de seleção de operadores de nó em todos os pools de staking ainda é excessivamente centralizado
Sobrecarga de consenso desnecessária: a Ethereum L1 precisa validar cerca de 800.000 assinaturas por Epoch, o que é uma carga enorme para um único slot. Além disso, como os pools de staking líquido precisam de muito capital, mas a rede em si não se beneficia suficientemente dessa carga. Portanto, se a rede Ethereum conseguir alcançar descentralização e segurança razoáveis sem que cada staker assine por período, a comunidade pode adotar esse tipo de solução, reduzindo efetivamente a quantidade de assinaturas por período.
Este artigo descreverá uma solução para resolver esses dois problemas. Primeiro, assumimos que a maior parte do capital está nas mãos daqueles que não querem, na forma atual, gerenciar pessoalmente nós de staking, assinar informações em cada slot, bloquear depósitos e, em seguida, realocar os fundos que foram reduzidos. Nessa situação, que papel essas pessoas ainda podem desempenhar para, ainda assim, contribuir de forma significativa para a descentralização e a segurança da rede?
Como o staking duplo atual funciona?
Hoje, os dois pools de staking mais populares são Lido e RocketPool. No caso do Lido, as duas partes envolvidas são:
Operadores de nó: escolhidos por votação do Lido DAO; isso significa que, na prática, são escolhidos por detentores de LDO. Quando alguém deposita ETH no sistema de contratos inteligentes do Lido, é criado stETH; operadores de nó podem colocá-lo em um pool de staking (mas, como os certificados de retirada ficam vinculados ao endereço do contrato inteligente, os operadores não podem sacar livremente).
Agentes: quando alguém armazena ETH no sistema de contratos inteligentes do Lido, é criado stETH. Os operadores de nó podem usá-lo como staking (mas, como os certificados de retirada ficam vinculados ao endereço do contrato inteligente, os operadores não podem sacar livremente).
Para a Rocket Pool, são:
Operadores de nó: qualquer pessoa pode se tornar um operador de nó, bastando enviar 8 ETH e uma certa quantidade de tokens RPL.
Agentes: quando alguém deposita ETH no sistema de contratos inteligentes da Rocket Pool, isso gera rETH. Os operadores de nó podem usá-lo como staking (e, como os certificados de retirada ficam vinculados ao endereço do contrato inteligente, os operadores não podem sacar livremente).
Função do agente
Nesses sistemas (ou em sistemas futuros habilitados por possíveis mudanças de protocolo), uma questão-chave que precisa ser levantada é: qual é o significado de estabelecer agentes do ponto de vista do protocolo?
Para entender o significado profundo desse problema, primeiro pensemos sobre as mudanças de protocolo mencionadas na postagem, como limitar a redução de penalidade a 2 ETH. Então, a Rocket Pool também reduziria o valor de staking dos operadores de nó para 2 ETH, e a participação de mercado da Rocket Pool aumentaria para 100%/ (para stakers e detentores de ETH, à medida que o rETH se torna livre de risco, quase todos os detentores de ETH se tornarão detentores de rETH ou operadores de nó).
Suponha que a taxa de retorno dos detentores de rETH seja 3% (incluindo recompensas do protocolo e taxas de prioridade + MEV) e a taxa de retorno dos operadores de nó seja 4%. Também supomos que a oferta total de ETH é de 100 milhões.
Os resultados do cálculo são os seguintes. Para evitar cálculos de juros compostos, calcularemos os ganhos em base diária:
Agora, suponha que não exista Rocket Pool. Nesse caso, o depósito mínimo de cada staker cairia para 2 ETH, o limite do total de liquidez seria 6,25 milhões de ETH e a taxa de retorno dos operadores de nó cairia para 1%. Agora vamos recalcular:
Considerando esses dois casos do ponto de vista do custo de ataque. No primeiro caso, um atacante não se registraria como agente, porque agentes não têm, em essência, nenhum direito de retirada, então não faz sentido. Assim, eles usariam todo o ETH para fazer staking e se tornariam operadores de nó. Para atingir 1/3 do total de staking, eles precisariam investir 2,08 milhões de ETH (justo dizer que isso ainda é um número consideravelmente grande). No segundo caso, o atacante só precisa investir dinheiro; para atingir 1/3 do total do pool, ele ainda precisaria investir 2,08 milhões de ETH.
Do ponto de vista da economia do staking e do custo de ataque, os resultados finais são exatamente os mesmos em ambos os casos. A parcela da oferta total de ETH em poder dos operadores de nó aumenta 0,00256% ao dia, enquanto a parcela da oferta total de ETH em poder de não operadores de nó diminui 0,00017% ao dia. O custo do ataque é de 2,08 milhões de ETH. Portanto, neste modelo, o agente parece ser uma máquina Rube Goldberg sem sentido; a comunidade racional até tenderia a remover intermediários, reduzindo bastante os prêmios de staking e limitando o total de ETH apostado a 6,25 milhões.
Claro, este artigo não defende reduzir as recompensas de staking em 4x e ao mesmo tempo fixar o limite total do staking em 6,25 milhões. Em vez disso, a visão deste artigo é que um sistema de staking bem funcionando deve ter uma característica essencial: os agentes devem desempenhar um papel importante em todo o sistema. Além disso, se os agentes em grande parte forem incentivados a agir corretamente sob pressão da comunidade e por incentivos altruístas, tudo bem; afinal, essa é a principal força que hoje incentiva as pessoas a adotar soluções de staking descentralizadas e de alta segurança.
Deveres dos agentes
Se os agentes puderem desempenhar um papel significativo no sistema de staking, que papel seria esse?
Acho que existem dois tipos de respostas:
Escolha do agente: o agente pode escolher para quais operadores de nó delegar seu interesse (stake). O “peso” dos operadores de nó no mecanismo de consenso é proporcional ao total de staking delegado a eles. Atualmente, a escolha de agentes ainda é limitada: holders de rETH ou stETH podem retirar seu ETH e mudar para um pool diferente, mas a disponibilidade prática da escolha de agentes pode ser bastante melhorada.
Participação no consenso: os delegantes podem escolher desempenhar algum papel no mecanismo de consenso, com responsabilidades “mais leves” do que o subscrever integralmente, sem longos períodos de saída nem risco de slashing, mas ainda assim capaz de restringir a atuação dos operadores de nó.
Melhorar a escolha de agentes
Há três maneiras de fortalecer o poder de escolha da representação:
Melhorando as ferramentas de votação no pool
Aumentar a competição entre pools
Fixar a representação
Atualmente, votar no pool realmente não é prático: na Rocket Pool, qualquer pessoa pode se tornar um operador de nó; no Lido, o voto é decidido pelos detentores de LDO, não pelos detentores de ETH. O Lido propôs uma proposta de governança dupla para LDO + stETH: eles podem ativar um mecanismo de proteção que impede novos votos, o que impede que operadores de nó sejam adicionados ou removidos, dando a stETH holders alguma voz. Ainda assim, esse poder é limitado; ele poderia ser mais forte.
A competição entre pools já existe hoje, mas é relativamente fraca. O principal desafio é que os tokens apostados por pools menores têm menor liquidez, é mais difícil ganhar confiança e há menos suporte de aplicações.
Podemos melhorar os dois primeiros problemas limitando o valor das penalidades a uma quantidade menor, como 2 ou 4 ETH. Depois, o restante do ETH pode ser seguramente depositado e retirado imediatamente, mantendo a permutação bidirecional funcional mesmo para pools menores de staking. Podemos melhorar o terceiro problema criando um contrato de emissão total, para gerenciar LST (semelhante aos contratos para carteiras usados em ERC-4337 e ERC-6900), para que possamos garantir que qualquer token de staking emitido por meio desse contrato seja seguro.
Atualmente, não existe um poder representativo que esteja consolidado no protocolo, mas parece possível que algo assim exista no futuro. Isso envolveria uma lógica semelhante à das ideias acima, mas implementada no nível do protocolo. Para os prós e contras de consolidar coisas, consulte este artigo.
Essas ideias melhoram o status quo, mas as vantagens que elas oferecem são limitadas. Governança de votação por tokens tem problemas; no final, qualquer forma de escolha de agentes não incentivada é apenas uma forma de votação por tokens. Esse sempre foi meu principal incômodo com a prova de participação delegada. Por isso, também faz sentido considerar formas mais fortes de participação no consenso.
Participação no consenso
Mesmo sem considerar os problemas atuais de staking líquido, ainda existem limitações na abordagem de staking independente atual. Suponha que se use single-slot finality; idealmente, cada slot poderia processar cerca de 100.000 a 1.000.000 de assinaturas BLS. Mesmo se usarmos SNARKs recursivos para agregar assinaturas, para que seja possível rastrear assinaturas, é preciso dar a cada assinatura um campo de índice de participante. Se a Ethereum se tornasse uma rede em escala global, armazenar completamente esse campo de índice de forma totalmente descentralizada não seria suficiente: 16 MB por slot suportariam apenas cerca de 64 milhões de stakers.
Por esse ponto de vista, é valioso dividir o staking em uma camada de reduzibilidade (descomissionamento) de maior complexidade e uma camada de menor complexidade. A camada de alta complexidade é ativada em cada slot, mas pode ter apenas 10.000 participantes; já a camada de menor complexidade só é chamada ocasionalmente para participar. A camada de menor complexidade pode ficar totalmente isenta de redução, ou pode ser atribuída aleatoriamente oportunidades de participação, depositando em alguns slots e se tornando alvos de redução.
Na prática, isso pode ser determinado aumentando o limite do saldo do validador e, em seguida, aumentando o limite de saldo (por exemplo, 2048 ETH), para decidir quais validadores existentes entram em camadas de complexidade maior ou menor.
A seguir estão algumas sugestões de como essas pequenas funções de staking podem operar:
Em cada slot, serão escolhidos aleatoriamente 10.000 pequenos stakers, que podem assinar o conteúdo que acreditam representar aquele slot. Use pequenos stakers como entrada para executar a regra de escolha de fork LMD GHOST. Se houver uma divergência entre a escolha de fork dirigida por pequenos stakers e a escolha de fork dirigida por operadores de nó, o cliente do usuário não aceitará nenhum bloco como confirmação final e exibirá um erro. Isso força a comunidade a intervir e resolver o problema.
O agente pode enviar transações para anunciar à rede que está online e disposto a atuar como pequeno staker pelos próximos uma hora. As mensagens enviadas pelo nó (bloco ou prova) calculadas precisam ser assinadas tanto pelo nó quanto por um agente escolhido aleatoriamente, para que o nó confirme.
O agente pode enviar transações para anunciar à rede que está online e disposto a atuar como pequeno staker durante a próxima hora. Em cada período, são escolhidos 10 agentes aleatórios como provedores de lista de inclusões (inclusion list provider) e 10.000 agentes adicionais como eleitores. Essas escolhas ocorrem antes do k-slot e recebem uma janela de k slots para publicar na cadeia mensagens confirmando que estão online. Cada provedor confirmado da lista de inclusões pode publicar uma lista de inclusões, exceto que, para cada lista de inclusões, ou ou a lista de inclusões contém as transações nela listadas ou é apresentada a votação pelos eleitores que foram escolhidos pela opção 1, indicando que aquela lista de inclusões não está disponível; caso contrário, o bloco será considerado inválido.
O que essas pequenas funções de staking têm em comum é que elas não precisam participar ativamente de cada slot; na verdade, até um nó leve é suficiente para executar todo o trabalho. Assim, a implantação do nó só precisa validar a camada de consenso, e os operadores de nó podem fazê-lo por meio de aplicativos ou extensões de navegador. Esses aplicativos ou extensões, em sua maioria, são passivos, exigindo pouca despesa computacional, baixos requisitos de hardware ou de truques técnicos, e nem mesmo é necessário ter tecnologia avançada como ZK-EVM.
Esses “pequenos personagens” também têm um objetivo em comum: impedir que a maioria dos operadores de nó revise transações. O primeiro e o segundo ainda conseguem impedir que a maioria participe da restauração de finalidade. O terceiro se concentra mais diretamente na revisão, mas é mais fácil de ser influenciado pela escolha de uma maioria de operadores de nó.
Essas ideias foram escritas do ponto de vista de implementar uma solução de staking duplo no protocolo, mas elas também podem ser implementadas como funcionalidades de um pool de staking. A seguir estão algumas ideias concretas de implementação:
Do ponto de vista do protocolo, cada validador pode definir duas chaves de staking: uma chave de staking contínuo P e um endereço Ethereum vinculado que pode ser invocado, além de produzir uma chave de staking rápida Q. A informação de assinatura do nó para escolhas de fork é rastreada por P; a informação de assinatura é por Q. Se o resultado de armazenamento de PQ não coincidir, nenhuma confirmação final de bloco será aceita; quem decide isso de forma aleatória é o pool de liquidez, que seleciona um representante.
O protocolo, em geral, pode permanecer inalterado, mas a chave pública do validador para esse período seria definida como P+Q. Observe que, para redução de posição, as duas mensagens de redução podem ter chaves Q diferentes, mas terão a mesma chave P; a redução precisa lidar com esse caso.
A chave Q só pode ser usada no protocolo para assinar e verificar a lista de inclusões em um bloco. Nesse caso, Q pode ser um contrato inteligente em vez de uma única chave, de modo que o pool de staking pode usá-la para implementar lógicas de votação mais complexas, aceitando uma lista de inclusões enviada por um provedor selecionado aleatoriamente ou, quando votos suficientes para a lista de inclusões não estiverem disponíveis, aceitando a decisão.
Conclusão
Se implementado corretamente, ajustes finos no design de prova de participação em direitos podem resolver dois problemas de uma vez:
Oferece uma oportunidade para aqueles que não têm hoje recursos ou capacidade de fazer uma prova independente de participação em direitos, para que possam participar de uma prova de participação em direitos e, assim, reter mais poder em suas próprias mãos: incluindo (i) o poder de escolher quais nós apoiar e (ii) participar ativamente do consenso de uma forma mais leve, mas ainda significativa, do que operar um nó de prova de participação em direitos em tempo integral. Nem todos os participantes escolherão uma ou ambas essas opções, mas qualquer participante que escolha uma ou ambas verá uma melhoria substancial em relação ao status quo.
Reduz o número de assinaturas que a camada de consenso do Ethereum precisa processar em cada slot, mesmo sob um regime de finalidade por slot único, reduzindo para uma quantidade menor, como cerca de 10.000. Isso também ajudará a descentralização, tornando mais fácil para todos executarem nós validadores.
Para essas soluções, pode-se encontrar formas de resolver o problema em diferentes níveis de abstração: permissões concedidas aos usuários dentro do protocolo de prova de participação em direitos, escolhas dos usuários entre protocolos de prova de participação em direitos e as configurações estabelecidas no protocolo. Essas escolhas devem ser consideradas com cautela e, em geral, é melhor escolher um estabelecimento mínimo viável para reduzir ao máximo a complexidade do protocolo e o grau de mudanças na economia do protocolo, ainda atingindo as metas desejadas.
Especialmente obrigado pelas contribuições e revisões de Mike Neuder, Justin Drake e de outras pessoas. Consulte também: Mike Neuder, Dankrad Feist e arixon.eth, artigos publicados anteriormente sobre temas semelhantes.