EIP-2537: uma longa jornada de 2020 a 2025

EIP-2537 é uma instrução de pré-compilação EVM que foi determinada para ser adicionada na mais recente atualização do fork Pectra do Ethereum. Esta instrução adiciona várias funcionalidades de cálculo da curva BLS12-381 ao EVM, como cálculos de emparelhamento no domínio da curva.

EIP-2537 foi proposto pela primeira vez em 2020 e só foi confirmado para inclusão na atualização do Ethereum em 2025. Este artigo irá apresentar o processo de governança do EIP-2537 e explorar por que esta proposta levou 5 anos para ser finalmente adotada.

Contexto da Proposta

Em janeiro de 2017, Vitalik Buterin apresentou pela primeira vez o algoritmo de pareamento e a curva alt_bn128 em um artigo. Em fevereiro seguinte, Vitalik e Christian Reitwiessner propuseram o EIP-196 e o EIP-197, recomendando a adição de suporte para cálculos da curva alt_bn128 na EVM.

A atualização Byzantium de outubro de 2017 incorporou oficialmente a curva alt_bn128, permitindo o cálculo de pares de domínios de curvas dentro do EVM, possibilitando que a verificação de provas ZK-Snarks seja realizada dentro do EVM.

Mas com o desenvolvimento da criptografia, em novembro de 2017 a equipe do zcash propôs a curva BLS12-381, que possui maior segurança e melhor desempenho em comparação com a alt_bn128. Muitos protocolos de blockchain adotaram posteriormente a curva BLS12-381 em substituição à alt_bn128.

Em maio de 2018, Justin Drake publicou que as futuras atualizações PoS e de shard do Ethereum poderiam usar um algoritmo de multi-assinatura BLS baseado em BLS12-381. Isso estabeleceu a base para a posterior atualização do ETH2.

Com o desenvolvimento do ETH2, crescem as vozes a favor da introdução do BLS12-381 na camada de execução. Em fevereiro de 2020, pesquisadores propuseram o EIP-2537, esperando testá-lo juntamente com a testnet do ETH2. O autor do EIP-2537, Alex Stokes, apelou para que fosse incluído no hard fork Berlin.

Vale a pena mencionar que o autor do EIP-2537 é também cofundador da Matter Labs, cuja produto mais famoso é o ZKSync.

Berlin em turbulência

Antes de introduzir o conteúdo subsequente, é necessário entender o EIP-1962. Esta é a primeira proposta de pré-compilação para emparelhamento de domínios de curvas elípticas apresentada pela Matter Labs em abril de 2019, que suporta três curvas: BLS12, BN e MNT4/6.

O EIP-1962 planeia adicionar 10 instruções pré-compiladas de uma só vez para processar diferentes curvas. No entanto, muitos desenvolvedores consideram que é demasiado complexo e difícil de implementar, além de não ser amigável para engenheiros de contratos inteligentes. Contudo, a Matter Labs já completou o desenvolvimento do algoritmo e oferece implementações de referência em várias linguagens.

Para resolver o problema EIP-1962, a Matter Labs propôs várias soluções de divisão de EIP em fevereiro de 2020:

• EIP-2537 oferece suporte a BLS12-381
• EIP-2539 fornece suporte a BLS12-377
• PR#2541 oferece suporte à curva BLS12-377(Zexe ), mas não recebeu número EIP

Dentre eles, o EIP-2537 é o mais importante, pois a camada de consenso também utiliza a curva BLS12-381. Os objetivos centrais do EIP-1962 e do EIP-2537 são implementar a verificação de assinaturas BLS na camada de consenso da mainnet.

Na época, o ETH2 estava desenvolvendo o contrato de depósito. Como a camada de execução não tinha validação BLS, o contrato de depósito no design original não validava a assinatura, sendo verificada pela camada de consenso; se estivesse incorreto, o depósito falharia, resultando em perda de fundos.

Portanto, os desenvolvedores principais desejam introduzir a pré-compilação BLS12-381 para verificar assinaturas nos contratos de depósito e evitar riscos financeiros. Esta também foi a razão pela qual os desenvolvedores estavam focados no EIP-1962 e no EIP-2537.

Após a proposta do EIP-2537, Vitalik imediatamente apontou uma série de problemas, principalmente concentrando-se no conteúdo do documento. O autor posteriormente respondeu e discutiu.

A reunião de desenvolvedores principais de 6 de março de 2020 discutiu a EIP-2537. Vitalik acredita que é muito eficaz para provas SNARK recursivas e, a longo prazo, não prejudicará o Ethereum. A reunião confirmou a prioridade da EIP-2537, e todos os clientes concordaram em implementá-la o mais rápido possível e concluir o desenvolvimento antes da atualização de Berlin.

Em seguida, o EIP-2537 tornou-se uma tarefa de alta prioridade. A reunião do dia 20 de março priorizou novamente a discussão dessa proposta, confirmando que ela substituiria o EIP-1962 como a proposta central de BLS e seria incluída na lista pré-selecionada para a atualização de Berlin.

A reunião de abril de 84 formalmente incorporou o EIP-2537 no hard fork Berlin, estabelecendo a linha do tempo para implementação em abril e testes em maio e junho. O EIP-2537 foi classificado como a prioridade mais alta.

Após isso, o EIP-2537 entrou em uma fase intensa de desenvolvimento e testes, com discussões relacionadas em quase todas as 20 reuniões de desenvolvedores principais que se seguiram.

Na reunião 85, discutiu-se o problema da codificação ABI. Como a Matter Labs já concluiu basicamente a implementação em Rust, o cliente Besu afirmou que já implementou basicamente a funcionalidade EIP-2537, mas o Geth afirmou que ainda não começou a trabalhar na implementação.

A reunião 86 sincronizou novamente a situação de implementação de cada nó, o Geth indicou que parte do trabalho foi concluída, mas ainda há uma grande quantidade de tarefas por completar.

O conteúdo central da reunião 87 é o problema da implementação do EIP-2537. Os desenvolvedores do Geth afirmaram que há um PR de 16.000 linhas que implementa o EIP-2537, mas não é possível determinar se é seguro e eficaz, podendo apenas ser avaliado por meio de testes de fuzzing simples. O Geth acredita que é muito provável que não consiga concluir o desenvolvimento relacionado antes do prazo estipulado para Berlim.

Hudson Jameson propôs encontrar engenheiros de criptografia para ajudar na revisão do PR do Geth e sugeriu testar a implementação de segurança na rede de testes. A equipe do ETH2 também pode participar dos testes.

É importante acrescentar que a implementação do PR do EIP-2537 do Geth utiliza uma grande quantidade de código assembly para garantir eficiência, tornando-a difícil de ler e entender. Alex Vlasov sugeriu remover as otimizações complexas de assembly para reduzir a dificuldade de revisão.

Embora um dos principais objetivos do EIP-2537 seja auxiliar o contrato de depósito ETH2, os desenvolvedores do contrato de depósito nesta reunião afirmaram que a versão que não usa o EIP-2537 já foi auditada, e alguns desenvolvedores sugeriram que não se deve lançar uma nova versão que utilize o EIP-2537.

A reunião final decidiu aumentar a rede de testes YOLO para testar especificamente o EIP-2537. Neste momento, pode-se observar que, à medida que o contrato de depósito é concluído, a importância do EIP-2537 diminuiu significativamente, e os desenvolvedores do Geth acreditam que é muito provável que não consiga ser implementado antes da atualização de Berlin. A exclusão do EIP-2537 de Berlin parece ter se tornado uma certeza.

Durante a reunião 88, os desenvolvedores do Geth descobriram uma série de problemas na implementação do PR do EIP-2537, afirmando que são necessários mais testes e correções. Neste momento, o Geth tem duas versões de implementação, uma que inclui otimizações de assembly e outra que é completamente escrita em Go. Alguém sugeriu usar diretamente a versão em Go para reduzir a dificuldade da revisão do código.

A reunião 89 apresentou problemas mais graves, a rede de testes YOLO apresentou anomalias, suspeitando que fosse causada pela assinatura BLS, mas os desenvolvedores do EIP-2537 refutaram isso. A boa notícia é que o contrato de depósito baseado no EIP-2537 está basicamente concluído e está aguardando auditoria.

A reunião 90 fixou o prazo para o lançamento da atualização Berlin em julho. A reunião também discutiu a questão da diversidade de clientes, com alguém propondo congelar a implementação atual do EIP para reduzir os custos de desenvolvimento de outros clientes. A reunião 91 até sugeriu usar uma solução modular para aumentar a diversidade de clientes.

A reunião 92 confirmou novamente que o EIP-2537 é o EIP necessário para a atualização de Berlin.

A reunião 96 discutiu se o EIP-2539 também deveria ser incluído no teste de Berlin, uma vez que a Celo já incluiu o EIP-2537 e o EIP-2539 em sua atualização de rede. No entanto, os desenvolvedores do Geth se opuseram, argumentando que o EIP-2537 ainda não foi completamente testado. A decisão final foi não incluir o EIP-2696 em Berlin.

A reunião 99 decidiu remover o EIP-2537 da rede de teste YOLO v3 e da atualização Berlin, sendo a principal razão que isso consumiu muito tempo dos desenvolvedores, afetando o desenvolvimento de outros EIPs. Um fator secundário é que a Fundação Ethereum propôs o EVM384 como uma alternativa. No entanto, os desenvolvedores expressaram preocupações sobre sua segurança.

Esta é a trajetória inicial do EIP-2537. Era um dos EIPs mais importantes da atualização Berlin, mas foi descartado devido a problemas de implementação. Em abril de 2021, o Ethereum completou a atualização Berlin, e a implementação de EIPs principais como o EIP-2565 foi relativamente simples, parecendo um pouco superficial, justamente porque o EIP-2537, que era o mais complexo, foi eliminado.

Desenvolvimento futuro

É bem sabido que cada atualização do Ethereum tem propostas principais, como a introdução do EIP-1559 após a atualização de Londres, que se seguiu a Berlim. Para o EIP-2537, que já foi uma proposta principal, é difícil que atualizações subsequentes o incluam novamente.

Durante a atualização de Londres, os desenvolvedores consideraram adicionar o EIP-2537. A reunião 109 sincronizou o seu estado de desenvolvimento, devido a discussões sobre o gas geradas pela implementação de uma nova biblioteca. Alguém sugeriu substituir por EVM384. No entanto, a reunião 111 o removeu da atualização de Londres devido à complexidade, principalmente porque a mudança da biblioteca causou alterações nos preços do gas, o que requer uma nova avaliação.

Em junho de 2021, foi proposto oficialmente incluir o EIP-2537 na atualização de Shanghai. Mas após Londres, The Merge consumiu muito do tempo dos desenvolvedores. Após a conclusão de The Merge em setembro de 2022, os desenvolvedores da camada de execução só tiveram a oportunidade de continuar a discutir os objetivos de Shanghai.

A reunião de novembro de 2022 discutiu brevemente a inclusão de Shanghai, mas os desenvolvedores acharam que deveria ser adiada, o núcleo de Shanghai é o suporte a retiradas de PoS. No final, o EIP-2537 não foi incluído na atualização de Shanghai centrada nas retiradas.

Pior ainda, a atualização de Cancun nunca discutiu o EIP-2537, pois seu núcleo é o suporte ao EIP-4844, que fornece disponibilidade de dados Blob para a camada dois.

Finalmente, na reunião de fevereiro de 2024, a discussão 181 sobre a atualização do Pectra incluiu o EIP-2537, os desenvolvedores acreditam que a implementação já não é um problema, existe apenas a questão da precificação do gas.

Na reunião de 19 de dezembro de 2024, os desenvolvedores da Nethermind finalmente definiram o modelo de precificação EIP-2537. O proponente original, a Matter Labs, quase saiu da discussão neste momento. A reunião 203 de janeiro de 2025 discutiu a reprecificação, com os desenvolvedores do Geth sugerindo um aumento de 20% nos custos de gás, obtendo o apoio da equipe do Besu.

Resumo

EIP-2537 passou por um longo período de 5 anos desde a sua proposta até à sua aceitação. Foi o núcleo da atualização de Berlin, mas foi abandonado devido à dificuldade de implementação. Em seguida, o Ethereum entrou no processo histórico de PoS, e EIPs complexos de camada de execução pura não receberam atenção, enquanto muitos EIPs relacionados ao PoS se tornaram objetivos centrais, resultando na não aceitação prolongada do EIP-2537. Até 2025, com a resolução de problemas técnicos principais, o EIP-2537 finalmente tem a esperança de ser implementado na atualização Pectra.

Este percurso demonstra que a inclusão de um EIP na atualização do Ethereum depende não apenas do seu valor técnico intrínseco, mas também da fase de desenvolvimento e das prioridades gerais do Ethereum. Cada atualização tem o seu tema, e apenas os EIPs que satisfaçam as necessidades atuais e que estejam tecnicamente maduros podem ser finalmente adotados.