EIP-2537: El largo camino de los cálculos de curvas de Ethereum
EIP-2537 es una instrucción de precompilación de EVM que se determinó añadir en la reciente actualización del fork de Pectra. Esta instrucción añade diversas funciones de cálculo de la curva BLS12-381 al EVM, incluyendo cálculos de emparejamiento en el dominio de la curva.
EIP-2573 fue propuesto inicialmente 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é pasaron 5 años para que esta propuesta fuera incluida en la actualización.
Antecedentes de la propuesta
En enero de 2017, Vitalik Buterin presentó por primera vez el algoritmo de emparejamiento y la curva alt_bn128. Posteriormente, Vitalik y Christian Reitwiessner propusieron EIP-196 y EIP-197, que añadieron soporte para cálculos de la curva alt_bn128 en el EVM. La actualización de Byzantium en octubre de 2017 incorporó oficialmente la curva alt_bn128, lo que permitió realizar cálculos de emparejamiento en el dominio de la curva dentro del EVM, permitiendo que la verificación de pruebas ZK-Snarks se pudiera completar dentro del EVM.
En noviembre de 2017, el equipo de zcash propuso la curva BLS12-381, que ofrece una mayor seguridad y rendimiento en comparación con alt_bn128. Muchos protocolos de blockchain adoptaron posteriormente la curva BLS12-381, abandonando la curva alt_bn128.
En mayo de 2018, Justin Drake señaló que las actualizaciones futuras de PoS y fragmentación de Ethereum podrían utilizar un algoritmo de firma múltiple BLS basado en la curva BLS12-381. Esto hizo que el anterior plan EIP-1011 quedara fuera de escena, y la posterior actualización de ETH2 finalmente adoptó la curva BLS12-381.
Con el desarrollo de ETH2, ha surgido un llamado para introducir BLS12-381 en la capa de ejecución de ETH. En febrero de 2020, algunos investigadores propusieron EIP-2537, con la esperanza de probarlo en la red de pruebas de ETH2. El autor de EIP-2537, Alex Stokes, hizo un llamado para incluirlo en la bifurcación dura de Berlín.
Curiosamente, el autor de EIP-2537 también es cofundador de Matter Labs, cuyo producto más famoso es ZKSync.
Berlín en turbulencia
Antes de introducir el contenido posterior, es necesario mencionar 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 tres curvas: BLS12, BN y MNT4/6. Este EIP planea agregar 10 instrucciones precompiladas de una sola vez para procesar diferentes curvas. Sin embargo, muchos desarrolladores cuestionan que la propuesta es demasiado compleja y difícil de implementar, y que no es conveniente para los ingenieros de contratos inteligentes. Como proponente, Matter Labs ha completado el desarrollo del algoritmo de curvas elípticas y ha proporcionado implementaciones de referencia en varios idiomas.
Para resolver el problema de EIP-1962, Matter Labs propuso en febrero de 2020 múltiples EIPs que dividen EIP-1962, heredando parcialmente su interfaz:
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, el EIP-2537 es el más importante, ya que la capa de consenso también utiliza la curva BLS12-381. El objetivo principal del EIP-1962 y del EIP-2537 es implementar la verificación de firmas BLS en la capa de consenso en la red principal. En ese momento, ETH2 estaba desarrollando el contrato de depósito; debido a la falta de un algoritmo de verificación BLS en la capa de ejecución, el diseño original no verificaba firmas en el contrato de depósito, sino que la verificación era realizada por la capa de consenso, y si se encontraba algún error, podría resultar en la pérdida de fondos del usuario.
En este contexto, los desarrolladores principales buscan introducir la precompilación BLS12-381 para verificar firmas dentro del contrato de depósito, evitando así posibles pérdidas de fondos de los usuarios. Esta 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 señaló que existía una serie de problemas, principalmente centrados en el contenido del documento EIP. Posteriormente, el autor participó en la discusión de respuestas. En la reunión de desarrolladores principales del 6 de marzo de 2020, Vitalik consideró que EIP-2537, entre otros, era muy efectivo para las pruebas SNARK recursivas y que a largo plazo no perjudicaría a Ethereum. La reunión confirmó la prioridad de EIP-2537, y todos los clientes acordaron implementarlo lo antes posible, planeando completar el desarrollo antes de la actualización de Berlín.
Luego, EIP-2537 se convirtió en una tarea de alta prioridad. La reunión del 20 de marzo confirmó que EIP-2537 reemplazaría a EIP-1962 como propuesta central de BLS y entraría en la lista de preselección para la actualización de Berlín. La reunión de abril formalmente incluyó EIP-2537 en la actualización del hard fork de Berlín, determinando una línea de tiempo para su implementación en abril y pruebas en mayo y junio, y lo clasificó como un asunto de máxima prioridad.
A continuación, EIP-2537 entra en una etapa masiva de pruebas de desarrollo, y casi cada una de las cerca de 20 reuniones de desarrolladores principales posteriores involucró discusiones relacionadas. Los temas principales incluyen:
Discusión sobre problemas de codificación ABI
Sincronización de progreso de las diferentes aplicaciones cliente
La implementación de PR en Geth tiene 16000 líneas de código, lo que dificulta determinar su seguridad y efectividad.
Los desarrolladores han indicado que Geth tiene dificultades para completar el desarrollo de EIP-2537 antes de julio.
Proponer buscar ingenieros en criptografía para ayudar con la revisión de PR, utilizar la red de pruebas para probar la seguridad de la implementación.
Discutir si eliminar la optimización de ensamblaje compleja para reducir la dificultad de revisión
Los desarrolladores del contrato de depósito han declarado que la versión que no utiliza EIP-2537 ha sido auditada y están considerando no lanzar una versión que utilice EIP-2537.
Decidir aumentar la prueba de la red de prueba YOLO para probar específicamente el EIP-2537
Hasta aquí se puede ver que la importancia de EIP-2537 ha disminuido significativamente con la finalización del contrato de depósito, y los desarrolladores de Geth consideran que será difícil implementarlo antes de Berlín. Parece que EIP-2537 no será aceptado en Berlín.
Aparecerán más problemas en las próximas reuniones:
Geth encontró un problema en la implementación del PR de EIP-2537, necesita más pruebas y correcciones.
Problemas en la red de prueba YOLO, sospecha que están relacionados con las firmas BLS
Discutir el problema de la diversidad de clientes, considerando congelar la implementación actual de EIP para reducir los costos de desarrollo de otros clientes.
Matter Labs desea incluir EIP-2539 en las pruebas, pero se encuentra con la oposición de los desarrolladores de Geth.
Finalmente, en la 99ª reunión de desarrolladores clave, se decidió mover el EIP-2537 fuera de la red de prueba YOLO v3 y de la actualización Berlin. La principal razón es que el EIP-2537 ha consumido demasiado tiempo de los desarrolladores clave, lo que ha obstaculizado el desarrollo de otros EIPs. Un factor secundario es que la Fundación Ethereum propuso EVM384 como alternativa.
En abril de 2021, Ethereum completó la actualización Berlin, que incluye implementaciones como EIP-2565 que no son complicadas; la actualización es un poco delgada, ya que la más compleja EIP-2537 fue descartada.
Desarrollo posterior
En la actualización de Londres después de Berlín, los desarrolladores consideraron la inclusión de EIP-2537, pero debido a que el cambio de la biblioteca de dependencias podría provocar cambios en el precio del gas, finalmente se abandonó nuevamente por su complejidad.
En junio de 2021, se propuso oficialmente la inclusión de EIP-2537 en la actualización de Shanghai. Sin embargo, la actualización de Merge ocupó gran parte del tiempo de los desarrolladores. Después de que se completó Merge en septiembre de 2022, los desarrolladores finalmente tuvieron la oportunidad de continuar la discusión sobre los objetivos de Shanghai.
En noviembre de 2022, los desarrolladores consideraron que EIP-2537 necesitaba ser pospuesto, la actualización de Shanghai se centra en apoyar el retiro de PoS. La actualización de Cancun tampoco discutió EIP-2537 debido a su enfoque en EIP-4844.
Hasta febrero de 2024, los desarrolladores discutieron la inclusión de EIP-2537 en la actualización de Pectra, considerando que la implementación ya no era un problema, solo existían algunos problemas de precios de consumo de gas. De diciembre de 2024 a enero de 2025, los desarrolladores discutieron el modelo de cálculo de costos específico, resolviendo finalmente el problema de costos de EIP-2537.
Resumen
EIP-2537 fue propuesto en febrero de 2020 y se finalizó en enero de 2025, lo que representa casi 5 años de tiempo. Durante este período, se ha pospuesto varias veces debido a la complejidad de su implementación o a que no se alineaba con el tema de la actualización. Esto indica que la inclusión de un EIP en una actualización de Ethereum no solo depende de su valor intrínseco, sino que también necesita considerar factores del proceso histórico. Cada actualización de Ethereum tiene su propio tema; aunque EIP-2537 fue una de las EIPs más importantes de la actualización de Berlin, fue descartada debido a su dificultad. Posteriormente, Ethereum entró en el proceso histórico de PoS, y los EIPs de capa de ejecución pura no recibieron atención, lo que llevó a que EIP-2537 no fuera aceptado durante mucho tiempo.
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.
17 me gusta
Recompensa
17
7
Republicar
Compartir
Comentar
0/400
BakedCatFanboy
· 08-09 07:22
¡Finalmente llegó después de ocho años!
Ver originalesResponder0
rugpull_ptsd
· 08-06 22:13
¿Realmente se puede esperar cinco años para que se suba a la cadena?
Ver originalesResponder0
MetaverseHermit
· 08-06 08:26
Cinco años para completar una actualización, qué lento.
Ver originalesResponder0
CoconutWaterBoy
· 08-06 08:25
Cinco años para una actualización, realmente es estable.
Ver originalesResponder0
SignatureVerifier
· 08-06 08:24
técnicamente esta implementación de bls necesita pruebas de penetración serias, hemos visto estas precompilaciones a medio hornear antes...
Ver originalesResponder0
MEVHunterX
· 08-06 08:14
Esta propuesta es demasiado lenta.
Ver originalesResponder0
TrustMeBro
· 08-06 08:14
5 años... Parece que esto de las actualizaciones no es fácil.
EIP-2537 un largo camino: desde el rechazo de la actualización de Berlín hasta la adopción final de Pectra
EIP-2537: El largo camino de los cálculos de curvas de Ethereum
EIP-2537 es una instrucción de precompilación de EVM que se determinó añadir en la reciente actualización del fork de Pectra. Esta instrucción añade diversas funciones de cálculo de la curva BLS12-381 al EVM, incluyendo cálculos de emparejamiento en el dominio de la curva.
EIP-2573 fue propuesto inicialmente 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é pasaron 5 años para que esta propuesta fuera incluida en la actualización.
Antecedentes de la propuesta
En enero de 2017, Vitalik Buterin presentó por primera vez el algoritmo de emparejamiento y la curva alt_bn128. Posteriormente, Vitalik y Christian Reitwiessner propusieron EIP-196 y EIP-197, que añadieron soporte para cálculos de la curva alt_bn128 en el EVM. La actualización de Byzantium en octubre de 2017 incorporó oficialmente la curva alt_bn128, lo que permitió realizar cálculos de emparejamiento en el dominio de la curva dentro del EVM, permitiendo que la verificación de pruebas ZK-Snarks se pudiera completar dentro del EVM.
En noviembre de 2017, el equipo de zcash propuso la curva BLS12-381, que ofrece una mayor seguridad y rendimiento en comparación con alt_bn128. Muchos protocolos de blockchain adoptaron posteriormente la curva BLS12-381, abandonando la curva alt_bn128.
En mayo de 2018, Justin Drake señaló que las actualizaciones futuras de PoS y fragmentación de Ethereum podrían utilizar un algoritmo de firma múltiple BLS basado en la curva BLS12-381. Esto hizo que el anterior plan EIP-1011 quedara fuera de escena, y la posterior actualización de ETH2 finalmente adoptó la curva BLS12-381.
Con el desarrollo de ETH2, ha surgido un llamado para introducir BLS12-381 en la capa de ejecución de ETH. En febrero de 2020, algunos investigadores propusieron EIP-2537, con la esperanza de probarlo en la red de pruebas de ETH2. El autor de EIP-2537, Alex Stokes, hizo un llamado para incluirlo en la bifurcación dura de Berlín.
Curiosamente, el autor de EIP-2537 también es cofundador de Matter Labs, cuyo producto más famoso es ZKSync.
Berlín en turbulencia
Antes de introducir el contenido posterior, es necesario mencionar 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 tres curvas: BLS12, BN y MNT4/6. Este EIP planea agregar 10 instrucciones precompiladas de una sola vez para procesar diferentes curvas. Sin embargo, muchos desarrolladores cuestionan que la propuesta es demasiado compleja y difícil de implementar, y que no es conveniente para los ingenieros de contratos inteligentes. Como proponente, Matter Labs ha completado el desarrollo del algoritmo de curvas elípticas y ha proporcionado implementaciones de referencia en varios idiomas.
Para resolver el problema de EIP-1962, Matter Labs propuso en febrero de 2020 múltiples EIPs que dividen EIP-1962, heredando parcialmente su interfaz:
Entre ellos, el EIP-2537 es el más importante, ya que la capa de consenso también utiliza la curva BLS12-381. El objetivo principal del EIP-1962 y del EIP-2537 es implementar la verificación de firmas BLS en la capa de consenso en la red principal. En ese momento, ETH2 estaba desarrollando el contrato de depósito; debido a la falta de un algoritmo de verificación BLS en la capa de ejecución, el diseño original no verificaba firmas en el contrato de depósito, sino que la verificación era realizada por la capa de consenso, y si se encontraba algún error, podría resultar en la pérdida de fondos del usuario.
En este contexto, los desarrolladores principales buscan introducir la precompilación BLS12-381 para verificar firmas dentro del contrato de depósito, evitando así posibles pérdidas de fondos de los usuarios. Esta 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 señaló que existía una serie de problemas, principalmente centrados en el contenido del documento EIP. Posteriormente, el autor participó en la discusión de respuestas. En la reunión de desarrolladores principales del 6 de marzo de 2020, Vitalik consideró que EIP-2537, entre otros, era muy efectivo para las pruebas SNARK recursivas y que a largo plazo no perjudicaría a Ethereum. La reunión confirmó la prioridad de EIP-2537, y todos los clientes acordaron implementarlo lo antes posible, planeando completar el desarrollo antes de la actualización de Berlín.
Luego, EIP-2537 se convirtió en una tarea de alta prioridad. La reunión del 20 de marzo confirmó que EIP-2537 reemplazaría a EIP-1962 como propuesta central de BLS y entraría en la lista de preselección para la actualización de Berlín. La reunión de abril formalmente incluyó EIP-2537 en la actualización del hard fork de Berlín, determinando una línea de tiempo para su implementación en abril y pruebas en mayo y junio, y lo clasificó como un asunto de máxima prioridad.
A continuación, EIP-2537 entra en una etapa masiva de pruebas de desarrollo, y casi cada una de las cerca de 20 reuniones de desarrolladores principales posteriores involucró discusiones relacionadas. Los temas principales incluyen:
Hasta aquí se puede ver que la importancia de EIP-2537 ha disminuido significativamente con la finalización del contrato de depósito, y los desarrolladores de Geth consideran que será difícil implementarlo antes de Berlín. Parece que EIP-2537 no será aceptado en Berlín.
Aparecerán más problemas en las próximas reuniones:
Finalmente, en la 99ª reunión de desarrolladores clave, se decidió mover el EIP-2537 fuera de la red de prueba YOLO v3 y de la actualización Berlin. La principal razón es que el EIP-2537 ha consumido demasiado tiempo de los desarrolladores clave, lo que ha obstaculizado el desarrollo de otros EIPs. Un factor secundario es que la Fundación Ethereum propuso EVM384 como alternativa.
En abril de 2021, Ethereum completó la actualización Berlin, que incluye implementaciones como EIP-2565 que no son complicadas; la actualización es un poco delgada, ya que la más compleja EIP-2537 fue descartada.
Desarrollo posterior
En la actualización de Londres después de Berlín, los desarrolladores consideraron la inclusión de EIP-2537, pero debido a que el cambio de la biblioteca de dependencias podría provocar cambios en el precio del gas, finalmente se abandonó nuevamente por su complejidad.
En junio de 2021, se propuso oficialmente la inclusión de EIP-2537 en la actualización de Shanghai. Sin embargo, la actualización de Merge ocupó gran parte del tiempo de los desarrolladores. Después de que se completó Merge en septiembre de 2022, los desarrolladores finalmente tuvieron la oportunidad de continuar la discusión sobre los objetivos de Shanghai.
En noviembre de 2022, los desarrolladores consideraron que EIP-2537 necesitaba ser pospuesto, la actualización de Shanghai se centra en apoyar el retiro de PoS. La actualización de Cancun tampoco discutió EIP-2537 debido a su enfoque en EIP-4844.
Hasta febrero de 2024, los desarrolladores discutieron la inclusión de EIP-2537 en la actualización de Pectra, considerando que la implementación ya no era un problema, solo existían algunos problemas de precios de consumo de gas. De diciembre de 2024 a enero de 2025, los desarrolladores discutieron el modelo de cálculo de costos específico, resolviendo finalmente el problema de costos de EIP-2537.
Resumen
EIP-2537 fue propuesto en febrero de 2020 y se finalizó en enero de 2025, lo que representa casi 5 años de tiempo. Durante este período, se ha pospuesto varias veces debido a la complejidad de su implementación o a que no se alineaba con el tema de la actualización. Esto indica que la inclusión de un EIP en una actualización de Ethereum no solo depende de su valor intrínseco, sino que también necesita considerar factores del proceso histórico. Cada actualización de Ethereum tiene su propio tema; aunque EIP-2537 fue una de las EIPs más importantes de la actualización de Berlin, fue descartada debido a su dificultad. Posteriormente, Ethereum entró en el proceso histórico de PoS, y los EIPs de capa de ejecución pura no recibieron atención, lo que llevó a que EIP-2537 no fuera aceptado durante mucho tiempo.