EIP-2537: O longo caminho para as instruções pré-compiladas BLS12-381 do Ethereum
EIP-2537 é a instrução pré-compilada EVM que foi adicionada na mais recente atualização do fork Pectra. Esta instrução adiciona várias funções de cálculo da curva BLS12-381 ao EVM, incluindo cálculos de emparelhamento no domínio da curva.
O 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 irá apresentar o histórico de governança do EIP-2537, explorando por que essa proposta levou 5 anos para ser finalmente incorporada à atualização.
Contexto da Proposta
Em janeiro de 2017, Vitalik Buterin apresentou pela primeira vez o algoritmo de pares e a curva alt_bn128. Em seguida, Vitalik e Christian Reitwiessner propuseram a EIP-196 e a EIP-197, para adicionar suporte ao cálculo da curva alt_bn128 na EVM. Essas propostas foram oficialmente adotadas na atualização Byzantium em outubro de 2017, implementando o cálculo de pares de domínio de curva dentro da EVM, permitindo que a verificação de provas ZK-Snarks fosse feita dentro da EVM.
Com o desenvolvimento da criptografia, a equipe do zcash propôs a curva BLS12-381 em novembro de 2017. Em comparação com a alt_bn128, a BLS12-381 possui maior segurança e melhor desempenho. Muitos protocolos de blockchain começaram a usar a curva BLS12-381 em vez da curva alt_bn128.
Em maio de 2018, Justin Drake apontou que as futuras atualizações de PoS e sharding do Ethereum poderiam usar um algoritmo de múltiplas assinaturas BLS baseado na curva BLS12-381. Isso fez com que o plano original EIP-1011 saísse do palco histórico. De fato, a atualização posterior do ETH2 adotou a curva BLS12-381.
Com o desenvolvimento do ETH2, a demanda por introduzir BLS12-381 na camada de execução do ETH está crescendo. Em fevereiro de 2020, pesquisadores propuseram o EIP-2537, esperando que essa proposta pudesse ser testada juntamente com a rede de testes ETH2. O autor do EIP-2537, Alex Stokes, apelou para que o EIP-2537 fosse incluído na hard fork de Berlin.
Vale a pena mencionar que o autor do EIP-2537 é também cofundador da Matter Labs, desenvolvedora do ZKSync.
As dificuldades da atualização de Berlim
Antes de introduzir o conteúdo subsequente, precisamos primeiro entender o EIP-1962. Esta é a primeira proposta sobre pré-compilações de emparelhamento de domínio de curva elíptica apresentada pela Matter Labs em abril de 2019, suportando três curvas: BLS12, BN e MNT4/6.
O EIP-1962 planeia adicionar 10 instruções pré-compiladas de uma só vez para lidar com diferentes curvas. No entanto, a proposta é demasiado complexa, tornando difícil a sua implementação pelos desenvolvedores. Além disso, devido à sua alta generalização, é também complicado para os engenheiros de contratos inteligentes chamá-las. No entanto, a Matter Labs já completou o desenvolvimento do algoritmo de curva elíptica e fornece 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 a divisão de vários EIPs a partir do EIP-1962, alguns dos quais herdaram sua interface. Esses EIPs incluem:
EIP-2537: fornece suporte a BLS12-381
EIP-2539: suporte a BLS12-377
PR#2541: Fornecer suporte à curva BLS12-377 (Zexe), mas não obteve número EIP
Entre eles, o EIP-2537 é o mais importante, pois a camada de consenso também utiliza a curva BLS12-381. O objetivo principal do EIP-1962 e do EIP-2537 é implementar a verificação de assinatura BLS na camada de consenso na mainnet. Na época, o ETH2 estava a desenhar o contrato de depósito, e como a camada de execução não tinha um algoritmo de verificação BLS, o contrato de depósito não verificaria as assinaturas; a verificação específica da assinatura BLS seria feita pela camada de consenso após o depósito do usuário, e se fosse encontrada uma irregularidade, isso poderia levar à perda de fundos do usuário.
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 de fundos ETH2 para os usuários. Esta foi a razão pela qual muitos desenvolvedores estavam atentos ao EIP-1962 e ao EIP-2537 na época.
Após a proposta do EIP-2537, Vitalik imediatamente apontou uma série de problemas, concentrando-se principalmente no conteúdo do documento EIP. Os autores do EIP responderam e discutiram em seguida. Na reunião de desenvolvedores principais de 6 de março de 2020, Vitalik acreditava que o EIP-2537 e outros EIPs eram muito eficazes para a prova SNARK recursiva e, a longo prazo, não prejudicariam o Ethereum. A reunião confirmou a prioridade do EIP-2537, e todos os clientes concordaram em implementá-lo o mais rápido possível, planejando concluir o desenvolvimento antes da atualização de Berlin.
Após isso, o EIP-2537 tornou-se uma tarefa de alta prioridade. A reunião de 20 de março confirmou que o EIP-2537 substituiria o EIP-1962 como a proposta central de BLS e entraria na lista pré-selecionada para a atualização de Berlin. A reunião de abril oficialmente incorporou o EIP-2537 na atualização do hard fork de Berlin, estabelecendo o cronograma para implementação em abril e testes em maio-junho, e listou isso como a questão de mais alta prioridade.
Em seguida, o EIP-2537 entrou em uma fase intensa de desenvolvimento e testes, sendo discutido em quase 20 reuniões de desenvolvedores principais subsequentes.
Na 85ª reunião, os desenvolvedores discutiram o problema de codificação ABI do EIP-2537. O cliente Besu afirmou que a funcionalidade está basicamente implementada, mas a equipe do Geth informou que ninguém iniciou trabalhos relacionados.
Na 86ª reunião, Geth afirmou que completou parte do trabalho, mas ainda há muito a ser feito.
A 87ª reunião concentrou-se na questão da implementação do EIP-2537. Os desenvolvedores do Geth afirmaram que existe um PR de 16.000 linhas implementando o EIP-2537, mas não é possível determinar sua segurança e eficácia, podendo apenas ser julgado por testes de fuzzing simples. Os desenvolvedores do Geth acreditam que não será possível concluir o desenvolvimento do EIP-2537 antes do prazo previsto para Berlim.
A reunião decidiu aumentar a rede de testes YOLO para testar especificamente o EIP-2537. Neste momento, a importância do EIP-2537 diminuiu significativamente, e os desenvolvedores do Geth acreditam que é muito provável que este EIP não seja incluído na atualização de Berlin.
Na 88ª reunião, os desenvolvedores do Geth descobriram que a implementação do PR do EIP-2537 apresentava uma série de problemas, necessitando de testes e correções adicionais. Existem duas implementações do EIP-2537 no sistema Geth, uma contendo otimizações de assembly, e a outra totalmente escrita em Go. Alguém sugeriu usar diretamente a versão em Go para reduzir a dificuldade da revisão do código.
Na 89ª reunião, surgiu um problema mais sério, a rede de testes YOLO apresentou anomalias, suspeitando-se que fosse causado pela assinatura BLS, mas os desenvolvedores do EIP-2537 negaram. A boa notícia é que o contrato de depósito baseado no EIP-2537 está praticamente concluído, aguardando auditoria.
A 90ª reunião fixou o prazo para o lançamento da atualização Berlin em julho. A reunião também discutiu a questão da predominância do Geth, com alguém a propor congelar a implementação atual do EIP para reduzir os custos de desenvolvimento de outros clientes.
A 92ª reunião ainda confirma o EIP-2537 como o EIP necessário para a atualização de Berlin.
Na 96ª reunião, a Matter Labs espera incluir o EIP-2539 nos testes do YOLO v2 e na atualização Berlin. No entanto, os desenvolvedores do Geth se opõem, acreditando que o EIP-2537 ainda não foi testado completamente no Geth. A decisão final é não adicionar o 2696 na atualização Berlin.
A 99ª reunião decidiu remover o EIP-2537 da rede de testes YOLO v3 e da atualização Berlin, sendo a principal razão o tempo excessivo que consumiu dos desenvolvedores principais, afetando o desenvolvimento de outros EIPs. Um fator secundário foi a proposta da Fundação Ethereum do EVM384 como alternativa.
Em abril de 2021, o Ethereum completou a atualização Berlin, cujo núcleo inclui implementações práticas como a EIP-2565, que não são muito complexas, tornando a atualização aparentemente magra, pois a EIP-2537, que é a mais complexa, foi removida.
Desenvolvimento futuro
A atualização de Londres após a atualização de Berlim introduziu o EIP-1559. Para o EIP-2537, que foi uma proposta central, é difícil que atualizações futuras o incluam.
A atualização de Londres está em andamento, os desenvolvedores consideraram adicionar o EIP-2537. A 109ª reunião sincronizou a situação de desenvolvimento do EIP-2537 e discutiu questões de uso de gás, onde alguém sugeriu substituir o EIP-2537 pelo EVM384. No entanto, a 111ª reunião retirou o EIP-2537 da atualização de Londres devido à complexidade. O principal motivo é que a implementação do padrão EIP-2537 trocou as bibliotecas de dependência, o que pode levar a mudanças na precificação do gás, e cada cliente precisa reavaliar o consumo de gás.
Em junho de 2021, foi oficialmente proposto incluir o EIP-2537 na atualização Shanghai. No entanto, a atualização Merge ocupou grande parte do tempo dos desenvolvedores. Após a conclusão do Merge em setembro de 2022, os desenvolvedores da camada de execução tiveram a oportunidade de continuar a discutir os objetivos da atualização Shanghai.
Em novembro de 2022, a 150ª reunião discutiu brevemente se o EIP-2537 deveria ser incluído na atualização Shanghai, mas concluiu que era necessário adiar. O núcleo da atualização Shanghai é o suporte para retiradas de PoS. No final, o EIP-2537 não foi incluído na atualização Shanghai, que tem como foco a funcionalidade de retirada.
A atualização do Cancun nunca discutiu o EIP-2537, pois seu núcleo é o suporte ao EIP-4844, que fornece uma camada de dados Blob disponível para a segunda camada.
Em fevereiro de 2024, a 181ª reunião discutiu a inclusão do EIP-2537 na atualização do Pectra, considerando que a implementação não é mais um problema, apenas a precificação do consumo de gas é um problema.
No dia 19 de dezembro de 2024, na 202ª reunião, os desenvolvedores da Nethermind determinaram o modelo de preços para o EIP-2537. O proponente inicial, a Matter Labs, já estava quase fora da discussão. Na 203ª reunião em janeiro de 2025, foi discutida a reavaliação da pré-compilação BLS, e os desenvolvedores do Geth sugeriram aumentar o custo de gás em 20%, recebendo o apoio da equipe do Besu para os testes de referência.
Resumo
O desenvolvimento do EIP-2537 pode ser resumido da seguinte forma:
Fevereiro de 2020: a divisão do EIP-1962 foi formalmente proposta no EIP-2537
Abril a Outubro de 2020: Várias discussões sobre problemas de implementação, finalmente abandonado devido à impossibilidade de implementação na atualização Berlin.
Março-Abril de 2021: Discussão sobre o problema dos custos de gas, que foi abandonado na atualização de Londres devido à complexidade.
Novembro de 2022: discussão sobre a inclusão da atualização Shanghai, sem sucesso
Fevereiro de 2024: acredita-se que não haverá problemas na implementação, ainda existem questões de custo de gas, pode ser incluído na atualização Pectra
Dezembro de 2024 a Janeiro de 2025: discutir o modelo de custos específico e resolver formalmente o problema de custos.
A inclusão do EIP na atualização do Ethereum depende tanto do esforço próprio quanto da consideração do processo histórico. Cada atualização tem um tema, e o EIP-2537 foi o núcleo da atualização de Berlin, mas foi abandonado devido à sua complexidade. Depois disso, o Ethereum focou no PoS, e os EIPs de camada de execução pura não receberam atenção, resultando na não aceitação prolongada do EIP-2537. Somente recentemente, os desenvolvedores começaram a se reatentar e resolver os problemas pendentes.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
25 Curtidas
Recompensa
25
8
Repostar
Compartilhar
Comentário
0/400
DefiPlaybook
· 08-12 22:17
Mais um projeto divino de 5 anos. Cadê o der?
Ver originalResponder0
LayerZeroHero
· 08-12 22:05
Cinco anos e ainda não foi lançada a Rede principal. O que está demorando?
Ver originalResponder0
SchrodingerAirdrop
· 08-12 19:46
O que há de errado em andar mais devagar? Uma atualização estável não é melhor do que gritar por velocidade.
Ver originalResponder0
UncleLiquidation
· 08-09 22:46
Cinco anos para começar, o ritmo de desenvolvimento do Ethereum é realmente lento.
Ver originalResponder0
Anon32942
· 08-09 22:45
Depois de esperar cinco anos, recentemente houve uma variação de preço.
Ver originalResponder0
GasWrangler
· 08-09 22:39
na verdade, levaram 5 anos para otimizar algo tão trivial matematicamente... smh com a ineficiência da camada 1
Ver originalResponder0
SchrodingerProfit
· 08-09 22:33
Cinco anos? Muito devagar, não? O tio V está sofrendo.
Ver originalResponder0
SelfStaking
· 08-09 22:31
Ah, por que é que esta atualização está a demorar tanto?
A instrução de pré-compilação BLS do Ethereum EIP-2537 foi adotada após 5 anos.
EIP-2537: O longo caminho para as instruções pré-compiladas BLS12-381 do Ethereum
EIP-2537 é a instrução pré-compilada EVM que foi adicionada na mais recente atualização do fork Pectra. Esta instrução adiciona várias funções de cálculo da curva BLS12-381 ao EVM, incluindo cálculos de emparelhamento no domínio da curva.
O 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 irá apresentar o histórico de governança do EIP-2537, explorando por que essa proposta levou 5 anos para ser finalmente incorporada à atualização.
Contexto da Proposta
Em janeiro de 2017, Vitalik Buterin apresentou pela primeira vez o algoritmo de pares e a curva alt_bn128. Em seguida, Vitalik e Christian Reitwiessner propuseram a EIP-196 e a EIP-197, para adicionar suporte ao cálculo da curva alt_bn128 na EVM. Essas propostas foram oficialmente adotadas na atualização Byzantium em outubro de 2017, implementando o cálculo de pares de domínio de curva dentro da EVM, permitindo que a verificação de provas ZK-Snarks fosse feita dentro da EVM.
Com o desenvolvimento da criptografia, a equipe do zcash propôs a curva BLS12-381 em novembro de 2017. Em comparação com a alt_bn128, a BLS12-381 possui maior segurança e melhor desempenho. Muitos protocolos de blockchain começaram a usar a curva BLS12-381 em vez da curva alt_bn128.
Em maio de 2018, Justin Drake apontou que as futuras atualizações de PoS e sharding do Ethereum poderiam usar um algoritmo de múltiplas assinaturas BLS baseado na curva BLS12-381. Isso fez com que o plano original EIP-1011 saísse do palco histórico. De fato, a atualização posterior do ETH2 adotou a curva BLS12-381.
Com o desenvolvimento do ETH2, a demanda por introduzir BLS12-381 na camada de execução do ETH está crescendo. Em fevereiro de 2020, pesquisadores propuseram o EIP-2537, esperando que essa proposta pudesse ser testada juntamente com a rede de testes ETH2. O autor do EIP-2537, Alex Stokes, apelou para que o EIP-2537 fosse incluído na hard fork de Berlin.
Vale a pena mencionar que o autor do EIP-2537 é também cofundador da Matter Labs, desenvolvedora do ZKSync.
As dificuldades da atualização de Berlim
Antes de introduzir o conteúdo subsequente, precisamos primeiro entender o EIP-1962. Esta é a primeira proposta sobre pré-compilações de emparelhamento de domínio de curva elíptica apresentada pela Matter Labs em abril de 2019, suportando três curvas: BLS12, BN e MNT4/6.
O EIP-1962 planeia adicionar 10 instruções pré-compiladas de uma só vez para lidar com diferentes curvas. No entanto, a proposta é demasiado complexa, tornando difícil a sua implementação pelos desenvolvedores. Além disso, devido à sua alta generalização, é também complicado para os engenheiros de contratos inteligentes chamá-las. No entanto, a Matter Labs já completou o desenvolvimento do algoritmo de curva elíptica e fornece 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 a divisão de vários EIPs a partir do EIP-1962, alguns dos quais herdaram sua interface. Esses EIPs incluem:
Entre eles, o EIP-2537 é o mais importante, pois a camada de consenso também utiliza a curva BLS12-381. O objetivo principal do EIP-1962 e do EIP-2537 é implementar a verificação de assinatura BLS na camada de consenso na mainnet. Na época, o ETH2 estava a desenhar o contrato de depósito, e como a camada de execução não tinha um algoritmo de verificação BLS, o contrato de depósito não verificaria as assinaturas; a verificação específica da assinatura BLS seria feita pela camada de consenso após o depósito do usuário, e se fosse encontrada uma irregularidade, isso poderia levar à perda de fundos do usuário.
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 de fundos ETH2 para os usuários. Esta foi a razão pela qual muitos desenvolvedores estavam atentos ao EIP-1962 e ao EIP-2537 na época.
Após a proposta do EIP-2537, Vitalik imediatamente apontou uma série de problemas, concentrando-se principalmente no conteúdo do documento EIP. Os autores do EIP responderam e discutiram em seguida. Na reunião de desenvolvedores principais de 6 de março de 2020, Vitalik acreditava que o EIP-2537 e outros EIPs eram muito eficazes para a prova SNARK recursiva e, a longo prazo, não prejudicariam o Ethereum. A reunião confirmou a prioridade do EIP-2537, e todos os clientes concordaram em implementá-lo o mais rápido possível, planejando concluir o desenvolvimento antes da atualização de Berlin.
Após isso, o EIP-2537 tornou-se uma tarefa de alta prioridade. A reunião de 20 de março confirmou que o EIP-2537 substituiria o EIP-1962 como a proposta central de BLS e entraria na lista pré-selecionada para a atualização de Berlin. A reunião de abril oficialmente incorporou o EIP-2537 na atualização do hard fork de Berlin, estabelecendo o cronograma para implementação em abril e testes em maio-junho, e listou isso como a questão de mais alta prioridade.
Em seguida, o EIP-2537 entrou em uma fase intensa de desenvolvimento e testes, sendo discutido em quase 20 reuniões de desenvolvedores principais subsequentes.
Na 85ª reunião, os desenvolvedores discutiram o problema de codificação ABI do EIP-2537. O cliente Besu afirmou que a funcionalidade está basicamente implementada, mas a equipe do Geth informou que ninguém iniciou trabalhos relacionados.
Na 86ª reunião, Geth afirmou que completou parte do trabalho, mas ainda há muito a ser feito.
A 87ª reunião concentrou-se na questão da implementação do EIP-2537. Os desenvolvedores do Geth afirmaram que existe um PR de 16.000 linhas implementando o EIP-2537, mas não é possível determinar sua segurança e eficácia, podendo apenas ser julgado por testes de fuzzing simples. Os desenvolvedores do Geth acreditam que não será possível concluir o desenvolvimento do EIP-2537 antes do prazo previsto para Berlim.
A reunião decidiu aumentar a rede de testes YOLO para testar especificamente o EIP-2537. Neste momento, a importância do EIP-2537 diminuiu significativamente, e os desenvolvedores do Geth acreditam que é muito provável que este EIP não seja incluído na atualização de Berlin.
Na 88ª reunião, os desenvolvedores do Geth descobriram que a implementação do PR do EIP-2537 apresentava uma série de problemas, necessitando de testes e correções adicionais. Existem duas implementações do EIP-2537 no sistema Geth, uma contendo otimizações de assembly, e a outra totalmente escrita em Go. Alguém sugeriu usar diretamente a versão em Go para reduzir a dificuldade da revisão do código.
Na 89ª reunião, surgiu um problema mais sério, a rede de testes YOLO apresentou anomalias, suspeitando-se que fosse causado pela assinatura BLS, mas os desenvolvedores do EIP-2537 negaram. A boa notícia é que o contrato de depósito baseado no EIP-2537 está praticamente concluído, aguardando auditoria.
A 90ª reunião fixou o prazo para o lançamento da atualização Berlin em julho. A reunião também discutiu a questão da predominância do Geth, com alguém a propor congelar a implementação atual do EIP para reduzir os custos de desenvolvimento de outros clientes.
A 92ª reunião ainda confirma o EIP-2537 como o EIP necessário para a atualização de Berlin.
Na 96ª reunião, a Matter Labs espera incluir o EIP-2539 nos testes do YOLO v2 e na atualização Berlin. No entanto, os desenvolvedores do Geth se opõem, acreditando que o EIP-2537 ainda não foi testado completamente no Geth. A decisão final é não adicionar o 2696 na atualização Berlin.
A 99ª reunião decidiu remover o EIP-2537 da rede de testes YOLO v3 e da atualização Berlin, sendo a principal razão o tempo excessivo que consumiu dos desenvolvedores principais, afetando o desenvolvimento de outros EIPs. Um fator secundário foi a proposta da Fundação Ethereum do EVM384 como alternativa.
Em abril de 2021, o Ethereum completou a atualização Berlin, cujo núcleo inclui implementações práticas como a EIP-2565, que não são muito complexas, tornando a atualização aparentemente magra, pois a EIP-2537, que é a mais complexa, foi removida.
Desenvolvimento futuro
A atualização de Londres após a atualização de Berlim introduziu o EIP-1559. Para o EIP-2537, que foi uma proposta central, é difícil que atualizações futuras o incluam.
A atualização de Londres está em andamento, os desenvolvedores consideraram adicionar o EIP-2537. A 109ª reunião sincronizou a situação de desenvolvimento do EIP-2537 e discutiu questões de uso de gás, onde alguém sugeriu substituir o EIP-2537 pelo EVM384. No entanto, a 111ª reunião retirou o EIP-2537 da atualização de Londres devido à complexidade. O principal motivo é que a implementação do padrão EIP-2537 trocou as bibliotecas de dependência, o que pode levar a mudanças na precificação do gás, e cada cliente precisa reavaliar o consumo de gás.
Em junho de 2021, foi oficialmente proposto incluir o EIP-2537 na atualização Shanghai. No entanto, a atualização Merge ocupou grande parte do tempo dos desenvolvedores. Após a conclusão do Merge em setembro de 2022, os desenvolvedores da camada de execução tiveram a oportunidade de continuar a discutir os objetivos da atualização Shanghai.
Em novembro de 2022, a 150ª reunião discutiu brevemente se o EIP-2537 deveria ser incluído na atualização Shanghai, mas concluiu que era necessário adiar. O núcleo da atualização Shanghai é o suporte para retiradas de PoS. No final, o EIP-2537 não foi incluído na atualização Shanghai, que tem como foco a funcionalidade de retirada.
A atualização do Cancun nunca discutiu o EIP-2537, pois seu núcleo é o suporte ao EIP-4844, que fornece uma camada de dados Blob disponível para a segunda camada.
Em fevereiro de 2024, a 181ª reunião discutiu a inclusão do EIP-2537 na atualização do Pectra, considerando que a implementação não é mais um problema, apenas a precificação do consumo de gas é um problema.
No dia 19 de dezembro de 2024, na 202ª reunião, os desenvolvedores da Nethermind determinaram o modelo de preços para o EIP-2537. O proponente inicial, a Matter Labs, já estava quase fora da discussão. Na 203ª reunião em janeiro de 2025, foi discutida a reavaliação da pré-compilação BLS, e os desenvolvedores do Geth sugeriram aumentar o custo de gás em 20%, recebendo o apoio da equipe do Besu para os testes de referência.
Resumo
O desenvolvimento do EIP-2537 pode ser resumido da seguinte forma:
A inclusão do EIP na atualização do Ethereum depende tanto do esforço próprio quanto da consideração do processo histórico. Cada atualização tem um tema, e o EIP-2537 foi o núcleo da atualização de Berlin, mas foi abandonado devido à sua complexidade. Depois disso, o Ethereum focou no PoS, e os EIPs de camada de execução pura não receberam atenção, resultando na não aceitação prolongada do EIP-2537. Somente recentemente, os desenvolvedores começaram a se reatentar e resolver os problemas pendentes.