EIP-2537: Um longo caminho da controvérsia à adoção
EIP-2537 é a diretiva de pré-compilação EVM que foi determinada para ser adicionada na mais recente atualização do fork Pectra do Ethereum. Esta diretiva adiciona várias funcionalidades de cálculo da curva BLS12-381 à EVM, como o cálculo de emparelhamento sobre o domínio da curva.
A EIP-2537 foi proposta pela primeira vez em 2020 e só foi confirmada como parte da atualização do Ethereum em 2025. Este artigo irá apresentar o processo de governança da EIP-2537 e discutir 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 emparelhamento e a curva alt_bn128 em um artigo. Em seguida, 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 de Bizâncio de outubro de 2017 introduziu oficialmente a curva alt_bn128, permitindo o cálculo de emparelhamento de curvas dentro da EVM, possibilitando que a verificação de provas ZK-Snarks seja realizada dentro da EVM.
No entanto, com o desenvolvimento da criptografia, em novembro de 2017, a equipe de desenvolvimento do zcash apresentou a curva BLS12-381. Em comparação com a alt_bn128, a BLS12-381 possui maior segurança e melhor desempenho. Muitos protocolos de blockchain adotaram posteriormente a curva BLS12-381, abandonando a alt_bn128.
Em maio de 2018, Justin Drake publicou um artigo apontando que as futuras atualizações de PoS e sharding do Ethereum poderiam utilizar o algoritmo de assinatura múltipla BLS baseado na curva BLS12-381. Esta solução resolveu o problema da limitação do número de validadores nas primeiras propostas de PoS. De fato, as atualizações posteriores do ETH2 adotaram a curva BLS12-381.
Com o avanço do desenvolvimento do ETH2, a demanda por introduzir o BLS12-381 na camada de execução do ETH tem crescido. Em fevereiro de 2020, pesquisadores propuseram o EIP-2537, esperando que a proposta pudesse ser testada junto com a rede de teste do ETH2. O autor do EIP-2537, Alex Stokes, fez um apelo para que essa proposta fosse incluída no hard fork de Berlin.
É importante notar que o autor do EIP-2537 é também um dos cofundadores da Matter Labs, a empresa desenvolvedora do ZKSync.
As peripécias da atualização de Berlim
Antes de apresentar os desenvolvimentos seguintes, precisamos primeiro entender o EIP-1962. Esta é a primeira proposta sobre pré-compilação de emparelhamento 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 planeja adicionar 10 instruções pré-compiladas de uma só vez para lidar com diferentes curvas. No entanto, a proposta foi questionada por muitos desenvolvedores, que a consideram excessivamente complexa e difícil de implementar. Além disso, devido à sua alta generalização, a chamada para engenheiros de contratos inteligentes também é bastante complicada. No entanto, como proponente, a Matter Labs já concluiu o trabalho de desenvolvimento do algoritmo de curva elíptica e forneceu implementações de referência em várias linguagens.
Para resolver o problema do EIP-1962, a Matter Labs propôs em fevereiro de 2020 vários EIPs para dividir o EIP-1962, sendo que esses EIPs herdam parcialmente a interface do EIP-1962:
EIP-2537 oferece suporte para BLS12-381
O EIP-2539 oferece suporte a BLS12-377
A PR#2541 oferece suporte à curva BLS12-377(Zexe ), mas a proposta não recebeu um número EIP.
O mais importante é o EIP-2537, pois a camada de consenso também utiliza a curva BLS12-381. Os principais objetivos do EIP-1962 e do EIP-2537 são implementar a verificação de assinaturas BLS na camada de consenso da mainnet. Naquele momento, o ETH2 estava desenvolvendo o contrato de depósito da camada de consenso. No design inicial, como a camada de execução não incluía o algoritmo de verificação BLS, o contrato de depósito não verificaria as assinaturas; a assinatura BLS específica seria verificada pela camada de consenso após o depósito do usuário. Se alguma inconsistência fosse encontrada, o depósito falharia e o ETH depositado pelo usuário poderia ser perdido.
Neste contexto, os desenvolvedores principais pretendem introduzir a pré-compilação BLS12-381 para implementar a verificação de assinaturas no contrato de depósito, evitando a possível perda de fundos dos usuários. Esta também foi a razão pela qual muitos desenvolvedores estavam atentos ao EIP-1962 e ao EIP-2537 na época.
Quando o EIP-2537 foi proposto, Vitalik já apontou uma série de problemas existentes na proposta. Essas dúvidas concentraram-se principalmente no conteúdo do documento EIP, e os autores do EIP responderam e discutiram sobre isso.
A 82ª reunião de desenvolvedores principais do Ethereum, realizada em 6 de março de 2020, discutiu o EIP-2537. Vitalik acredita que este EIP é muito eficaz para provas recursivas SNARK e, a longo prazo, não terá um impacto negativo no Ethereum. A reunião confirmou a prioridade do EIP-2537, todos os clientes concordaram em implementar este EIP o mais rápido possível e planejam concluir todo o desenvolvimento antes da atualização de Berlim.
Em seguida, o EIP-2537 tornou-se uma tarefa de alta prioridade. A 83ª reunião dos desenvolvedores principais, realizada em 20 de março, novamente colocou-o como a proposta principal a ser discutida. A reunião confirmou que o EIP-2537 substituiria o EIP-1962 como proposta central de BLS e seria incluído na lista pré-selecionada de atualizações de Berlim.
A 84ª reunião de abril oficialmente incorporou o EIP-2537 na atualização do hard fork Berlin, e estabeleceu o cronograma para implementação em abril e testes em maio-junho. Vale ressaltar que o EIP-2537 foi classificado como item de máxima prioridade nesta discussão.
Após isso, o EIP-2537 entrou em uma fase intensa de desenvolvimento e testes, com discussões relevantes em quase todas as 20 reuniões de desenvolvedores principais que se seguiram.
Na 85ª reunião, os desenvolvedores discutiram o problema de codificação ABI do EIP-2537. Como a Matter Labs já havia basicamente concluído a implementação da versão Rust, o cliente Besu afirmou que a funcionalidade do EIP-2537 estava praticamente implementada, mas o Geth afirmou que atualmente ninguém estava trabalhando nesse assunto.
Na 86ª reunião, diferentes nós conseguiram sincronizar novamente o progresso do EIP-2537, o Geth informou que parte do trabalho foi concluída, mas ainda há muitas tarefas a serem realizadas.
A 87ª reunião centrou-se nas questões de implementação do EIP-2537. Os desenvolvedores do Geth afirmaram que existe um PR de 16000 linhas que implementa o EIP-2537, mas não é possível determinar se esse PR implementa o EIP-2537 de forma segura e eficaz, podendo apenas avaliar a situação do código através de testes de fuzzing mais simples.
Os desenvolvedores do Geth disseram: "Pela minha intuição, o Geth não pode estar pronto para a operação da curva BLS antes do lançamento da mainnet em julho."
Hudson Jameson propôs procurar engenheiros de criptografia para ajudar na revisão de PRs do Geth e sugeriu usar a rede de testes 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, pode participar dos testes.
É importante acrescentar que a implementação do EIP-2537 do Geth, na PR, usa uma quantidade significativa de código assembly para garantir eficiência, tornando essa parte do código muito difícil de ler e entender. Alex Vlasov sugeriu remover as otimizações de assembly complexas da PR para reduzir a dificuldade de revisão.
Um dos objetivos principais do EIP-2537 é auxiliar o contrato de depósito ETH2, mas durante esta reunião, os desenvolvedores do contrato de depósito afirmaram que não usarão o contrato do EIP-2537, que já foi auditado. Alguns desenvolvedores acreditam que é melhor não lançar uma nova versão do contrato que utilize o EIP-2537.
Por fim, a reunião decidiu aumentar a rede de testes YOLO, especificamente para testar o EIP-2537. Na verdade, a partir desta reunião, pode-se ver que, com a conclusão do contrato de depósito, a importância do EIP-2537 diminuiu significativamente, enquanto os desenvolvedores do Geth acreditam que é muito provável que este EIP não possa ser implementado antes da atualização de Berlin. A não aceitação do EIP-2537 na atualização de Berlin parece ter se tornado um fato consumado.
Na 88ª reunião, os desenvolvedores do Geth descobriram que a implementação do PR do EIP-2537 apresenta uma série de problemas, indicando a necessidade de mais testes e correções. Neste momento, existem duas implementações do EIP-2537 no sistema Geth, uma contendo otimizações em assembly e a outra totalmente escrita em Go. Um desenvolvedor sugeriu usar diretamente a versão em Go para reduzir a dificuldade de revisão do código.
Na 89ª reunião, surgiram problemas mais graves, com a rede de testes YOLO apresentando algumas anomalias. Os desenvolvedores suspeitam que seja causado 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á praticamente concluído e está aguardando auditoria.
A 90ª reunião estabeleceu o prazo final para o lançamento da atualização Berlin em julho. A reunião também discutiu a questão da diversidade de clientes, principalmente relacionada à situação dominante do Geth, com desenvolvedores sugerindo congelar a implementação atual do EIP para reduzir o custo de desenvolvimento de outros clientes. Na 91ª reunião, um desenvolvedor propôs usar uma solução modular para reduzir os custos de desenvolvimento e aumentar a diversidade de clientes.
A 92ª reunião ainda confirmou o EIP-2537 como o EIP necessário para a atualização de Berlim.
Na 96ª reunião, como a Celo incorporou simultaneamente o EIP-2537 e o EIP-2539 em seu hard fork de rede, a Matter Labs deseja que o EIP-2539 também seja colocado em teste no YOLO v2 e entre na atualização Berlin. No entanto, os desenvolvedores do Geth se opuseram, afirmando que o EIP-2537 ainda não foi testado completamente no Geth. A decisão final da reunião foi não adicionar o EIP-2696 na atualização Berlin, deixando para discussão futura.
A 99ª reunião decidiu remover o EIP-2537 da rede de testes YOLO v3 e da atualização Berlin. A principal razão é que o EIP-2537 consumiu muito tempo dos desenvolvedores principais, o que impediu o desenvolvimento de outros EIPs para a atualização Berlin. Um fator secundário é que a Fundação Ethereum propôs o EVM384 como substituto do EIP-2537, oferecendo uma solução de cálculo de curvas elípticas mais genérica. No entanto, os desenvolvedores principais expressaram preocupações em relação à segurança.
Esta é a trajetória inicial do EIP-2537. Podemos ver que o EIP-2537 foi inicialmente um dos EIPs mais importantes na atualização Berlin, mas acabou sendo abandonado devido a problemas de implementação. Em abril de 2021, o Ethereum completou a atualização Berlin, e o EIP central como o EIP-2565 na verdade não é complicado de implementar, a atualização parece um pouco magra, exatamente porque o EIP-2537, que é o mais complexo, foi eliminado.
Desenvolvimento futuro
É de conhecimento geral que cada atualização do Ethereum traz uma proposta central. A atualização de Londres, após Berlim, introduziu a proposta de taxas de transação mais importante da história do Ethereum, EIP-1559. Para a antiga proposta central EIP-2537, é difícil que futuras atualizações a incluam novamente.
A atualização de Londres após Berlim está em andamento, e os desenvolvedores estão considerando adicionar EIP-2537 no issues#369. A 109ª reunião dos desenvolvedores principais sincronizou o estado de desenvolvimento do EIP-2537, e devido à utilização de outras bibliotecas, houve discussões sobre o uso de gas. Um desenvolvedor propôs substituir EIP-2537 por EVM384. No entanto, na 111ª reunião em abril de 2021, o EIP-2537 foi removido da atualização de Londres devido à sua complexidade. A principal razão é que a implementação padrão do EIP-2537 trocou as bibliotecas de dependência, o que pode levar a mudanças na precificação do gas, e diferentes implementações de clientes exigem muito tempo para reavaliar o consumo de gas.
Em junho de 2021, a issues#343 propôs oficialmente a inclusão do EIP-2537 na atualização Shanghai. No entanto, após a atualização de Londres, o The Merge ocupou muito tempo dos desenvolvedores, que precisaram escrever uma grande quantidade de código para implementar a atualização PoS. Em setembro de 2022, após a conclusão do The Merge, os desenvolvedores da camada de execução finalmente tiveram a oportunidade de continuar discutindo os objetivos da atualização Shanghai.
Em novembro de 2022, na 150ª reunião dos desenvolvedores principais, foi discutido de forma resumida se o EIP-2537 deveria ser incluído no Shanghai, mas os desenvolvedores acharam que deveria ser adiado, pois o foco do Shanghai é o suporte para retiradas de PoS. No final, o EIP-2537 não foi incluído na atualização do Shanghai, que tem como núcleo a retirada.
Mais infelizes, a atualização Cancun não discutiu o EIP-2537, pois o foco de Cancun é suportar o EIP-4844, fornecendo Blobs para a camada 2 do Ethereum para que a camada 2 utilize o Ethereum como camada de disponibilidade de dados.
Até a 181ª reunião de desenvolvedores principais em fevereiro de 2024, os desenvolvedores só discutiram a inclusão do EIP-2537 na atualização Pectra. Neste momento, os desenvolvedores acreditavam que a implementação do EIP-2537 já não era um problema, apenas algumas questões de precificação do consumo de gás precisavam ser resolvidas.
Na 202ª reunião, realizada a 19 de dezembro de 2024, os desenvolvedores da Nethermind finalizaram o modelo de precificação do EIP-2537. Vale a pena notar que, como proponente original do EIP-2537, a Matter Labs já havia praticamente se retirado da discussão. A 203ª reunião, em janeiro de 2025, discutiu a redefinição do preço da pré-compilação BLS, e o desenvolvedor do Geth, Jared Wasinger, sugeriu aumentar o custo de gás em 20%, recebendo apoio da equipe do Besu em testes de referência.
Resumo
EIP-2537 passou por um longo e tortuoso processo desde a sua proposta até a sua adoção final:
Fevereiro de 2020: EIP-2537 foi oficialmente proposta como uma bifurcação da EIP-1962
Abril a Outubro de 2020: Várias discussões sobre problemas de implementação, finalmente abandonado devido à impossibilidade de implementação com a atualização de Berlin.
Março-Abril de 2021: discussão sobre o problema do custo do gás, que foi abandonado devido à complexidade na atualização de Londres.
Novembro de 2022: Discussão sobre a inclusão da atualização Shanghai, sem resultado.
Fevereiro de 2024: acredita-se que a realização já não é um problema, ainda existem alguns problemas de custo de gás, que podem ser incluídos na atualização do Pectra
Dezembro de 2024 a Janeiro de 2025: discutir o modelo de cálculo de custos específico, resolver oficialmente os custos de gás.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
12 gostos
Recompensa
12
6
Partilhar
Comentar
0/400
StableGenius
· 08-03 06:12
empiricamente falando, levaram 5 anos para fazer o que deveria ter sido feito em 6 meses. teatro clássico da governança eth
Ver originalResponder0
RugResistant
· 08-01 07:29
analisou a eip. potenciais sinais de alerta na implementação do bls precisam de uma auditoria mais profunda, para ser honesto
Ver originalResponder0
NFTDreamer
· 08-01 07:29
Caramba, o Vitalik Buterin já queria fazer isso há muito tempo.
Ver originalResponder0
TokenSleuth
· 08-01 07:29
Ah, realmente vai demorar cinco anos... Que sofrimento.
Ver originalResponder0
0xSunnyDay
· 08-01 07:14
5 anos à espera de um eip é muito difícil
Ver originalResponder0
LiquidityHunter
· 08-01 07:11
Zé, a ação do Ethereum está tão lenta que eu já estou cansado de esperar.
EIP-2537: Uma importante atualização do Ethereum que passou de controvérsia à adoção em 5 anos
EIP-2537: Um longo caminho da controvérsia à adoção
EIP-2537 é a diretiva de pré-compilação EVM que foi determinada para ser adicionada na mais recente atualização do fork Pectra do Ethereum. Esta diretiva adiciona várias funcionalidades de cálculo da curva BLS12-381 à EVM, como o cálculo de emparelhamento sobre o domínio da curva.
A EIP-2537 foi proposta pela primeira vez em 2020 e só foi confirmada como parte da atualização do Ethereum em 2025. Este artigo irá apresentar o processo de governança da EIP-2537 e discutir 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 emparelhamento e a curva alt_bn128 em um artigo. Em seguida, 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 de Bizâncio de outubro de 2017 introduziu oficialmente a curva alt_bn128, permitindo o cálculo de emparelhamento de curvas dentro da EVM, possibilitando que a verificação de provas ZK-Snarks seja realizada dentro da EVM.
No entanto, com o desenvolvimento da criptografia, em novembro de 2017, a equipe de desenvolvimento do zcash apresentou a curva BLS12-381. Em comparação com a alt_bn128, a BLS12-381 possui maior segurança e melhor desempenho. Muitos protocolos de blockchain adotaram posteriormente a curva BLS12-381, abandonando a alt_bn128.
Em maio de 2018, Justin Drake publicou um artigo apontando que as futuras atualizações de PoS e sharding do Ethereum poderiam utilizar o algoritmo de assinatura múltipla BLS baseado na curva BLS12-381. Esta solução resolveu o problema da limitação do número de validadores nas primeiras propostas de PoS. De fato, as atualizações posteriores do ETH2 adotaram a curva BLS12-381.
Com o avanço do desenvolvimento do ETH2, a demanda por introduzir o BLS12-381 na camada de execução do ETH tem crescido. Em fevereiro de 2020, pesquisadores propuseram o EIP-2537, esperando que a proposta pudesse ser testada junto com a rede de teste do ETH2. O autor do EIP-2537, Alex Stokes, fez um apelo para que essa proposta fosse incluída no hard fork de Berlin.
É importante notar que o autor do EIP-2537 é também um dos cofundadores da Matter Labs, a empresa desenvolvedora do ZKSync.
As peripécias da atualização de Berlim
Antes de apresentar os desenvolvimentos seguintes, precisamos primeiro entender o EIP-1962. Esta é a primeira proposta sobre pré-compilação de emparelhamento 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 planeja adicionar 10 instruções pré-compiladas de uma só vez para lidar com diferentes curvas. No entanto, a proposta foi questionada por muitos desenvolvedores, que a consideram excessivamente complexa e difícil de implementar. Além disso, devido à sua alta generalização, a chamada para engenheiros de contratos inteligentes também é bastante complicada. No entanto, como proponente, a Matter Labs já concluiu o trabalho de desenvolvimento do algoritmo de curva elíptica e forneceu implementações de referência em várias linguagens.
Para resolver o problema do EIP-1962, a Matter Labs propôs em fevereiro de 2020 vários EIPs para dividir o EIP-1962, sendo que esses EIPs herdam parcialmente a interface do EIP-1962:
O mais importante é o EIP-2537, pois a camada de consenso também utiliza a curva BLS12-381. Os principais objetivos do EIP-1962 e do EIP-2537 são implementar a verificação de assinaturas BLS na camada de consenso da mainnet. Naquele momento, o ETH2 estava desenvolvendo o contrato de depósito da camada de consenso. No design inicial, como a camada de execução não incluía o algoritmo de verificação BLS, o contrato de depósito não verificaria as assinaturas; a assinatura BLS específica seria verificada pela camada de consenso após o depósito do usuário. Se alguma inconsistência fosse encontrada, o depósito falharia e o ETH depositado pelo usuário poderia ser perdido.
Neste contexto, os desenvolvedores principais pretendem introduzir a pré-compilação BLS12-381 para implementar a verificação de assinaturas no contrato de depósito, evitando a possível perda de fundos dos usuários. Esta também foi a razão pela qual muitos desenvolvedores estavam atentos ao EIP-1962 e ao EIP-2537 na época.
Quando o EIP-2537 foi proposto, Vitalik já apontou uma série de problemas existentes na proposta. Essas dúvidas concentraram-se principalmente no conteúdo do documento EIP, e os autores do EIP responderam e discutiram sobre isso.
A 82ª reunião de desenvolvedores principais do Ethereum, realizada em 6 de março de 2020, discutiu o EIP-2537. Vitalik acredita que este EIP é muito eficaz para provas recursivas SNARK e, a longo prazo, não terá um impacto negativo no Ethereum. A reunião confirmou a prioridade do EIP-2537, todos os clientes concordaram em implementar este EIP o mais rápido possível e planejam concluir todo o desenvolvimento antes da atualização de Berlim.
Em seguida, o EIP-2537 tornou-se uma tarefa de alta prioridade. A 83ª reunião dos desenvolvedores principais, realizada em 20 de março, novamente colocou-o como a proposta principal a ser discutida. A reunião confirmou que o EIP-2537 substituiria o EIP-1962 como proposta central de BLS e seria incluído na lista pré-selecionada de atualizações de Berlim.
A 84ª reunião de abril oficialmente incorporou o EIP-2537 na atualização do hard fork Berlin, e estabeleceu o cronograma para implementação em abril e testes em maio-junho. Vale ressaltar que o EIP-2537 foi classificado como item de máxima prioridade nesta discussão.
Após isso, o EIP-2537 entrou em uma fase intensa de desenvolvimento e testes, com discussões relevantes em quase todas as 20 reuniões de desenvolvedores principais que se seguiram.
Na 85ª reunião, os desenvolvedores discutiram o problema de codificação ABI do EIP-2537. Como a Matter Labs já havia basicamente concluído a implementação da versão Rust, o cliente Besu afirmou que a funcionalidade do EIP-2537 estava praticamente implementada, mas o Geth afirmou que atualmente ninguém estava trabalhando nesse assunto.
Na 86ª reunião, diferentes nós conseguiram sincronizar novamente o progresso do EIP-2537, o Geth informou que parte do trabalho foi concluída, mas ainda há muitas tarefas a serem realizadas.
A 87ª reunião centrou-se nas questões de implementação do EIP-2537. Os desenvolvedores do Geth afirmaram que existe um PR de 16000 linhas que implementa o EIP-2537, mas não é possível determinar se esse PR implementa o EIP-2537 de forma segura e eficaz, podendo apenas avaliar a situação do código através de testes de fuzzing mais simples.
Os desenvolvedores do Geth disseram: "Pela minha intuição, o Geth não pode estar pronto para a operação da curva BLS antes do lançamento da mainnet em julho."
Hudson Jameson propôs procurar engenheiros de criptografia para ajudar na revisão de PRs do Geth e sugeriu usar a rede de testes 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, pode participar dos testes.
É importante acrescentar que a implementação do EIP-2537 do Geth, na PR, usa uma quantidade significativa de código assembly para garantir eficiência, tornando essa parte do código muito difícil de ler e entender. Alex Vlasov sugeriu remover as otimizações de assembly complexas da PR para reduzir a dificuldade de revisão.
Um dos objetivos principais do EIP-2537 é auxiliar o contrato de depósito ETH2, mas durante esta reunião, os desenvolvedores do contrato de depósito afirmaram que não usarão o contrato do EIP-2537, que já foi auditado. Alguns desenvolvedores acreditam que é melhor não lançar uma nova versão do contrato que utilize o EIP-2537.
Por fim, a reunião decidiu aumentar a rede de testes YOLO, especificamente para testar o EIP-2537. Na verdade, a partir desta reunião, pode-se ver que, com a conclusão do contrato de depósito, a importância do EIP-2537 diminuiu significativamente, enquanto os desenvolvedores do Geth acreditam que é muito provável que este EIP não possa ser implementado antes da atualização de Berlin. A não aceitação do EIP-2537 na atualização de Berlin parece ter se tornado um fato consumado.
Na 88ª reunião, os desenvolvedores do Geth descobriram que a implementação do PR do EIP-2537 apresenta uma série de problemas, indicando a necessidade de mais testes e correções. Neste momento, existem duas implementações do EIP-2537 no sistema Geth, uma contendo otimizações em assembly e a outra totalmente escrita em Go. Um desenvolvedor sugeriu usar diretamente a versão em Go para reduzir a dificuldade de revisão do código.
Na 89ª reunião, surgiram problemas mais graves, com a rede de testes YOLO apresentando algumas anomalias. Os desenvolvedores suspeitam que seja causado 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á praticamente concluído e está aguardando auditoria.
A 90ª reunião estabeleceu o prazo final para o lançamento da atualização Berlin em julho. A reunião também discutiu a questão da diversidade de clientes, principalmente relacionada à situação dominante do Geth, com desenvolvedores sugerindo congelar a implementação atual do EIP para reduzir o custo de desenvolvimento de outros clientes. Na 91ª reunião, um desenvolvedor propôs usar uma solução modular para reduzir os custos de desenvolvimento e aumentar a diversidade de clientes.
A 92ª reunião ainda confirmou o EIP-2537 como o EIP necessário para a atualização de Berlim.
Na 96ª reunião, como a Celo incorporou simultaneamente o EIP-2537 e o EIP-2539 em seu hard fork de rede, a Matter Labs deseja que o EIP-2539 também seja colocado em teste no YOLO v2 e entre na atualização Berlin. No entanto, os desenvolvedores do Geth se opuseram, afirmando que o EIP-2537 ainda não foi testado completamente no Geth. A decisão final da reunião foi não adicionar o EIP-2696 na atualização Berlin, deixando para discussão futura.
A 99ª reunião decidiu remover o EIP-2537 da rede de testes YOLO v3 e da atualização Berlin. A principal razão é que o EIP-2537 consumiu muito tempo dos desenvolvedores principais, o que impediu o desenvolvimento de outros EIPs para a atualização Berlin. Um fator secundário é que a Fundação Ethereum propôs o EVM384 como substituto do EIP-2537, oferecendo uma solução de cálculo de curvas elípticas mais genérica. No entanto, os desenvolvedores principais expressaram preocupações em relação à segurança.
Esta é a trajetória inicial do EIP-2537. Podemos ver que o EIP-2537 foi inicialmente um dos EIPs mais importantes na atualização Berlin, mas acabou sendo abandonado devido a problemas de implementação. Em abril de 2021, o Ethereum completou a atualização Berlin, e o EIP central como o EIP-2565 na verdade não é complicado de implementar, a atualização parece um pouco magra, exatamente porque o EIP-2537, que é o mais complexo, foi eliminado.
Desenvolvimento futuro
É de conhecimento geral que cada atualização do Ethereum traz uma proposta central. A atualização de Londres, após Berlim, introduziu a proposta de taxas de transação mais importante da história do Ethereum, EIP-1559. Para a antiga proposta central EIP-2537, é difícil que futuras atualizações a incluam novamente.
A atualização de Londres após Berlim está em andamento, e os desenvolvedores estão considerando adicionar EIP-2537 no issues#369. A 109ª reunião dos desenvolvedores principais sincronizou o estado de desenvolvimento do EIP-2537, e devido à utilização de outras bibliotecas, houve discussões sobre o uso de gas. Um desenvolvedor propôs substituir EIP-2537 por EVM384. No entanto, na 111ª reunião em abril de 2021, o EIP-2537 foi removido da atualização de Londres devido à sua complexidade. A principal razão é que a implementação padrão do EIP-2537 trocou as bibliotecas de dependência, o que pode levar a mudanças na precificação do gas, e diferentes implementações de clientes exigem muito tempo para reavaliar o consumo de gas.
Em junho de 2021, a issues#343 propôs oficialmente a inclusão do EIP-2537 na atualização Shanghai. No entanto, após a atualização de Londres, o The Merge ocupou muito tempo dos desenvolvedores, que precisaram escrever uma grande quantidade de código para implementar a atualização PoS. Em setembro de 2022, após a conclusão do The Merge, os desenvolvedores da camada de execução finalmente tiveram a oportunidade de continuar discutindo os objetivos da atualização Shanghai.
Em novembro de 2022, na 150ª reunião dos desenvolvedores principais, foi discutido de forma resumida se o EIP-2537 deveria ser incluído no Shanghai, mas os desenvolvedores acharam que deveria ser adiado, pois o foco do Shanghai é o suporte para retiradas de PoS. No final, o EIP-2537 não foi incluído na atualização do Shanghai, que tem como núcleo a retirada.
Mais infelizes, a atualização Cancun não discutiu o EIP-2537, pois o foco de Cancun é suportar o EIP-4844, fornecendo Blobs para a camada 2 do Ethereum para que a camada 2 utilize o Ethereum como camada de disponibilidade de dados.
Até a 181ª reunião de desenvolvedores principais em fevereiro de 2024, os desenvolvedores só discutiram a inclusão do EIP-2537 na atualização Pectra. Neste momento, os desenvolvedores acreditavam que a implementação do EIP-2537 já não era um problema, apenas algumas questões de precificação do consumo de gás precisavam ser resolvidas.
Na 202ª reunião, realizada a 19 de dezembro de 2024, os desenvolvedores da Nethermind finalizaram o modelo de precificação do EIP-2537. Vale a pena notar que, como proponente original do EIP-2537, a Matter Labs já havia praticamente se retirado da discussão. A 203ª reunião, em janeiro de 2025, discutiu a redefinição do preço da pré-compilação BLS, e o desenvolvedor do Geth, Jared Wasinger, sugeriu aumentar o custo de gás em 20%, recebendo apoio da equipe do Besu em testes de referência.
Resumo
EIP-2537 passou por um longo e tortuoso processo desde a sua proposta até a sua adoção final: