EIP-2537 es una instrucción precompilada de EVM que se ha determinado agregar en la última actualización de bifurcación Pectra de Ethereum. 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.
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. Luego, en febrero, Vitalik y Christian Reitwiessner propusieron EIP-196 y EIP-197, sugiriendo agregar soporte para cálculos de la curva alt_bn128 a la EVM.
La actualización de Byzantium en octubre de 2017 incorporó oficialmente la curva alt_bn128, lo que permitió el cálculo de emparejamiento de dominios de curvas dentro de la EVM, haciendo que la verificación de pruebas ZK-Snarks se pudiera llevar a cabo dentro de la EVM.
Pero con el desarrollo de la criptografía, en noviembre de 2017, el equipo de zcash propuso la curva BLS12-381, que tiene una mayor seguridad y mejor rendimiento en comparación con alt_bn128. Muchos protocolos de blockchain adoptaron posteriormente la curva BLS12-381 en lugar de alt_bn128.
En mayo de 2018, Justin Drake publicó que la futura actualización PoS y de fragmentación de Ethereum podría usar un algoritmo de firma múltiple BLS basado en BLS12-381. Esto sentó las bases para la posterior actualización de ETH2.
Con el desarrollo de ETH2, ha surgido el clamor por introducir BLS12-381 en la capa de ejecución. En febrero de 2020, los investigadores propusieron EIP-2537, con la esperanza de probarlo junto con la red de prueba de ETH2. El autor de EIP-2537, Alex Stokes, hizo un llamado para incluirlo en el hard fork de Berlín.
Cabe mencionar que el autor de EIP-2537 también es cofundador de Matter Labs, cuya producto más famoso es ZKSync.
Berlín en turbulencia
Antes de presentar el contenido posterior, es necesario entender el EIP-1962. Esta es la primera propuesta de precompilación de emparejamiento de dominios de curvas elípticas presentada por Matter Labs en abril de 2019, que soporta las tres curvas BLS12, BN y MNT4/6.
El plan EIP-1962 es aumentar en una sola vez 10 instrucciones precompiladas para manejar diferentes curvas. Sin embargo, muchos desarrolladores consideran que es demasiado complejo y difícil de implementar, además de que no es amigable para los ingenieros de contratos inteligentes. Sin embargo, Matter Labs ha completado el desarrollo del algoritmo y proporciona implementaciones de referencia en varios idiomas.
Para resolver el problema de EIP-1962, Matter Labs propuso en febrero de 2020 varios planes de división de EIP:
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 no recibió un número EIP.
Entre ellos, EIP-2537 es el más importante, ya que la capa de consenso también utiliza la curva BLS12-381. Los objetivos centrales de EIP-1962 y EIP-2537 son implementar la verificación de firmas BLS en la capa de consenso en la red principal.
En ese momento, se estaba desarrollando el contrato de depósito de ETH2. Debido a que la capa de ejecución no tiene verificación BLS, el contrato de depósito en el diseño original no verifica las firmas, sino que es verificado por la capa de consenso; si es incorrecto, el depósito falla, lo que provoca la pérdida de fondos.
Por lo tanto, los desarrolladores principales esperan introducir la precompilación BLS12-381 para verificar las firmas en los contratos de depósito y evitar riesgos de fondos. Esta también fue la razón por la que los desarrolladores prestaron atención a EIP-1962 y EIP-2537 en ese momento.
Después de la propuesta del EIP-2537, Vitalik señaló inmediatamente una serie de problemas, principalmente centrados en el contenido del documento. El autor respondió y discutió posteriormente.
La reunión de desarrolladores principales del 6 de marzo de 2020 discutió el EIP-2537. Vitalik cree que es muy efectivo para las pruebas SNARK recursivas y que a largo plazo no perjudicará a Ethereum. La reunión confirmó la prioridad del EIP-2537, y todos los clientes acordaron implementarlo lo antes posible y completar el desarrollo antes de la actualización de Berlín.
Luego, EIP-2537 se convirtió en una tarea de alta prioridad. En la reunión del 20 de marzo, se discutió nuevamente esta propuesta como prioridad 83, confirmando que reemplazaría a EIP-1962 como la propuesta central de BLS y que se incluiría en la lista de preselección para la actualización de Berlín.
La reunión de abril 84 formalmente incorporó el EIP-2537 en la bifurcación dura de Berlín, estableciendo una línea de tiempo para su implementación en abril y pruebas en mayo-junio. El EIP-2537 se enumeró como un asunto de máxima prioridad.
Desde entonces, EIP-2537 ha entrado en una gran fase de desarrollo y pruebas, y en casi cada una de las cerca de 20 reuniones de desarrolladores principales posteriores ha habido discusiones relacionadas.
En la reunión 85 se discutió el problema de la codificación ABI. Dado que Matter Labs ha completado en gran medida la implementación en Rust, el cliente Besu ha indicado que ha implementado en gran medida la funcionalidad EIP-2537, pero Geth ha mencionado que aún no ha comenzado a trabajar en la implementación.
La reunión 86 volvió a sincronizar la situación de cada nodo, Geth indicó que se ha completado parte del trabajo, pero aún hay muchas tareas pendientes.
El contenido central de la reunión 87 es el problema de implementación de EIP-2537. Los desarrolladores de Geth indican que hay una PR de 16000 líneas que implementa EIP-2537, pero no se puede determinar si es segura y efectiva, solo se puede juzgar a través de pruebas de fuzzing simples. Geth considera que es muy probable que no se complete el desarrollo relacionado antes de la fecha programada en Berlín.
Hudson Jameson propuso buscar ingenieros criptográficos para ayudar con la revisión de PR de Geth, y sugirió probar la implementación de seguridad en la red de pruebas. El equipo de ETH2 también podría participar en las pruebas.
Es importante añadir que la implementación del PR de EIP-2537 de Geth utiliza mucho código ensamblador para garantizar la eficiencia, lo que lo hace difícil de leer y entender. Alex Vlasov sugiere eliminar las optimizaciones complejas de ensamblador para reducir la dificultad de revisión.
Aunque uno de los objetivos principales de EIP-2537 es ayudar a los contratos de depósito de ETH2, los desarrolladores del contrato de depósito en esta reunión afirmaron que no usarán la versión de EIP-2537 que ya ha sido auditada, y algunos desarrolladores sugirieron que no se debería lanzar una nueva versión que use EIP-2537.
La última reunión decidió aumentar la prueba de la red de prueba YOLO para probar específicamente el EIP-2537. En este momento se puede ver que, con la finalización del contrato de depósito, la importancia del EIP-2537 ha disminuido significativamente, y los desarrolladores de Geth creen que es muy probable que no se pueda implementar antes de la actualización de Berlín. Parece que no incluir el EIP-2537 en Berlín ya se ha convertido en un hecho.
En la reunión 88, los desarrolladores de Geth descubrieron una serie de problemas en la implementación del PR de EIP-2537, indicando que se necesita más prueba y reparación. En este momento, Geth tiene dos versiones de implementación, una que incluye optimización de ensamblador y otra completamente escrita en Go. Alguien sugirió utilizar directamente la versión de Go para reducir la dificultad de revisión del código.
La reunión 89 presentó un problema más grave, la red de prueba YOLO mostró anomalías, se sospecha que es causado por la firma BLS, pero los desarrolladores de EIP-2537 lo refutaron. La buena noticia es que el contrato de depósito basado en EIP-2537 está prácticamente terminado y está esperando auditoría.
La reunión 90 estableció el plazo para el lanzamiento de la actualización de Berlin en julio. La reunión también discutió el problema de la diversidad de clientes, y alguien propuso congelar la implementación actual del EIP para reducir los costos de desarrollo de otros clientes. La reunión 91 incluso propuso utilizar un enfoque modular para aumentar la diversidad de clientes.
La reunión 92 confirmó una vez más que EIP-2537 es el EIP necesario para la actualización de Berlín.
La reunión 96 discutió si también se debería incluir el EIP-2539 en la prueba de Berlín, ya que Celo ha incluido el EIP-2537 y el EIP-2539 en su actualización de red. Sin embargo, los desarrolladores de Geth se oponen, argumentando que el EIP-2537 en sí mismo aún no ha sido completamente probado. La decisión final fue no añadir el EIP-2696 en Berlín.
La reunión 99 decidió sacar el EIP-2537 de la red de prueba YOLO v3 y de la actualización de Berlín, principalmente porque consumió demasiado tiempo de los desarrolladores, afectando el desarrollo de otros EIP. Un factor secundario es que la Fundación Ethereum propuso EVM384 como alternativa. Sin embargo, los desarrolladores expresaron preocupaciones sobre su seguridad.
Este es el recorrido temprano de EIP-2537. Fue uno de los EIP más importantes de la actualización de Berlín, pero debido a problemas de implementación, finalmente fue desechado. En abril de 2021, Ethereum completó la actualización de Berlín; la implementación de los EIP centrales, como EIP-2565, fue relativamente sencilla, lo que lo hizo parecer un poco débil, precisamente porque el EIP-2537, el más complejo, fue eliminado.
Desarrollo futuro
Como todos saben, cada actualización de Ethereum tiene propuestas centrales, como la introducción de EIP-1559 en Londres después de Berlín. En el caso de EIP-2537, que fue una propuesta central, es difícil que se incluya en futuras actualizaciones.
Durante la actualización de Londres, los desarrolladores consideraron agregar EIP-2537. La reunión 109 sincronizó su estado de desarrollo, ya que la implementación de una nueva biblioteca provocó una discusión sobre el gas. Se propuso reemplazarlo con EVM384. Sin embargo, la reunión 111 lo eliminó de la actualización de Londres debido a su complejidad, principalmente porque el cambio de la biblioteca provocó cambios en la fijación de precios del gas, lo que requiere una nueva evaluación.
En junio de 2021, se propuso oficialmente incluir EIP-2537 en la actualización de Shanghai. Pero después de Londres, The Merge ocupó gran parte del tiempo de los desarrolladores. Después de completar The Merge en septiembre de 2022, los desarrolladores de la capa de ejecución tuvieron la oportunidad de continuar discutiendo los objetivos de Shanghai.
En la reunión de noviembre de 2022 se discutió brevemente si incluir Shanghai, pero los desarrolladores consideraron que debía posponerse, el núcleo de Shanghai es el soporte para retiros de PoS. Al final, EIP-2537 no fue incluido en la actualización de Shanghai centrada en los retiros.
Peor aún, la actualización de Cancún no ha discutido EIP-2537, ya que su núcleo es el soporte para EIP-4844, que proporciona disponibilidad de datos Blob para la segunda capa.
Finalmente, en la reunión 181 de febrero de 2024 se discutió la inclusión de EIP-2537 en la actualización de Pectra, los desarrolladores creen que la implementación ya no es un problema, solo existe el problema de la fijación de precios del gas.
La reunión del 19 de diciembre de 2024, número 202, los desarrolladores de Nethermind confirmaron el modelo de precios EIP-2537. El proponente original, Matter Labs, casi ha abandonado la discusión en este momento. La reunión 203 de enero de 2025 discutió la revalorización; los desarrolladores de Geth propusieron aumentar los costos de gas en un 20%, recibiendo el apoyo del equipo de Besu.
Resumen
EIP-2537 ha pasado por un largo período de 5 años desde su propuesta hasta su adopción. Fue el núcleo de la actualización de Berlín, pero se abandonó debido a las dificultades de implementación. Luego, Ethereum entró en el proceso histórico de PoS, y el complejo EIP de capa de ejecución pura no recibió atención, mientras que muchos EIP relacionados con PoS se convirtieron en objetivos centrales, lo que llevó a que EIP-2537 no fuera aceptado durante mucho tiempo. Hasta 2025, con la resolución de los principales problemas técnicos, EIP-2537 finalmente tiene la esperanza de ser implementado en la actualización de Pectra.
Este proceso demuestra que la inclusión de un EIP en las actualizaciones de Ethereum no solo depende de su valor técnico inherente, sino que también necesita considerar la etapa de desarrollo y las prioridades generales de Ethereum. Cada actualización tiene su propio tema, y solo aquellos EIP que cumplan con las necesidades actuales y que sean técnicamente maduros pueden ser finalmente adoptados.
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.
11 me gusta
Recompensa
11
8
Compartir
Comentar
0/400
LuckyPig
· hace10h
¡Vamos! 💪 ¡Rápido, introduce una posición! 🚗 ¡Ajusta tu asiento y prepárate, To the moon! 🛫 ¡Ajusta tu asiento y prepárate, To the moon! 🛫 ¡Ajusta tu asiento y prepárate, To the moon! 🛫 ¡Ajusta tu asiento y prepárate, To the moon! 🛫 ¡Ajusta tu asiento y prepárate, To the moon! 🛫 ¡Ajusta tu asiento y prepárate, To the moon! 🛫
Ver originalesResponder0
DataBartender
· hace10h
Esta espera de 5 años ha sido demasiado difícil.
Ver originalesResponder0
MetaverseHobo
· hace10h
¿Cinco años de espera es una tortura para la gente?
Ver originalesResponder0
AirdropHunterXM
· hace10h
¿Cinco años de trabajo? La acción de V神 es demasiado lenta, ¿no?
Ver originalesResponder0
defi_detective
· hace10h
5 años también es demasiado lento ¿me va a matar de ansiedad?
Ver originalesResponder0
MevWhisperer
· hace11h
Después de cinco años, finalmente lo logré. ¡Es tan frustrante que me dan ganas de romper la computadora!
Ver originalesResponder0
NoodlesOrTokens
· hace11h
¿5 años es demasiado lento? ¿Qué está haciendo Vitalik Buterin?
Ver originalesResponder0
rekt_but_not_broke
· hace11h
¡Han pasado cinco años! Esta eficiencia no es mejor que la de Newton descubriendo la gravedad.
EIP-2537 un largo camino: de la alta prioridad de Berlín a la adopción final en la actualización de Pectra
EIP-2537: Un largo camino desde 2020 hasta 2025
EIP-2537 es una instrucción precompilada de EVM que se ha determinado agregar en la última actualización de bifurcación Pectra de Ethereum. 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.
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. Luego, en febrero, Vitalik y Christian Reitwiessner propusieron EIP-196 y EIP-197, sugiriendo agregar soporte para cálculos de la curva alt_bn128 a la EVM.
La actualización de Byzantium en octubre de 2017 incorporó oficialmente la curva alt_bn128, lo que permitió el cálculo de emparejamiento de dominios de curvas dentro de la EVM, haciendo que la verificación de pruebas ZK-Snarks se pudiera llevar a cabo dentro de la EVM.
Pero con el desarrollo de la criptografía, en noviembre de 2017, el equipo de zcash propuso la curva BLS12-381, que tiene una mayor seguridad y mejor rendimiento en comparación con alt_bn128. Muchos protocolos de blockchain adoptaron posteriormente la curva BLS12-381 en lugar de alt_bn128.
En mayo de 2018, Justin Drake publicó que la futura actualización PoS y de fragmentación de Ethereum podría usar un algoritmo de firma múltiple BLS basado en BLS12-381. Esto sentó las bases para la posterior actualización de ETH2.
Con el desarrollo de ETH2, ha surgido el clamor por introducir BLS12-381 en la capa de ejecución. En febrero de 2020, los investigadores propusieron EIP-2537, con la esperanza de probarlo junto con la red de prueba de ETH2. El autor de EIP-2537, Alex Stokes, hizo un llamado para incluirlo en el hard fork de Berlín.
Cabe mencionar que el autor de EIP-2537 también es cofundador de Matter Labs, cuya producto más famoso es ZKSync.
Berlín en turbulencia
Antes de presentar el contenido posterior, es necesario entender el EIP-1962. Esta es la primera propuesta de precompilación de emparejamiento de dominios de curvas elípticas presentada por Matter Labs en abril de 2019, que soporta las tres curvas BLS12, BN y MNT4/6.
El plan EIP-1962 es aumentar en una sola vez 10 instrucciones precompiladas para manejar diferentes curvas. Sin embargo, muchos desarrolladores consideran que es demasiado complejo y difícil de implementar, además de que no es amigable para los ingenieros de contratos inteligentes. Sin embargo, Matter Labs ha completado el desarrollo del algoritmo y proporciona implementaciones de referencia en varios idiomas.
Para resolver el problema de EIP-1962, Matter Labs propuso en febrero de 2020 varios planes de división de EIP:
Entre ellos, EIP-2537 es el más importante, ya que la capa de consenso también utiliza la curva BLS12-381. Los objetivos centrales de EIP-1962 y EIP-2537 son implementar la verificación de firmas BLS en la capa de consenso en la red principal.
En ese momento, se estaba desarrollando el contrato de depósito de ETH2. Debido a que la capa de ejecución no tiene verificación BLS, el contrato de depósito en el diseño original no verifica las firmas, sino que es verificado por la capa de consenso; si es incorrecto, el depósito falla, lo que provoca la pérdida de fondos.
Por lo tanto, los desarrolladores principales esperan introducir la precompilación BLS12-381 para verificar las firmas en los contratos de depósito y evitar riesgos de fondos. Esta también fue la razón por la que los desarrolladores prestaron atención a EIP-1962 y EIP-2537 en ese momento.
Después de la propuesta del EIP-2537, Vitalik señaló inmediatamente una serie de problemas, principalmente centrados en el contenido del documento. El autor respondió y discutió posteriormente.
La reunión de desarrolladores principales del 6 de marzo de 2020 discutió el EIP-2537. Vitalik cree que es muy efectivo para las pruebas SNARK recursivas y que a largo plazo no perjudicará a Ethereum. La reunión confirmó la prioridad del EIP-2537, y todos los clientes acordaron implementarlo lo antes posible y completar el desarrollo antes de la actualización de Berlín.
Luego, EIP-2537 se convirtió en una tarea de alta prioridad. En la reunión del 20 de marzo, se discutió nuevamente esta propuesta como prioridad 83, confirmando que reemplazaría a EIP-1962 como la propuesta central de BLS y que se incluiría en la lista de preselección para la actualización de Berlín.
La reunión de abril 84 formalmente incorporó el EIP-2537 en la bifurcación dura de Berlín, estableciendo una línea de tiempo para su implementación en abril y pruebas en mayo-junio. El EIP-2537 se enumeró como un asunto de máxima prioridad.
Desde entonces, EIP-2537 ha entrado en una gran fase de desarrollo y pruebas, y en casi cada una de las cerca de 20 reuniones de desarrolladores principales posteriores ha habido discusiones relacionadas.
En la reunión 85 se discutió el problema de la codificación ABI. Dado que Matter Labs ha completado en gran medida la implementación en Rust, el cliente Besu ha indicado que ha implementado en gran medida la funcionalidad EIP-2537, pero Geth ha mencionado que aún no ha comenzado a trabajar en la implementación.
La reunión 86 volvió a sincronizar la situación de cada nodo, Geth indicó que se ha completado parte del trabajo, pero aún hay muchas tareas pendientes.
El contenido central de la reunión 87 es el problema de implementación de EIP-2537. Los desarrolladores de Geth indican que hay una PR de 16000 líneas que implementa EIP-2537, pero no se puede determinar si es segura y efectiva, solo se puede juzgar a través de pruebas de fuzzing simples. Geth considera que es muy probable que no se complete el desarrollo relacionado antes de la fecha programada en Berlín.
Hudson Jameson propuso buscar ingenieros criptográficos para ayudar con la revisión de PR de Geth, y sugirió probar la implementación de seguridad en la red de pruebas. El equipo de ETH2 también podría participar en las pruebas.
Es importante añadir que la implementación del PR de EIP-2537 de Geth utiliza mucho código ensamblador para garantizar la eficiencia, lo que lo hace difícil de leer y entender. Alex Vlasov sugiere eliminar las optimizaciones complejas de ensamblador para reducir la dificultad de revisión.
Aunque uno de los objetivos principales de EIP-2537 es ayudar a los contratos de depósito de ETH2, los desarrolladores del contrato de depósito en esta reunión afirmaron que no usarán la versión de EIP-2537 que ya ha sido auditada, y algunos desarrolladores sugirieron que no se debería lanzar una nueva versión que use EIP-2537.
La última reunión decidió aumentar la prueba de la red de prueba YOLO para probar específicamente el EIP-2537. En este momento se puede ver que, con la finalización del contrato de depósito, la importancia del EIP-2537 ha disminuido significativamente, y los desarrolladores de Geth creen que es muy probable que no se pueda implementar antes de la actualización de Berlín. Parece que no incluir el EIP-2537 en Berlín ya se ha convertido en un hecho.
En la reunión 88, los desarrolladores de Geth descubrieron una serie de problemas en la implementación del PR de EIP-2537, indicando que se necesita más prueba y reparación. En este momento, Geth tiene dos versiones de implementación, una que incluye optimización de ensamblador y otra completamente escrita en Go. Alguien sugirió utilizar directamente la versión de Go para reducir la dificultad de revisión del código.
La reunión 89 presentó un problema más grave, la red de prueba YOLO mostró anomalías, se sospecha que es causado por la firma BLS, pero los desarrolladores de EIP-2537 lo refutaron. La buena noticia es que el contrato de depósito basado en EIP-2537 está prácticamente terminado y está esperando auditoría.
La reunión 90 estableció el plazo para el lanzamiento de la actualización de Berlin en julio. La reunión también discutió el problema de la diversidad de clientes, y alguien propuso congelar la implementación actual del EIP para reducir los costos de desarrollo de otros clientes. La reunión 91 incluso propuso utilizar un enfoque modular para aumentar la diversidad de clientes.
La reunión 92 confirmó una vez más que EIP-2537 es el EIP necesario para la actualización de Berlín.
La reunión 96 discutió si también se debería incluir el EIP-2539 en la prueba de Berlín, ya que Celo ha incluido el EIP-2537 y el EIP-2539 en su actualización de red. Sin embargo, los desarrolladores de Geth se oponen, argumentando que el EIP-2537 en sí mismo aún no ha sido completamente probado. La decisión final fue no añadir el EIP-2696 en Berlín.
La reunión 99 decidió sacar el EIP-2537 de la red de prueba YOLO v3 y de la actualización de Berlín, principalmente porque consumió demasiado tiempo de los desarrolladores, afectando el desarrollo de otros EIP. Un factor secundario es que la Fundación Ethereum propuso EVM384 como alternativa. Sin embargo, los desarrolladores expresaron preocupaciones sobre su seguridad.
Este es el recorrido temprano de EIP-2537. Fue uno de los EIP más importantes de la actualización de Berlín, pero debido a problemas de implementación, finalmente fue desechado. En abril de 2021, Ethereum completó la actualización de Berlín; la implementación de los EIP centrales, como EIP-2565, fue relativamente sencilla, lo que lo hizo parecer un poco débil, precisamente porque el EIP-2537, el más complejo, fue eliminado.
Desarrollo futuro
Como todos saben, cada actualización de Ethereum tiene propuestas centrales, como la introducción de EIP-1559 en Londres después de Berlín. En el caso de EIP-2537, que fue una propuesta central, es difícil que se incluya en futuras actualizaciones.
Durante la actualización de Londres, los desarrolladores consideraron agregar EIP-2537. La reunión 109 sincronizó su estado de desarrollo, ya que la implementación de una nueva biblioteca provocó una discusión sobre el gas. Se propuso reemplazarlo con EVM384. Sin embargo, la reunión 111 lo eliminó de la actualización de Londres debido a su complejidad, principalmente porque el cambio de la biblioteca provocó cambios en la fijación de precios del gas, lo que requiere una nueva evaluación.
En junio de 2021, se propuso oficialmente incluir EIP-2537 en la actualización de Shanghai. Pero después de Londres, The Merge ocupó gran parte del tiempo de los desarrolladores. Después de completar The Merge en septiembre de 2022, los desarrolladores de la capa de ejecución tuvieron la oportunidad de continuar discutiendo los objetivos de Shanghai.
En la reunión de noviembre de 2022 se discutió brevemente si incluir Shanghai, pero los desarrolladores consideraron que debía posponerse, el núcleo de Shanghai es el soporte para retiros de PoS. Al final, EIP-2537 no fue incluido en la actualización de Shanghai centrada en los retiros.
Peor aún, la actualización de Cancún no ha discutido EIP-2537, ya que su núcleo es el soporte para EIP-4844, que proporciona disponibilidad de datos Blob para la segunda capa.
Finalmente, en la reunión 181 de febrero de 2024 se discutió la inclusión de EIP-2537 en la actualización de Pectra, los desarrolladores creen que la implementación ya no es un problema, solo existe el problema de la fijación de precios del gas.
La reunión del 19 de diciembre de 2024, número 202, los desarrolladores de Nethermind confirmaron el modelo de precios EIP-2537. El proponente original, Matter Labs, casi ha abandonado la discusión en este momento. La reunión 203 de enero de 2025 discutió la revalorización; los desarrolladores de Geth propusieron aumentar los costos de gas en un 20%, recibiendo el apoyo del equipo de Besu.
Resumen
EIP-2537 ha pasado por un largo período de 5 años desde su propuesta hasta su adopción. Fue el núcleo de la actualización de Berlín, pero se abandonó debido a las dificultades de implementación. Luego, Ethereum entró en el proceso histórico de PoS, y el complejo EIP de capa de ejecución pura no recibió atención, mientras que muchos EIP relacionados con PoS se convirtieron en objetivos centrales, lo que llevó a que EIP-2537 no fuera aceptado durante mucho tiempo. Hasta 2025, con la resolución de los principales problemas técnicos, EIP-2537 finalmente tiene la esperanza de ser implementado en la actualización de Pectra.
Este proceso demuestra que la inclusión de un EIP en las actualizaciones de Ethereum no solo depende de su valor técnico inherente, sino que también necesita considerar la etapa de desarrollo y las prioridades generales de Ethereum. Cada actualización tiene su propio tema, y solo aquellos EIP que cumplan con las necesidades actuales y que sean técnicamente maduros pueden ser finalmente adoptados.