Nova pesquisa de Vitalik: Como os protocolos LSDFi e a liquidez precisam mudar para aumentar a descentralização e reduzir a sobrecarga de consenso?

Este artigo irá focar principalmente nos atuais riscos de centralização dos operadores de nós e no fardo desnecessário de consenso presentes nos protocolos LSDFi e pools de liquidez.

Autor:Vitalik Buterin

Tradução: bayemon.eth, ChainCatcher

O estado atual do desenvolvimento do Ethereum pode ser descrito como contendo uma grande quantidade de staking em dois níveis (two-tiered staking), onde este termo refere-se a um modelo de staking com dois tipos de participantes.

• Operador de nó (Node Operator): opera nós e coloca uma certa quantia de capital próprio como garantia, respaldado por sua reputação
• Delegador (Delegator): os delegadores fazem staking de uma quantidade de Ethereum, sem valor mínimo, e não há restrições adicionais além do colateral

Esse novo modelo de staking em dois níveis é criado por pools de staking que oferecem tokens de staking líquido (LST) a muitos participantes (Rocket Pool e Lido seguem esse modelo).

No entanto, o staking em dois níveis atual apresenta dois problemas:

• Risco de centralização dos operadores de nó: atualmente, o mecanismo de seleção dos operadores de nó em todos os pools de staking ainda é excessivamente centralizado
• Fardo de consenso desnecessário: o Ethereum L1 precisa validar cerca de 800.000 assinaturas por Epoch, o que é uma carga enorme para cada slot. Além disso, como os pools de staking líquido exigem mais capital, a rede em si não se beneficia plenamente desse fardo. Portanto, se a rede Ethereum puder alcançar descentralização e segurança razoáveis sem exigir que cada staker assine a cada slot, a comunidade pode adotar tais soluções para reduzir efetivamente o número de assinaturas por slot.

Este artigo irá descrever soluções para os dois problemas acima, assumindo inicialmente que a maior parte do capital está nas mãos daqueles que não desejam operar nós de staking pessoalmente na forma atual, assinar informações a cada slot, bloquear depósitos e redistribuir fundos para quem for penalizado. Nessa situação, qual papel essas pessoas ainda podem desempenhar para contribuir de forma significativa para a descentralização e segurança da rede?

Como funciona o staking em dois níveis atualmente?

Atualmente, os dois pools de staking mais populares são Lido e RocketPool. No caso do Lido, as duas partes envolvidas são:

• Operador de nó: escolhido por votação do Lido DAO, o que significa que, na prática, são escolhidos pelos detentores de LDO. Quando alguém deposita ETH no sistema de contratos inteligentes do Lido, é criado stETH, que o operador de nó pode usar para staking (mas, como o comprovante de saque está vinculado ao endereço do contrato inteligente, o operador não pode sacar livremente)
• Delegador: quando alguém deposita ETH no sistema de contratos inteligentes do Lido, é gerado stETH, que o operador de nó pode usar para staking (mas, como o comprovante de saque está vinculado ao endereço do contrato inteligente, o operador não pode sacar livremente)

No Rocket Pool, temos:

• Operador de nó: qualquer pessoa pode se tornar operador de nó, bastando depositar 8 ETH e uma certa quantidade de tokens RPL.
• Delegador: quando alguém deposita ETH no sistema de contratos inteligentes do Rocket Pool, é gerado rETH, que o operador de nó pode usar para staking (novamente, como o comprovante de saque está vinculado ao endereço do contrato inteligente, o operador não pode sacar livremente).

O papel do delegador

Nesses sistemas (ou em novos sistemas habilitados por futuras mudanças de protocolo), uma questão fundamental precisa ser levantada: do ponto de vista do protocolo, qual é o propósito de se ter delegadores?

Para entender profundamente essa questão, vamos primeiro considerar uma mudança de protocolo mencionada neste artigo, que limita a penalidade de slashing a 2 ETH. O Rocket Pool também reduziria o valor de staking dos operadores de nó para 2 ETH, e sua participação de mercado aumentaria para 100% (para stakers e detentores de ETH, à medida que rETH se torna livre de risco, quase todos os detentores de ETH se tornariam detentores de rETH ou operadores de nó).

Suponha que a taxa de retorno dos detentores de rETH seja de 3% (incluindo recompensas do protocolo e taxas de prioridade + MEV), enquanto a dos operadores de nó seja de 4%. Suponhamos também que o fornecimento total de ETH seja de 100 milhões.

O cálculo é o seguinte. Para evitar cálculo de juros compostos, vamos calcular os rendimentos em base diária:

Agora, suponha que o Rocket Pool não exista, então o depósito mínimo para cada staker cai para 2 ETH, o limite total de liquidez é de 6,25 milhões de ETH, e a taxa de retorno dos operadores de nó cai para 1%. Vamos calcular novamente:

Considerando o custo de ataque em ambas as situações. No primeiro caso, um atacante não se registraria como delegador, pois delegadores essencialmente não têm direito de saque, então não faz sentido. Portanto, eles usariam todo seu ETH para staking como operadores de nó. Para atingir 1/3 do total em staking, precisariam investir 2,08 milhões de ETH (o que ainda é um número considerável). No segundo caso, o atacante só precisa investir fundos; para atingir 1/3 do total do pool de staking, ainda precisaria investir 2,08 milhões de ETH.

Do ponto de vista da economia do staking e do custo de ataque, o resultado final é exatamente o mesmo nos dois casos. A participação dos operadores de nó no fornecimento total de ETH aumenta 0,00256% ao dia, enquanto a dos não operadores de nó diminui 0,00017% ao dia. O custo de ataque é de 2,08 milhões de ETH. Portanto, neste modelo, o delegador parece ser uma máquina de Rube Goldberg sem sentido, e uma comunidade racional tenderia a eliminar o intermediário, reduzir drasticamente as recompensas de staking e limitar o total de ETH em staking a 6,25 milhões.

Obviamente, este artigo não defende reduzir as recompensas de staking em 4 vezes e limitar o total de staking a 6,25 milhões. Pelo contrário, o ponto de vista aqui é que um sistema de staking bem projetado deve possuir uma característica fundamental: os delegadores devem assumir responsabilidades importantes no sistema como um todo. Além disso, não há problema se os delegadores forem motivados em grande parte por pressão comunitária e altruísmo para agir corretamente; afinal, esse é o principal fator que incentiva hoje a adoção de soluções de staking descentralizadas e seguras.

As responsabilidades dos delegadores

Se os delegadores podem desempenhar um papel significativo no sistema de staking, qual seria esse papel?

Acredito que existem duas respostas:

• Escolha do delegador: o delegador pode escolher a quais operadores de nó delegar seus interesses. O "peso" do operador de nó no mecanismo de consenso é proporcional ao total de staking delegado a ele. Atualmente, o mecanismo de escolha do delegador ainda é limitado, ou seja, detentores de rETH ou stETH podem retirar seu ETH e migrar para outro pool, mas a usabilidade real da escolha do delegador pode ser muito melhorada.
• Participação no consenso: o delegador pode escolher desempenhar um papel no mecanismo de consenso, com responsabilidade menor do que operar um nó completo, sem longos períodos de saída ou risco de slashing, mas ainda atuando como contrapeso aos operadores de nó.

Fortalecendo o poder de escolha do delegador

Existem três maneiras de fortalecer o poder de escolha do representante:

• Melhorar as ferramentas de votação dentro do pool
• Aumentar a competição entre pools
• Tornar o poder de representação fixo

Atualmente, votar dentro do pool não é prático: no Rocket Pool, qualquer um pode ser operador de nó; no Lido, a votação é decidida pelos detentores de LDO, não pelos detentores de ETH. O Lido propôs uma proposta de governança dupla LDO + stETH, que pode ativar um mecanismo de proteção para impedir novas votações, bloqueando a adição ou remoção de operadores de nó, dando algum poder de voz aos detentores de stETH. Ainda assim, esse poder é limitado e poderia ser mais forte.

A competição entre pools já existe hoje, mas é relativamente fraca. O principal desafio é que tokens de staking de pools menores têm menor liquidez, é mais difícil conquistar confiança e recebem menos suporte de aplicativos.

Podemos melhorar os dois primeiros problemas limitando o valor da penalidade a uma quantia pequena, como 2 ou 4 ETH. Assim, o restante do ETH pode ser depositado e retirado com segurança e imediatamente, permitindo que a troca bidirecional continue válida mesmo para pools menores. Podemos melhorar o terceiro problema criando um contrato de emissão geral para gerenciar LSTs (semelhante ao ERC-4337 e ERC-6900 para carteiras), garantindo que qualquer token de staking emitido por esse contrato seja seguro.

Atualmente, não existe poder de representação fixo no protocolo, mas esse tipo de situação pode existir no futuro. Isso envolveria lógica semelhante às ideias acima, mas implementada no nível do protocolo. Para vantagens e desvantagens de fixar coisas, veja este artigo.

Essas ideias são melhorias em relação ao status quo, mas os benefícios que podem oferecer são limitados. A governança por votação de tokens tem problemas, e qualquer forma de escolha de delegador não incentivada é apenas uma forma de votação por tokens; isso sempre foi minha principal insatisfação com proof-of-stake delegado. Portanto, considerar formas mais robustas de participação no consenso também é valioso.

Participação no consenso

Mesmo sem considerar os problemas atuais do staking líquido, existem limitações nos métodos de staking independente atuais. Suponha que se use single-slot finality; idealmente, cada slot pode processar cerca de 100.000 a 1.000.000 de assinaturas BLS. Mesmo usando SNARKs recursivos para agregar assinaturas, para rastreabilidade, cada assinatura precisa de um campo de bits de participante. Se o Ethereum se tornar uma rede em escala global, mesmo o armazenamento totalmente descentralizado de campos de bits não é suficiente: 16 MB por slot só suportam cerca de 64 milhões de stakers.

Nesse contexto, faz sentido dividir o staking em uma camada de maior complexidade e penalidade e uma camada de menor complexidade, onde a camada de alta complexidade atua a cada slot, mas pode ter apenas 10.000 participantes, enquanto a camada de baixa complexidade só é chamada ocasionalmente. A camada de baixa complexidade pode ser totalmente isenta de penalidade, ou pode ser dada aos participantes a chance de serem penalizados aleatoriamente em alguns slots.

Na prática, isso pode ser feito aumentando o limite de saldo dos validadores e, em seguida, aumentando o limite de saldo (por exemplo, 2048 ETH) para determinar quais validadores entram na camada de alta ou baixa complexidade.

A seguir, algumas sugestões de como esses papéis de staking de pequeno porte podem funcionar:

• Em cada slot, 10.000 pequenos stakers são escolhidos aleatoriamente para 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 divergência significativa entre a escolha de fork dos pequenos stakers e dos operadores de nó, o cliente do usuário não aceitará nenhum bloco como finalizado e exibirá um erro. Isso força a comunidade a intervir para resolver a situação.
• Delegadores podem enviar transações para anunciar à rede que estão online e dispostos a atuar como pequenos stakers na próxima hora. As mensagens enviadas pelos nós (blocos ou provas) exigem que tanto o nó quanto um delegador escolhido aleatoriamente assinem a confirmação do nó.
• Delegadores podem enviar transações para anunciar à rede que estão online e dispostos a atuar como pequenos stakers na próxima hora. A cada época, 10 delegadores aleatórios são escolhidos como provedores de inclusion list, e outros 10.000 como eleitores. Isso é feito antes do k-slot, e eles têm uma janela de k slots para publicar on-chain uma mensagem confirmando que estão online. Cada inclusion list provider confirmado pode publicar uma inclusion list; para cada inclusion list, ou as transações nela são incluídas, ou há votos suficientes de eleitores indicando que a inclusion list não está disponível, caso contrário, o bloco é considerado inválido.

Esses pequenos nós de staking têm em comum o fato de não precisarem participar ativamente de cada slot, podendo até usar apenas um light node para realizar todo o trabalho. Portanto, a implantação do nó só precisa validar a camada de consenso, e os operadores de nó podem usar aplicativos ou extensões de navegador, que são em sua maioria passivos, com requisitos mínimos de computação, hardware ou conhecimento técnico, sem necessidade de tecnologias avançadas como ZK-EVM.

Esses "pequenos papéis" também têm um objetivo comum: impedir que uma maioria de 51% dos operadores de nó realize censura de transações. O primeiro e o segundo métodos também impedem a reversão da finalização por maioria. O terceiro foca mais diretamente na censura, mas é mais suscetível à escolha da maioria dos operadores de nó.

Essas ideias são escritas do ponto de vista de implementar soluções de staking em dois níveis no protocolo, mas também podem ser implementadas como funcionalidades de pools de staking. Aqui estão algumas ideias concretas de implementação:

1. 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, e emitir uma chave de staking rápida Q. As informações de assinatura para escolha de fork são rastreadas por P, e as informações de assinatura por Q. Se os resultados de armazenamento de PQ forem inconsistentes, nenhum bloco é aceito como finalizado, e o pool de liquidez é responsável por selecionar representantes aleatoriamente.
2. O protocolo pode permanecer basicamente inalterado, mas a chave pública do validador para aquele período será definida como P+Q. Observe que, para penalidades, duas mensagens penalizáveis podem ter diferentes chaves Q, mas terão a mesma chave P; o design do slashing precisa lidar com isso.
3. A chave Q só pode ser usada no protocolo para assinar e verificar inclusion lists em blocos. Nesse caso, Q pode ser um contrato inteligente, não uma chave única, permitindo que o pool de staking implemente lógica de votação mais complexa, aceitando inclusion lists de provedores escolhidos aleatoriamente ou votos suficientes indicando que a inclusion list não está disponível.

Conclusão

Se implementadas corretamente, pequenas mudanças no design do proof-of-stake podem resolver dois problemas de uma só vez:

• Oferecer uma oportunidade para aqueles que hoje não têm recursos ou capacidade para operar proof-of-stake de forma independente participarem do proof-of-stake, mantendo mais poder em suas 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ó completo. Nem todos os participantes escolherão uma ou ambas as opções, mas qualquer participante que escolher uma ou ambas terá uma melhoria significativa em relação ao status quo.
• Reduzir o número de assinaturas que a camada de consenso do Ethereum precisa processar em cada slot, mesmo sob finalização de slot único, para cerca de 10.000 ou outro número pequeno. Isso também ajudará a descentralização, tornando mais fácil para todos rodarem um nó validador.

Para essas soluções, é possível encontrar abordagens em diferentes níveis de abstração: poderes concedidos aos usuários dentro do protocolo de proof-of-stake, escolha do usuário entre protocolos de proof-of-stake e configurações dentro do protocolo. Essa escolha deve ser cuidadosamente considerada, e geralmente é melhor optar pela configuração mínima viável, para minimizar a complexidade do protocolo e as mudanças na economia do protocolo, ao mesmo tempo em que se alcançam os objetivos desejados.

Agradecimentos especiais a Mike Neuder, Justin Drake e outros pelo feedback e revisão. Veja também: artigos anteriores de Mike Neuder, Dankrad Feist e arixon.eth sobre temas semelhantes.