Reenviar el Título Original: The Prague/Electra (Pectra) Hardfork Explained

introducir

En nuestro artículo anterior, revisamos extensamente el ciclo de vida de los validadores de Ethereum, discutiendo varios aspectos relacionados con la próxima actualización de Electra. Ahora, es el momento de centrarse en los próximos cambios en las actualizaciones de Electra y Praga y explicarlos en detalle.

La historia de Ethereum 2.0 "proof-of-stake" hardforks es compleja. Comenzó con la adición de la capa beacon a la capa de ejecución existente, lanzando el consenso proof-of-stake en la capa beacon mientras se mantenía el proof-of-work en la capa de ejecución (los hardforks Phase0 y Altair). PoS se activó completamente en el hardfork Bellatrix (aunque los retiros no estaban habilitados). Posteriormente, el hardfork Capella permitió los retiros, completando el ciclo de vida del validador. El hardfork más reciente, Deneb (parte de la actualización Dencun(Deneb/Cancún)), trajo revisiones menores a los parámetros de la cadena beacon, como la ventana de tiempo para incluir testimonios, el manejo de salidas voluntarias y el límite de rotación del validador. Los cambios principales en Dencun estuvieron en la capa de ejecución, introduciendo innovaciones como transacciones de blob, gas de blob, compromisos KZG para blobs y la deprecación de la operación SELFDESTRUCT.

Ahora, el hardfork de Prague/Electra introduce mejoras significativas tanto en la capa de ejecución como en la capa de consenso. Como auditores del proyecto Lido, nuestro enfoque se centra principalmente en los cambios relacionados con el consenso y el staking en este hardfork. Sin embargo, no podemos ignorar los cambios en la capa de ejecución en Prague, ya que incluyen características críticas que afectan a la red y a los validadores de Ethereum. Vamos a profundizar en los detalles de estos cambios.

Descripción general de alto nivel de Pectra

Electra introduce numerosas características para la capa del beacon. Las actualizaciones principales incluyen:

• Permitir a los validadores tener un saldo efectivo que oscile entre 32 y 2048 ETH (en lugar de 32 ETH fijos).
• Habilitar a los validadores para iniciar salidas con credenciales secundarias de "retiro" (sin necesidad de la clave activa del validador).
• Cambiando la forma en que se procesan los depósitos de Eth1 por la capa de beacon (alejándose de analizar eventos del contrato de depósito).
• Agregando un nuevo marco de propósito general para manejar solicitudes de contratos Eth1 regulares en la capa de beacon (similar a cómo se gestionaban los depósitos antes de Electra).

Mientras tanto, Praga introduce cambios en la capa de ejecución, como:

• Un nuevo contrato precompilado que admite la curva BLS12-381 para verificar pruebas zkSNARK (además de la popular curva BN254).
• Un nuevo contrato de sistema para almacenar y acceder hasta 8192 hashes de bloques históricos (útil para clientes sin estado).
• Aumento de los costos de gas de calldata para reducir el tamaño del bloque y alentar a los proyectos a trasladar operaciones intensivas en calldata (como rollups) a blobs, que se introdujeron en Dencun.
• Soporte para un mayor número de bloques por bloque Eth1, junto con una API para leer estos números.
• Permitir que las Cuentas de Propiedad Externa (EOAs) tengan su propio código de cuenta, expandiendo drásticamente lo que las EOAs pueden hacer, como ejecutar multicalls o delegar la ejecución a otras direcciones.

Vamos a hacer referencia a las Propuestas de Mejora de Ethereum (EIP) pertinentes para facilitar una mayor discusión:

• EIP-7251: Aumentar el MAX_EFFECTIVE_BALANCE
• EIP-7002: Salidas activables por la capa de ejecución
• EIP-6110: Suministrar depósitos de validadores en cadena
• EIP-7549: Mover el índice del comité fuera de la Attestation
• EIP-7685: Solicitudes de capa de ejecución de propósito general
• EIP-2537: Precompilado para operaciones de curva BLS12-381
• EIP-2935: Guardar los hashes de bloques históricos en el estado
• EIP-7623: Aumentar el costo de los datos de llamada
• EIP-7691: aumento del rendimiento del blob
• EIP-7840: Agregar programación de blob a archivos de configuración EL
• EIP-7702: Establecer código de cuenta EOA

Algunos de estos EIP abordan principalmente la capa de consenso (beacon), mientras que otros se refieren a la capa de ejecución. Algunos abarcan ambas capas, ya que ciertas operaciones como depósitos y retiros requieren cambios sincronizados en las capas de consenso y ejecución. Debido a esta interdependencia, separar Electra y Praga es impráctico, por lo que revisaremos cada EIP de forma secuencial y especificaremos el componente de Ethereum afectado en cada caso.

EIP-7251: Aumentar el MAX_EFFECTIVE_BALANCE

Referencia: EIP-7251

Desde el primer hardfork Phase0, implementado para preparar Ethereum para Proof-of-Stake, y hasta Electra, el saldo efectivo máximo de un validador se fijó en 32 ETH. La activación de un validador requiere al menos el spec.min_activation_balance (32 ETH). Después de la activación, el validador comienza con este saldo efectivo máximo, pero puede reducir su saldo efectivo al spec.ejection_balance (16 ETH) y es expulsado al alcanzar ese umbral. Esta lógica de "mínimo" permanece sin cambios en Electra, pero ahora el spec.max_effective_balance ha aumentado a 2048 ETH. Como resultado, un validador puede depositar entre 32 y 2048 ETH para la activación, y todas las cantidades en este rango contribuyen a su saldo efectivo. Este cambio marca un cambio de "prueba de participación de 32ETH" a una "prueba de participación" :)

Este saldo efectivo variable se utilizará ahora:

• aumentar la probabilidad de ser un proponente de bloque, proporcional al saldo efectivo
• aumentar la probabilidad de ser miembro del comité de sincronización, en proporción al saldo efectivo
• como base para calcular los montos relativos de penalizaciones por corte e inactividad

Las dos primeras actividades son las acciones más gratificantes para los validadores. En consecuencia, después de Electra, los validadores con apuestas más grandes participarán con más frecuencia en la propuesta de bloques y comités de sincronización, en proporción a su saldo efectivo.

Otro efecto está relacionado con las sanciones por reducción. Todas las penalizaciones por reducción son proporcionales al saldo efectivo del validador:

• Las penalizaciones por reducción 'inmediatas' y 'diferidas' son mayores para los validadores con apuestas más altas.
• Los castigos por reducción diferida para los validadores reducidos junto con los validadores de gran participación también son mayores, ya que la fracción "reducida" del total de participaciones es mayor.
• Un denunciante que informa sobre un validador con un saldo efectivo más alto recibe una fracción mayor de la participación reducida.

Electra también propone cambios en las cuotas de reducción, definiendo una fracción del saldo de los validadores que se reduce y se recibe por el informante.

Los efectos de inactividad son los siguientes. Cuando un validador está fuera de línea mientras está activo (atestiguando o proponiendo), se acumula un puntaje de inactividad, lo que conduce a penalizaciones por inactividad aplicadas en cada época. Estas penalizaciones también son proporcionales al saldo efectivo del validador.

Los límites de rotación del validador también experimentan cambios debido a los saldos efectivos aumentados. En Ethereum "pre-Electra", los validadores generalmente tienen el mismo saldo efectivo, y el límite de rotación de salida se define como "no más de 1/65536 (spec.churn_limit_quotient) del total de participación puede salir en un solo período". Esto crea un número "fijo" de salidas de validadores con el mismo saldo. Sin embargo, en "post-Electra", es posible un escenario en el que solo algunos "ballenas" salen, ya que representan una parte significativa del total de participación.

Otra consideración es la rotación de muchas claves validadoras en una única instancia de validador. Actualmente, los validadores grandes se ven obligados a ejecutar miles de claves validadoras en una única instancia para acomodar grandes apuestas, dividiéndolas en partes de 32 ETH. Con Electra, este comportamiento ya no es obligatorio. Financieramente, este cambio hace poca diferencia ya que las recompensas y probabilidades escalan linealmente con la cantidad apostada. Por lo tanto, 100 validadores con 32 ETH cada uno son equivalentes a un validador con 3200 ETH. Además, múltiples claves validadoras activas pueden tener las mismas credenciales de retiro de Eth1, lo que permite retirar todas las recompensas a una única dirección ETH y evitar los costos de gas asociados con la consolidación de recompensas. Sin embargo, administrar un gran número de claves conlleva costos administrativos adicionales.

La capacidad de consolidar saldos de validadores agrega otro tipo de solicitud de capa de ejecución. Anteriormente, teníamos depósitos y retiros. Ahora, habrá otro tipo: una solicitud de consolidación. Fusionará dos validadores en uno. Esta solicitud de operación incluirá la pubkey del validador de origen y la pubkey de destino, y se procesará de manera similar a los depósitos y retiros. Las consolidaciones también tendrán solicitudes pendientes y límites de rotación de saldo, al igual que los depósitos y retiros.

Para resumir:

• Para los validadores solitarios pequeños, Electra introduce la capacidad de aumentar automáticamente su saldo efectivo (y recompensas). Anteriormente, cualquier excedente por encima de 32 ETH solo se podía retirar, pero después de Electra, este excedente eventualmente contribuirá a su saldo efectivo. Sin embargo, el saldo efectivo solo puede aumentar en múltiplos de spec.effective_balance_increment (1 ETH), lo que significa que el aumento ocurre solo después de alcanzar el próximo "1 ETH bound".
• Para los validadores solitarios de gran tamaño, Electra ofrece una simplificación significativa en la gestión al permitir la consolidación de múltiples claves de validador activas en una sola. Si bien no cambia las reglas del juego, operar una sola participación de 1x2048 es innegablemente más simple que gestionar 64 participaciones de 32x.
• Para los proveedores de participación líquida, que recopilan pequeñas participaciones de los usuarios y las distribuyen entre los validadores, Electra añade más flexibilidad en los esquemas de distribución de participaciones, pero al mismo tiempo, requiere una seria reestructuración de la contabilidad de los validadores, que actualmente se basa en un saldo efectivo fijo de 32 ETH.

Otro tema importante es el historial de datos y la estimación de beneficios para los validadores, lo cual es especialmente relevante para los nuevos participantes que intentan evaluar riesgos y rendimientos. El límite de 32 ETH (tanto mínimo como máximo, en la práctica) antes de Electra (en el momento de la redacción de este artículo) creó uniformidad en los datos históricos. Todos los validadores tenían saldos efectivos iguales, recompensas, penalizaciones individuales por reducción y frecuencias de propuesta de bloques, entre otras métricas. Esta uniformidad permitió a Ethereum probar su mecanismo de consenso con un gran número de validadores sin valores atípicos estadísticos, recopilando datos valiosos sobre el comportamiento de la red.

Después de Electra, la distribución de las participaciones cambiará significativamente. Los validadores grandes participarán más a menudo en las propuestas de bloques y en el comité de sincronización, recibirán sanciones más grandes en eventos de reducción y tendrán mayor influencia en las reducciones diferidas, las colas de activación y las colas de salida. Si bien esto podría crear desafíos en la agregación de datos, el consenso de Ethereum garantiza que los cálculos no lineales sean mínimos. El único componente no lineal utiliza sqrt(total_effective_balance) para calcular la recompensa base, que se aplica de manera uniforme a todos los validadores. Esto significa que las recompensas y reducciones de los validadores aún pueden estimarse en una base de "por 1 ETH" (o, más precisamente, por incremento de balance efectivo específico, que podría cambiar potencialmente en el futuro).

Para obtener más detalles, consulte nuestro artículo anterior sobre el comportamiento del validador.

EIP-7002: Salidas desencadenables de la capa de ejecución

Referencia: EIP-7002

Cada validador en Ethereum tiene dos pares de claves: una clave activa y una clave de retiro. La clave pública activa BLS sirve como la identidad principal del validador en la cadena de referencia, y este par de claves se utiliza para firmar bloques, atestaciones, castigos, agregados del comité de sincronización y (hasta esta EIP) salidas voluntarias (para iniciar la salida del validador del consenso después de un retraso). El segundo par de claves ("credenciales de retiro") puede ser otro par de claves BLS o una cuenta regular de Eth1 (clave privada y dirección). Ahora, retirarse a una dirección ETH requiere un mensaje de retiro firmado por la clave privada activa BLS. Esta EIP cambia eso.

En la práctica, los propietarios de estos dos pares de claves (activas y de retiro) pueden ser diferentes. La clave activa del validador es responsable de las tareas de validación: ejecutar servidores, mantenerlos operativos, etc., mientras que las credenciales de retiro suelen estar controladas por el propietario de la participación, quien recibe recompensas y es responsable de los fondos. Actualmente, un propietario de participación que solo controla las credenciales de retiro no puede iniciar la salida del validador y solo puede retirar recompensas. Esta situación permite al propietario de la clave activa del validador mantener efectivamente el saldo del validador como “rehén”. Los validadores pueden “pre-firmar” mensajes de salida y dárselos a los propietarios de participación, pero esta solución no es ideal. Además, tanto los retiros como las salidas actualmente requieren interactuar con el validador de la capa de beacon utilizando APIs especializadas.

La solución óptima es permitir a los propietarios de participaciones realizar tanto operaciones de salida como de retiro mediante una llamada regular de contrato inteligente. Esto implica una verificación estándar de firma Eth1, simplificando en gran medida las operaciones.

Esta EIP permite a los propietarios de participaciones desencadenar retiros y salidas a través de una transacción estándar desde su dirección ETH a un contrato inteligente dedicado (similar al proceso de depósito existente que utiliza el contrato de “Depósito”). El proceso de retiro (o salida si se retira suficiente participación) funciona de la siguiente manera:

• El propietario de la participación envía una solicitud de retiro (solicitud "in") al contrato "Retiros" del sistema.
• El contrato cobra una tarifa específica (en ETH) para mitigar posibles ataques de abuso emocional y opera de manera similar a EIP-1559, con tarifas que aumentan cuando la cola de solicitudes está ocupada.
• El contrato guarda la solicitud de retiro/salida "en" en su almacenamiento.
• Cuando se propone un bloque a la capa de beacon, se recuperan de almacenamiento las solicitudes de retiro/salida en cola 'in'.
• La capa de beacon procesa las solicitudes "in", interactuando con el saldo del validador activo, programando al validador para la salida y formando las solicitudes de retiro "out".
• Las solicitudes de retiro "out" se procesan en la capa de ejecución, y el propietario de la participación recibe su ETH.

Mientras que los depósitos fueron operaciones desencadenadas en bloques Eth1 y luego "movidas" a la capa Beacon utilizando la cola de depósitos "pendientes", las retiradas siguieron un esquema diferente. Fueron desencadenadas en la capa Beacon (a través de la CLI) y luego "movidas" a bloques Eth1. Ahora, ambos esquemas operarán utilizando el mismo marco genérico (descrito a continuación): creación de solicitudes en la capa Eth1, procesamiento de la cola de depósitos/retiradas/consolidaciones "pendientes" y procesamiento en la capa Beacon. Para operaciones de "salida" como retiradas, la cola de salida también se procesa y los resultados se "liquidan" en bloques Eth1.

Con este EIP, los propietarios de participaciones pueden retirar y salir de sus validadores utilizando transacciones regulares de ETH sin necesidad de interactuar directamente con la CLI del validador o acceder a la infraestructura del validador. Esto simplifica en gran medida las operaciones de participación, especialmente para los grandes proveedores de participación. La infraestructura de los validadores ahora puede estar casi completamente aislada, ya que solo es necesario mantener las claves de validador activas, mientras que todas las operaciones de participación pueden manejarse en otro lugar. Elimina la necesidad de que los participantes individuales esperen acciones de validador activas y simplifica significativamente las partes fuera de la cadena para servicios como el Módulo de Participación Comunitaria de Lido.

Como resultado, este EIP "completa" las operaciones de staking migrándolas completamente a la capa Eth1, reduce significativamente los riesgos de seguridad de la infraestructura y mejora la descentralización de las iniciativas de staking en solitario.

EIP-6110: Depósitos de validadores de suministro en cadena

Referencia: EIP-6110

Actualmente, los depósitos se implementan a través de eventos en el contrato del sistema 'Depósito' (como se discutió en detalle en un artículo anterior). El contrato acepta ETH y credenciales de validador, emite un evento 'Depósito()', y estos eventos se analizan y transforman posteriormente en solicitudes de depósito en la capa del beacon. Este sistema tiene numerosas desventajas: requiere votar por eth1data en la capa del beacon chain, lo que añade retrasos significativos. Además, la capa del beacon necesita consultar la capa de ejecución, lo que introduce más complejidad. Estos problemas se discuten en detalle en el EIP. Un método más sencillo, que elimina muchos de estos problemas, consiste en incluir directamente las solicitudes de depósito en los bloques Eth1 en una ubicación designada. Este mecanismo refleja el proceso de manejo de retiros descrito en el EIP anterior.

Las modificaciones propuestas en este EIP son prometedoras. Ahora se puede eliminar por completo el procesamiento de eth1data, eliminando la necesidad de votación o largos retrasos entre eventos en el lado de Eth1 e inclusión de depósitos en la capa de beacon (actualmente alrededor de 12 horas). También elimina la lógica de instantáneas del contrato de depósito. Este EIP simplifica el procesamiento de depósitos y lo alinea con el esquema de procesamiento de retiros descrito anteriormente.

Tanto para los dueños de apuestas como para los validadores, estos cambios reducen significativamente la demora entre un depósito y la activación del validador. Las recargas, que son necesarias cuando se penaliza a un validador, también serán más rápidas.

No hay mucho más que decir sobre este EIP que el hecho de que elimina la lógica obsoleta, simplifica los procesos y crea mejores resultados para todos los involucrados.

EIP-7685: solicitudes de capa de ejecución de propósito general

Referencia: EIP-7685

Este EIP debería haber sido presentado, argumentablemente, antes que los tres EIPs anteriores relacionados con depósitos/retiros/consolidación, ya que sienta las bases para ellos. Sin embargo, se introduce aquí para enfatizar la creciente necesidad de mecanismos genéricos para mover consistentemente datos especializados entre los bloques (capas) de la cadena Eth1 (ejecución) y Beacon (consenso). Este EIP afecta a ambas capas, haciendo más eficiente el procesamiento de solicitudes desencadenadas por transacciones ETH regulares. Actualmente, observamos:

• Eventos de depósito en bloques Eth1 están siendo “movidos” de Eth1 a bloques de Beacon para su procesamiento.
• Las solicitudes de retiro en bloques de Beacon (usando CLI) se están "moviendo" a bloques de Eth1 para su procesamiento.
• La necesidad de manejar consolidaciones de validadores, que también son las solicitudes de Eth1->Beacon.

Estas tres operaciones demuestran la necesidad de un manejo consistente para los diversos tipos de solicitudes a medida que pasan entre las capas de ejecución y de beacon. Además, necesitamos la capacidad de activar estas operaciones solo utilizando la capa Eth1, ya que esto nos permitirá aislar la infraestructura de los validadores de la infraestructura de gestión de participaciones, mejorando la seguridad. Por lo tanto, una solución genérica para gestionar tales solicitudes es tanto práctica como esencial.

Esta EIP establece un marco para al menos tres casos principales: depósitos, retiros y consolidaciones. Es por eso que las EIP anteriores introdujeron campos como WITHDRAWAL_REQUEST_TYPE y DEPOSIT_REQUEST_TYPE, y ahora las consolidaciones agregarán otro, CONSOLIDATION_REQUEST_TYPE. Además, esta EIP probablemente incluirá mecanismos comunes para manejar límites para tales solicitudes (constantes de referencia: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).

Aunque aún no están disponibles los detalles específicos de implementación para este marco, sin duda incorporará tipos de solicitud clave, mecanismos de integridad (por ejemplo, hash y Merkle-ización de solicitudes) y procesamiento de cola pendiente con limitación de velocidad.

Esta EIP tiene una importancia arquitectónica, permitiendo que Eth1 desencadene acciones críticas en la capa de Beacon a través de un marco unificado. Para usuarios finales y proyectos, esto significa que todas las solicitudes desencadenadas en la capa Eth1 se entregarán y procesarán en la capa de Beacon de manera mucho más eficiente.

EIP-2537: Precompilado para operaciones de curva BLS12-381

Referencia: EIP-2537

Si no quieres profundizar demasiado, puedes pensar en el precompilado BLS12-381 como una operación criptográfica compleja que ahora se puede utilizar en contratos inteligentes. Para aquellos interesados, exploremos esto más a fondo.

Las operaciones matemáticas en curvas elípticas como BLS12-381 (y su contraparte: BN-254) se utilizan actualmente para dos propósitos principales:

• Firmas BLS, donde se utiliza una operación especial llamada "emparejamiento" para verificar estas firmas. Las firmas BLS son ampliamente utilizadas por los validadores porque permiten la agregación de múltiples firmas en una sola. Los validadores confían en las firmas BLS basadas en la curva BLS12-381 (aunque también se pueden implementar utilizando cualquier curva que admita emparejamientos, como BN254).
• Verificación de pruebas zkSNARK, donde se utilizan apareamientos para validar pruebas. Además, los compromisos KZG a los blobs (introducidos por el hard fork Dencun) también utilizan apareamientos para verificar los compromisos de los blobs.

Si desea verificar una firma BLS o una prueba zkSNARK dentro de un contrato inteligente, debe calcular estas "apareamientos" que son computacionalmente costosos. Ethereum ya tiene un contrato precompilado para operaciones de curva BN254 (EIP-196 y EIP-197). Sin embargo, la curva BLS12-381 (que ahora se reconoce como más segura y se usa mucho más ampliamente hoy en día) no se ha implementado como una precompilación. Sin tal precompilación, implementar apareamientos y otras operaciones de curva en contratos inteligentes requiere cálculos intensivos, como se muestra aquí, y consume enormes cantidades de gas (~10^5 a 10^6 gas).

Esta EIP abre la puerta a muchas aplicaciones potenciales, particularmente al permitir la verificación económica de firmas BLS basadas en la curva BLS12-381. Esto hace posible implementar esquemas de umbral para varios propósitos. Como se mencionó anteriormente, los validadores de Ethereum ya utilizan firmas basadas en BLS12-381. Con esta EIP, los contratos inteligentes estándar ahora pueden realizar una verificación eficiente de firmas de validadores agregados. Esto puede simplificar las pruebas de consenso y el puenteo de activos entre redes, ya que las firmas BLS se utilizan ampliamente en todas las blockchains. Las firmas BLS de umbral por sí solas permiten la construcción de muchos esquemas de umbral eficientes para votación, generación descentralizada de números aleatorios, multisigs, etc.

La verificación más barata de la prueba zkSNARK, a su vez, desbloqueará numerosas aplicaciones. Muchas soluciones basadas en zkSNARK se ven actualmente obstaculizadas por los altos costos de la verificación de la prueba, lo que hace que ciertos proyectos sean casi impracticables. Este EIP tiene el potencial de cambiar eso.

EIP-2935: Guardar hashes de bloques históricos en el estado

Referencia: EIP-2935

Esta EIP propone almacenar 8192 (~27.3 horas) hashes de bloques históricos dentro del estado de la cadena de bloques, proporcionando un historial extendido para clientes sin estado (como rollups) y contratos inteligentes. Sugiere conservar el comportamiento actual del opcode BLOCKHASH, manteniendo la restricción a 256 bloques, al tiempo que introduce un nuevo contrato del sistema diseñado específicamente para almacenar y recuperar hashes históricos. Este contrato realiza una operación set() cuando la capa de ejecución procesa un bloque. Su método get(), accesible para cualquier persona, recupera el hash de bloque requerido de un buffer circular.

Actualmente, es posible hacer referencia a hashes de bloques históricos dentro del EVM, pero el acceso está limitado a los 256 bloques más recientes (~50 minutos). Sin embargo, hay casos donde el acceso a datos de bloques más antiguos es esencial, como en aplicaciones entre cadenas (que requieren demostrar datos de bloques anteriores) y clientes sin estado, que periódicamente necesitan acceso a hashes de bloques anteriores.

Este EIP extiende el horizonte temporal disponible para rollups y aplicaciones entre cadenas, lo que les permite acceder a datos históricos directamente en el EVM sin necesidad de recopilarlos externamente. Como resultado, estas soluciones se vuelven más sólidas y sostenibles.

EIP-7623: Aumentar el costo de los datos de llamada

Referencia: EIP-7623

Los costos de los datos de llamada regulan el tamaño disponible de las cargas útiles de transacción, que en algunos casos pueden ser bastante grandes (por ejemplo, al pasar grandes matrices o búferes binarios como parámetros). El uso significativo de los datos de llamada se atribuye principalmente a los rollups, que envían cargas útiles a través de los datos de llamada que contienen el estado actual del rollup.

La capacidad de introducir datos binarios grandes y comprobables en la cadena de bloques es esencial para los rollups. La actualización Dencun (Deneb-Cancun) introdujo una innovación importante para tales casos de uso: transacciones de blob (EIP-4844). Las transacciones de blob tienen sus propias tarifas de gas dedicadas de “blob”, y aunque sus cuerpos se almacenan temporalmente, sus pruebas criptográficas (compromisos KZG), junto con sus hashes, se integran en la capa de consenso. Los blobs proporcionan así una solución superior para los rollups en comparación con el uso de calldata para el almacenamiento de datos.

Fomentar que las rollups trasladen sus datos a blobs se puede lograr mediante un enfoque de “zanahoria y palo”. Las tarifas de gas reducidas para blobs actúan como la “zanahoria”, mientras que este EIP funciona como el “palo” al aumentar los costos de calldata, desalentando así el almacenamiento excesivo de datos en transacciones. Este EIP complementa el próximo EIP-7691 (Aumento de la capacidad de blobs), que aumenta el número máximo de blobs permitidos por bloque.

EIP-7691: Aumento de rendimiento de blobs

Referencia: EIP-7691

Los Blobs fueron introducidos en la anterior bifurcación Dencun, y los valores iniciales para el número máximo y objetivo de blobs "por bloque" eran estimaciones conservadoras. Esto se debía a la complejidad de predecir cómo la red p2p manejaría la propagación de objetos binarios grandes entre los nodos validadores. La configuración inicial ha demostrado funcionar bien, por lo que este es un momento adecuado para probar nuevos valores. Anteriormente, los números objetivo/máximo de blobs por bloque se establecieron en 3/6. Estos límites ahora se están aumentando a 6/9, respectivamente.

Cuando se combina con el EIP-7623 anterior (Aumento del costo de los datos de llamada), este ajuste motiva aún más a los rollups a trasladar sus datos de datos de llamada a blobs. La búsqueda de parámetros de blob óptimos continúa.

EIP-7840: Agregar programación de blob a archivos de configuración EL

Referencia: EIP-7840

Esta EIP propone agregar el número objetivo y máximo de blobs "por bloque" (discutidos anteriormente) y los valores de baseFeeUpdateFraction a los archivos de configuración de la Capa de Ejecución de Ethereum (EL). También permite a los clientes recuperar estos valores a través de la API del nodo. Esta característica es particularmente útil para tareas como la estimación de las tarifas de gas de los blobs.

EIP-7702: Establecer código de cuenta EOA

Referencia: EIP-7702

Este es un EIP muy significativo que traerá cambios importantes para los usuarios de Ethereum. Como sabemos, una EOA (Cuenta de Propiedad Externa) no puede tener ningún código, pero puede proporcionar una firma de transacción (tx.origin). Por el contrario, un contrato inteligente tiene código de bytes pero no puede presentar "su" firma directa. Cualquier interacción de un usuario que requiera lógica adicional, automática y verificable actualmente solo se puede lograr llamando a un contrato externo para realizar las acciones requeridas. Sin embargo, en tales casos, el contrato externo se convierte en el remitente de msg.sender para los contratos posteriores, lo que hace que la llamada sea "una llamada de un contrato, no del usuario".

Esta EIP introduce un nuevo tipo de transacción SET_CODE_TX_TYPE=0x04 (anteriormente teníamos las transacciones antiguas 0x1, las transacciones más nuevas 0x02 de las actualizaciones de Berlin y EIP-1559, y las transacciones de blobs 0x03 introducidas en Dencun). Este nuevo tipo de transacción permite establecer código para una cuenta EOA. Básicamente, permite que una EOA ejecute código externo 'en el contexto de su propia cuenta EOA'. Desde una perspectiva externa, durante una transacción, la EOA 'toma prestado' código de un contrato externo y lo ejecuta. Técnicamente, esto es posible agregando tuplas de datos de autorización especiales al almacenamiento 'código' de la dirección EOA (antes de esta EIP, este almacenamiento 'código' siempre estaba vacío para las EOAs).

Actualmente, esta EIP propone que el nuevo tipo de transacción 0x04 incluya una matriz:

authorization_list = [[chain_id, address, nonce, y_parity, r, s], …]

donde cada elemento permite a la cuenta usar el código de la dirección especificada (del último elemento de autorización válido). El procesamiento de dicha transacción establece el código del EOA dado en un valor especial 0xef0100 || dirección (23 bytes), donde la dirección apunta a un contrato con el código deseado a ejecutar, || denota concatenación, y 0xef0100 representa un valor mágico especial que los contratos inteligentes regulares no pueden contener (según el EIP-3541). Este valor mágico asegura que este EOA no puede ser tratado como un contrato regular o recibir llamadas realizadas como tal.

Cuando esta EOA inicia una transacción, la dirección especificada se utilizará para llamar al código correspondiente dentro del contexto de esa EOA. Aunque aún no se conocen todos los detalles de implementación de este EIP, es seguro que traerá cambios significativos.

Uno de los principales impactos es la habilitación de la capacidad de realizar llamadas múltiples directamente desde un EOA. Las llamadas múltiples son una tendencia continua en DeFi, con muchos protocolos que ofrecen esta función como una herramienta poderosa (los ejemplos incluyen Uniswap V4, Balancer V3 o Euler V2). Con este EIP, ahora se pueden realizar llamadas múltiples directamente desde EOA.

Por ejemplo, esta nueva función resuelve un problema común en DeFi: la ineficiencia de approve() + anything() que requiere dos transacciones separadas. Esta EIP permite una lógica de "pre-aprobación" genérica, lo que permite completar acciones como approve(X) + deposit(X) en una sola transacción.

Otra ventaja introducida por la capacidad de delegar la ejecución de transacciones "en nombre de" un EOA es el concepto de patrocinio. Los patrocinios se discuten con frecuencia y son características muy deseadas para incorporar nuevos usuarios a Ethereum.

La lógica programable asociada a un EOA desbloquea numerosas posibilidades, como la implementación de restricciones de seguridad, el establecimiento de límites de gasto, el cumplimiento de los requisitos de KYC y mucho más.

Naturalmente, este cambio también plantea muchas preguntas de diseño. Un problema es el uso de chain_id, que determina si la misma firma puede o no ser válida en múltiples redes según su inclusión o exclusión en la firma. Otro asunto complejo es si se debe utilizar la dirección del código objetivo o incrustar el bytecode real. Ambos enfoques tienen características y limitaciones únicas. Además, el uso de nonce juega un papel clave en la definición de si los permisos son "multiuso" o "de un solo uso". Estos elementos influyen en características y preocupaciones de seguridad, incluidos aspectos como la invalidez masiva de firmas y la facilidad de uso. Vitalik ha planteado estas preguntas en una discusión (aquí), que vale la pena explorar más a fondo.

Es crucial tener en cuenta que este cambio afectará a uno de los mecanismos de seguridad de Ethereum, tx.origin. Se requieren más detalles sobre la implementación de este EIP, pero parece que el comportamiento de require(tx.origin == msg.sender) cambiará. Esta comprobación ha sido la forma más fiable de garantizar que msg.sender es un EOA y NO un contrato. Otros métodos, como la comprobación de EXTCODESIZE (para comprobar si ES un contrato), a menudo fallan y se pueden omitir (por ejemplo, llamando desde un constructor o implementando código en una dirección predefinida después de una transacción). Estas comprobaciones se han utilizado para evitar ataques de reentrada y flashloan, pero están lejos de ser ideales, ya que también dificultan las integraciones con protocolos externos. Después de este EIP, incluso la comprobación confiable require(tx.origin == msg.sender) parece quedar obsoleta. Los protocolos deben adaptarse eliminando dichas comprobaciones, ya que la distinción entre "EOA" y "contrato" ya no se aplicará: ahora cada dirección puede tener un código asociado.

La separación tradicional entre EOA y contratos inteligentes continúa difuminándose. Este EIP acerca a Ethereum a diseños como TON, donde cada cuenta es esencialmente código ejecutable. Esta evolución es natural a medida que las interacciones con los protocolos se vuelven cada vez más complejas, haciéndose necesario utilizar lógica programable para mejorar la experiencia de usuario final.

Conclusión

La actualización de Prague/Electra (Pectra) está programada para marzo de 2025. Sus cambios planificados más significativos incluyen:

• apuestas efectivas variables de validadores, de hasta 2048 ETH, lo que alterará significativamente la distribución de las apuestas, los horarios de los validadores y simplificará la gestión para los proveedores de apuestas grandes al consolidar apuestas más pequeñas
• interacción mejorada entre la capa de ejecución y consenso, optimizando el intercambio de datos entre los bloques de ejecución Eth1 y los bloques de la cadena Beacon. Esto simplificará en gran medida los depósitos, activaciones, retiros y salidas, acelerando estos procesos y sentando las bases para futuras interacciones entre las capas de consenso y ejecución
• soporte para verificaciones más baratas de firmas BLS y zkSNARK directamente en contratos inteligentes a través del nuevo precompilado "amigable para el emparejamiento" BLS12-381
• continuando alentar a rollups a adoptar transacciones de blob en lugar de calldata aumentando los umbrales de transacciones de blob y aumentando los costos de calldata
• habilitar a las EOAs para actuar como cuentas programables, otorgándoles características como multicalls, patrocinios y otras funcionalidades avanzadas

Como puedes ver, Pectra tendrá un impacto significativo tanto en las capas de participación como de consenso, así como en la experiencia del usuario final en la capa de ejecución. Si bien no podemos analizar todos estos cambios en detalle a través del código en esta etapa, dado que el desarrollo está en curso, cubriremos estas actualizaciones en futuros artículos.

Renuncia:

1. Este artículo se reproduce de [TechFlow]. Forward the Original Title: The Prague/Electra (Pectra) Hardfork Explained. The copyright belongs to the original author [MixBytes]. Si tiene alguna objeción a la reimpresión, por favor contacte Equipo de Aprendizaje de Gate, y el equipo lo manejará tan pronto como sea posible de acuerdo con los procedimientos relevantes.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo representan únicamente las opiniones personales del autor y no constituyen ningún consejo de inversión.
3. Las versiones en otros idiomas del artículo son traducidas por el equipo de gate Learn. A menos que se indique lo contrario, el artículo traducido no puede ser copiado, distribuido o plagiado.