A última pesquisa de Vitalik: Como resolver os riscos causados por um grande número de promessas duplas no Ethereum?

原文标题：《Mudanças no protocolo e no pool de staking que poderiam melhorar a descentralização e reduzir a sobrecarga de consenso》

Autor: Vitalik Buterin

Compilado por: bayemon.eth, ChainCatcher

*Agradecimentos especiais a Mike Neuder, Justin Drake e outros pelos comentários e críticas. Veja também: Mike Neuder, Dankrad Feist e postagens anteriores de arixon.eth sobre tópicos semelhantes. *

Pode-se dizer que o status de desenvolvimento atual do Ethereum inclui um grande número de staking de duas camadas (staking de dois níveis).O piquetamento de dois níveis mencionado aqui refere-se ao modelo de piquetagem com dois tipos de participantes.

1. Operador de Nó: Opere nós e use sua própria reputação ou uma certa quantia de seu próprio capital como garantia.
2. Agente Delegador: Os agentes prometem uma determinada quantia de Ethereum, não há valor mínimo e não há 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 estão neste modo).

No entanto, o atual duplo compromisso tem duas falhas:

1. Risco de centralização de operadores de nós: O atual mecanismo de seleção de operadores de nós em todos os pools de piquetagem ainda é excessivamente centralizado.
2. Carga de consenso desnecessária: Cada época do Ethereum L1 precisa verificar cerca de 800.000 assinaturas, o que é uma carga enorme para um único slot. Além disso, como os pools de liquidez exigem mais fundos, a própria rede não se beneficia totalmente dessa carga. Portanto, se a rede Ethereum puder alcançar descentralização e segurança razoáveis sem exigir que cada staker assine de acordo com o período, então a comunidade poderá adotar tal solução, reduzindo efetivamente o número de assinaturas por período.

Este artigo irá descrever uma solução para os dois problemas acima, ** primeiro assumindo que a maior parte do capital é detida por aqueles que não estão dispostos a gerir pessoalmente os nós de staking na sua forma atual, assinar as informações em cada slot, bloquear o depósito e realocá-lo à medida que os fundos são cortados. Então, neste caso, que papel essas pessoas podem desempenhar para ainda dar uma contribuição significativa à descentralização e à segurança da rede? **

**Como funciona a garantia dupla atualmente? **

Atualmente, os dois pools de apostas mais populares são Lido e RocketPool. No que diz respeito ao Lido, as duas partes participantes são:

1. Operador de nó: Votado pelo Lido DAO, o que significa que é realmente eleito pelos titulares de LDO. Quando alguém deposita ETH no sistema de contrato inteligente do Lido, stETH será criado, o operador do nó pode colocá-lo no penhor pool (mas como o certificado de retirada está vinculado ao endereço do contrato inteligente, a operadora não pode sacar dinheiro à vontade)
2. Agente: Quando alguém deposita ETH no sistema de contrato inteligente Lido, stETH será gerado e o operador do nó poderá usá-lo como penhor (mas como o voucher de retirada está vinculado ao endereço do contrato inteligente, o operador não pode sacar dinheiro à vontade)

Para Rocket Pool, eles são:

1. Operador de nó: Qualquer pessoa pode se tornar um operador de nó enviando 8 ETH e um certo número de tokens RPL.
2. Agente: Quando alguém deposita ETH no sistema de contrato inteligente Rocket Pool, o rETH será gerado e o operador do nó poderá usá-lo como penhor (também porque o voucher de retirada está vinculado ao endereço do contrato inteligente, o operador não pode retirar-se à vontade).

Função do agente

Nestes sistemas (ou em novos sistemas habilitados por possíveis mudanças futuras de protocolo), uma pergunta importante a ser feita é: **Qual é o sentido de ter um agente do ponto de vista do protocolo? **

Para entender o profundo significado desta questão, primeiro pensamos nas mudanças de protocolo mencionadas no post, que limitarão a penalidade a 2ETH. O Rocket Pool também reduzirá o valor da aposta dos operadores de nós para 2ETH e a participação de mercado do Rocket Pool. aumentará para 100%/(para stakers e detentores de ETH, à medida que o rETH se tornar livre de risco, quase todos os detentores de ETH se tornarão detentores de rETH ou operadores de nós).

Suponha um retorno de 3% para os detentores de rETH (incluindo recompensas no protocolo e taxas de prioridade + MEV) e um retorno de 4% para os operadores de nós. Também assumimos 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 retornos diariamente:

Agora, supondo que o Rocket Pool não exista, o depósito mínimo por staker cai para 2 ETH, a liquidez total é limitada a 6,25 milhões de ETH e a taxa de retorno do operador do nó cai para 1%. Vamos calcular novamente:

Considere ambos os cenários do ponto de vista do custo do ataque. No primeiro caso, o atacante não se registará como agente porque o agente essencialmente não tem quaisquer direitos para levantar dinheiro, pelo que não tem sentido. Portanto, eles prometerão todos os seus ETH e se tornarão operadores de nós. Para atingir 1/3 do valor total apostado, eles precisariam apostar 2,08 milhões de Ethereum (o que, para ser justo, ainda é um número bastante grande).No segundo caso, o invasor só teria que apostar fundos para atingir o valor. pool de apostas Para 1/3 do valor total, eles ainda precisam investir 2,08 milhões de Ethereum.

**Do ponto de vista da economia de staking e do custo do ataque, o resultado final de ambos os casos é exatamente o mesmo. **A participação do fornecimento total de ETH detido por operadores de nós aumenta 0,00256% todos os dias, e a participação do fornecimento total de ETH detido por operadores não-nós diminui 0,00017% todos os dias. O custo do ataque é de 2,08 milhões de ETH. ** Portanto, neste modelo, o agente parece ter se tornado uma máquina de Rube Goldberg sem sentido, e a comunidade racional está até inclinada a remover o intermediário, reduzir significativamente as recompensas de aposta e limitar o valor total de ETH apostado a 6,25 milhões individuais. **

É claro que este artigo não defende a redução da recompensa da aposta em 4 vezes e a limitação do valor total da aposta a 6,25 milhões. Pelo contrário, o objetivo deste artigo é que um atributo chave de um sistema de staking que funcione bem é que os agentes devem assumir responsabilidades importantes no sistema global**. Além disso, não importaria se os agentes fossem motivados, em grande parte, pela pressão e pelo altruísmo da comunidade para tomar as medidas corretas; afinal, é isso que incentiva as soluções de staking descentralizadas e de alta segurança hoje em dia.

As responsabilidades dos agentes

Se os agentes pudessem desempenhar um papel significativo no sistema de staking, qual seria esse papel?

Acho que existem duas categorias de respostas:

• **Seleção de Agente: **Os agentes podem escolher a quais operadores de nó confiar suas apostas. O “peso” dos operadores de nós no mecanismo de consenso é proporcional à participação total que lhes é confiada. Atualmente, o mecanismo de seleção de agentes ainda é limitado, ou seja, os detentores de rETH ou stETH podem retirar seus ETH e mudar para um pool diferente, mas a disponibilidade real de seleção de agentes poderia ser bastante melhorada.
• Participação no mecanismo de consenso: Os delegadores podem optar por desempenhar um determinado papel no mecanismo de consenso. A responsabilidade é “mais leve” do que a assinatura completa, e não haverá um longo período de saída e redução de risco, mas ainda pode desempenhar uma função Verifica e equilibra a função dos operadores de nó.

Aprimorar a seleção de agentes

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

1. Ferramentas de votação aprimoradas no pool
2. Aumentar a competição entre pools
3. Fixar direitos de representação

Atualmente, votar no pool não é prático: no Rocket Pool, qualquer pessoa pode se tornar um operador de nó, e no Lido, a votação é decidida pelos detentores de LDO, não pelos detentores de ETH. Lido apresentou uma proposta de governança dupla de LDO + stETH. Eles podem ativar um mecanismo de proteção que impede novos votos e, assim, impede que operadores de nós sejam adicionados ou removidos. Isso de alguma forma dá aos detentores de stETH uma palavra a dizer. Ainda assim, este poder é limitado e pode ser mais poderoso.

A concorrência entre grupos já existe hoje, mas é relativamente fraca. O principal desafio é que os tokens de piquetagem de pools de piquetagem menores são menos líquidos, mais difíceis de ganhar confiança e menos suportados por aplicativos.

**Podemos melhorar os dois primeiros problemas limitando o valor da penalidade a um valor menor, como 2 ou 4 ETH. **O ETH restante pode então ser depositado com segurança e retirado instantaneamente, permitindo que resgates bidirecionais ainda sejam válidos para grupos de apostas menores. Podemos melhorar o terceiro problema criando um contrato de emissão total para gerenciamento de LST (semelhante aos contratos que ERC-4337 e ERC-6900 usam para carteiras) para que possamos garantir que todos os tokens apostados emitidos através deste contrato estão seguros.

Atualmente, não existem poderes representativos sólidos no acordo, mas parece provável que tal situação exista no futuro. Envolverá uma lógica semelhante à ideia acima, mas implementada no nível do protocolo. Veja este artigo sobre os prós e os contras de solidificar as coisas.

Estas ideias são melhorias em relação ao status quo, mas as vantagens que oferecem são limitadas**. Existem problemas com a governança da votação simbólica e, em última análise, qualquer forma de seleção de procuração não incentivada é apenas uma forma de votação simbólica; esta sempre foi minha principal reclamação com a Prova de Participação Delegada. **Portanto, também há valor em considerar formas de alcançar uma participação de consenso mais forte.

Participação por consenso

Mesmo deixando de lado os problemas atuais com a aposta de liquidez, existem limitações aos atuais métodos de aposta independente. Supondo que a finalidade de slot único seja usada, cada slot pode idealmente lidar com aproximadamente 100.000 a 1.000.000 assinaturas BLS. Mesmo se usarmos SNARKs recursivos para agregar assinaturas, cada assinatura precisa receber um campo de bit de participante para rastreabilidade. **Se o Ethereum se tornar uma rede em escala global, os campos de bits de armazenamento totalmente descentralizados não serão suficientes: 16 MB em cada slot podem suportar apenas aproximadamente 64 milhões de stakers.

Dessa perspectiva, há valor em dividir o staking em níveis redutíveis de maior complexidade e níveis de complexidade mais baixa, onde cada slot estará ativo, mas poderá ter apenas 10.000 participantes. As camadas de menor complexidade são chamadas para participar apenas ocasionalmente. As camadas de menor complexidade poderiam ser completamente isentas de reduções, ou os participantes poderiam receber aleatoriamente a oportunidade de depositar em alguns slots e se tornarem alvos de reduções.

Na prática, isto pode ser conseguido aumentando o limite de saldo do validador e subsequentemente aumentando o limite de saldo (por exemplo, 2048 ETH) para determinar quais validadores existentes passam para níveis de complexidade mais altos ou mais baixos.

Aqui estão algumas sugestões sobre como essas pequenas funções de piquetagem podem funcionar:

1. Para cada slot, 10.000 pequenos apostadores serão selecionados aleatoriamente e poderão assinar o que considerarem representativo do slot. Execute a regra de seleção de fork LMD GHOST usando pequenos stakers como entrada. Se houver alguma discordância entre a seleção de fork conduzida por pequenos stakers e a seleção de fork conduzida por operadores de nós, 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 para resolver a situação.
2. Os agentes podem enviar transações anunciando à rede que estão online e dispostos a servir como pequenos apostadores durante a próxima hora. O cálculo da mensagem (bloqueio ou prova) enviada pelo nó requer que tanto o nó quanto um agente selecionado aleatoriamente assinem as informações de confirmação do nó**.
3. Os agentes podem enviar transações anunciando à rede que estão online e dispostos a servir como pequenos apostadores durante a próxima hora. A cada época, 10 agentes aleatórios são selecionados como provedores de listas de inclusão e mais 10.000 agentes são selecionados como eleitores. Eles são selecionados antes dos k-slots e recebem uma janela k-slot para publicar uma mensagem na cadeia confirmando sua presença online. Cada fornecedor de lista de inclusão selecionado confirmado pode publicar uma lista de inclusão, a menos que, para cada lista de inclusão, uma transação incluída nessa lista de inclusão ou um voto de um eleitorado geral 1 selecionado indique que a lista de inclusão não está disponível, caso contrário o bloqueio será considerado inválido .

O que esses pequenos nós de staking têm em comum é que eles não precisam participar ativamente de cada slot, ou mesmo precisam apenas de nós leves para concluir todo o trabalho. Portanto, a implantação de nós requer apenas a verificação da camada de consenso, que os operadores de nós podem alcançar através de aplicativos ou plug-ins de navegador, que são em sua maioria passivos e não impõem nenhuma sobrecarga computacional, requisitos de hardware ou conhecimento técnico. requerem tecnologia avançada como ZK-EVM.

Esses “pequenos atores” também têm um objetivo comum: impedir a revisão das transações pela maioria de 51% dos operadores de nós. **O primeiro e o segundo tipos também podem impedir que a maioria das pessoas participe da restauração final. O terceiro está mais diretamente relacionado com a censura, mas é mais suscetível às escolhas dos operadores dos nós majoritários.

Essas ideias são escritas da perspectiva de uma solução de piquetagem dupla implementada no protocolo, mas também podem ser implementadas como um recurso de pools de piquetagem. Aqui estão algumas ideias de implementação específicas:

1. Do ponto de vista do protocolo, cada verificador pode definir duas chaves de penhor: uma chave de penhor contínua P e um endereço Ethereum vinculado que pode ser chamado e gerar uma chave de penhor rápida Q. O rastreamento de informações de assinatura do nó para seleção de fork é representado por P, e as informações assinadas são representadas por Q. Se os resultados de armazenamento de PQ forem inconsistentes, a finalização de qualquer bloco não será aceita, e o pool de liquidez será responsável por selecionar aleatoriamente representantes.
2. O protocolo pode permanecer praticamente inalterado, mas a chave pública do validador para este período será definida como P+Q. Observe que, para reduções, duas mensagens redutíveis podem ter teclas Q diferentes, mas terão a mesma tecla P; o projeto de redução precisa lidar com esse caso.
3. A chave Q só pode ser utilizada no protocolo para assinar e verificar listas de inclusão em blocos. Nesse caso, Q pode ser um contrato inteligente em vez de uma chave única, de modo que o pool de staking pode usá-lo para implementar uma lógica de votação mais complexa, aceitando uma lista inclusiva de um provedor selecionado aleatoriamente ou o suficiente Indica que a lista que o contém não está disponível para votos .

para concluir

Se implementado corretamente, o ajuste fino do design da prova de aposta pode resolver dois problemas de uma só vez:

1. Fornecer uma oportunidade para aqueles que não têm os recursos ou a capacidade de realizar uma prova de aposta independente hoje para participar da prova de aposta, mantendo assim 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 que seja mais leve, mas ainda significativa, do que operar totalmente um nó de prova de aposta. Nem todos os participantes escolherão uma ou ambas as opções, mas qualquer participante que escolha uma ou ambas as opções experimentará uma melhoria significativa em relação ao status quo.
2. Reduzir o número de assinaturas que a camada de consenso Ethereum precisa processar em cada slot, mesmo sob um regime de finalidade de slot único, para um número menor, como cerca de 10.000. Isso também ajudará na descentralização, tornando mais fácil para todos executarem nós de validação.

Para estas soluções, soluções para o problema podem ser encontradas em diferentes níveis de abstração: permissões concedidas aos usuários dentro de protocolos de prova de aposta, seleção de usuários entre protocolos de prova de aposta e estabelecimento dentro dos protocolos. Esta escolha deve ser cuidadosamente considerada, e muitas vezes é melhor escolher uma configuração mínima viável para minimizar a complexidade do protocolo e a extensão das alterações na economia do protocolo, ao mesmo tempo que atinge os objetivos desejados.