Introdução

Em 2024, ocorreram muitos eventos significativos em torno do Ethereum. No início do ano, o Ethereum introduziu blobs através da atualização Dencun. Essa atualização reduziu drasticamente os custos de transação para rollups existentes, lançando as bases para a expansão rápida dos ecossistemas de 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 próprio Ethereum começou a diminuir. Além disso, à medida que os rollups deixaram de pagar altas taxas ao Ethereum, preocupações começaram a surgir dentro da comunidade.

Além disso, 2024 foi um ano em que L1s focados na 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 roteiro centrado em rollup do Ethereum está 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 mergulha em partes do roadmap do Ethereum sob dois tópicos principais, analisando seu futuro com base em detalhes técnicos. O primeiro tópico é a cadeia Beam.

Qual é a proposta do Beam Chain 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 feito por Justin Drake, pesquisador do Ethereum, sobre a Cadeia Beam na Devcon. Esse anúncio atraiu muita atenção e, consequentemente, gerou muito barulho. Vamos analisar o que essa proposta significa.

A ideia central da proposta 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 cadeia beacon, precisa ser redesenhada:

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

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

Dentre estes, as quatro áreas marcadas a negrito representam mudanças fundamentais que vão além de simples modificações na cadeia beacon. Por exemplo, a snarkificação da cadeia refere-se à conversão do manuseio de estado da camada de consenso para a tecnologia ZK, exigindo mudanças fundamentais que vão desde funções de 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, ao mesmo tempo em que mantêm a segurança - um fator não priorizado nos designs iniciais. Implementar isso requer mudanças extensas na camada de consenso.

A Beam Chain propõe alcançar essas mudanças por meio de uma única bifurcação rígida. Para resumir:

1. Implementar o roteiro para a camada de consenso do Ethereum requer uma remodelação completa da camada de consenso.
2. Para este fim, grandes mudanças no roteiro serão agrupadas em um hard fork chamado Beam Chain.
3. Inclui quatro elementos: tempos de bloco mais rápidos, finalização 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 implicam.

Detalhes técnicos do design da cadeia Beam

Slots mais rápidos & 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 alcance a finalidade. Melhorar esses tempos teria um impacto positivo nos usuários, aplicativos e rollups do Ethereum.

Finalidade mais curta (Orbit SSF)

Este tópico, conhecido entre os investigadores do Ethereum como SSF (Single Slot Finality), tem como objetivo reduzir o tempo para que os blocos do Ethereum atinjam a finalidade de cerca de 15 minutos para 12 segundos, proporcionando aos utilizadores uma confirmação mais rápida. Para compreender a finalidade de um único slot, devemos compreender o algoritmo de consenso atual do Ethereum, Gasper.

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

Os validadores 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, ou seja, um nó designado dentro do comitê coleta essas assinaturas e as compila em um único pacote de dados compacto. Ao transmitir essa 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 da Ethereum alcança escalabilidade e segurança econômica através 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 numa base de época e a “conectividade” entre as épocas deve ser verificada antes de um slot atingir a finalidade. No Gasper, é necessário um mínimo de duas épocas (64 slots) para alcançar a finalidade equivalente à segurança econômica completa do Ethereum.

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

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

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

• Ao retirar fundos de uma CEX (centralized exchange) 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 os dApps enfrentam o risco de que os blocos L1 em que se baseiam podem não ser finalizados e podem se tornar inválidos. Se não forem implementadas medidas adequadas de contramedidas, isso pode causar problemas.

Por exemplo, em março de 2024, o zkEVM da Polygon experimentou uma interrupção da cadeia durando mais de dois dias devido a um tratamento 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 de adotar o mecanismo do Tendermint reside na frequente comunicação P2P entre os nós, o 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 abordar 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 do comité do Gasper para reduzir o tempo de finalidade da slot, mantendo ao mesmo tempo uma elevada 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 comunicação do validador, impactando negativamente a descentralização do Ethereum.

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

Aumentar o valor máximo de apostas 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 quantias de aposta mais altas seriam quase sempre 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 montante máximo de participação (MaxEB) para validadores de 32 ETH para 2048 ETH. Embora esta proposta seja atraente para os operadores de infraestrutura de nós Ethereum, também é um requisito prévio para a Orbit SSF.

No entanto, se os validadores com grandes quantidades de participação forem quase sempre incluídos em comissões, os validadores solitários menores podem ter recompensas reduzidas, potencialmente prejudicando a descentralização do Ethereum. Para evitar isso, a Orbit SSF ajusta as recompensas para que a APR aumente linearmente com a quantidade de participação, garantindo ao mesmo tempo que os validadores maiores sejam incluídos com mais frequência nas comissões.

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

Além disso, o Orbit SSF se volta para a "finalidade baseada em comitê". No Gasper, os comitês só poderiam contribuir para a finalidade depois de passadas duas ou mais épocas, mas o Orbit SSF permite que cada comitê designado para um slot contribua para a finalidade em tempo real. O objetivo é tornar os comitês contribuintes mais ativos para a finalidade e alcançar escalabilidade mais rápida.

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

A chave aqui reside na composição dos membros do comitê. A Orbit SSF propõe um mecanismo de "rotação lenta" em que 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 uma sobrecarga mínima de comunicação 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 ao Ethereum alcançar 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 de todo o conjunto de validadores do Ethereum não é fácil. Isso poderia reduzir o custo de realizar um ataque de 51% ao Ethereum. Como tal, o desafio principal para o Orbit SSF no futuro é determinar como aumentar tecnicamente F para garantir que a segurança do Ethereum continue robusta sem sacrificar muita descentralização.

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

1. Latência longa em comparação com outros L1s como Solana e Sui
2. Maior vulnerabilidade a MEV (MEV diminui à medida que o tempo de bloco diminui, tornando os utilizadores de Ethereum mais suscetíveis a MEV)

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

Foram propostas duas soluções para resolver isto:

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

b. Utilize pré-confirmações

Reduzir o tempo de bloco do Ethereum

Reduzir o tempo do 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 ideal para a experiência do usuário ou para rollups baseados. Alcançar um tempo de slot mais curto parece ser mais desejável.

Dito isto, tempos de bloco mais curtos podem levar a uma maior centralização do conjunto de validadores. Devido às restrições físicas, os validadores geograficamente distantes enfrentam tempos de comunicação mais longos e um tempo de slot de 4 segundos pode 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 blocos.

(CDF dos tempos de chegada de mensagens | Fonte:Latência de Propagação de Mensagens 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 leva em conta mais do que apenas a comunicação - inclui a execução e a votação. Considerando estes fatores, apenas cerca de 2 segundos de um tempo de bloco de 4 segundos estariam disponíveis para comunicação. Nestas condições, alcançar um tempo de bloco de 4 segundos é desafiante.

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, pré-confirmações podem melhorar a experiência do usuário. Pré-confirmações permitem que 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 de 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 de forma segura.

O Commit-Boost, tal como o MEV-Boost, é um 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 pelos usuários pode ser significativamente reduzida, mesmo com tempos de bloco mais longos. Quando um validador recebe a transação de um usuário, ele pode executá-la e retornar o resultado para o usuário. Como esse resultado é baseado no compromisso do validador e não na criação do 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 experiência do usuário será mínimo. Dito isto, o Commit-Boost tem recebido um forte apoio da comunidade Ethereum e tem o potencial para se tornar uma middleware generalizada como o MEV-Boost. Recebeu o apoio de operadores de validação bem conhecidos, como Rocket Pool, Renzo, SSV, Luganodes, Nethermind, Puffer, A41 e Figment. Além disso, obteve subsídios da EF, Lido e Eigenlayer e conta com um forte apoio da Titan, construtora de blocos.

No entanto, como mencionado anteriormente, a pré-confirmação é mais provável de ser usada como um sidecar 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 do Beam Chain é reduzir os tempos de bloco. Assim, a pesquisa e implementação provavelmente se concentrarão na redução do tempo de slot para 4 segundos sem sacrificar a descentralização. Isso pode ser resolvido com a snarkificação total 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 é tornar o cliente de consenso mais seguro usando a tecnologia ZK. O que isso significa, como pode ser alcançado e por que é necessário?

Snarkificação da cadeia

Atualmente, a cadeia beacon do Ethereum alcança consenso ao fazer com que os validadores 're-executem' cada bloco para verificar se a raiz do estado resultante está correta. Esse processo de reexecuçã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 esse processo de reexecução por "verificação" usando a 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 executada sem a necessidade de reexecutar a computação
2. O tamanho da prova é compacto em comparação com os 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 todo o bloco 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 os validadores Ethereum podem ser dramaticamente reduzidos. Por exemplo, Vitalik expressou num artigo The Verge que o objetivo é permitir que os validadores operem mesmo em ambientes com recursos limitados, como smartwatches.

O que precisa de ser feito?

O primeiro passo é tornar o snarkificação da função de transição de estado. A função de transição de estado geralmente assume a seguinte forma:

f(S,B)=S’

Aqui:

• S: O pré-estado da 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 tem diferentes funções de transição de estado para suas camadas de consenso e execução. Tornar ambos esses processos à prova de conhecimento de zero tornaria possível verificar todo o sistema Ethereum usando ZK, permitindo assim validadores totalmente leves.

Na Beam Chain, o objetivo é tornar a função de transição de estado da camada de consenso mais snarkify. 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 saques, penalizações, finalização de blocos e outras informações sempre que ocorre uma transição de época

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

Neste caso, quem gera a prova ZK? Normalmente, pode-se supor 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 3 segundos num portátil padrão. No entanto, mesmo que esse objetivo seja atingido, 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 sozinha 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 na largura de banda da rede. Os validadores lutam para alcançar consenso dentro do tempo alocado quando o tamanho dos dados (blocos) que trocam aumenta. Esta é uma das razões pelas quais 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 ocorre 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 snarkificação completa da Ethereum para os validadores.

1. Os validadores apenas precisam verificar provas, não reexecutar cálculos, reduzindo as exigências computacionais
2. Os 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 cumpra os requisitos mínimos de stake pode executar um nó Ethereum, diminuindo significativamente a barreira para se tornar um validador.

Isso tornaria a participação do validador muito mais acessível e descentralizada.

Assinaturas resistentes a ataques quânticos

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

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

Há outra área que Beam Chain visa snarkificar: geração de assinaturas. 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 forks.

Atualmente, o Ethereum utiliza assinaturas BLS para esse fim, que, como explicado anteriormente, possuem 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 tem 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 intrinsecamente vulneráveis aos computadores quânticos.

A computação quântica tem avançado rapidamente, como evidenciado pelos recentes desenvolvimentos da Google com chips de computação quântica, como o Willow. A 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, os avanços contínuos nesse ritmo podem colocar os sistemas de 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.

A 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 quântica, mas a apresentação da Beam Chain do 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 de serem comprometidas por computadores quânticos. Como resultado, as assinaturas baseadas em hash são consideradas resistentes a quântica, e a Beam Chain tem como objetivo adotar tais assinaturas.

Desafios e o papel do 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 a agregação, o Ethereum não seria mais capaz de acomodar um grande conjunto de validadores.

ZK pode ser usado para lidar com isso. Ele envolve aproveitar a Agregação de Provas, uma tecnologia que combina várias provas de ZK em uma única prova. O mecanismo funciona da seguinte forma:

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

1. Os validadores assinam um bloco usando um algoritmo resistente a quântica.
2. As assinaturas são enviadas para um agregador**ou Comité 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.

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

Papéis do ZK na Cadeia Beam

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

1. Permitindo 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 leves do validador.
2. Servindo como base para um algoritmo de agregação para assinaturas resistentes a quântica, melhorando a eficiência da camada de consenso.

zkVM como a base para ZK na cadeia de feixe

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

(A transição de estado do Beam deve ser compilada em Risc-V e comprovada em zkVMs | Fonte: Anúncio da Cadeia 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 cadeia Beam, vários clientes escreverão a função de transição de estado em várias linguagens de programação, compilando-a para Risc-V e permitindo que ela seja comprovada em qualquer zkVM baseado em Risc-V. Por esse motivo, zkVM é uma escolha natural para a Cadeia Beam.

Conclusão

Se a Beam Chain for implementada com sucesso, é provável que a Ethereum tenha as seguintes funcionalidades:

1. Os utilizadores irão experienciar confirmações de transações em 4 segundos, com finalidade alcançada em 12 segundos.
2. Os validadores irão verificar as transições de estado na camada de consenso usando provas de conhecimento zero. Se a camada de execução também for snarkificada, os validadores só precisarão 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 computadores quânticos comprometam o consenso do Ethereum.

Atualmente, a Beam Chain 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 prosseguir com o fork da Beam Chain, as melhorias resultantes na experiência do usuário podem ser transformadoras.

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

Apêndice: Perguntas frequentes sobre a cadeia Beam

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

(A): Não, não o faz. A proposta da Beam Chain sugere simplesmente implementar certas partes do roadmap existente da Ethereum de uma vez. Se será ou não implementada é algo que ainda requer discussão na comunidade. Todos os tópicos discutidos acima já têm EIPs ou publicações associadas no Ethresear.ch. Isso, mais ou menos, mostra que a Beam Chain não é uma proposta que propõe uma direção nova e não divulgada anteriormente para a Ethereum. Além disso, as discussões sobre o roadmap da Ethereum são realizadas publicamente durante a chamada quinzenal dos desenvolvedores principais, na qual qualquer pessoa pode participar. Se alguém discorda do roadmap ou tem novas ideias, pode expressar as suas opiniões durante estas chamadas ou submeter novas propostas na forma de EIPs ou publicações no Ethresear.ch.

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

(Q): Não é um período muito longo de 5 anos para implementar a cadeia Beam?

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

1. Ethereum é construído sobre uma arquitetura de vários clientes.
2. Ethereum tem o maior número de validadores de qualquer blockchain.

(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 multi-cliente 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. Levando em consideração 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 é republicado a partir de [2077research]. Todos os direitos autorais pertencem ao autor original [sm-pilha]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer conselho de investimento.
3. A equipe Learn da Gate faz traduções do artigo para outros idiomas. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.