Nota do editor: Esta tarde, no local principal do evento Devcon em Bangkok, o desenvolvedor do núcleo Ethereum Justin Drake anunciou a proposta de mudança de camada de consenso "mais ambiciosa" do Ethereum nos últimos anos - Beam Chain, que introduz uma série de tecnologias ZK para substituir a "velha" Ethereum Beacon Chain. Na reunião, Justin disse que o desenvolvimento da nova camada de consenso pode continuar até 2030. No entanto, o mercado não parecia comprá-lo e, enquanto a coletiva de imprensa estava acontecendo, o preço do Ethereum caiu drasticamente. Todo mundo parece estar pensando: a fundação tem outra desculpa para vender moedas?

A seguir está o texto completo do discurso:

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

Fonte da imagem: Uncommons Dasong

Antes de eu compartilhar mais, dois avisos: Primeiro, esta é uma proposta, apenas minha, e só avançará com consenso. Segundo, não há novo token, não há nova rede, continuaremos a usar o mesmo ticker, Vitalik foi muito claro sobre isso.

Na seguinte palestra, vou tentar explicar uma ideia aparentemente louca em uma proposta razoável - ou seja, redesenhar completamente a camada de consenso.

Primeiramente, gostaria de falar sobre a grande visão do framework Beam Chain. O escopo do 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 aplicativos e precisam manter compatibilidade futura, então as oportunidades de alterar essas duas camadas são relativamente limitadas. A camada de consenso não é consumida diretamente por aplicativos, o que nos permite ter mais espaço para ajustes a esse respeito.

Por que Beam Chain?

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

O motivo principal é que a Beacon Chain já está um pouco “antiga”.

"Especificações" foram congeladas há cinco anos, e muita coisa mudou nesses cinco anos, especialmente porque 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.

Segundo, do ponto de vista de engenharia, agora temos uma tecnologia muito poderosa chamada SNARKs. Nos últimos cinco anos, houve inúmeras descobertas na tecnologia SNARKs, aumentando as velocidades em ordens de magnitude. Ao mesmo tempo, também vimos o surgimento de zkVMs, uma tecnologia incrível que permite a qualquer programador no mundo aproveitar essa tecnologia poderosa sem precisar conhecer 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 uma 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.

Quais mudanças o Beam Chain inclui?

Em seguida, vou tomar um momento para descrever o que exatamente 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 nível do construtor de blocos e do relayer. 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 de proponente-construtor (PBS) e inclui ideias como funções de execução.

O último item na categoria de produção de blocos são slots de tempo mais rápidos, talvez possamos reduzir ainda mais os slots de tempo mantendo os atuais slots de tempo de 12 segundos inalterados e garantir que, mesmo em uma conexão de rede doméstica, mesmo que a latência da rede seja alta na Austrália, os usuários ainda possam participar como validadores e desfrutar de direitos de primeira classe.

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

Recentemente, houve 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 é a criptografia, que contém dois projetos importantes. O primeiro projeto é a verificação SNARK de toda a camada de consenso em tempo real, com suporte de hardware razoável.

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

Aqui eu uso cores diferentes para diferenciar se os itens no roteiro podem ser concluídos facilmente ou gradualmente, ou se eles 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 os melhores através de uma abordagem mais holística.

Tomando a 'Notificação de Mudança' como exemplo, para alcançar a prova em tempo real da Beacon Chain em hardware razoável, precisamos alterar 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 na Beacon Chain, então talvez haja uma oportunidade para fazermos esses ajustes juntamente com outras melhorias.

Uma situação semelhante se aplica 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 designs que podem manter a segurança de que precisamos, ao mesmo tempo em que melhoram o desempenho e aproveitam algumas melhorias de desempenho fáceis de alcançar.

Este PPT mostra o mapeamento da camada de consenso da estrada que acabei de mencionar para a estrada mais ampla de Vitalik. Alguns de nossos projetos estão na fase de Merge, alguns estão na fase de Scourge e alguns estão nas fases de Verge e Scourge.

O objetivo principal deste PPT é transmitir que a Beam Chain não está mudando 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 ser capaz de acelerar esses projetos importantes, também podemos limpar parte da dívida técnica mencionada anteriormente. Se implementarmos a finalidade de fonte única, os epochs não serão mais necessários e os slots podem ser usados diretamente. Além disso, o contrato de depósito atual é um pouco complexo e é um legado da fusão; a infraestrutura como o comitê de sincronização não será mais necessária após a SNARKing em tempo real da Beacon Chain ser alcançada. Esta é uma oportunidade para limpar tudo de uma vez.

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

Esta imagem mostra o quadro completo das nossas atualizações para a camada de consenso desde a sua criação. Como pode ser visto no canto inferior esquerdo, a criação 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 máximo efetivo.

Esperamos continuar fazendo 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, encontraremos um gargalo. Uma vez concluídos todos os projetos de baixa dificuldade, os demais são projetos importantes que são gradualmente difíceis de implementar. Neste momento, é necessário o "Fork Beam". O Fork Beam oferece uma oportunidade para dar um grande salto à frente na camada de consenso por meio de uma atualização única. Pense no Fork Beam como uma oportunidade de agrupamento, onde várias atualizações são mescladas em um único fork, com benefícios técnicos e de governança.

Esta oportunidade de processamento em lote pode ser chamada de "aceleração solidificada". Isso parece um oxímoro, mas a ideia básica é querer que o Ethereum entre no modo de manutenção o mais rápido possível, e há uma tensão nesse sentido no momento. Sabemos que existem alguns projetos importantes que requerem uma reestruturação fundamental do Ethereum e, quanto mais essas mudanças forem adiadas, mais tempo levará para que o Ethereum atinja um estado estável.

Quais tecnologias o Beam Chain utiliza?

Em seguida, vem a parte dois, onde eu apresento 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 do Proof of Work (POW), depois avançando para a era do Proof of Stake (POS), e agora podemos estar entrando em uma era de Zero Knowledge Proof (ZK).

Na era ZK, faremos amplo uso da tecnologia SNARKs. Um local 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 Beam Chain em diferentes linguagens de programação de alto nível, como Rust e Go, e então compilar essas linguagens de alto nível em bytecode que 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 bloco) não requer verificação SNARK.

O RISC-V tornou-se o padrão da indústria para essas zkVMs nos últimos anos. RISC-V é um conjunto de instruções que basicamente compila código de alto nível em instruções RISC-V. Existem agora sete empresas que oferecem ZKVMs RISC-V, como RISC Zero e SP1, das quais você já deve ter ouvido falar.

É importante notar que essa tecnologia poderosa também pode ser usada na camada de execução, o que é uma história diferente da Beam Chain, mas é muito empolgante 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 lugar onde SNARKs são amplamente usados na Beam Chain é em assinaturas agregáveis. Gostaríamos de ter assinaturas agregáveis resistentes a quantum, e a proposta aqui é usar funções hash. Funções hash são resistentes a quantum e podem ser usadas como um 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 comprimir milhares de assinaturas em uma única prova. Ao combinar os dois, podemos construir uma solução baseada em hash, agregável e resistente a ataques quânticos que pode ser usada no Ethereum. Um detalhe interessante é que esse esquema de agregação tem a capacidade de agregação recursiva infinita, o que significa que os resultados da agregação podem ser continuamente re-agregados, o que atualmente não é possível com assinaturas BLS e é mais flexível.

A razão pela qual estou propondo isso hoje é que houve grandes melhorias no desempenho da função hash SNARK nos últimos meses. Para aqueles que sabem, agora conseguimos verificar isso em um laptop.

Este benchmark foi concluído em um MacBook Pro CPU 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. potencial.

Além do zkVM e SNARKs que estaremos usando, também quero enfatizar que estaremos reutilizando a infraestrutura existente em grande parte.

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

Além disso, infraestruturas como o Protocolo Guild podem também ser reutilizadas. Estas não existiam nos primeiros dias da Beacon Chain, mas agora podem ser reutilizadas gratuitamente.

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

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

Na parte final, quero falar sobre os próximos passos e perspectivas futuras. Uma possível consequência é que, a partir de 2025, entraremos em um processo de normalização. Isso será realizado por uma pequena equipe de pesquisadores e pode levar o ano inteiro. Em 2026, o processo de desenvolvimento será iniciado com equipes de clientes escrevendo código de produção de alta qualidade, seguido por um processo de teste muito rigoroso em 2027 para garantir a segurança e estabilidade das implantações de produção.

Fonte da imagem: Uncommons Dasong

Minha próxima tarefa como pesquisador é começar a escrever uma especificação executável, a qual eu chamo de 'roadmap executável'. A ideia é combinar os 'pixels' do roadmap, as centenas de milhares de palavras em vários artigos de pesquisa e acadêmicos, e as várias ideias nas mentes dos pesquisadores, extrair sua essência principal 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 clientes de consenso está espalhada pela América do Norte, Europa e Oceania. Hoje, tenho o prazer de anunciar que uma nova equipe se dispôs a desenvolver o cliente Beam. Uma das equipes está baseada na Índia, chamada Zine, e eles estão escrevendo um cliente Beam usando a linguagem Zig. Há também uma equipe da Lambda Class baseada na América do Sul que também manifestou interesse em desenvolver um cliente Beam.

Se você também estiver interessado em participar, precisamos de muitas pessoas talentosas, incluindo especialistas em especificações e redes, coordenadores, especialistas em criptografia e desenvolvedores de clientes. Por favor, entre em contato conosco através deste email para se juntar a nós e começar esta 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 essa reimpressão, entre em contato com o Gate Learnequipe e eles cuidarão disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe de aprendizado da gate. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.