EIP-2537 es la instrucción de preensamblado EVM que se ha determinado agregar en la última actualización bifurcada de Pectra. Esta instrucción añade diversas funciones de cálculo de la curva BLS12-381 al EVM, como el cálculo de pares en el dominio de la curva.
EIP-2573 fue propuesto por primera vez en 2020 y no fue confirmado para ser incluido en la actualización de Ethereum hasta 2025. Este artículo presenta la historia de 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ó 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, cuyo contenido era añadir soporte para cálculos de la curva alt_bn128 en la EVM.
En la actualización de Byzantium de octubre de 2017, se incorporó oficialmente la curva alt_bn128. En pocas palabras, alt_bn128 implementó por primera vez el cálculo de pares de campos de curvas dentro de la EVM, lo que permitió que la verificación de pruebas ZK-Snarks se pudiera realizar dentro de la EVM.
Pero a medida que la criptografía avanzaba, en noviembre de 2017, el equipo de desarrollo de zcash presentó la curva BLS12-381 en BLS12-381: New zk-SNARK Elliptic Curve Construction. En comparación con alt_bn128, BLS12-381 ofrece mayor seguridad y mejor rendimiento. Muchos protocolos de blockchain comenzaron a utilizar la curva BLS12-381 y descontinuaron la curva alt_bn128.
En mayo de 2018, Justin Drake publicó un artículo titulado "Agregación de firmas pragmáticas con BLS" en ethresear, señalando que las futuras actualizaciones de PoS y fragmentación de Ethereum podrían utilizar el algoritmo de firma múltiple BLS basado en la curva BLS12-381. En ese momento, los investigadores de Ethereum esperaban resolver los problemas de la capa de consenso con EIP-1011, pero la propuesta de EIP-1011 podía acomodar un máximo de 900 validadores, estableciendo así una enorme escala de participación de 1500 ETH por validador. Con la propuesta del esquema de firma múltiple 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 llamar a la capa de ejecución de ETH que utiliza BLS12-381. En febrero de 2020, algunos investigadores propusieron EIP-2537, con la esperanza de que esta propuesta pudiera ser probada en conjunto en la red de prueba de ETH2. El autor de EIP-2537, Alex Stokes, hace un llamado en el artículo What eth2 needs from eth1 over the next six months para incluir EIP-2537 en la bifurcación dura de Berlín.
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 agitación
Antes de presentar el contenido posterior, necesitamos introducir primero el EIP-1962. EIP-1962 es la primera propuesta sobre la precompilación de emparejamientos de dominios de curvas elípticas presentada por Matter Labs en abril de 2019, y esta propuesta soporta tres curvas, que son:
BLS12
BN
MNT4/6 (Ate emparejamiento)
Esta EIP está diseñada para agregar una 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 es demasiado compleja para que los desarrolladores la implementen. Además, debido a que EIP1962 está altamente generalizado, para los ingenieros de contratos inteligentes, la invocación también es bastante problemática. Por supuesto, como proponente 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 abordar el problema del EIP-1962, Matter Labs propuso en febrero de 2020 varios EIP que descomponen el EIP-1962, y estos EIP heredan parcialmente la interfaz del EIP-1962. Estos EIP 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 esta propuesta no obtuvo finalmente un número EIP y no se puede encontrar en el sitio web oficial de documentos EIP.
Dentro de estos EIP, el más importante es el EIP-2537, porque la capa de consenso también utiliza la curva BLS12-381. Tanto el EIP-1962 como el EIP-2537 tienen como objetivo central implementar la verificación de firmas BLS en la capa de consenso de la red principal. En ese momento, ETH2 estaba desarrollando el diseño del contrato de depósito de la capa de consenso. Cuando se diseñó inicialmente el contrato de depósito, dado que la capa de ejecución no incluía el algoritmo de verificación BLS, el contrato de depósito no verificaría la firma; la firma BLS específica sería verificada por la capa de consenso después del depósito del usuario, y si se encuentra 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 ETH2 de los usuarios. Esta también fue la razón por la cual muchos desarrolladores estaban interesados en EIP-1962 y EIP-2537 en ese momento.
Cuando se propuso EIP-2537, Vitalik inmediatamente identificó una serie de problemas que existían en la EIP:
Estas consultas se centraron en el contenido del documento EIP, que luego fue respondido y discutido por los autores de EIP. Posteriormente, el 6 de marzo de 2020, los desarrolladores del núcleo de Ethereum discutieron EIP-2537 #82会议中 la reunión de desarrolladores del núcleo de Ethereum. Durante esta sesión, Vitalik argumentó que los EIP como EIP-2537 son muy efectivos para las pruebas recursivas de SNARK y no dañan Ethereum a largo plazo. Al mismo tiempo, se confirmó la prioridad de EIP-2537 y todos los clientes acordaron implementar EIP-2537 lo antes posible y planear 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 fue el primer proyecto discutido. Esta reunión confirmó que EIP-2537 reemplazaría a EIP-1962 como la propuesta principal de BLS y se incluiría en la lista de EIPs preseleccionados para la actualización de Berlín ( es Elegibilidad para Inclusión (EFI)).
En la reunión de desarrolladores de Ethereum Core de abril de 2020, #84会议内 reunión incluyó oficialmente EIP-2537 en la actualización de la bifurcación dura de Berlín y estableció un cronograma para que la actualización de Berlín se implemente en abril y se pruebe en mayo-junio. En particular, EIP-2537 fue catalogado como la prioridad más alta en esta discusión.
A continuación, 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é cuestiones sobre 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. Luego, los desarrolladores principales sincronizaron la situación actual de implementación, donde, debido a que el autor de EIP-2537, Matter Labs, ya había completado en gran medida la implementación en Rust, el cliente Besu declaró que había implementado en gran medida las funciones de EIP-2537. Sin embargo, el lado de Geth indicó que actualmente nadie está trabajando en la implementación de EIP-2537.
En la reunión de desarrolladores de Ethereum Core #86, diferentes implementaciones de nodos de Ethereum sincronizaron nuevamente el estado de implementación de EIP-2537, donde Geth indicó que 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 central de esta reunión de desarrolladores es el problema de implementación de EIP-2537. Los desarrolladores de Geth informaron que actualmente hay un PR de 16,000 líneas que implementa EIP-2537, pero los desarrolladores de Geth no pueden determinar si el PR es una implementación segura y efectiva de EIP-2537, por lo que los desarrolladores solo pueden juzgar el estado del código a través de pruebas de fuzzing simples y rudimentarias.
Los desarrolladores de Geth dicen: "Así que mi reacción instintiva es que no hay posibilidad de que Geth esté listo con las operaciones de la curva BLS para el lanzamiento de mainnet en julio." Es decir, es muy probable que Geth no complete el desarrollo relacionado con EIP-2537 antes de la fecha programada de Berlín.
Hudson Jameson propuso buscar ingenieros criptográficos para ayudar en la revisión de PR de Geth, y sugirió usar la red de prueba para evaluar 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 proporcionar un conocimiento de fondo, que es que la implementación EIP-2537 de Geth utiliza mucho código ensamblador para garantizar la eficiencia, y esta parte del código ensamblador es muy difícil de leer y comprender. Por lo tanto, Alex Vlasov sugiere eliminar las optimizaciones complejas de ensamblador dentro del PR para reducir la dificultad de revisión.
Ya hemos mencionado en el texto anterior que uno de los objetivos centrales de EIP-2537 es asistir al contrato de depósito de ETH2, pero en esta reunión, los desarrolladores del contrato de depósito indicaron que el contrato de depósito que no utiliza EIP-2537 ya ha sido auditado, por lo que algunos desarrolladores sugirieron que sería mejor no lanzar otro contrato de depósito que utilice EIP-2537.
Al final, la reunión decidió aumentar la red de prueba YOLO, cuyo núcleo es probar el EIP-2537. De hecho, en esta reunión, 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 han considerado que es muy probable que este EIP no se implemente antes de la actualización de Berlín. Parece que ya está decidido que el EIP-2537 no será aceptado en la actualización de Berlín.
En la reunión de desarrolladores del núcleo de Ethereum #88, los desarrolladores de Geth descubrieron una serie de problemas en la implementación del PR de EIP-2537, y los desarrolladores afirmaron que se necesita más pruebas y correcciones. En ese momento, había dos implementaciones de EIP-2537 en el sistema Geth, una de las cuales incluía optimización de ensamblador, mientras que la otra estaba completamente escrita en lenguaje go. Un desarrollador propuso usar la versión escrita en go para reducir la dificultad de la revisión del código.
En la reunión de desarrolladores de Ethereum Core Devs Meeting #89, surgieron problemas más graves, aparecieron algunos problemas en las pruebas de YOLO, los desarrolladores sospechan que son causados por la firma BLS, pero los desarrolladores de EIP2537 refutaron esto, argumentando que los problemas de la red de pruebas no son causados por la firma BLS. La buena noticia para EIP-2537 es que el contrato de depósito basado en EIP-2537 está prácticamente terminado, y este contrato está a la espera de una auditoría.
En la reunión de desarrolladores de Ethereum Core Devs Meeting #90内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91, un desarrollador propuso utilizar 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 de desarrolladores de Ethereum Core #96, Celo ha incluido simultáneamente EIP-2537 y EIP-2539 en su actualización de hard fork de la red, por lo que Matter Labs desea probar EIP-2539 en la red de prueba YOLO v2 y que entre en la actualización de Berlín al mismo tiempo que se propuso EIP-2537. Sin embargo, los desarrolladores de Geth se opusieron, argumentando que EIP-2537 aún no ha sido probado completamente internamente en Geth. Finalmente, la reunión decidió no añadir 2696 en la actualización de Berlín y dejarlo para futuras discusiones.
En la reunión de desarrolladores principales de Ethereum #99, se decidió retirar el EIP-2537 de la red de pruebas YOLO v3 y de la actualización de Berlín. 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 EIPs dentro de la actualización de Berlín. Un factor secundario es que la Fundación Ethereum propuso el EVM384 como sustituto del EIP-2537, ya que el EVM 384 ofrece una solución de cálculo de curvas elípticas más general. Sin embargo, los desarrolladores principales expresaron preocupaciones sobre 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. Las implementaciones reales de los EIP incluidos en la actualización, como el EIP-2565, no son complejas. Parece que la actualización de Berlin es un poco delgada, esto se debe a que el EIP-2537, que es el más complejo, fue eliminado de la actualización de Berlin.
desarrollo futuro
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 el caso de EIP-2537, que alguna vez fue una propuesta central, ha sido difícil incluir esta propuesta en las sucesivas actualizaciones.
En la actualización de Londres después de Berlín, los desarrolladores en issues#369曾考虑在 London 升级中增加 EIP-2537。在Ethereum Core Devs Meeting #109 sincronizaron el estado actual del desarrollo de EIP-2537. En este momento, debido a la implementación de EIP-2537 utilizando otras bibliotecas, se introdujo una discusión sobre el uso de gas de EIP-2537. Al mismo tiempo, algunos desarrolladores propusieron reemplazar EIP-2537 por EVM384. Sin embargo, en la reunión de desarrolladores principales de Ethereum #111 en abril de 2021, EIP-2537 fue descartado de la actualización de Londres debido a su complejidad. La complejidad principal radica en que la implementación estándar de EIP-2537 cambió las bibliotecas de dependencia, lo que podría causar cambios en la fijación de precios del gas; las diferentes implementaciones de clientes necesitarían un tiempo considerable para reevaluar el consumo de gas.
En junio de 2021, se propuso formalmente incluir 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 Londres, la actualización de Pairs, también conocida como The Merge, ocupó una gran parte del tiempo de los desarrolladores, quienes tuvieron que escribir una gran cantidad de código para implementar la actualización de PoS. En septiembre de 2022, se completó la actualización de Pairs y los desarrolladores de la capa de ejecución finalmente tuvieron la oportunidad de continuar discutiendo algunos de los 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 el EIP-2537 en la actualización de Shanghai, pero los desarrolladores consideraron que el EIP-2537 debía posponerse, ya que el núcleo de la actualización de Shanghai es el soporte para retiros de PoS. Al final, el EIP-2537 no fue incluido en la actualización de Shanghai, que tiene como objetivo principal la funcionalidad de retiros.
Más trágico 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 Blob para la segunda capa de Ethereum para facilitar que la segunda capa use Ethereum como capa de disponibilidad de datos.
Finalmente, en la reunión de desarrolladores centrales 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 sobre la redistribución del precio de la precompilación BLS. Jared Wasinger, un desarrollador de Geth, sugirió aumentar el costo de gas en un 20%, y recibió el respaldo de las pruebas de referencia del equipo de Besu.
resumen
| Fecha | Evento |
| --- | --- |
| Febrero de 2020 | Se propone oficialmente EIP-1962 y se divide EIP-2537 |
| Abril de 2020 - Octubre de 2020 | La conferencia de desarrolladores discutió en varias ocasiones los problemas de implementación de EIP-2537, y finalmente fue abandonado en la actualización de Berlín debido a la imposibilidad de su implementación |
| Marzo de 2021 - Abril de 2021 | La reunión de desarrolladores discutió el problema del costo de gas de EIP-2537, que finalmente fue abandonado en la actualización de Londres debido a su complejidad |
| Noviembre de 2022 | reunión de desarrolladores discutió si incluir la actualización de Shanghai, sin resultados |
| Febrero de 2024 | Los desarrolladores creen que EIP-2537 no tiene problemas de implementación, pero todavía existen algunos problemas de costo de gas, y piensan que se puede incluir en la actualización de Pectra |
| Diciembre de 2024 - Enero de 2025 | Reunión de desarrolladores para discutir un modelo de cálculo de costos específico, resolviendo oficialmente el problema de costos de EIP-2537 |
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 fue una vez el EIP más importante de la actualización de Berlín, pero fue descartado debido a la dificultad y complejidad de su implementación. Posteriormente, Ethereum entró en el proceso histórico de PoS, donde los EIP de capa de ejecución pura complejos no recibieron atención, mientras que una gran cantidad de EIP de ejecución relacionados con PoS se consideraron objetivos de actualización centrales, lo que resultó en 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.
Observación de la gobernanza de Ethereum: Proceso de precompilación de EIP-2537
Autor: shew
Resumen
EIP-2537 es la instrucción de preensamblado EVM que se ha determinado agregar en la última actualización bifurcada de Pectra. Esta instrucción añade diversas funciones de cálculo de la curva BLS12-381 al EVM, como el cálculo de pares en el dominio de la curva.
EIP-2573 fue propuesto por primera vez en 2020 y no fue confirmado para ser incluido en la actualización de Ethereum hasta 2025. Este artículo presenta la historia de 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ó el algoritmo de emparejamiento y la curva
alt_bn128en Exploring Elliptic Curve Pairings. Luego, en febrero de 2017, Vitalik Buterin y Christian Reitwiessner propusieron las propuestas EIP-196 y EIP-197, cuyo contenido era añadir soporte para cálculos de la curvaalt_bn128en la EVM.En la actualización de Byzantium de octubre de 2017, se incorporó oficialmente la curva
alt_bn128. En pocas palabras,alt_bn128implementó por primera vez el cálculo de pares de campos de curvas dentro de la EVM, lo que permitió que la verificación de pruebas ZK-Snarks se pudiera realizar dentro de la EVM.Pero a medida que la criptografía avanzaba, en noviembre de 2017, el equipo de desarrollo de zcash presentó la curva
BLS12-381en BLS12-381: New zk-SNARK Elliptic Curve Construction. En comparación conalt_bn128,BLS12-381ofrece mayor seguridad y mejor rendimiento. Muchos protocolos de blockchain comenzaron a utilizar la curvaBLS12-381y descontinuaron la curvaalt_bn128.En mayo de 2018, Justin Drake publicó un artículo titulado "Agregación de firmas pragmáticas con BLS" en ethresear, señalando que las futuras actualizaciones de PoS y fragmentación de Ethereum podrían utilizar el algoritmo de firma múltiple BLS basado en la curva
BLS12-381. En ese momento, los investigadores de Ethereum esperaban resolver los problemas de la capa de consenso con EIP-1011, pero la propuesta de EIP-1011 podía acomodar un máximo de 900 validadores, estableciendo así una enorme escala de participación de 1500 ETH por validador. Con la propuesta del esquema de firma múltiple BLS, EIP-1011 salió del escenario histórico. Resultó que la posterior actualización de ETH2 también utilizó finalmente la curvaBLS12-381.Con el desarrollo de ETH2, se ha comenzado a llamar a la capa de ejecución de ETH que utiliza
BLS12-381. En febrero de 2020, algunos investigadores propusieron EIP-2537, con la esperanza de que esta propuesta pudiera ser probada en conjunto en la red de prueba de ETH2. El autor de EIP-2537, Alex Stokes, hace un llamado en el artículo What eth2 needs from eth1 over the next six months para incluir EIP-2537 en la bifurcación dura de Berlín.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 agitación
Antes de presentar el contenido posterior, necesitamos introducir primero el EIP-1962. EIP-1962 es la primera propuesta sobre la precompilación de emparejamientos de dominios de curvas elípticas presentada por Matter Labs en abril de 2019, y esta propuesta soporta tres curvas, que son:
Esta EIP está diseñada para agregar una 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 es demasiado compleja para que los desarrolladores la implementen. Además, debido a que EIP1962 está altamente generalizado, para los ingenieros de contratos inteligentes, la invocación también es bastante problemática. Por supuesto, como proponente 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 abordar el problema del EIP-1962, Matter Labs propuso en febrero de 2020 varios EIP que descomponen el EIP-1962, y estos EIP heredan parcialmente la interfaz del EIP-1962. Estos EIP incluyen:
Dentro de estos EIP, el más importante es el EIP-2537, porque la capa de consenso también utiliza la curva BLS12-381. Tanto el EIP-1962 como el EIP-2537 tienen como objetivo central implementar la verificación de firmas BLS en la capa de consenso de la red principal. En ese momento, ETH2 estaba desarrollando el diseño del contrato de depósito de la capa de consenso. Cuando se diseñó inicialmente el contrato de depósito, dado que la capa de ejecución no incluía el algoritmo de verificación BLS, el contrato de depósito no verificaría la firma; la firma BLS específica sería verificada por la capa de consenso después del depósito del usuario, y si se encuentra 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 ETH2 de los usuarios. Esta también fue la razón por la cual muchos desarrolladores estaban interesados en EIP-1962 y EIP-2537 en ese momento.
Cuando se propuso EIP-2537, Vitalik inmediatamente identificó una serie de problemas que existían en la EIP:
Estas consultas se centraron en el contenido del documento EIP, que luego fue respondido y discutido por los autores de EIP. Posteriormente, el 6 de marzo de 2020, los desarrolladores del núcleo de Ethereum discutieron EIP-2537 #82会议中 la reunión de desarrolladores del núcleo de Ethereum. Durante esta sesión, Vitalik argumentó que los EIP como EIP-2537 son muy efectivos para las pruebas recursivas de SNARK y no dañan Ethereum a largo plazo. Al mismo tiempo, se confirmó la prioridad de EIP-2537 y todos los clientes acordaron implementar EIP-2537 lo antes posible y planear 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 fue el primer proyecto discutido. Esta reunión confirmó que EIP-2537 reemplazaría a EIP-1962 como la propuesta principal de BLS y se incluiría en la lista de EIPs preseleccionados para la actualización de Berlín ( es Elegibilidad para Inclusión (EFI)).
En la reunión de desarrolladores de Ethereum Core de abril de 2020, #84会议内 reunión incluyó oficialmente EIP-2537 en la actualización de la bifurcación dura de Berlín y estableció un cronograma para que la actualización de Berlín se implemente en abril y se pruebe en mayo-junio. En particular, EIP-2537 fue catalogado como la prioridad más alta en esta discusión.
A continuación, 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é cuestiones sobre 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. Luego, los desarrolladores principales sincronizaron la situación actual de implementación, donde, debido a que el autor de EIP-2537, Matter Labs, ya había completado en gran medida la implementación en Rust, el cliente Besu declaró que había implementado en gran medida las funciones de EIP-2537. Sin embargo, el lado de Geth indicó que actualmente nadie está trabajando en la implementación de EIP-2537.
En la reunión de desarrolladores de Ethereum Core #86, diferentes implementaciones de nodos de Ethereum sincronizaron nuevamente el estado de implementación de EIP-2537, donde Geth indicó que 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 central de esta reunión de desarrolladores es el problema de implementación de EIP-2537. Los desarrolladores de Geth informaron que actualmente hay un PR de 16,000 líneas que implementa EIP-2537, pero los desarrolladores de Geth no pueden determinar si el PR es una implementación segura y efectiva de EIP-2537, por lo que los desarrolladores solo pueden juzgar el estado del código a través de pruebas de fuzzing simples y rudimentarias.
Los desarrolladores de Geth dicen: "Así que mi reacción instintiva es que no hay posibilidad de que Geth esté listo con las operaciones de la curva BLS para el lanzamiento de mainnet en julio." Es decir, es muy probable que Geth no complete el desarrollo relacionado con EIP-2537 antes de la fecha programada de Berlín.
Hudson Jameson propuso buscar ingenieros criptográficos para ayudar en la revisión de PR de Geth, y sugirió usar la red de prueba para evaluar 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 proporcionar un conocimiento de fondo, que es que la implementación EIP-2537 de Geth utiliza mucho código ensamblador para garantizar la eficiencia, y esta parte del código ensamblador es muy difícil de leer y comprender. Por lo tanto, Alex Vlasov sugiere eliminar las optimizaciones complejas de ensamblador dentro del PR para reducir la dificultad de revisión.
Ya hemos mencionado en el texto anterior que uno de los objetivos centrales de EIP-2537 es asistir al contrato de depósito de ETH2, pero en esta reunión, los desarrolladores del contrato de depósito indicaron que el contrato de depósito que no utiliza EIP-2537 ya ha sido auditado, por lo que algunos desarrolladores sugirieron que sería mejor no lanzar otro contrato de depósito que utilice EIP-2537.
Al final, la reunión decidió aumentar la red de prueba YOLO, cuyo núcleo es probar el EIP-2537. De hecho, en esta reunión, 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 han considerado que es muy probable que este EIP no se implemente antes de la actualización de Berlín. Parece que ya está decidido que el EIP-2537 no será aceptado en la actualización de Berlín.
En la reunión de desarrolladores del núcleo de Ethereum #88, los desarrolladores de Geth descubrieron una serie de problemas en la implementación del PR de EIP-2537, y los desarrolladores afirmaron que se necesita más pruebas y correcciones. En ese momento, había dos implementaciones de EIP-2537 en el sistema Geth, una de las cuales incluía optimización de ensamblador, mientras que la otra estaba completamente escrita en lenguaje go. Un desarrollador propuso usar la versión escrita en go para reducir la dificultad de la revisión del código.
En la reunión de desarrolladores de Ethereum Core Devs Meeting #89, surgieron problemas más graves, aparecieron algunos problemas en las pruebas de YOLO, los desarrolladores sospechan que son causados por la firma BLS, pero los desarrolladores de EIP2537 refutaron esto, argumentando que los problemas de la red de pruebas no son causados por la firma BLS. La buena noticia para EIP-2537 es que el contrato de depósito basado en EIP-2537 está prácticamente terminado, y este contrato está a la espera de una auditoría.
En la reunión de desarrolladores de Ethereum Core Devs Meeting #90内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91, un desarrollador propuso utilizar 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 de desarrolladores de Ethereum Core #96, Celo ha incluido simultáneamente EIP-2537 y EIP-2539 en su actualización de hard fork de la red, por lo que Matter Labs desea probar EIP-2539 en la red de prueba YOLO v2 y que entre en la actualización de Berlín al mismo tiempo que se propuso EIP-2537. Sin embargo, los desarrolladores de Geth se opusieron, argumentando que EIP-2537 aún no ha sido probado completamente internamente en Geth. Finalmente, la reunión decidió no añadir 2696 en la actualización de Berlín y dejarlo para futuras discusiones.
En la reunión de desarrolladores principales de Ethereum #99, se decidió retirar el EIP-2537 de la red de pruebas YOLO v3 y de la actualización de Berlín. 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 EIPs dentro de la actualización de Berlín. Un factor secundario es que la Fundación Ethereum propuso el EVM384 como sustituto del EIP-2537, ya que el EVM 384 ofrece una solución de cálculo de curvas elípticas más general. Sin embargo, los desarrolladores principales expresaron preocupaciones sobre 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. Las implementaciones reales de los EIP incluidos en la actualización, como el EIP-2565, no son complejas. Parece que la actualización de Berlin es un poco delgada, esto se debe a que el EIP-2537, que es el más complejo, fue eliminado de la actualización de Berlin.
desarrollo futuro
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 el caso de EIP-2537, que alguna vez fue una propuesta central, ha sido difícil incluir esta propuesta en las sucesivas actualizaciones.
En la actualización de Londres después de Berlín, los desarrolladores en issues#369曾考虑在 London 升级中增加 EIP-2537。在Ethereum Core Devs Meeting #109 sincronizaron el estado actual del desarrollo de EIP-2537. En este momento, debido a la implementación de EIP-2537 utilizando otras bibliotecas, se introdujo una discusión sobre el uso de gas de EIP-2537. Al mismo tiempo, algunos desarrolladores propusieron reemplazar EIP-2537 por EVM384. Sin embargo, en la reunión de desarrolladores principales de Ethereum #111 en abril de 2021, EIP-2537 fue descartado de la actualización de Londres debido a su complejidad. La complejidad principal radica en que la implementación estándar de EIP-2537 cambió las bibliotecas de dependencia, lo que podría causar cambios en la fijación de precios del gas; las diferentes implementaciones de clientes necesitarían un tiempo considerable para reevaluar el consumo de gas.
En junio de 2021, se propuso formalmente incluir 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 Londres, la actualización de Pairs, también conocida como The Merge, ocupó una gran parte del tiempo de los desarrolladores, quienes tuvieron que escribir una gran cantidad de código para implementar la actualización de PoS. En septiembre de 2022, se completó la actualización de Pairs y los desarrolladores de la capa de ejecución finalmente tuvieron la oportunidad de continuar discutiendo algunos de los 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 el EIP-2537 en la actualización de Shanghai, pero los desarrolladores consideraron que el EIP-2537 debía posponerse, ya que el núcleo de la actualización de Shanghai es el soporte para retiros de PoS. Al final, el EIP-2537 no fue incluido en la actualización de Shanghai, que tiene como objetivo principal la funcionalidad de retiros.
Más trágico 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 Blob para la segunda capa de Ethereum para facilitar que la segunda capa use Ethereum como capa de disponibilidad de datos.
Finalmente, en la reunión de desarrolladores centrales 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 sobre la redistribución del precio de la precompilación BLS. Jared Wasinger, un desarrollador de Geth, sugirió aumentar el costo de gas en un 20%, y recibió el respaldo de las pruebas de referencia del equipo de Besu.
resumen
| Fecha | Evento | | --- | --- | | Febrero de 2020 | Se propone oficialmente EIP-1962 y se divide EIP-2537 | | Abril de 2020 - Octubre de 2020 | La conferencia de desarrolladores discutió en varias ocasiones los problemas de implementación de EIP-2537, y finalmente fue abandonado en la actualización de Berlín debido a la imposibilidad de su implementación | | Marzo de 2021 - Abril de 2021 | La reunión de desarrolladores discutió el problema del costo de gas de EIP-2537, que finalmente fue abandonado en la actualización de Londres debido a su complejidad | | Noviembre de 2022 | reunión de desarrolladores discutió si incluir la actualización de Shanghai, sin resultados | | Febrero de 2024 | Los desarrolladores creen que EIP-2537 no tiene problemas de implementación, pero todavía existen algunos problemas de costo de gas, y piensan que se puede incluir en la actualización de Pectra | | Diciembre de 2024 - Enero de 2025 | Reunión de desarrolladores para discutir un modelo de cálculo de costos específico, resolviendo oficialmente el problema de costos de EIP-2537 |
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 fue una vez el EIP más importante de la actualización de Berlín, pero fue descartado debido a la dificultad y complejidad de su implementación. Posteriormente, Ethereum entró en el proceso histórico de PoS, donde los EIP de capa de ejecución pura complejos no recibieron atención, mientras que una gran cantidad de EIP de ejecución relacionados con PoS se consideraron objetivos de actualización centrales, lo que resultó en que el EIP-2537 no fuera aceptado durante un largo período.