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:
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:
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?
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:
No caso do Rocket Pool, os níveis são:
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).
Vejo duas classes de respostas:
Existem três maneiras de expandir os poderes de seleção de delegados:
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.
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:
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:
Se bem feitos, ajustes no design de estaqueamento podem resolver dois coelhos com uma cajadada só:
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.
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:
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:
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?
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:
No caso do Rocket Pool, os níveis são:
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).
Vejo duas classes de respostas:
Existem três maneiras de expandir os poderes de seleção de delegados:
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.
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:
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:
Se bem feitos, ajustes no design de estaqueamento podem resolver dois coelhos com uma cajadada só:
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.