¿Qué es EIP-8361? Explicación de las pruebas de validez de Ethereum

EIP-8361 aborda de forma específica la admisión mediante pruebas de validez para las transacciones frame de EIP-8141. No sustituye la ejecución de Ethereum, no introduce un nuevo tipo de transacción, no despliega contratos inteligentes, no otorga privacidad a las transacciones, no modifica las recompensas de los validadores ni define un periodo de implementación de 18 meses. Su función práctica es más limitada: reducir la computación redundante durante la validación de transacciones, manteniendo salvaguardas contra operaciones inválidas o de alto consumo de recursos.

A continuación se explica cómo funciona el proceso de admisión con pruebas, qué verifican los nodos, en qué se diferencia EIP-8361 de las pruebas de validez de rollups y de la simulación de transacciones, y qué limitaciones técnicas siguen abiertas.

Puntos clave:

• EIP-8361 estandariza los datos de pruebas de validez de transacciones para su propagación peer-to-peer. Una transacción frame puede portar un STARK que demuestra que su prefijo de validación alcanza un estado aprobado.
• Los nodos verifican la prueba en lugar de repetir lógica de autorización costosa. Esta separación entre prueba y verificación puede reducir la computación repetida en los nodos de Ethereum.
• La prueba permanece fuera del consenso. Se transporta con la transacción, se usa para la admisión en el mempool y se descarta cuando ya no es necesaria.
• El diseño admite validaciones complejas de smart accounts. Ejemplos: multifirma, sistemas de firmas alternativos, paymasters y autorizaciones intensivas en pruebas.
• EIP-8361 sigue siendo un borrador. No está activado y no debe confundirse con EIP-7701, EIP-7702, pruebas de validez de rollups ni propuestas de recompensas por staking.

¿Qué es EIP-8361?

EIP-8361, titulada Pruebas de validez de transacciones, propone un mecanismo de red para que una transacción de Ethereum pueda incluir evidencia criptográfica de que su lógica de validación la aprueba. Este borrador complementa a nivel de red los cambios de protocolo de EIP-8141, que define transacciones frame y validaciones programables.

Una Propuesta de Mejora de Ethereum (EIP) es un documento técnico que describe un estándar potencial, una funcionalidad de protocolo, una interfaz o un proceso para Ethereum. La publicación como EIP no implica aceptación ni despliegue automático. EIP-8361 sigue siendo un borrador en desarrollo y su especificación, dependencias y estado pueden cambiar.

La propuesta responde a esta pregunta:

¿Cómo puede un nodo admitir de forma segura una transacción cuya autorización es costosa de ejecutar, sin requerir que cada par repita esa computación costosa?

Con EIP-8361, un probador ejecuta la lógica de validación relevante fuera de la cadena y genera un STARK. El nodo receptor verifica esa prueba, comprueba sus supuestos frente al estado actual de Ethereum y decide si incluye la transacción en su mempool público.

La transacción debe seguir siendo válida según las reglas de ejecución de Ethereum cuando se incluya en un bloque. La prueba respalda la política de admisión, pero no sustituye la ejecución ni la validación por consenso.

Por qué la validación compleja de transacciones en Ethereum es difícil

Una cuenta externa convencional (EOA) se controla mediante una clave privada y su clave pública. La cuenta autoriza transacciones con una firma ECDSA, mientras que la transacción define campos como nonce, dirección de destino, valor, chain ID, límite de gas y precio del gas o parámetros de comisión de EIP-1559.

Estas comprobaciones son predecibles. Un nodo puede verificar la firma, confirmar fondos suficientes, comprobar el nonce y rechazar transacciones mal formadas o repetidas.

Las smart accounts amplían la superficie de validación. En vez de depender de una sola clave privada, una smart account puede usar:

• Varias claves públicas
• Límites de gasto
• Claves de sesión
• Contratos delegados
• Reglas de paymaster
• Firmas post-cuánticas
• Condiciones de recuperación
• Pruebas de conocimiento cero
• Código de autorización específico de la aplicación

Esta lógica puede estar en un contrato inteligente ya desplegado o en uno creado al desplegar la cuenta. Crear y desplegar contratos puede requerir validar una factory, código de inicialización o la dirección del nuevo contrato.

Los nodos de Ethereum no pueden ejecutar código de validación ilimitado para cada transacción no confirmada que reciben. Un atacante podría enviar transacciones fraudulentas que invoquen contratos inteligentes costosos, funciones hash, lecturas de almacenamiento o sistemas de pruebas sin autorizar la ejecución. Aunque sean inválidas, verificarlas consume recursos del nodo.

Las pruebas de validez de transacciones EIP-8361 trasladan el trabajo costoso a un probador, manteniendo acotada la verificación.

Cómo funcionan las transacciones con pruebas de EIP-8361

EIP-8361 propone dos formas de admitir una transacción frame de EIP-8141:

1. Admisión simulada: el nodo ejecuta directamente el prefijo de validación.
2. Admisión mediante prueba: el nodo verifica un STARK que demuestra que el prefijo de validación aprueba.

La segunda vía está prevista para casos en los que una llamada normal al código de validación superaría el presupuesto de verificación del nodo.

1. La transacción define su lógica de validación

Una transacción frame de EIP-8141 puede dividir su trabajo en frames con distintos propósitos. Algunos frames establecen la autorización, identifican al pagador o preparan la ejecución. El prefijo de validación se ejecuta antes de los frames de ejecución normales.

El prefijo de validación puede invocar un contrato inteligente del remitente u otro contrato delegado. Ese contrato puede comprobar firmas, permisos, saldos, vencimientos u otras reglas antes de invocar la operación APPROVE.

EIP-8141 difiere de una transacción convencional en la que una firma ECDSA reconocida por el protocolo determina directamente el remitente. Su modelo de validación programable es parte del avance hacia la abstracción nativa de cuentas. EIP-8141 evita depender de la lista de autorizaciones basada en ECDSA de EIP-7702, ya que las transacciones frame buscan mayor flexibilidad criptográfica.

2. Un probador ejecuta el prefijo de validación

El probador ejecuta el prefijo de validación de la transacción con entradas y supuestos de estado declarados. Esto puede incluir verificar que:

• Una firma corresponde a la clave pública adecuada
• El saldo del remitente es suficiente
• El saldo de un paymaster supera el mínimo requerido
• Un slot de almacenamiento del contrato contiene el permiso esperado
• El chain ID coincide con la red prevista
• Un nonce evita ataques de repetición
• El código de validación termina con aprobación

El probador crea entonces un STARK que compromete la transacción, dependencias, supuestos, pagador y condiciones de validez.

3. La prueba declara supuestos de estado

Una prueba criptográfica no es útil si depende de un estado que ha cambiado. EIP-8361 propone un vector de supuestos que describe los hechos de estado usados durante la prueba.

Una condición de igualdad puede exigir que el hash de código, el nonce o el valor de almacenamiento coincidan exactamente con lo declarado. Una condición de mayor o igual puede exigir que el saldo de una cuenta supere un mínimo.

Estos supuestos vinculan la prueba a un estado anterior sin requerir que incluya todo el estado de Ethereum. Cuando un nuevo bloque cambie datos relevantes, el nodo puede volver a comprobar el vector de supuestos.

Este mecanismo es clave para la validación de mempool según EIP-8361: el nodo no confía en una prueba antigua solo por su validez criptográfica.

4. Los nodos verifican el STARK

El nodo receptor realiza comprobaciones estructurales de bajo coste antes de verificar la prueba. Luego verifica el STARK con la clave de verificación y comprueba dependencias y supuestos frente a su visión actual del estado de Ethereum.

Las pruebas modernas pueden ser más rápidas de verificar que volver a ejecutar el cálculo original. Una sola prueba puede reemplazar la simulación repetida por muchos pares, reduciendo la computación redundante en la red peer-to-peer.

Esto no significa que generar la prueba sea barato. Producir un STARK puede requerir mucho procesamiento, memoria y software especializado. La propuesta traslada la computación, no la elimina.

5. La transacción entra en el mempool

Si la prueba y las comprobaciones de estado son correctas, el nodo puede admitir y propagar la transacción sin repetir el prefijo de validación costoso.

La prueba es solo metadatos peer-to-peer. No se añade al calldata, ni se almacena en contratos inteligentes, ni en el estado de la cuenta, ni se incluye en la raíz de Merkle del bloque.

Una vez incluida la transacción, Ethereum la ejecuta según las reglas del protocolo. Si la prueba queda obsoleta o la transacción se elimina, los metadatos pueden descartarse.

¿Qué prueba una prueba de validez EIP-8361?

Una prueba de validez EIP-8361 es evidencia criptográfica de que un cálculo de validación se ejecutó correctamente bajo los supuestos declarados y alcanzó el estado de aprobación requerido.

Puede demostrar que la lógica de validación comprobó una firma válida, saldos suficientes, el nonce correcto, un pagador permitido o una autorización definida por contrato. Sin embargo, no prueba la corrección de cada transición de estado de la EVM que produzca la transacción.

La distinción es relevante:

• EIP-8361 prueba la validación para la admisión.
• Una prueba de validez de rollup prueba una o más transiciones de estado off-chain.
• Una prueba de Merkle acredita la inclusión en una estructura de datos autenticada.
• Una prueba de conocimiento cero puede ocultar información, pero la validez no implica privacidad.

Una prueba de Merkle puede demostrar que una transacción pertenece a un lote, bloque o árbol de estado conectando una hoja a una raíz de Merkle conocida. En los ZK rollups, las pruebas de Merkle pueden demostrar que las cuentas existían en el estado anterior y que los saldos actualizados producen la nueva raíz de estado.

EIP-8361 utiliza un STARK como prueba eficiente de corrección, pero el objetivo no es la ejecución confidencial. La transacción y sus dependencias pueden seguir siendo visibles para los nodos participantes.

EIP-8361 frente a pruebas de validez de ZK-Rollup

Las soluciones de escalado de capa 2 usan pruebas de validez de forma más amplia. Un ZK rollup ejecuta un lote de transacciones off-chain y envía una prueba sucinta a un contrato verificador de Ethereum. Esa prueba demuestra que el lote transformó el estado anterior en uno correcto según las reglas del rollup.

En vez de volver a ejecutar cada transacción en Ethereum, el contrato verificador comprueba la prueba y las entradas públicas. Esto puede reducir el consumo de recursos on-chain y repartir las comisiones de gas entre muchas transacciones. Las pruebas recursivas pueden agregar varias pruebas en una sola.

Las pruebas de validez ayudan a evitar que un ZK rollup finalice una transición de estado inválida, si su sistema de pruebas, circuito, contrato verificador y modelo de disponibilidad de datos son seguros. También permiten una liquidación L2 a L1 más rápida que los sistemas con ventana de disputas.

EIP-8361 es diferente. No prueba un lote de cálculos, ni actualiza una raíz de Merkle de L2, ni desencadena retiros. Prueba que una transacción frame cumple los requisitos de admisión de un nodo.

Pruebas de validez EIP-8361 frente a pruebas de fraude

Los rollups optimistas asumen que los cambios de estado enviados son válidos salvo impugnación. Las pruebas de fraude requieren que los observadores detecten una transición disputada y aporten evidencia durante el periodo de desafíos. Una reclamación inválida puede aceptarse provisionalmente hasta que se resuelva el desafío.

Las pruebas de validez adoptan el enfoque contrario: un nuevo compromiso de estado solo se acepta tras confirmar evidencia criptográfica de ejecución correcta. Esto permite retiros más rápidos porque los usuarios no esperan el periodo de desafíos por fraude.

Sin embargo, afirmar que las pruebas de validez son siempre “más seguras” que las de fraude es demasiado general. Las diferencias clave incluyen la complejidad del probador, seguridad del verificador, disponibilidad de datos, configuraciones de confianza, supuestos de desafío y madurez de la implementación.

EIP-8361 no es un modelo de seguridad de rollup. Su prueba se verifica antes de la admisión en el mempool, mientras que las pruebas de fraude y validez de rollups protegen sistemas de escalado off-chain.

EIP-8361 frente a delegación de cuentas en EIP-7702

EIP-7702 permite que las EOA establezcan un indicador de delegación en su campo de código para que las llamadas a la cuenta ejecuten código de un contrato inteligente designado. Introdujo un tipo de transacción 4 con una authorization_list.

Cada tupla de autorización incluye:

• chain_id
• Dirección del contrato delegado
• Nonce de la cuenta
• Campos de firma

La autorización la firma la clave privada de la EOA. El firmante puede diferir de tx.origin y una transacción puede incluir autorizaciones de varias EOA. Cada autorización puede actualizar el indicador de delegación antes de la ejecución normal.

Así, los usuarios pueden delegar capacidades de ejecución a contratos inteligentes con autorizaciones firmadas sin convertir la cuenta en un contrato inteligente convencional. El código delegado puede admitir agrupación, patrocinio de gas, permisos u otros comportamientos de smart account.

EIP-7702 también plantea consideraciones de seguridad. Un chain ID de cero puede hacer válida una autorización entre cadenas, mientras que nonces y campos firmados limitan ataques de repetición. El código delegado puede afectar supuestos sobre tx.origin, transacciones pendientes, almacenamiento y saldos.

EIP-8361 no reemplaza ni amplía la authorization_list. Aborda cómo los nodos pueden admitir transacciones con validación compleja. Las diferencias clave entre pruebas de validez EIP-8361 y simulación de transacciones afectan a la computación en mempool, no a la delegación de código de EOA.

EIP-8361 frente a abstracción nativa de cuentas en EIP-7701

EIP-7701 se propuso el 1 de mayo de 2024 como abstracción nativa de cuentas. Dividía el procesamiento de transacciones en validación, ejecución y post-operación, y proponía un nuevo tipo de transacción EIP-2718.

Su diseño usaba la dirección entry-point nativa 0x7701, opcodes basados en roles, validación separada de remitente y paymaster y pago de gas controlado por contrato. No requería el flujo de agrupador ERC-4337 para su tipo de transacción.

EIP-7701 ha sido retirado porque lo reemplazó EIP-8141, no solo marcado como “Stagnant”. Su especificación publicada indica el motivo de la retirada. La afirmación de que EIP-7701 requiere contratos con formato EOF no es parte de su especificación final.

EIP-8361 se basa en el modelo de transacciones frame de EIP-8141. Así, facilita una vía de abstracción de cuentas a nivel de protocolo al hacer más segura la validación programable costosa.

EIP-2718 proporciona el sobre de transacción tipada usado por propuestas como EIP-7701, EIP-7702 y EIP-8141. Define una transacción como TransactionType || TransactionPayload, donde el tipo identifica cómo debe interpretarse la carga. Incluir el tipo en los datos firmados también reduce el riesgo de repetición de firmas entre tipos.

Impacto práctico en billeteras, nodos y desarrolladores

Los desarrolladores de billeteras pueden usar la admisión mediante pruebas cuando la autorización de una smart account sea demasiado costosa para la simulación normal del mempool. Una billetera podría solicitar una prueba a un probador local, un servicio de billetera o una red distribuida antes de enviar la transacción.

Los desarrolladores de nodos deberán implementar:

• Transporte de pruebas entre conexiones peer-to-peer
• Claves de verificación versionadas
• Límites de tamaño de prueba
• Comprobaciones de supuestos y dependencias
• Límites de frecuencia por par
• Expulsión de pruebas obsoletas
• Simulación de reserva

Los desarrolladores de contratos inteligentes podrán mantener validaciones específicas de la aplicación sin requerir que todos los nodos ejecuten su coste completo. Esto puede admitir firmas post-cuánticas, políticas de varias claves, paymasters complejos o permisos basados en pruebas.

El impacto de EIP-8361 en billeteras, nodos y desarrolladores dependerá de la latencia de pruebas, la adopción por parte de los clientes, la interoperabilidad y la especificación final de EIP-8141.

Por ejemplo, un trader que evalúe la reacción del mercado en un exchange como Gate ante una futura actualización de Ethereum puede comparar los anuncios de red con el gráfico de mercado ETH/USDT. El precio de mercado, el volumen de trading o las comisiones de gas no determinan si un EIP en borrador ha sido aceptado o activado técnicamente.

Consideraciones de seguridad y limitaciones

EIP-8361 introduce varias consideraciones de seguridad.

Primero, la solidez de la prueba depende de la corrección del circuito STARK y la clave de verificación. Un fallo en el circuito podría probar una afirmación que no represente las reglas de validación buscadas.

Segundo, la verificación de la prueba consume computación y ancho de banda. Los atacantes pueden enviar pruebas mal formadas o de gran tamaño, por lo que se requieren controles preliminares, límites de tamaño y atribución de pares.

Tercero, los supuestos pueden quedar obsoletos. Una prueba válida para un saldo, almacenamiento, hash de código de contrato o nonce puede dejar de ser aplicable tras un nuevo bloque.

Cuarto, políticas de nodos inconsistentes pueden fragmentar la propagación de transacciones. Diferentes clientes pueden elegir límites de tamaño de prueba, límites de validación o valores predeterminados de admisión distintos.

Quinto, la generación de pruebas puede centralizarse si solo unos pocos servicios cuentan con hardware o software optimizado suficiente.

EIP-8361 tampoco elimina los costes ordinarios de transacción. Si una transacción llega a la ejecución en bloque, el remitente o pagador sigue pagando el gas correspondiente. Una prueba de validez puede reducir la computación redundante off-chain, pero no elimina las comisiones de gas de Ethereum.

Qué NO propone EIP-8361

Algunas afirmaciones difundidas corresponden a propuestas no relacionadas y no deben atribuirse a EIP-8361.

EIP-8361 no:

• Especifica un periodo de transición de 18 meses
• Elimina un suelo de rendimiento por staking
• Limita las recompensas de los validadores
• Deduce recompensas conforme el staking se acerca al 50 %
• Crea un equilibrio de staking impulsado por el mercado
• Introduce la lista de autorizaciones de EIP-7702
• Introduce el entry point nativo de EIP-7701
• Crea un nuevo tipo de transacción EIP-2718
• Garantiza privacidad
• Liquida lotes de ZK-rollup
• Sustituye pruebas de fraude
• Renuncia a derechos contractuales o relacionados de los usuarios

La sección de copyright del borrador puede indicar que los derechos de autor y conexos se renuncian bajo CC0, como es habitual en los EIP. Ese aviso legal se refiere al documento de la propuesta, no a fondos, derechos de transacción ni permisos de contratos inteligentes de los usuarios.

Conclusión

EIP-8361 propone la admisión de transacciones con pruebas para el mempool público de Ethereum. Un probador ejecutaría una vez un prefijo de validación complejo de EIP-8141, generaría un STARK y varios nodos podrían verificar el resultado sin repetir la misma computación costosa.

Su caso de uso más fuerte es la autorización programable que supera los límites de validación ordinarios del mempool, incluyendo smart accounts avanzadas, sistemas de firmas alternativos, paymasters y contratos intensivos en pruebas. El diseño puede reducir la computación redundante de los nodos, manteniendo los supuestos de estado actuales visibles y comprobables.

EIP-8361 no debe confundirse con la liquidación de ZK-rollups, desafíos de pruebas de fraude, la delegación de cuentas de EIP-7702 ni el diseño retirado de EIP-7701. Sigue siendo una propuesta de red en borrador cuya seguridad, economía de pruebas, interoperabilidad y dependencias requieren mayor desarrollo antes de cualquier despliegue potencial en Ethereum.

Preguntas frecuentes

¿EIP-8361 crea un nuevo tipo de transacción?

No. Aplica la admisión mediante pruebas a las transacciones frame de EIP-8141. EIP-2718 proporciona el marco general de transacciones tipadas, pero EIP-8361 no introduce otro sobre de transacción.

¿Las pruebas de EIP-8361 son pruebas de conocimiento cero?

El borrador propone pruebas de validez basadas en STARK, pero la validez no implica necesariamente privacidad. La prueba acredita la validación correcta bajo los supuestos declarados, no oculta todos los datos de la transacción.

¿Una sola prueba puede abarcar varias transacciones?

Los sistemas de pruebas pueden agregar cálculos o usar pruebas recursivas, y los rollups pueden comprimir varias pruebas de transacción en una. El diseño actual de EIP-8361 se centra en la admisión de una transacción frame concreta, no en estandarizar la agregación de lotes arbitrarios.

¿EIP-8361 reduce las comisiones de gas?

No directamente. Puede reducir la computación repetida off-chain por parte de los nodos, pero una transacción incluida sigue pagando el gas requerido por la ejecución en Ethereum.

¿En qué se diferencia EIP-8361 de EIP-7702?

EIP-7702 permite que las EOA deleguen la ejecución de código mediante tuplas de autorización firmadas. EIP-8361 propone una vía basada en pruebas para que los nodos admitan transacciones con validación programable costosa.

Aviso legal

Este contenido es educativo y describe propuestas técnicas en borrador, no actualizaciones garantizadas de Ethereum. Las especificaciones, planes de implementación, supuestos de seguridad y soporte de red pueden cambiar. Los desarrollos del protocolo y los datos históricos de mercado no predicen el rendimiento futuro de ETH.