EIP-2537 é a instrução de pré-compilação EVM que foi determinada para ser adicionada na mais recente atualização do fork Pectra. Esta instrução adiciona várias funcionalidades de cálculo da curva BLS12-381 ao EVM, como o cálculo de emparelhamento no domínio da curva.
EIP-2573 foi proposto pela primeira vez em 2020 e só foi confirmado para inclusão na atualização do Ethereum em 2025. Este artigo aborda a história da governança do EIP-2537 e investiga por que levou 5 anos para que esta proposta fosse incluída na atualização.
Contexto da Proposta
Em janeiro de 2017, Vitalik Buterin apresentou 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 era adicionar suporte ao cálculo da curva alt_bn128 na EVM.
Na atualização Byzantium em outubro de 2017, a curva alt_bn128 foi oficialmente incorporada. Simplificando, alt_bn128 implementou pela primeira vez o cálculo de pares de domínio de curva internamente no EVM, permitindo que a verificação de prova ZK-Snarks fosse realizada dentro do 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 BLS12-381: New zk-SNARK Elliptic Curve Construction. Em comparação com alt_bn128, a BLS12-381 possui maior segurança e melhor desempenho. Um número considerável de protocolos de blockchain passou a usar a curva BLS12-381 e abandonou a curva alt_bn128.
Em maio de 2018, Justin Drake publicou no ethresear o artigo "Agregação de assinaturas pragmática com BLS", apontando que as futuras atualizações de PoS e sharding do Ethereum poderiam utilizar o algoritmo de múltiplas assinaturas BLS baseado na curva BLS12-381. Naquela época, os pesquisadores do Ethereum esperavam resolver os problemas da camada de consenso com o EIP-1011, mas o plano do EIP-1011 poderia acomodar no máximo 900 validadores, estabelecendo um enorme tamanho de staking de 1500 ETH para cada validador. Com a proposta do esquema de múltiplas assinaturas BLS, o EIP-1011 saiu de cena. Comprovou-se que as atualizações posteriores do ETH2 também acabaram utilizando a curva BLS12-381.
Com o desenvolvimento do ETH2, o BLS12-381 utilizado pelo ETH2 começou a ser solicitado para a camada de execução do ETH. Em fevereiro de 2020, alguns pesquisadores propuseram o EIP-2537, esperando que essa proposta pudesse ser testada junto à testnet do ETH2. O autor do EIP-2537, Alex Stokes, fez um apelo no artigo What eth2 needs from eth1 over the next six months para incluir o EIP-2537 no hard fork de Berlim.
Curiosamente, o autor do EIP-2537 é também co-fundador da Matter Labs, e o produto mais famoso da Matter Labs é o ZKSync.
Berlim turbulento
Antes de apresentar o conteúdo subsequente, precisamos primeiro apresentar o EIP-1962. O EIP-1962 é a primeira proposta sobre pré-compilação de emparelhamentos de domínio de curvas elípticas apresentada pela Matter Labs em abril de 2019, que suporta três curvas, que são:
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 desta proposta, um número considerável de desenvolvedores questionou se a proposta era demasiado complexa para que os desenvolvedores a implementassem. Além disso, devido à alta generalização do EIP-1962, a chamada também é bastante complicada para os engenheiros de contratos inteligentes. Claro, como proponentes 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árias divisões do EIP-1962, que herdaram parcialmente a interface do EIP-1962. Esses EIPs incluem:
EIP-2537 fornece suporte para BLS12-381
EIP-2539 oferece suporte a BLS12-377
O PR#2541 fornece suporte (Zexe curve) BLS12-377, mas observe que a proposta não recebeu um número EIP e não pode ser encontrada no site oficial do documento EIP
Entre esses EIPs, o mais importante é o EIP-2537, pois o nível de consenso também utiliza a curva BLS12-381. O objetivo central do EIP-1962 e do EIP-2537 é implementar a verificação de assinaturas BLS no nível de consenso da rede principal. Na época, o ETH2 estava desenvolvendo o design do contrato de depósito para o nível de consenso. No design inicial do contrato de depósito, como o nível 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 pelo nível de consenso após o depósito do usuário. Se fosse encontrada incorreta (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 possíveis perdas dos usuários ao depositar fundos ETH2. Esta também foi a razão pela qual muitos desenvolvedores estavam focados nas EIP-1962 e EIP-2537 na época.
Quando o EIP-2537 foi proposto, Vitalik imediatamente identificou uma série de problemas existentes no EIP:
Essas dúvidas concentram-se apenas no conteúdo da documentação do EIP, ao qual os autores do EIP responderam e discutiram. Em seguida, no dia 6 de março de 2020, durante a reunião #82 dos desenvolvedores principais do Ethereum, os desenvolvedores principais do Ethereum discutiram o EIP-2537. Nessa reunião, Vitalik acreditou que EIPs como o EIP-2537 são muito eficazes para provas SNARK recursivas e que, a longo prazo, não prejudicariam o Ethereum. Além disso, a reunião também confirmou a prioridade do EIP-2537, e todos os clientes concordaram em implementar o EIP-2537 o mais rapidamente possível, planejando concluir todo o desenvolvimento antes da atualização de Berlin.
Subsequentemente, o EIP-2537 tornou-se uma tarefa de alta prioridade. Em 20 de março de 2020, na Ethereum Core Devs Meeting #83, o EIP-2537 continuou a ser a proposta discutida em primeiro lugar. Esta reunião confirmou que o EIP-2537 substituiria o EIP-1962 como a proposta central de BLS e faria parte da lista pré-selecionada de EIPs para a atualização de Berlim ( ou Eligibility for Inclusion ( EFI ) ).
Na reunião dos Desenvolvedores Principais do Ethereum #84, em abril de 2020, foi oficialmente incluído o EIP-2537 na atualização do hard fork Berlin, e foi estabelecido o cronograma para a implementação em abril e testes em maio e junho. Vale a pena notar que, nesta discussão, o EIP-2537 foi listado como a prioridade máxima.
Em seguida, o EIP-2537 entrou em uma ampla fase de desenvolvimento e testes, e nas quase 20 reuniões de desenvolvedores principais que se sucederam, cada reunião basicamente abordou discussões sobre o EIP-2537. A seguir, podemos ver quais questões relacionadas ao 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 praticamente concluído a implementação da versão em Rust, o cliente Besu declarou que já havia implementado praticamente todas as funcionalidades do EIP-2537. No entanto, a equipe do Geth afirmou que neste momento ninguém estava trabalhando na implementação do EIP-2537.
Na reunião dos desenvolvedores principais do Ethereum #86, diferentes implementações de nós do Ethereum sincronizaram novamente o status da implementação do EIP-2537, onde o Geth indicou que completou parte do trabalho, mas ainda há uma grande quantidade de trabalho a ser feita.
Na reunião dos desenvolvedores do Ethereum Core Devs Meeting #87, o conteúdo mais central desta reunião de desenvolvedores é a questão da implementação do EIP-2537. O desenvolvedor do Geth afirmou que atualmente existe um PR de 16000 linhas implementando o EIP-2537, mas os desenvolvedores do Geth não conseguem determinar se o PR implementou o EIP-2537 de forma segura e eficaz, então os desenvolvedores só podem avaliar a situação do código por meio de testes de fuzzing mais simples e diretos.
Os desenvolvedores do Geth disseram: "Então, minha reação instintiva é que não há chance de que o Geth esteja pronto com as operações da 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 encontrar engenheiros de criptografia para ajudar na revisão de PR do Geth, e sugeriu usar uma 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, 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 usa uma quantidade significativa de código em assembly para garantir eficiência, e essa parte do código em assembly é muito difícil de ler e entender. Portanto, Alex Vlasov sugeriu remover as otimizações complexas em assembly internas do PR para reduzir a dificuldade de revisão.
Já mencionamos anteriormente que um dos objetivos centrais do EIP-2537 é auxiliar o contrato de depósito do ETH2, mas nesta reunião, os desenvolvedores do contrato de depósito afirmaram que o contrato de depósito que não utiliza o EIP-2537 já foi auditado, então 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 adicionar a rede de testes YOLO, cujo núcleo é testar o EIP-2537. De fato, nesta reunião, 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 este EIP não seja implementado antes da atualização de Berlin. Parece que a não aceitação do EIP-2537 na atualização de Berlin já é uma certeza.
Na reunião dos desenvolvedores principais do Ethereum #88, os desenvolvedores do Geth descobriram uma série de problemas na PR de implementação do EIP-2537, e os desenvolvedores afirmaram que mais testes e correções são necessários. Neste momento, existem duas implementações do EIP-2537 no sistema Geth, sendo que uma delas inclui otimizações em assembly, enquanto a outra é totalmente escrita na linguagem 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, surgiu um problema mais grave, o teste YOLO apresentou alguns problemas, os desenvolvedores suspeitam que seja um problema causado pela assinatura BLS, mas os desenvolvedores do EIP2537 refutaram isso, afirmando que o problema da rede de testes não é causado pela assinatura BLS. A boa notícia sobre o EIP-2537 é que o contrato de depósito baseado no EIP-2537 está basicamente concluído, e o contrato está aguardando auditoria.
Na reunião dos desenvolvedores principais do Ethereum #90内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91, um desenvolvedor propôs utilizar uma solução modular para reduzir os custos de desenvolvimento e aumentar a diversidade de clientes. Se os leitores estiverem interessados na diversidade de clientes do Ethereum, podem ler os registros dessas duas reuniões.
Na reunião dos desenvolvedores principais do Ethereum #92, o EIP 2537 ainda é confirmado como necessário para a atualização Berlin.
Na reunião dos desenvolvedores principais do Ethereum #96, a Celo já integrou EIP-2537 e EIP-2539 em sua atualização de hard fork, portanto, a Matter Labs espera que o EIP-2539, proposto simultaneamente com o EIP-2537, também seja testado na rede de teste YOLO v2 e entre na atualização Berlin. No entanto, os desenvolvedores do Geth se opuseram, argumentando que o EIP-2537 ainda não foi testado completamente internamente no Geth. No final, a reunião decidiu não incluir o 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 razão mais central para isso é que o EIP-2537 desperdiçou 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 curvas elípticas 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 na 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, e as implementações reais dos EIPs centrais, como o EIP-2565, não eram muito complexas. Parece que a atualização de Berlin foi um pouco magra, pois o EIP-2537, que era o mais complexo, foi removido da atualização de Berlin.
desenvolvimento futuro
É bem conhecido que cada atualização do Ethereum tem uma proposta central, como a atualização de Londres após a atualização de Berlim, que introduziu a proposta de taxa de transação mais importante da história do Ethereum, EIP-1559. Para o EIP-2537, que já foi uma proposta central, as atualizações subsequentes têm dificuldade em incluir essa proposta.
Na atualização pós-Berlim de Londres, os desenvolvedores sincronizaram o desenvolvimento atual do EIP-2537 no issues#369曾考虑在 London 升级中增加 EIP-2537。在Ethereum Core Devs Meeting #109, e neste momento introduziram uma discussão sobre o uso de gás para EIP-2537 devido ao uso de outras bibliotecas para implementar o EIP-2537. Ao mesmo tempo, alguns desenvolvedores propuseram substituir o EIP-2537 pelo EVM384. No entanto, #111内 o Ethereum Core Devs Meeting em abril de 2021, o EIP-2537 foi removido da atualização de Londres devido à complexidade. A complexidade central reside na substituição de bibliotecas dependentes pela implementação do padrão EIP-2537, o que leva a possíveis mudanças nos preços do gás e a um tempo considerável para diferentes implementações de clientes reavaliarem o consumo de gás.
Em junho de 2021, foi oficialmente proposto no issues#343 a inclusão do EIP-2537 na atualização de Shanghai. No entanto, é importante notar que, após a atualização de Londres, na verdade a atualização Pairs, também conhecida como 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, a atualização Pairs foi concluída, e os desenvolvedores da camada de execução finalmente tiveram a oportunidade de continuar discutindo alguns dos objetivos da atualização de Shanghai.
Em novembro de 2022, na reunião dos desenvolvedores principais do Ethereum #150, houve uma breve discussão sobre a inclusão do EIP-2537 na atualização de Shanghai, mas os desenvolvedores acharam que o EIP-2537 precisava ser adiado, pois o foco da atualização de Shanghai era suportar saques de PoS. No final, o EIP-2537 não foi incluído na atualização de Shanghai, que tem como núcleo a funcionalidade de saques.
Mais trágico é que a atualização Cancun nunca discutiu o EIP-2537, pois o núcleo da atualização Cancun é o suporte ao EIP-4844 pelos nós da camada de execução. O EIP-4844 fornece blobs para a segunda camada do Ethereum para facilitar 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 do Pectra, e neste momento os desenvolvedores acreditavam que a implementação do EIP-2537 já não era um problema, apenas algumas questões relacionadas à precificaçã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%, com o apoio dos testes de referência da equipe Besu.
Resumo
| Data | Evento |
| --- | --- |
| Fevereiro de 2020 | Proposta formal da EIP-1962 e EIP-2537 |
| Abril de 2020 - Outubro de 2020 | A conferência de desenvolvedores discutiu várias vezes os problemas de implementação do EIP-2537, e acabou sendo abandonado pela atualização de Berlim devido à impossibilidade de implementação |
| Março de 2021 - Abril de 2021 | Discussão na reunião de desenvolvedores sobre o problema dos custos de gás EIP-2537, que foi abandonado na atualização de Londres devido à complexidade |
| Novembro de 2022 | Reunião de desenvolvedores discutiu a inclusão da atualização Shanghai, sem resultado |
| Fevereiro de 2024 | Os desenvolvedores acreditam que o EIP-2537 não apresenta problemas de implementação, mas ainda existem algumas questões de custo de gas, acreditando que pode ser incluído na atualização Pectra |
| Dezembro de 2024 - Janeiro de 2025 | Reunião de desenvolvedores para discutir modelos de cálculo de custos específicos, resolvendo formalmente o problema de custos do EIP-2537 |
É evidente que a inclusão do EIP nas atualizações do Ethereum "depende, claro, do esforço pessoal, mas também deve levar em conta o percurso histórico". Cada atualização do Ethereum tem seu próprio tema, assim como o EIP-2537 se tornou um dos EIPs mais importantes da atualização Berlin, mas foi descartado devido à sua dificuldade e complexidade de implementação. As subsequentes atualizações do Ethereum entraram no processo histórico de PoS, com EIPs complexos de camada de execução pura não recebendo atenção, enquanto muitos EIPs de execução relacionados ao PoS foram considerados como objetivos centrais de atualização, o que levou à 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.
Observação da Governança do Ethereum: O Processo de Pré-Compilação do EIP-2537
Autor: shew
Resumo
EIP-2537 é a instrução de pré-compilação EVM que foi determinada para ser adicionada na mais recente atualização do fork Pectra. Esta instrução adiciona várias funcionalidades de cálculo da curva BLS12-381 ao EVM, como o cálculo de emparelhamento no domínio da curva.
EIP-2573 foi proposto pela primeira vez em 2020 e só foi confirmado para inclusão na atualização do Ethereum em 2025. Este artigo aborda a história da governança do EIP-2537 e investiga por que levou 5 anos para que esta proposta fosse incluída na atualização.
Contexto da Proposta
Em janeiro de 2017, Vitalik Buterin apresentou o algoritmo de emparelhamento e a curva
alt_bn128em 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 era adicionar suporte ao cálculo da curvaalt_bn128na EVM.Na atualização Byzantium em outubro de 2017, a curva
alt_bn128foi oficialmente incorporada. Simplificando,alt_bn128implementou pela primeira vez o cálculo de pares de domínio de curva internamente no EVM, permitindo que a verificação de prova ZK-Snarks fosse realizada dentro do EVM.Mas com o desenvolvimento da criptografia, em novembro de 2017, a equipe de desenvolvimento do zcash apresentou pela primeira vez a curva
BLS12-381no BLS12-381: New zk-SNARK Elliptic Curve Construction. Em comparação comalt_bn128, aBLS12-381possui maior segurança e melhor desempenho. Um número considerável de protocolos de blockchain passou a usar a curvaBLS12-381e abandonou a curvaalt_bn128.Em maio de 2018, Justin Drake publicou no ethresear o artigo "Agregação de assinaturas pragmática com BLS", apontando que as futuras atualizações de PoS e sharding do Ethereum poderiam utilizar o algoritmo de múltiplas assinaturas BLS baseado na curva
BLS12-381. Naquela época, os pesquisadores do Ethereum esperavam resolver os problemas da camada de consenso com o EIP-1011, mas o plano do EIP-1011 poderia acomodar no máximo 900 validadores, estabelecendo um enorme tamanho de staking de 1500 ETH para cada validador. Com a proposta do esquema de múltiplas assinaturas BLS, o EIP-1011 saiu de cena. Comprovou-se que as atualizações posteriores do ETH2 também acabaram utilizando a curvaBLS12-381.Com o desenvolvimento do ETH2, o
BLS12-381utilizado pelo ETH2 começou a ser solicitado para a camada de execução do ETH. Em fevereiro de 2020, alguns pesquisadores propuseram o EIP-2537, esperando que essa proposta pudesse ser testada junto à testnet do ETH2. O autor do EIP-2537, Alex Stokes, fez um apelo no artigo What eth2 needs from eth1 over the next six months para incluir o EIP-2537 no hard fork de Berlim.Curiosamente, o autor do EIP-2537 é também co-fundador da Matter Labs, e o produto mais famoso da Matter Labs é o ZKSync.
Berlim turbulento
Antes de apresentar o conteúdo subsequente, precisamos primeiro apresentar o EIP-1962. O EIP-1962 é a primeira proposta sobre pré-compilação de emparelhamentos de domínio de curvas elípticas apresentada pela Matter Labs em abril de 2019, que suporta três curvas, que são:
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 desta proposta, um número considerável de desenvolvedores questionou se a proposta era demasiado complexa para que os desenvolvedores a implementassem. Além disso, devido à alta generalização do EIP-1962, a chamada também é bastante complicada para os engenheiros de contratos inteligentes. Claro, como proponentes 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árias divisões do EIP-1962, que herdaram parcialmente a interface do EIP-1962. Esses EIPs incluem:
Entre esses EIPs, o mais importante é o EIP-2537, pois o nível de consenso também utiliza a curva BLS12-381. O objetivo central do EIP-1962 e do EIP-2537 é implementar a verificação de assinaturas BLS no nível de consenso da rede principal. Na época, o ETH2 estava desenvolvendo o design do contrato de depósito para o nível de consenso. No design inicial do contrato de depósito, como o nível 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 pelo nível de consenso após o depósito do usuário. Se fosse encontrada incorreta (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 possíveis perdas dos usuários ao depositar fundos ETH2. Esta também foi a razão pela qual muitos desenvolvedores estavam focados nas EIP-1962 e EIP-2537 na época.
Quando o EIP-2537 foi proposto, Vitalik imediatamente identificou uma série de problemas existentes no EIP:
Essas dúvidas concentram-se apenas no conteúdo da documentação do EIP, ao qual os autores do EIP responderam e discutiram. Em seguida, no dia 6 de março de 2020, durante a reunião #82 dos desenvolvedores principais do Ethereum, os desenvolvedores principais do Ethereum discutiram o EIP-2537. Nessa reunião, Vitalik acreditou que EIPs como o EIP-2537 são muito eficazes para provas SNARK recursivas e que, a longo prazo, não prejudicariam o Ethereum. Além disso, a reunião também confirmou a prioridade do EIP-2537, e todos os clientes concordaram em implementar o EIP-2537 o mais rapidamente possível, planejando concluir todo o desenvolvimento antes da atualização de Berlin.
Subsequentemente, o EIP-2537 tornou-se uma tarefa de alta prioridade. Em 20 de março de 2020, na Ethereum Core Devs Meeting #83, o EIP-2537 continuou a ser a proposta discutida em primeiro lugar. Esta reunião confirmou que o EIP-2537 substituiria o EIP-1962 como a proposta central de BLS e faria parte da lista pré-selecionada de EIPs para a atualização de Berlim ( ou Eligibility for Inclusion ( EFI ) ).
Na reunião dos Desenvolvedores Principais do Ethereum #84, em abril de 2020, foi oficialmente incluído o EIP-2537 na atualização do hard fork Berlin, e foi estabelecido o cronograma para a implementação em abril e testes em maio e junho. Vale a pena notar que, nesta discussão, o EIP-2537 foi listado como a prioridade máxima.
Em seguida, o EIP-2537 entrou em uma ampla fase de desenvolvimento e testes, e nas quase 20 reuniões de desenvolvedores principais que se sucederam, cada reunião basicamente abordou discussões sobre o EIP-2537. A seguir, podemos ver quais questões relacionadas ao 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 praticamente concluído a implementação da versão em Rust, o cliente Besu declarou que já havia implementado praticamente todas as funcionalidades do EIP-2537. No entanto, a equipe do Geth afirmou que neste momento ninguém estava trabalhando na implementação do EIP-2537.
Na reunião dos desenvolvedores principais do Ethereum #86, diferentes implementações de nós do Ethereum sincronizaram novamente o status da implementação do EIP-2537, onde o Geth indicou que completou parte do trabalho, mas ainda há uma grande quantidade de trabalho a ser feita.
Na reunião dos desenvolvedores do Ethereum Core Devs Meeting #87, o conteúdo mais central desta reunião de desenvolvedores é a questão da implementação do EIP-2537. O desenvolvedor do Geth afirmou que atualmente existe um PR de 16000 linhas implementando o EIP-2537, mas os desenvolvedores do Geth não conseguem determinar se o PR implementou o EIP-2537 de forma segura e eficaz, então os desenvolvedores só podem avaliar a situação do código por meio de testes de fuzzing mais simples e diretos.
Os desenvolvedores do Geth disseram: "Então, minha reação instintiva é que não há chance de que o Geth esteja pronto com as operações da 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 encontrar engenheiros de criptografia para ajudar na revisão de PR do Geth, e sugeriu usar uma 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, 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 usa uma quantidade significativa de código em assembly para garantir eficiência, e essa parte do código em assembly é muito difícil de ler e entender. Portanto, Alex Vlasov sugeriu remover as otimizações complexas em assembly internas do PR para reduzir a dificuldade de revisão.
Já mencionamos anteriormente que um dos objetivos centrais do EIP-2537 é auxiliar o contrato de depósito do ETH2, mas nesta reunião, os desenvolvedores do contrato de depósito afirmaram que o contrato de depósito que não utiliza o EIP-2537 já foi auditado, então 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 adicionar a rede de testes YOLO, cujo núcleo é testar o EIP-2537. De fato, nesta reunião, 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 este EIP não seja implementado antes da atualização de Berlin. Parece que a não aceitação do EIP-2537 na atualização de Berlin já é uma certeza.
Na reunião dos desenvolvedores principais do Ethereum #88, os desenvolvedores do Geth descobriram uma série de problemas na PR de implementação do EIP-2537, e os desenvolvedores afirmaram que mais testes e correções são necessários. Neste momento, existem duas implementações do EIP-2537 no sistema Geth, sendo que uma delas inclui otimizações em assembly, enquanto a outra é totalmente escrita na linguagem 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, surgiu um problema mais grave, o teste YOLO apresentou alguns problemas, os desenvolvedores suspeitam que seja um problema causado pela assinatura BLS, mas os desenvolvedores do EIP2537 refutaram isso, afirmando que o problema da rede de testes não é causado pela assinatura BLS. A boa notícia sobre o EIP-2537 é que o contrato de depósito baseado no EIP-2537 está basicamente concluído, e o contrato está aguardando auditoria.
Na reunião dos desenvolvedores principais do Ethereum #90内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91, um desenvolvedor propôs utilizar uma solução modular para reduzir os custos de desenvolvimento e aumentar a diversidade de clientes. Se os leitores estiverem interessados na diversidade de clientes do Ethereum, podem ler os registros dessas duas reuniões.
Na reunião dos desenvolvedores principais do Ethereum #92, o EIP 2537 ainda é confirmado como necessário para a atualização Berlin.
Na reunião dos desenvolvedores principais do Ethereum #96, a Celo já integrou EIP-2537 e EIP-2539 em sua atualização de hard fork, portanto, a Matter Labs espera que o EIP-2539, proposto simultaneamente com o EIP-2537, também seja testado na rede de teste YOLO v2 e entre na atualização Berlin. No entanto, os desenvolvedores do Geth se opuseram, argumentando que o EIP-2537 ainda não foi testado completamente internamente no Geth. No final, a reunião decidiu não incluir o 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 razão mais central para isso é que o EIP-2537 desperdiçou 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 curvas elípticas 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 na 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, e as implementações reais dos EIPs centrais, como o EIP-2565, não eram muito complexas. Parece que a atualização de Berlin foi um pouco magra, pois o EIP-2537, que era o mais complexo, foi removido da atualização de Berlin.
desenvolvimento futuro
É bem conhecido que cada atualização do Ethereum tem uma proposta central, como a atualização de Londres após a atualização de Berlim, que introduziu a proposta de taxa de transação mais importante da história do Ethereum, EIP-1559. Para o EIP-2537, que já foi uma proposta central, as atualizações subsequentes têm dificuldade em incluir essa proposta.
Na atualização pós-Berlim de Londres, os desenvolvedores sincronizaram o desenvolvimento atual do EIP-2537 no issues#369曾考虑在 London 升级中增加 EIP-2537。在Ethereum Core Devs Meeting #109, e neste momento introduziram uma discussão sobre o uso de gás para EIP-2537 devido ao uso de outras bibliotecas para implementar o EIP-2537. Ao mesmo tempo, alguns desenvolvedores propuseram substituir o EIP-2537 pelo EVM384. No entanto, #111内 o Ethereum Core Devs Meeting em abril de 2021, o EIP-2537 foi removido da atualização de Londres devido à complexidade. A complexidade central reside na substituição de bibliotecas dependentes pela implementação do padrão EIP-2537, o que leva a possíveis mudanças nos preços do gás e a um tempo considerável para diferentes implementações de clientes reavaliarem o consumo de gás.
Em junho de 2021, foi oficialmente proposto no issues#343 a inclusão do EIP-2537 na atualização de Shanghai. No entanto, é importante notar que, após a atualização de Londres, na verdade a atualização Pairs, também conhecida como 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, a atualização Pairs foi concluída, e os desenvolvedores da camada de execução finalmente tiveram a oportunidade de continuar discutindo alguns dos objetivos da atualização de Shanghai.
Em novembro de 2022, na reunião dos desenvolvedores principais do Ethereum #150, houve uma breve discussão sobre a inclusão do EIP-2537 na atualização de Shanghai, mas os desenvolvedores acharam que o EIP-2537 precisava ser adiado, pois o foco da atualização de Shanghai era suportar saques de PoS. No final, o EIP-2537 não foi incluído na atualização de Shanghai, que tem como núcleo a funcionalidade de saques.
Mais trágico é que a atualização Cancun nunca discutiu o EIP-2537, pois o núcleo da atualização Cancun é o suporte ao EIP-4844 pelos nós da camada de execução. O EIP-4844 fornece blobs para a segunda camada do Ethereum para facilitar 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 do Pectra, e neste momento os desenvolvedores acreditavam que a implementação do EIP-2537 já não era um problema, apenas algumas questões relacionadas à precificaçã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%, com o apoio dos testes de referência da equipe Besu.
Resumo
| Data | Evento | | --- | --- | | Fevereiro de 2020 | Proposta formal da EIP-1962 e EIP-2537 | | Abril de 2020 - Outubro de 2020 | A conferência de desenvolvedores discutiu várias vezes os problemas de implementação do EIP-2537, e acabou sendo abandonado pela atualização de Berlim devido à impossibilidade de implementação | | Março de 2021 - Abril de 2021 | Discussão na reunião de desenvolvedores sobre o problema dos custos de gás EIP-2537, que foi abandonado na atualização de Londres devido à complexidade | | Novembro de 2022 | Reunião de desenvolvedores discutiu a inclusão da atualização Shanghai, sem resultado | | Fevereiro de 2024 | Os desenvolvedores acreditam que o EIP-2537 não apresenta problemas de implementação, mas ainda existem algumas questões de custo de gas, acreditando que pode ser incluído na atualização Pectra | | Dezembro de 2024 - Janeiro de 2025 | Reunião de desenvolvedores para discutir modelos de cálculo de custos específicos, resolvendo formalmente o problema de custos do EIP-2537 |
É evidente que a inclusão do EIP nas atualizações do Ethereum "depende, claro, do esforço pessoal, mas também deve levar em conta o percurso histórico". Cada atualização do Ethereum tem seu próprio tema, assim como o EIP-2537 se tornou um dos EIPs mais importantes da atualização Berlin, mas foi descartado devido à sua dificuldade e complexidade de implementação. As subsequentes atualizações do Ethereum entraram no processo histórico de PoS, com EIPs complexos de camada de execução pura não recebendo atenção, enquanto muitos EIPs de execução relacionados ao PoS foram considerados como objetivos centrais de atualização, o que levou à não aceitação do EIP-2537 por um longo período.