¿Cómo operan las pruebas de validez de transacciones bajo EIP-8361?

EIP-8361 permite que una transacción de marco EIP-8141 envíe un STARK sucinto junto con su carga útil peer-to-peer, lo que habilita a los nodos para confirmar que el prefijo de validación aprobó la transacción bajo las suposiciones de estado declaradas. En lugar de ejecutar repetidamente el mismo mecanismo, los nodos verifican una sola prueba, sus dependencias y las condiciones de estado relevantes, lo que puede reducir el coste de verificación para lógica compleja de cuentas. Las secciones siguientes trazan cómo las transacciones válidas obtienen pruebas, cómo los nodos detectan transacciones obsoletas o fraudulentas, por qué la prueba se refiere al estado válido anterior sin convertirse en una raíz de Merkle, y por qué desaparece tras la inclusión en el bloque.

La explicación también distingue EIP-8361 de los dos principales tipos de seguridad de rollup: las pruebas ZK, que establecen la corrección antes de la aceptación, y las pruebas de fraude, que requieren un proceso de desafío para demostrar que ocurrió una transición inválida. Además, aclara los límites relacionados con firmas ECDSA, seguridad cuántica, posibles riesgos de computadoras cuánticas y el papel más limitado de la propuesta en comparación con soluciones de escalado. Este desglose técnico está dirigido a equipos de billetera, desarrolladores de clientes, operadores de probadores y usuarios que evalúan cómo las transacciones portadoras de pruebas podrían permitir una validación de Ethereum más compleja mientras EIP-8361 sigue siendo una propuesta de red en borrador y no una regla de consenso activa.

Puntos clave:

• EIP-8361 permite que una transacción de marco EIP-8141 lleve una prueba de admisión como metadatos de transporte off-chain.
• Un probador off-chain ejecuta el prefijo de validación contra las suposiciones declaradas y produce un STARK vinculado a la transacción, pagador, dependencias y condiciones de validez.
• Un nodo receptor realiza comprobaciones sin estado, verifica la prueba y las dependencias, y compara las suposiciones con su estado actual de Ethereum.
• Una prueba válida permite la admisión en el mempool sin repetir la simulación completa del prefijo de validación.
• La prueba no determina la validez del bloque, no altera la ejecución ni forma parte del estado permanente de Ethereum. Se descarta tras la inclusión o eliminación del mempool.

¿Qué son las pruebas de validez de transacciones EIP-8361?

EIP-8361 define un método propuesto de admisión para transacciones creadas bajo EIP-8141. Su propósito es limitado: hacer que ciertas transacciones computacionalmente costosas sean lo suficientemente baratas para que los nodos las evalúen antes de reenviarlas a través del mempool público.

Una transacción de marco EIP-8141 puede contener lógica programable que determina si el remitente autoriza la transacción, quién pagará la ejecución y si se cumplen las condiciones especificadas. Esta lógica aparece en un prefijo de validación que se ejecuta antes de los marcos de ejecución ordinarios de la transacción.

En la admisión simulada normal, cada nodo receptor puede necesitar ejecutar ese prefijo para determinar si la transacción debe entrar en su mempool. EIP-8361 añade otra opción. Un probador ejecuta el prefijo una vez off-chain y crea una prueba criptográfica que demuestra que termina con un resultado APPROVE y un pagador identificado.

La transacción y la prueba viajan juntas. El nodo verifica la prueba en lugar de reconstruir todo el proceso de validación.

El marco EIP-8361 más amplio se ocupa de la admisión en el mempool portando pruebas, mientras que el proceso de validación del mempool EIP-8361 determina cómo los nodos receptores deciden aceptar, retener, aparcar o eliminar estas transacciones.

A fecha de 6 de agosto de 2026, EIP-8361 se presenta en el pull request en borrador n.°12075 como propuesta de networking de Standards Track. No introduce un nuevo tipo de transacción ni cambia el consenso de Ethereum por sí mismo.

¿Cómo funciona la prueba criptográfica de EIP-8361?

La prueba cubre una declaración específica en lugar de afirmar que se conoce todo resultado futuro de ejecución.

De forma simplificada, el probador debe demostrar que:

El prefijo de validación de la transacción T, al evaluarse bajo las suposiciones y dependencias declaradas, sigue las reglas de traza de EIP-8141 y termina con APPROVE y pagador P, sujeto a las condiciones declaradas.

Los inputs públicos propuestos vinculan la prueba a cinco elementos:

Esta vinculación es importante porque una prueba válida para una transacción no puede simplemente adjuntarse a otra transacción con datos, dependencias, condiciones o información de pagador diferentes.

El testigo privado incluye la información requerida para evaluar el prefijo, incluyendo el contenido de la lista de dependencias declaradas. La prueba resultante demuestra la corrección de ese cálculo sin obligar a cada nodo receptor a repetirlo.

EIP-8361 actualmente propone reutilizar el formato de prueba y la maquinaria de verificación de ingreso asociada a EIP-8288. El EIP menciona STARKs porque pueden representar un cálculo grande con una prueba relativamente sucinta y no requieren que cada verificador reproduzca la carga de trabajo original.

¿Cómo se utiliza el vector de suposiciones en la validación de transacciones?

Una prueba criptográfica puede demostrar que un cálculo fue correcto para inputs particulares, pero un nodo mempool aún debe determinar si esos inputs coinciden con el estado actual de Ethereum.

EIP-8361 aborda esto con un vector de suposiciones, representado como A. Enumera cada valor de estado leído por el prefijo de validación. Las entradas propuestas incluyen una dirección, una clave de almacenamiento o referencia de saldo, un tipo de comparación y un valor.

Se definen dos tipos de comparación:

• Suposiciones EQ requieren que el valor de estado actual sea igual al valor declarado en la prueba.
• Suposiciones GEQ requieren que el valor de estado actual sea mayor o igual a un umbral declarado.

Una entrada EQ exacta puede ser apropiada para un hash de código, nonce o rama de almacenamiento cuyo significado cambia cada vez que cambia el valor subyacente. Una entrada GEQ es más útil para requisitos monótonos, como verificar que un pagador tenga al menos fondos suficientes para cubrir un prefund.

Por ejemplo, supón que el prefijo de validación de una cuenta inteligente aprueba una transacción solo cuando el balance del paymaster es al menos 0,2 ETH. El probador puede registrar una suposición GEQ con un umbral de 0,2 ETH. Un nodo puede seguir considerando la prueba aplicable mientras el balance sea 0,2 ETH o superior. No necesita una nueva prueba cada vez que el balance aumenta o cambia por encima de ese umbral.

Este diseño evita anclar la prueba a una raíz de estado completa o requerir una prueba de Merkle grande para todo el estado de Ethereum. El circuito evalúa el prefijo de validación contra los valores declarados, mientras que el nodo verifica esos valores contra su propio estado actual.

¿Cómo funcionan las pruebas de validez de transacciones bajo EIP-8361?

El proceso propuesto de validación de transacciones sigue una serie ordenada de comprobaciones.

1. Ejecutar comprobaciones sin estado. El nodo verifica la validez intrínseca de la transacción y confirma que la lista de dependencias o firmas está bien formada. Una transacción mal formada se rechaza antes de la verificación costosa de la prueba.
2. Verificar la prueba de admisión. El nodo verifica el STARK contra la clave de verificación designada. El fallo significa que el cálculo de validación reclamado no ha sido establecido.
3. Verificar dependencias externas. La prueba puede asumir que firmas u otras dependencias declaradas son válidas. El nodo verifica esas dependencias por separado y confirma que su lista coincide con el hash de dependencias comprometido.
4. Comprobar condiciones de validez. El nodo evalúa las condiciones declaradas, que pueden incluir plazos, ventanas de slot o epoch, rangos de vencimiento o requisitos de nonce.
5. Comparar suposiciones con el estado en vivo. Cada entrada EQ se verifica por igualdad, mientras que cada entrada GEQ se prueba contra su umbral.
6. Admitir la transacción. Cuando todas las comprobaciones tienen éxito, el nodo puede aceptar y propagar la transacción sin simular su prefijo de validación completo.

Esta secuencia impide que una prueba eluda comprobaciones estructurales, de firma, estado o temporales ordinarias. Cambia el método computacional utilizado para tomar una decisión de admisión, no los requisitos de validez subyacentes de la transacción.

¿Qué ocurre cuando el estado de Ethereum cambia?

La admisión en el mempool no es una garantía permanente, ya que el estado de Ethereum sigue cambiando después de que una transacción entra en el pool.

Bajo EIP-8361, un nodo vuelve a comprobar las condiciones de validez y el vector de suposiciones cuando un nuevo bloque cambia la cabeza de la cadena. No necesita regenerar la prueba, volver a ejecutar el prefijo de validación ni verificar la misma prueba de nuevo. La prueba previamente verificada sigue siendo un resultado en caché sobre la función de validación bajo sus inputs declarados.

Un fallo EQ normalmente invalida la prueba porque un input exacto ha cambiado. El nodo debe eliminar la transacción a menos que el remitente cree una nueva prueba o la transacción califique para la admisión simulada ordinaria.

Un fallo en una condición GEQ puede manejarse de forma diferente. El nodo puede aparcar la transacción en vez de eliminarla completamente. Si el pagador o paymaster recibe fondos suficientes después, el nodo puede reactivar la transacción comprobando el umbral de nuevo.

Esta distinción hace que el vector de suposiciones sea más que un compromiso estilo Merkle con un estado histórico. Define qué cambios de estado invalidan realmente la aprobación y cuáles siguen siendo compatibles con ella.

¿Por qué se descarta la prueba tras la inclusión en el bloque?

La prueba EIP-8361 solo se necesita para la admisión y propagación en el mempool público. No es la prueba autorizada de que la transacción incluida produjo la transición de estado correcta.

Una vez que un validador incluye la transacción en un bloque, Ethereum la procesa mediante la ejecución ordinaria del protocolo. La EVM ejecuta el prefijo de validación y los marcos restantes según el estado canónico del bloque. Los clientes de consenso determinan si el bloque es válido usando las reglas normales de Ethereum.

En consecuencia, la prueba de admisión:

• No se coloca en el bloque;
• No se añade a la calldata de la transacción;
• No aparece en el recibo;
• No forma parte de un árbol de Merkle ni de una raíz de estado;
• No crea un cambio permanente de estado on-chain;
• No necesita conservarse tras la inclusión o eliminación de la transacción.

Descartarla evita el coste permanente de calldata y el crecimiento del estado para información que ya ha cumplido su función de networking. La transacción en sí permanece on-chain, pero su sobre temporal de prueba no.

Sistema de pruebas EIP-8361 vs. pruebas de validez ZK-Rollup

EIP-8361 utiliza tecnología de pruebas criptográficas, pero su prueba de admisión no debe confundirse con las pruebas de validez usadas por los ZK rollups.

Los ZK rollups suelen usar ZK-SNARKs o ZK-STARKs para probar la corrección de lotes de transacciones. Una vez que la prueba es aceptada por el contrato de capa 1, el rollup puede finalizar la transición de estado asociada sin esperar el periodo de desafío de prueba de fraude usado por los rollups optimistas.

EIP-8361 no prueba un lote L2, ni autoriza retiros inmediatos de rollup, ni garantiza que una cadena L2 nunca entre en un estado inválido. Su prueba es un artefacto temporal de networking sobre la validación previa a la inclusión.

Del mismo modo, aunque las pruebas de conocimiento cero pueden verificar una declaración sin revelar todos los datos del testigo subyacente, EIP-8361 no es principalmente una propuesta de privacidad. “Prueba sucinta” y “conocimiento cero” son propiedades relacionadas pero no intercambiables.

Los retiros de capa 2 a capa 1 pueden ser más rápidos con pruebas de validez porque los ZK rollups no requieren el periodo de desafío de fraude usado por los rollups optimistas. El tiempo final de retiro sigue dependiendo de la generación de la prueba, la verificación en capa 1, las reglas de puente y la finalidad de Ethereum. EIP-8361 no proporciona este mecanismo de retiro; su prueba apoya la admisión en el mempool de una transacción de marco EIP-8141 individual en vez de la liquidación de un lote de transacciones de capa 2.

¿Cómo funcionan las pruebas de fraude en rollups optimistas?

Las pruebas de fraude dependen de un mecanismo de seguridad diferente. Un rollup optimista acepta inicialmente una transición de estado propuesta y permite a los participantes demostrar fraude durante un periodo de disputa. Dependiendo de la implementación, resolver una disputa puede requerir múltiples rondas o una prueba de ejecución acotada.

EIP-8361 intenta establecer la declaración de admisión requerida antes de que la transacción sea aceptada en la clase de mempool relevante. No hay un periodo de desafío posterior a la admisión en el que otro participante pruebe que el resultado del prefijo fue fraudulento.

La diferencia clave es el momento y el alcance:

• Una prueba de validez demuestra una declaración especificada antes de la aceptación.
• Una prueba de fraude permite una declaración optimista salvo que sea desafiada con éxito.
• Una prueba de admisión EIP-8361 concierne a la política del mempool.
• Una prueba de fraude de rollup concierne a la corrección de una transición de estado L2.

Los compromisos técnicos entre ejecución repetida de EVM y verificación sucinta se abordan en EIP-8361 versus simulación de transacciones, incluyendo donde el coste de generación de pruebas reemplaza el coste de simulación en el nodo.

EIP-8361, validación compleja de cuentas y seguridad post-cuántica

Las cuentas programables pueden usar autorización multifirma, rotación de claves, reglas de recuperación, esquemas de firma no estándar, candidatos de firma post-cuántica, políticas de gasto o comprobaciones de conocimiento cero intensivas en gas. Parte de esta lógica puede ser válida pero demasiado costosa para que cada nodo mempool la simule de forma segura.

EIP-8361 intenta preservar la propagación pública de transacciones para estas cuentas haciendo la validación costosa para el probador pero relativamente barata para cada verificador. También puede reducir la presión para mover la autorización compleja a la fase de ejecución, donde una comprobación fallida podría convertirse en una transacción revertida pagada y registrada públicamente.

Este mecanismo no hace que todos los contratos inteligentes sean seguros ni establece seguridad post-cuántica completa. Un STARK puede evitar algunas suposiciones asociadas a sistemas de prueba basados en curvas elípticas, pero la transacción aún puede depender de claves públicas, esquemas de firma, implementaciones de clientes, código de billetera o claves de verificación con propiedades de seguridad separadas.

Las responsabilidades resultantes para creadores de transacciones, billeteras, probadores y clientes difieren sustancialmente, como se resume en el impacto de EIP-8361 en billeteras, nodos y desarrolladores.

Por ejemplo, un trader que evalúe si los avances en la abstracción de cuentas de Ethereum están influyendo en el sentimiento del mercado puede comparar hitos de propuestas con el gráfico de mercado ETH/USDT, aunque la acción del precio no puede confirmar que un EIP en borrador haya sido implementado o adoptado.

Riesgos y limitaciones

EIP-8361 sigue siendo un borrador temprano, por lo que su formato de prueba, límites, dependencias, terminología y detalles de implementación pueden cambiar antes de la estandarización.

El mecanismo también introduce varios riesgos técnicos:

Concentración en la generación de pruebas: Producir un STARK puede requerir software especializado y cálculo sustancial. Si solo unos pocos servicios pueden generar pruebas eficientemente, las billeteras pueden depender de infraestructura de probadores centralizada.

Presión de denegación de servicio: La verificación de pruebas es más barata que repetir el cálculo original, pero no es gratuita. Los clientes necesitan límites consistentes de tamaño de prueba, límites de tasa entre pares y atribución de fallos para evitar que atacantes saturen nodos con pruebas inválidas o sobredimensionadas.

Integridad de suposiciones: La prueba solo es significativa cuando el vector de suposiciones contiene cada estado leído por el prefijo de validación. Un error en el circuito o cliente que omita una dependencia podría producir decisiones de admisión incorrectas.

Obsolescencia de estado: Una prueba puede seguir siendo criptográficamente correcta mientras sus condiciones declaradas ya no coinciden con el estado actual. Los nodos deben seguir comprobando A y C mientras la transacción permanezca en el pool.

Sin garantía de ejecución: La admisión en el mempool no garantiza la inclusión en el bloque ni la ejecución final exitosa. Otra transacción puede cambiar el nonce, saldo, código, almacenamiento u otro estado relevante del remitente antes de la inclusión.

Complejidad de implementación: Clientes, billeteras y sistemas de probadores deben acordar la codificación de pruebas, claves de verificación, manejo de dependencias, comportamiento entre pares y reglas de revalidación. Implementaciones inconsistentes podrían fragmentar la propagación de transacciones.

¿EIP-8361 es también la propuesta Tapered Issuance Burn?

Algunas discusiones iniciales asociaron el número EIP-8361 con una propuesta separada de política monetaria de Ethereum llamada Tapered Issuance Burn. Esa propuesta fue identificada posteriormente como EIP-8363, mientras que EIP-8361 se refiere a pruebas de validez de transacciones en la categoría de networking. Las dos propuestas no están relacionadas: EIP-8361 aborda la admisión en el mempool basada en pruebas, mientras que Tapered Issuance Burn cambia la economía de recompensas del consenso según el saldo activo de staking.

Conclusión

Las pruebas de validez de transacciones EIP-8361 trasladan la parte costosa de la validación de transacciones programables de cada nodo receptor hacia un probador off-chain. El STARK resultante vincula una transacción EIP-8141 a su resultado de aprobación, pagador, dependencias, condiciones y suposiciones de estado, permitiendo a los nodos verificar una declaración concisa antes de la admisión en el mempool.

El mecanismo es más útil cuando una cuenta inteligente tiene lógica de validación legítima que excede los límites prácticos de simulación. Su principal restricción es igualmente importante: la prueba solo se aplica a la admisión en la capa de networking. Ethereum sigue ejecutando la transacción normalmente al incluirla, y la prueba temporal se descarta porque no tiene papel de consenso ni on-chain después.

Preguntas frecuentes

¿Cómo usan los ZK rollups las pruebas de validez?

Los ZK rollups procesan transacciones off-chain, las agrupan en lotes y calculan una prueba de validez para cada lote. La prueba, a menudo construida con ZK-SNARKs, ZK-STARKs o compromisos polinomiales, permite a un contrato de Ethereum verificar que la transición de estado resultante es correcta sin volver a ejecutar cada transacción.

¿Las pruebas de validez garantizan que una cadena L2 no pueda volverse inválida?

Las pruebas de validez evitan que un verificador L1 acepte una transición de estado inválida cuando el circuito, el contrato verificador, la criptografía y la implementación funcionan correctamente. No eliminan riesgos relacionados con errores de código, disponibilidad de datos, puentes, secuenciadores, gobernanza o controles de actualización.

¿Por qué los retiros de ZK-rollup suelen ser más rápidos?

Los ZK rollups pueden finalizar retiros después de que la prueba de validez se envía y verifica, sin esperar el periodo de desafío de fraude usado por los rollups optimistas. Los retiros pueden depender aún de la generación de la prueba, envío del lote, reglas de puente y finalidad de Ethereum, por lo que “inmediato” no siempre significa instantáneo.

¿Cómo difieren las pruebas de validez de las pruebas de fraude?

Las pruebas de validez establecen la corrección de la transacción antes de que se acepte una transición de estado. Las pruebas de fraude funcionan mediante un modelo optimista en el que una transición puede aceptarse temporalmente y ser desafiada después; muchos rollups optimistas usan un periodo de desafío de unos siete días, aunque la duración exacta varía.

¿Las pruebas de conocimiento cero siempre ocultan datos de transacciones?

No. Las pruebas de conocimiento cero pueden verificar una declaración sin revelar su testigo privado, pero la privacidad depende de qué inputs permanecen ocultos. Muchos ZK rollups usan pruebas ZK principalmente para la verificación escalable de transacciones en vez de transacciones totalmente privadas.

¿Cuál es la diferencia entre ZK-SNARKs y ZK-STARKs?

Los ZK-SNARKs generalmente producen pruebas pequeñas con bajo coste de verificación, aunque muchos diseños requieren una configuración confiable. Los ZK-STARKs no requieren configuración confiable y suelen considerarse más resistentes a futuros ataques de computadoras cuánticas, pero sus pruebas suelen ser más grandes.

¿Qué verifica una prueba de Merkle?

Una prueba de Merkle confirma que datos específicos pertenecen a un conjunto representado por una raíz de Merkle sin revelar ni descargar el conjunto completo. Prueba inclusión o exclusión, no la corrección de un lote completo de transacciones o transición de estado.

¿Las pruebas de validez reducen el consumo de recursos on-chain?

Sí, pueden comprimir un cálculo off-chain grande en una sola prueba que es más barata de verificar on-chain que volver a ejecutar cada transacción. El ahorro real depende del coste de verificación de la prueba, tamaño del lote, uso de calldata o blob y la implementación del rollup.

¿Las pruebas de validez reducen el riesgo de ataque del 51 %?

No directamente. Las pruebas de validez protegen la corrección de transiciones de estado verificadas de capa 2, mientras que un ataque del 51 % concierne al control sobre el consenso y la elección de fork en Ethereum. Los dos mecanismos abordan riesgos de seguridad diferentes.

¿Las pruebas EIP-8361 son iguales a las pruebas ZK-rollup?

No. Las pruebas ZK-rollup verifican lotes de transacciones de capa 2 y apoyan la finalidad de estado y retiros. Las pruebas EIP-8361 apoyan la admisión en el mempool de transacciones de marco EIP-8141 individuales, permanecen fuera del bloque y se descartan tras la inclusión o eliminación.

Aviso legal

Este contenido es educativo y describe una propuesta de Ethereum en borrador cuya especificación y estado de implementación pueden cambiar. No proporciona asesoramiento financiero, de seguridad ni de despliegue de software. Los desarrolladores deben verificar el texto EIP más reciente y los requisitos de cliente antes de construir sistemas de producción.