Cifrado por transacción para combatir el MEV malicioso

Los ataques maliciosos de MEV representan una amenaza significativa para los traders en Ethereum. Nuestra última investigación revela que se producen casi 2,000 ataques tipo «sandwich» diariamente, y se extraen más de 2 millones de dólares de la red cada mes. Incluso los traders que realizan intercambios grandes de WETH, WBTC o stablecoins están en riesgo y pueden perder una porción considerable de sus operaciones.

El MEV prospera gracias a la naturaleza transparente de las blockchains, donde los datos de las transacciones son visibles antes de que sean ejecutadas y finalizadas. Una vía para mitigar el MEV es la encriptación del mempool, especialmente mediante el uso de encriptación de umbral. En artículos anteriores, examinamos dos modelos diferentes para mempools encriptados con umbral. Shutter, uno de los primeros proyectos en aplicar la encriptación de umbral para proteger el mempool, introdujo una configuración por época. La encriptación de umbral por lotes (BTE), un modelo más reciente, desencripta múltiples transacciones con una sola clave para reducir costos de comunicación y aumentar la capacidad de procesamiento.

En este artículo, analizamos Flash Freezing Flash Boys (F3B) de H. Zhang et al. (2022), un nuevo diseño de encriptación de umbral que aplica encriptación en base a cada transacción. Exploramos su mecánica, explicamos sus propiedades de escalado en relación con la latencia y la memoria, y discutimos las razones por las que aún no se ha desplegado en la práctica.

Cómo Flash Freezing Flash Boys implementa encriptación por transacción

Flash Freezing Flash Boys aborda las limitaciones de los primeros sistemas de encriptación de umbral que dependían de configuraciones por épocas. Proyectos como FairBlock y las versiones iniciales de Shutter utilizaban una única clave para encriptar cada transacción dentro de una época seleccionada. Una época es un número fijo de bloques, por ejemplo, 32 bloques en Ethereum. Esto generó vulnerabilidades, ya que algunas transacciones que no lograban ser incluidas en el bloque especificado eran desencriptadas junto con el resto del lote. Esto exponía datos sensibles y abría oportunidades de MEV para los validadores, haciéndolos vulnerables a ataques de front-running.

F3B aplica la encriptación de umbral de manera individual por transacción, garantizando que cada transacción se mantenga confidencial hasta llegar a la finalización. El flujo general del protocolo F3B es el siguiente: el usuario encripta la transacción con una clave a la que solo el comité de umbral designado, conocido como el Comité de Gestión Secreta (SMC), puede acceder. El texto cifrado de la transacción y la clave encriptada se envían al grupo de consenso como un par (Paso 1). De este modo, los nodos pueden almacenar y ordenar transacciones mientras conservan toda la metadata de descifrado necesaria para la reconstrucción y ejecución rápida posterior a la finalización. Mientras tanto, el SMC prepara sus comparticiones de desencriptación, pero las retiene hasta que el consenso confirme la transacción (Paso 2). Una vez que una transacción se finaliza y el SMC libera suficientes comparticiones válidas (Paso 3), el grupo de consenso desencripta la transacción y la ejecuta (Paso 4).

La encriptación por transacción había permanecido impráctica durante mucho tiempo debido a su alto costo computacional tanto para encriptar como para desencriptar, así como los requisitos de almacenamiento derivados de grandes cargas útiles encriptadas. F3B aborda esto encriptando solo una clave simétrica ligera en lugar de toda la transacción. La transacción misma se encripta con esta clave simétrica, lo que puede reducir la cantidad de datos que necesitan ser encriptados asimétricamente en hasta un 90% para una transacción de intercambio simple.

Comparación de diferentes implementaciones criptográficas de F3B y su sobrecarga de latencia

Flash Freezing Flash Boys se puede implementar con uno de dos protocolos criptográficos: TDH2 o PVSS. La diferencia radica en quién asume la carga de configuración y con qué frecuencia se fija la estructura del comité, de acuerdo con las ventajas y desventajas en flexibilidad, latencia y sobrecarga de almacenamiento.

TDH2 (Threshold Diffie-Hellman 2) se basa en un comité que realiza un proceso de generación de clave distribuida (DKG) para producir comparticiones de clave individuales junto con una clave pública colectiva. Luego, un usuario crea una nueva clave simétrica, encripta su transacción con ella y encripta esa clave simétrica con la clave pública del comité. El grupo de consenso registra este par encriptado en la cadena. Después de que la cadena alcanza el número requerido de confirmaciones, los miembros del comité publican desencriptaciones parciales de la clave simétrica encriptada junto con pruebas NIZK (Non-Interactive Zero-Knowledge), necesarias para prevenir ataques de texto cifrado elegido, donde los atacantes envían textos cifrados dañados para intentar engañar a los fideicomisarios y que filtren información durante la desencriptación. Las NIZK garantizan que el texto cifrado del usuario esté bien formado y sea desencriptable, y también que los fideicomisarios enviasen comparticiones de desencriptación correctas. El consenso verifica las pruebas y, una vez que se dispone de un umbral de comparticiones válidas, reconstruye y desencripta la clave simétrica, desencripta la transacción y la ejecuta.

El segundo esquema, PVSS (Publicly Verifiable Secret Sharing), sigue un camino diferente. En lugar de que el comité ejecute un DKG en cada época, cada miembro del comité posee una clave privada a largo plazo y una clave pública correspondiente, que se almacena en la blockchain y es accesible para cualquier usuario. Para cada transacción, los usuarios eligen un polinomio aleatorio y utilizan la compartición secreta de Shamir para generar comparticiones secretas, que luego son encriptadas para cada fideicomisario elegido utilizando la clave pública respectiva. La clave simétrica se obtiene mediante el hash del secreto reconstruido. Las comparticiones encriptadas están acompañadas por una prueba NIZK, que permite a cualquier persona verificar que todas las comparticiones se derivaron del mismo secreto, junto con un compromiso polinómico público, que es un registro que vincula la relación entre compartición y secreto. Los pasos posteriores de inclusión de transacción, liberación de comparticiones tras la finalización, reconstrucción de claves, desencriptación y ejecución son similares a los del esquema TDH2.

El protocolo TDH2 es más eficiente debido a un comité fijo y datos de encriptación de umbral de tamaño constante. PVSS, en cambio, proporciona más flexibilidad a los usuarios, ya que pueden seleccionar los miembros del comité responsables de su transacción. Sin embargo, esto conlleva un costo en forma de textos cifrados de clave pública más grandes y mayor carga computacional debido a la encriptación por fideicomisario. En un análisis más amplio, la implementación prototipo del protocolo F3B en un Ethereum de prueba con prueba de participación mostró que tiene una sobrecarga mínima en el rendimiento. Con un comité de 128 fideicomisarios, el retraso posterior a la finalización es de solo 197 ms para TDH2 y 205 ms para PVSS, lo que equivale al 0.026% y 0.027% del tiempo de finalización de 768 segundos de Ethereum. La sobrecarga de almacenamiento es de solo 80 bytes por transacción para TDH2, mientras que la sobrecarga de PVSS crece linealmente con el número de fideicomisarios debido a las comparticiones, pruebas y compromisos por miembro. Estos resultados confirman que F3B podría ofrecer sus garantías de privacidad con un impacto despreciable en el rendimiento y la capacidad de Ethereum.

Incentivos y castigos en el protocolo Flash Freezing Flash Boys

F3B incentiva el comportamiento honesto entre los fideicomisarios del Comité de Gestión Secreta a través de un mecanismo de staking con colaterales bloqueados. Las tarifas motivan a los fideicomisarios a estar en línea y mantener el nivel de rendimiento que el protocolo requiere. Un contrato inteligente de slashing asegura que, si alguien presenta prueba de una violación, que demuestre que la desencriptación se realizó de manera prematura, la participación del fideicomisario infractor se pierde. En TDH2, tal evidencia consiste en la compartición de desencriptación de un fideicomisario que se puede verificar públicamente en contra del texto cifrado de la transacción. Mientras tanto, en PVSS, las pruebas consisten en una compartición desencriptada junto con una prueba NIZK específica de fideicomisario que la autentica. Este mecanismo penaliza la divulgación prematura detectable de comparticiones de desencriptación, aumentando el costo del comportamiento indebido detectable. Sin embargo, no previene que los fideicomisarios coluden en privado fuera de la cadena para reconstruir y desencriptar datos de transacciones sin publicar comparticiones. Como resultado, el protocolo aún depende de la suposición de que la mayoría de los miembros del comité se comporten de manera honesta.

Dado que las transacciones encriptadas no se pueden ejecutar de inmediato, otro vector de ataque para un usuario malicioso es inundar la blockchain con transacciones no ejecutables para ralentizar los tiempos de confirmación. Esta es una superficie de ataque potencial común a todos los esquemas de mempool encriptado. F3B requiere que los usuarios realicen un depósito de almacenamiento para cada transacción encriptada, lo que hace que el spam sea costoso. El sistema deduce el depósito por adelantado y reembolsa solo una parte cuando la transacción se ejecuta con éxito.

Desafíos para desplegar F3B en Ethereum

Flash Freezing Flash Boys ofrece un enfoque criptográfico integral para mitigar el MEV, pero es poco probable que se implemente en el mundo real en Ethereum debido a la complejidad de su integración. Aunque F3B no altera el mecanismo de consenso y preserva la compatibilidad total con los contratos inteligentes existentes, requiere modificaciones en la capa de ejecución para soportar transacciones encriptadas y ejecuciones retrasadas. Esto requeriría un hard fork mucho más amplio que cualquier otra actualización introducida desde The Merge.

A pesar de ello, F3B representa un hito valioso en la investigación que va más allá de Ethereum. Su mecanismo minimizado de confianza para compartir datos de transacciones privadas puede aplicarse tanto a redes blockchain emergentes como a aplicaciones descentralizadas que requieren ejecuciones retrasadas. Protocolos al estilo de F3B pueden ser útiles incluso en blockchains con tiempos de bloque inferiores a un segundo, donde tiempos de bloque más bajos ya reducen significativamente el MEV, para eliminar completamente el front-running basado en el mempool. Como aplicación de ejemplo, F3B también podría usarse en un contrato inteligente de subasta sellada, donde los postores envían ofertas encriptadas que permanecen ocultas hasta que finaliza la fase de pujas. De este modo, las ofertas pueden ser reveladas y ejecutadas solo después de la fecha límite de la subasta, lo que previene la manipulación de ofertas, el front-running o la filtración temprana de información.