Introdução

Em 2024, muitos eventos significativos ocorreram em torno do Ethereum. No início do ano, o Ethereum introduziu blobs através da atualização Dencun. Esta atualização reduziu drasticamente os custos de transação para rollups existentes, lançando as bases para a rápida expansão dos ecossistemas rollup.

(Redução de taxas nas Cadeias OP após a atualização Dencun | Fonte:Optimism X)

No entanto, à medida que os dapps dentro do ecossistema migraram para rollups altamente escaláveis e redes alternativas de Camada 1 (L1), a atividade do usuário no Ethereum em si começou a declinar. Além disso, à medida que os rollups pararam de enviar taxas altas para o Ethereum, preocupações começaram a surgir dentro da comunidade.

Além disso, 2024 foi um ano em que L1s focados em escalabilidade como Solana e Sui demonstraram uma força significativa. O enorme TPS (transações por segundo) gerado por essas redes fez a atividade nos rollups parecer relativamente pequena.

Neste contexto, surgiram críticas, como “o roadmap centrado em rollup do Ethereum é falho” ou “o desenvolvimento do Ethereum é muito lento para ter sucesso.” O Ethereum está realmente no caminho certo? Como será o Ethereum em 2025 ou mesmo em 2030?

Esta série explora partes do roadmap do Ethereum sob dois tópicos principais, analisando seu futuro com base em detalhes técnicos. O primeiro tópico é a Beam Chain.

O que é a proposta da corrente Beam e por que isso importa?

Se alguém tivesse que escolher o tópico mais comentado dentro da comunidade Ethereum este ano, provavelmente seria o anúncio do pesquisador da Ethereum, Justin Drake, sobre a Corrente de Farol na Devcon. Este anúncio despertou grande interesse e, correspondente, muito barulho. Vamos analisar o que essa proposta significa.

A ideia central da proposta da Beam Chain é redesenhar completamente a camada de consenso do Ethereum. Justin Drake apresentou as seguintes três razões pelas quais a camada de consenso atual, a corrente de farol, precisa ser redesenhada:

• Melhor compreensão do MEV através de experiências passadas
• Avanços rápidos na tecnologia SNARK (por exemplo, o desenvolvimento do zkVM progredindo a uma taxa surpreendente, mais de 10 vezes mais rápido)
• Eliminando a "dívida técnica" presente na Corrente de Farol

Atualmente, o roadmap da camada de consenso do Ethereum inclui os seguintes elementos:

Dentre essas, as quatro áreas marcadas em negrito representam mudanças fundamentais que vão além de simples modificações na Beacon Chain. Por exemplo, snarkificação da cadeia refere-se à conversão do manuseio de estado da camada de consenso para tecnologia ZK, exigindo mudanças fundamentais que vão desde funções hash até os métodos de merkleização/serialização de estado.

Além disso, slots mais rápidos e finalidade mais rápida são novos designs propostos para alcançar melhorias de desempenho, mantendo a segurança - um fator não priorizado nos designs iniciais. Implementar esses requer mudanças extensas na camada de consenso.

A Beam Chain propõe alcançar essas mudanças por meio de um único hard fork. Para resumir:

1. Implementar a roadmap da camada de consenso do Ethereum requer uma reformulação completa da camada de consenso.
2. Com esse objetivo, grandes mudanças no roteiro serão agrupadas em uma hard fork chamada Corrente Beam.
3. Inclui quatro elementos: tempos de bloco mais rápidos, finalidade mais rápida, snarkification da cadeia e resistência quântica.

Em seguida, vamos explorar como cada um deles é implementado e os impactos técnicos que eles acarretam.

Detalhes técnicos do design da corrente Beam

Slots mais rápidos e finalidade mais rápida

Atualmente, o tempo de slot do Ethereum é de 12 segundos e leva de 2 a 3 épocas (aproximadamente 15 minutos) para que um bloco conectado a um slot atinja a finalidade. Melhorar esses tempos teria um impacto positivo nos usuários do Ethereum, aplicativos e rollups construídos no Ethereum.

Finalidade mais curta (Orbit SSF)

Esse tópico, conhecido entre os pesquisadores da Ethereum como SSF (Single Slot Finality), tem como objetivo reduzir o tempo para que os blocos da Ethereum alcancem a finalidade de cerca de 15 minutos para até 12 segundos, proporcionando aos usuários uma confirmação mais rápida. Para entender a finalidade de um único slot, devemos compreender o algoritmo de consenso atual da Ethereum, Gasper.

Um princípio de design chave do Gasper é garantir que um bloco proposto em um slot alcance um certo nível de segurança econômica após um tempo determinado, ao mesmo tempo em que minimiza a carga de comunicação em cada validador. Para conseguir isso, o Ethereum divide todo o conjunto de validadores em comitês distribuídos em 32 slots. Cada slot pode conter até 64 comitês, e o objetivo é compor cada comitê com 128 validadores (embora esse número possa aumentar se o número total de validadores ativos exceder isso).

Validadores dentro de cada comitê verificam independentemente o bloco e votam nele usando assinaturas BLS. O mecanismo de assinatura BLS permite que várias assinaturas sejam agregadas em uma, o que significa que um nó designado dentro do comitê coleta essas assinaturas e as compila em um único pacote de dados compacto. Ao transmitir esta assinatura agregada, o próximo proponente de bloco pode confirmar com dados mínimos que o bloco foi devidamente verificado.

(Agregação de assinatura BLS entre os validadores do Ethereum | Fonte: eth2book)

Em resumo, o Gasper do Ethereum alcança escalabilidade e segurança econômica por meio dos seguintes mecanismos:

• Os validadores são distribuídos em slots em comitês ao longo de um período de 6,4 minutos, eliminando a necessidade de comunicação direta entre todos os validadores.
• O processo de assinatura agregada garante que os votos dos validadores no bloco possam ser verificados usando uma pequena quantidade de dados.

No entanto, surge um problema porque o Gasper opera com base em épocas, e a "conectividade" entre épocas deve ser verificada antes que um slot possa atingir a finalidade. No Gasper, um mínimo de duas épocas (64 slots) deve passar antes de alcançar a finalidade equivalente à segurança econômica completa do Ethereum.

Isso resulta na seguinte representação diagramática:

(Finalidade Econômica em Gasper | Fonte:Orbit SSF)

Isso apresenta vários desafios e diminui a experiência do usuário. Por exemplo:

• Ao sacar fundos de uma CEX (exchange centralizada) para Ethereum, ou vice-versa, o período de confirmação pode ser de cerca de 10 minutos, o que é relativamente excessivo.
• Os rollups do Ethereum e as dApps correm o risco de que os blocos L1 em que eles dependem possam não ser finalizados e sejam invalidados. Se contramedidas adequadas não forem implementadas, isso pode causar problemas.

Por exemplo, em março de 2024, o Polygon zkEVM experimentou uma parada de corrente que durou mais de dois dias devido ao manuseio inadequado da reorganização do Ethereum.

Reduzir o tempo de finalização não é impossível, como demonstrado por algoritmos de consenso como Tendermint, que já são aplicados em vários protocolos. No entanto, o desafio ao adotar o mecanismo do Tendermint reside na comunicação P2P frequente entre os nós, que introduz limitações de escalabilidade.

No Tendermint, se o número de nós for N, sua complexidade de mensagem é O(N^3). Isso significa que à medida que o número de nós aumenta, a frequência de comunicação entre eles cresce exponencialmente, restringindo a escalabilidade. Assim, protocolos como o Ethereum, com muitos validadores, não podem adotar diretamente o Tendermint como está.

É necessário realizar trabalho adicional para resolver esses problemas e aplicar o consenso no estilo Tendermint ao Ethereum.

Uma visão geral da proposta Orbit SSF

Orbit SSF tem como objetivo modificar o mecanismo de comitê do Gasper para reduzir o tempo de finalidade do slot, mantendo alta segurança econômica.

A proposta é reduzir o tamanho do época de 32 slots para um único slot (~12 segundos). No entanto, como mencionado anteriormente, isso aumentaria o uso de recursos para a comunicação do validador, prejudicando negativamente a descentralização do Ethereum.

Para resolver isso, a Orbit SSF propõe as seguintes ideias:

Aumentar o valor máximo de aposta para cada validador Ethereum pode alcançar o mesmo nível de segurança econômica com menos validadores.

Em vez de ter várias comissões por slot, a Orbit SSF sugere a introdução de um único 'super comitê'. Validadores com quantidades maiores de aposta quase sempre seriam incluídos proporcionalmente no comitê, garantindo que o mesmo nível de segurança econômica seja mantido mesmo com menos comitês.

A próxima atualização do Ethereum, Pectra, inclui o EIP-7251, que propõe aumentar o valor máximo de aposta (MaxEB) para validadores de 32 ETH para 2048 ETH. Embora essa proposta seja atraente para os operadores de infraestrutura de nós do Ethereum, ela também é um pré-requisito para o Orbit SSF.

No entanto, se validadores com grandes quantidades de apostas forem quase sempre incluídos em comitês, validadores solos menores podem ter suas recompensas reduzidas, prejudicando potencialmente a descentralização do Ethereum. Para evitar isso, o Orbit SSF ajusta as recompensas para que a APR aumente linearmente com a quantidade de apostas, ao mesmo tempo em que garante que validadores maiores sejam incluídos com mais frequência em comitês.

(Recompensa e Probabilidade de ser incluído no comitê na Orbit SSF | Fonte:Orbit SSF)

Além disso, Orbit SSF se desloca para a "finalidade baseada em comitê". No Gasper, os comitês só podiam contribuir para a finalidade após duas ou mais épocas terem passado, mas o Orbit SSF permite que cada comitê designado por slot contribua para a finalidade em tempo real. Ele visa tornar os comitês contribuintes mais ativos para a finalidade e alcançar escalabilidade mais rápida.

(Finalidade na Orbita SSF usando Cap-and-slow-rotate | Fonte:Orbit SSF)

A chave aqui está na composição dos membros do comitê. A Orbit SSF propõe um mecanismo de “rotação lenta” onde os validadores de grande participação são matematicamente quase fixos dentro dos comitês, enquanto os validadores menores são rotacionados dentro e fora. Isso permite que o valor de F, representando o limiar de segurança econômica, seja definido muito alto, ao mesmo tempo que mantém um overhead de comunicação mínimo entre os validadores e garante que os tempos de finalização permaneçam baixos.

Por exemplo, definir n = 3 e um F significativamente grande permitiria que o Ethereum alcançasse a finalidade em aproximadamente três slots, realizando assim a visão de Justin Drake de um FFG de 3 slots.

No entanto, elevar F ao nível do conjunto completo de validadores do Ethereum não é fácil. Isso poderia reduzir o custo de realizar um ataque de 51% no Ethereum. Sendo assim, o desafio principal para a Orbit SSF no futuro é determinar como aumentar tecnicamente F para garantir que a segurança do Ethereum permaneça robusta sem sacrificar muito a descentralização.

Tempo de slot mais curto (slots de 4 segundos)Mesmo que SSF (ou finalidade de 3 slots) seja alcançado, os usuários do Ethereum ainda experimentariam um tempo mínimo de confirmação da transação de 12 segundos. Isso leva a duas principais desvantagens para os usuários:

1. Latência longa em comparação com outras L1s como Solana e Sui
2. Maior vulnerabilidade ao MEV (o MEV diminui à medida que o tempo do bloco diminui, tornando os usuários do Ethereum mais suscetíveis ao MEV)

Além disso, um tempo de bloco de 12 segundos é particularmente desfavorável para rollups, especialmente rollups baseados. Por exemplo, Taiko implementa um rollup baseado postando cada bloco L2 em L1. Como resultado, o tempo de bloco do Taiko pode aumentar para um mínimo de 12 segundos e às vezes exceder 24 segundos.

Duas soluções foram propostas para resolver isso:

a. Reduzir o tempo de bloco do Ethereum para 4 ou 8 segundos

b. Use preconfirmations

Reduzindo o tempo de bloco do Ethereum

Reduzir o tempo de bloco do Ethereum é um tópico de discussão ativa. Foi formalizado como EIP-7782, que propõe reduzir o tempo do slot de 12 segundos para 8 segundos, aumentando assim a escalabilidade do Ethereum em 33%. No entanto, um tempo de slot de 8 segundos pode não ser ótimo para a experiência do usuário ou para rollups baseados. Alcançar um tempo de slot mais curto parece mais desejável.

Dito isso, tempos de bloco mais curtos podem levar a um aumento da centralização do conjunto de validadores. Devido a restrições físicas, validadores geograficamente distantes enfrentam tempos de comunicação mais longos, e um tempo de slot de 4 segundos poderia tornar a comunicação inviável em certos cenários.

As estatísticas de tempo de propagação de blocos da mainnet do Ethereum fornecem insights sobre a viabilidade de um tempo de bloco de 4 segundos. O gráfico abaixo mostra a distribuição dos tempos de propagação de bloco.

(CDF de tempos de chegada de mensagens | Fonte:Latência de Propagação de Mensagem do Gossipsub)

Aproximadamente 98% dos blocos são propagados dentro de 4 segundos, enquanto cerca de 2% levam mais tempo. Com base nestes dados, um tempo de bloco de 4 segundos pode parecer viável. No entanto, o tempo de bloco abrange mais do que apenas comunicação - inclui execução e votação. Levando em consideração esses fatores, apenas cerca de 2 segundos de um tempo de bloco de 4 segundos estariam disponíveis para comunicação. Nessas condições, alcançar um tempo de bloco de 4 segundos é desafiador.

Para resolver isso, o tamanho dos dados transmitidos deve ser reduzido, o desempenho dos componentes P2P nos clientes deve ser maximizado ou a comunicação física deve se tornar mais eficiente.

Usando pré-confirmações

Enquanto isso, as pré-confirmações podem melhorar a experiência do usuário. As pré-confirmações permitem que as entidades produtoras de blocos prometam aos usuários: 'Sua transação será incluída no próximo bloco', entregando resultados aos usuários mais rapidamente do que o tempo do slot.

A vantagem da pré-confirmação é que os validadores L1 podem utilizá-la sem a necessidade de um fork ou modificações no cliente. Por exemplo, o Commit-Boost é um software que permite aos validadores do Ethereum gerar e propagar pré-confirmações com segurança.

Commit-Boost, como MEV-Boost, é uma sidecar opcional para validadores, permitindo-lhes gerar e propagar “compromissos” com segurança. Dependendo do caso de uso, esses compromissos podem assumir várias formas:

Usando o terceiro tipo de arquitetura de pré-confirmação, a latência percebida para os usuários pode ser significativamente reduzida mesmo com tempos de bloco mais longos. Quando um validador recebe a transação de um usuário, eles podem executá-la e retornar o resultado para o usuário. Como esse resultado é baseado no compromisso do validador e não na criação de bloco, os usuários podem recebê-lo em questão de milissegundos.

No entanto, a eficácia do Commit-Boost depende da adoção pelos validadores. Se apenas alguns validadores o utilizarem, o impacto na UX será mínimo. Dito isso, o Commit-Boost tem recebido forte apoio da comunidade Ethereum e tem o potencial de se tornar um middleware generalizado, assim como o MEV-Boost. Ele recebeu o apoio de operadores de validadores conhecidos, como Rocket Pool, Renzo, SSV, Luganodes, Nethermind, Puffer, A41 e Figment. Além disso, recebeu subsídios da EF, Lido e Eigenlayer e conta com o forte apoio do construtor de blocos Titan.

No entanto, como mencionado anteriormente, a pré-confirmação é mais provável de ser usada como um acessório externo off-chain, como o MEV-Boost, em vez de ser integrada diretamente no protocolo.

O papel da Beam Chain em slots mais rápidos

Conforme discutido na apresentação de Justin Drake, o objetivo da Beam Chain é reduzir os tempos de bloco. Assim, a pesquisa e implementação provavelmente se concentrarão na redução do tempo do slot para 4 segundos sem sacrificar a descentralização. Isso pode ser resolvido com a snarkificação completa do Ethereum, que será explicada na última parte deste artigo.

Snarkificação de cadeia e resistência quântica

Justin afirmou em sua apresentação que o objetivo da Beam Chain é snarkificar o cliente de consenso usando a tecnologia ZK. O que isso significa, como pode ser alcançado e por que é necessário?

Cadeia de snarkificação

Atualmente, a corrente de farol Ethereum alcança consenso ao fazer com que os validadores 're-executem' cada bloco para verificar se a raiz de estado resultante está correta. Esse processo de re-execução introduz ineficiências e atua como uma barreira para reduzir os requisitos de hardware para os validadores.

A Beam Chain tem como objetivo substituir este processo de reexecução por “verificação” usando tecnologia ZK. Isso reduziria significativamente os requisitos de hardware para validadores e permitiria que qualquer pessoa executasse um nó Ethereum de qualquer lugar. Para alcançar isso, a Beam Chain e o Ethereum utilizarão ZK SNARKs.

ZK no protocolo Ethereum

ZK SNARKs têm as seguintes duas propriedades:

1. Eles permitem a verificação do fato de que uma determinada computação foi realizada sem precisar executar novamente a computação
2. O tamanho da prova é compacto em comparação aos dados originais

A ideia é aplicar ZK aos cálculos e dados necessários para o consenso no Ethereum, gerando uma prova de que a lógica prescrita foi seguida. Isso significa que os validadores podem alcançar consenso verificando a prova ZK em vez de reexecutar o bloco inteiro e armazenar o estado atualizado. Verificar uma prova ZK é muito mais eficiente em termos de tamanho de dados e escalabilidade do que a reexecução.

Como resultado, os requisitos de hardware para validadores do Ethereum podem ser drasticamente reduzidos. Por exemplo, Vitalik expressou em um artigo do The Verge que o objetivo é permitir que os validadores operem até mesmo em ambientes com recursos limitados, como smartwatches.

O que precisa ser feito?

O primeiro passo é tornar a função de transição de estado em snark. A função de transição do estado geralmente tem a seguinte forma:

f(S,B)=S’

Aqui:

• S: O pré-estado do blockchain
• B: O bloco fornecido
• S': O estado posterior da blockchain após a execução do bloco
• f: A função de transição de estado

Todas as blockchains são baseadas em funções de transição de estado determinísticas, e o Ethereum não é exceção. O Ethereum possui diferentes funções de transição de estado para suas camadas de consenso e execução. A aplicação de Snark a ambas tornaria possível verificar todo o sistema Ethereum usando ZK, possibilitando validadores totalmente leves.

Na Beam Chain, o objetivo é snarkificar a função de transição de estado da camada de consenso. Atualmente, a função de transição de estado dentro da camada de consenso do Ethereum é executada em cada slot e realiza as seguintes ações:

• Atualiza as informações do slot e do cabeçalho do bloco após receber um bloco
• Verifica a assinatura do validador que propôs o bloco
• Valida as transações dentro do bloco
• Processa retiradas, redução, finalização de blocos e outras informações sempre que ocorre uma transição de época

Esta função é executada todas as vezes que um validador recebe um bloco de outro validador. Se esta função for snarkificada, os validadores não precisariam mais executar a função de transição de estado diretamente. Em vez disso, eles poderiam verificar uma prova mostrando que a função foi executada corretamente.

Neste caso, quem gera a prova ZK? Tipicamente, pode-se presumir que o proponente do bloco também é responsável por gerar a prova ZK. No entanto, é importante notar que nem todos os validadores podem gerar provas ZK.

A Beam Chain tem como objetivo alcançar um desempenho em que uma prova ZK possa ser gerada em até 3 segundos em um laptop comum. No entanto, mesmo que esse objetivo seja alcançado, os validadores em dispositivos como smartwatches ou smartphones podem não ter recursos suficientes para gerar provas ZK.

Aqui, a rede pode contar com o altruísmo. Apenas uma prova ZK para a transição de estado da camada de consenso é necessária por bloco, e não necessariamente precisa ser gerada pelo proponente do bloco. Em outras palavras, desde que pelo menos uma entidade na rede gere uma prova ZK para cada bloco, pode-se garantir que os blocos da Beam Chain sejam produzidos corretamente.

Futuro: Snarkificação completa do Ethereum

Esta mudança por si só pode não melhorar significativamente o desempenho do validador. A função de transição de estado da camada de consenso envolve ações relativamente leves em comparação com a função de transição de estado da camada de execução. No entanto, o gargalo principal não está nos recursos necessários para executar a função de transição de estado, mas sim na largura de banda da rede. Os validadores têm dificuldade em alcançar consenso dentro do tempo alocado quando o tamanho dos dados (blocos) que eles trocam aumenta. Esta é uma das razões pelas quais o Ethereum manteve um limite de gás de 30M nos últimos três anos.

Se essa mudança for implementada juntamente com a snarkificação da camada de execução, os validadores só precisariam trocar quantidades muito menores de dados em comparação com blocos inteiros. Isso porque as provas SNARK são significativamente mais compactas do que os dados originais. Validadores totalmente snarkificados do Ethereum trocariam menos dados, reduzindo os requisitos de rede em comparação com o sistema atual.

Em resumo, as seguintes são as vantagens da completa snarkificação do Ethereum para validadores.

1. Os validadores só precisam verificar as provas, não reexecutar cálculos, reduzindo as demandas computacionais
2. Validadores trocam dados de prova em vez de dados completos do bloco, reduzindo os requisitos de largura de banda da rede

Como resultado, o ecossistema do Ethereum poderia mudar drasticamente. Por exemplo:

• Coisas como "Aplicativos de Nó Ethereum" poderiam permitir que validadores operem em dispositivos móveis.
• Qualquer pessoa que atenda aos requisitos mínimos de participação poderia executar um nó Ethereum, reduzindo significativamente a barreira para se tornar um validador.

Isso tornaria a participação dos validadores muito mais acessível e descentralizada.

Assinaturas resistentes a quantum

Apenas snarkificar a função de transição de estado é suficiente para a Beam Chain como uma camada de consenso?

Quais problemas o Ethereum enfrentará em um mundo pós-quântico?

Há outra área que a Beam Chain visa snarkificar: geração de assinatura. A camada de consenso do Ethereum atualmente usa assinaturas de validadores como dados de atestação para finalizar blocos e determinar a cadeia correta em caso de bifurcações.

Atualmente, o Ethereum utiliza assinaturas BLS para esse fim, que, como explicado anteriormente, têm a propriedade de agregação, permitindo que várias assinaturas sejam combinadas em uma única. Essa agregação melhora significativamente a eficiência do processo de consenso do Ethereum. No entanto, esse mecanismo de assinatura possui um problema fundamental: ele é vulnerável a computadores quânticos.

As assinaturas BLS usadas na Beacon Chain do Ethereum são baseadas em curvas elípticas. A segurança dos mecanismos de assinatura baseados em curvas elípticas depende do Problema do Logaritmo Discreto (DLP), que o poder computacional superior dos computadores quânticos poderia comprometer. Isso torna as assinaturas baseadas em curvas elípticas inerentemente vulneráveis aos computadores quânticos.

A computação quântica tem avançado rapidamente, como evidenciado pelos recentes desenvolvimentos do Google com chips de computação quântica como o Willow. O Google afirma que o Willow pode realizar cálculos em 5 minutos que levariam um supercomputador 10^25 anos. Embora isso ainda não ameace fundamentalmente a segurança das curvas elípticas, avanços contínuos nesse ritmo poderiam colocar os sistemas blockchain em risco dentro de alguns anos.

(Transição para Padrões de Criptografia Pós-Quântica | Fonte: NIST IR 8547)

O Instituto Nacional de Padrões e Tecnologia (NIST) dos EUA já iniciou esforços para padronizar algoritmos de assinatura resistentes a quântica para lidar com o colapso previsto dos sistemas existentes devido aos computadores quânticos.

Ethereum também está levando esse problema a sério. Na Beam Chain, o objetivo é alcançar algoritmos de assinatura resistentes a quantum.

Existem vários tipos de assinaturas resistentes a quantum, mas a apresentação da Corrente Beam de Justin mencionou especificamente algoritmos de assinatura baseados em hash. Ao contrário das curvas elípticas, as assinaturas baseadas em hash não dependem de mecanismos matemáticos, tornando-as significativamente mais difíceis para os computadores quânticos comprometerem. Como resultado, as assinaturas baseadas em hash são consideradas resistentes a quantum, e a Corrente Beam visa adotar tais assinaturas.

Desafios e o papel de ZK

O principal desafio é que as assinaturas baseadas em hash não possuem a propriedade de agregação presente nas assinaturas BLS. O Ethereum depende da agregação de assinaturas durante o consenso para alcançar eficiência. Sem agregação, o Ethereum não seria mais capaz de acomodar um grande conjunto de validadores.

ZK pode ser usado para resolver isso. Envolve alavancar Agregação de Prova, uma tecnologia que combina várias provas ZK em uma única prova. O mecanismo funciona da seguinte forma:

(Diagrama de Agregação de Prova | Fonte: Figment Capital)

1. Os validadores assinam um bloco usando um algoritmo resistente ao quântico.
2. As assinaturas são enviadas para um agregador**ou comissão de agregação.
3. O agregador gera uma prova ZK verificando a correção das assinaturas.
4. Usando técnicas de agregação de provas, o agregador combina novas provas com as existentes à medida que novas assinaturas são recebidas.

Essa abordagem permite que o Ethereum alcance a mesma eficiência da agregação de assinaturas BLS, ao mesmo tempo em que obtém resistência quântica no nível de consenso.

Papéis de ZK na Corrente Beam

Em resumo, a corrente Beam com ZK trará as seguintes vantagens:

1. Permitir que os validadores realizem a verificação de prova em vez de reexecução para a função de transição de estado da camada de consenso contribuindo para os requisitos de validação leves.
2. Servindo como base para um algoritmo de agregação para assinaturas resistentes a quantum, melhorando a eficiência da camada de consenso.

zkVM como base para ZK na Corrente Beam

O sistema de prova subjacente ao ZK na Beam Chain será zkVM. O zkVM baseado em Risc-V permite a prova de qualquer programa em qualquer linguagem, oferecendo maior flexibilidade.

(Transição de estado do Beam para ser compilada em Risc-V e comprovada em zkVMs | Fonte: Anúncio da Corrente BEAM por Justin Drake)

Isso se alinha bem com o ecossistema de clientes existente do Ethereum, que é desenvolvido em várias linguagens, preservando a diversidade e tolerância a falhas do Ethereum. No futuro da Beam Chain, vários clientes escreverão a função de transição de estado em várias linguagens de programação, compilá-la em Risc-V e permitir que ela seja comprovada em qualquer zkVM baseado em Risc-V. Por esse motivo, zkVM é uma escolha natural para a Beam Chain.

Conclusão

Se a Beam Chain for implementada com sucesso, o Ethereum provavelmente terá as seguintes características:

1. Os usuários experimentarão confirmações de transações em 4 segundos, com finalidade alcançada em 12 segundos.
2. Os validadores verificarão as transições de estado na camada de consenso usando provas ZK. Se a camada de execução também for snarkified, os validadores precisarão apenas de quantidades mínimas de dados para participar do consenso.
3. As assinaturas dos validadores serão resistentes a quântica
4. t, impedindo que os computadores quânticos comprometam o consenso do Ethereum.

Atualmente, a Beam Chain ainda não foi oficialmente reconhecida como parte do roteiro do Ethereum. Sua implementação exigiria extensa pesquisa, desenvolvimento e testes ao longo de um longo período. No entanto, se o Ethereum avançar com o fork da Beam Chain, as melhorias resultantes na UX poderiam ser transformadoras.

Isso conclui nossa exploração de como o Ethereum pode evoluir em cinco anos através da perspectiva da Corrente Beam. No próximo artigo, examinaremos como o Ethereum pode parecer em 2025 a partir de duas perspectivas: UX e resistência à censura.

Apêndice: Perguntas frequentes sobre a corrente de feixe

(P): A proposta de Justin Drake foi discutida em particular. Isso não entra em conflito com o valor central do Ethereum de ser "aberto"?

(A): Não, não faz. A proposta da Beam Chain simplesmente sugere implementar certas partes do roadmap existente do Ethereum de uma só vez. Se será implementado ou não é algo que ainda requer discussão na comunidade. Todos os tópicos discutidos acima já têm EIPs associados ou posts no Ethresear.ch. Isso, mais ou menos, mostra que a Beam Chain não é uma proposta que propõe uma direção nova, previamente não divulgada, para o Ethereum. Além disso, as discussões sobre o roadmap do Ethereum são realizadas publicamente durante a chamada quinzenal All Core Devs, na qual qualquer um pode participar. Se alguém discordar do roadmap ou tiver novas ideias, pode expressar suas opiniões durante essas chamadas ou enviar novas propostas na forma de EIPs ou posts no Ethresear.ch.

Em resumo, a proposta da Corrente Beam de Justin não se trata de mudar o roteiro, mas sim de agrupar partes do roteiro sob um único nome ou meme.

(P): Não são 5 anos muito tempo para implementar a Corrente Beam?

(A): Cinco anos podem parecer um longo tempo, mas dois fatores precisam ser considerados:

1. Ethereum é construído em uma arquitetura multi-cliente.
2. Ethereum possui o maior número de validadores de todas as blockchains.

Diversidade de clientes de consenso | Fonte: Diversidade de Clientes Ethereum)

O mecanismo de consenso do Ethereum segue um protocolo baseado em BFT, onde, se mais de um terço dos validadores agirem de forma diferente dos outros, os blocos não podem ser finalizados. Se o Ethereum fosse construído com apenas um ou dois clientes, qualquer bug nesses clientes poderia interromper a produção de blocos. Portanto, o Ethereum sempre teve como objetivo uma arquitetura de vários clientes desenvolvida em várias linguagens de programação. Essa diversidade é evidente no ecossistema atual de clientes do Ethereum.

Conforme mostrado na imagem, a camada de consenso do Ethereum opera atualmente com pelo menos quatro clientes. Para substituir a Beacon Chain pela Beam Chain, todas as quatro equipes de clientes devem colaborar no desenvolvimento. Considerando isso e o grande conjunto de validadores do Ethereum, o processo de desenvolvimento da Beam Chain deve priorizar a estabilidade e não pode ser acelerado para um prazo de alguns meses ou 1-2 anos.

Aviso legal:

1. Este artigo foi republicado a partir de [2077research]. Todos os direitos autorais pertencem ao autor original [sm-stack]. Se houver objeções a esse reenvio, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. A equipe do Gate Learn faz traduções do artigo para outros idiomas. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.