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 de consenso desnecessário presentes nos protocolos LSDFi e pools de liquidez.

Autor:Vitalik Buterin

Tradução: bayemon.eth, ChainCatcher

O estágio atual de desenvolvimento do Ethereum pode ser descrito como contendo uma grande quantidade de staking em dois níveis (two-tiered staking). O staking em dois níveis aqui se refere a um modelo de staking com dois tipos de participantes.

• Operador de Nó (Node Operator): opera o nó e coloca uma certa quantidade 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 é gerado por pools de staking que fornecem tokens de staking líquido (LST) com ampla participação. (Rocket Pool e Lido seguem esse modelo).

No entanto, o staking em dois níveis atualmente apresenta dois defeitos:

• Risco de centralização dos operadores de nós: o mecanismo de seleção de operadores de nós 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 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 em cada slot, a comunidade poderá adotar essas soluções, reduzindo 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 em cada slot, bloquear depósitos e redistribuí-los para quem sofre penalidades. Nessa situação, que 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 caso do Rocket Pool, é assim:

• 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 (também aqui, como o comprovante de saque está vinculado ao endereço do contrato inteligente, o operador não pode sacar livremente).

Papel do Delegador

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

Para entender o significado profundo dessa questão, primeiro pensemos: para a mudança de protocolo mencionada no post, que limita a penalidade de slashing a 2ETH, o Rocket Pool também reduziria o valor de staking do operador de nó para 2ETH, e a participação de mercado do Rocket Pool 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 internas do protocolo e taxas de prioridade + MEV), e a taxa de retorno dos operadores de nó seja de 4%. Suponhamos ainda que o fornecimento total de ETH seja de 100 milhões.

O cálculo é o seguinte. Para evitar cálculos de juros compostos, calcularemos 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, o atacante não se registraria como delegador, pois o delegador, essencialmente, não tem direito de saque, então não faz sentido. Portanto, ele usaria todo seu ETH para staking e se tornaria operador de nó. Para atingir 1/3 do total de staking, ele precisaria investir 2,08 milhões de Ethereum (ainda é um número bastante grande). No segundo caso, o atacante só precisa investir capital, e para atingir 1/3 do total do pool de staking, ainda precisaria investir 2,08 milhões de Ethereum.

Do ponto de vista da economia do staking e do custo de ataque, o resultado final das duas situações é exatamente o mesmo. A participação dos operadores de nó no fornecimento total de ETH aumenta 0,00256% ao dia, enquanto a participação 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.

Claro, 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 operado deve ter uma característica fundamental: os delegadores devem ter responsabilidades importantes em todo o sistema. Além disso, se os delegadores agirem corretamente, motivados principalmente pela pressão da comunidade e altruísmo, tudo bem; afinal, esse é o principal fator que impulsiona hoje a adoção de soluções de staking descentralizadas e de alta segurança.

Responsabilidades dos Delegadores

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

Acredito que há 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 mudar para outro pool, mas a usabilidade real da escolha do delegador pode ser muito melhorada.
• Participação no mecanismo de consenso: o delegador pode escolher desempenhar algum papel no mecanismo de consenso, com responsabilidade mais leve do que o staking integral, sem longos períodos de saída e risco de slashing, mas ainda servindo como contrapeso aos operadores de nó.

Reforçando o poder de escolha dos delegadores

Existem três maneiras de reforçar o poder de escolha dos delegadores:

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

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, impedindo assim a adição ou remoção de operadores de nó, o que dá algum poder 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 os tokens de staking de pools menores têm menor liquidez, é mais difícil conquistar confiança e têm 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 ainda funcione para pools menores. Podemos melhorar o terceiro problema criando um contrato de emissão total 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 em nível de protocolo. Para mais sobre os prós e contras de fixar coisas, veja este artigo.

Essas ideias são melhorias em relação ao status quo, mas as vantagens que oferecem são limitadas. A governança por votação de tokens tem problemas, e, no fim, qualquer forma de escolha de delegador não incentivada é apenas uma forma de votação por tokens; essa sempre foi minha principal insatisfação com o proof-of-stake delegado. Portanto, considerar maneiras mais robustas de participação no consenso também é valioso.

Participação no consenso

Mesmo sem considerar os problemas atuais do staking líquido, há limitações no método atual de staking independente. Suponha que se use single-slot finality; no estado ideal, 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, nem mesmo o armazenamento totalmente descentralizado de campos de bits seria suficiente: 16 MB por slot só suportariam cerca de 64 milhões de stakers.

Nesse sentido, é valioso dividir o staking em uma camada de maior complexidade e capacidade de slashing e uma camada de menor complexidade. A camada de alta complexidade atua em cada slot, mas pode ter apenas 10.000 participantes, enquanto a camada de baixa complexidade só é chamada ocasionalmente para participar. A camada de baixa complexidade pode ser totalmente isenta de slashing, ou pode ser aleatoriamente selecionada para ter a chance de depositar e se tornar alvo de slashing 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 maior ou menor complexidade.

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

• Em cada slot, 10.000 pequenos stakers são escolhidos aleatoriamente para assinar o que acreditam ser o conteúdo representativo do slot. Use esses 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 mais 10.000 delegadores são escolhidos como eleitores. Isso é feito antes do slot k, e eles têm uma janela de k slots para publicar on-chain a confirmação de que estão online. Cada inclusion list provider confirmado pode publicar uma inclusion list, e, para cada inclusion list, ou as transações nela são incluídas, ou há votos suficientes dos eleitores mostrando que a inclusion list está indisponí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é mesmo operar como light nodes. Portanto, a implantação do nó só precisa validar a camada de consenso, e o operador de nó pode usar aplicativos ou extensões de navegador, que são em sua maioria passivos, com baixa demanda 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ó censure transações. O primeiro e o segundo também impedem que a maioria reverta a finalização. 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 implementação de 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 específicas de implementação:

1. Do ponto de vista do protocolo, cada validador pode definir duas chaves de staking: uma chave de staking contínua P e um endereço Ethereum vinculado, e emitir uma chave de staking rápida Q. As informações de assinatura de escolha de fork do nó são rastreadas com P, as informações de assinatura com Q, e se os resultados de armazenamento de PQ forem inconsistentes, nenhum bloco é aceito como finalizado, e o pool de liquidez é responsável por escolher representantes aleatoriamente
2. O protocolo pode permanecer basicamente inalterado, mas a chave pública do validador naquele slot será definida como P+Q. Observe que, para slashing, duas mensagens de slashing podem ter diferentes chaves Q, mas terão a mesma chave P; o design de 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 única chave, 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 indisponibilidade da inclusion list.

Conclusão

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

• Oferecer oportunidade para quem hoje não tem recursos ou capacidade de operar um nó de proof-of-stake independente, permitindo que participem do proof-of-stake e mantenham 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ó de proof-of-stake 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 single-slot finality, reduzindo para cerca de 10.000 ou outro número pequeno. Isso também ajudará a descentralização, tornando mais fácil para todos operarem um nó validador.

Para essas soluções, é possível encontrar abordagens em diferentes níveis de abstração: permissões concedidas aos usuários dentro do protocolo de proof-of-stake, escolha do usuário entre protocolos de proof-of-stake e a configuração 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 alterações 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.