Nota do editor: Esta tarde, no local principal do evento Devcon em Bangkok, o desenvolvedor principal do Ethereum, Justin Drake, anunciou a proposta de mudança da camada de consenso "mais ambiciosa" do Ethereum nos últimos anos - Beam Chain, que introduz uma série de tecnologias ZK para substituir a "antiga" Beacon Chain do Ethereum. Na reunião, Justin disse que o desenvolvimento da nova camada de consenso pode continuar até 2030. No entanto, o mercado parece não acreditar nisso, e enquanto a conferência de imprensa acontecia, o preço do Ethereum caiu bruscamente. Todos parecem estar pensando: A fundação tem outra desculpa para vender moedas?

O seguinte é o texto completo do discurso:

O projeto em que investi muito tempo este ano é chamado de “Beam Chain”. Beam Chain é uma reformulação da camada de consenso que incorpora as ideias mais recentes e avançadas do mapa de pesquisa. O objetivo é fazer a transição da atual Beacon Chain para este projeto de forma segura e rápida, o que estará mais próximo da forma final do Ethereum.

Fonte da imagem: Uncommons Dasong

Antes de partilhar mais, duas advertências: Primeiro, isto é uma proposta, apenas minha, e só avançará com consenso. Segundo, não há um novo token, nem uma nova rede, continuaremos a utilizar o mesmo ticker, Vitalik foi muito claro sobre isto.

Na seguinte conversa, tentarei explicar uma ideia aparentemente louca num proposta razoável - nomeadamente redesenhar completamente a camada de consenso.

Em primeiro lugar, gostaria de falar sobre a grande visão estrutural da Beam Chain. O escopo da Beam Chain concentra-se na camada de consenso e não inclui blobs na camada de dados e EVM na camada de execução, porque blobs e EVM são usados diretamente por aplicações e precisam manter compatibilidade futura, portanto as oportunidades de mudança dessas duas camadas são relativamente limitadas. A camada de consenso não é diretamente consumida por aplicações, o que nos permite ter mais espaço para ajustes a esse respeito.

Por que Beam Chain?

Então, por que estou propondo essa grande refatoração da camada de consenso agora?

A principal razão é que a Beacon Chain já está um pouco “antiga”.

As “especificações” foram congeladas há cinco anos, e muita coisa mudou nesses cinco anos, especialmente o fato de que a nossa compreensão de novas perspectivas é muito mais profunda do que era há cinco anos. Éramos relativamente ingênuos quando se tratava de PoW há cinco anos, mas desde então o mercado cresceu rapidamente e temos uma compreensão melhor dos mecanismos que podem ajudar a mitigar as externalidades negativas do MEV.

Em segundo lugar, do ponto de vista da engenharia, agora temos uma tecnologia muito poderosa chamada SNARKs. Nos últimos cinco anos, houve inúmeros avanços na tecnologia SNARKs, aumentando as velocidades em ordens de grandeza. Ao mesmo tempo, também vimos o nascimento de zkVMs, uma tecnologia incrível que permite a qualquer programador no mundo aproveitar essa tecnologia poderosa sem precisar ser versado em criptografia ou ter um profundo entendimento de SNARKs.

Além disso, ao longo do tempo, agora temos uma compreensão clara dos erros que foram cometidos na Beacon Chain e da dívida técnica que se acumulou. Essas dívidas são muito teimosas e crescerão ao longo do tempo.

Agora, talvez tenhamos a oportunidade de limpar essa dívida técnica. Portanto, recomendo integrar as tecnologias mais avançadas do roteiro da camada de consenso na Beam Chain.

Que mudanças inclui o Beam Chain?

Em seguida, vou tirar um momento para descrever exatamente o que está incluído no roteiro da camada de consenso. Existem basicamente nove projetos diferentes, e eu os dividi em três categorias: produção de blocos, staking e criptografia.

Origem: Aaros.183

O primeiro é a produção de blocos, que envolve o MEV. Atualmente, existem muitos problemas de centralização no construtor de blocos e no nível de retransmissão. Esperamos introduzir uma “lista de inclusão” para melhorar significativamente a resistência à censura. Uma vez que a lista de inclusão seja resistente à censura, seremos capazes de separar claramente os validadores do processo de produção de blocos. Isso é chamado de separação proponente-construtor (PBS) e inclui ideias como funções de execução.

O último item na categoria de produção de bloco são intervalos de tempo mais rápidos. Talvez possamos reduzir ainda mais o intervalo de tempo mantendo os atuais 12 segundos inalterados e garantindo que, mesmo com uma conexão de rede doméstica, mesmo que a latência da rede seja alta na Austrália, os usuários possam ainda assim participar como validadores e aproveitar os direitos de primeira classe.

A segunda categoria é a garantia. Os pesquisadores em grande parte chegaram a um consenso de que a curva de emissão atual é falha e que existem oportunidades para ajustes visando melhorar a saúde e o desenvolvimento a longo prazo do Ethereum. O segundo projeto na categoria de garantia é reduzir significativamente o ETH necessário para se tornar um validador de 32 ETH atualmente para apenas 1 ETH.

Recentemente, têm surgido algumas ideias sobre "Orbit". Além disso, outra ideia que tem sido discutida há anos é a finalidade de um único slot, o que poderia acelerar significativamente o processo de finalidade do Ethereum.

A última categoria é criptografia, que contém dois projetos importantes. O primeiro projeto é verificação de SNARK da camada de consenso inteira em tempo real, com suporte de hardware razoável.

Finalmente, podemos tornar a criptografia que garante o Ethereum sustentável e resistente a ataques quânticos por décadas ou até séculos?

Aqui eu uso cores diferentes para diferenciar se os itens na estrada podem ser concluídos facilmente ou gradualmente, ou se são difíceis de alcançar. Os quatro projetos verdes no canto superior esquerdo são projetos que eu acho que podem e devem ser implementados gradualmente na Beacon Chain, e quando esses projetos menores forem concluídos, o que resta são alguns projetos principais (partes vermelhas) que eu acho que são melhores através de uma abordagem mais holística.

Tomando como exemplo a "Notificação de Mudança", para alcançar uma prova em tempo real da Beacon Chain em hardware razoável, precisamos mudar a função de hash, o método de assinatura, e os métodos de serialização de estado e Merkelização. Isso será uma grande mudança para a Beacon Chain, então talvez haja uma oportunidade para fazermos esses ajustes juntamente com outras melhorias.

Uma situação semelhante aplica-se aos “Faster Slots” e “Faster Finality” nas duas caixas vermelhas na parte inferior. Quando projetamos a Beacon Chain há cinco anos, nosso foco era a segurança, não o desempenho. Agora, no entanto, estamos descobrindo que existem projetos que podem manter a segurança de que precisamos, ao mesmo tempo que melhoram o desempenho e aproveitam algumas melhorias de desempenho fáceis de alcançar.

Este PPT mostra a correspondência entre o roteiro da camada de consenso que acabei de mencionar e o roteiro mais amplo do Vitalik. Alguns dos nossos projetos estão na fase de Mesclagem, outros na fase de Flagelo e outros nas fases de Verge e Flagelo.

O objetivo principal desta apresentação é transmitir que a Beam Chain não está alterando todo o roteiro, mas identificando um subconjunto específico dele, acelerando-o e dando-lhe um significado único.

Origem: Aaros.183

Os "intervalos de tempo mais rápidos" no roadmap da camada de consenso são novos, pois as discussões sobre intervalos de tempo mais rápidos começaram em 2024, e o roadmap de Vitalik foi atualizado pela última vez em 2023.

Além de poder acelerar esses projetos importantes, também podemos eliminar algumas das dívidas técnicas mencionadas anteriormente. Se implementarmos a finalidade de uma única fonte, os períodos não serão mais necessários e os slots poderão ser usados diretamente. Além disso, o contrato de depósito atual é um pouco complexo e é um legado da fusão; infraestruturas como o comitê de sincronização não serão mais necessárias após a realização do SNARKing em tempo real da Beacon Chain. Esta é uma oportunidade para limpar de uma vez por todas.

Se estiver interessado em alguns dos problemas de design da Beacon Chain, no ano passado dei uma palestra completa discutindo mais de 20 erros que cometemos ao projetar a Beacon Chain.

Esta imagem mostra a imagem completa das nossas atualizações na camada de consenso desde a sua criação. Como pode ver no canto inferior esquerdo, o Gênesis ocorreu em 2020 e desde então tivemos um novo fork a cada ano, e com cada fork fizemos melhorias incrementais na camada de consenso.

Em 2021 adicionamos um comitê de sincronização, em 2022 fizemos uma fusão, em 2023 adicionamos capacidades de retirada e fragmentação dinâmica nativa, e em 2025 aumentaremos o saldo efetivo máximo.

Espere que continuemos a fazer esses forks incrementais ao longo dos próximos anos, pegando os projetos de baixa dificuldade marcados em verde no canto superior esquerdo do roteiro.

Gradualmente iremos encontrar um gargalo. Uma vez concluídos todos os projetos de baixa dificuldade, o restante são projetos importantes que são difíceis de implementar gradualmente. Neste momento, é necessário um "Beam Fork". O Beam Fork fornece uma oportunidade para dar um grande salto em frente na camada de consenso através de uma atualização única. Pense no Beam Fork como uma oportunidade de agrupamento, onde múltiplas atualizações são fundidas em um único fork, com benefícios técnicos e de governança.

Esta oportunidade de processamento em lote pode ser chamada de 'aceleracionismo sólido'. Isso parece um oxímoro, mas a ideia básica é querer que o Ethereum entre em modo de manutenção o mais rápido possível, e há essa tensão no momento. Sabemos que existem alguns projetos importantes que exigem uma reestruturação fundamental do Ethereum, e quanto mais essas mudanças forem adiadas, mais longe estará o Ethereum de alcançar um estado estável.

Que tecnologias utiliza a Beam Chain?

A seguir está a parte dois, onde eu introduzo algumas das técnicas que serão usadas na Beam Chain. Pense nisso como diferentes eras do mecanismo de consenso do Ethereum: inicialmente a era de Prova de Trabalho (POW), depois passando para a era de Prova de Participação (POS), e agora podemos estar entrando em uma era de Prova de Conhecimento Zero (ZK).

Na era ZK, faremos um uso intensivo da tecnologia SNARKs. Um lugar onde já estamos usando SNARKs é fornecer verificação de conhecimento zero para toda a Beam Chain - toda a camada de consenso - e é aqui que as zkVMs (máquinas virtuais de conhecimento zero) se tornam muito úteis.

Imagine que pudéssemos implementar a Beam Chain em diferentes linguagens de programação de alto nível, como Rust e Go, e depois compilar essas linguagens de alto nível em bytecode que os zkVMs possam entender para alcançar a verificação SNARK sem se preocupar com os detalhes de baixo nível.

Um ponto que precisa ser enfatizado é que a única parte que requer verificação SNARK é a Função de Transição de Estado, que é o núcleo de se tornar um cliente de consenso. Essencialmente, a função de transição de estado é uma parte muito pequena da construção do cliente, e a infraestrutura circundante (como rede, sincronização, otimização de cache ou regras de seleção de blocos) não requer verificação SNARK.

RISC-V tornou-se o padrão da indústria para esses zkVMs ao longo dos últimos anos. RISC-V é um conjunto de instruções que basicamente compila código de alto nível em instruções RISC-V. Agora existem sete empresas que oferecem RISC-V zkVMs, como RISC Zero e SP1, que você pode ter ouvido falar.

É importante notar que esta tecnologia poderosa também pode ser utilizada na camada de execução, o que é uma história diferente da Beam Chain, mas é muito emocionante porque significa que podemos aumentar significativamente o limite de gás e melhorar o Ethereum como escalabilidade vertical L1, mas isso é outro tópico.

Outro local onde os SNARKs são amplamente utilizados na Beam Chain é em assinaturas agregáveis. Gostaríamos de ter assinaturas agregáveis resistentes a quântica, e a proposta aqui é usar funções de hash. As funções de hash são resistentes a quântica e podem ser usadas como módulo básico para construir criptografia.

Usaremos assinaturas baseadas em hash, geradas por verificadores e provadores, e também introduziremos SNARKs baseados em hash que podem compactar milhares de assinaturas em uma única prova. Ao combinar os dois, podemos construir uma solução baseada em hash agregável e resistente ao quântico que pode ser usada no Ethereum. Um detalhe interessante é que este esquema de agregação tem a capacidade de agregação recursiva infinita, o que significa que os resultados da agregação podem ser continuamente reagregados, o que atualmente não é possível com assinaturas BLS e é mais flexível.

A razão pela qual estou a propor isto hoje é que tem havido grandes melhorias no desempenho da função hash SNARK nos últimos meses. Para quem está a par, agora conseguimos verificar isto num portátil.

Este benchmark foi concluído numa CPU MacBook Pro e agora pode verificar 2 milhões de hashes por segundo. Esta é uma velocidade incrível, o que significa que esta proposta baseada em hash tem um ótimo desempenho na Beam Chain.

Além do zkVM e SNARKs que iremos utilizar, também quero enfatizar que iremos reutilizar a infraestrutura existente em grande medida.

Por exemplo, a biblioteca de rede libp2p, a biblioteca de serialização Simple Serialize, etc. podem ser reutilizadas diretamente. O mesmo acontece com o framework Pyspec, o framework de especificação Python que usamos para escrever especificações formais e testes unitários.

Além disso, a infraestrutura, como o Protocol Guild, também pode ser reutilizada. Estes não existiam nos primeiros dias da Beacon Chain, mas agora podem ser reutilizados gratuitamente.

Da mesma forma, agora existem várias equipas a apoiar o desenvolvimento da Beacon Chain. Naquela altura, não tínhamos uma equipa cliente de consenso. As atuais cinco equipas cliente de consenso podem ser usadas diretamente, sem necessidade de reorganização.

Além disso, temos equipas dedicadas responsáveis pelas operações combinadas, como o suporte DevOps fornecido pela equipa Panda Ops, grupos de pesquisa de aplicativos como a equipa de segurança e a equipa de motivação, estes são todos recursos que podem ser diretamente aproveitados.

Na parte final, quero falar sobre os próximos passos e perspetivas futuras. Um resultado possível é que, a partir de 2025, iremos entrar num processo de normalização. Este será realizado por uma pequena equipa de investigadores e poderá demorar o ano inteiro. Em 2026, o processo de desenvolvimento será iniciado com as equipas de clientes a escreverem código de produção, seguido por um processo de teste muito rigoroso em 2027 para garantir a segurança e estabilidade das implementações de produção.

Fonte da imagem: Uncommons Dasong

A minha próxima tarefa como investigador é começar a escrever uma especificação executável, que eu chamo de "roadmap executável". A ideia é combinar os "pixels" no roadmap, as centenas de milhares de palavras em vários artigos de pesquisa e académicos, e as várias ideias nas mentes dos investigadores, extrair a sua essência central e formar um documento de especificação executável. No final, este será um documento muito compacto, com cerca de 1000 linhas de código Python.

A coisa emocionante para mim é que se houver um consenso geral sobre a nova direção da Beam Chain, esta será uma ótima oportunidade para injetar sangue novo no cliente de consenso.

Atualmente, nossa equipe de consenso está espalhada pela América do Norte, Europa e Oceania. Hoje, estou feliz em anunciar que uma nova equipe está disposta a desenvolver o cliente Beam. Uma das equipes está sediada na Índia, chamada Zine, e eles estão escrevendo um cliente Beam usando a linguagem Zig. Também há uma equipe da Classe Lambda baseada na América do Sul que também manifestou interesse em desenvolver um cliente Beam.

Se você também está interessado em participar, precisamos de muitas pessoas talentosas, incluindo especialistas em especificações e rede, coordenadores, especialistas em criptografia e desenvolvedores de clientes. Por favor, entre em contato conosco via e-mail para se juntar a nós e começar essa nova aventura juntos. Muito obrigado!

Aviso legal：

1. Este artigo é reproduzido a partir de [BlockBeats], Todos os direitos autorais pertencem ao autor original [BlockBeats]. Se houver objeções a esta reimpressão, por favor entre em contato com oGate Learnequipa, e eles vão lidar com isso prontamente.
2. Aviso de Responsabilidade: As opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.