En nuestro artículo anterior, revisamos en detalle el ciclo de vida de los validadores de Ethereum y discutimos varios aspectos relacionados con el próximo hard fork de Electra. Ahora es el momento de centrarnos en los cambios que se avecinan en las actualizaciones de Electra y Prague, y explicarlos en detalle.
La historia de la bifurcación dura de Ethereum 2.0 'Proof of Stake' es complicada. Comenzó agregando una capa de señales a la capa de ejecución existente, manteniendo al mismo tiempo la prueba de trabajo en la capa de ejecución (fases 0 y Altair). Luego, en la bifurcación dura de Bellatrix, se activó por completo el PoS (aunque el retiro no estaba habilitado). Luego, en la bifurcación dura de Capella, se permitieron los retiros, completando el ciclo de vida de los validadores. La bifurcación dura más reciente, Deneb (parte de la actualización Deneb/Cancún), realizó pequeñas revisiones a los parámetros de la cadena de señales, como la ventana de tiempo de prueba, el manejo de salidas voluntarias y las restricciones de cambio de validadores. Los cambios principales en Deneb/Cancún ocurrieron en la capa de ejecución, introduciendo transacciones de blob, gas de blob, compromisos KZG para blobs y desechando la operación SELFDESTRUCT.
Ahora, la bifurcación dura de Prague/Electra (también conocida como Pectra) ha introducido importantes actualizaciones en las capas de ejecución y consenso. Como auditores del proyecto Lido, nos centramos principalmente en los cambios relacionados con el consenso y la participación en esta bifurcación dura. Sin embargo, no podemos pasar por alto los cambios en la capa de ejecución de Prague, ya que incluyen características importantes que afectan a la red de Ethereum y a los validadores. Profundicemos en los detalles de estos cambios.
Visión general de nivel superior de Pectra
Electra ha introducido muchas funciones en la capa de balizas. Las actualizaciones principales incluyen:
Permite que el saldo válido del validador varíe entre 32 y 2048 ETH (en lugar de los fijos 32 ETH).
Permite a los validadores iniciar una salida mediante un comprobante de retiro de segundo nivel (ya no es necesario la clave de validador activo).
Cambiar la forma en que se manejan los depósitos Eth1 en la capa de anclaje (ya no se analizan los eventos del contrato de depósito).
Agregar un nuevo marco general para manejar las solicitudes de contratos Eth1 regulares en la capa de beacon (similar a la forma en que Electra maneja los depósitos previos).
Al mismo tiempo, Praga ha introducido los siguientes cambios en la capa de ejecución:
Un nuevo contrato precompilado que admite la curva BLS12-381 para verificar pruebas zkSNARK (además de la popular curva BN254).
Un nuevo contrato del sistema, utilizado para almacenar y acceder a un máximo de 8192 hashes de bloques históricos (muy útil para clientes sin estado).
Aumentar el costo de gas de calldata para reducir el tamaño del bloque y fomentar la migración de operaciones intensivas de calldata (como rollup) a los blobs introducidos en Dencun.
Admite más blobs para cada bloque Eth1 y proporciona una API para leer esta cantidad.
Permite a las cuentas de propiedad externa (EOA) tener su propio código de cuenta, lo que amplía enormemente las operaciones que las EOA pueden realizar, como realizar múltiples llamadas o delegar la ejecución a otras direcciones.
Consultemos la Propuesta de Mejora de Ethereum relevante (EIP) para una discusión más profunda:
EIP-7251: Añadir MAX_EFFECTIVE_BALANCE
EIP-7002: La capa de ejecución puede activar una salida
EIP-6110: Depósito del validador ofrecido en la cadena
EIP-7549: Remover el índice del comité de la prueba
EIP-7685: Solicitud de capa de ejecución general
EIP-2537: Precompilación de operaciones en la curva BLS12-381
EIP-2935: Guardar el hash del bloque histórico en el estado
EIP-7623: Aumentar el costo de calldata
EIP-7691: aumento de la capacidad de rendimiento de blobs
EIP-7840: Agregar programación de blobs al archivo de configuración de EL
EIP-7702: Configuración del código de la cuenta EOA
Algunos de estos EIP están principalmente relacionados con la capa de consenso (beacon), mientras que otros están relacionados con la capa de ejecución. Algunos atraviesan ambas capas, ya que ciertas operaciones (como depósitos y retiros) requieren cambios sincronizados entre la capa de consenso y la capa de ejecución. Debido a esta interdependencia, separar Electra y Prague es impracticable, por lo tanto, revisaremos cada EIP secuencialmente y especificaremos los componentes de Ethereum afectados en cada caso.
EIP-7251: Aumentar MAX_EFECTIVE_BALANCE
Referencia: EIP-7251
Desde el primer hard fork de la Fase 0, hasta Electra, en preparación para la prueba de participación de Ethereum, el saldo máximo efectivo de los validadores ha sido fijo en 32 ETH. Activar un validador requiere al menos el spec.min_activation_balance (32 ETH). Después de la activación, el validador comienza con este saldo máximo efectivo, pero puede reducir su saldo efectivo a spec.ejection_balance (16 ETH) y ser expulsado una vez que alcance ese umbral. Esta lógica 'mínima' se mantiene en Electra, pero ahora el spec.max_effective_balance ha aumentado a 2048 ETH. Por lo tanto, los validadores pueden depositar entre 32 y 2048 ETH para activarse, y todas estas cantidades contribuirán a su saldo efectivo. Este cambio marca la transición de '32ETH-Prueba de Participación' a 'Prueba de Participación' :)
Este saldo disponible variable ahora se utilizará para:
Aumentar la probabilidad de convertirse en un proponente de bloques, en proporción directa al saldo efectivo
Aumentar la probabilidad de convertirse en miembro del comité de sincronización, en proporción al saldo efectivo
Como base para calcular las cantidades de reducción relativa y las sanciones por inactividad
Las dos primeras actividades son las más rentables para los validadores. Por lo tanto, después de Electra, los validadores que realizan grandes apuestas participarán más frecuentemente en la propuesta de bloques y en el comité de sincronización, y su frecuencia será proporcional a su saldo efectivo.
Otro impacto está relacionado con las reducciones. Todas las multas de reducción son proporcionales al saldo efectivo del validador:
La reducción de las multas por 'inmediato' y 'retraso' es mayor para los validadores con altas apuestas.
La penalización por reducción 'retrasada' es aún mayor cuando se trata de validadores reducidos con altas cantidades de apuestas, ya que la parte 'reducida' en el total de las apuestas se vuelve mayor.
Los denunciantes que informen sobre validadores con saldos activos más altos recibirán una proporción mayor de la participación reducida.
Electra también propuso cambios en la proporción de reducción, definiendo una parte del saldo del validador reducido y recibido por el denunciante.
A continuación viene el impacto de la invalidez. Cuando un validador está inactivo (ya sea probando o proponiendo) sin conexión, la puntuación de invalidez se acumulará, lo que resultará en una penalización de invalidez en cada período. Estas penalizaciones también están relacionadas con el saldo efectivo del validador.
Debido al aumento del saldo efectivo, también ha habido un cambio en la 'restricción de cambio' del validador. En el Ethereum 'antes de Electra', los validadores suelen tener saldos efectivos similares, y la restricción de cambio de salida se define como 'en un período, como máximo, el 1/65536 (especie.churn_limit_quotient) del total de la apuesta puede salir'. Esto creó una cantidad fija de validadores que salen con la misma apuesta. Sin embargo, 'después de Electra', puede ocurrir que solo unos pocos 'cetáceos' salgan, ya que representan una parte importante de la apuesta total.
Otra consideración es la rotación de muchas claves de validador en una única instancia de validador. Los grandes validadores actualmente están obligados a ejecutar miles de claves de validador en una sola instancia para adaptarse a grandes apuestas, dividiéndolas en partes de 32 ETH. Con Electra, este comportamiento ya no es obligatorio. Desde un punto de vista financiero, este cambio tiene poco impacto, ya que las recompensas y probabilidades escalan linealmente con la cantidad apostada. Por lo tanto, 100 validadores de 32 ETH cada uno son equivalentes a un validador de 3200 ETH. Además, múltiples claves de validador activas pueden tener el mismo comprobante de retiro Eth1, lo que permite que todas las recompensas se retiren a una única dirección ETH, evitando así los costos de gas asociados con la consolidación de recompensas. Sin embargo, gestionar una gran cantidad de claves conlleva costos de gestión adicionales.
La capacidad de saldo de los validadores agregados ha aumentado con un nuevo tipo de solicitud de capa de ejecución. Anteriormente, teníamos depósitos y retiros. Ahora, habrá otro tipo: solicitud de agregación. Fusionará dos validadores en uno. La solicitud de operación incluirá las claves públicas del validador de origen y del destino, y se procesará de manera similar a los depósitos y retiros. La agregación también tendrá límites de solicitud pendiente y cambio de saldo, al igual que los depósitos y retiros.
Resumiendo:
Para los validadores independientes de pequeña escala, Electra introduce la capacidad de aumentar automáticamente su saldo efectivo (y recompensas). Anteriormente, cualquier excedente de 32 ETH solo se podía retirar, pero después de Electra, este excedente finalmente 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 solo ocurre una vez que se alcanza el próximo 'límite de 1 ETH'.
Para validadores independientes a gran escala, Electra proporciona una simplificación significativa en la gestión al permitir la integración de múltiples claves de validadores activos en una sola. Si bien esto no cambiará las reglas del juego, operar un 1x2048 stake sin duda es mucho más simple que gestionar un 64x32 stake.
Para los proveedores de liquidez de staking, recogen pequeñas apuestas de los usuarios y las distribuyen entre los validadores. Electra ha añadido más flexibilidad en el esquema de distribución de staking, pero también requiere una reconstrucción significativa en la contabilidad de los validadores con un saldo efectivo fijo de 32 ETH.
Otro tema importante es el historial de datos y la estimación de ganancias de los validadores, especialmente relevante para los nuevos participantes que intentan evaluar los riesgos y recompensas. Antes de Electra (hasta la fecha de redacción de este artículo), el límite de 32 ETH (ya sea mínimo o máximo, de hecho) creó uniformidad en los datos históricos. El saldo efectivo, las recompensas, las penalizaciones individuales de reducción, la frecuencia de propuesta de bloques y otros indicadores son iguales para todos los validadores. Esta uniformidad permite a Ethereum probar su mecanismo de consenso sin valores atípicos estadísticos y recopilar datos de comportamiento de red valiosos.
Después de Electra, habrá cambios significativos en la distribución del staking. Los validadores grandes participarán con más frecuencia en los comités de propuesta y sincronización de bloques, se enfrentarán a mayores penalizaciones en los eventos de recorte y tendrán un mayor impacto en el recorte retrasado, las colas de activación y las colas de salida. Si bien esto puede crear desafíos en la agregación de datos, el consenso de Ethereum garantiza que la computación no lineal sea mínima. El único componente no lineal utiliza sqrt(total_effective_balance) para calcular la recompensa base, que se aplica a todos los validadores. Esto significa que las recompensas y barras de los validadores aún se pueden estimar "por 1 ETH" (o más precisamente, en función de spec.effective_balance_increment, que puede cambiar en el futuro).
Para obtener más información detallada, consulte nuestro artículo anterior sobre el comportamiento del validador.
EIP-7002: Salida activable 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 BLS activa sirve como la identidad principal del validador en la cadena de señales, se utiliza para firmar bloques, pruebas, reducciones, agregaciones de comités sincronizados y (antes de esta EIP) salidas voluntarias (para iniciar la salida por consenso del validador después de un retraso). El segundo par de claves ("comprobante de retiro") puede ser otro par de claves BLS o una cuenta Eth1 convencional (clave privada y dirección). Ahora, la extracción a una dirección ETH requiere un mensaje de retiro firmado por la clave privada BLS activa. Este EIP realiza cambios.
De hecho, los propietarios de estas dos claves (activa y de retiro) pueden ser diferentes. La clave activa del validador es responsable de las funciones de validación: ejecutar el servidor, mantener su funcionamiento normal, etc., mientras que el retiro generalmente está controlado por el propietario del depósito, quien recibe recompensas y es responsable de los fondos. Actualmente, solo el propietario del depósito que controla el retiro no puede iniciar la salida del validador, solo puede reclamar recompensas. Esta situación permite que el propietario de la clave activa del validador efectivamente mantenga el saldo del validador como un "rehén". El validador puede "pre-firmar" el mensaje de salida y entregárselo al propietario del depósito, pero este método alternativo no es ideal. Además, actualmente la extracción y la salida requieren interactuar con el validador de la capa de señales a través de una API especial.
La mejor solución es permitir que los propietarios de la participación realicen depósitos y retiros simultáneos a través de contratos inteligentes convencionales. Esto implica comprobaciones de firmas Eth1 estándar, lo que simplifica en gran medida las operaciones.
Este EIP permite a los propietarios de tokens apostados activar retiros y salidas enviando transacciones estándar desde sus direcciones ETH a contratos inteligentes dedicados (similar al proceso de depósito utilizando contratos de "depósito" existentes). El proceso de retiro (o salida al retirar suficiente garantía) es el siguiente:
Los validadores envían una solicitud de retiro (solicitud "in") al contrato de retiro del sistema.
Los contratos cobran una tarifa específica (en ETH) para mitigar posibles ataques maliciosos y, al igual que EIP-1559, la tarifa aumenta cuando la cola de solicitudes está ocupada.
El contrato guardará las solicitudes de retiro / salida de "in" en su almacenamiento.
Cuando se propone un bloque en la capa de señales, las solicitudes de retiro / salida en la cola 'in' se recuperarán del almacenamiento.
La capa de beacon procesa las solicitudes de "in", interactúa con el saldo de los validadores activos, coordina la salida de los validadores y genera solicitudes de retiro "out".
La solicitud de retiro 'out' se procesa en la capa de ejecución y el depositante recibe su ETH.
Aunque los depósitos son una operación desencadenada en el bloque Eth1 y luego 'movida' a la capa de señales a través de la cola de depósitos 'pendientes', los retiros siguen un esquema diferente. Se desencadenan en la capa de señales (a través de la CLI) y luego se 'mueven' al bloque Eth1. Ahora, ambos esquemas funcionarán a través de un marco común (como se describe a continuación): crear solicitudes en la capa Eth1, procesar las colas de depósitos/retiros/fusiones 'pendientes' y procesar en la capa de señales. Para operaciones de 'salida' como los retiros, también se procesará la cola de salidas y los resultados se liquidarán en el bloque Eth1.
A través de este EIP, los validadores pueden depositar y retirar sus validadores utilizando transacciones ETH convencionales sin interactuar directamente con la CLI del validador o acceder a la infraestructura del validador. Esto simplifica en gran medida las operaciones de depósito, especialmente para grandes proveedores de depósito. La infraestructura del validador ahora puede estar casi completamente aislada, ya que solo se requiere mantener las claves de los validadores activos y todas las operaciones de depósito se pueden manejar en otro lugar. Elimina la necesidad de que los validadores independientes esperen la acción de los validadores activos y simplifica significativamente la parte fuera de la cadena de servicios como el módulo de apuesta comunitaria de Lido.
Por lo tanto, este EIP 'completa' la operación de staking, trasladándola completamente a la capa Eth1, lo que reduce significativamente el riesgo de seguridad de la infraestructura y fortalece la descentralización de la iniciativa de staking independiente.
EIP-6110: Depositar verificadores en cadena
Referencia: EIP-6110
Actualmente, los depósitos se realizan a través del evento 'Depósito' en el contrato 'Depósito' del sistema (como se discutió detalladamente en un artículo anterior). El contrato acepta ETH y credenciales de validador, emitiendo el evento 'Depósito()', que luego se analiza y se convierte en una solicitud de depósito en la capa de anclaje. Este sistema tiene muchas desventajas: requiere votar por eth1data en la capa de anclaje, lo que agrega un retraso significativo. Además, la capa de anclaje necesita consultar la capa de ejecución, lo que aumenta aún más la complejidad. Estos problemas se discuten en detalle en la EIP. Una forma más simple de abordar muchos de estos problemas es incluir las solicitudes de depósito directamente en los bloques de Eth1 en la ubicación especificada. Este mecanismo es similar al proceso de retiro descrito en una EIP anterior.
Los cambios propuestos en este EIP parecen prometedores. Ahora es posible eliminar por completo el manejo de eth1data, ya no es necesario votar o sufrir largos retrasos (actualmente alrededor de 12 horas) entre los eventos del lado Eth1 y los depósitos incluidos en la capa de anclaje. También se elimina la lógica de instantáneas del contrato de depósito. Este EIP simplifica el manejo de los depósitos y lo alinea con el esquema de retiros mencionado anteriormente.
Para los depositantes y validadores, estos cambios reducen significativamente la demora entre el depósito y la activación del validador. Cuando se reduce un validador, los complementos necesarios también se realizan más rápidamente.
No hay mucho más que decir sobre este EIP, excepto que elimina la lógica obsoleta, simplifica el proceso y crea mejores resultados para todas las partes involucradas.
EIP-7685: Solicitud de capa de ejecución general
Referencia: EIP-7685
Este EIP debería haber sido propuesto antes de los tres EIP relacionados con depósitos/retiros/fusiones, ya que sienta las bases para estos EIP. Sin embargo, se presenta aquí para resaltar la creciente necesidad de mover datos especializados de manera coherente entre Eth1 (ejecución) y bloques de la cadena de consenso de beacon. Este EIP afecta a dos capas, lo que permite un procesamiento más eficiente de las solicitudes desencadenadas por transacciones ETH regulares. En este momento, observamos:
El evento de depósito en el bloque Eth1 se "mueve" para su procesamiento en el bloque de señal.
La solicitud de retiro en el bloque de referencia (usando CLI) se 'moverá' al bloque Eth1 para su procesamiento.
beacon.
Estas tres operaciones demuestran la necesidad de un manejo consistente de varios tipos de solicitudes al realizar la transición entre la capa de ejecución y la capa de señal. Además, necesitamos la capacidad de activar estas operaciones solo en la capa Eth1, ya que esto nos permitirá aislar la infraestructura del validador de la infraestructura de gestión de staking, mejorando así la seguridad. Por lo tanto, es tanto práctico como necesario contar con una solución general para gestionar este tipo de solicitudes.
Este EIP establece un marco para al menos tres casos principales: depósito, retiro y consolidación. Es por eso que los primeros EIP introdujeron campos como WITHDRAWAL_REQUEST_TYPE y DEPOSIT_REQUEST_TYPE, y ahora la consolidación agregará otro campo, CONSOLIDATION_REQUEST_TYPE. Además, este EIP también puede incluir un mecanismo general para manejar las limitaciones de este tipo de solicitudes (consulte las constantes: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).
Aunque los detalles de implementación de este marco aún no están disponibles, seguramente incluirá tipos de solicitudes clave, mecanismos de integridad (por ejemplo, solicitudes hash y merkleizadas), así como el procesamiento de la cola pendiente y limitaciones de velocidad.
Este EIP tiene un significado arquitectónico que permite a Eth1 activar operaciones clave en la capa de anclaje a través de un marco unificado. Para los usuarios finales y proyectos, esto significa que todas las solicitudes activadas en la capa Eth1 se transmitirán y procesarán de manera más eficiente en la capa de anclaje.
EIP-2537: Precompilación de operaciones en la curva BLS12-381
Referencia: EIP-2537
Si no quieres profundizar, puedes considerar la precompilación de BLS12-381 como una operación de cifrado 'hash' compleja que ahora se puede utilizar en contratos inteligentes. Para aquellos interesados, exploremos más a fondo.
Las operaciones matemáticas realizadas en curvas elípticas como BLS12-381 (y su contraparte BN-254) se utilizan principalmente para dos propósitos en la actualidad:
La firma BLS, donde se utiliza una operación especial llamada 'emparejar' para verificar estas firmas. Las firmas BLS son ampliamente utilizadas por los verificadores ya que permiten agregar múltiples firmas en una sola. Los verificadores dependen de las firmas BLS basadas en la curva BLS12-381 (aunque también pueden utilizar cualquier implementación de curvas que admita emparejamiento, como BN254).
Verificación de pruebas zkSNARK, donde los emparejamientos se utilizan para verificar las pruebas. Además, los compromisos KZG para bloques grandes introducidos por el hard fork de Dencun también se verifican utilizando emparejamientos para verificar los compromisos de los bloques.
Si deseas verificar firmas BLS o pruebas zkSNARK en contratos inteligentes, debes calcular estas "parejas", lo que resulta muy costoso en términos computacionales. Ethereum ya tiene un contrato precompilado (EIP-196 y EIP-197) para operaciones en la curva BN254. Sin embargo, la curva BLS12-381 (ahora considerada más segura y de uso más extendido) aún no se ha implementado como precompilada. Sin un contrato precompilado, la implementación de parejas y otras operaciones en la curva en contratos inteligentes requiere cálculos intensivos, como se muestra aquí, y consume una gran cantidad de gas (alrededor de ~10^5 a 10^6 gas).
Esta EIP abre muchas puertas para posibles aplicaciones, especialmente en la verificación de firmas BLS baratas basadas en la curva BLS12-381. Esto hace posible la implementación de esquemas de umbral para diversos fines. Como se mencionó anteriormente, los validadores de Ethereum ya están utilizando firmas basadas en BLS12-381. A través de esta EIP, los contratos inteligentes estándar ahora pueden verificar de manera eficiente las firmas de los validadores agregados. Esto puede simplificar la prueba de consenso y la interoperabilidad de activos entre redes, ya que las firmas BLS se utilizan ampliamente en blockchain. Las propias firmas BLS umbral permiten la construcción de muchos esquemas de umbral eficientes para votación, generación de números aleatorios descentralizada, firmas múltiples, etc.
La verificación de las pruebas zkSNARK más baratas desbloqueará numerosas aplicaciones. Muchas soluciones basadas en zkSNARK actualmente se ven obstaculizadas por los altos costos de verificación de pruebas, lo que hace que algunos proyectos sean casi inviables. Este EIP tiene el potencial de cambiar esto.
EIP-2935: Guardar el hash del bloque histórico en el estado
Referencia: EIP-2935
Esta propuesta de EIP propone almacenar 8192 (aproximadamente 27.3 horas) hash de bloques históricos en el estado de la cadena de bloques para proporcionar un historial ampliado para clientes sin estado (como rollup) y contratos inteligentes. Propone mantener el comportamiento actual del código de operación BLOCKHASH, manteniendo el límite de 256 bloques, mientras introduce un nuevo contrato del sistema diseñado específicamente para almacenar y recuperar hashes históricos. Este contrato realiza la operación set() al procesar bloques en la capa de ejecución. Su método get() está disponible para cualquiera que desee acceder y recuperar los hash de bloques requeridos del búfer circular.
Currently, it is possible to reference historical block hashes in the EVM, but access is limited to the most recent 256 blocks (about 50 minutes). However, in some cases, accessing older block data is crucial, especially for cross-chain applications (which require proof of previous block data) and stateless clients, which regularly need to access early block hashes.
Esta EIP amplía el alcance temporal disponible para rollup y las aplicaciones entre cadenas, permitiéndoles acceder directamente a los datos históricos en EVM sin necesidad de recopilarlos externamente. Por lo tanto, estas soluciones se vuelven más robustas y sostenibles.
EIP-7623: Aumentar el costo de calldata
Referencia: EIP-7623
calldata ajusta el tamaño disponible de la carga útil de la transacción, lo que puede ser grande en ciertos casos (por ejemplo, al pasar grandes matrices o búferes binarios como parámetros). El uso significativo de calldata se atribuye principalmente a los rollup, que envían la carga útil a través de calldata que incluye el estado actual del rollup.
La introducción de datos binarios grandes y verificables en la cadena de bloques es crucial para el rollup. La actualización de Dencun (Deneb-Cancun) introduce una importante innovación para este tipo de casos de uso: transacciones de blob (EIP-4844). Las transacciones de blob tienen su propio costo de gas especializado llamado "blob", aunque su cuerpo se almacena temporalmente, su prueba de encriptación (compromiso KZG) junto con su hash se integra en la capa de consenso. Por lo tanto, en comparación con el almacenamiento de datos utilizando calldata, el blob proporciona una mejor solución para el rollup.
Se alienta a rollup a transferir sus datos a un blob utilizando el enfoque de 'zanahoria y palo'. El costo reducido de gas del blob actúa como la 'zanahoria', mientras que este EIP aumenta el costo de calldata como el 'palo', lo que ayuda a controlar el exceso de almacenamiento de datos en las transacciones. Este EIP complementa al siguiente EIP-7691 (Aumento de la capacidad de blob), que aumenta la cantidad máxima de blobs permitidos por bloque.
EIP-7691: Aumento de la capacidad de datos de blob
Referencia: EIP-7691
En la bifurcación dura anterior de Dencun, se introdujo el blob y el valor inicial de la cantidad máxima y objetivo del blob por "cada bloque" fue una estimación conservadora. Esto se debe a la complejidad de predecir cómo la red P2P manejará la propagación de objetos binarios grandes entre nodos validadores. La configuración anterior ha demostrado ser efectiva, lo que hace que este sea un momento adecuado para probar nuevos valores. Anteriormente, la cantidad de blobs objetivo/máxima por cada bloque se establecía en 3/6. Estas restricciones ahora se han aumentado a 6/9.
La combinación con el EIP-7623 anterior (aumento del costo de calldata) ha motivado aún más a rollup a trasladar sus datos de calldata a blobs. El trabajo para encontrar los mejores parámetros de blobs sigue en marcha.
EIP-7840: agregar la programación de blob al archivo de configuración EL
Referencia: EIP-7840
Esta propuesta de EIP agrega el objetivo y la cantidad máxima de blobs 'por bloque' (discutidos anteriormente) y el valor de actualización de baseFeeUpdateFraction al archivo 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 función es especialmente útil para tareas como estimar el costo de gas de los blobs.
EIP-7702: Configuración del código de cuenta EOA
Referencia: EIP-7702
Este es un EIP muy importante que traerá cambios significativos para los usuarios de Ethereum. Como sabemos, un EOA (cuenta de propiedad externa) no puede tener ningún código, pero puede proporcionar una firma de transacción (tx.origin). Por otro lado, un contrato inteligente tiene bytes de código, pero no puede presentar activamente su propia firma directa. Cualquier interacción de usuario que requiera lógica adicional, automática y verificable actualmente solo se puede realizar llamando a un contrato externo para ejecutar las operaciones necesarias. Sin embargo, en este caso, el contrato externo se convierte en el msg.sender del contrato siguiente, lo que hace que la llamada provenga de 'un contrato en lugar de un usuario'.
Este EIP introduce un nuevo tipo de transacción SET_CODE_TX_TYPE=0x04 (antes teníamos la antigua transacción 0x1, la nueva transacción 0x02 de Berlín y la actualización EIP-1559, y la transacción de blob 0x03 introducida en Dencun). Este nuevo tipo de operación le permite configurar códigos para cuentas EOA. En efecto, permite a EOA ejecutar código externo "en el contexto de su propia cuenta EOA". Desde una perspectiva externa, EOA parece "tomar prestado" el código de un contrato externo y ejecutarlo durante una transacción. Técnicamente, esto se hace agregando una tupla de datos de autorización especiales al almacén de "código" de la dirección EOA (hasta este EIP, este almacén de "código" siempre estaba vacío para el EOA).
Actualmente, este nuevo tipo de transacción 0x04 propuesto por EIP contiene una matriz:
Cada elemento permite que la cuenta utilice un código de la dirección especificada (de la última autoridad válida). Al procesar dichas transacciones, establezca el código de una EOA determinada en un 0xef0100|| especial El valor de la dirección (23 bytes) donde la dirección apunta al contrato con el código requerido, || Representa una conexión, y 0xef0100 representa un maná especial que no se puede incluir en un contrato inteligente normal (según EIP-3541). Este maná garantiza que este EOA no se pueda tratar como un contrato normal, ni se pueda invocar como un contrato normal.
Cuando este EOA inicia una transacción, la dirección especificada se utilizará para llamar al código correspondiente en el contexto de este EOA. Aunque los detalles completos de implementación de este EIP aún no están claros, se puede afirmar que traerá cambios significativos.
Uno de los impactos principales es la capacidad de realizar llamadas múltiples (multicall) directamente desde EOA. Las llamadas múltiples son una tendencia continua en DeFi, y muchos protocolos ofrecen esta característica como una herramienta poderosa (por ejemplo, Uniswap V4, Balancer V3 o Euler V2). Con este EIP, ahora es posible iniciar llamadas múltiples directamente desde EOA.
Por ejemplo, esta nueva característica resuelve un problema común en DeFi: la ineficiencia de realizar dos transacciones independientes para approve() + anything(). Este EIP permite la lógica de "preautorización" general, lo que permite que acciones como approve(X) + deposit(X) se realicen en una sola transacción.
Otra ventaja de poder 'representar' la ejecución de transacciones delegadas por EOA es el concepto de patrocinio. El patrocinio es una característica que se discute con frecuencia y se desea intensamente para ayudar a los nuevos usuarios a ingresar a Ethereum.
La lógica programable asociada a EOA ha desbloqueado muchas posibilidades, como la implementación de restricciones de seguridad, establecer límites de gasto, exigir KYC, entre otros.
Por supuesto, este cambio también plantea muchas cuestiones de diseño. Una cuestión es el uso de chain_id, que determina si una misma firma es válida en múltiples redes o no, dependiendo de si está incluida o no en la firma. Otro problema complejo es la elección entre el uso de direcciones de código objetivo y la incrustación de 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 permisos como "multipropósito" o "único propósito". Estos elementos afectan a cuestiones de funcionalidad y seguridad, incluyendo la invalidación masiva de firmas y la facilidad de uso. Vitalik planteó estas cuestiones en una discusión (aquí), que merece una exploración más profunda.
Es importante tener en cuenta que este cambio afectará a un mecanismo de seguridad de Ethereum, tx.origin. Se necesitan más detalles sobre la implementación de este EIP, pero parece que cambiará el comportamiento de require(tx.origin == msg.sender). Esta comprobación siempre ha sido el método más confiable para asegurarse de que msg.sender es una cuenta externa (EOA) en lugar de un contrato. Otros métodos, como comprobar EXTCODESIZE (para ver si es un contrato), suelen fallar y pueden ser eludidos (por ejemplo, llamando al constructor o desplegando código en una dirección predefinida después de la transacción). Estas comprobaciones se utilizan para prevenir ataques de reentrancia y préstamos relámpago, pero están lejos de ser ideales ya que también obstaculizan la integración 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 estas comprobaciones, ya que la distinción entre 'EOA' y 'contrato' ya no será válida, dado que cada dirección puede tener código relacionado.
La separación entre EOA (cuenta externa propiedad de una persona) y los contratos inteligentes continúa difuminándose. Este EIP acerca a Ethereum a diseños como el de TON, donde cada cuenta es esencialmente código ejecutable. A medida que la interacción con los protocolos se vuelve más compleja, el uso de lógica programable para mejorar la experiencia del usuario final es un proceso natural de esta evolución.
Conclusión
La actualización de Prague/Electra (Pectra) está programada para marzo de 2025. Los cambios más significativos en el plan incluyen:
Los validadores con apuestas variables pueden apostar hasta 2048 ETH, lo que cambiará significativamente la distribución de las apuestas, el cronograma de los validadores y simplificará la gestión de los proveedores de grandes apuestas al integrar apuestas más pequeñas.
Mejorar la interacción entre la capa de ejecución y la capa de consenso, simplificar el intercambio de datos entre los bloques de ejecución Eth1 y los bloques de la cadena de referencia. Esto simplificará en gran medida los procesos de depósito, activación, retiro y salida, acelerando estos procesos y sentando las bases para una mayor interacción entre la capa de consenso y la capa de ejecución.
Soportar firmas BLS y verificaciones zkSNARK más económicas directamente a través de la nueva precompilación 'compatible con emparejamiento' BLS12-381 en contratos inteligentes.
Fomentar la adopción de Rollups mediante el aumento del umbral de transacciones de blob y el aumento del costo de calldata para adoptar transacciones de blob.
Hacer que EOA actúe como una cuenta programable, otorgándole múltiples llamadas, patrocinio y otras funciones avanzadas.
Como puedes ver, Pectra tendrá un impacto significativo en la experiencia del usuario final en términos de apuestas, capa de consenso y capa de ejecución. Aunque actualmente no podemos analizar en detalle todos estos cambios a través del código en esta etapa, ya que el desarrollo aún está en curso, cubriremos estas actualizaciones en futuros artículos.
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.
Se acerca una bifurcación dura de Ethereum - Actualización Pectra
Introducción
En nuestro artículo anterior, revisamos en detalle el ciclo de vida de los validadores de Ethereum y discutimos varios aspectos relacionados con el próximo hard fork de Electra. Ahora es el momento de centrarnos en los cambios que se avecinan en las actualizaciones de Electra y Prague, y explicarlos en detalle.
La historia de la bifurcación dura de Ethereum 2.0 'Proof of Stake' es complicada. Comenzó agregando una capa de señales a la capa de ejecución existente, manteniendo al mismo tiempo la prueba de trabajo en la capa de ejecución (fases 0 y Altair). Luego, en la bifurcación dura de Bellatrix, se activó por completo el PoS (aunque el retiro no estaba habilitado). Luego, en la bifurcación dura de Capella, se permitieron los retiros, completando el ciclo de vida de los validadores. La bifurcación dura más reciente, Deneb (parte de la actualización Deneb/Cancún), realizó pequeñas revisiones a los parámetros de la cadena de señales, como la ventana de tiempo de prueba, el manejo de salidas voluntarias y las restricciones de cambio de validadores. Los cambios principales en Deneb/Cancún ocurrieron en la capa de ejecución, introduciendo transacciones de blob, gas de blob, compromisos KZG para blobs y desechando la operación SELFDESTRUCT.
Ahora, la bifurcación dura de Prague/Electra (también conocida como Pectra) ha introducido importantes actualizaciones en las capas de ejecución y consenso. Como auditores del proyecto Lido, nos centramos principalmente en los cambios relacionados con el consenso y la participación en esta bifurcación dura. Sin embargo, no podemos pasar por alto los cambios en la capa de ejecución de Prague, ya que incluyen características importantes que afectan a la red de Ethereum y a los validadores. Profundicemos en los detalles de estos cambios.
Visión general de nivel superior de Pectra
Electra ha introducido muchas funciones en la capa de balizas. Las actualizaciones principales incluyen:
Al mismo tiempo, Praga ha introducido los siguientes cambios en la capa de ejecución:
Consultemos la Propuesta de Mejora de Ethereum relevante (EIP) para una discusión más profunda:
Algunos de estos EIP están principalmente relacionados con la capa de consenso (beacon), mientras que otros están relacionados con la capa de ejecución. Algunos atraviesan ambas capas, ya que ciertas operaciones (como depósitos y retiros) requieren cambios sincronizados entre la capa de consenso y la capa de ejecución. Debido a esta interdependencia, separar Electra y Prague es impracticable, por lo tanto, revisaremos cada EIP secuencialmente y especificaremos los componentes de Ethereum afectados en cada caso.
EIP-7251: Aumentar MAX_EFECTIVE_BALANCE
Referencia: EIP-7251
Desde el primer hard fork de la Fase 0, hasta Electra, en preparación para la prueba de participación de Ethereum, el saldo máximo efectivo de los validadores ha sido fijo en 32 ETH. Activar un validador requiere al menos el spec.min_activation_balance (32 ETH). Después de la activación, el validador comienza con este saldo máximo efectivo, pero puede reducir su saldo efectivo a spec.ejection_balance (16 ETH) y ser expulsado una vez que alcance ese umbral. Esta lógica 'mínima' se mantiene en Electra, pero ahora el spec.max_effective_balance ha aumentado a 2048 ETH. Por lo tanto, los validadores pueden depositar entre 32 y 2048 ETH para activarse, y todas estas cantidades contribuirán a su saldo efectivo. Este cambio marca la transición de '32ETH-Prueba de Participación' a 'Prueba de Participación' :)
Este saldo disponible variable ahora se utilizará para:
Las dos primeras actividades son las más rentables para los validadores. Por lo tanto, después de Electra, los validadores que realizan grandes apuestas participarán más frecuentemente en la propuesta de bloques y en el comité de sincronización, y su frecuencia será proporcional a su saldo efectivo.
Otro impacto está relacionado con las reducciones. Todas las multas de reducción son proporcionales al saldo efectivo del validador:
Electra también propuso cambios en la proporción de reducción, definiendo una parte del saldo del validador reducido y recibido por el denunciante.
A continuación viene el impacto de la invalidez. Cuando un validador está inactivo (ya sea probando o proponiendo) sin conexión, la puntuación de invalidez se acumulará, lo que resultará en una penalización de invalidez en cada período. Estas penalizaciones también están relacionadas con el saldo efectivo del validador.
Debido al aumento del saldo efectivo, también ha habido un cambio en la 'restricción de cambio' del validador. En el Ethereum 'antes de Electra', los validadores suelen tener saldos efectivos similares, y la restricción de cambio de salida se define como 'en un período, como máximo, el 1/65536 (especie.churn_limit_quotient) del total de la apuesta puede salir'. Esto creó una cantidad fija de validadores que salen con la misma apuesta. Sin embargo, 'después de Electra', puede ocurrir que solo unos pocos 'cetáceos' salgan, ya que representan una parte importante de la apuesta total.
Otra consideración es la rotación de muchas claves de validador en una única instancia de validador. Los grandes validadores actualmente están obligados a ejecutar miles de claves de validador en una sola instancia para adaptarse a grandes apuestas, dividiéndolas en partes de 32 ETH. Con Electra, este comportamiento ya no es obligatorio. Desde un punto de vista financiero, este cambio tiene poco impacto, ya que las recompensas y probabilidades escalan linealmente con la cantidad apostada. Por lo tanto, 100 validadores de 32 ETH cada uno son equivalentes a un validador de 3200 ETH. Además, múltiples claves de validador activas pueden tener el mismo comprobante de retiro Eth1, lo que permite que todas las recompensas se retiren a una única dirección ETH, evitando así los costos de gas asociados con la consolidación de recompensas. Sin embargo, gestionar una gran cantidad de claves conlleva costos de gestión adicionales.
La capacidad de saldo de los validadores agregados ha aumentado con un nuevo tipo de solicitud de capa de ejecución. Anteriormente, teníamos depósitos y retiros. Ahora, habrá otro tipo: solicitud de agregación. Fusionará dos validadores en uno. La solicitud de operación incluirá las claves públicas del validador de origen y del destino, y se procesará de manera similar a los depósitos y retiros. La agregación también tendrá límites de solicitud pendiente y cambio de saldo, al igual que los depósitos y retiros.
Resumiendo:
Otro tema importante es el historial de datos y la estimación de ganancias de los validadores, especialmente relevante para los nuevos participantes que intentan evaluar los riesgos y recompensas. Antes de Electra (hasta la fecha de redacción de este artículo), el límite de 32 ETH (ya sea mínimo o máximo, de hecho) creó uniformidad en los datos históricos. El saldo efectivo, las recompensas, las penalizaciones individuales de reducción, la frecuencia de propuesta de bloques y otros indicadores son iguales para todos los validadores. Esta uniformidad permite a Ethereum probar su mecanismo de consenso sin valores atípicos estadísticos y recopilar datos de comportamiento de red valiosos.
Después de Electra, habrá cambios significativos en la distribución del staking. Los validadores grandes participarán con más frecuencia en los comités de propuesta y sincronización de bloques, se enfrentarán a mayores penalizaciones en los eventos de recorte y tendrán un mayor impacto en el recorte retrasado, las colas de activación y las colas de salida. Si bien esto puede crear desafíos en la agregación de datos, el consenso de Ethereum garantiza que la computación no lineal sea mínima. El único componente no lineal utiliza sqrt(total_effective_balance) para calcular la recompensa base, que se aplica a todos los validadores. Esto significa que las recompensas y barras de los validadores aún se pueden estimar "por 1 ETH" (o más precisamente, en función de spec.effective_balance_increment, que puede cambiar en el futuro).
Para obtener más información detallada, consulte nuestro artículo anterior sobre el comportamiento del validador.
EIP-7002: Salida activable 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 BLS activa sirve como la identidad principal del validador en la cadena de señales, se utiliza para firmar bloques, pruebas, reducciones, agregaciones de comités sincronizados y (antes de esta EIP) salidas voluntarias (para iniciar la salida por consenso del validador después de un retraso). El segundo par de claves ("comprobante de retiro") puede ser otro par de claves BLS o una cuenta Eth1 convencional (clave privada y dirección). Ahora, la extracción a una dirección ETH requiere un mensaje de retiro firmado por la clave privada BLS activa. Este EIP realiza cambios.
De hecho, los propietarios de estas dos claves (activa y de retiro) pueden ser diferentes. La clave activa del validador es responsable de las funciones de validación: ejecutar el servidor, mantener su funcionamiento normal, etc., mientras que el retiro generalmente está controlado por el propietario del depósito, quien recibe recompensas y es responsable de los fondos. Actualmente, solo el propietario del depósito que controla el retiro no puede iniciar la salida del validador, solo puede reclamar recompensas. Esta situación permite que el propietario de la clave activa del validador efectivamente mantenga el saldo del validador como un "rehén". El validador puede "pre-firmar" el mensaje de salida y entregárselo al propietario del depósito, pero este método alternativo no es ideal. Además, actualmente la extracción y la salida requieren interactuar con el validador de la capa de señales a través de una API especial.
La mejor solución es permitir que los propietarios de la participación realicen depósitos y retiros simultáneos a través de contratos inteligentes convencionales. Esto implica comprobaciones de firmas Eth1 estándar, lo que simplifica en gran medida las operaciones.
Este EIP permite a los propietarios de tokens apostados activar retiros y salidas enviando transacciones estándar desde sus direcciones ETH a contratos inteligentes dedicados (similar al proceso de depósito utilizando contratos de "depósito" existentes). El proceso de retiro (o salida al retirar suficiente garantía) es el siguiente:
Aunque los depósitos son una operación desencadenada en el bloque Eth1 y luego 'movida' a la capa de señales a través de la cola de depósitos 'pendientes', los retiros siguen un esquema diferente. Se desencadenan en la capa de señales (a través de la CLI) y luego se 'mueven' al bloque Eth1. Ahora, ambos esquemas funcionarán a través de un marco común (como se describe a continuación): crear solicitudes en la capa Eth1, procesar las colas de depósitos/retiros/fusiones 'pendientes' y procesar en la capa de señales. Para operaciones de 'salida' como los retiros, también se procesará la cola de salidas y los resultados se liquidarán en el bloque Eth1.
A través de este EIP, los validadores pueden depositar y retirar sus validadores utilizando transacciones ETH convencionales sin interactuar directamente con la CLI del validador o acceder a la infraestructura del validador. Esto simplifica en gran medida las operaciones de depósito, especialmente para grandes proveedores de depósito. La infraestructura del validador ahora puede estar casi completamente aislada, ya que solo se requiere mantener las claves de los validadores activos y todas las operaciones de depósito se pueden manejar en otro lugar. Elimina la necesidad de que los validadores independientes esperen la acción de los validadores activos y simplifica significativamente la parte fuera de la cadena de servicios como el módulo de apuesta comunitaria de Lido.
Por lo tanto, este EIP 'completa' la operación de staking, trasladándola completamente a la capa Eth1, lo que reduce significativamente el riesgo de seguridad de la infraestructura y fortalece la descentralización de la iniciativa de staking independiente.
EIP-6110: Depositar verificadores en cadena
Referencia: EIP-6110
Actualmente, los depósitos se realizan a través del evento 'Depósito' en el contrato 'Depósito' del sistema (como se discutió detalladamente en un artículo anterior). El contrato acepta ETH y credenciales de validador, emitiendo el evento 'Depósito()', que luego se analiza y se convierte en una solicitud de depósito en la capa de anclaje. Este sistema tiene muchas desventajas: requiere votar por eth1data en la capa de anclaje, lo que agrega un retraso significativo. Además, la capa de anclaje necesita consultar la capa de ejecución, lo que aumenta aún más la complejidad. Estos problemas se discuten en detalle en la EIP. Una forma más simple de abordar muchos de estos problemas es incluir las solicitudes de depósito directamente en los bloques de Eth1 en la ubicación especificada. Este mecanismo es similar al proceso de retiro descrito en una EIP anterior.
Los cambios propuestos en este EIP parecen prometedores. Ahora es posible eliminar por completo el manejo de eth1data, ya no es necesario votar o sufrir largos retrasos (actualmente alrededor de 12 horas) entre los eventos del lado Eth1 y los depósitos incluidos en la capa de anclaje. También se elimina la lógica de instantáneas del contrato de depósito. Este EIP simplifica el manejo de los depósitos y lo alinea con el esquema de retiros mencionado anteriormente.
Para los depositantes y validadores, estos cambios reducen significativamente la demora entre el depósito y la activación del validador. Cuando se reduce un validador, los complementos necesarios también se realizan más rápidamente.
No hay mucho más que decir sobre este EIP, excepto que elimina la lógica obsoleta, simplifica el proceso y crea mejores resultados para todas las partes involucradas.
EIP-7685: Solicitud de capa de ejecución general
Referencia: EIP-7685
Este EIP debería haber sido propuesto antes de los tres EIP relacionados con depósitos/retiros/fusiones, ya que sienta las bases para estos EIP. Sin embargo, se presenta aquí para resaltar la creciente necesidad de mover datos especializados de manera coherente entre Eth1 (ejecución) y bloques de la cadena de consenso de beacon. Este EIP afecta a dos capas, lo que permite un procesamiento más eficiente de las solicitudes desencadenadas por transacciones ETH regulares. En este momento, observamos:
Estas tres operaciones demuestran la necesidad de un manejo consistente de varios tipos de solicitudes al realizar la transición entre la capa de ejecución y la capa de señal. Además, necesitamos la capacidad de activar estas operaciones solo en la capa Eth1, ya que esto nos permitirá aislar la infraestructura del validador de la infraestructura de gestión de staking, mejorando así la seguridad. Por lo tanto, es tanto práctico como necesario contar con una solución general para gestionar este tipo de solicitudes.
Este EIP establece un marco para al menos tres casos principales: depósito, retiro y consolidación. Es por eso que los primeros EIP introdujeron campos como WITHDRAWAL_REQUEST_TYPE y DEPOSIT_REQUEST_TYPE, y ahora la consolidación agregará otro campo, CONSOLIDATION_REQUEST_TYPE. Además, este EIP también puede incluir un mecanismo general para manejar las limitaciones de este tipo de solicitudes (consulte las constantes: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).
Aunque los detalles de implementación de este marco aún no están disponibles, seguramente incluirá tipos de solicitudes clave, mecanismos de integridad (por ejemplo, solicitudes hash y merkleizadas), así como el procesamiento de la cola pendiente y limitaciones de velocidad.
Este EIP tiene un significado arquitectónico que permite a Eth1 activar operaciones clave en la capa de anclaje a través de un marco unificado. Para los usuarios finales y proyectos, esto significa que todas las solicitudes activadas en la capa Eth1 se transmitirán y procesarán de manera más eficiente en la capa de anclaje.
EIP-2537: Precompilación de operaciones en la curva BLS12-381
Referencia: EIP-2537
Si no quieres profundizar, puedes considerar la precompilación de BLS12-381 como una operación de cifrado 'hash' compleja que ahora se puede utilizar en contratos inteligentes. Para aquellos interesados, exploremos más a fondo.
Las operaciones matemáticas realizadas en curvas elípticas como BLS12-381 (y su contraparte BN-254) se utilizan principalmente para dos propósitos en la actualidad:
Si deseas verificar firmas BLS o pruebas zkSNARK en contratos inteligentes, debes calcular estas "parejas", lo que resulta muy costoso en términos computacionales. Ethereum ya tiene un contrato precompilado (EIP-196 y EIP-197) para operaciones en la curva BN254. Sin embargo, la curva BLS12-381 (ahora considerada más segura y de uso más extendido) aún no se ha implementado como precompilada. Sin un contrato precompilado, la implementación de parejas y otras operaciones en la curva en contratos inteligentes requiere cálculos intensivos, como se muestra aquí, y consume una gran cantidad de gas (alrededor de ~10^5 a 10^6 gas).
Esta EIP abre muchas puertas para posibles aplicaciones, especialmente en la verificación de firmas BLS baratas basadas en la curva BLS12-381. Esto hace posible la implementación de esquemas de umbral para diversos fines. Como se mencionó anteriormente, los validadores de Ethereum ya están utilizando firmas basadas en BLS12-381. A través de esta EIP, los contratos inteligentes estándar ahora pueden verificar de manera eficiente las firmas de los validadores agregados. Esto puede simplificar la prueba de consenso y la interoperabilidad de activos entre redes, ya que las firmas BLS se utilizan ampliamente en blockchain. Las propias firmas BLS umbral permiten la construcción de muchos esquemas de umbral eficientes para votación, generación de números aleatorios descentralizada, firmas múltiples, etc.
La verificación de las pruebas zkSNARK más baratas desbloqueará numerosas aplicaciones. Muchas soluciones basadas en zkSNARK actualmente se ven obstaculizadas por los altos costos de verificación de pruebas, lo que hace que algunos proyectos sean casi inviables. Este EIP tiene el potencial de cambiar esto.
EIP-2935: Guardar el hash del bloque histórico en el estado
Referencia: EIP-2935
Esta propuesta de EIP propone almacenar 8192 (aproximadamente 27.3 horas) hash de bloques históricos en el estado de la cadena de bloques para proporcionar un historial ampliado para clientes sin estado (como rollup) y contratos inteligentes. Propone mantener el comportamiento actual del código de operación BLOCKHASH, manteniendo el límite de 256 bloques, mientras introduce un nuevo contrato del sistema diseñado específicamente para almacenar y recuperar hashes históricos. Este contrato realiza la operación set() al procesar bloques en la capa de ejecución. Su método get() está disponible para cualquiera que desee acceder y recuperar los hash de bloques requeridos del búfer circular.
Currently, it is possible to reference historical block hashes in the EVM, but access is limited to the most recent 256 blocks (about 50 minutes). However, in some cases, accessing older block data is crucial, especially for cross-chain applications (which require proof of previous block data) and stateless clients, which regularly need to access early block hashes.
Esta EIP amplía el alcance temporal disponible para rollup y las aplicaciones entre cadenas, permitiéndoles acceder directamente a los datos históricos en EVM sin necesidad de recopilarlos externamente. Por lo tanto, estas soluciones se vuelven más robustas y sostenibles.
EIP-7623: Aumentar el costo de calldata
Referencia: EIP-7623
calldata ajusta el tamaño disponible de la carga útil de la transacción, lo que puede ser grande en ciertos casos (por ejemplo, al pasar grandes matrices o búferes binarios como parámetros). El uso significativo de calldata se atribuye principalmente a los rollup, que envían la carga útil a través de calldata que incluye el estado actual del rollup.
La introducción de datos binarios grandes y verificables en la cadena de bloques es crucial para el rollup. La actualización de Dencun (Deneb-Cancun) introduce una importante innovación para este tipo de casos de uso: transacciones de blob (EIP-4844). Las transacciones de blob tienen su propio costo de gas especializado llamado "blob", aunque su cuerpo se almacena temporalmente, su prueba de encriptación (compromiso KZG) junto con su hash se integra en la capa de consenso. Por lo tanto, en comparación con el almacenamiento de datos utilizando calldata, el blob proporciona una mejor solución para el rollup.
Se alienta a rollup a transferir sus datos a un blob utilizando el enfoque de 'zanahoria y palo'. El costo reducido de gas del blob actúa como la 'zanahoria', mientras que este EIP aumenta el costo de calldata como el 'palo', lo que ayuda a controlar el exceso de almacenamiento de datos en las transacciones. Este EIP complementa al siguiente EIP-7691 (Aumento de la capacidad de blob), que aumenta la cantidad máxima de blobs permitidos por bloque.
EIP-7691: Aumento de la capacidad de datos de blob
Referencia: EIP-7691
En la bifurcación dura anterior de Dencun, se introdujo el blob y el valor inicial de la cantidad máxima y objetivo del blob por "cada bloque" fue una estimación conservadora. Esto se debe a la complejidad de predecir cómo la red P2P manejará la propagación de objetos binarios grandes entre nodos validadores. La configuración anterior ha demostrado ser efectiva, lo que hace que este sea un momento adecuado para probar nuevos valores. Anteriormente, la cantidad de blobs objetivo/máxima por cada bloque se establecía en 3/6. Estas restricciones ahora se han aumentado a 6/9.
La combinación con el EIP-7623 anterior (aumento del costo de calldata) ha motivado aún más a rollup a trasladar sus datos de calldata a blobs. El trabajo para encontrar los mejores parámetros de blobs sigue en marcha.
EIP-7840: agregar la programación de blob al archivo de configuración EL
Referencia: EIP-7840
Esta propuesta de EIP agrega el objetivo y la cantidad máxima de blobs 'por bloque' (discutidos anteriormente) y el valor de actualización de baseFeeUpdateFraction al archivo 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 función es especialmente útil para tareas como estimar el costo de gas de los blobs.
EIP-7702: Configuración del código de cuenta EOA
Referencia: EIP-7702
Este es un EIP muy importante que traerá cambios significativos para los usuarios de Ethereum. Como sabemos, un EOA (cuenta de propiedad externa) no puede tener ningún código, pero puede proporcionar una firma de transacción (tx.origin). Por otro lado, un contrato inteligente tiene bytes de código, pero no puede presentar activamente su propia firma directa. Cualquier interacción de usuario que requiera lógica adicional, automática y verificable actualmente solo se puede realizar llamando a un contrato externo para ejecutar las operaciones necesarias. Sin embargo, en este caso, el contrato externo se convierte en el msg.sender del contrato siguiente, lo que hace que la llamada provenga de 'un contrato en lugar de un usuario'.
Este EIP introduce un nuevo tipo de transacción SET_CODE_TX_TYPE=0x04 (antes teníamos la antigua transacción 0x1, la nueva transacción 0x02 de Berlín y la actualización EIP-1559, y la transacción de blob 0x03 introducida en Dencun). Este nuevo tipo de operación le permite configurar códigos para cuentas EOA. En efecto, permite a EOA ejecutar código externo "en el contexto de su propia cuenta EOA". Desde una perspectiva externa, EOA parece "tomar prestado" el código de un contrato externo y ejecutarlo durante una transacción. Técnicamente, esto se hace agregando una tupla de datos de autorización especiales al almacén de "código" de la dirección EOA (hasta este EIP, este almacén de "código" siempre estaba vacío para el EOA).
Actualmente, este nuevo tipo de transacción 0x04 propuesto por EIP contiene una matriz:
lista_de_autorización = [[chain_id, dirección, nonce, y_parity, r, s], ...]
Cada elemento permite que la cuenta utilice un código de la dirección especificada (de la última autoridad válida). Al procesar dichas transacciones, establezca el código de una EOA determinada en un 0xef0100|| especial El valor de la dirección (23 bytes) donde la dirección apunta al contrato con el código requerido, || Representa una conexión, y 0xef0100 representa un maná especial que no se puede incluir en un contrato inteligente normal (según EIP-3541). Este maná garantiza que este EOA no se pueda tratar como un contrato normal, ni se pueda invocar como un contrato normal.
Cuando este EOA inicia una transacción, la dirección especificada se utilizará para llamar al código correspondiente en el contexto de este EOA. Aunque los detalles completos de implementación de este EIP aún no están claros, se puede afirmar que traerá cambios significativos.
Uno de los impactos principales es la capacidad de realizar llamadas múltiples (multicall) directamente desde EOA. Las llamadas múltiples son una tendencia continua en DeFi, y muchos protocolos ofrecen esta característica como una herramienta poderosa (por ejemplo, Uniswap V4, Balancer V3 o Euler V2). Con este EIP, ahora es posible iniciar llamadas múltiples directamente desde EOA.
Por ejemplo, esta nueva característica resuelve un problema común en DeFi: la ineficiencia de realizar dos transacciones independientes para approve() + anything(). Este EIP permite la lógica de "preautorización" general, lo que permite que acciones como approve(X) + deposit(X) se realicen en una sola transacción.
Otra ventaja de poder 'representar' la ejecución de transacciones delegadas por EOA es el concepto de patrocinio. El patrocinio es una característica que se discute con frecuencia y se desea intensamente para ayudar a los nuevos usuarios a ingresar a Ethereum.
La lógica programable asociada a EOA ha desbloqueado muchas posibilidades, como la implementación de restricciones de seguridad, establecer límites de gasto, exigir KYC, entre otros.
Por supuesto, este cambio también plantea muchas cuestiones de diseño. Una cuestión es el uso de chain_id, que determina si una misma firma es válida en múltiples redes o no, dependiendo de si está incluida o no en la firma. Otro problema complejo es la elección entre el uso de direcciones de código objetivo y la incrustación de 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 permisos como "multipropósito" o "único propósito". Estos elementos afectan a cuestiones de funcionalidad y seguridad, incluyendo la invalidación masiva de firmas y la facilidad de uso. Vitalik planteó estas cuestiones en una discusión (aquí), que merece una exploración más profunda.
Es importante tener en cuenta que este cambio afectará a un mecanismo de seguridad de Ethereum, tx.origin. Se necesitan más detalles sobre la implementación de este EIP, pero parece que cambiará el comportamiento de require(tx.origin == msg.sender). Esta comprobación siempre ha sido el método más confiable para asegurarse de que msg.sender es una cuenta externa (EOA) en lugar de un contrato. Otros métodos, como comprobar EXTCODESIZE (para ver si es un contrato), suelen fallar y pueden ser eludidos (por ejemplo, llamando al constructor o desplegando código en una dirección predefinida después de la transacción). Estas comprobaciones se utilizan para prevenir ataques de reentrancia y préstamos relámpago, pero están lejos de ser ideales ya que también obstaculizan la integración 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 estas comprobaciones, ya que la distinción entre 'EOA' y 'contrato' ya no será válida, dado que cada dirección puede tener código relacionado.
La separación entre EOA (cuenta externa propiedad de una persona) y los contratos inteligentes continúa difuminándose. Este EIP acerca a Ethereum a diseños como el de TON, donde cada cuenta es esencialmente código ejecutable. A medida que la interacción con los protocolos se vuelve más compleja, el uso de lógica programable para mejorar la experiencia del usuario final es un proceso natural de esta evolución.
Conclusión
La actualización de Prague/Electra (Pectra) está programada para marzo de 2025. Los cambios más significativos en el plan incluyen:
Como puedes ver, Pectra tendrá un impacto significativo en la experiencia del usuario final en términos de apuestas, capa de consenso y capa de ejecución. Aunque actualmente no podemos analizar en detalle todos estos cambios a través del código en esta etapa, ya que el desarrollo aún está en curso, cubriremos estas actualizaciones en futuros artículos.