EIP-2537: El largo camino de las instrucciones precompiladas BLS12-381 de Ethereum
EIP-2537 es la última instrucción precompilada de EVM que se ha determinado agregar en la actualización del fork de Pectra. Esta instrucción añade múltiples funciones de cálculo de la curva BLS12-381 a la EVM, incluyendo cálculos de emparejamiento 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 presentará la trayectoria de gobernanza de EIP-2537 y explorará por qué esta propuesta tardó 5 años en ser finalmente incorporada a 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. Luego, Vitalik y Christian Reitwiessner propusieron EIP-196 y EIP-197, que añadieron soporte para cálculos de la curva alt_bn128 en la EVM. Estas propuestas fueron adoptadas oficialmente en la actualización de Byzantium en octubre de 2017, implementando cálculos de emparejamiento en el dominio de la curva dentro de la EVM, lo que permite que la verificación de pruebas ZK-Snarks se realice dentro de la EVM.
Con el desarrollo de la criptografía, el equipo de zcash propuso la curva BLS12-381 en noviembre de 2017. En comparación con alt_bn128, BLS12-381 tiene una mayor seguridad y un mejor rendimiento. Muchos protocolos de blockchain han comenzado a utilizar la curva BLS12-381 en lugar de la curva alt_bn128.
En mayo de 2018, Justin Drake señaló que las futuras actualizaciones de PoS y fragmentación de Ethereum podrían utilizar el algoritmo BLS de múltiples firmas basado en la curva BLS12-381. Esto hizo que el plan original EIP-1011 saliera de la escena histórica. De hecho, la posterior actualización ETH2 adoptó la curva BLS12-381.
Con el desarrollo de ETH2, la demanda de introducir BLS12-381 en la capa de ejecución de ETH es cada vez más alta. En febrero de 2020, los investigadores propusieron el EIP-2537, con la esperanza de que esta propuesta pudiera ser probada junto con la red de prueba de ETH2. El autor del EIP-2537, Alex Stokes, hizo un llamado para incluir el EIP-2537 en la bifurcación dura de Berlín.
Cabe mencionar que el autor de EIP-2537 también es cofundador de Matter Labs, desarrollador de ZKSync.
Los contratiempos de la actualización de Berlín
Antes de introducir el contenido posterior, primero necesitamos entender el EIP-1962. Esta es la primera propuesta sobre la 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.
EIP-1962 planea aumentar de una vez 10 instrucciones precompiladas para manejar diferentes curvas. Sin embargo, la propuesta es demasiado compleja, lo que hace difícil su implementación para los desarrolladores. Al mismo tiempo, debido a su alta generalización, también es complicado para los ingenieros de contratos inteligentes llamarlo. Sin embargo, Matter Labs ya ha completado el desarrollo del algoritmo de curva elíptica y ha proporcionado referencias en varios idiomas.
Para resolver el problema de EIP-1962, Matter Labs propuso en febrero de 2020 múltiples EIP que dividen EIP-1962, y algunas heredan su interfaz. Estos EIP incluyen:
EIP-2537: proporciona soporte para BLS12-381
EIP-2539: soporte para BLS12-377
PR#2541: Proporcionar soporte para la curva BLS12-377 (Zexe ), pero no se ha obtenido el 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. Los objetivos principales del EIP-1962 y del EIP-2537 son implementar la verificación de firmas BLS en la capa de consenso en la red principal. En ese momento, ETH2 estaba diseñando el contrato de depósito; debido a que la capa de ejecución no tiene el algoritmo de verificación BLS, el contrato de depósito no verificará la firma. Las firmas BLS específicas serán verificadas por la capa de consenso después de que el usuario realice el depósito; si se encuentra algún error, podría resultar en la pérdida de fondos del usuario.
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ósito, evitando posibles pérdidas de fondos ETH2 para los usuarios. Esta fue la razón por la que muchos desarrolladores estaban interesados en EIP-1962 y EIP-2537 en ese momento.
Después de la propuesta de EIP-2537, Vitalik señaló de inmediato una serie de problemas, centrándose principalmente en el contenido del documento EIP. Los autores de EIP respondieron y discutieron posteriormente. En la reunión de desarrolladores principales del 6 de marzo de 2020, Vitalik consideró que EIP-2537 y otros EIPs son muy efectivos para la prueba SNARK recursiva, y a largo plazo no perjudicarán a Ethereum. La reunión confirmó la prioridad de EIP-2537, y todos los clientes acordaron implementarlo lo antes posible y planean completar el desarrollo antes de la actualización de Berlin.
Desde entonces, 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 la propuesta central de BLS y entraría en la lista preliminar de la actualización de Berlín. En la reunión de abril, se incluyó oficialmente EIP-2537 en la actualización del hard fork de Berlín, estableciendo una línea de tiempo para su implementación en abril y pruebas en mayo y junio, y se clasificó como un asunto de máxima prioridad.
Luego, EIP-2537 entró en una fase masiva de desarrollo y pruebas, donde se discutió en casi 20 reuniones de desarrolladores principales posteriores.
En la 85ª reunión, los desarrolladores discutieron el problema de codificación ABI de EIP-2537. El cliente Besu indicó que había implementado funcionalidad básica, pero desde el lado de Geth no se ha iniciado ningún trabajo relacionado.
En la 86ª reunión, Geth indicó que se ha completado parte del trabajo, pero aún queda mucho 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 su seguridad y efectividad, solo se puede evaluar a través de pruebas de fuzzing simples. Los desarrolladores de Geth creen que no podrán completar el desarrollo de EIP-2537 antes de la fecha programada en Berlín.
La reunión decidió aumentar las pruebas en la red de prueba YOLO específicamente para probar el EIP-2537. En este momento, la importancia del EIP-2537 ha disminuido significativamente, y los desarrolladores de Geth creen que es muy probable que este EIP no se incluya en la actualización de Berlín.
En la 88ª reunión, los desarrolladores de Geth descubrieron una serie de problemas en la implementación del PR de EIP-2537, que necesitan ser probados y reparados. Dentro del sistema Geth existen dos implementaciones de EIP-2537, una que incluye optimizaciones en ensamblador y otra completamente escrita en Go; se sugirió utilizar directamente la versión en Go para reducir la dificultad de la revisión del código.
En la 89ª reunión surgió un problema más grave, la red de prueba YOLO presentó anomalías, se sospecha que es causado por la firma BLS, pero el desarrollador de EIP-2537 lo negó. La buena noticia es que el contrato de depósito basado en EIP-2537 está casi terminado y está esperando auditoría.
La 90ª reunión fijó el plazo para el lanzamiento de la actualización Berlin en julio. La reunión también discutió el tema de la dominancia de Geth, y se propuso congelar la implementación actual de EIP para reducir los costos de desarrollo de otros clientes.
La 92ª reunión aún confirma el EIP-2537 como el EIP necesario para la actualización de Berlín.
En la 96ª reunión, Matter Labs espera 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 ha sido probado completamente en Geth. Finalmente, se decidió no incluir 2696 en la actualización de Berlín.
La 99ª reunión 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 principales, afectando el desarrollo de otros EIP. Un factor secundario es que la Fundación Ethereum propuso EVM384 como alternativa.
En abril de 2021, Ethereum completó la actualización Berlin, donde la implementación real de EIP-2565 y otros no es complicada, la actualización parece ligera, esto se debe a que el EIP-2537, que es el más complejo, fue eliminado.
Desarrollo futuro
La actualización de Londres, después de la actualización de Berlín, introdujo EIP-1559. Para EIP-2537, que fue una propuesta central, es difícil que las actualizaciones posteriores la incluyan.
La actualización de Londres está en curso, los desarrolladores consideraron agregar EIP-2537. La 109ª reunión sincronizó la situación del desarrollo de EIP-2537 y discutió el problema del uso de gas; alguien propuso reemplazar EIP-2537 con EVM384. Sin embargo, en la 111ª reunión, EIP-2537 fue retirado de la actualización de Londres debido a su complejidad. Principalmente, la implementación del estándar EIP-2537 cambió las bibliotecas dependientes, lo que podría provocar cambios en la fijación de precios del gas, y cada cliente necesita reevaluar el consumo de gas.
En junio de 2021, se propuso oficialmente incluir el EIP-2537 en la actualización de Shanghai. Sin embargo, la actualización de Merge ocupó mucho tiempo de los desarrolladores. Después de que se completara Merge en septiembre de 2022, 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, la 150ª reunión discutió brevemente si incluir el EIP-2537 en la actualización de Shanghai, pero se consideró necesario posponerlo. La actualización de Shanghai se centra en apoyar los retiros de PoS. Finalmente, el EIP-2537 no se incluyó en la actualización de Shanghai, que tiene como núcleo la función de retiro.
Cancún no ha discutido la actualización de EIP-2537, porque su núcleo es apoyar EIP-4844, proporcionando una capa de disponibilidad de datos Blob para la segunda capa.
En febrero de 2024, en la 181ª reunión se discutió la inclusión de EIP-2537 en la actualización de Pectra, considerando que la implementación ya no es un problema, solo existe un problema con la fijación de precios del consumo de gas.
En la reunión número 202 del 19 de diciembre de 2024, los desarrolladores de Nethermind confirmaron el modelo de precios de EIP-2537. El proponente inicial, Matter Labs, casi ha salido de la discusión en este momento. La reunión número 203 de enero de 2025 discutió la revalorización de la precompilación BLS, y los desarrolladores de Geth sugirieron aumentar el costo de gas en un 20%, recibiendo el apoyo del equipo de Besu en las pruebas de referencia.
Resumen
La evolución de EIP-2537 se puede resumir de la siguiente manera:
Febrero de 2020: se propone oficialmente la división EIP-1962 y EIP-2537
Abril-Octubre de 2020: Múltiples discusiones sobre problemas de implementación, finalmente abandonado por 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: se discutió si incluir la actualización de Shanghai, sin resultado.
Febrero de 2024: se considera que no hay problemas en su implementación, aún existen problemas de costos de gas, se puede incluir en la actualización de Pectra.
Diciembre de 2024 - Enero de 2025: Discutir el modelo de costos específico y resolver oficialmente el problema de costos.
La inclusión de EIP en la actualización de Ethereum depende tanto de su propio esfuerzo como de considerar el proceso histórico. Cada actualización tiene un tema; EIP-2537 fue el núcleo de la actualización de Berlín, pero fue descartado debido a su complejidad. Después, Ethereum se centró en PoS, y las EIP de capa de ejecución pura no recibieron atención, lo que llevó a que EIP-2537 no fuera aceptado durante mucho tiempo. Hasta hace poco, los desarrolladores volvieron a prestar atención y resolvieron los problemas pendientes.
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.
19 me gusta
Recompensa
19
5
Republicar
Compartir
Comentar
0/400
UncleLiquidation
· hace22h
Cinco años para empezar, el ritmo de desarrollo de Ethereum es realmente lento.
Ver originalesResponder0
Anon32942
· hace22h
He estado jugando y esperando durante cinco años, recientemente hubo una diferencia de precios.
Ver originalesResponder0
GasWrangler
· hace22h
realmente les tomó 5 años optimizar algo tan trivial matemáticamente... smh ante la ineficiencia de layer1
La instrucción precompilada BLS de Ethereum EIP-2537 ha sido adoptada después de 5 años.
EIP-2537: El largo camino de las instrucciones precompiladas BLS12-381 de Ethereum
EIP-2537 es la última instrucción precompilada de EVM que se ha determinado agregar en la actualización del fork de Pectra. Esta instrucción añade múltiples funciones de cálculo de la curva BLS12-381 a la EVM, incluyendo cálculos de emparejamiento 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 presentará la trayectoria de gobernanza de EIP-2537 y explorará por qué esta propuesta tardó 5 años en ser finalmente incorporada a 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. Luego, Vitalik y Christian Reitwiessner propusieron EIP-196 y EIP-197, que añadieron soporte para cálculos de la curva alt_bn128 en la EVM. Estas propuestas fueron adoptadas oficialmente en la actualización de Byzantium en octubre de 2017, implementando cálculos de emparejamiento en el dominio de la curva dentro de la EVM, lo que permite que la verificación de pruebas ZK-Snarks se realice dentro de la EVM.
Con el desarrollo de la criptografía, el equipo de zcash propuso la curva BLS12-381 en noviembre de 2017. En comparación con alt_bn128, BLS12-381 tiene una mayor seguridad y un mejor rendimiento. Muchos protocolos de blockchain han comenzado a utilizar la curva BLS12-381 en lugar de la curva alt_bn128.
En mayo de 2018, Justin Drake señaló que las futuras actualizaciones de PoS y fragmentación de Ethereum podrían utilizar el algoritmo BLS de múltiples firmas basado en la curva BLS12-381. Esto hizo que el plan original EIP-1011 saliera de la escena histórica. De hecho, la posterior actualización ETH2 adoptó la curva BLS12-381.
Con el desarrollo de ETH2, la demanda de introducir BLS12-381 en la capa de ejecución de ETH es cada vez más alta. En febrero de 2020, los investigadores propusieron el EIP-2537, con la esperanza de que esta propuesta pudiera ser probada junto con la red de prueba de ETH2. El autor del EIP-2537, Alex Stokes, hizo un llamado para incluir el EIP-2537 en la bifurcación dura de Berlín.
Cabe mencionar que el autor de EIP-2537 también es cofundador de Matter Labs, desarrollador de ZKSync.
Los contratiempos de la actualización de Berlín
Antes de introducir el contenido posterior, primero necesitamos entender el EIP-1962. Esta es la primera propuesta sobre la 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.
EIP-1962 planea aumentar de una vez 10 instrucciones precompiladas para manejar diferentes curvas. Sin embargo, la propuesta es demasiado compleja, lo que hace difícil su implementación para los desarrolladores. Al mismo tiempo, debido a su alta generalización, también es complicado para los ingenieros de contratos inteligentes llamarlo. Sin embargo, Matter Labs ya ha completado el desarrollo del algoritmo de curva elíptica y ha proporcionado referencias en varios idiomas.
Para resolver el problema de EIP-1962, Matter Labs propuso en febrero de 2020 múltiples EIP que dividen EIP-1962, y algunas heredan su interfaz. Estos EIP incluyen:
Entre ellos, el EIP-2537 es el más importante, ya que la capa de consenso también utiliza la curva BLS12-381. Los objetivos principales del EIP-1962 y del EIP-2537 son implementar la verificación de firmas BLS en la capa de consenso en la red principal. En ese momento, ETH2 estaba diseñando el contrato de depósito; debido a que la capa de ejecución no tiene el algoritmo de verificación BLS, el contrato de depósito no verificará la firma. Las firmas BLS específicas serán verificadas por la capa de consenso después de que el usuario realice el depósito; si se encuentra algún error, podría resultar en la pérdida de fondos del usuario.
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ósito, evitando posibles pérdidas de fondos ETH2 para los usuarios. Esta fue la razón por la que muchos desarrolladores estaban interesados en EIP-1962 y EIP-2537 en ese momento.
Después de la propuesta de EIP-2537, Vitalik señaló de inmediato una serie de problemas, centrándose principalmente en el contenido del documento EIP. Los autores de EIP respondieron y discutieron posteriormente. En la reunión de desarrolladores principales del 6 de marzo de 2020, Vitalik consideró que EIP-2537 y otros EIPs son muy efectivos para la prueba SNARK recursiva, y a largo plazo no perjudicarán a Ethereum. La reunión confirmó la prioridad de EIP-2537, y todos los clientes acordaron implementarlo lo antes posible y planean completar el desarrollo antes de la actualización de Berlin.
Desde entonces, 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 la propuesta central de BLS y entraría en la lista preliminar de la actualización de Berlín. En la reunión de abril, se incluyó oficialmente EIP-2537 en la actualización del hard fork de Berlín, estableciendo una línea de tiempo para su implementación en abril y pruebas en mayo y junio, y se clasificó como un asunto de máxima prioridad.
Luego, EIP-2537 entró en una fase masiva de desarrollo y pruebas, donde se discutió en casi 20 reuniones de desarrolladores principales posteriores.
En la 85ª reunión, los desarrolladores discutieron el problema de codificación ABI de EIP-2537. El cliente Besu indicó que había implementado funcionalidad básica, pero desde el lado de Geth no se ha iniciado ningún trabajo relacionado.
En la 86ª reunión, Geth indicó que se ha completado parte del trabajo, pero aún queda mucho 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 su seguridad y efectividad, solo se puede evaluar a través de pruebas de fuzzing simples. Los desarrolladores de Geth creen que no podrán completar el desarrollo de EIP-2537 antes de la fecha programada en Berlín.
La reunión decidió aumentar las pruebas en la red de prueba YOLO específicamente para probar el EIP-2537. En este momento, la importancia del EIP-2537 ha disminuido significativamente, y los desarrolladores de Geth creen que es muy probable que este EIP no se incluya en la actualización de Berlín.
En la 88ª reunión, los desarrolladores de Geth descubrieron una serie de problemas en la implementación del PR de EIP-2537, que necesitan ser probados y reparados. Dentro del sistema Geth existen dos implementaciones de EIP-2537, una que incluye optimizaciones en ensamblador y otra completamente escrita en Go; se sugirió utilizar directamente la versión en Go para reducir la dificultad de la revisión del código.
En la 89ª reunión surgió un problema más grave, la red de prueba YOLO presentó anomalías, se sospecha que es causado por la firma BLS, pero el desarrollador de EIP-2537 lo negó. La buena noticia es que el contrato de depósito basado en EIP-2537 está casi terminado y está esperando auditoría.
La 90ª reunión fijó el plazo para el lanzamiento de la actualización Berlin en julio. La reunión también discutió el tema de la dominancia de Geth, y se propuso congelar la implementación actual de EIP para reducir los costos de desarrollo de otros clientes.
La 92ª reunión aún confirma el EIP-2537 como el EIP necesario para la actualización de Berlín.
En la 96ª reunión, Matter Labs espera 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 ha sido probado completamente en Geth. Finalmente, se decidió no incluir 2696 en la actualización de Berlín.
La 99ª reunión 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 principales, afectando el desarrollo de otros EIP. Un factor secundario es que la Fundación Ethereum propuso EVM384 como alternativa.
En abril de 2021, Ethereum completó la actualización Berlin, donde la implementación real de EIP-2565 y otros no es complicada, la actualización parece ligera, esto se debe a que el EIP-2537, que es el más complejo, fue eliminado.
Desarrollo futuro
La actualización de Londres, después de la actualización de Berlín, introdujo EIP-1559. Para EIP-2537, que fue una propuesta central, es difícil que las actualizaciones posteriores la incluyan.
La actualización de Londres está en curso, los desarrolladores consideraron agregar EIP-2537. La 109ª reunión sincronizó la situación del desarrollo de EIP-2537 y discutió el problema del uso de gas; alguien propuso reemplazar EIP-2537 con EVM384. Sin embargo, en la 111ª reunión, EIP-2537 fue retirado de la actualización de Londres debido a su complejidad. Principalmente, la implementación del estándar EIP-2537 cambió las bibliotecas dependientes, lo que podría provocar cambios en la fijación de precios del gas, y cada cliente necesita reevaluar el consumo de gas.
En junio de 2021, se propuso oficialmente incluir el EIP-2537 en la actualización de Shanghai. Sin embargo, la actualización de Merge ocupó mucho tiempo de los desarrolladores. Después de que se completara Merge en septiembre de 2022, 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, la 150ª reunión discutió brevemente si incluir el EIP-2537 en la actualización de Shanghai, pero se consideró necesario posponerlo. La actualización de Shanghai se centra en apoyar los retiros de PoS. Finalmente, el EIP-2537 no se incluyó en la actualización de Shanghai, que tiene como núcleo la función de retiro.
Cancún no ha discutido la actualización de EIP-2537, porque su núcleo es apoyar EIP-4844, proporcionando una capa de disponibilidad de datos Blob para la segunda capa.
En febrero de 2024, en la 181ª reunión se discutió la inclusión de EIP-2537 en la actualización de Pectra, considerando que la implementación ya no es un problema, solo existe un problema con la fijación de precios del consumo de gas.
En la reunión número 202 del 19 de diciembre de 2024, los desarrolladores de Nethermind confirmaron el modelo de precios de EIP-2537. El proponente inicial, Matter Labs, casi ha salido de la discusión en este momento. La reunión número 203 de enero de 2025 discutió la revalorización de la precompilación BLS, y los desarrolladores de Geth sugirieron aumentar el costo de gas en un 20%, recibiendo el apoyo del equipo de Besu en las pruebas de referencia.
Resumen
La evolución de EIP-2537 se puede resumir de la siguiente manera:
La inclusión de EIP en la actualización de Ethereum depende tanto de su propio esfuerzo como de considerar el proceso histórico. Cada actualización tiene un tema; EIP-2537 fue el núcleo de la actualización de Berlín, pero fue descartado debido a su complejidad. Después, Ethereum se centró en PoS, y las EIP de capa de ejecución pura no recibieron atención, lo que llevó a que EIP-2537 no fuera aceptado durante mucho tiempo. Hasta hace poco, los desarrolladores volvieron a prestar atención y resolvieron los problemas pendientes.