Investigadores de Nethermind, desarrollador de clientes de Ethereum, han publicado un benchmark que examina cuánto puede crecer el presupuesto de validación definido por el parámetro MAX_VERIFY_GAS de EIP-8141 antes de que los nodos de Ethereum queden expuestos a ataques de denegación de servicio (DoS) en el mempool. El hallazgo central del estudio es que una protección a nivel de cliente — pausar la validación del mempool mientras se procesa un bloque — es la diferencia entre un tope viable de 300,000 gas y una configuración que agota los recursos del nodo bajo una avalancha adversaria sostenida.

Qué pretende restringir el presupuesto de validación de EIP-8141

EIP-8141 es una propuesta Core de Standards Track en estado Draft titulada "Frame Transaction". Según su propósito declarado, la propuesta añade una capa de abstracción de frame para la validación, ejecución y pago de gas de las transacciones, permitiendo que las transacciones incluyan lógica de validación personalizada antes de ser admitidas en el mempool y eventualmente incluidas en un bloque. El texto de la propuesta está disponible en el repositorio de EIP de Ethereum. El mempool es la cola donde los nodos mantienen las transacciones que han pasado la validación mientras esperan ser incluidas en un bloque, razón por la cual el cómputo en la etapa de admisión es el punto focal de la preocupación de DoS aquí analizada.

El presupuesto de validación — definido por un parámetro llamado MAX_VERIFY_GAS — establece cuánto cómputo debe realizar un nodo para admitir una sola transacción frame. Con 100,000 gas por transacción, el tope actual del borrador es demasiado bajo para casos de uso reales: un gasto de privacidad Groth16 de una sola nota requiere 211,828 gas para su validación, y las variantes de firmas SPHINCS+ demandan hasta 276,000 gas. Por lo tanto, el tope debe crecer para ser práctico, pero cada revisión al alza amplía la superficie de ataque disponible para adversarios dispuestos a inundar los nodos con transacciones costosas que fallan.

La tensión de diseño es familiar para quien siguió el debate de abstracción de cuentas de EIP-4337: el trabajo de validación que ocurre fuera del camino de ejecución es barato de disparar para los atacantes, pero costoso de absorber para los nodos. EIP-8141 traslada ese trabajo a un presupuesto impuesto por el protocolo, lo que al menos acota el costo. Sin embargo, dónde colocar ese límite implica una compensación directa entre riqueza de funcionalidades y resiliencia del mempool.

EIP-8141 sigue siendo una propuesta en borrador y no está activada en ninguna red de Ethereum en producción. Los hallazgos del benchmark son un aporte de investigación a esa discusión de diseño, no una descripción de una configuración desplegada.

Cómo mide el benchmark la exposición a DoS del mempool

Los investigadores de Nethermind inundaron un nodo Nethermind de un solo núcleo con transacciones de validación fallidas en tres máquinas de rendimiento variado, probando topes de MAX_VERIFY_GAS de entre 100,000 y 500,000 gas. La métrica central fue si la sobrecarga de validación mantenía la latencia de importación de bloques dentro de un presupuesto de 25 ms — el umbral por debajo del cual se considera que el procesamiento normal de bloques no se ve afectado por la carga concurrente del mempool. El informe completo aparece en el foro de Ethereum Research.

Sin protección en el cliente, los resultados fueron limitantes. En el perfil de nodo completo más lento, el nodo solo se mantuvo dentro del presupuesto de retraso de importación de 25 ms hasta aproximadamente 15 millones de gas de validación por segundo. Con una tasa de avalancha de 100 transacciones fallidas por segundo, ese techo de throughput dejó solo el tope de 100,000 gas dentro del presupuesto — lo que significa que cualquier incremento del tope que habilite validación criptográfica real también crearía un vector de DoS viable en hardware típico de operadores de nodos domésticos.

El benchmark evalúa dos ejes distintos de la salud del mempool: la seguridad del procesamiento de bloques (¿la sobrecarga de validación retrasa la importación de bloques?) y la equidad de admisión de transacciones (¿los remitentes honestos aún logran introducir sus transacciones frame en el mempool cuando un adversario inunda la red?). Estos dos ejes no avanzan juntos, razón por la cual el mecanismo de protección no resuelve el problema completo incluso cuando maneja bien el primer eje.

El mecanismo de protección y su costo residual

La protección propuesta en el cliente es directa: pausar la validación del mempool mientras el nodo procesa un bloque entrante. Esto desacopla las dos cargas de trabajo que compiten por el mismo núcleo de CPU, evitando que una avalancha de validación consuma el presupuesto de tiempo que necesita la importación de bloques. Con esta protección activa, el benchmark reporta que el retraso de importación cayó a aproximadamente 2 ms o menos en todas las máquinas probadas, permitiendo que un tope de 300,000 gas bajo una avalancha de 100 transacciones por segundo se mantenga dentro del presupuesto de procesamiento de bloques de 25 ms. Nethermind tiene un pull request abierto que implementa este comportamiento de priorización.

El mecanismo de pausa resuelve el problema de importación de bloques, pero no el de equidad de admisión. Bajo una avalancha de 100 transacciones por segundo con el tope de 300,000 gas, la máquina más lenta probada admitió solo el 12% de las transacciones frame honestas. Cuando el nodo pausa la validación para procesar bloques, la avalancha adversaria llena la cola de validación en los intervalos, y las transacciones honestas son desplazadas. El presupuesto de procesamiento de bloques de 25 ms se preserva, pero la utilidad del mempool para los remitentes legítimos de transacciones frame se degrada drásticamente bajo presión adversaria sostenida.

Este colapso de admisión es estructuralmente similar a la dinámica de spam en el mempool que afectó a Ethereum durante periodos de acuñaciones de NFT con tarifas altas o actividad de bots de arbitraje. Sin embargo, EIP-8141 hace el ataque más barato de sostener, porque el adversario solo necesita generar transacciones que lleguen a la validación, no transacciones que sean incluidas on-chain. Como las transacciones fallan la validación, no conllevan costo de inclusión para el atacante más allá del gas por validación consumido — que es exactamente el recurso que el protocolo intenta acotar.

Lo que los hallazgos podrían significar para los clientes de Ethereum y los operadores de nodos

El benchmark establece un camino creíble hacia un tope de 300,000 gas — suficientemente alto para soportar transacciones de privacidad Groth16, pero no las variantes de SPHINCS+ más costosas — siempre que cada cliente principal de Ethereum implemente la protección de prioridad al procesamiento de bloques. Este es un requisito de coordinación, no una regla del protocolo: el propio EIP no obliga al comportamiento del cliente y solo fija el techo de gas. Si una minoría de nodos se despliega sin la protección, esos nodos se convierten en objetivos desproporcionados durante una avalancha. Esa carga de coordinación se ve amplificada por la arquitectura multicliente de Ethereum, en la que varios equipos independientes mantienen el software de nodos y el comportamiento de toda la red depende de que cada implementación incorpore protecciones equivalentes.

Para los operadores de nodos con hardware en el extremo inferior del rango probado por el benchmark — una máquina de un solo núcleo con ancho de banda de memoria limitado — el resultado del 12% de admisión de transacciones honestas bajo condiciones de avalancha significa que las transacciones frame pueden volverse efectivamente poco confiables durante periodos de congestión adversaria, incluso en un cliente completamente actualizado. Esto importa principalmente para las aplicaciones que dependen de una admisión rápida en el mempool, como los flujos de transacciones privadas sensibles al tiempo o los protocolos de coordinación de firmas umbral. Los diseñadores de protocolos que construyan sobre EIP-8141 deberían incorporar las condiciones adversarias del mempool en sus supuestos de liveness, de la misma manera que los protocolos DeFi como Aave tratan el riesgo de latencia de liquidación como una función de la congestión de la red y no como una constante.

El benchmark no evalúa topes superiores a 300,000 gas como viables bajo el diseño de protección actual con 100 transacciones fallidas por segundo. Alcanzar el techo de 500,000 gas — que acomodaría las variantes de SPHINCS+ más pesadas — requeriría un rate-limiting más fuerte en la capa de propagación de transacciones, filtrado de spam basado en stake, o un supuesto de tasa de avalancha base más bajo. Cada una de estas opciones implica complejidad adicional del protocolo y coordinación entre clientes más allá de lo que especifica el borrador actual de EIP-8141.

Estado de borrador y preguntas abiertas

EIP-8141 sigue en estado Draft, y los hallazgos del benchmark alimentan directamente la discusión en curso sobre parámetros en lugar de resolverla. Bajo el proceso de EIP, las propuestas en etapa Draft aún pasan por Review y Last Call antes de alcanzar el estado Final, dejando parámetros como MAX_VERIFY_GAS abiertos a revisión con base precisamente en este tipo de aportes de investigación. Los desarrolladores de clientes y los autores del EIP deberán sopesar el costo de admisión honesta del tope de 300,000 gas frente a los casos de uso criptográficos que requieren presupuestos más altos, y determinar si la protección de prioridad al procesamiento de bloques es suficiente como mitigación independiente o si caben mecanismos adicionales de resistencia al spam en la propuesta core.

La cifra de admisión del 12% en la máquina más lenta probablemente será un punto focal de esa discusión: un protocolo que admite menos de una de cada ocho transacciones honestas bajo una avalancha moderada ofrece garantías de liveness materialmente más débiles que el mempool actual, incluso si la finalidad de los bloques no se ve afectada. El hilo del foro de Ethereum Research y el pull request abierto de Nethermind son los dos espacios documentados donde esa evaluación continuará desarrollándose.