Angela TrenardEIP-8105: Cómo Ethereum planea eliminar los ataques sandwich con un mempool encriptado a nivel de protocolo
La propuesta Universal Enshrined Encrypted Mempool busca proteger a los usuarios de pérdidas anuales estimadas en $60 millones por MEV malicioso, mediante un diseño flexible que soporta múltiples tecnologías de encriptación.
Los ataques sandwich, que aprovechan la visibilidad pública de las transacciones en el mempool de Ethereum, cuestan a los usuarios aproximadamente $60 millones anuales. La propuesta EIP-8105, conocida como Universal Enshrined Encrypted Mempool, introduce un sistema de encriptación a nivel de protocolo que permitiría ocultar el contenido de las transacciones hasta su inclusión en un bloque. El diseño, de naturaleza agnóstica, soporta múltiples métodos de encriptación como threshold encryption, entornos de ejecución confiables (TEEs) o computación totalmente homomórfica (FHE).
El Problema del Mempool Público y los Ataques Sandwich
¿Cómo funcionan los ataques sandwich?
El mempool de Ethereum es un espacio público donde las transacciones pendientes de confirmación son visibles para todos los participantes de la red. Los bots de valor extraíble de mineros (MEV) monitorean constantemente este espacio en busca de oportunidades de lucro.
El mecanismo del ataque sandwich opera en tres pasos. Primero, el bot detecta una transacción grande pendiente en el mempool, por ejemplo, una compra significativa de un token. Segundo, el bot coloca una transacción de compra justo antes de la transacción objetivo, lo que eleva el precio. Tercero, inmediatamente después de ejecutarse la transacción original, el bot vende los tokens adquiridos a un precio más alto, obteniendo ganancias a expensas del usuario original.
Este tipo de extracción de valor, conocida como MEV malicioso, genera pérdidas estimadas en $60 millones anuales para los usuarios de Ethereum, según cálculos basados en investigaciones del ecosistema.
Intentos previos de mitigación
La comunidad de Ethereum ha debatido durante años la necesidad de implementar soluciones contra el MEV dañino a nivel de protocolo, sin que hasta ahora se haya concretado una implementación oficial. En paralelo, han surgido soluciones fuera del protocolo que buscan mitigar el problema.
Entre las propuestas más destacadas se encuentran Shutter, un sistema de threshold encryption para proteger transacciones; Batched Threshold Encryption, que agrupa transacciones en lotes encriptados; y Flash Freezing Flash Boys, un enfoque que congela temporalmente las transacciones para dificultar la extracción de MEV. Sin embargo, estas soluciones han enfrentado limitaciones técnicas y de adopción, principalmente porque operan por fuera del núcleo del protocolo de Ethereum.
¿Qué es EIP-8105? Universal Enshrined Encrypted Mempool
Diseño agnóstico de encriptación
La característica central de EIP-8105 es su flexibilidad tecnológica. A diferencia de propuestas anteriores que se limitaban a un único método de encriptación, la Universal Enshrined Encrypted Mempool está diseñada para soportar múltiples enfoques.
Entre los métodos compatibles se incluyen: threshold encryption, que divide una clave entre múltiples partes; comités de computación multiparte (MPC); entornos de ejecución confiables (TEEs), como los chips de hardware seguros; delay encryption, que retrasa la desencriptación por un período fijo; y computación totalmente homomórfica (FHE), que permite operar sobre datos encriptados sin desencriptarlos.
Esta arquitectura modular permite que el sistema evolucione y adopte nuevas tecnologías de encriptación a medida que estas maduran.
El Key Provider Registry
Un componente fundamental de la propuesta es el Key Provider Registry, un nuevo contrato del sistema implementado en la capa de ejecución de Ethereum. Este registro permite a cualquier cuenta registrarse como proveedor de claves, utilizando su tecnología de encriptación preferida.
Cada proveedor de claves es responsable de publicar sus claves de desencriptación en el momento adecuado, así como de revelar información cuando sea necesario. El sistema no impone un método de encriptación único, sino que delega en los proveedores la elección de la tecnología que mejor se adapte a sus capacidades y necesidades.
Flujo de Ejecución de Transacciones en EIP-8105
Nuevos tipos de transacción
EIP-8105 introduce dos nuevos tipos de transacción en Ethereum. El tipo 0x05 corresponde a transacciones encriptadas, que incluyen un envelope con el payload encriptado y un payload público. El tipo 0x06 corresponde a transacciones desencriptadas, es decir, aquellas que ya han sido reveladas y están listas para su ejecución.
El envelope de una transacción tipo 0x05 contiene varios componentes esenciales: un nonce para prevenir ataques de repetición, el monto de gas asignado, parámetros de gas price, un identificador del proveedor de claves (key provider ID), un identificador de clave (key ID) y la firma de la transacción.
Flujo de dos pasos
El proceso de ejecución de una transacción encriptada se desarrolla en dos etapas claramente diferenciadas. En el primer paso, llamado «inclusión del envelope», la transacción encriptada se incluye en un bloque con el payload oculto. En este punto, los validadores pueden verificar la validez básica de la transacción sin conocer su contenido real.
El segundo paso, denominado «revelación y ejecución», implica la intervención de los proveedores de claves. Estos monitorean las transacciones encriptadas que han sido incluidas en la blockchain y publican las claves de desencriptación correspondientes. En caso de que no puedan o no deseen revelar una clave, deben emitir un «withhold notice» (aviso de retención).
El Payload Timeliness Committee (PTC)
Para garantizar que los proveedores de claves cumplan con su función de manera oportuna, la propuesta crea el Payload Timeliness Committee (PTC). Este comité tiene la responsabilidad de monitorear y validar la publicación de las claves de desencriptación.
El PTC atestigua si una clave válida estuvo presente o ausente en el momento requerido, proporcionando un mecanismo de verificación y accountability. Este sistema de supervisión es esencial para mantener la integridad del proceso y evitar que los proveedores de claves actúen de manera fraudulenta o negligente.
Manejo de fallos
El diseño de EIP-8105 contempla escenarios en los que la desencriptación no es exitosa. Si la clave está disponible y la desencriptación se completa con éxito, la transacción se ejecuta en el siguiente bloque. Sin embargo, si la clave falta, se retiene o la desencriptación falla, el payload se omite y no se ejecuta.
En estos casos, el envelope de la transacción permanece incluido en el bloque y la tarifa de gas se paga igualmente. Este mecanismo incentiva a los usuarios a seleccionar proveedores de claves confiables y disuade comportamientos maliciosos por parte de los proveedores.
Estructura de Bloque y Prevención de MEV
Ordenamiento de transacciones en el bloque
EIP-8105 propone una estructura de bloque con tres zonas diferenciadas para el ordenamiento de las transacciones. Al inicio del bloque se colocan las transacciones desencriptadas (tipo 0x06). En la sección media se ubican las transacciones en texto plano, es decir, las que no utilizan encriptación. Al final del bloque se sitúan las transacciones encriptadas (tipo 0x05).
Este ordenamiento tiene implicaciones importantes para la prevención del MEV, ya que las transacciones encriptadas se revelan y ejecutan solo después de haber sido incluidas en un bloque, eliminando la ventana de oportunidad para los bots que monitorean el mempool.
Mecanismo anti-MEV
El diseño de EIP-8105 previene la inserción de transacciones MEV en la ventana entre la desencriptación y la ejecución. Como las transacciones encriptadas solo se revelan después de su inclusión en el bloque, los atacantes no pueden conocer su contenido ni adelantarse a ellas.
Esta garantía es fundamental para eliminar los ataques sandwich, ya que el momento de la desencriptación ocurre demasiado tarde para que los bots puedan reaccionar y extraer valor de la transacción.
Limitaciones del diseño
A pesar de sus ventajas, el diseño de EIP-8105 presenta limitaciones. Los proveedores de claves que aparecen antes en el bloque retienen una capacidad limitada de extraer MEV, ya que conocen el contenido de las transacciones que han encriptado y podrían potencialmente adelantarse a ellas.
Para mitigar este riesgo, la propuesta introduce un mecanismo basado en la designación de proveedores de confianza. El ordenamiento de las transacciones en el bloque se basa en un «key provider trust graph» (gráfico de confianza de proveedores de claves), que prioriza a aquellos proveedores considerados más confiables por la red.
Estado Actual y Futuro en el Roadmap de Ethereum
Importancia creciente de los mempools encriptados
La protección contra el MEV malicioso se ha convertido en una prioridad cada vez más relevante dentro del roadmap de desarrollo de Ethereum. La comunidad reconoce que los mempools encriptados son una herramienta esencial para mejorar la equidad y la seguridad de la red, protegiendo a los usuarios de prácticas extractivas.
La búsqueda de soluciones a nivel de protocolo para el MEV dañino refleja un cambio en la estrategia de Ethereum, que durante años dependió de soluciones externas para mitigar este problema.
Estado de EIP-8105
Actualmente, la propuesta EIP-8105 ya no es considerada la opción principal para el primer hard fork de 2027, según informan fuentes del ecosistema. Sin embargo, la propuesta permanece como un borrador abierto (open draft) que continúa siendo evaluado y discutido por la comunidad de desarrolladores.
Las ideas contenidas en EIP-8105 siguen informando el esfuerzo más amplio para preparar una propuesta líder de mempool encriptado para Ethereum. Aunque su implementación podría retrasarse, los conceptos fundamentales que introduce —como el diseño agnóstico de encriptación, el Key Provider Registry y el Payload Timeliness Committee— probablemente influirán en el desarrollo futuro de soluciones contra el MEV en la red.
