A equipa de protocolo da Ethereum está a trabalhar para cumprir um prazo de dezembro de 2029 para tornar as camadas de execução, consenso e dados da rede resistentes a ataques quânticos, usando como pressuposto de planeamento que o “Q-day” — o momento em que os computadores quânticos poderão quebrar a criptografia amplamente utilizada — poderá chegar até 2030.
O calendário colocaria a capacidade pós-quântica completa numa atualização conhecida como L*, o quinto hard fork depois de Glamsterdam, cuja implementação na mainnet está prevista para dezembro de 2026. A equipa de protocolo da Ethereum Foundation planeia reavaliar os progressos da computação quântica em janeiro de 2027, mas tem tratado o horizonte de 2029 como o prazo de engenharia em vigor, e não como um objetivo de investigação distante.
Esse calendário deixa a Ethereum a tentar implementar várias grandes alterações de protocolo em paralelo. Entre Glamsterdam e L*, a rede teria de lançar Hegotá, I*, J*, K* e L* a um intervalo médio de aproximadamente 7,2 meses. A equipa ainda não definiu datas fixas de implementação na mainnet para as atualizações posteriores a Glamsterdam, e a ordem de alguns trabalhos quânticos posteriores continua em análise.
Um caminho acelerado para uma Ethereum resistente à computação quântica
Hegotá funcionaria como o primeiro ponto de controlo de entrega do programa, embora não tenha sido concebida como um hard fork pós-quântico. As equipas de clientes esperam iniciar o trabalho de implementação no final de 2026, enquanto a investigação, as especificações técnicas, os protótipos e os testes de segurança para as atualizações seguintes avançariam em simultâneo.
O roteiro divide a transição quântica em etapas, em vez de tentar substituir todos os componentes criptográficos vulneráveis numa única versão. Espera-se que I* introduza um registo de chaves públicas pós-quânticas, dando às contas uma forma de registar e utilizar chaves resistentes à computação quântica. É também neste ponto que o “consenso desacoplado” está a ser considerado como uma direção prioritária, juntamente com o trabalho inicial em grandes alterações à estrutura de estado da Ethereum e ao processo de migração.
Está previsto que J* introduza uma Layer 1 pós-quântica mínima viável, ou MV-PQ. O pacote combinaria um mecanismo pós-quântico de “heartbeat” para o consenso, amostragem leanDA pós-quântica para a camada de disponibilidade de dados da Ethereum e transações leanSPHINCS pós-quânticas para a execução.
K* tem atualmente atribuídas provas de execução obrigatórias. Segundo esse modelo, os validadores passariam a verificar provas criptográficas sucintas da execução dos blocos, em vez de reexecutarem integralmente cada bloco. Esta abordagem poderia alterar o papel computacional dos validadores, preparando simultaneamente o Ethereum para um ambiente de execução mais orientado para provas.
L* acrescentaria mensagens de atestação pós-quântica, concluindo a proteção planeada da camada de consenso do Ethereum. A ordem ainda não está definida: os investigadores do protocolo estão a ponderar integrar as atestações resistentes à computação quântica no K* e transferir as provas de execução obrigatórias para o L*. Qualquer uma das sequências manteria o L* como o ponto-alvo para uma cobertura completa dos sistemas de execução, consenso e dados.
Hegotá restringe o seu âmbito inicial a duas propostas obrigatórias
A equipa do protocolo organizou as 62 propostas candidatas para Hegotá em grupos de prioridade. Duas estão no nível S obrigatório, 15 são classificadas como trabalho de alta prioridade do nível A, oito encontram-se no nível B condicional, sete ficam abaixo da linha de inclusão no nível C, 28 estão marcadas como “não incluir no fork” e duas continuam por decidir.
Os dois itens obrigatórios de Hegotá são a EIP-7805, Fork-choice enforced Inclusion Lists, ou FOCIL, e a EIP-8141, Frame Transactions.
A FOCIL acrescentaria regras de inclusão de transações impostas pelos validadores ao processo atual de criação de blocos do Ethereum. Em cada slot, um comité publicaria listas de transações visíveis para os seus membros. O produtor de blocos do slot seguinte agregaria as listas e incluiria as transações elegíveis, enquanto os validadores atestantes verificariam se o bloco proposto cumpria as listas que tinham recebido atempadamente.
Um bloco que omitisse transações elegíveis incluídas nas listas, sem uma razão permitida, poderia continuar válido segundo as regras de execução do Ethereum, mas não receber apoio suficiente das atestações para passar a fazer parte da cadeia canónica. Este modelo atribui aos validadores um papel mais direto na resistência à censura de transações, sem substituir o atual fluxo de produção de blocos.
A EIP-8369 define quais as transações que podem ser elegíveis para inclusão ao estilo da FOCIL. Distingue as transações convencionais das transações Frames, cuja verificação programável pode exigir limites sobre o estado que leem e a computação que consomem.
As Frames, propostas no âmbito da EIP-8141, tornariam a validação, a execução e o pagamento de gas das transações mais programáveis ao nível do protocolo. A proposta fornece uma base para a abstração nativa de contas, permitindo que as contas utilizem lógica de validação personalizada em vez de dependerem exclusivamente do modelo de assinaturas associado às contas detidas externamente.
Essa flexibilidade também faz parte da estratégia de migração da Ethereum. A validação programável poderia permitir que as contas adotassem novos esquemas de assinatura à medida que as condições criptográficas mudam, reduzindo a necessidade de um hard fork separado sempre que a Ethereum precisar de suportar um método de autenticação diferente.
A migração de contas e a resistência à censura convergem
As Frames dependem de duas propostas de nível A: a EIP-8250, Keyed Nonces, e a EIP-8272. Os Keyed Nonces permitiriam a um remetente operar múltiplos canais de nonce independentes, reduzindo o risco de uma transação atrasada bloquear atividade não relacionada da mesma conta. A EIP-8272 permitiria que as transações referenciassem estados recentes na cadeia que os validadores podem verificar.
A equipa do protocolo relaciona essa capacidade de referenciar estados com os esforços para alargar as garantias de inclusão a alguns modelos de transação orientados para a privacidade. Em termos práticos, a Ethereum está a tentar combinar regras mais fortes contra a censura com funcionalidades de conta capazes de acomodar uma verificação de transações mais complexa.
Várias outras propostas de nível A abordam a migração para longe de pressupostos criptográficos que podem tornar-se inseguros perante uma computação quântica suficientemente avançada. A EIP-8365 iniciaria uma saída faseada de determinadas credenciais BLS de levantamento. O trabalho poderia começar antes de a Ethereum finalizar a sua arquitetura completa de consenso pós-quântico.
As EIP-7906, EIP-8298 e EIP-8151 formam um conjunto adicional de segurança de contas em torno das Frames. A EIP-7906 introduziria as Transaction Assertions, permitindo que uma transação exigisse condições especificadas antes de ser finalizada. A EIP-8298 permitiria às contas reutilizar código de contratos existente, proporcionando às contas delegadas uma via para se tornarem contas de contratos inteligentes com o seu próprio código completo. A EIP-8151 impediria que endereços que já contêm código de conta continuassem a utilizar a autenticação tradicional baseada em ecRecover.
Os sistemas de prova e a definição de preços dos recursos continuam a fazer parte do compromisso
O roteiro também inclui a EIP-8025, provas de execução opcionais, na discussão sobre Hegotá. A proposta está ligada ao futuro trabalho da zkEVM e pretende incluir as alterações necessárias numa especificação de execução partilhada, evitando a manutenção a longo prazo de forks de protocolo separados para diferentes projetos de máquinas virtuais de conhecimento zero.
A EIP-8279 e a EIP-8131 estabeleceriam preços mínimos para bytes de listas de acesso a blocos e uma camada unificada de conteúdo de transações. O seu objetivo é limitar os custos máximos de processamento de blocos criados por conteúdo de transações com preço demasiado baixo. A EIP-3298, que remove o mecanismo de reembolso de gas do Ethereum, e a EIP-5920, o opcode PAY para transferir ETH sem executar o código do destinatário, também estão na categoria A.
Algumas ideias proeminentes têm prioridade inferior. A EIP-8198, Quick Slots, que procura tempos de slot mais curtos, continua condicionada a especificações completas, protótipos, análise do impacto nos sistemas dependentes e provas de que não irá interferir com a dissociação do consenso. Prevê-se que as decisões sobre a EIP-8368 e a EIP-8372, que abrangem os limites de gas e a definição de preços dos recursos de estado, dependam dos dados da mainnet recolhidos após Glamsterdam.
A sequência proposta para o Ethereum coloca entregas de curto prazo, como FOCIL e Frames, lado a lado com uma migração de segurança de quatro anos que abrange as funções dos validadores da rede, o modelo de transações e os fundamentos criptográficos. A reavaliação de janeiro de 2027 testará se o ritmo presumido do progresso quântico — e a própria capacidade do Ethereum de lançar atualizações aproximadamente duas vezes por ano — continua a permitir concluir o processo em dezembro de 2029.
Explore como o roteiro do Ethereum influencia a negociação e a segurança da rede — comece hoje a analisar os mercados de criptomoedas em tempo real com Toobit Markets hoje.
Aviso legal: O conteúdo desta página é fornecido apenas para fins informativos gerais e não representa as opiniões nem aconselhamento financeiro da Toobit. Não oferecemos garantias quanto à exatidão ou integralidade destas informações e não seremos responsáveis por quaisquer erros, omissões ou resultados decorrentes da sua utilização. O investimento em ativos digitais envolve riscos; os utilizadores devem avaliar de forma independente a sua situação financeira e os riscos envolvidos. Para mais informações, consulte os nossos Termos de Serviço e Divulgação de Riscos.
