Este artículo presenta la historia de gobernanza de EIP-2537 y explora por qué ha pasado 5 años para que esta propuesta se incluya en la actualización.
Redactado por: shew
Resumen
EIP-2537 es la instrucción de preensamblador EVM que se ha determinado agregar en la última actualización del fork de Pectra. Esta instrucción añade múltiples funciones de cálculo de la curva BLS12-381 al EVM, como el cálculo de emparejamiento en el dominio de la curva, entre otros.
EIP-2573 fue propuesto por primera vez en 2020 y no fue confirmado para su inclusión en la actualización de Ethereum hasta 2025. Este artículo presenta la historia de la gobernanza de EIP-2537 y explora por qué tomó 5 años incluir esta propuesta en la actualización.
Antecedentes de la propuesta
En enero de 2017, Vitalik Buterin presentó por primera vez el algoritmo de emparejamiento y la curva alt_bn128 en Exploring Elliptic Curve Pairings. Luego, en febrero de 2017, Vitalik Buterin y Christian Reitwiessner propusieron las propuestas EIP-196 y EIP-197, que consisten en agregar soporte para cálculos de la curva alt_bn128 en la EVM.
En la actualización de Byzantium en octubre de 2017, se incorporó oficialmente la curva alt_bn128. En términos simples, alt_bn128 logró por primera vez el cálculo de emparejamiento de dominio de curva dentro de la EVM, lo que permite que la verificación de pruebas ZK-Snarks se realice dentro de la EVM.
Sin embargo, con el desarrollo de la criptografía, en noviembre de 2017, el equipo de desarrollo de zcash dio la curva BLS12-381 por primera vez en BLS12-381: New zk-SNARK Elliptic Curve Construction. En comparación con alt_bn128, BLS12-381 tiene mayor seguridad y mejor rendimiento. Desde entonces, bastantes protocolos de blockchain han utilizado la curva BLS12-381 y han desechado la curva alt_bn128.
En mayo de 2018, Justin Drake publicó en ethresear un artículo titulado "Agregación de firmas pragmáticas con BLS", señalando que en las futuras actualizaciones de PoS y fragmentación de Ethereum se podría utilizar el algoritmo de múltiples firmas BLS basado en la curva BLS12-381. En ese momento, los investigadores de Ethereum esperaban resolver el problema de la capa de consenso con EIP-1011, pero el esquema de EIP-1011 podía acomodar un máximo de 900 validadores, estableciendo así un enorme tamaño de apuesta de 1500 ETH por cada validador. Con la propuesta del esquema de múltiples firmas BLS, EIP-1011 salió del escenario histórico. Resultó que la posterior actualización de ETH2 también utilizó finalmente la curva BLS12-381.
Con el desarrollo de ETH2, se ha comenzado a exigir la introducción de BLS12-381 utilizado por ETH2 en la capa de ejecución de ETH. En febrero de 2020, algunos investigadores propusieron EIP-2537, con la esperanza de que esta propuesta pudiera ser aceptada para pruebas en la red de prueba de ETH2. El autor de EIP-2537, Alex Stokes, hizo un llamado para incluir EIP-2537 en la bifurcación dura de Berlín en el artículo What eth2 needs from eth1 over the next six months.
Curiosamente, el autor de EIP-2537 también es cofundador de Matter Labs, y el producto más famoso de Matter Labs es ZKSync.
Berlín turbulento
Antes de presentar el contenido posterior, necesitamos introducir primero el EIP-1962. El EIP-1962 es la primera propuesta sobre la precompilación de emparejamiento de curvas elípticas presentada por Matter Labs en abril de 2019, la cual soporta tres curvas, que son:
BLS12
BN
MNT4/6 (Ate pairing)
Esta EIP está preparada para agregar de una sola vez 10 instrucciones preensambladas para manejar diferentes curvas. Sin embargo, después del nacimiento de esta propuesta, un número considerable de desarrolladores cuestionó que la propuesta era demasiado compleja, lo que dificultaba su implementación. Al mismo tiempo, debido a la alta generalización de EIP1962, la llamada también es bastante problemática para los ingenieros de contratos inteligentes. Por supuesto, como proponentes de EIP-1962, Matter Labs ha completado esencialmente el trabajo de desarrollo del algoritmo de curva elíptica y ha proporcionado implementaciones de referencia en Rust / Go / C++.
Para resolver el problema de EIP-1962, Matter Labs propuso en febrero de 2020 múltiples EIPs que descomponen EIP-1962, y estos EIPs heredan parcialmente la interfaz de EIP-1962. Estos EIPs incluyen:
EIP-2537 proporciona soporte para BLS12-381
EIP-2539 proporciona soporte para BLS12-377
PR#2541 proporciona soporte para la curva BLS12-377 (Zexe ), pero tenga en cuenta que la propuesta no recibió un número EIP, por lo que no se puede encontrar en el sitio oficial de documentación de EIP.
Dentro de estos EIP, el más importante es el EIP-2537, ya que la capa de consenso también utiliza la curva BLS12-381. Tanto el EIP-1962 como el EIP-2537 tienen como objetivo principal implementar la verificación de firmas BLS en la capa de consenso dentro de la mainnet. En ese momento, ETH2 estaba desarrollando el diseño del contrato de depósito para la capa de consenso. En el diseño inicial del contrato de depósito, como la capa de ejecución no incluía el algoritmo de verificación BLS, el contrato de depósito no verificaría las firmas; la firma BLS específica sería verificada por la capa de consenso después de que el usuario realizara el depósito. Si se encuentra que es incorrecta (para nuevos validadores), el depósito fallará y el ETH depositado por el usuario se perderá.
En este contexto, los desarrolladores principales desean introducir la precompilación BLS12-381 para implementar la verificación de firmas dentro del contrato de depósitos, evitando así la posible pérdida de fondos de ETH2 por parte de los usuarios. Esta también fue la razón por la que muchos desarrolladores prestaron atención a EIP-1962 y EIP-2537 en ese momento.
Cuando se propuso por primera vez el EIP-2537, Vitalik inmediatamente identificó una serie de problemas existentes en el EIP:
Estas dudas se centraron en el contenido del documento EIP, y luego el autor del EIP respondió y discutió al respecto. Posteriormente, el 6 de marzo de 2020, en la reunión de desarrolladores principales de Ethereum #82, los desarrolladores principales de Ethereum discutieron el EIP-2537. En esta reunión, Vitalik consideró que el EIP-2537 y otros EIPs son muy efectivos para las pruebas SNARK recursivas y que, a largo plazo, no perjudicarán a Ethereum. Al mismo tiempo, la reunión también confirmó la prioridad del EIP-2537, y todos los clientes acordaron implementar el EIP-2537 lo antes posible, con el plan de completar todo el desarrollo antes de la actualización de Berlín.
Luego, EIP-2537 se convirtió en una tarea de alta prioridad. El 20 de marzo de 2020, en la reunión de desarrolladores de Ethereum Core #83, EIP-2537 seguía siendo la propuesta discutida primero. Esta reunión confirmó que EIP-2537 sustituiría a EIP-1962 como la propuesta principal de BLS y se incluiría en la lista preliminar de EIP para la actualización de Berlín ( es Eligibility for Inclusion (EFI)).
En la reunión de desarrolladores principales de Ethereum #84 en abril de 2020, se decidió oficialmente incluir el EIP-2537 en la actualización del hard fork de Berlín, y se estableció una línea de tiempo para implementar la actualización de Berlín en abril y realizar pruebas en mayo y junio. Es importante destacar que, en esta discusión, el EIP-2537 se clasificó como un asunto de máxima prioridad.
Luego, EIP-2537 entró en una gran fase de desarrollo y pruebas, y en casi 20 reuniones de desarrolladores principales que siguieron, cada reunión básicamente involucró discusiones sobre EIP-2537. A continuación, podemos ver qué problemas relacionados con EIP-2537 se discutieron en cada reunión.
En la reunión de desarrolladores principales de Ethereum #85, Danno y Axic discutieron el problema de codificación ABI de EIP-2537. Posteriormente, los desarrolladores principales sincronizaron el estado actual de la implementación, donde debido a que el proponente de EIP-2537, Matter Labs, ya había completado en gran medida la implementación de la versión en Rust, el cliente Besu declaró que había implementado en gran medida la funcionalidad de EIP-2537. Sin embargo, desde Geth, se indicó que actualmente no hay nadie trabajando en la implementación de EIP-2537.
En la reunión de desarrolladores principales de Ethereum #86, diferentes implementaciones de nodos de Ethereum sincronizaron nuevamente el estado de implementación de EIP-2537, donde Geth indicó que se había completado parte del trabajo, pero aún queda mucho por hacer.
En la reunión de desarrolladores del núcleo de Ethereum #87, el contenido más importante de esta reunión fue el problema de implementación del EIP-2537. Los desarrolladores de Geth mencionaron que actualmente hay un PR de 16000 líneas que implementa el EIP-2537, pero no pueden determinar si el PR es una implementación segura y efectiva del EIP-2537, por lo que los desarrolladores solo pueden juzgar la situación del código a través de pruebas de fuzzing muy simples.
Los desarrolladores de Geth dijeron: «Así que mi reacción instintiva es que no hay ninguna posibilidad de que Geth esté listo con las operaciones de curva BLS para el lanzamiento de mainnet en julio.», es decir, Geth probablemente no podrá completar el desarrollo relacionado con EIP-2537 antes de la fecha programada en Berlín.
Hudson Jameson propuso buscar ingenieros criptográficos para ayudar en la revisión de PR de Geth, y también propuso usar la red de pruebas para verificar la seguridad de la implementación de EIP-2537. Dado que en este momento el equipo de desarrollo de ETH2 también está implementando la verificación de firmas BLS, el equipo de ETH2 puede participar en las pruebas.
Aquí, necesitamos agregar un conocimiento de fondo, que es que la implementación del PR de EIP-2537 de Geth ha utilizado una gran cantidad de código ensamblador para garantizar la eficiencia, y esta parte del código ensamblador es muy difícil de leer y entender. Por lo tanto, Alex Vlasov sugiere eliminar las optimizaciones de ensamblador complejas dentro del PR para reducir la dificultad de revisión.
Ya hemos mencionado anteriormente que uno de los objetivos principales de EIP-2537 es ayudar al contrato de depósito de ETH2, pero en esta reunión, los desarrolladores del contrato de depósito indicaron que no van a utilizar el contrato de depósito de EIP-2537, ya que ha sido auditado. Por lo tanto, algunos desarrolladores sugirieron que lo mejor sería no lanzar otro contrato de depósito que use EIP-2537.
Al final, la reunión decidió aumentar la red de pruebas YOLO, cuyo núcleo es probar el EIP-2537. De hecho, en esta reunión, ya podemos ver que la importancia del EIP-2537 ha disminuido considerablemente con la finalización del contrato de depósito, mientras que los desarrolladores de Geth ya consideran que es muy probable que este EIP no se implemente antes de la actualización de Berlín. Parece que la no aceptación del EIP-2537 en la actualización de Berlín se ha convertido en un hecho consumado.
Durante la Reunión de Desarrolladores del Núcleo de Ethereum #88, los desarrolladores de Geth identificaron una serie de problemas con el PR de implementación para EIP-2537, que los desarrolladores dijeron que necesitaban más pruebas y correcciones. En este momento, hay dos implementaciones de EIP-2537 en el sistema Geth, una de las cuales contiene optimizaciones de ensamblaje y la otra está escrita completamente en go.
En la reunión de desarrolladores de Ethereum Core #89, surgió un problema más grave, el test de YOLO presentó algunos problemas, los desarrolladores sospechan que es un problema causado por la firma BLS, pero los desarrolladores de EIP2537 lo refutaron, argumentando que el problema en la red de pruebas no es causado por la firma BLS. La buena noticia sobre EIP-2537 es que el contrato de depósito basado en EIP-2537 está prácticamente terminado, y el contrato está en espera de auditoría.
En la reunión de desarrolladores de Ethereum Core Devs Meeting #90 内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91, un desarrollador propuso usar un enfoque modular para reducir los costos de desarrollo y aumentar la diversidad de clientes. Si los lectores están interesados en la diversidad de clientes de Ethereum, pueden leer las actas de estas dos reuniones.
En la reunión de desarrolladores de Ethereum Core #92, el EIP 2537 sigue siendo confirmado como necesario para la actualización de Berlín.
En la reunión #96 de Ethereum Core Devs, Matter Labs quiere poner EIP-2539 propuesto al mismo tiempo que EIP-2537 en la red de pruebas YOLO v2 e ingresar a la actualización de Berlín, dado que Celo ha incluido tanto EIP-2537 como EIP-2539 en su actualización de bifurcación dura de red. Sin embargo, los desarrolladores de Geth se opusieron, argumentando que el actual EIP-2537 no ha sido completamente probado dentro de Geth. En la reunión final se decidió no añadir 2696 a la mejora de Berlín, dejándola para futuras discusiones.
En la reunión de desarrolladores principales de Ethereum #99, se decidió sacar el EIP-2537 de la red de pruebas YOLO v3 y la actualización Berlin. La razón principal es que el EIP-2537 ha desperdiciado demasiado tiempo de los desarrolladores principales, lo que ha obstaculizado el desarrollo de otros EIP en la actualización Berlin. Un factor secundario es que la Fundación Ethereum propuso el EVM384 como sustituto del EIP-2537, que ofrece una solución de cálculo de curvas elípticas más general. Sin embargo, los desarrolladores principales expresaron su preocupación por los problemas de seguridad durante la discusión de la reunión.
El contenido anterior es el recorrido temprano de EIP-2537. Podemos ver que EIP-2537 fue uno de los EIP más importantes en la actualización de Berlin, pero debido a problemas de implementación, finalmente fue descartado. Al final, en abril de 2021, Ethereum completó la actualización de Berlin, en la que los EIP centrales incluidos, como EIP-2565, no eran realmente complejos. Parece que la actualización de Berlin es un poco delgada, ya que el EIP-2537, que es el más complejo, fue excluido de la actualización de Berlin.
Desarrollo posterior
Como todos saben, cada actualización de Ethereum tiene una propuesta central, como la actualización de Londres después de la actualización de Berlín, que introdujo la propuesta de tarifas más importante en la historia de Ethereum, EIP-1559. En cuanto a EIP-2537, que alguna vez fue una propuesta central, es difícil que las actualizaciones posteriores incluyan esta propuesta.
En la actualización de Londres después de Berlín, los desarrolladores sincronizaron el estado actual del desarrollo de EIP-2537 en issues#369 曾考虑在 London 升级中增加 EIP-2537。在 Ethereum Core Devs Meeting #109. En ese momento, debido al uso de otras bibliotecas para implementar EIP-2537, se introdujo una discusión sobre el uso de gas de EIP-2537. Al mismo tiempo, algunos desarrolladores propusieron reemplazar EIP-2537 con EVM384. Sin embargo, en la reunión de desarrolladores principales de Ethereum #111 en abril de 2021, EIP-2537 fue eliminado de la actualización de Londres debido a su complejidad. La complejidad central radica en que la implementación estándar de EIP-2537 cambió las bibliotecas dependientes, lo que podría provocar cambios en la fijación de precios de gas, y las diferentes implementaciones del cliente necesitarían un tiempo considerable para reevaluar el consumo de gas.
En junio de 2021, se propuso oficialmente la inclusión de EIP-2537 en la actualización de Shanghai en issues#343. Sin embargo, es importante tener en cuenta que después de la actualización de London, la actualización de Pairs, también conocida como The Merge, ocupó gran parte del tiempo de los desarrolladores, ya que los desarrolladores de la capa de ejecución necesitaban escribir una gran cantidad de código para implementar la actualización de PoS. En septiembre de 2022, la actualización de Pairs se completó y los desarrolladores de la capa de ejecución finalmente tuvieron la oportunidad de continuar discutiendo algunos objetivos de la actualización de Shanghai.
En noviembre de 2022, durante la reunión de desarrolladores de Ethereum Core #150, se discutió brevemente si incluir EIP-2537 en la actualización de Shanghai, pero los desarrolladores consideraron que EIP-2537 debía posponerse, ya que el núcleo de la actualización de Shanghai es soportar los retiros de PoS. Al final, EIP-2537 no fue incluido en la actualización de Shanghai centrada en la función de retiro.
Más trágico aún es que la actualización de Cancun no ha discutido EIP-2537, ya que el núcleo de la actualización de Cancun es el soporte de nodos de la capa de ejecución para EIP-4844. EIP-4844 proporciona Blobs para la segunda capa de Ethereum, facilitando que la segunda capa use Ethereum como capa de disponibilidad de datos.
Finalmente, en la reunión de desarrolladores del núcleo de Ethereum #181 en febrero de 2024, los desarrolladores discutieron la inclusión de EIP-2537 en la actualización de Pectra, y en ese momento los desarrolladores consideraron que la implementación de EIP-2537 ya no era un problema, solo había algunos problemas en cuanto a la fijación de precios del consumo de Gas.
En la reunión de desarrolladores de Ethereum Core del 19 de diciembre de 2024 #202 内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的 Ethereum Core Devs Meeting #203, los desarrolladores discutieron la revalorización de la precompilación BLS. Jared Wasinger, desarrollador de Geth, sugirió aumentar el costo de gas en un 20%, y recibió el apoyo de las pruebas de referencia del equipo de Besu.
Resumen
Como se puede ver, si el EIP se incluye en la actualización de Ethereum, "por supuesto depende del esfuerzo propio, pero también hay que considerar el curso de la historia". Cada actualización de Ethereum tiene su propio tema, así como el EIP-2537 se convirtió en el EIP más importante de la actualización de Berlín, pero fue descartado debido a su dificultad de implementación y complejidad. Las actualizaciones posteriores de Ethereum entraron en el proceso histórico de PoS, y los EIP de capa de ejecución pura y compleja no recibieron atención, mientras que una gran cantidad de EIP de ejecución relacionados con PoS se consideraron objetivos de actualización clave, lo que llevó a que el EIP-2537 no fuera aceptado durante un largo período.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Observatorio de gobernanza de Ethereum: Proceso de precompilación de EIP-2537｜Investigación GCC
Redactado por: shew
Resumen
EIP-2537 es la instrucción de preensamblador EVM que se ha determinado agregar en la última actualización del fork de Pectra. Esta instrucción añade múltiples funciones de cálculo de la curva BLS12-381 al EVM, como el cálculo de emparejamiento en el dominio de la curva, entre otros.
EIP-2573 fue propuesto por primera vez en 2020 y no fue confirmado para su inclusión en la actualización de Ethereum hasta 2025. Este artículo presenta la historia de la gobernanza de EIP-2537 y explora por qué tomó 5 años incluir esta propuesta en la actualización.
Antecedentes de la propuesta
En enero de 2017, Vitalik Buterin presentó por primera vez el algoritmo de emparejamiento y la curva alt_bn128 en Exploring Elliptic Curve Pairings. Luego, en febrero de 2017, Vitalik Buterin y Christian Reitwiessner propusieron las propuestas EIP-196 y EIP-197, que consisten en agregar soporte para cálculos de la curva alt_bn128 en la EVM.
En la actualización de Byzantium en octubre de 2017, se incorporó oficialmente la curva alt_bn128. En términos simples, alt_bn128 logró por primera vez el cálculo de emparejamiento de dominio de curva dentro de la EVM, lo que permite que la verificación de pruebas ZK-Snarks se realice dentro de la EVM.
Sin embargo, con el desarrollo de la criptografía, en noviembre de 2017, el equipo de desarrollo de zcash dio la curva BLS12-381 por primera vez en BLS12-381: New zk-SNARK Elliptic Curve Construction. En comparación con alt_bn128, BLS12-381 tiene mayor seguridad y mejor rendimiento. Desde entonces, bastantes protocolos de blockchain han utilizado la curva BLS12-381 y han desechado la curva alt_bn128.
En mayo de 2018, Justin Drake publicó en ethresear un artículo titulado "Agregación de firmas pragmáticas con BLS", señalando que en las futuras actualizaciones de PoS y fragmentación de Ethereum se podría utilizar el algoritmo de múltiples firmas BLS basado en la curva BLS12-381. En ese momento, los investigadores de Ethereum esperaban resolver el problema de la capa de consenso con EIP-1011, pero el esquema de EIP-1011 podía acomodar un máximo de 900 validadores, estableciendo así un enorme tamaño de apuesta de 1500 ETH por cada validador. Con la propuesta del esquema de múltiples firmas BLS, EIP-1011 salió del escenario histórico. Resultó que la posterior actualización de ETH2 también utilizó finalmente la curva BLS12-381.
Con el desarrollo de ETH2, se ha comenzado a exigir la introducción de BLS12-381 utilizado por ETH2 en la capa de ejecución de ETH. En febrero de 2020, algunos investigadores propusieron EIP-2537, con la esperanza de que esta propuesta pudiera ser aceptada para pruebas en la red de prueba de ETH2. El autor de EIP-2537, Alex Stokes, hizo un llamado para incluir EIP-2537 en la bifurcación dura de Berlín en el artículo What eth2 needs from eth1 over the next six months.
Curiosamente, el autor de EIP-2537 también es cofundador de Matter Labs, y el producto más famoso de Matter Labs es ZKSync.
Berlín turbulento
Antes de presentar el contenido posterior, necesitamos introducir primero el EIP-1962. El EIP-1962 es la primera propuesta sobre la precompilación de emparejamiento de curvas elípticas presentada por Matter Labs en abril de 2019, la cual soporta tres curvas, que son:
Esta EIP está preparada para agregar de una sola vez 10 instrucciones preensambladas para manejar diferentes curvas. Sin embargo, después del nacimiento de esta propuesta, un número considerable de desarrolladores cuestionó que la propuesta era demasiado compleja, lo que dificultaba su implementación. Al mismo tiempo, debido a la alta generalización de EIP1962, la llamada también es bastante problemática para los ingenieros de contratos inteligentes. Por supuesto, como proponentes de EIP-1962, Matter Labs ha completado esencialmente el trabajo de desarrollo del algoritmo de curva elíptica y ha proporcionado implementaciones de referencia en Rust / Go / C++.
Para resolver el problema de EIP-1962, Matter Labs propuso en febrero de 2020 múltiples EIPs que descomponen EIP-1962, y estos EIPs heredan parcialmente la interfaz de EIP-1962. Estos EIPs incluyen:
Dentro de estos EIP, el más importante es el EIP-2537, ya que la capa de consenso también utiliza la curva BLS12-381. Tanto el EIP-1962 como el EIP-2537 tienen como objetivo principal implementar la verificación de firmas BLS en la capa de consenso dentro de la mainnet. En ese momento, ETH2 estaba desarrollando el diseño del contrato de depósito para la capa de consenso. En el diseño inicial del contrato de depósito, como la capa de ejecución no incluía el algoritmo de verificación BLS, el contrato de depósito no verificaría las firmas; la firma BLS específica sería verificada por la capa de consenso después de que el usuario realizara el depósito. Si se encuentra que es incorrecta (para nuevos validadores), el depósito fallará y el ETH depositado por el usuario se perderá.
En este contexto, los desarrolladores principales desean introducir la precompilación BLS12-381 para implementar la verificación de firmas dentro del contrato de depósitos, evitando así la posible pérdida de fondos de ETH2 por parte de los usuarios. Esta también fue la razón por la que muchos desarrolladores prestaron atención a EIP-1962 y EIP-2537 en ese momento.
Cuando se propuso por primera vez el EIP-2537, Vitalik inmediatamente identificó una serie de problemas existentes en el EIP:
Estas dudas se centraron en el contenido del documento EIP, y luego el autor del EIP respondió y discutió al respecto. Posteriormente, el 6 de marzo de 2020, en la reunión de desarrolladores principales de Ethereum #82, los desarrolladores principales de Ethereum discutieron el EIP-2537. En esta reunión, Vitalik consideró que el EIP-2537 y otros EIPs son muy efectivos para las pruebas SNARK recursivas y que, a largo plazo, no perjudicarán a Ethereum. Al mismo tiempo, la reunión también confirmó la prioridad del EIP-2537, y todos los clientes acordaron implementar el EIP-2537 lo antes posible, con el plan de completar todo el desarrollo antes de la actualización de Berlín.
Luego, EIP-2537 se convirtió en una tarea de alta prioridad. El 20 de marzo de 2020, en la reunión de desarrolladores de Ethereum Core #83, EIP-2537 seguía siendo la propuesta discutida primero. Esta reunión confirmó que EIP-2537 sustituiría a EIP-1962 como la propuesta principal de BLS y se incluiría en la lista preliminar de EIP para la actualización de Berlín ( es Eligibility for Inclusion (EFI)).
En la reunión de desarrolladores principales de Ethereum #84 en abril de 2020, se decidió oficialmente incluir el EIP-2537 en la actualización del hard fork de Berlín, y se estableció una línea de tiempo para implementar la actualización de Berlín en abril y realizar pruebas en mayo y junio. Es importante destacar que, en esta discusión, el EIP-2537 se clasificó como un asunto de máxima prioridad.
Luego, EIP-2537 entró en una gran fase de desarrollo y pruebas, y en casi 20 reuniones de desarrolladores principales que siguieron, cada reunión básicamente involucró discusiones sobre EIP-2537. A continuación, podemos ver qué problemas relacionados con EIP-2537 se discutieron en cada reunión.
En la reunión de desarrolladores principales de Ethereum #85, Danno y Axic discutieron el problema de codificación ABI de EIP-2537. Posteriormente, los desarrolladores principales sincronizaron el estado actual de la implementación, donde debido a que el proponente de EIP-2537, Matter Labs, ya había completado en gran medida la implementación de la versión en Rust, el cliente Besu declaró que había implementado en gran medida la funcionalidad de EIP-2537. Sin embargo, desde Geth, se indicó que actualmente no hay nadie trabajando en la implementación de EIP-2537.
En la reunión de desarrolladores principales de Ethereum #86, diferentes implementaciones de nodos de Ethereum sincronizaron nuevamente el estado de implementación de EIP-2537, donde Geth indicó que se había completado parte del trabajo, pero aún queda mucho por hacer.
En la reunión de desarrolladores del núcleo de Ethereum #87, el contenido más importante de esta reunión fue el problema de implementación del EIP-2537. Los desarrolladores de Geth mencionaron que actualmente hay un PR de 16000 líneas que implementa el EIP-2537, pero no pueden determinar si el PR es una implementación segura y efectiva del EIP-2537, por lo que los desarrolladores solo pueden juzgar la situación del código a través de pruebas de fuzzing muy simples.
Los desarrolladores de Geth dijeron: «Así que mi reacción instintiva es que no hay ninguna posibilidad de que Geth esté listo con las operaciones de curva BLS para el lanzamiento de mainnet en julio.», es decir, Geth probablemente no podrá completar el desarrollo relacionado con EIP-2537 antes de la fecha programada en Berlín.
Hudson Jameson propuso buscar ingenieros criptográficos para ayudar en la revisión de PR de Geth, y también propuso usar la red de pruebas para verificar la seguridad de la implementación de EIP-2537. Dado que en este momento el equipo de desarrollo de ETH2 también está implementando la verificación de firmas BLS, el equipo de ETH2 puede participar en las pruebas.
Aquí, necesitamos agregar un conocimiento de fondo, que es que la implementación del PR de EIP-2537 de Geth ha utilizado una gran cantidad de código ensamblador para garantizar la eficiencia, y esta parte del código ensamblador es muy difícil de leer y entender. Por lo tanto, Alex Vlasov sugiere eliminar las optimizaciones de ensamblador complejas dentro del PR para reducir la dificultad de revisión.
Ya hemos mencionado anteriormente que uno de los objetivos principales de EIP-2537 es ayudar al contrato de depósito de ETH2, pero en esta reunión, los desarrolladores del contrato de depósito indicaron que no van a utilizar el contrato de depósito de EIP-2537, ya que ha sido auditado. Por lo tanto, algunos desarrolladores sugirieron que lo mejor sería no lanzar otro contrato de depósito que use EIP-2537.
Al final, la reunión decidió aumentar la red de pruebas YOLO, cuyo núcleo es probar el EIP-2537. De hecho, en esta reunión, ya podemos ver que la importancia del EIP-2537 ha disminuido considerablemente con la finalización del contrato de depósito, mientras que los desarrolladores de Geth ya consideran que es muy probable que este EIP no se implemente antes de la actualización de Berlín. Parece que la no aceptación del EIP-2537 en la actualización de Berlín se ha convertido en un hecho consumado.
Durante la Reunión de Desarrolladores del Núcleo de Ethereum #88, los desarrolladores de Geth identificaron una serie de problemas con el PR de implementación para EIP-2537, que los desarrolladores dijeron que necesitaban más pruebas y correcciones. En este momento, hay dos implementaciones de EIP-2537 en el sistema Geth, una de las cuales contiene optimizaciones de ensamblaje y la otra está escrita completamente en go.
En la reunión de desarrolladores de Ethereum Core #89, surgió un problema más grave, el test de YOLO presentó algunos problemas, los desarrolladores sospechan que es un problema causado por la firma BLS, pero los desarrolladores de EIP2537 lo refutaron, argumentando que el problema en la red de pruebas no es causado por la firma BLS. La buena noticia sobre EIP-2537 es que el contrato de depósito basado en EIP-2537 está prácticamente terminado, y el contrato está en espera de auditoría.
En la reunión de desarrolladores de Ethereum Core Devs Meeting #90 内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91, un desarrollador propuso usar un enfoque modular para reducir los costos de desarrollo y aumentar la diversidad de clientes. Si los lectores están interesados en la diversidad de clientes de Ethereum, pueden leer las actas de estas dos reuniones.
En la reunión de desarrolladores de Ethereum Core #92, el EIP 2537 sigue siendo confirmado como necesario para la actualización de Berlín.
En la reunión #96 de Ethereum Core Devs, Matter Labs quiere poner EIP-2539 propuesto al mismo tiempo que EIP-2537 en la red de pruebas YOLO v2 e ingresar a la actualización de Berlín, dado que Celo ha incluido tanto EIP-2537 como EIP-2539 en su actualización de bifurcación dura de red. Sin embargo, los desarrolladores de Geth se opusieron, argumentando que el actual EIP-2537 no ha sido completamente probado dentro de Geth. En la reunión final se decidió no añadir 2696 a la mejora de Berlín, dejándola para futuras discusiones.
En la reunión de desarrolladores principales de Ethereum #99, se decidió sacar el EIP-2537 de la red de pruebas YOLO v3 y la actualización Berlin. La razón principal es que el EIP-2537 ha desperdiciado demasiado tiempo de los desarrolladores principales, lo que ha obstaculizado el desarrollo de otros EIP en la actualización Berlin. Un factor secundario es que la Fundación Ethereum propuso el EVM384 como sustituto del EIP-2537, que ofrece una solución de cálculo de curvas elípticas más general. Sin embargo, los desarrolladores principales expresaron su preocupación por los problemas de seguridad durante la discusión de la reunión.
El contenido anterior es el recorrido temprano de EIP-2537. Podemos ver que EIP-2537 fue uno de los EIP más importantes en la actualización de Berlin, pero debido a problemas de implementación, finalmente fue descartado. Al final, en abril de 2021, Ethereum completó la actualización de Berlin, en la que los EIP centrales incluidos, como EIP-2565, no eran realmente complejos. Parece que la actualización de Berlin es un poco delgada, ya que el EIP-2537, que es el más complejo, fue excluido de la actualización de Berlin.
Desarrollo posterior
Como todos saben, cada actualización de Ethereum tiene una propuesta central, como la actualización de Londres después de la actualización de Berlín, que introdujo la propuesta de tarifas más importante en la historia de Ethereum, EIP-1559. En cuanto a EIP-2537, que alguna vez fue una propuesta central, es difícil que las actualizaciones posteriores incluyan esta propuesta.
En la actualización de Londres después de Berlín, los desarrolladores sincronizaron el estado actual del desarrollo de EIP-2537 en issues#369 曾考虑在 London 升级中增加 EIP-2537。在 Ethereum Core Devs Meeting #109. En ese momento, debido al uso de otras bibliotecas para implementar EIP-2537, se introdujo una discusión sobre el uso de gas de EIP-2537. Al mismo tiempo, algunos desarrolladores propusieron reemplazar EIP-2537 con EVM384. Sin embargo, en la reunión de desarrolladores principales de Ethereum #111 en abril de 2021, EIP-2537 fue eliminado de la actualización de Londres debido a su complejidad. La complejidad central radica en que la implementación estándar de EIP-2537 cambió las bibliotecas dependientes, lo que podría provocar cambios en la fijación de precios de gas, y las diferentes implementaciones del cliente necesitarían un tiempo considerable para reevaluar el consumo de gas.
En junio de 2021, se propuso oficialmente la inclusión de EIP-2537 en la actualización de Shanghai en issues#343. Sin embargo, es importante tener en cuenta que después de la actualización de London, la actualización de Pairs, también conocida como The Merge, ocupó gran parte del tiempo de los desarrolladores, ya que los desarrolladores de la capa de ejecución necesitaban escribir una gran cantidad de código para implementar la actualización de PoS. En septiembre de 2022, la actualización de Pairs se completó y los desarrolladores de la capa de ejecución finalmente tuvieron la oportunidad de continuar discutiendo algunos objetivos de la actualización de Shanghai.
En noviembre de 2022, durante la reunión de desarrolladores de Ethereum Core #150, se discutió brevemente si incluir EIP-2537 en la actualización de Shanghai, pero los desarrolladores consideraron que EIP-2537 debía posponerse, ya que el núcleo de la actualización de Shanghai es soportar los retiros de PoS. Al final, EIP-2537 no fue incluido en la actualización de Shanghai centrada en la función de retiro.
Más trágico aún es que la actualización de Cancun no ha discutido EIP-2537, ya que el núcleo de la actualización de Cancun es el soporte de nodos de la capa de ejecución para EIP-4844. EIP-4844 proporciona Blobs para la segunda capa de Ethereum, facilitando que la segunda capa use Ethereum como capa de disponibilidad de datos.
Finalmente, en la reunión de desarrolladores del núcleo de Ethereum #181 en febrero de 2024, los desarrolladores discutieron la inclusión de EIP-2537 en la actualización de Pectra, y en ese momento los desarrolladores consideraron que la implementación de EIP-2537 ya no era un problema, solo había algunos problemas en cuanto a la fijación de precios del consumo de Gas.
En la reunión de desarrolladores de Ethereum Core del 19 de diciembre de 2024 #202 内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的 Ethereum Core Devs Meeting #203, los desarrolladores discutieron la revalorización de la precompilación BLS. Jared Wasinger, desarrollador de Geth, sugirió aumentar el costo de gas en un 20%, y recibió el apoyo de las pruebas de referencia del equipo de Besu.
Resumen
Como se puede ver, si el EIP se incluye en la actualización de Ethereum, "por supuesto depende del esfuerzo propio, pero también hay que considerar el curso de la historia". Cada actualización de Ethereum tiene su propio tema, así como el EIP-2537 se convirtió en el EIP más importante de la actualización de Berlín, pero fue descartado debido a su dificultad de implementación y complejidad. Las actualizaciones posteriores de Ethereum entraron en el proceso histórico de PoS, y los EIP de capa de ejecución pura y compleja no recibieron atención, mientras que una gran cantidad de EIP de ejecución relacionados con PoS se consideraron objetivos de actualización clave, lo que llevó a que el EIP-2537 no fuera aceptado durante un largo período.