EIP-2537: Un largo camino desde la controversia hasta la adopción
EIP-2537 es una instrucción de precompilación de EVM que se ha determinado agregar en la última actualización del fork Pectra de Ethereum. Esta instrucción agrega diversas funcionalidades de cálculo de la curva BLS12-381 a EVM, como el cálculo de emparejamientos en el dominio de la curva.
EIP-2537 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 presentará el proceso de gobernanza de EIP-2537 y explorará por qué esta propuesta tardó 5 años en ser finalmente adoptada.
Antecedentes de la propuesta
En enero de 2017, Vitalik Buterin presentó por primera vez el algoritmo de emparejamiento y la curva alt_bn128 en un artículo. Posteriormente, Vitalik y Christian Reitwiessner propusieron EIP-196 y EIP-197, sugiriendo agregar soporte para el cálculo de la curva alt_bn128 en la EVM.
La actualización de Bizancio en octubre de 2017 introdujo oficialmente la curva alt_bn128, permitiendo el cálculo de pares de dominio de curvas dentro de la EVM, lo que hace posible 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 propuso la curva BLS12-381. En comparación con alt_bn128, BLS12-381 tiene una mayor seguridad y un mejor rendimiento. Muchos protocolos de blockchain adoptaron posteriormente la curva BLS12-381, abandonando alt_bn128.
En mayo de 2018, Justin Drake publicó un artículo 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. Esta solución resuelve el problema del número limitado de validadores en los primeros esquemas de PoS. De hecho, las posteriores actualizaciones de ETH2 adoptaron la curva BLS12-381.
Con el avance del desarrollo de ETH2, la demanda de introducir BLS12-381 en la capa de ejecución de ETH está en aumento. En febrero de 2020, los investigadores propusieron EIP-2537 y esperaban que esta propuesta pudiera ser probada junto con la red de prueba de ETH2. El autor de EIP-2537, Alex Stokes, hizo un llamado para que se incluya esta propuesta en la bifurcación dura de Berlín.
Cabe destacar que el autor de EIP-2537 también es cofundador de Matter Labs, la empresa desarrolladora de ZKSync.
Las dificultades de la actualización de Berlín
Antes de presentar los avances posteriores, necesitamos entender primero el EIP-1962. Esta es la primera propuesta sobre la precompilación de emparejamiento de curvas elípticas presentada por Matter Labs en abril de 2019, que admite tres curvas: BLS12, BN y MNT4/6.
El plan EIP-1962 propone agregar 10 instrucciones predefinidas de una sola vez para manejar diferentes curvas. Sin embargo, esta propuesta ha sido cuestionada por muchos desarrolladores, quienes consideran que es demasiado compleja y difícil de implementar. Al mismo tiempo, debido a su alta generalización, también es complicado para los ingenieros de contratos inteligentes realizar las llamadas. Sin embargo, como parte proponente, Matter Labs ya ha completado el trabajo de desarrollo del algoritmo de curvas elípticas y ha proporcionado implementaciones de referencia en varios lenguajes.
Para resolver el problema de EIP-1962, Matter Labs propuso en febrero de 2020 varios EIP para descomponer EIP-1962, estos EIP heredan parcialmente la interfaz de EIP-1962:
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 esta propuesta no recibió un número EIP al final.
Lo más importante es EIP-2537, ya que la capa de consenso también utiliza la curva BLS12-381. Los objetivos principales de EIP-1962 y EIP-2537 son implementar la verificación de firmas BLS en la capa de consenso de la red principal. En ese momento, ETH2 estaba desarrollando el contrato de depósito de la capa de consenso. En el diseño inicial, debido a 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 de que el usuario hiciera el depósito. Si se detectaba un error, el depósito fallaría y el ETH depositado por el usuario podría perderse.
En este contexto, los desarrolladores principales desean introducir la precompilación BLS12-381 en el contrato de depósito para implementar la verificación de firmas y evitar la posible pérdida de fondos de los usuarios. Esta también fue la razón por la cual muchos desarrolladores prestaron atención a EIP-1962 y EIP-2537 en ese momento.
Cuando se propuso por primera vez el EIP-2537, Vitalik señaló una serie de problemas existentes en la propuesta. Estas dudas se centraron principalmente en el contenido del documento EIP, y posteriormente los autores del EIP respondieron y discutieron al respecto.
La 82ª reunión de desarrolladores centrales de Ethereum, que tuvo lugar el 6 de marzo de 2020, discutió el EIP-2537. Vitalik considera que este EIP es muy efectivo para las pruebas SNARK recursivas y que, a largo plazo, no tendrá un impacto negativo en Ethereum. La reunión confirmó la prioridad del EIP-2537, y todos los clientes acordaron implementar este EIP lo antes posible, con la intención de completar todo el desarrollo antes de la actualización de Berlín.
Luego, el EIP-2537 se convirtió en una tarea de alta prioridad. En la 83ª reunión de desarrolladores principales del 20 de marzo, se volvió a presentar como la propuesta principal en discusión. La reunión confirmó que el EIP-2537 reemplazaría al EIP-1962 como la propuesta central de BLS y se incluiría en la lista de preselección de la actualización de Berlín.
La 84ª reunión de abril incluyó oficialmente el EIP-2537 en la actualización del hard fork de Berlín y estableció la línea de tiempo para su implementación en abril y pruebas en mayo y junio. Es importante destacar que el EIP-2537 fue clasificado como un asunto de máxima prioridad en esta discusión.
A partir de entonces, EIP-2537 entró en una fase de desarrollo y pruebas intensivas, y casi en cada una de las cerca de 20 reuniones de desarrolladores principales posteriores se discutió el tema.
En la 85ª reunión, los desarrolladores discutieron el problema de codificación ABI de EIP-2537. Dado que Matter Labs ya había completado básicamente la implementación de la versión en Rust, el cliente Besu indicó que había implementado básicamente la funcionalidad de EIP-2537, pero desde Geth afirmaron que actualmente no hay nadie trabajando en el tema.
En la 86ª reunión, diferentes nodos lograron sincronizar nuevamente los avances de EIP-2537, Geth indicó que se ha completado parte del trabajo, pero aún quedan muchas tareas por hacer.
La 87ª reunión se centró en los problemas de implementación de EIP-2537. Los desarrolladores de Geth indicaron que existe un PR de 16000 líneas que implementa EIP-2537, pero no se puede determinar si ese PR implementa EIP-2537 de manera segura y efectiva, solo se puede juzgar el estado del código a través de las pruebas de fuzzing más simples.
Los desarrolladores de Geth dijeron: "Según mi intuición, Geth no podrá tener listas las operaciones de la curva BLS antes del lanzamiento de la red principal en julio."
Hudson Jameson propuso buscar ingenieros criptográficos para ayudar con la revisión de PR de Geth y sugirió utilizar la red de pruebas para probar la seguridad de la implementación de EIP-2537. Dado que el equipo de desarrollo de ETH2 también está implementando la verificación de firmas BLS, puede participar en las pruebas.
Es importante añadir que la implementación de EIP-2537 de Geth utiliza en gran medida código ensamblador para garantizar la eficiencia, lo que hace que esta parte del código sea muy difícil de leer y entender. Alex Vlasov sugiere eliminar las optimizaciones de ensamblador complejas en el PR para reducir la dificultad de revisión.
Un objetivo central 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 usarán el contrato de EIP-2537 que ya ha sido auditado. Algunos desarrolladores creen que es mejor no lanzar una nueva versión del contrato que use EIP-2537.
Finalmente, la reunión decidió aumentar la red de pruebas YOLO, dedicada a probar el EIP-2537. De hecho, de esta reunión se puede ver que, con la finalización del contrato de depósito, la importancia del EIP-2537 ha disminuido drásticamente, mientras que los desarrolladores de Geth consideran que es muy probable que este EIP no se implemente antes de la actualización de Berlín. Parece que la no adopción del EIP-2537 en la actualización de Berlín ya es un hecho consumado.
En la 88ª reunión, los desarrolladores de Geth encontraron una serie de problemas en la implementación del PR de EIP-2537, indicando que se necesita más pruebas y correcciones. En ese momento, había dos implementaciones de EIP-2537 en el sistema Geth, una que incluía optimizaciones en ensamblador y otra completamente escrita en Go. Un desarrollador sugirió usar directamente la versión en Go para reducir la dificultad de la revisión del código.
En la 89ª reunión surgieron problemas más graves, la red de pruebas YOLO presentó algunas anomalías, los desarrolladores sospechan que son causadas por la firma BLS, pero los desarrolladores de EIP-2537 refutaron esto. La buena noticia es que el contrato de depósito basado en EIP-2537 está prácticamente completado y está esperando auditoría.
La novena reunión determinó la fecha límite para el lanzamiento de la actualización Berlin en julio. La reunión también discutió el problema de la diversidad de clientes, principalmente relacionado con la situación dominante de Geth, y algunos desarrolladores sugirieron congelar la implementación actual del EIP para reducir los costos de desarrollo de otros clientes. En la décima reunión, un desarrollador propuso utilizar un enfoque modular para reducir los costos de desarrollo y aumentar la diversidad de clientes.
La 92ª reunión seguirá confirmando el EIP-2537 como el EIP necesario para la actualización de Berlín.
En la 96ª reunión, dado que Celo ha incorporado simultáneamente EIP-2537 y EIP-2539 en su bifurcación dura de la red, Matter Labs desea incluir EIP-2539 en las pruebas de YOLO v2 y en la actualización de Berlín. Sin embargo, los desarrolladores de Geth se oponen, argumentando que EIP-2537 aún no se ha probado completamente en Geth. Finalmente, la reunión decidió no añadir EIP-2696 en la actualización de Berlín, dejando su discusión para el futuro.
La 99ª reunión decidió sacar el EIP-2537 de la red de prueba YOLO v3 y de la actualización de Berlín, siendo la razón principal que el EIP-2537 ha consumido demasiado tiempo de los desarrolladores principales, lo que ha bloqueado el desarrollo de otros EIP para la actualización de Berlín. Un factor secundario es que la Fundación Ethereum propuso el EVM384 como un reemplazo para el EIP-2537, ofreciendo una solución de cálculo de curvas elípticas más general. Sin embargo, los desarrolladores principales expresaron preocupaciones sobre la seguridad.
Este es el recorrido temprano de EIP-2537. Podemos ver que EIP-2537 fue inicialmente uno de los EIP más importantes en la actualización de Berlin, pero fue desechado debido a problemas de implementación. En abril de 2021, Ethereum completó la actualización de Berlin, los EIP centrales como EIP-2565 no son realmente complejos de implementar, y la actualización parece un poco escasa, precisamente porque el EIP-2537, que era el más complejo, fue eliminado.
Desarrollo futuro
Como es bien sabido, cada actualización de Ethereum tiene una propuesta central. La actualización de Londres después de Berlín introdujo la propuesta de tarifas más importante en la historia de Ethereum, EIP-1559. Para la antigua propuesta central EIP-2537, es difícil que las actualizaciones posteriores la incluyan.
La actualización de Londres después de Berlín está en progreso, y los desarrolladores están considerando agregar EIP-2537 en issues#369. La 109ª reunión de desarrolladores principales sincronizó el estado de desarrollo de EIP-2537, y debido a la implementación utilizando otras bibliotecas, se generó una discusión sobre el uso de gas. Un desarrollador propuso reemplazar EIP-2537 con EVM384. Sin embargo, en la 111ª reunión de abril de 2021, EIP-2537 fue eliminado de la actualización de Londres debido a su complejidad. La razón principal es que la implementación del estándar EIP-2537 cambió las bibliotecas de dependencia, lo que podría afectar los precios del gas, y la implementación en diferentes clientes requeriría mucho tiempo para reevaluar el consumo de gas.
En junio de 2021, se propuso oficialmente el EIP-2537 para ser incluido en la actualización de Shanghai a través del issues#343. Sin embargo, después de la actualización de Londres, The Merge ocupó gran parte del tiempo de los desarrolladores, y los desarrolladores de la capa de ejecución necesitaron escribir una gran cantidad de código para implementar la actualización de PoS. En septiembre de 2022, después de completar The Merge, los desarrolladores de la capa de ejecución finalmente tuvieron la oportunidad de continuar discutiendo los objetivos de la actualización de Shanghai.
En noviembre de 2022, en la 150ª reunión de desarrolladores principales, se discutió brevemente si incluir EIP-2537 en Shanghai, pero los desarrolladores consideraron que debería posponerse. El núcleo de Shanghai es el soporte para retiros de PoS. Finalmente, EIP-2537 no fue incluido en la actualización de Shanghai centrada en los retiros.
Desafortunadamente, la actualización de Cancun no ha discutido EIP-2537, ya que el enfoque de Cancun es apoyar EIP-4844, proporcionando Blob para la segunda capa de Ethereum para que la segunda capa utilice Ethereum como capa de disponibilidad de datos.
Hasta la 181ª reunión de desarrolladores principales en febrero de 2024, los desarrolladores solo discutieron la inclusión de EIP-2537 en la actualización de Pectra. En ese momento, los desarrolladores consideraban que la implementación de EIP-2537 ya no era un problema, solo quedaba por resolver algunos problemas de precios del consumo de gas.
En la 202ª reunión del 19 de diciembre de 2024, los desarrolladores de Nethermind finalmente confirmaron el modelo de precios de EIP-2537. Es importante destacar que Matter Labs, el proponente inicial de EIP-2537, se había retirado prácticamente de la discusión en ese momento. La 203ª reunión de enero de 2025 discutió la revalorización de la precompilación BLS, el desarrollador de Geth Jared Wasinger sugirió aumentar el costo de gas en un 20%, y recibió el apoyo de las pruebas de referencia del equipo de Besu.
Resumen
EIP-2537 pasó por un largo y tortuoso proceso desde su propuesta hasta su adopción final:
Febrero de 2020: se propuso oficialmente EIP-2537, que se separó de EIP-1962
Abril-Octubre de 2020: Se discutieron múltiples problemas de implementación, y finalmente se abandonó la actualización de Berlín debido a la imposibilidad de implementación.
Marzo-Abril de 2021: Se discutió el problema del costo del gas, que fue abandonado en la actualización de Londres debido a su complejidad.
Noviembre de 2022: discusión sobre si incluir la actualización de Shanghai, sin resultados.
Febrero de 2024: Se considera que la realización ya no es un problema, aunque todavía existen algunos problemas de costo de gas, que se pueden incluir en la actualización de Pectra.
Diciembre de 2024 - Enero de 2025: Discutir el modelo de cálculo de costos específico y resolver formalmente los costos de gas.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
12 me gusta
Recompensa
12
6
Compartir
Comentar
0/400
StableGenius
· 08-03 06:12
empíricamente hablando, les tomó 5 años hacer lo que debería haberse hecho en 6 meses. clásico teatro de gobernanza de eth
Ver originalesResponder0
RugResistant
· 08-01 07:29
analizó el eip. las posibles banderas rojas en la implementación de bls necesitan una auditoría más profunda, para ser honesto
Ver originalesResponder0
NFTDreamer
· 08-01 07:29
¡Vaya! Vitalik Buterin ya quería hacer esto.
Ver originalesResponder0
TokenSleuth
· 08-01 07:29
Ah, ¿realmente tengo que esperar cinco años? Es bastante molesto.
Ver originalesResponder0
0xSunnyDay
· 08-01 07:14
5 años esperando un eip, es muy difícil.
Ver originalesResponder0
LiquidityHunter
· 08-01 07:11
Zut, Ethereum esta acción tan lenta que ya me he cansado de esperar.
EIP-2537: Una importante actualización de Ethereum que ha pasado de la controversia a la adopción después de 5 años.
EIP-2537: Un largo camino desde la controversia hasta la adopción
EIP-2537 es una instrucción de precompilación de EVM que se ha determinado agregar en la última actualización del fork Pectra de Ethereum. Esta instrucción agrega diversas funcionalidades de cálculo de la curva BLS12-381 a EVM, como el cálculo de emparejamientos en el dominio de la curva.
EIP-2537 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 presentará el proceso de gobernanza de EIP-2537 y explorará por qué esta propuesta tardó 5 años en ser finalmente adoptada.
Antecedentes de la propuesta
En enero de 2017, Vitalik Buterin presentó por primera vez el algoritmo de emparejamiento y la curva alt_bn128 en un artículo. Posteriormente, Vitalik y Christian Reitwiessner propusieron EIP-196 y EIP-197, sugiriendo agregar soporte para el cálculo de la curva alt_bn128 en la EVM.
La actualización de Bizancio en octubre de 2017 introdujo oficialmente la curva alt_bn128, permitiendo el cálculo de pares de dominio de curvas dentro de la EVM, lo que hace posible 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 propuso la curva BLS12-381. En comparación con alt_bn128, BLS12-381 tiene una mayor seguridad y un mejor rendimiento. Muchos protocolos de blockchain adoptaron posteriormente la curva BLS12-381, abandonando alt_bn128.
En mayo de 2018, Justin Drake publicó un artículo 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. Esta solución resuelve el problema del número limitado de validadores en los primeros esquemas de PoS. De hecho, las posteriores actualizaciones de ETH2 adoptaron la curva BLS12-381.
Con el avance del desarrollo de ETH2, la demanda de introducir BLS12-381 en la capa de ejecución de ETH está en aumento. En febrero de 2020, los investigadores propusieron EIP-2537 y esperaban que esta propuesta pudiera ser probada junto con la red de prueba de ETH2. El autor de EIP-2537, Alex Stokes, hizo un llamado para que se incluya esta propuesta en la bifurcación dura de Berlín.
Cabe destacar que el autor de EIP-2537 también es cofundador de Matter Labs, la empresa desarrolladora de ZKSync.
Las dificultades de la actualización de Berlín
Antes de presentar los avances posteriores, necesitamos entender primero el EIP-1962. Esta es la primera propuesta sobre la precompilación de emparejamiento de curvas elípticas presentada por Matter Labs en abril de 2019, que admite tres curvas: BLS12, BN y MNT4/6.
El plan EIP-1962 propone agregar 10 instrucciones predefinidas de una sola vez para manejar diferentes curvas. Sin embargo, esta propuesta ha sido cuestionada por muchos desarrolladores, quienes consideran que es demasiado compleja y difícil de implementar. Al mismo tiempo, debido a su alta generalización, también es complicado para los ingenieros de contratos inteligentes realizar las llamadas. Sin embargo, como parte proponente, Matter Labs ya ha completado el trabajo de desarrollo del algoritmo de curvas elípticas y ha proporcionado implementaciones de referencia en varios lenguajes.
Para resolver el problema de EIP-1962, Matter Labs propuso en febrero de 2020 varios EIP para descomponer EIP-1962, estos EIP heredan parcialmente la interfaz de EIP-1962:
Lo más importante es EIP-2537, ya que la capa de consenso también utiliza la curva BLS12-381. Los objetivos principales de EIP-1962 y EIP-2537 son implementar la verificación de firmas BLS en la capa de consenso de la red principal. En ese momento, ETH2 estaba desarrollando el contrato de depósito de la capa de consenso. En el diseño inicial, debido a 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 de que el usuario hiciera el depósito. Si se detectaba un error, el depósito fallaría y el ETH depositado por el usuario podría perderse.
En este contexto, los desarrolladores principales desean introducir la precompilación BLS12-381 en el contrato de depósito para implementar la verificación de firmas y evitar la posible pérdida de fondos de los usuarios. Esta también fue la razón por la cual muchos desarrolladores prestaron atención a EIP-1962 y EIP-2537 en ese momento.
Cuando se propuso por primera vez el EIP-2537, Vitalik señaló una serie de problemas existentes en la propuesta. Estas dudas se centraron principalmente en el contenido del documento EIP, y posteriormente los autores del EIP respondieron y discutieron al respecto.
La 82ª reunión de desarrolladores centrales de Ethereum, que tuvo lugar el 6 de marzo de 2020, discutió el EIP-2537. Vitalik considera que este EIP es muy efectivo para las pruebas SNARK recursivas y que, a largo plazo, no tendrá un impacto negativo en Ethereum. La reunión confirmó la prioridad del EIP-2537, y todos los clientes acordaron implementar este EIP lo antes posible, con la intención de completar todo el desarrollo antes de la actualización de Berlín.
Luego, el EIP-2537 se convirtió en una tarea de alta prioridad. En la 83ª reunión de desarrolladores principales del 20 de marzo, se volvió a presentar como la propuesta principal en discusión. La reunión confirmó que el EIP-2537 reemplazaría al EIP-1962 como la propuesta central de BLS y se incluiría en la lista de preselección de la actualización de Berlín.
La 84ª reunión de abril incluyó oficialmente el EIP-2537 en la actualización del hard fork de Berlín y estableció la línea de tiempo para su implementación en abril y pruebas en mayo y junio. Es importante destacar que el EIP-2537 fue clasificado como un asunto de máxima prioridad en esta discusión.
A partir de entonces, EIP-2537 entró en una fase de desarrollo y pruebas intensivas, y casi en cada una de las cerca de 20 reuniones de desarrolladores principales posteriores se discutió el tema.
En la 85ª reunión, los desarrolladores discutieron el problema de codificación ABI de EIP-2537. Dado que Matter Labs ya había completado básicamente la implementación de la versión en Rust, el cliente Besu indicó que había implementado básicamente la funcionalidad de EIP-2537, pero desde Geth afirmaron que actualmente no hay nadie trabajando en el tema.
En la 86ª reunión, diferentes nodos lograron sincronizar nuevamente los avances de EIP-2537, Geth indicó que se ha completado parte del trabajo, pero aún quedan muchas tareas por hacer.
La 87ª reunión se centró en los problemas de implementación de EIP-2537. Los desarrolladores de Geth indicaron que existe un PR de 16000 líneas que implementa EIP-2537, pero no se puede determinar si ese PR implementa EIP-2537 de manera segura y efectiva, solo se puede juzgar el estado del código a través de las pruebas de fuzzing más simples.
Los desarrolladores de Geth dijeron: "Según mi intuición, Geth no podrá tener listas las operaciones de la curva BLS antes del lanzamiento de la red principal en julio."
Hudson Jameson propuso buscar ingenieros criptográficos para ayudar con la revisión de PR de Geth y sugirió utilizar la red de pruebas para probar la seguridad de la implementación de EIP-2537. Dado que el equipo de desarrollo de ETH2 también está implementando la verificación de firmas BLS, puede participar en las pruebas.
Es importante añadir que la implementación de EIP-2537 de Geth utiliza en gran medida código ensamblador para garantizar la eficiencia, lo que hace que esta parte del código sea muy difícil de leer y entender. Alex Vlasov sugiere eliminar las optimizaciones de ensamblador complejas en el PR para reducir la dificultad de revisión.
Un objetivo central 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 usarán el contrato de EIP-2537 que ya ha sido auditado. Algunos desarrolladores creen que es mejor no lanzar una nueva versión del contrato que use EIP-2537.
Finalmente, la reunión decidió aumentar la red de pruebas YOLO, dedicada a probar el EIP-2537. De hecho, de esta reunión se puede ver que, con la finalización del contrato de depósito, la importancia del EIP-2537 ha disminuido drásticamente, mientras que los desarrolladores de Geth consideran que es muy probable que este EIP no se implemente antes de la actualización de Berlín. Parece que la no adopción del EIP-2537 en la actualización de Berlín ya es un hecho consumado.
En la 88ª reunión, los desarrolladores de Geth encontraron una serie de problemas en la implementación del PR de EIP-2537, indicando que se necesita más pruebas y correcciones. En ese momento, había dos implementaciones de EIP-2537 en el sistema Geth, una que incluía optimizaciones en ensamblador y otra completamente escrita en Go. Un desarrollador sugirió usar directamente la versión en Go para reducir la dificultad de la revisión del código.
En la 89ª reunión surgieron problemas más graves, la red de pruebas YOLO presentó algunas anomalías, los desarrolladores sospechan que son causadas por la firma BLS, pero los desarrolladores de EIP-2537 refutaron esto. La buena noticia es que el contrato de depósito basado en EIP-2537 está prácticamente completado y está esperando auditoría.
La novena reunión determinó la fecha límite para el lanzamiento de la actualización Berlin en julio. La reunión también discutió el problema de la diversidad de clientes, principalmente relacionado con la situación dominante de Geth, y algunos desarrolladores sugirieron congelar la implementación actual del EIP para reducir los costos de desarrollo de otros clientes. En la décima reunión, un desarrollador propuso utilizar un enfoque modular para reducir los costos de desarrollo y aumentar la diversidad de clientes.
La 92ª reunión seguirá confirmando el EIP-2537 como el EIP necesario para la actualización de Berlín.
En la 96ª reunión, dado que Celo ha incorporado simultáneamente EIP-2537 y EIP-2539 en su bifurcación dura de la red, Matter Labs desea incluir EIP-2539 en las pruebas de YOLO v2 y en la actualización de Berlín. Sin embargo, los desarrolladores de Geth se oponen, argumentando que EIP-2537 aún no se ha probado completamente en Geth. Finalmente, la reunión decidió no añadir EIP-2696 en la actualización de Berlín, dejando su discusión para el futuro.
La 99ª reunión decidió sacar el EIP-2537 de la red de prueba YOLO v3 y de la actualización de Berlín, siendo la razón principal que el EIP-2537 ha consumido demasiado tiempo de los desarrolladores principales, lo que ha bloqueado el desarrollo de otros EIP para la actualización de Berlín. Un factor secundario es que la Fundación Ethereum propuso el EVM384 como un reemplazo para el EIP-2537, ofreciendo una solución de cálculo de curvas elípticas más general. Sin embargo, los desarrolladores principales expresaron preocupaciones sobre la seguridad.
Este es el recorrido temprano de EIP-2537. Podemos ver que EIP-2537 fue inicialmente uno de los EIP más importantes en la actualización de Berlin, pero fue desechado debido a problemas de implementación. En abril de 2021, Ethereum completó la actualización de Berlin, los EIP centrales como EIP-2565 no son realmente complejos de implementar, y la actualización parece un poco escasa, precisamente porque el EIP-2537, que era el más complejo, fue eliminado.
Desarrollo futuro
Como es bien sabido, cada actualización de Ethereum tiene una propuesta central. La actualización de Londres después de Berlín introdujo la propuesta de tarifas más importante en la historia de Ethereum, EIP-1559. Para la antigua propuesta central EIP-2537, es difícil que las actualizaciones posteriores la incluyan.
La actualización de Londres después de Berlín está en progreso, y los desarrolladores están considerando agregar EIP-2537 en issues#369. La 109ª reunión de desarrolladores principales sincronizó el estado de desarrollo de EIP-2537, y debido a la implementación utilizando otras bibliotecas, se generó una discusión sobre el uso de gas. Un desarrollador propuso reemplazar EIP-2537 con EVM384. Sin embargo, en la 111ª reunión de abril de 2021, EIP-2537 fue eliminado de la actualización de Londres debido a su complejidad. La razón principal es que la implementación del estándar EIP-2537 cambió las bibliotecas de dependencia, lo que podría afectar los precios del gas, y la implementación en diferentes clientes requeriría mucho tiempo para reevaluar el consumo de gas.
En junio de 2021, se propuso oficialmente el EIP-2537 para ser incluido en la actualización de Shanghai a través del issues#343. Sin embargo, después de la actualización de Londres, The Merge ocupó gran parte del tiempo de los desarrolladores, y los desarrolladores de la capa de ejecución necesitaron escribir una gran cantidad de código para implementar la actualización de PoS. En septiembre de 2022, después de completar The Merge, los desarrolladores de la capa de ejecución finalmente tuvieron la oportunidad de continuar discutiendo los objetivos de la actualización de Shanghai.
En noviembre de 2022, en la 150ª reunión de desarrolladores principales, se discutió brevemente si incluir EIP-2537 en Shanghai, pero los desarrolladores consideraron que debería posponerse. El núcleo de Shanghai es el soporte para retiros de PoS. Finalmente, EIP-2537 no fue incluido en la actualización de Shanghai centrada en los retiros.
Desafortunadamente, la actualización de Cancun no ha discutido EIP-2537, ya que el enfoque de Cancun es apoyar EIP-4844, proporcionando Blob para la segunda capa de Ethereum para que la segunda capa utilice Ethereum como capa de disponibilidad de datos.
Hasta la 181ª reunión de desarrolladores principales en febrero de 2024, los desarrolladores solo discutieron la inclusión de EIP-2537 en la actualización de Pectra. En ese momento, los desarrolladores consideraban que la implementación de EIP-2537 ya no era un problema, solo quedaba por resolver algunos problemas de precios del consumo de gas.
En la 202ª reunión del 19 de diciembre de 2024, los desarrolladores de Nethermind finalmente confirmaron el modelo de precios de EIP-2537. Es importante destacar que Matter Labs, el proponente inicial de EIP-2537, se había retirado prácticamente de la discusión en ese momento. La 203ª reunión de enero de 2025 discutió la revalorización de la precompilación BLS, el desarrollador de Geth Jared Wasinger sugirió aumentar el costo de gas en un 20%, y recibió el apoyo de las pruebas de referencia del equipo de Besu.
Resumen
EIP-2537 pasó por un largo y tortuoso proceso desde su propuesta hasta su adopción final: