Este artigo apresenta a história de governança do EIP-2537, explorando por que levou 5 anos para que esta proposta fosse incluída na atualização.
撰文：shew
Resumo
EIP-2537 é a instrução pré-compilada EVM que foi determinada para ser adicionada na mais recente atualização de bifurcação do Pectra. 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-2573 foi proposto pela primeira vez em 2020 e só foi confirmado para ser incluído na atualização do Ethereum em 2025. Este artigo apresenta a história da governança do EIP-2537, explorando por que levou 5 anos para que esta proposta fosse incorporada à atualização.
Contexto da proposta
Em janeiro de 2017, Vitalik Buterin apresentou pela primeira vez o algoritmo de emparelhamento e a curva alt_bn128 em Exploring Elliptic Curve Pairings. Em seguida, em fevereiro de 2017, Vitalik Buterin e Christian Reitwiessner propuseram as propostas EIP-196 e EIP-197, cujo conteúdo é adicionar suporte para cálculos da curva alt_bn128 ao EVM.
Na atualização Byzantium de outubro de 2017, a curva alt_bn128 foi oficialmente incorporada. Em termos simples, a alt_bn128 implementou pela primeira vez o cálculo de pares de domínios de curvas dentro da EVM, permitindo que a verificação de provas ZK-Snarks fosse realizada na EVM.
Mas com o desenvolvimento da criptografia, em novembro de 2017, a equipe de desenvolvimento do zcash apresentou pela primeira vez a curva BLS12-381 no documento BLS12-381: New zk-SNARK Elliptic Curve Construction. Em comparação com a alt_bn128, a BLS12-381 oferece maior segurança e melhor desempenho. Vários protocolos de blockchain passaram a usar a curva BLS12-381 e abandonaram a curva alt_bn128.
Em maio de 2018, Justin Drake publicou no ethresear o artigo "Pragmatic signature aggregation with BLS", apontando que as futuras atualizações de PoS e sharding do Ethereum poderiam usar o algoritmo de multi-assinatura BLS baseado na curva BLS12-381. Na época, os pesquisadores do Ethereum esperavam usar o EIP-1011 para resolver problemas na camada de consenso, mas a proposta do EIP-1011 poderia acomodar no máximo 900 validadores, estabelecendo assim uma enorme escala de staking de 1500 ETH para cada validador. Com a proposta do esquema de multi-assinatura BLS, o EIP-1011 saiu de cena. Comprovou-se que a atualização posterior do ETH2 também acabou por usar a curva BLS12-381.
Com o desenvolvimento do ETH2, a BLS12-381 utilizada pelo ETH2 começou a ser chamada para a camada de execução do ETH. Em fevereiro de 2020, alguns pesquisadores propuseram o EIP-2537 e esperavam que essa proposta pudesse ser testada juntamente com a rede de testes do ETH2. O autor do EIP-2537, Alex Stokes, apelou para a inclusão do EIP-2537 na atualização do hard fork de Berlim no artigo "What eth2 needs from eth1 over the next six months".
Curiosamente, o autor do EIP-2537 também é cofundador da Matter Labs, e o produto mais famoso da Matter Labs é o ZKSync.
Berlin Turbulência
Antes de apresentarmos o conteúdo subsequente, precisamos primeiro introduzir o EIP-1962. O EIP-1962 é a primeira proposta sobre a pré-compilação de emparelhamento de curvas elípticas apresentada pela Matter Labs em abril de 2019, que suporta três curvas, a saber:
BLS12
BN
MNT4/6 (Ate pairing)
Este EIP propõe adicionar 10 instruções de pré-compilação de uma só vez para lidar com diferentes curvas. No entanto, após o surgimento da proposta, um número considerável de desenvolvedores questionou se a proposta era complexa demais para que os desenvolvedores a implementassem. Ao mesmo tempo, devido à alta generalização do EIP1962, a chamada também é bastante complicada para engenheiros de contratos inteligentes. Claro, como proponente do EIP-1962, a Matter Labs já completou essencialmente o trabalho de desenvolvimento do algoritmo de curva elíptica e forneceu implementações de referência em Rust / Go / C++.
Para resolver o problema do EIP-1962, a Matter Labs propôs em fevereiro de 2020 vários EIPs que dividem o EIP-1962, todos os quais herdam parcialmente a interface do EIP-1962. Esses EIPs incluem:
EIP-2537 fornece suporte para BLS12-381
EIP-2539 fornece suporte para BLS12-377
PR#2541 fornece suporte para a curva BLS12-377 (Zexe ), mas note que esta proposta não obteve um número EIP e não pode ser encontrada na documentação oficial do EIP.
Dentro desses EIPs, o mais importante é o EIP-2537, porque a camada de consenso também utiliza a curva BLS12-381. Tanto o EIP-1962 quanto o EIP-2537 têm como objetivo central realizar a verificação da assinatura BLS na camada de consenso na mainnet. Naquela época, o ETH2 estava desenvolvendo o design do contrato de depósito da camada de consenso. Quando o contrato de depósito foi projetado inicialmente, como a camada de execução não incluía o algoritmo de verificação BLS, o contrato de depósito não verificaria a assinatura; a assinatura BLS específica seria verificada pela camada de consenso após o depósito do usuário, e se fosse detectada uma falha (para novos validadores), o depósito falharia, e o ETH depositado pelo usuário seria perdido.
Neste contexto, os desenvolvedores principais desejam introduzir a pré-compilação BLS12-381 para implementar a verificação de assinaturas dentro do contrato de depósito, evitando a possível perda de fundos ETH2 pelos usuários. Esta foi também a razão pela qual muitos desenvolvedores estavam atentos ao EIP-1962 e EIP-2537.
Quando o EIP-2537 foi proposto, Vitalik imediatamente identificou uma série de problemas existentes no EIP:
Essas dúvidas se concentraram apenas no conteúdo da documentação do EIP, e os autores do EIP responderam e discutiram a respeito. Em seguida, no dia 6 de março de 2020, durante a reunião #82 dos desenvolvedores principais do Ethereum, os desenvolvedores principais discutiram o EIP-2537. Nessa reunião, Vitalik acreditou que o EIP-2537 e outros EIPs são muito eficazes para provas SNARK recursivas e que, a longo prazo, não prejudicariam o Ethereum. Além disso, a reunião confirmou a prioridade do EIP-2537, e todos os clientes concordaram em implementar o EIP-2537 o mais rápido possível, planejando concluir todo o desenvolvimento antes da atualização de Berlin.
Em seguida, o EIP-2537 tornou-se uma tarefa de alta prioridade. No dia 20 de março de 2020, na Ethereum Core Devs Meeting #83, o EIP-2537 ainda foi a proposta discutida primeiro. Esta reunião confirmou que o EIP-2537 substituiria o EIP-1962 como a proposta principal de BLS e entraria na lista pré-selecionada de EIPs para a atualização de Berlin (, ou seja, Eligibility for Inclusion (EFI)).
Na reunião dos desenvolvedores principais do Ethereum #84, em abril de 2020, foi oficialmente incorporado o EIP-2537 na atualização do hard fork Berlin, e foi estabelecido um cronograma para a implementação em abril e testes em maio e junho. É importante notar que, nesta discussão, o EIP-2537 foi listado como uma questão de máxima prioridade.
Em seguida, o EIP-2537 entrou em uma fase intensa de desenvolvimento e testes, e em quase 20 reuniões de desenvolvedores principais que se seguiram, cada reunião basicamente envolveu discussões sobre o EIP-2537. A seguir, podemos ver quais questões sobre o EIP-2537 foram discutidas em cada uma das reuniões.
Na reunião dos desenvolvedores principais do Ethereum #85, Danno e Axic discutiram o problema de codificação ABI do EIP-2537. Em seguida, os desenvolvedores principais sincronizaram a situação atual da implementação, onde devido ao fato de que o proponente do EIP-2537, Matter Labs, já havia concluído basicamente a implementação da versão em Rust, o cliente Besu declarou que já havia implementado basicamente a funcionalidade do EIP-2537, mas o pessoal do Geth afirmou que atualmente ninguém está trabalhando na implementação do EIP-2537.
Na reunião dos desenvolvedores principais do Ethereum #86, diferentes implementações de nós Ethereum sincronizaram novamente o estado de implementação do EIP-2537, onde o Geth indicou que completou parte do trabalho, mas ainda há muito trabalho a ser feito.
Na Reunião dos Desenvolvedores do Ethereum Core #87, o conteúdo mais central desta reunião de desenvolvedores é a questão da implementação do EIP-2537. Os desenvolvedores do Geth afirmaram que atualmente existe um PR de 16000 linhas que implementa o EIP-2537, mas os desenvolvedores do Geth não conseguem determinar se o PR é uma implementação segura e eficaz do EIP-2537, portanto, os desenvolvedores podem apenas avaliar a situação do código através de testes de fuzzing simples e diretos.
Os desenvolvedores do Geth disseram: «Então, minha reação instintiva é que não há chance de o Geth estar pronto com as operações de curva BLS para o lançamento da mainnet em julho.», ou seja, é muito provável que o Geth não consiga concluir o desenvolvimento relacionado ao EIP-2537 antes do tempo previsto em Berlim.
Hudson Jameson propôs buscar engenheiros de criptografia para auxiliar na revisão de PR do Geth, e sugeriu usar uma testnet para testar a segurança da implementação do EIP-2537. Como a equipe de desenvolvimento do ETH2 também está implementando a verificação de assinaturas BLS, a equipe do ETH2 pode participar dos testes.
Aqui, precisamos adicionar um conhecimento de fundo, que é que a implementação do PR do EIP-2537 do Geth, para garantir eficiência, utilizou amplamente código assembly, que é muito difícil de ler e entender. Portanto, Alex Vlasov sugeriu remover as otimizações complexas em assembly dentro do PR para reduzir a dificuldade de revisão.
Já discutimos anteriormente que um dos objetivos centrais do EIP-2537 é auxiliar o contrato de depósito ETH2, mas na reunião desta vez, os desenvolvedores do contrato de depósito afirmaram que o contrato de depósito que não utiliza o EIP-2537 já foi auditado, portanto, alguns desenvolvedores sugeriram que seria melhor não lançar um contrato de depósito que utilizasse o EIP-2537.
No final, a reunião decidiu aumentar a rede de teste YOLO, cujo núcleo é testar o EIP-2537. Na verdade, nesta reunião, já podemos ver que a importância do EIP-2537 diminuiu significativamente com a conclusão do contrato de depósito, enquanto os desenvolvedores do Geth já acreditam que é muito provável que esse EIP não possa ser implementado antes da atualização de Berlim. Parece que a rejeição do EIP-2537 pela atualização de Berlim já se tornou um fato consumado.
Na Reunião dos Desenvolvedores do Ethereum Core #88, os desenvolvedores do Geth descobriram uma série de problemas na PR de implementação do EIP-2537, e os desenvolvedores afirmaram que são necessários mais testes e correções. Neste momento, existem duas implementações do EIP-2537 dentro do sistema Geth, uma das quais contém otimizações em assembly, enquanto a outra é totalmente escrita em Go. Um desenvolvedor sugeriu usar diretamente a versão escrita em Go para reduzir a dificuldade da revisão do código.
Na reunião dos desenvolvedores principais do Ethereum #89, um problema mais sério ocorreu, o teste YOLO apresentou alguns problemas, os desenvolvedores suspeitam que seja um problema causado pela assinatura BLS, mas os desenvolvedores do EIP2537 rebateram isso, acreditando que o problema da rede de teste não foi causado pela assinatura BLS. A boa notícia sobre o EIP-2537 é que o contrato de depósito baseado no EIP-2537 está praticamente concluído, e o contrato está aguardando auditoria.
Na reunião dos Desenvolvedores do Core Ethereum #90 内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91, um desenvolvedor propôs o uso de uma solução modular para reduzir os custos de desenvolvimento e aumentar a diversidade dos clientes. Se os leitores estiverem interessados na diversidade dos clientes do Ethereum, podem ler as atas dessas duas reuniões.
Na Reunião dos Desenvolvedores do Core do Ethereum #92, o 2537 ainda é confirmado como o EIP necessário para a atualização Berlin.
Na Reunião dos Desenvolvedores do Ethereum Core #96, foi mencionado que a Celo já integrou EIP-2537 e EIP-2539 em sua atualização de hard fork de rede. Assim, a Matter Labs espera que o EIP-2539, apresentado juntamente com o EIP-2537, também seja testado na rede de testes YOLO v2 e integrado na atualização Berlin. No entanto, os desenvolvedores do Geth se opuseram, argumentando que o atual EIP-2537 ainda não passou por testes completos internamente no Geth. A decisão final da reunião foi não adicionar 2696 na atualização Berlin, deixando para discussão futura.
Na Reunião dos Desenvolvedores Principais do Ethereum #99, foi decidido remover o EIP-2537 da rede de testes YOLO v3 e da atualização Berlin. A principal razão para isso é que o EIP-2537 consumiu muito tempo dos desenvolvedores principais, impedindo o desenvolvimento de outros EIPs na atualização Berlin. Um fator secundário é que a Fundação Ethereum propôs o EVM384 como substituto do EIP-2537, que oferece uma solução de cálculo de curva elíptica mais genérica. No entanto, os desenvolvedores principais expressaram preocupações sobre questões de segurança durante a discussão da reunião.
O conteúdo acima é a trajetória inicial do EIP-2537. Podemos ver que o EIP-2537 foi um dos EIPs mais importantes durante a atualização de Berlin, mas devido a problemas de implementação, acabou sendo descartado. Por fim, em abril de 2021, o Ethereum completou a atualização de Berlin, onde os EIPs centrais, como o EIP-2565, não eram de fato complexos, fazendo parecer que a atualização de Berlin era um pouco magra, pois o EIP-2537, que era o mais complexo, foi excluído da atualização de Berlin.
Desenvolvimento Futuro
É bem conhecido que cada atualização do Ethereum tem uma proposta central, como a proposta de taxa de transação mais importante da história do Ethereum, EIP-1559, introduzida na atualização London após a atualização Berlin. Para a EIP-2537, que anteriormente foi uma proposta central, as atualizações subsequentes têm dificuldade em incluir essa proposta.
Na atualização de Londres após Berlim, os desenvolvedores sincronizaram a situação atual do desenvolvimento do EIP-2537 na issues#369 曾考虑在 London 升级中增加 EIP-2537。在 Ethereum Core Devs Meeting #109. Nesse momento, devido ao uso de outras bibliotecas para implementar o EIP-2537, surgiu uma discussão sobre o uso de gás do EIP-2537. Ao mesmo tempo, um desenvolvedor sugeriu substituir o EIP-2537 pelo EVM384. No entanto, na reunião dos desenvolvedores principais do Ethereum #111 em abril de 2021, o EIP-2537 foi removido da atualização de Londres devido à sua complexidade. A complexidade central reside no fato de que a implementação padrão do EIP-2537 alterou as bibliotecas de dependência, o que pode resultar em mudanças na precificação do gás, e as diferentes implementações do cliente precisarão de um tempo considerável para reavaliar o consumo de gás.
Em junho de 2021, foi formalmente proposta a inclusão do EIP-2537 na atualização Shanghai no issues#343. No entanto, é importante notar que, após a atualização London, na verdade, a atualização Pairs ou conhecida como The Merge ocupou muito tempo dos desenvolvedores, e os desenvolvedores da camada de execução precisaram escrever uma grande quantidade de código para implementar a atualização PoS. Em setembro de 2022, a atualização Pairs foi concluída, e os desenvolvedores da camada de execução finalmente tiveram a oportunidade de continuar a discutir alguns dos objetivos da atualização Shanghai.
Em novembro de 2022, durante a 150ª reunião dos desenvolvedores principais do Ethereum, foi brevemente discutido se o EIP-2537 deveria ser incluído na atualização Shanghai, mas os desenvolvedores acharam que o EIP-2537 precisava ser adiado, já que o foco da atualização Shanghai era o suporte a retiradas de PoS. No final, o EIP-2537 não foi incluído na atualização Shanghai, que tinha como núcleo a funcionalidade de retiradas.
Mais triste ainda é que a atualização Cancun nunca discutiu o EIP-2537, porque o núcleo da atualização Cancun é o suporte dos nós da camada de execução ao EIP-4844. O EIP-4844 fornece Blobs para a segunda camada do Ethereum, facilitando o uso do Ethereum como camada de disponibilidade de dados.
Finalmente, na reunião dos desenvolvedores principais do Ethereum #181 em fevereiro de 2024, os desenvolvedores discutiram a inclusão do EIP-2537 na atualização Pectra, e nesse momento, os desenvolvedores acreditavam que a implementação do EIP-2537 já não era um problema, apenas algumas questões relacionadas ao preço do consumo de Gas.
Na reunião dos desenvolvedores principais do Ethereum, em 19 de dezembro de 2024, #202 内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的 Ethereum Core Devs Meeting #203, os desenvolvedores discutiram a reavaliação da pré-compilação BLS. Jared Wasinger, desenvolvedor do Geth, sugeriu aumentar o custo de gas em 20%, recebendo o apoio da equipe do Besu para a realização de testes de benchmark.
Resumo
É evidente que a inclusão do EIP na atualização do Ethereum "depende, claro, do esforço próprio, mas também deve considerar o curso da história". Cada atualização do Ethereum tem seu próprio tema, assim como o EIP-2537 que se tornou o EIP mais importante da atualização Berlin, mas foi abandonado devido à sua dificuldade e complexidade de implementação. O Ethereum subsequentemente entrou no processo histórico do PoS, onde EIPs complexos de camada de execução pura não foram valorizados, enquanto uma grande quantidade de EIPs relacionados ao PoS foi vista como objetivos de atualização centrais, o que resultou na não aceitação do EIP-2537 por um longo período.
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Observatório de Governança do Ethereum: O Processo de Pré-Compilação do EIP-2537｜GCC Research
撰文：shew
Resumo
EIP-2537 é a instrução pré-compilada EVM que foi determinada para ser adicionada na mais recente atualização de bifurcação do Pectra. 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-2573 foi proposto pela primeira vez em 2020 e só foi confirmado para ser incluído na atualização do Ethereum em 2025. Este artigo apresenta a história da governança do EIP-2537, explorando por que levou 5 anos para que esta proposta fosse incorporada à atualização.
Contexto da proposta
Em janeiro de 2017, Vitalik Buterin apresentou pela primeira vez o algoritmo de emparelhamento e a curva alt_bn128 em Exploring Elliptic Curve Pairings. Em seguida, em fevereiro de 2017, Vitalik Buterin e Christian Reitwiessner propuseram as propostas EIP-196 e EIP-197, cujo conteúdo é adicionar suporte para cálculos da curva alt_bn128 ao EVM.
Na atualização Byzantium de outubro de 2017, a curva alt_bn128 foi oficialmente incorporada. Em termos simples, a alt_bn128 implementou pela primeira vez o cálculo de pares de domínios de curvas dentro da EVM, permitindo que a verificação de provas ZK-Snarks fosse realizada na EVM.
Mas com o desenvolvimento da criptografia, em novembro de 2017, a equipe de desenvolvimento do zcash apresentou pela primeira vez a curva BLS12-381 no documento BLS12-381: New zk-SNARK Elliptic Curve Construction. Em comparação com a alt_bn128, a BLS12-381 oferece maior segurança e melhor desempenho. Vários protocolos de blockchain passaram a usar a curva BLS12-381 e abandonaram a curva alt_bn128.
Em maio de 2018, Justin Drake publicou no ethresear o artigo "Pragmatic signature aggregation with BLS", apontando que as futuras atualizações de PoS e sharding do Ethereum poderiam usar o algoritmo de multi-assinatura BLS baseado na curva BLS12-381. Na época, os pesquisadores do Ethereum esperavam usar o EIP-1011 para resolver problemas na camada de consenso, mas a proposta do EIP-1011 poderia acomodar no máximo 900 validadores, estabelecendo assim uma enorme escala de staking de 1500 ETH para cada validador. Com a proposta do esquema de multi-assinatura BLS, o EIP-1011 saiu de cena. Comprovou-se que a atualização posterior do ETH2 também acabou por usar a curva BLS12-381.
Com o desenvolvimento do ETH2, a BLS12-381 utilizada pelo ETH2 começou a ser chamada para a camada de execução do ETH. Em fevereiro de 2020, alguns pesquisadores propuseram o EIP-2537 e esperavam que essa proposta pudesse ser testada juntamente com a rede de testes do ETH2. O autor do EIP-2537, Alex Stokes, apelou para a inclusão do EIP-2537 na atualização do hard fork de Berlim no artigo "What eth2 needs from eth1 over the next six months".
Curiosamente, o autor do EIP-2537 também é cofundador da Matter Labs, e o produto mais famoso da Matter Labs é o ZKSync.
Berlin Turbulência
Antes de apresentarmos o conteúdo subsequente, precisamos primeiro introduzir o EIP-1962. O EIP-1962 é a primeira proposta sobre a pré-compilação de emparelhamento de curvas elípticas apresentada pela Matter Labs em abril de 2019, que suporta três curvas, a saber:
Este EIP propõe adicionar 10 instruções de pré-compilação de uma só vez para lidar com diferentes curvas. No entanto, após o surgimento da proposta, um número considerável de desenvolvedores questionou se a proposta era complexa demais para que os desenvolvedores a implementassem. Ao mesmo tempo, devido à alta generalização do EIP1962, a chamada também é bastante complicada para engenheiros de contratos inteligentes. Claro, como proponente do EIP-1962, a Matter Labs já completou essencialmente o trabalho de desenvolvimento do algoritmo de curva elíptica e forneceu implementações de referência em Rust / Go / C++.
Para resolver o problema do EIP-1962, a Matter Labs propôs em fevereiro de 2020 vários EIPs que dividem o EIP-1962, todos os quais herdam parcialmente a interface do EIP-1962. Esses EIPs incluem:
Dentro desses EIPs, o mais importante é o EIP-2537, porque a camada de consenso também utiliza a curva BLS12-381. Tanto o EIP-1962 quanto o EIP-2537 têm como objetivo central realizar a verificação da assinatura BLS na camada de consenso na mainnet. Naquela época, o ETH2 estava desenvolvendo o design do contrato de depósito da camada de consenso. Quando o contrato de depósito foi projetado inicialmente, como a camada de execução não incluía o algoritmo de verificação BLS, o contrato de depósito não verificaria a assinatura; a assinatura BLS específica seria verificada pela camada de consenso após o depósito do usuário, e se fosse detectada uma falha (para novos validadores), o depósito falharia, e o ETH depositado pelo usuário seria perdido.
Neste contexto, os desenvolvedores principais desejam introduzir a pré-compilação BLS12-381 para implementar a verificação de assinaturas dentro do contrato de depósito, evitando a possível perda de fundos ETH2 pelos usuários. Esta foi também a razão pela qual muitos desenvolvedores estavam atentos ao EIP-1962 e EIP-2537.
Quando o EIP-2537 foi proposto, Vitalik imediatamente identificou uma série de problemas existentes no EIP:
Essas dúvidas se concentraram apenas no conteúdo da documentação do EIP, e os autores do EIP responderam e discutiram a respeito. Em seguida, no dia 6 de março de 2020, durante a reunião #82 dos desenvolvedores principais do Ethereum, os desenvolvedores principais discutiram o EIP-2537. Nessa reunião, Vitalik acreditou que o EIP-2537 e outros EIPs são muito eficazes para provas SNARK recursivas e que, a longo prazo, não prejudicariam o Ethereum. Além disso, a reunião confirmou a prioridade do EIP-2537, e todos os clientes concordaram em implementar o EIP-2537 o mais rápido possível, planejando concluir todo o desenvolvimento antes da atualização de Berlin.
Em seguida, o EIP-2537 tornou-se uma tarefa de alta prioridade. No dia 20 de março de 2020, na Ethereum Core Devs Meeting #83, o EIP-2537 ainda foi a proposta discutida primeiro. Esta reunião confirmou que o EIP-2537 substituiria o EIP-1962 como a proposta principal de BLS e entraria na lista pré-selecionada de EIPs para a atualização de Berlin (, ou seja, Eligibility for Inclusion (EFI)).
Na reunião dos desenvolvedores principais do Ethereum #84, em abril de 2020, foi oficialmente incorporado o EIP-2537 na atualização do hard fork Berlin, e foi estabelecido um cronograma para a implementação em abril e testes em maio e junho. É importante notar que, nesta discussão, o EIP-2537 foi listado como uma questão de máxima prioridade.
Em seguida, o EIP-2537 entrou em uma fase intensa de desenvolvimento e testes, e em quase 20 reuniões de desenvolvedores principais que se seguiram, cada reunião basicamente envolveu discussões sobre o EIP-2537. A seguir, podemos ver quais questões sobre o EIP-2537 foram discutidas em cada uma das reuniões.
Na reunião dos desenvolvedores principais do Ethereum #85, Danno e Axic discutiram o problema de codificação ABI do EIP-2537. Em seguida, os desenvolvedores principais sincronizaram a situação atual da implementação, onde devido ao fato de que o proponente do EIP-2537, Matter Labs, já havia concluído basicamente a implementação da versão em Rust, o cliente Besu declarou que já havia implementado basicamente a funcionalidade do EIP-2537, mas o pessoal do Geth afirmou que atualmente ninguém está trabalhando na implementação do EIP-2537.
Na reunião dos desenvolvedores principais do Ethereum #86, diferentes implementações de nós Ethereum sincronizaram novamente o estado de implementação do EIP-2537, onde o Geth indicou que completou parte do trabalho, mas ainda há muito trabalho a ser feito.
Na Reunião dos Desenvolvedores do Ethereum Core #87, o conteúdo mais central desta reunião de desenvolvedores é a questão da implementação do EIP-2537. Os desenvolvedores do Geth afirmaram que atualmente existe um PR de 16000 linhas que implementa o EIP-2537, mas os desenvolvedores do Geth não conseguem determinar se o PR é uma implementação segura e eficaz do EIP-2537, portanto, os desenvolvedores podem apenas avaliar a situação do código através de testes de fuzzing simples e diretos.
Os desenvolvedores do Geth disseram: «Então, minha reação instintiva é que não há chance de o Geth estar pronto com as operações de curva BLS para o lançamento da mainnet em julho.», ou seja, é muito provável que o Geth não consiga concluir o desenvolvimento relacionado ao EIP-2537 antes do tempo previsto em Berlim.
Hudson Jameson propôs buscar engenheiros de criptografia para auxiliar na revisão de PR do Geth, e sugeriu usar uma testnet para testar a segurança da implementação do EIP-2537. Como a equipe de desenvolvimento do ETH2 também está implementando a verificação de assinaturas BLS, a equipe do ETH2 pode participar dos testes.
Aqui, precisamos adicionar um conhecimento de fundo, que é que a implementação do PR do EIP-2537 do Geth, para garantir eficiência, utilizou amplamente código assembly, que é muito difícil de ler e entender. Portanto, Alex Vlasov sugeriu remover as otimizações complexas em assembly dentro do PR para reduzir a dificuldade de revisão.
Já discutimos anteriormente que um dos objetivos centrais do EIP-2537 é auxiliar o contrato de depósito ETH2, mas na reunião desta vez, os desenvolvedores do contrato de depósito afirmaram que o contrato de depósito que não utiliza o EIP-2537 já foi auditado, portanto, alguns desenvolvedores sugeriram que seria melhor não lançar um contrato de depósito que utilizasse o EIP-2537.
No final, a reunião decidiu aumentar a rede de teste YOLO, cujo núcleo é testar o EIP-2537. Na verdade, nesta reunião, já podemos ver que a importância do EIP-2537 diminuiu significativamente com a conclusão do contrato de depósito, enquanto os desenvolvedores do Geth já acreditam que é muito provável que esse EIP não possa ser implementado antes da atualização de Berlim. Parece que a rejeição do EIP-2537 pela atualização de Berlim já se tornou um fato consumado.
Na Reunião dos Desenvolvedores do Ethereum Core #88, os desenvolvedores do Geth descobriram uma série de problemas na PR de implementação do EIP-2537, e os desenvolvedores afirmaram que são necessários mais testes e correções. Neste momento, existem duas implementações do EIP-2537 dentro do sistema Geth, uma das quais contém otimizações em assembly, enquanto a outra é totalmente escrita em Go. Um desenvolvedor sugeriu usar diretamente a versão escrita em Go para reduzir a dificuldade da revisão do código.
Na reunião dos desenvolvedores principais do Ethereum #89, um problema mais sério ocorreu, o teste YOLO apresentou alguns problemas, os desenvolvedores suspeitam que seja um problema causado pela assinatura BLS, mas os desenvolvedores do EIP2537 rebateram isso, acreditando que o problema da rede de teste não foi causado pela assinatura BLS. A boa notícia sobre o EIP-2537 é que o contrato de depósito baseado no EIP-2537 está praticamente concluído, e o contrato está aguardando auditoria.
Na reunião dos Desenvolvedores do Core Ethereum #90 内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91, um desenvolvedor propôs o uso de uma solução modular para reduzir os custos de desenvolvimento e aumentar a diversidade dos clientes. Se os leitores estiverem interessados na diversidade dos clientes do Ethereum, podem ler as atas dessas duas reuniões.
Na Reunião dos Desenvolvedores do Core do Ethereum #92, o 2537 ainda é confirmado como o EIP necessário para a atualização Berlin.
Na Reunião dos Desenvolvedores do Ethereum Core #96, foi mencionado que a Celo já integrou EIP-2537 e EIP-2539 em sua atualização de hard fork de rede. Assim, a Matter Labs espera que o EIP-2539, apresentado juntamente com o EIP-2537, também seja testado na rede de testes YOLO v2 e integrado na atualização Berlin. No entanto, os desenvolvedores do Geth se opuseram, argumentando que o atual EIP-2537 ainda não passou por testes completos internamente no Geth. A decisão final da reunião foi não adicionar 2696 na atualização Berlin, deixando para discussão futura.
Na Reunião dos Desenvolvedores Principais do Ethereum #99, foi decidido remover o EIP-2537 da rede de testes YOLO v3 e da atualização Berlin. A principal razão para isso é que o EIP-2537 consumiu muito tempo dos desenvolvedores principais, impedindo o desenvolvimento de outros EIPs na atualização Berlin. Um fator secundário é que a Fundação Ethereum propôs o EVM384 como substituto do EIP-2537, que oferece uma solução de cálculo de curva elíptica mais genérica. No entanto, os desenvolvedores principais expressaram preocupações sobre questões de segurança durante a discussão da reunião.
O conteúdo acima é a trajetória inicial do EIP-2537. Podemos ver que o EIP-2537 foi um dos EIPs mais importantes durante a atualização de Berlin, mas devido a problemas de implementação, acabou sendo descartado. Por fim, em abril de 2021, o Ethereum completou a atualização de Berlin, onde os EIPs centrais, como o EIP-2565, não eram de fato complexos, fazendo parecer que a atualização de Berlin era um pouco magra, pois o EIP-2537, que era o mais complexo, foi excluído da atualização de Berlin.
Desenvolvimento Futuro
É bem conhecido que cada atualização do Ethereum tem uma proposta central, como a proposta de taxa de transação mais importante da história do Ethereum, EIP-1559, introduzida na atualização London após a atualização Berlin. Para a EIP-2537, que anteriormente foi uma proposta central, as atualizações subsequentes têm dificuldade em incluir essa proposta.
Na atualização de Londres após Berlim, os desenvolvedores sincronizaram a situação atual do desenvolvimento do EIP-2537 na issues#369 曾考虑在 London 升级中增加 EIP-2537。在 Ethereum Core Devs Meeting #109. Nesse momento, devido ao uso de outras bibliotecas para implementar o EIP-2537, surgiu uma discussão sobre o uso de gás do EIP-2537. Ao mesmo tempo, um desenvolvedor sugeriu substituir o EIP-2537 pelo EVM384. No entanto, na reunião dos desenvolvedores principais do Ethereum #111 em abril de 2021, o EIP-2537 foi removido da atualização de Londres devido à sua complexidade. A complexidade central reside no fato de que a implementação padrão do EIP-2537 alterou as bibliotecas de dependência, o que pode resultar em mudanças na precificação do gás, e as diferentes implementações do cliente precisarão de um tempo considerável para reavaliar o consumo de gás.
Em junho de 2021, foi formalmente proposta a inclusão do EIP-2537 na atualização Shanghai no issues#343. No entanto, é importante notar que, após a atualização London, na verdade, a atualização Pairs ou conhecida como The Merge ocupou muito tempo dos desenvolvedores, e os desenvolvedores da camada de execução precisaram escrever uma grande quantidade de código para implementar a atualização PoS. Em setembro de 2022, a atualização Pairs foi concluída, e os desenvolvedores da camada de execução finalmente tiveram a oportunidade de continuar a discutir alguns dos objetivos da atualização Shanghai.
Em novembro de 2022, durante a 150ª reunião dos desenvolvedores principais do Ethereum, foi brevemente discutido se o EIP-2537 deveria ser incluído na atualização Shanghai, mas os desenvolvedores acharam que o EIP-2537 precisava ser adiado, já que o foco da atualização Shanghai era o suporte a retiradas de PoS. No final, o EIP-2537 não foi incluído na atualização Shanghai, que tinha como núcleo a funcionalidade de retiradas.
Mais triste ainda é que a atualização Cancun nunca discutiu o EIP-2537, porque o núcleo da atualização Cancun é o suporte dos nós da camada de execução ao EIP-4844. O EIP-4844 fornece Blobs para a segunda camada do Ethereum, facilitando o uso do Ethereum como camada de disponibilidade de dados.
Finalmente, na reunião dos desenvolvedores principais do Ethereum #181 em fevereiro de 2024, os desenvolvedores discutiram a inclusão do EIP-2537 na atualização Pectra, e nesse momento, os desenvolvedores acreditavam que a implementação do EIP-2537 já não era um problema, apenas algumas questões relacionadas ao preço do consumo de Gas.
Na reunião dos desenvolvedores principais do Ethereum, em 19 de dezembro de 2024, #202 内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的 Ethereum Core Devs Meeting #203, os desenvolvedores discutiram a reavaliação da pré-compilação BLS. Jared Wasinger, desenvolvedor do Geth, sugeriu aumentar o custo de gas em 20%, recebendo o apoio da equipe do Besu para a realização de testes de benchmark.
Resumo
É evidente que a inclusão do EIP na atualização do Ethereum "depende, claro, do esforço próprio, mas também deve considerar o curso da história". Cada atualização do Ethereum tem seu próprio tema, assim como o EIP-2537 que se tornou o EIP mais importante da atualização Berlin, mas foi abandonado devido à sua dificuldade e complexidade de implementação. O Ethereum subsequentemente entrou no processo histórico do PoS, onde EIPs complexos de camada de execução pura não foram valorizados, enquanto uma grande quantidade de EIPs relacionados ao PoS foi vista como objetivos de atualização centrais, o que resultou na não aceitação do EIP-2537 por um longo período.