Además de la compilación del texto original, este artículo también completa la introducción de otros EIPs de Pectra que no se mencionan en el texto original.
Enlace original:
Puntos clave
Pectra es la próxima gran actualización de Ethereum, que implica cambios en la capa de ejecución (Praga) y la capa de consenso (Electra). Después de una serie de altibajos en la actualización de la red de pruebas Pectra, se ha decidido activar la actualización de la red principal Pectra alrededor de las 10:05 UTC del 7 de mayo.
Esta actualización realizará mejoras clave en la participación, la escalabilidad de Layer 2 y la experiencia del usuario (UX), sentando las bases para futuras transformaciones.
Los principales cambios incluyen: aumentar el límite de estaca de los validadores, retiros de estaca flexibles, mejoras en la abstracción de cuentas y aumento de la capacidad de procesamiento de blobs para mejorar la eficiencia y seguridad de la red.
Introducción
Han pasado 31 meses desde la "fusión" (The Merge), 24 meses desde la actualización "Shapella", 13 meses desde la actualización "Dencun" y Ethereum se está preparando para la próxima gran actualización — el hard fork Pectra.
Y antes de la actualización de la red principal de Pectra, la actualización de la red de pruebas fue un proceso lleno de altibajos.
La actualización de Pectra de la testnet de Holesky se activó el 24 de febrero a las 21:55 UTC, pero se interrumpió debido a un error de configuración del software del cliente (direcciones de contrato de depósito incorrectas en Geth, Nethermind y Besu), lo que provocó una bifurcación de la cadena. Los desarrolladores discutieron un plan para restaurar la red a través de un evento de penalización masiva, con el objetivo de acelerar la salida de los validadores erróneos y lograr la finalización de la red, que no se podrá lograr hasta el 11 de marzo.
La actualización de Pectra en la red de pruebas Sepolia se realizó según lo programado el 5 de marzo. Debido a un problema de configuración del contrato de depósito personalizado, algunos clientes de la capa de ejecución (EL) experimentaron excepciones al incluir transacciones en el bloque. Sin embargo, el problema se solucionó rápidamente y la red logró la finalización.
El 19 de marzo, se lanzó la nueva red de pruebas Hoodi para probar la salida de los validadores, y el 26 de marzo se activó con éxito la actualización de la red Pectra.
La actualización de la red de prueba Pectra de Ethereum ha pasado por altibajos durante dos meses, allanando el camino para el despliegue en la red principal, y se ha decidido activar la actualización de la red principal de Pectra alrededor de las 10:05 UTC del 7 de mayo.
Al igual que las actualizaciones anteriores de Ethereum, Pectra implica tanto la capa de ejecución (EL) como la capa de consenso (CL). Su nombre refleja este doble enfoque: Praga representa la actualización de la capa de ejecución, en honor a la sede de Devcon 4; Electra simboliza la actualización de la capa de consenso.
Pectra es uno de los hard forks que más EIPs (Propuestas de Mejora de Ethereum) ha involucrado en la historia de Ethereum, con un total de 11 EIPs. Se basa en la actualización Dencun del año pasado y se optimiza aún más, con el objetivo de mejorar la experiencia del usuario (UX), optimizar las operaciones de los validadores y promover la escalabilidad de Layer 2, se espera que tenga un impacto profundo en el ecosistema de Ethereum.
En este artículo, clasificaremos y dividiremos según el área de cada EIP, analizando en profundidad cada EIP.
Mejoras en el mecanismo de validadores y staking
Pectra optimiza la experiencia de operación de los validadores en el sistema PoS de Ethereum a través de tres principales EIP:
EIP-7251: Aumentar el saldo máximo efectivo (MaxEB)
Actualmente, el mecanismo de staking de Ethereum limita el límite de staking efectivo de un solo validador a 32 ETH, lo que significa que los stakers independientes deben hacer staking en unidades de 32 ETH, y las recompensas que superen este límite no se contabilizan en el staking efectivo.
La propuesta EIP-7251 eleva el saldo máximo efectivo (MaxEB) a 2048 ETH, permitiendo que el rango de staking de un solo validador se expanda de 32 a 2048 ETH, con impactos que incluyen:
· Aumentar la flexibilidad del staking: los stakers pueden reinvertir todas las ganancias en el saldo de staking efectivo, sin estar limitados por múltiplos de 32 ETH. Por ejemplo, un validador que posee 33 ETH puede ahora recibir recompensas de staking por los 33 ETH, mejorando la eficiencia y flexibilidad del capital.
· Reducir el número de validadores: actualmente, Ethereum tiene un total de 1.05 millones de validadores activos, este EIP permite a los grandes operadores combinar sus validadores, lo que reduce el total y alivia la carga en la red.
· Reducir la carga de la red: Aunque un mayor número de validadores ayuda a la descentralización, también aumenta la carga de ancho de banda y cálculo. Aumentar MaxEB puede optimizar el conjunto de validadores y reducir los costos de comunicación punto a punto.
EIP-7002: Capa de ejecución puede activar retiros
EIP-7002 mejora aún más las funciones de los validadores, permitiéndoles activar directamente la salida y los retiros parciales mediante el recibo de retiro a través de la capa de ejecución (0x01).
Actualmente, los validadores tienen dos claves:
Clave de actividad, utilizada para llevar a cabo funciones de verificación;
Clave de retiro, utilizada para acceder y gestionar los fondos en staking.
Anteriormente, solo las claves de actividad podían activar el retiro, mientras que las claves de retiro no podían operar de manera independiente. EIP-7002 permite que las claves de retiro también puedan activar el retiro, lo que trae:
· Mayor control sobre los fondos: los validadores pueden gestionar los fondos directamente sin depender de los operadores de nodos.
· Soporta grupos de staking completamente no confiables, aumentando la seguridad y el grado de descentralización.
EIP-6110: Depósito de validadores en almacenamiento en cadena
Actualmente, después de que los nuevos validadores realizan depósitos en la capa de ejecución, deben esperar a que la capa de consenso los reconozca y procese, lo que provoca retrasos en la activación.
EIP-6110 permite que la capa de ejecución transfiera directamente la información de depósitos a la capa de consenso, reduciendo pasos de verificación adicionales y acortando el tiempo de activación de los validadores de aproximadamente 9 horas a aproximadamente 13 minutos.
Mejorar la capacidad de escalado de Layer 2: aumentar el rendimiento de Blob
EIP-7691: Aumentar el rendimiento de Blob
El año pasado, la actualización Dencun introdujo Blobs como una forma eficiente de almacenar datos en rollups de Layer 2. Actualmente, se envían aproximadamente 21,000 Blobs a Ethereum cada día, pero la capacidad se está acercando a su límite, lo que provoca un aumento en las tarifas y limita el rendimiento.
Actualmente, el número objetivo de Blobs por bloque de Ethereum es de 3, con un máximo de 6. La EIP-7691 propone aumentar su valor objetivo a 6 y el valor máximo a 9, para aumentar la capacidad de almacenamiento de datos y mejorar la capacidad de procesamiento y escalabilidad. Esto reducirá los costos de almacenamiento de datos, lo que a su vez disminuirá las tarifas de transacción de L2.
EIP-7623: Aumentar el costo de calldata
Antes de la introducción del mecanismo Blob, L2 utilizaba principalmente calldata para almacenar datos, y en ciertos casos todavía se utiliza, ya que puede ser más rentable.
EIP-7623 aumenta los costos de calldata para incentivar el uso principal de almacenamiento de blob en L2, mejorando así la eficiencia de las transacciones de rollup.
Mejora de la experiencia del usuario (UX)
EIP-7702: Configuración del código de la cuenta EOA
Idea principal: otorgar temporalmente capacidades de contrato inteligente a EOA
EIP-7702 introduce un nuevo tipo de transacción (identificado como 0x04) que permite a las cuentas de propiedad externa (EOA) obtener temporalmente la funcionalidad de un contrato inteligente durante la ejecución de una transacción. Es decir, aunque tradicionalmente las EOA no tienen código y solo se pueden usar para firmar transacciones, a través de esta propuesta, las EOA pueden "cargar" un fragmento de código en una transacción, permitiendo así realizar operaciones complejas como una billetera de contrato inteligente.
Principales ventajas
Operaciones por lotes: los usuarios pueden realizar múltiples operaciones en una sola transacción (por ejemplo, la combinación de aprobar + depositar), evitando el problema de ineficiencia que implicaría realizar múltiples transacciones.
· Gas patrocinado: este mecanismo también puede soportar el patrocinio de tarifas de transacción por terceros, mejorando la experiencia del usuario, permitiendo que los usuarios operen sin necesidad de poseer ETH por adelantado.
· Mejora de la seguridad y flexibilidad: los usuarios pueden ejercer un control de permisos de forma granular sobre las transacciones, como permitir que las subcuentas operen solo bajo condiciones específicas, lo que aumenta la seguridad de la cuenta.
Desafíos potenciales
· Problemas de compatibilidad ecológica: dado que EOA tradicionalmente se considera sin código, algunos contratos inteligentes existentes o verificaciones de seguridad (por ejemplo, require(tx.origin == msg.sender)) pueden necesitar ajustes para adaptarse a este mecanismo de otorgar temporalmente código.
· Aumento de la complejidad de la estructura de transacciones: La introducción de nuevos tipos de transacciones requerirá cambios significativos en las billeteras y clientes, asegurando que no haya vulnerabilidades de seguridad o costos adicionales elevados al manejar nuevos conjuntos de autorizaciones y configuraciones de código temporal.
EIP-7702 permite que las cuentas de usuario (EOA) obtengan temporalmente funciones de contratos inteligentes en una sola transacción, lo que apoya transacciones en lote, patrocinio de transacciones y una gestión de permisos más flexible. Este mecanismo puede mejorar enormemente la experiencia del usuario y expandir las funcionalidades de las dApps, pero también romperá algunas suposiciones tradicionales, requiriendo que todas las partes del ecosistema se adapten y actualicen. En general, es una propuesta importante que allana el camino para la abstracción de cuentas, con el objetivo de que las cuentas de Ethereum en el futuro sean tanto seguras como más flexibles.
Otros EIPs
EIP-7685: Solicitud de capa de ejecución general
Antecedentes y objetivos
Actualmente, entre Eth1 (capa de ejecución) y la cadena de balizas (capa de consenso) se deben procesar tres solicitudes principales:
Depósito: El evento de depósito iniciado por el usuario aparece inicialmente en el bloque Eth1, pero finalmente necesita ser procesado en la cadena de balizas.
Retiro: Las solicitudes de retiro enviadas desde la cadena de balizas (generalmente a través de herramientas de línea de comandos) deben procesarse en Eth1.
Fusión de validadores: De igual manera, esta solicitud también necesita ser transmitida entre Eth1 y la cadena de balizas.
¿Por qué se necesita esta propuesta?
Actualmente, diferentes tipos de operaciones se transmiten entre dos capas, lo que puede causar confusión. El marco de procesamiento unificado propuesto por EIP-7685 tiene como objetivo:
· Manejar todas estas solicitudes de una manera estándar para que el proceso sea más claro y eficiente;
· Al depender únicamente de Eth1 para activar estas operaciones, se pueden separar el entorno de ejecución de los validadores y la gestión de la participación, lo que aumenta la seguridad.
Contenido principal
Identificación del tipo de solicitud: se ha definido una identificación específica para cada operación, como los tipos de solicitud de depósito y retiro existentes, y ahora se debe agregar el tipo de solicitud de fusión.
Garantía de integridad: se utilizarán algunos mecanismos (como la verificación hash y la data merkelizada) para asegurar la integridad y seguridad de los datos solicitados.
Manejo de colas y limitación de velocidad: se establecerán algunas restricciones para las solicitudes pendientes (como el número de depósitos, retiros o solicitudes de fusión que esperan al mismo tiempo) para evitar la sobrecarga del sistema.
significado final
Para los usuarios comunes y los desarrolladores, esto significa que en el futuro, ya sea que se trate de iniciar un depósito, un retiro o una operación de fusión de validadores, se podrán completar más rápido y de manera más segura a través de un proceso unificado y estandarizado. Esto no solo mejora la eficiencia del sistema, sino que también ayuda a reducir el riesgo general.
EIP-2537: Compilación de operaciones de la curva BLS12–381
Propósito principal
Esta propuesta incluye funciones integradas en Ethereum (llamadas contratos precompilados) específicamente para manejar cálculos matemáticos en la curva BLS12–381.
¿Por qué se necesita esta precompilación?
· Mejora de la eficiencia: implementar directamente cálculos complejos de curvas elípticas (como la verificación de firmas y la agregación) en contratos inteligentes consume una gran cantidad de gas. Los contratos precompilados pueden reducir significativamente el costo de estos cálculos.
· Mayor seguridad: en comparación con la curva BN254 actualmente utilizada (que ofrece aproximadamente 80 bits de seguridad), la curva BLS12–381 proporciona alrededor de 120 bits de seguridad, lo que hace que las operaciones criptográficas sean más seguras.
Principal uso
· Verificación de firma BLS: La firma BLS permite agrupar múltiples firmas en una sola, lo que reduce significativamente la carga computacional durante la verificación.
· Verificación de pruebas zkSNARK: En algunos esquemas de protección de la privacidad y escalabilidad, es necesario verificar las pruebas zkSNARK, y estas operaciones también dependen de cálculos complejos de curvas elípticas.
significado real
A través de este EIP, los desarrolladores pueden utilizar operaciones criptográficas relacionadas con la curva BLS12–381 de manera más eficiente y a menor costo en contratos inteligentes, lo que permite apoyar más aplicaciones innovadoras, como mecanismos de consenso más eficientes, interacciones entre cadenas y diversas aplicaciones descentralizadas.
En resumen, EIP-2537 está diseñado para resolver el problema del consumo excesivo de gas durante operaciones de cifrado de alta seguridad en la cadena, haciendo que estos cálculos complejos sean más eficientes y prácticos a través de contratos precompilados.
EIP-2935: Guardar el hash de bloques históricos en el estado
Problema actual
En la máquina virtual de Ethereum (EVM), la operación BLOCKHASH solo puede recuperar el hash de los 256 bloques más recientes (aproximadamente en los últimos 50 minutos), lo cual no es suficiente para ciertas aplicaciones, como las aplicaciones de cadena cruzada que necesitan demostrar datos de bloques más antiguos o clientes sin estado (como rollup).
El núcleo de la propuesta
La propuesta EIP-2935 sugiere guardar 8192 hashes de bloques adicionales en el estado de la blockchain (aproximadamente 27.3 horas), lo que ampliaría significativamente el rango de datos históricos de bloques disponibles para consultas.
¿Cómo realizar?
Además de mantener que el código de operación BLOCKHASH solo puede acceder a los últimos 256 bloques, la propuesta también introducirá un nuevo contrato de sistema especializado:
· set() método: cada vez que se procesa un bloque, el nuevo contrato automáticamente almacenará el hash del bloque actual en un búfer circular.
· get() método: Cualquiera puede consultar el hash de bloques históricos almacenados en el búfer circular a través de este método, ya sea una persona o un contrato inteligente.
Beneficios reales
De esta manera, las aplicaciones de cadena cruzada, rollups u otros sistemas que necesitan acceder a datos de bloques anteriores podrán obtener directamente la información histórica necesaria en la cadena, sin depender adicionalmente de datos externos, lo que hace que su diseño sea más simple, seguro y confiable.
EIP-7840: Añadir programación de blobs al archivo de configuración de EL
Objetivo principal
Esta propuesta tiene como objetivo escribir en el archivo de configuración de la capa de ejecución (EL) los parámetros clave relacionados con la programación de blobs (como el número de blobs permitidos por bloque y la proporción de actualización de la tarifa base).
Método específico
· Agregar la configuración de "número de blobs objetivo" y "número máximo de blobs" en el archivo de configuración.
· Al mismo tiempo, se añade un parámetro llamado baseFeeUpdateFraction, que se utiliza para ajustar la velocidad de actualización de la tarifa base.
· El cliente puede consultar estos parámetros a través de la API del nodo, para conocer la configuración específica del blob en la red actual.
¿Por qué es útil?
Esta información puede ayudar a los desarrolladores y operadores de nodos a estimar de manera más precisa los costos de gas de blob, y también ayuda a la red a gestionar mejor la programación y el procesamiento de grandes cantidades de datos en los bloques.
En general, EIP-7840 añade un conjunto de parámetros de programación de blob configurables a la capa de ejecución de Ethereum, lo que hace que la red sea más eficiente y transparente al procesar grandes datos (blob).
EIP-7549: Mover el índice del comité fuera de la prueba
Idea central
Actualmente, el mensaje de verificación de votos (Attestation) contiene tres partes:
· Votación LMD GHOST (incluye raíz de bloque y ranura de tiempo)
· Votación de Casper-FFG (incluye source y target)
· Índice de la Comisión (index)
El problema es que el índice del comité también está firmado, lo que significa que incluso si el contenido de la votación es el mismo, las raíces de firma generadas serán diferentes debido a los índices distintos. Esto hará que las votaciones con el mismo contenido no puedan ser agregadas.
La solución propuesta por EIP-7549 es: eliminar el índice del comité del mensaje de votación firmado. De esta manera, solo el contenido central de la votación (votación LMD GHOST y Casper-FFG) participará en el cálculo de la firma, lo que permitirá que varios validadores de la misma votación generen la misma raíz de firma, lo que permite que se agreguen.
Principales beneficios
· Reducción drástica de la carga de trabajo de verificación: En la situación actual, para alcanzar un consenso de 2/3, puede ser necesario verificar 1366 votos. Después de eliminar el índice del comité, solo es necesario verificar aproximadamente 22 votos (ahorrando alrededor de 62 veces la carga computacional), lo que mejora significativamente la eficiencia del proceso de verificación que requiere una gran cantidad de cálculos de emparejamiento, especialmente para el cliente Casper FFG basado en pruebas de conocimiento cero.
· Aumentar la eficiencia del almacenamiento de datos en la cadena: dado que la información de votación se puede agregar de manera más eficiente, se pueden empaquetar más votaciones en cada bloque. Ahora, un bloque solo puede contener votaciones de 2 intervalos de tiempo, mientras que con la mejora se podrán incluir hasta 8 intervalos de tiempo, incluso si solo 1/8 de los proponentes están en línea, se podrán incluir todas las votaciones en el bloque.
Al eliminar el índice del comité del mensaje de atestación, no solo se puede reducir drásticamente la cantidad de operaciones de emparejamiento que se deben procesar al validar los votos, sino que también se puede empaquetar de manera más eficiente los datos de votación, mejorando así el rendimiento de todo el proceso de validación del consenso y la utilización del almacenamiento en cadena. Esta mejora es particularmente importante para el mecanismo de consenso Casper FFG y su validación de pruebas de conocimiento cero relacionadas.
Conclusión
Pectra, como una actualización que abarca un número récord de EIP, impulsará el desarrollo de Ethereum en direcciones clave como la abstracción de cuentas, la optimización del mecanismo de validadores, la mejora de la eficiencia de la red y la expansión de Layer 2. Al mismo tiempo, como Vitalik Buterin destacó recientemente, aunque Ethereum adopta una ruta de expansión centrada en Rollup, sigue optimizando Layer 1, como el reciente aumento del límite de Gas a 36 millones, y en el futuro podría mejorar aún más la resistencia a la censura, el rendimiento y la escalabilidad.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Todo lo que necesitas saber sobre la actualización de Ethereum Pectra: Análisis completo de las EIPs
Autor | Tanay Ved, Coin Metrics
Compilación | GaryMa Wu dijo Cadena de bloques
Además de la compilación del texto original, este artículo también completa la introducción de otros EIPs de Pectra que no se mencionan en el texto original.
Enlace original:
Puntos clave
Pectra es la próxima gran actualización de Ethereum, que implica cambios en la capa de ejecución (Praga) y la capa de consenso (Electra). Después de una serie de altibajos en la actualización de la red de pruebas Pectra, se ha decidido activar la actualización de la red principal Pectra alrededor de las 10:05 UTC del 7 de mayo.
Esta actualización realizará mejoras clave en la participación, la escalabilidad de Layer 2 y la experiencia del usuario (UX), sentando las bases para futuras transformaciones.
Los principales cambios incluyen: aumentar el límite de estaca de los validadores, retiros de estaca flexibles, mejoras en la abstracción de cuentas y aumento de la capacidad de procesamiento de blobs para mejorar la eficiencia y seguridad de la red.
Introducción
Han pasado 31 meses desde la "fusión" (The Merge), 24 meses desde la actualización "Shapella", 13 meses desde la actualización "Dencun" y Ethereum se está preparando para la próxima gran actualización — el hard fork Pectra.
Y antes de la actualización de la red principal de Pectra, la actualización de la red de pruebas fue un proceso lleno de altibajos.
La actualización de Pectra de la testnet de Holesky se activó el 24 de febrero a las 21:55 UTC, pero se interrumpió debido a un error de configuración del software del cliente (direcciones de contrato de depósito incorrectas en Geth, Nethermind y Besu), lo que provocó una bifurcación de la cadena. Los desarrolladores discutieron un plan para restaurar la red a través de un evento de penalización masiva, con el objetivo de acelerar la salida de los validadores erróneos y lograr la finalización de la red, que no se podrá lograr hasta el 11 de marzo.
La actualización de Pectra en la red de pruebas Sepolia se realizó según lo programado el 5 de marzo. Debido a un problema de configuración del contrato de depósito personalizado, algunos clientes de la capa de ejecución (EL) experimentaron excepciones al incluir transacciones en el bloque. Sin embargo, el problema se solucionó rápidamente y la red logró la finalización.
El 19 de marzo, se lanzó la nueva red de pruebas Hoodi para probar la salida de los validadores, y el 26 de marzo se activó con éxito la actualización de la red Pectra.
La actualización de la red de prueba Pectra de Ethereum ha pasado por altibajos durante dos meses, allanando el camino para el despliegue en la red principal, y se ha decidido activar la actualización de la red principal de Pectra alrededor de las 10:05 UTC del 7 de mayo.
Al igual que las actualizaciones anteriores de Ethereum, Pectra implica tanto la capa de ejecución (EL) como la capa de consenso (CL). Su nombre refleja este doble enfoque: Praga representa la actualización de la capa de ejecución, en honor a la sede de Devcon 4; Electra simboliza la actualización de la capa de consenso.
Pectra es uno de los hard forks que más EIPs (Propuestas de Mejora de Ethereum) ha involucrado en la historia de Ethereum, con un total de 11 EIPs. Se basa en la actualización Dencun del año pasado y se optimiza aún más, con el objetivo de mejorar la experiencia del usuario (UX), optimizar las operaciones de los validadores y promover la escalabilidad de Layer 2, se espera que tenga un impacto profundo en el ecosistema de Ethereum.
En este artículo, clasificaremos y dividiremos según el área de cada EIP, analizando en profundidad cada EIP.
Mejoras en el mecanismo de validadores y staking
Pectra optimiza la experiencia de operación de los validadores en el sistema PoS de Ethereum a través de tres principales EIP:
EIP-7251: Aumentar el saldo máximo efectivo (MaxEB)
Actualmente, el mecanismo de staking de Ethereum limita el límite de staking efectivo de un solo validador a 32 ETH, lo que significa que los stakers independientes deben hacer staking en unidades de 32 ETH, y las recompensas que superen este límite no se contabilizan en el staking efectivo.
La propuesta EIP-7251 eleva el saldo máximo efectivo (MaxEB) a 2048 ETH, permitiendo que el rango de staking de un solo validador se expanda de 32 a 2048 ETH, con impactos que incluyen:
· Aumentar la flexibilidad del staking: los stakers pueden reinvertir todas las ganancias en el saldo de staking efectivo, sin estar limitados por múltiplos de 32 ETH. Por ejemplo, un validador que posee 33 ETH puede ahora recibir recompensas de staking por los 33 ETH, mejorando la eficiencia y flexibilidad del capital.
· Reducir el número de validadores: actualmente, Ethereum tiene un total de 1.05 millones de validadores activos, este EIP permite a los grandes operadores combinar sus validadores, lo que reduce el total y alivia la carga en la red.
· Reducir la carga de la red: Aunque un mayor número de validadores ayuda a la descentralización, también aumenta la carga de ancho de banda y cálculo. Aumentar MaxEB puede optimizar el conjunto de validadores y reducir los costos de comunicación punto a punto.
EIP-7002: Capa de ejecución puede activar retiros
EIP-7002 mejora aún más las funciones de los validadores, permitiéndoles activar directamente la salida y los retiros parciales mediante el recibo de retiro a través de la capa de ejecución (0x01).
Actualmente, los validadores tienen dos claves:
Clave de actividad, utilizada para llevar a cabo funciones de verificación;
Clave de retiro, utilizada para acceder y gestionar los fondos en staking.
Anteriormente, solo las claves de actividad podían activar el retiro, mientras que las claves de retiro no podían operar de manera independiente. EIP-7002 permite que las claves de retiro también puedan activar el retiro, lo que trae:
· Mayor control sobre los fondos: los validadores pueden gestionar los fondos directamente sin depender de los operadores de nodos.
· Soporta grupos de staking completamente no confiables, aumentando la seguridad y el grado de descentralización.
EIP-6110: Depósito de validadores en almacenamiento en cadena
Actualmente, después de que los nuevos validadores realizan depósitos en la capa de ejecución, deben esperar a que la capa de consenso los reconozca y procese, lo que provoca retrasos en la activación.
EIP-6110 permite que la capa de ejecución transfiera directamente la información de depósitos a la capa de consenso, reduciendo pasos de verificación adicionales y acortando el tiempo de activación de los validadores de aproximadamente 9 horas a aproximadamente 13 minutos.
Mejorar la capacidad de escalado de Layer 2: aumentar el rendimiento de Blob
EIP-7691: Aumentar el rendimiento de Blob
El año pasado, la actualización Dencun introdujo Blobs como una forma eficiente de almacenar datos en rollups de Layer 2. Actualmente, se envían aproximadamente 21,000 Blobs a Ethereum cada día, pero la capacidad se está acercando a su límite, lo que provoca un aumento en las tarifas y limita el rendimiento.
Actualmente, el número objetivo de Blobs por bloque de Ethereum es de 3, con un máximo de 6. La EIP-7691 propone aumentar su valor objetivo a 6 y el valor máximo a 9, para aumentar la capacidad de almacenamiento de datos y mejorar la capacidad de procesamiento y escalabilidad. Esto reducirá los costos de almacenamiento de datos, lo que a su vez disminuirá las tarifas de transacción de L2.
EIP-7623: Aumentar el costo de calldata
Antes de la introducción del mecanismo Blob, L2 utilizaba principalmente calldata para almacenar datos, y en ciertos casos todavía se utiliza, ya que puede ser más rentable.
EIP-7623 aumenta los costos de calldata para incentivar el uso principal de almacenamiento de blob en L2, mejorando así la eficiencia de las transacciones de rollup.
Mejora de la experiencia del usuario (UX)
EIP-7702: Configuración del código de la cuenta EOA
Idea principal: otorgar temporalmente capacidades de contrato inteligente a EOA
EIP-7702 introduce un nuevo tipo de transacción (identificado como 0x04) que permite a las cuentas de propiedad externa (EOA) obtener temporalmente la funcionalidad de un contrato inteligente durante la ejecución de una transacción. Es decir, aunque tradicionalmente las EOA no tienen código y solo se pueden usar para firmar transacciones, a través de esta propuesta, las EOA pueden "cargar" un fragmento de código en una transacción, permitiendo así realizar operaciones complejas como una billetera de contrato inteligente.
Principales ventajas
· Gas patrocinado: este mecanismo también puede soportar el patrocinio de tarifas de transacción por terceros, mejorando la experiencia del usuario, permitiendo que los usuarios operen sin necesidad de poseer ETH por adelantado.
· Mejora de la seguridad y flexibilidad: los usuarios pueden ejercer un control de permisos de forma granular sobre las transacciones, como permitir que las subcuentas operen solo bajo condiciones específicas, lo que aumenta la seguridad de la cuenta.
Desafíos potenciales
· Problemas de compatibilidad ecológica: dado que EOA tradicionalmente se considera sin código, algunos contratos inteligentes existentes o verificaciones de seguridad (por ejemplo, require(tx.origin == msg.sender)) pueden necesitar ajustes para adaptarse a este mecanismo de otorgar temporalmente código.
· Aumento de la complejidad de la estructura de transacciones: La introducción de nuevos tipos de transacciones requerirá cambios significativos en las billeteras y clientes, asegurando que no haya vulnerabilidades de seguridad o costos adicionales elevados al manejar nuevos conjuntos de autorizaciones y configuraciones de código temporal.
EIP-7702 permite que las cuentas de usuario (EOA) obtengan temporalmente funciones de contratos inteligentes en una sola transacción, lo que apoya transacciones en lote, patrocinio de transacciones y una gestión de permisos más flexible. Este mecanismo puede mejorar enormemente la experiencia del usuario y expandir las funcionalidades de las dApps, pero también romperá algunas suposiciones tradicionales, requiriendo que todas las partes del ecosistema se adapten y actualicen. En general, es una propuesta importante que allana el camino para la abstracción de cuentas, con el objetivo de que las cuentas de Ethereum en el futuro sean tanto seguras como más flexibles.
Otros EIPs
EIP-7685: Solicitud de capa de ejecución general
Antecedentes y objetivos
Actualmente, entre Eth1 (capa de ejecución) y la cadena de balizas (capa de consenso) se deben procesar tres solicitudes principales:
Depósito: El evento de depósito iniciado por el usuario aparece inicialmente en el bloque Eth1, pero finalmente necesita ser procesado en la cadena de balizas.
Retiro: Las solicitudes de retiro enviadas desde la cadena de balizas (generalmente a través de herramientas de línea de comandos) deben procesarse en Eth1.
Fusión de validadores: De igual manera, esta solicitud también necesita ser transmitida entre Eth1 y la cadena de balizas.
¿Por qué se necesita esta propuesta?
Actualmente, diferentes tipos de operaciones se transmiten entre dos capas, lo que puede causar confusión. El marco de procesamiento unificado propuesto por EIP-7685 tiene como objetivo:
· Manejar todas estas solicitudes de una manera estándar para que el proceso sea más claro y eficiente;
· Al depender únicamente de Eth1 para activar estas operaciones, se pueden separar el entorno de ejecución de los validadores y la gestión de la participación, lo que aumenta la seguridad.
Contenido principal
Identificación del tipo de solicitud: se ha definido una identificación específica para cada operación, como los tipos de solicitud de depósito y retiro existentes, y ahora se debe agregar el tipo de solicitud de fusión.
Garantía de integridad: se utilizarán algunos mecanismos (como la verificación hash y la data merkelizada) para asegurar la integridad y seguridad de los datos solicitados.
Manejo de colas y limitación de velocidad: se establecerán algunas restricciones para las solicitudes pendientes (como el número de depósitos, retiros o solicitudes de fusión que esperan al mismo tiempo) para evitar la sobrecarga del sistema.
significado final
Para los usuarios comunes y los desarrolladores, esto significa que en el futuro, ya sea que se trate de iniciar un depósito, un retiro o una operación de fusión de validadores, se podrán completar más rápido y de manera más segura a través de un proceso unificado y estandarizado. Esto no solo mejora la eficiencia del sistema, sino que también ayuda a reducir el riesgo general.
EIP-2537: Compilación de operaciones de la curva BLS12–381
Propósito principal
Esta propuesta incluye funciones integradas en Ethereum (llamadas contratos precompilados) específicamente para manejar cálculos matemáticos en la curva BLS12–381.
¿Por qué se necesita esta precompilación?
· Mejora de la eficiencia: implementar directamente cálculos complejos de curvas elípticas (como la verificación de firmas y la agregación) en contratos inteligentes consume una gran cantidad de gas. Los contratos precompilados pueden reducir significativamente el costo de estos cálculos.
· Mayor seguridad: en comparación con la curva BN254 actualmente utilizada (que ofrece aproximadamente 80 bits de seguridad), la curva BLS12–381 proporciona alrededor de 120 bits de seguridad, lo que hace que las operaciones criptográficas sean más seguras.
Principal uso
· Verificación de firma BLS: La firma BLS permite agrupar múltiples firmas en una sola, lo que reduce significativamente la carga computacional durante la verificación.
· Verificación de pruebas zkSNARK: En algunos esquemas de protección de la privacidad y escalabilidad, es necesario verificar las pruebas zkSNARK, y estas operaciones también dependen de cálculos complejos de curvas elípticas.
significado real
A través de este EIP, los desarrolladores pueden utilizar operaciones criptográficas relacionadas con la curva BLS12–381 de manera más eficiente y a menor costo en contratos inteligentes, lo que permite apoyar más aplicaciones innovadoras, como mecanismos de consenso más eficientes, interacciones entre cadenas y diversas aplicaciones descentralizadas.
En resumen, EIP-2537 está diseñado para resolver el problema del consumo excesivo de gas durante operaciones de cifrado de alta seguridad en la cadena, haciendo que estos cálculos complejos sean más eficientes y prácticos a través de contratos precompilados.
EIP-2935: Guardar el hash de bloques históricos en el estado
Problema actual
En la máquina virtual de Ethereum (EVM), la operación BLOCKHASH solo puede recuperar el hash de los 256 bloques más recientes (aproximadamente en los últimos 50 minutos), lo cual no es suficiente para ciertas aplicaciones, como las aplicaciones de cadena cruzada que necesitan demostrar datos de bloques más antiguos o clientes sin estado (como rollup).
El núcleo de la propuesta
La propuesta EIP-2935 sugiere guardar 8192 hashes de bloques adicionales en el estado de la blockchain (aproximadamente 27.3 horas), lo que ampliaría significativamente el rango de datos históricos de bloques disponibles para consultas.
¿Cómo realizar?
Además de mantener que el código de operación BLOCKHASH solo puede acceder a los últimos 256 bloques, la propuesta también introducirá un nuevo contrato de sistema especializado:
· set() método: cada vez que se procesa un bloque, el nuevo contrato automáticamente almacenará el hash del bloque actual en un búfer circular.
· get() método: Cualquiera puede consultar el hash de bloques históricos almacenados en el búfer circular a través de este método, ya sea una persona o un contrato inteligente.
Beneficios reales
De esta manera, las aplicaciones de cadena cruzada, rollups u otros sistemas que necesitan acceder a datos de bloques anteriores podrán obtener directamente la información histórica necesaria en la cadena, sin depender adicionalmente de datos externos, lo que hace que su diseño sea más simple, seguro y confiable.
EIP-7840: Añadir programación de blobs al archivo de configuración de EL
Objetivo principal
Esta propuesta tiene como objetivo escribir en el archivo de configuración de la capa de ejecución (EL) los parámetros clave relacionados con la programación de blobs (como el número de blobs permitidos por bloque y la proporción de actualización de la tarifa base).
Método específico
· Agregar la configuración de "número de blobs objetivo" y "número máximo de blobs" en el archivo de configuración.
· Al mismo tiempo, se añade un parámetro llamado baseFeeUpdateFraction, que se utiliza para ajustar la velocidad de actualización de la tarifa base.
· El cliente puede consultar estos parámetros a través de la API del nodo, para conocer la configuración específica del blob en la red actual.
¿Por qué es útil?
Esta información puede ayudar a los desarrolladores y operadores de nodos a estimar de manera más precisa los costos de gas de blob, y también ayuda a la red a gestionar mejor la programación y el procesamiento de grandes cantidades de datos en los bloques.
En general, EIP-7840 añade un conjunto de parámetros de programación de blob configurables a la capa de ejecución de Ethereum, lo que hace que la red sea más eficiente y transparente al procesar grandes datos (blob).
EIP-7549: Mover el índice del comité fuera de la prueba
Idea central
Actualmente, el mensaje de verificación de votos (Attestation) contiene tres partes:
· Votación LMD GHOST (incluye raíz de bloque y ranura de tiempo)
· Votación de Casper-FFG (incluye source y target)
· Índice de la Comisión (index)
El problema es que el índice del comité también está firmado, lo que significa que incluso si el contenido de la votación es el mismo, las raíces de firma generadas serán diferentes debido a los índices distintos. Esto hará que las votaciones con el mismo contenido no puedan ser agregadas.
La solución propuesta por EIP-7549 es: eliminar el índice del comité del mensaje de votación firmado. De esta manera, solo el contenido central de la votación (votación LMD GHOST y Casper-FFG) participará en el cálculo de la firma, lo que permitirá que varios validadores de la misma votación generen la misma raíz de firma, lo que permite que se agreguen.
Principales beneficios
· Reducción drástica de la carga de trabajo de verificación: En la situación actual, para alcanzar un consenso de 2/3, puede ser necesario verificar 1366 votos. Después de eliminar el índice del comité, solo es necesario verificar aproximadamente 22 votos (ahorrando alrededor de 62 veces la carga computacional), lo que mejora significativamente la eficiencia del proceso de verificación que requiere una gran cantidad de cálculos de emparejamiento, especialmente para el cliente Casper FFG basado en pruebas de conocimiento cero.
· Aumentar la eficiencia del almacenamiento de datos en la cadena: dado que la información de votación se puede agregar de manera más eficiente, se pueden empaquetar más votaciones en cada bloque. Ahora, un bloque solo puede contener votaciones de 2 intervalos de tiempo, mientras que con la mejora se podrán incluir hasta 8 intervalos de tiempo, incluso si solo 1/8 de los proponentes están en línea, se podrán incluir todas las votaciones en el bloque.
Al eliminar el índice del comité del mensaje de atestación, no solo se puede reducir drásticamente la cantidad de operaciones de emparejamiento que se deben procesar al validar los votos, sino que también se puede empaquetar de manera más eficiente los datos de votación, mejorando así el rendimiento de todo el proceso de validación del consenso y la utilización del almacenamiento en cadena. Esta mejora es particularmente importante para el mecanismo de consenso Casper FFG y su validación de pruebas de conocimiento cero relacionadas.
Conclusión
Pectra, como una actualización que abarca un número récord de EIP, impulsará el desarrollo de Ethereum en direcciones clave como la abstracción de cuentas, la optimización del mecanismo de validadores, la mejora de la eficiencia de la red y la expansión de Layer 2. Al mismo tiempo, como Vitalik Buterin destacó recientemente, aunque Ethereum adopta una ruta de expansión centrada en Rollup, sigue optimizando Layer 1, como el reciente aumento del límite de Gas a 36 millones, y en el futuro podría mejorar aún más la resistencia a la censura, el rendimiento y la escalabilidad.
Referencia de enlace: