Autor: Hank Han, pesquisador da Mint Ventures

1. Introdução

O staking de Ethereum e seus derivados relacionados são, sem dúvida, os tópicos mais quentes dos últimos dois anos. De Beacon Chain a The Merge e Shanghai Upgrade, de LST a DVT a Restaking e LSTfi, testemunhamos a ascensão e o rápido desenvolvimento de staking e faixas relacionadas. Investigando os fatores determinantes por trás disso, não é difícil descobrir que seu desenvolvimento se originou da mudança de paradigma do staking de Ethereum. Portanto, devemos também pensar em como o paradigma de piquetagem do Ethereum evoluirá no longo prazo e como isso afetará as faixas relacionadas e os principais players.

Em um artigo intitulado <Protocol and staking pool changes that could best descentralization and reduce consenso overhead> publicado em 7 de outubro, Vitalik propôs algumas soluções para otimizar o atual mecanismo de staking do Ethereum para reduzir ainda mais a centralização do Ethereum. a carga de consenso. Algumas dessas ideias trarão grandes mudanças no mecanismo de piquetagem e estão alinhadas com as principais tendências de desenvolvimento do Ethereum. Portanto, iremos interpretar o artigo e analisar o impacto potencial de diferentes soluções na pista de piquetagem.

2. Revisão do artigo

2.1 Situação atual do compromisso de dupla camada

Vitalik chama o padrão de piquetagem atual do Ethereum de piquetagem de duas camadas. Neste modelo de piquetagem, existem duas camadas de participantes: operadores de nó e delegadores.

  • Operadores de nós: Os operadores de nós são responsáveis ​​pela operação dos nós Ethereum.

  • Delegadores: Delegadores, usuários que participam do piqueteamento de diversas maneiras (exceto executando os próprios nós).

Atualmente, a principal forma de os delegadores participarem do staking é utilizando os serviços prestados por provedores de serviços de staking, como Lido e Rocket Pool.

2.2 Problemas

Vitalik acredita que o modelo de compromisso de dupla camada trouxe dois problemas, nomeadamente o risco de centralização da via de compromisso e a carga desnecessária na camada de consenso.

  • Risco de centralização da trilha de piquetagem: Depois que os delegadores prometem a ETH, eles precisam de provedores de serviços como o Lido para selecionar os nós. O mecanismo de seleção específico trará o risco de centralização dos operadores dos nós de diferentes ângulos. Por exemplo, se o Lido determinar os operadores por meio de votação DAO, os operadores de nós podem estar inclinados a manter grandes quantidades de LDO para aumentar sua participação no mercado. O Rocket Pool permite que qualquer pessoa se torne um operador de nó após prometer 8 ETH, o que permite que empresas com forte solidez financeira o façam; As operadoras podem “comprar” participação de mercado diretamente.

  • Carga desnecessária na camada de consenso: Atualmente, a camada de consenso do Ethereum precisa agregar e verificar cerca de 800.000 assinaturas em cada época. Se o objetivo da Finalidade de Slot Único (SSF) for alcançado, o Ethereum precisará agregar e verificar 800.000 de um slot. assinaturas, ou seja, a tarefa permanece inalterada e o tempo é reduzido para 1/32 do original, o que impõe requisitos mais elevados ao hardware do nó em execução. A julgar pela atual estrutura de piquetagem de dois níveis, a maior parte do trabalho de verificação é realizada por operadores de nós. Embora o número de verificadores seja grande, os sujeitos que realmente executam os verificadores não são diversos. Em outras palavras, o aumento do número de nós não reduziu a centralização do Ethereum, mas aumentou a carga de consenso sobre o Ethereum. Portanto, o número de nós de verificação pode ser reduzido (reduzir o número de assinaturas que precisam ser processadas), reduzindo assim a carga de consenso do Ethereum (parece mais centralizado, e as medidas de apoio para reduzir a centralização serão explicadas na seção seguinte ).

Conhecimento prévio adicional:

Slot: refere-se ao tempo que leva para um novo bloco ser incluído no consenso. Um slot no Ethereum é de cerca de 12 segundos. Em cada slot, a rede seleciona aleatoriamente um validador como proponente do bloco, responsável por criar novos blocos e enviá-los para outros nós da rede. Além disso, em cada vaga, um comitê de validadores é selecionado aleatoriamente e seus votos determinam a validade do bloco proposto. Ou seja, todos os validadores não precisam participar do trabalho de verificação de um determinado slot. Somente os validadores do comitê selecionado podem participar normalmente de 2/3 dos votos do comitê. Cada slot não exige a participação de todos os validadores, o que facilita o gerenciamento da carga da rede.

Época (período): refere-se a um período de tempo contendo 32 slots. Uma época no Ethereum dura aproximadamente 6,4 minutos. Numa época, um validador só pode aderir a um comité, e todos os validadores activos na rede precisam de fornecer provas para comprovar o seu estatuto “activo” nesta época. O primeiro slot de cada época (normalmente) também é chamado de ponto de verificação.

Finalidade: A “finalidade” de uma transação em uma rede distribuída significa que a transação se torna parte do bloco e não pode ser alterada a menos que uma grande quantidade de ETH seja destruída, fazendo com que o blockchain seja revertido. Ethereum gerencia a finalidade por meio de blocos de “pontos de verificação”. Um par de pontos de verificação (o primeiro slot de épocas adjacentes) será atualizado se receber mais de 2/3 do total de votos ETH apostados. O mais novo dos dois pontos de verificação torna-se o estado "razoável", e o ponto de verificação mais antigo é atualizado para o estado "finalizado" a partir do estado razoável obtido na época anterior. Em média, as transações do usuário estarão em um bloco no meio de uma época, a meia época de distância do próximo ponto de verificação, indicando que as transações são finalizadas em 2,5 épocas, cerca de 16 minutos (após 0,5 épocas, o próximo ponto de verificação é alcançado; após outra época, o próximo ponto de verificação obterá um estado razoável; após outra época, o próximo ponto de verificação obterá o estado final). Idealmente, o 22º slot de uma época alcançaria a plausibilidade do ponto de verificação para aquela época. Portanto, o tempo médio de finalização da transação é de 14min (16+32+22 slots).

Finalidade de slot único (SSF, finalidade de slot único): A finalidade é alcançada imediatamente após cada slot produzir um bloco. O tempo atual que o Ethereum leva para finalizar os blocos é muito longo. A maioria dos usuários não quer esperar cerca de 15 minutos para finalizar as transações e isso restringe o desenvolvimento de aplicativos que desejam atingir um alto rendimento de transações. Além disso, o atraso entre a proposta do bloco e a finalização também cria oportunidades para reorganizações de curto prazo, que os invasores podem explorar para censurar determinados blocos ou realizar extrações de MEV. O mecanismo para lidar com blocos de atualização em etapas também é bastante complexo e é uma das partes mais vulneráveis ​​da base de código Ethereum a pequenos bugs. Todos esses problemas podem ser resolvidos reduzindo o tempo de finalização para um único slot. SSF está no ramo The Merge no roteiro Ethereum (referência: https://twitter.com/VitalikButerin/status/1588669782471368704/photo/1) e é um dos objetivos de longo prazo do Ethereum. No entanto, os funcionários do Ethereum não esperam que o SSF seja lançado dentro de alguns anos e exigirá grandes atualizações, como Verkle Trees e Danksharding, como trabalho preparatório.

2.3 Solução

Vitalik destacou que os atuais delegantes não estão desempenhando o devido papel e acredita que ambos os problemas acima podem ser resolvidos dando aos delegantes mais direitos e obrigações. As duas principais formas de resolver o problema são a expansão dos poderes de selecção dos delegados e a participação por consenso.

2.3.1 Expansão dos poderes de seleção de delegados

Expandir os poderes de seleção de delegados significa expandir as opções dos delegantes, dando-lhes uma posição mais proativa na seleção de prestadores de serviços de staking e operadores de nós. Atualmente, este método existe parcialmente, porque os delegadores detentores de stETH ou rETH podem retirar dinheiro diretamente e depois penhorá-lo para outros pools de staking. No entanto, existem muitas limitações, como a incapacidade de escolher diretamente um operador e saques insuficientes, etc. .

Vitalik mencionou três maneiras de expandir as opções dos delegantes:

  • Melhores ferramentas de votação dentro dos pools, otimizando a votação dentro do pool: ou seja, otimizando a votação dentro do pool de piquetagem, permitindo que os usuários do pool escolham seus próprios operadores de nó, mas esse método não existe atualmente. O Rocket Pool permite que qualquer staker se torne um operador de nó no Lido, os detentores de LDO determinam os operadores de nó, embora o Lido tenha proposto um modelo de governança de dois níveis de LDO + stETH (link da proposta: https://research.lido.fi/t/). ldo-steth-dual-governance/2382).

  • Mais concorrência entre pools, fortalecer a concorrência entre pools: isto é, aumentar o nível de competição entre pools de apostas, permitindo que os delegadores tenham escolhas mais ricas. Mas, na verdade, o LST do pool de apostas de cauda longa está em desvantagem em termos de liquidez, confiabilidade e aceitação de dapp. Ele não pode competir com projetos líderes como o Lido, então os delegados não têm escolha. Vitalik acredita que as três questões de liquidez, confiança e aceitação de dapp podem ser resolvidas por meio de uma série de medidas, como a redução do valor das multas para reduzir os riscos de redução enfrentados pelos delegantes, possibilitando que os usuários retirem o ETH prometido a qualquer momento. ao mesmo tempo, resolvendo assim os problemas de liquidez e falta de confiabilidade do LST, um padrão unificado de token LST também pode ser introduzido, de modo que todos os LSTs no pool de apostas sejam emitidos por meio de um contrato unificado para garantir a compatibilidade e segurança do LST para diferentes dapps; .

Sobre a barra:

O que é barra: O consenso Ethereum exige um certo mecanismo de incentivo para que os validadores atuem ativamente. Para participar do consenso Ethereum, os validadores precisam prometer antecipadamente uma certa quantia de ETH. Se um validador se comportar de maneira inadequada, seu ETH apostado poderá ser reduzido. Existem dois tipos principais de comportamento considerados desonestos: propor vários blocos em um slot (ambiguidade) e enviar votos conflitantes.

Por que reduzir a quantidade de barra pode reduzir os riscos enfrentados pelos delegantes: Na atual estrutura de penhor de camada dupla, os delegantes fornecem apenas ETH prometido, e o comportamento do verificador é na verdade o comportamento do operador do nó, portanto, quando o operador faz o mal , isso fará com que os delegadores sejam punidos em seu nome. Projetos como o Rocket Pool exigem que os operadores dos nós contribuam com uma certa quantidade de ETH prometido para reduzir o problema de agência. Se a quantidade de ETH que pode ser reduzida for reduzida no nível Ethereum na medida em que a participação do operador do nó possa cobri-la, então os delegantes poderão eliminar o risco de redução, e o provedor de serviços de penhor também poderá permitir que os delegantes retirem dinheiro a qualquer momento. tempo sem ter que reservar uma certa quantidade de liquidez.

  • Delegação consagrada, delegação integrada nativa: Ethereum integra direta e nativamente as funções de delegação relacionadas mencionadas acima, como forçar os delegadores a selecionar operadores de nó ao participar do staking no nível do protocolo Ethereum, etc.

2.3.2 Participação por consenso

A participação no consenso permite que os delegados participem do consenso Ethereum de uma forma mais leve, sem trazer encargos adicionais ao consenso Ethereum. Vitalik admitiu que muitos delegados não querem fazer isso. Eles apenas querem realizar LSTs da maneira mais simples, mas também acredita que haverá delegados que participarão ativamente do consenso. Vitalik oferece duas soluções de implementação: integração nativa Ethereum e integração de projetos de terceiros, que serão discutidas uma a uma abaixo.

2.3.2.1 Integração nativa Ethereum

No nível do protocolo Ethereum, os validadores são primeiro divididos em dois tipos: validadores complexos (nível slashable de maior complexidade) e validadores simples (nível de complexidade mais baixa), cada um dos quais realiza tarefas diferentes para garantir o desempenho e a descentralização do Ethereum.

  • Validador complexo: realiza os principais trabalhos de verificação e cálculo do Ethereum e precisa estar sempre online. A quantidade de ETH prometida por cada validador complexo deverá ser aumentada para 2.048 ETH (exemplo dado por Vitalik), e o risco de corte será retido. O número de validadores complexos em toda a rede é limitado a 10.000.

  • Validador simples: Não há limite de cota, limite de staking, barra e só precisa participar do consenso em alguns slots.

    • Fontes de validadores simples: Delegadores que participam do staking por meio de provedores de serviços de staking para fornecer ETH para validadores complexos e usuários da rede que desejam se tornar validadores simples de forma independente; (Nota: Vitalik usou "small-stakers" para se referir a validadores simples no artigo original. A seguir, pequenos stakers e validadores simples serão usados ​​alternadamente)

    • Várias maneiras possíveis de um validador simples funcionar

      • Cada vaga terá 10.000 validadores simples selecionados aleatoriamente para votar no estado de sua preferência.

      • Um delegador pode enviar uma transação para declarar que está online e disposto a se tornar um simples validador durante a próxima hora para votar nos cabeçalhos de bloco que aprova e precisa sair após a conclusão do trabalho.

      • Um delegador pode enviar uma transação para declarar que está online e disposto a se tornar um simples validador na próxima hora. A cada época, 10 delegadores aleatórios serão selecionados para formar a lista de recomendação do bloco, e mais de 10.000 delegadores serão selecionados para se tornarem eleitores. Os verificadores simples nesta parte não precisam sair e os requisitos online expiram com o tempo.

    • As características das três soluções acima são: todas elas são projetadas para evitar ataques de 51% por operadores de nós e melhorar a resistência à censura do Ethereum. A primeira e a segunda soluções evitam principalmente que a finalidade seja revertida; a terceira solução concentra-se mais na resistência à censura da rede, e os verificadores simples precisam trabalhar mais.

    • Pré-requisito para participação leve: existe um cliente ultraleve para uso de verificadores simples, permitindo-lhes concluir o trabalho de verificação por meio de telefones celulares ou páginas da web, o que envolve pesquisas relacionadas em clientes Ethereum leves (como a introdução de Verkle Tree, stateless,; etc.), com o objetivo de reduzir o limite de participação dos validadores.

Fonte: https://notes.ethereum.org/@vbuterin/stake_2023_10

2.3.2.2 Integração de projetos de terceiros

A integração de projetos de terceiros refere-se à realização da participação dos delegadores no consenso Ethereum, principalmente por meio da atualização do próprio pool de apostas. A ideia central é introduzir a assinatura conjunta de delegantes e verificadores no processo de votação por consenso para refletir os desejos do grupo de delegantes. Aqui estão três opções propostas por Vitalik:

  1. O pool de piquetagem declara duas chaves de piquetagem ao abrir uma conta de validador, nomeadamente P (chave de piquetagem persistente) e Q (chave de piquetagem rápida, que é na verdade o resultado de saída quando um endereço Ethereum é chamado). Os nós rastreiam respectivamente as assinaturas de P e Q nas mensagens escolhidas por uma determinada bifurcação. Se as escolhas de P e Q forem iguais, a verificação será bem-sucedida; se forem diferentes, a verificação falhará. O pool de staking é responsável por selecionar aleatoriamente os delegadores como detentores de chaves Q do slot atual.

  2. O verificador gera aleatoriamente uma chave pública de penhor P + Q em cada slot, e a assinatura de votação de cada slot requer cálculo conjunto entre o verificador e os delegados. Como cada slot gera chaves diferentes aleatoriamente, há problemas de atribuição relacionados quando ocorre uma barra, e certos designs precisam ser feitos para resolver esse problema.

  3. Coloque Q no contrato inteligente, em vez de como uma chave mantida diretamente pelos delegantes. Q gerenciado por contratos inteligentes pode introduzir diversas condições de gatilho, trazendo assim uma lógica de votação mais rica para o pool de apostas.

2.3.3 Resumo

Vitalik acredita que se a solução acima for adotada corretamente, os ajustes no design da prova de aposta podem alcançar dois coelhos com uma cajadada só (reduzir a centralização das promessas e reduzir a carga de consenso do Ethereum):

  1. Fornecer àqueles que atualmente não têm recursos ou capacidade para participar de PoS uma oportunidade de participar, dando-lhes mais poder (incluindo o poder de escolher os nós que suportam) e participar de uma forma mais leve, mas ainda significativa. Ao mesmo tempo, Vitalik destacou ainda que nem todos os participantes escolherão estas duas ou uma das opções, mas qualquer opção escolhida pode melhorar a situação atual.

  2. A redução do número de assinaturas que a camada de consenso Ethereum precisa processar por slot, mesmo com uma implementação determinística de slot único, pode ser reduzida para aproximadamente 10.000. Isso contribui para a descentralização e torna mais fácil para todos executarem um nó validador.

Embora as soluções acima estejam em diferentes níveis de abstração, incluindo a otimização de eleições intra-pool, o fortalecimento da competição entre pools e a integração nativa do Ethereum, seus objetivos são resolver os problemas atuais de centralização de promessas e carga de consenso do Ethereum. Vitalik acredita que soluções de implementação específicas devem ser cuidadosamente consideradas antes de serem adotadas, e a solução ideal ainda deve atingir os objetivos desejados, minimizando as alterações de protocolo.

3. Análise do impacto nas trilhas relacionadas ao staking

3.1 Visão geral das trilhas relacionadas ao staking

Consulte a divisão do ecossistema de piquetagem Ethereum do @StakeRewards. De baixo para cima, ele pode ser dividido em camada de verificação, camada de piquetagem, camada de ponte, camada de infraestrutura DeFi e camada de produto estruturado superior. As relações lógicas internas e respectivos valores podem ser resumidos da seguinte forma:

  • Camada validadora: representada por operadores de nó como P2P e Stakefish, fornece os recursos de hardware de nível mais baixo para a camada de piquetagem ou clientes de piquetagem individual. Estes também incluem os prestadores de serviços SSV e Obol, que fornecem tecnologia DVT. A camada verificadora resolve problemas relacionados ao hardware da camada de garantia.

  • Camada de promessa: Os provedores de serviços de promessa representados por Lido e Rocket Pool recebem fundos dos delegantes e fazem interface com os operadores de nós em nome dos delegantes para realizar a verificação de consenso do Ethereum, incluindo EigenLayer, que propôs o conceito de restabelecimento. A camada de penhor encapsula a participação indireta dos delegantes no PoS em produtos financeiros, reduzindo o limite de participação e introduzindo mais ações de penhor no Ethereum.

  • Camada de ponte: Refere-se ao LST (Liquid Staking Token) emitido pela camada de staking. Os usuários participam de vários protocolos DeFi por meio de LST. Os provedores de serviços de staking adicionam pares de negociação LST-ETH a protocolos como o Curve para fornecer aos delegantes liquidez para retirar. de apostar antecipadamente. Reduzir o custo de oportunidade dos delegadores que participam na aposta.

  • Infraestrutura DeFi e camada de produto estruturado: Use o armazenamento de valor e a lucratividade do LST para desenvolver produtos e serviços derivados, criar mais cenários de aplicação LST, enriquecer o ecossistema DeFi e atrair usuários para se comprometerem.

Fonte: https://twitter.com/StakeRewards/status/1711409661734219886/photo/1

No ecossistema de piquetagem, a camada de piquetagem desempenha um papel fundamental na conexão do passado e do próximo: introduzindo mais ações de piquetagem no Ethereum e fornecendo liquidez ao sistema DeFi por meio do LST. A posição central da camada de promessa permite que as suas próprias alterações causem alterações em todo o ecossistema de promessas, pelo que nos concentraremos na análise do impacto de soluções relevantes nos projectos da camada de promessas. A trilha de piquetagem neste artigo se referirá principalmente à camada de piquetagem.

3.2 Impacto potencial das soluções acima na pista de piquetagem

Os ângulos de implementação das soluções acima são diferentes, mas todos terão impacto na trajetória de piquetagem. A seguir analisaremos o impacto das diferentes soluções e inferiremos a viabilidade de adoção das soluções correspondentes.

3.2.1 Expansão dos poderes de seleção de delegados

A seguir está uma breve análise do impacto potencial das três opções mencionadas por Vitalik para expandir as opções dos delegantes.

  • Otimizar a votação dentro dos pools (Melhores ferramentas de votação dentro dos pools): ou seja, otimizar a votação dentro do pool de staking, permitindo que os usuários do pool escolham seus próprios operadores de nó.

    • Impacto potencial: Pode tornar os próprios prestadores de serviços de staking mais descentralizados, mas não pode reduzir a concentração da pista de staking, porque os utilizadores podem confiar mais nos principais prestadores de serviços de staking nas opções do operador que eram originalmente mais controladas pelos prestadores de serviços de staking; ser Parte dele é transferida para os delegantes, o que pode reduzir a captura de valor do token de governança original.

    • Análise de possibilidade de adoção

      • O custo geral é pequeno: nenhuma alteração na camada de consenso Ethereum é necessária, apenas o provedor de serviços de promessa precisa alterar seu próprio mecanismo.

      • Falta de incentivos para os prestadores de serviços de staking existentes: Esta solução exige que os prestadores de serviços de staking existentes mudem ativamente e suportem custos maiores, incluindo custos de desenvolvimento e o custo da utilidade reduzida dos tokens de governação.

    • Resumo: Resolve parcialmente o problema da centralização de promessas, mas não pode resolver o problema da carga de consenso, e o efeito final pode ser médio. O custo de implementação é baixo, mas os prestadores de serviços de compromisso existentes não têm incentivos para o fazer e são menos propensos a adotá-lo. Pode haver novos provedores de serviços de staking que utilizem esse recurso para entrar no mercado.

  • Fortalecer a competição entre pools (Mais competição entre pools): ou seja, fortalecer a competição entre pools de staking para que os delegadores tenham opções ricas. Atualmente, a principal diferença entre os diferentes pools de apostas na atração de usuários reside na liquidez, confiabilidade e aceitação de dapp do LST. Vitalik propôs reduzir o valor da redução e introduzir um padrão LST unificado para reduzir as três diferenças acima e fortalecer a concorrência entre os prestadores de serviços de penhor.

    • Impacto potencial: A diferença entre os prestadores de serviços de piquetagem é reduzida e a quota de mercado de projectos líderes como o Lido diminui, reduzindo a centralização da pista de piquetagem, o ecossistema LSTfi pode tornar-se mais próspero, porque o dapp correspondente pode suportar mais pools de piquetagem; LST; Câmara de Comércio do Serviço de Staking Para buscar diferenciação em outros aspectos, o rumo da concorrência pode se voltar para a receita de staking do próprio LST, principalmente na estratégia de retirada de MEV.

    • Análise de possibilidade de adoção

      • O custo geral é médio: o custo técnico é baixo, porque esta solução não requer alterações na camada de consenso Ethereum, apenas a introdução do novo padrão de token LST, e a cooperação do provedor de serviços de staking na redução da participação de barra do usuário e adotando o novo padrão LST. No entanto, durante o processo de adopção, um grande número de titulares de LST existentes são obrigados a trocar o seu LST pelo novo LST padrão unificado, pelo que há aqui um grande custo de migração.

      • Falta de incentivos para os prestadores de serviços de penhor existentes: Esta solução exige que os prestadores de serviços de penhor existentes façam certas mudanças proativas, suportem certos custos de atualização e desenvolvimento e envolvam uma grande quantidade de custos e riscos de conversão de LST. A adopção desta solução também fez com que os prestadores de serviços existentes enfrentassem a pressão do declínio da quota de mercado.

    • Resumo: O problema da centralização dos compromissos foi em grande medida resolvido, mas o problema da carga de consenso não pode ser resolvido e a solução para o problema está incompleta. O custo global de implementação é médio, mas os prestadores de serviços de compromisso existentes não têm incentivos para o fazer e a possibilidade de adopção é baixa. Pode haver novos provedores de serviços de staking que utilizem esse recurso para entrar no mercado.

  • Delegação integrada nativa (delegação consagrada): As funções de delegação relacionadas mencionadas acima são diretamente incorporadas à camada de protocolo Ethereum, como usuários selecionando diretamente operadores de nó, Ethereum lançando seu próprio padrão de token LST, etc.

    • Impacto potencial: O mesmo impacto do esquema de competição entre pools acima mencionado, mas o suporte da camada de protocolo Ethereum garantirá até certo ponto a segurança da transformação correspondente. Isso pode aumentar a carga sobre o consenso Ethereum porque os usuários que participam da delegação na camada do protocolo Ethereum trarão mais trabalho de verificação para o consenso Ethereum.

    • Adote análise de viabilidade

      • O custo geral é alto: a camada de consenso Ethereum precisa ser atualizada para suportar nativamente funções de delegação relacionadas.

      • Isso pode ir contra a intenção original da atualização: aumenta a carga de consenso no Ethereum, a forma como os delegadores selecionam diretamente os operadores de nós para hospedagem por meio do nível do protocolo é essencialmente mais próxima do DPoS, o que pode ser um resultado que Vitalik não está disposto a ver.

    • Resumo: Resolve em grande medida o problema da centralização de promessas, mas aumentará o problema da carga de consenso. Ao mesmo tempo, o custo da atualização é relativamente alto e requer certas mudanças no Ethereum. A adoção é altamente improvável.

3.2.2 Participação por consenso

A ideia básica da participação no Consenso é permitir que validadores mais simples participem do consenso. A diferença entre as duas soluções é se ela é implementada através da integração nativa do Ethereum ou dentro de um projeto de terceiros.

3.2.2.1 Integração nativa

Segundo a ideia de Vitalik, a solução de integração nativa do Ethereum dividirá diretamente a rede em dois grupos: validadores complexos e validadores simples. O limite de penhor para validadores complexos será aumentado para 2.048 ETH, e o número de validadores será limitado a 10.000. Eles precisam permanecer online em tempo real e ser responsáveis ​​pelo trabalho principal de verificação e cálculo, enquanto a verificação simples só precisa usar seu; possuir equipamento para administrar um cliente leve Participe do consenso em um horário específico e realize apenas tarefas leves, como votação.

Nota: 2048 ETH é o exemplo dado por Vitalik no artigo original, mas é mais provável que se torne o número adotado nos planos subsequentes. Combinando a explicação de Vitalik no artigo <Paths into single-slot finality> e o EIP-7251 citado por Vitalik no artigo original, podemos saber que estes dados têm significado prático: 2048 ETH pode limitar o número de validadores no estado de equilíbrio para Um nível ideal que reduz a carga de consenso sobre o Ethereum e abre caminho para a implementação do SSF. Ao mesmo tempo, em <Protocol e mudanças no pool de staking que poderiam melhorar a descentralização e reduzir a sobrecarga de consenso>, Vitalik propôs uma abordagem prática: Ethereum pode primeiro integrar EIP-7251 como uma transição, ou seja, aumentar o limite de saldo do validador para 2048 ETH e, ao mesmo tempo, manter o limite inferior de 32 ETH e usar 2.048 ETH como limite geral de promessa para permitir que os validadores escolham seu próprio nível; Em resumo, percebe-se que utilizar o número 2048 ETH para análise na análise a seguir tem grande valor de referência.

Fonte: https://notes.ethereum.org/@vbuterin/single_slot_finality

  • impacto potencial

    • Pode resolver simultaneamente a centralização de promessas e o problema de carga do consenso Ethereum: a integração nativa permite que a maioria dos delegadores e outros usuários comuns participem do consenso de forma simples e de baixo custo, melhorando muito a descentralização da rede Ethereum; ao mesmo tempo, 10.000 O limite no número de validadores complexos reduz a dificuldade de chegar ao consenso e o tamanho agregado da assinatura de cada slot, reduzindo a carga de consenso no Ethereum.

    • O valor das tecnologias de segurança, como os serviços dos prestadores de serviços de compromisso e a TVP, tornar-se-á mais elevado e a taxa de penetração será ainda melhorada: um único verificador complexo necessita de realizar uma verificação de rede mais activa e garantir uma taxa online extremamente elevada, para que o operação de hardware À medida que o limite de dimensionalidade aumenta, o valor de tecnologias de segurança como a TVP é ainda mais destacado; o limite de promessa de 2048 ETH faz com que a maioria dos usuários que poderiam originalmente prometer sozinhos se voltem para os delegadores com base no acima exposto, a taxa de penetração dos provedores de serviços de promessa; e os prestadores de serviços técnicos, como a TVP, aumentarão.

    • Haverá um limite máximo para o tamanho do mercado da pista de piquetagem: na visão de Vitalik, a maneira para validadores simples participarem do consenso é executar nós ultraleves por conta própria. O ETH prometido pela parte dos delegantes não criará mais TVL para o provedor de serviços de penhor, e outros usuários que se tornam simples validadores não precisam se tornar delegantes por meio do provedor de serviços de penhor, porque eles próprios precisam executar nós ultraleves e há não há necessidade de hospedá-los para os provedores de serviços e pagar as taxas de hospedagem correspondentes. Portanto, o TVL que os provedores de serviços de staking podem capturar será limitado a 20,48 milhões de ETH.

    • O crescimento a longo prazo dos prestadores de serviços de compromisso e projetos relacionados pode estagnar

      • Ainda há espaço no curto e médio prazo, mas a motivação é insuficiente: a julgar pelo tamanho atual do mercado, a oferta total de ETH se estabilizou em cerca de 120 milhões após EIP-1559 e Merge. aproximadamente 28 milhões, e a taxa de promessa é de aproximadamente 23,29%, ainda há espaço para melhorias no caminho de piquetagem, mas a julgar pela situação de fila de entrada e saída de validadores, o crescimento do piquetagem de ETH atingiu um gargalo com a diminuição; na receita de staking. Sem o aumento no volume de transações em cadeia, se a receita do MEV aumentar significativamente, o número de promessas estará em um estado de equilíbrio estável e o crescimento não terá impulso.

      • O crescimento de projetos de tecnologia, como prestadores de serviços de penhor e TVP, estagnará no longo prazo: desde prestadores de serviços de penhor representados por Lido até projetos de TVP representados por SSV, seus modelos de renda devem cobrar uma certa porcentagem de taxas sobre a renda de penhor deste parte dos fundos. Quando o limite superior dos fundos dos delegantes for 20,48 milhões de ETH, então esta parte dos fundos será inferior aos actuais 28 milhões. Se a receita futura do MEV não aumentar o suficiente (o que significa que a taxa de penhor não é aumentada o suficiente), o. a escala de rendimento absoluta da faixa de piquetagem não será de aumento em vez de diminuição, e não há fonte de crescimento a longo prazo.

Fonte: https://etherscan.io/chart/ethersupplygrowth

Fonte: https://www.validatorqueue.com/

  • Análise de possibilidade de adoção

    • O custo geral é enorme: as regras de participação consensual do Ethereum precisam ser alteradas.

    • Em linha com os interesses de desenvolvimento a longo prazo do Ethereum, uma arquitetura em camadas de validadores pode ser introduzida a longo prazo.

      • Um dos objetivos de desenvolvimento de longo prazo do Ethereum requer a introdução de uma arquitetura em camadas de validador semelhante: Vitalik apontou em <Endgame> que à medida que os blocos ficam maiores (problema de inflação estatal), apenas algumas centenas de nós grandes terão a capacidade de executar nós completos nas condições futuras, Ethereum precisa encontrar outra maneira leve de permitir que mais pessoas participem do consenso e garantir uma desconfiança aceitável e resistência à censura. Ao mesmo tempo, para obter recursos como o determinismo de slot único (SSF) que melhoram o desempenho e a segurança do Ethereum, também são necessários dois tipos de validadores para trabalharem juntos. Os dois tipos de validadores têm responsabilidades diferentes e é mais razoável aplicar regras de piquetagem diferentes (estratificação).

      • A estrutura hierárquica do validador apareceu muitas vezes no roteiro do Ethereum e em artigos relacionados, e há um grande número de soluções leves relacionadas ao cliente em planejamento e pesquisa, com o objetivo de criar condições para que validadores simples participem do consenso.

        • A partir de atualizações importantes, como PBS e Danksharding, podemos ver ideias semelhantes de camadas e divisão de trabalho: permitir que nós profissionais assumam um trabalho mais árduo (como armazenar blobs e blocos de construção) para garantir a eficiência, permitir que nós mais leves participem do consenso; garantir a descentralização.

        • A partir da ideia principal de <Endgame>, podemos ver que a SNARKização (ponderação) da verificação é fornecer um método de referência para que verificadores simples participem do consenso. Também podemos ver no roteiro do Ethereum que pesquisas relacionadas, incluindo stateless, The Verge, etc., estão todas se preparando para que os usuários possam executar nós ultraleves.

<Vitalik: Endgame>, fonte: https://vitalik.ca/general/2021/12/06/endgame.html

Conteúdo relacionado ao The Verge, fonte: https://twitter.com/VitalikButerin/status/1588669782471368704

  • Resumo: Pode resolver os problemas de centralização de promessas e carga de consenso ao mesmo tempo. O custo de adoção é extremamente alto e requer mudanças nas regras de PoS na camada de consenso do Ethereum, mas é do interesse de desenvolvimento de longo prazo do Ethereum, e os preparativos relevantes foram parcialmente refletidos no roteiro do Ethereum. A adopção é possível a longo prazo, mas a realização a curto prazo é menos provável.

3.2.2.2 Integração de projetos de terceiros

Vitalik também propôs um plano de implementação que só é implementado através de pool de piquetagem sem suporte nativo do Ethereum. O núcleo é dividir a chave privada do verificador em duas partes, P e Q, respectivamente, e entregá-las ao nó de verificação e ao usuário respectivamente, permitindo que os usuários participem do consenso por meio da assinatura conjunta de P e Q.

  • Impacto potencial: Pode resolver o problema de centralização do piqueteamento de servidores até certo ponto, mas o efeito é incerto porque o processo de participação do usuário é relativamente complexo e a vontade de participar pode ser pequena. Este plano é mais um ajuste interno do prestador de serviços de penhor e terá pouco impacto no traçado da via.

  • Adote análise de viabilidade

    • Custo moderado de implementação: Não são necessárias grandes mudanças na camada de consenso Ethereum, mas os provedores de serviços de promessa existentes são obrigados a realizar atualizações mais complexas, incluindo o design de divisão de chaves, custódia e assinaturas conjuntas, ao mesmo tempo que atraem usuários para participarem de consenso simples verificação.

    • Os custos suportados pelos prestadores de serviços de penhor aumentarão e os projetos existentes poderão não ser incentivados a atualizar: em primeiro lugar, a divisão e a custódia das chaves privadas do validador e, em segundo lugar, a conceção da experiência do utilizador do utilizador, acarretarão certos custos de atualização para os prestadores de serviços de penhor existentes. , mas é difícil gerar lucros maiores para os prestadores de serviços existentes.

    • À medida que a lógica de verificação se torna mais complexa, pode aumentar a carga de trabalho no Ethereum: uma lógica de verificação mais complexa inclui a comparação de mensagens assinadas por P e Q, etc.

  • Resumo: Pode resolver o problema de centralização dos servidores de promessa até certo ponto, mas o efeito é incerto e terá pouco impacto no padrão dos projetos de acompanhamento. Os projetos existentes têm menos probabilidade de adotá-lo, mas novos provedores de serviços de staking podem usar esse recurso para entrar no mercado.

3.3 Resumo

Vitalik não expressou explicitamente sua preferência por uma determinada solução em seu artigo, mas ainda podemos inferir o que pode acontecer analisando o efeito e o impacto da solução e combinando informações dos artigos anteriores de Vitalik e do roteiro Ethereum.

  • Três opções para expandir a direção dos poderes de seleção de delegados

    • O problema não está completamente resolvido: as soluções relacionadas à expansão dos poderes de seleção de delegados são otimizadas principalmente para o problema da centralização de promessas, mas o efeito da solução é incerto. Dado que a atual estrutura de staking de dois níveis em torno dos pools de staking de delegadores já é de natureza próxima da DPoS, a solução para expandir os poderes de seleção de delegados não quebra a estrutura existente e pode até realçar as características da DPoS. Ao mesmo tempo, esta solução relacionada não resolve o problema da carga de consenso Ethereum, e a solução de integração nativa da delegação também pode aumentar a carga sobre o consenso Ethereum.

    • Os incentivos para a adopção dos actuais intervenientes são pequenos: soluções neste sentido prejudicarão os interesses dos prestadores de serviços de compromisso existentes. Ao mesmo tempo, as soluções para optimizar as eleições intra-grupos e reforçar a concorrência entre grupos também requerem o apoio dos prestadores de serviços de compromisso. Portanto, os prestadores de serviços de promessa existentes têm pouco incentivo para adotar soluções menores.

    • No curto prazo, poderá ser adotado por novos projetos: novos prestadores de serviços de staking poderão utilizar isto como um recurso mais descentralizado para entrar no mercado e competir com projetos existentes.

  • Para soluções no sentido da participação no Consenso

    • O suporte nativo pode ser a solução de longo prazo: O suporte nativo pode resolver tanto a centralização de piquetagem quanto os problemas de carga de consenso do Ethereum mencionados por Vitalik. Enquanto isso, estão em andamento preparativos para implementar uma arquitetura de validação em camadas semelhante. É difícil conseguir a curto prazo, mas é muito possível a longo prazo.

    • Em comparação com a expansão dos poderes de seleção de delegados, as soluções de integração de terceiros podem resolver em maior medida o problema da centralização de compromissos, mas não podem resolver o problema da carga de consenso. Semelhante à expansão dos poderes de seleção de delegados, existe também o problema dos pequenos incentivos para os participantes existentes adotá-lo. No curto prazo, novos prestadores de serviços de staking podem utilizar esta funcionalidade como forma de entrar no mercado.

4. Conclusão

Nos muitos discursos e artigos de Vitalik, podemos ver uma ideia central: Ethereum deve permanecer neutro e minimalista. Embora muitos recursos (como abstração de contas, serviços de depósito de liquidez, contas de privacidade, etc.) tenham melhorado a competitividade do Ethereum, o Ethereum não optou por integrar diretamente todos os recursos, mas deixa algumas funções para projetos de terceiros. Muitos projetos de terceiros também responderam bem às propostas deixadas pela Ethereum e encontraram seu próprio posicionamento no mercado. No entanto, à medida que o próprio Ethereum continua a evoluir, os problemas e oportunidades enfrentados por projetos de terceiros também estão mudando. Para estes participantes, este não é apenas um teste de adaptabilidade, mas também um momento para pensar profundamente sobre o futuro e antecipar e aproveitar as oportunidades finais.

Na análise deste artigo, tentamos realizar uma dedução abrangente sobre as variáveis ​​que os atuais projetos relacionados a staking track podem enfrentar no futuro com base nas suposições de Vitalik. Embora Vitalik tenha apresentado o possível fim do Ethereum num artigo relacionado, o futuro permanece incerto, uma vez que os planos atuais podem mudar em resposta às novas exigências do mercado e aos avanços tecnológicos. Neste cenário em constante mudança, apenas os jogadores com visão final do jogo e a capacidade de capturar os bônus da janela atual podem permanecer à frente na corrida de longo prazo.

Referências

  • <Mudanças de protocolo e pool de staking que poderiam melhorar a descentralização e reduzir a sobrecarga de consenso>

  • <Ethereum deveria concordar em consagrar mais coisas no protocolo?>

  • <Caminhos em direção à finalidade de slot único>

  • Roteiro Etheream: Finalidade de slot único

  • <Uma visão geral da prova de participação>

  • <Podemos encontrar Cachinhos Dourados? Reflexões sobre piquetagem de “duas camadas”, um design nativo de token de piquetagem líquida.>

  • <Fim do jogo>

  • <Explicador do Beacon Chain Ethereum 2.0 que você precisa ler primeiro>

  • Perguntas frequentes sobre EIP-7251; Aumentando o MAX_EFFECTIVE_BALANCE – HackMD