Sobre las limitaciones de los mempools cifrados

El valor que puede obtenerse mediante la inclusión, exclusión o reordenación de transacciones en un bloque se denomina “valor máximo extraíble” o MEV. El MEV está presente en la mayoría de las blockchains y ha suscitado un notable interés y debate en la comunidad.

Nota: Esta entrada asume conocimientos previos sobre MEV. Si lo desea, puede comenzar por leer nuestra introducción al MEV.

Numerosos investigadores, al analizar el fenómeno del MEV, han planteado una pregunta fundamental: ¿puede la criptografía resolver este problema? Una vía explorada es el mempool cifrado, en el que los usuarios transmiten transacciones encriptadas que solo se revelan una vez secuenciadas. Así, el protocolo de consenso debe comprometerse con un orden de transacciones sin conocer su contenido, lo que teóricamente impediría explotar oportunidades de MEV durante dicho proceso.

Sin embargo, por motivos tanto prácticos como teóricos, no consideramos que los mempools cifrados puedan resolver el MEV de forma universal. A continuación, detallamos las dificultades y analizamos cómo podrían diseñarse estos mempools cifrados.

Funcionamiento de los mempools cifrados

Se han planteado diversas propuestas de mempools cifrados, pero el marco general es el siguiente:

1. Los usuarios transmiten sus transacciones cifradas.
2. Las transacciones cifradas se registran en la cadena (en ciertos modelos, tras ser aleatorizadas de forma demostrada).
3. Una vez finalizado el bloque en el que se han incorporado, se descifran las transacciones.
4. Por último, se ejecutan las transacciones.

Debe señalarse que el paso 3 (descifrado de las transacciones) supone un reto crucial: ¿quién realiza dicho descifrado y qué ocurre si no se completa? Una solución ingenua sería permitir que los propios usuarios descifren sus transacciones (en ese caso, no haría falta cifrado, bastaría con ocultar los compromisos). Sin embargo, este planteamiento es vulnerable: un atacante podría ejecutar un MEV especulativo.

En el MEV especulativo, el atacante trata de adivinar que una transacción cifrada específica genera MEV. Cifra sus propias transacciones tratando de posicionarlas estratégicamente (por ejemplo, antes o después de la transacción objetivo). Si se logra el orden esperado, el atacante descifra su transacción y extrae el MEV; si no, simplemente no la descifra y queda excluida de la cadena final.

Podría contemplarse una penalización para quienes no descifren, pero su implementación es compleja. Dicha penalización debería ser igual para todas las transacciones cifradas (al no poder distinguirse entre ellas), pero lo suficientemente elevada para evitar el MEV especulativo incluso contra objetivos de gran valor. Esto supondría inmovilizar importantes sumas de capital, que además deberían ser anónimas (para evitar revelar la autoría de las transacciones). Además, podría perjudicar a usuarios legítimos en caso de errores o fallos de red que impidan el descifrado.

Por tanto, la mayoría de propuestas plantea que las transacciones se cifren de manera que el descifrado esté, en algún momento futuro, garantizado, aunque el usuario original no coopere o no esté en línea. Existen varios mecanismos para lograr esto:

TEEs: Los usuarios cifran sus transacciones con una clave mantenida por un enclave de Trusted Execution Environment (TEE). En versiones simples, el TEE solo se emplea para descifrar transacciones tras una fecha límite (lo que requiere una noción interna de tiempo). Los modelos más avanzados permiten que el TEE descifre y construya el bloque, ordenando las transacciones según criterios como el momento de llegada o la comisión ofrecida. La principal ventaja frente a otros enfoques es que pueden operar sobre transacciones en claro, filtrando las que revertirían y reduciendo el spam en la cadena. Sin embargo, este método exige confiar en el hardware.

Compartición secreta y cifrado umbral: En este enfoque, las transacciones se cifran para una clave compartida por un comité (habitualmente, un subconjunto de validadores). Se requiere alcanzar un umbral (por ejemplo, dos tercios) para descifrar.

La variante más sencilla emplea una nueva clave de descifrado compartida en cada ronda (p. ej., en cada bloque o epoch en Ethereum), que el comité reconstruye y publica tras ordenar las transacciones del bloque finalizado. Se trata de una compartición secreta básica. El principal inconveniente es que expone todas las transacciones del mempool, incluso las que no se incluyeron en el bloque, y exige una nueva generación distribuida de claves (DKG) en cada ronda.

Un enfoque más privado consiste en descifrar únicamente las transacciones realmente incluidas. Esto puede lograrse empleando descifrado umbral y permite amortizar el coste de los protocolos DKG, reutilizando la clave para múltiples bloques y realizando el descifrado umbral tras el ordenamiento en un bloque finalizado. El reto es el aumento de trabajo para el comité, ya que, de forma ingenua, el esfuerzo escala linealmente con el número de transacciones a descifrar, aunque recientes investigaciones proponen soluciones por lotes más eficientes.

En este modelo, la confianza deja de recaer en el hardware y se traslada a un comité. El argumento es que, como la mayoría de protocolos ya asume una mayoría honesta de validadores en el consenso, puede suponerse que la mayoría no descifrará antes de tiempo. No obstante, conviene ser cautos: no es un supuesto idéntico. Los fallos de consenso como los forks son públicos y detectables (confianza débil), mientras que un comité malicioso que descifrase en privado no dejaría rastro ni podría ser sancionado (confianza fuerte). Así, aunque externamente parezca la misma hipótesis, en la práctica es más arriesgado.

Cifrado por retardo y encriptado temporal: Una alternativa es el cifrado con retardo. En este modelo, los usuarios cifran sus transacciones para una clave pública cuyo secreto está oculto en un rompecabezas criptográfico dependiente del tiempo. Solo puede resolverse tras un periodo computacional predeterminado realizando cálculos secuenciales no paralelizables. Cualquiera puede abrir el rompecabezas y descifrar las transacciones, pero sólo una vez transcurrido el tiempo suficiente para haber finalizado el bloque. El modelo más robusto emplea cifrado por retardo para generar el rompecabezas; también puede implementarse usando un comité confiable, si bien sus ventajas frente al cifrado umbral son entonces discutibles.

Sea mediante cifrado por retardo o mediante cómputo de un comité, existen desafíos prácticos: primero, la dificultad para controlar el momento exacto de descifrado, ya que el tiempo depende de lo computacional. Segundo, el sistema exige que una entidad resuelva eficientemente los rompecabezas mediante hardware especializado; aunque cualquiera puede hacerlo, existen dudas sobre cómo incentivar esta labor. Por último, en estos diseños todas las transacciones difundidas acabarán descifradas, incluso aquellas que no se incluyeron en bloque. Las soluciones umbral (o vía witness encryption) podrían limitar el descifrado a las efectivamente incluidas.

Witness encryption. El enfoque más avanzado emplea la llamada witness encryption. En teoría, permite cifrar datos de manera que sólo quien conoce un testigo de una relación NP concreta puede descifrarlos. Por ejemplo, solo podría descifrarse quien resuelva un Sudoku concreto o disponga de la preimagen de un hash dado.

Esto se puede pensar también como cifrado a quien sea capaz de generar un SNARK que demuestre una condición específica. En mempools cifrados, una restricción típica sería que sólo puedan descifrarse las transacciones cuando se haya finalizado un bloque.

Esta primitiva teórica es sumamente potente; de hecho, generaliza soluciones de comité y de retardo como casos particulares. Sin embargo, actualmente no existen implementaciones prácticas. Y, aun en caso de existir, no queda claro que mejorasen los esquemas de comité en cadenas proof-of-stake: un comité malicioso podría simular en privado el consenso, considerar finalizada la cadena, y emplear ese “testigo” para descifrar las transacciones. En tal situación, el descifrado umbral por el propio comité es igual de seguro y mucho más sencillo.

Witness encryption aporta una ventaja diferenciadora en redes proof-of-work, ya que ni siquiera un comité totalmente malicioso puede minar privadamente varios bloques extra para forzar la finalidad.

Retos técnicos para los mempools cifrados

Existen varios desafíos prácticos que limitan la capacidad de los mempools cifrados para frenar el MEV. En general, salvaguardar la confidencialidad es complicado. Paradójicamente, el cifrado suele emplearse poco en el ecosistema web3, pese a décadas de experiencia práctica que muestran las dificultades de su despliegue, tanto en la web (TLS/HTTPS) como en comunicaciones privadas (de PGP a Signal o WhatsApp). Aunque el cifrado ayuda a preservar la confidencialidad, no la garantiza plenamente.

Por ejemplo, puede haber agentes con acceso directo al texto plano de la transacción. Normalmente, el usuario no cifra por sí mismo sus transacciones, sino que delega en el proveedor de wallet, que tiene acceso al dato y podría emplearlo o venderlo para extraer MEV. El cifrado nunca protege más allá de los titulares de la clave.

El mayor reto viene de la metadata, es decir, los datos que rodean la transacción cifrada y permanecen sin cifrar. Los searchers pueden analizar esta metadata para deducir la intención y tratar de extraer MEV especulativo. Esto les basta incluso sin comprender la transacción completamente ni acertar siempre; por ejemplo, si con cierta probabilidad una transacción representa una orden de compra en una DEX concreta.

Pueden distinguirse varios tipos de metadata, algunos clásicos y otros propios de los mempools cifrados.

• Tamaño de la transacción: El cifrado estándar no oculta el tamaño del mensaje original. (De hecho, las definiciones formales de seguridad semántica suelen exceptuar el tamaño). Es un vector clásico de ataque en comunicaciones cifradas. (Por ejemplo, un tercero puede identificar en tiempo real el vídeo reproducido en Netflix sólo por el tamaño de los paquetes). En mempools cifrados, ciertas operaciones pueden tener tamaños característicos que revelan información.

• Momento de difusión: El cifrado tampoco oculta el instante de emisión (otro vector clásico de ataque). En web3, ciertos emisores —por ejemplo, ventas programadas— pueden operar a intervalos regulares. El timing puede correlacionarse con actividad en exchanges o eventos externos. De forma más sutil, un secuenciador puede aprovechar el arbitrage CEX/DEX insertando su transacción tan tarde como sea posible, excluyendo otras (incluso cifradas) y asegurando el acceso al precio actualizado.

• Dirección IP de origen: Los searchers pueden inferir la identidad del emisor observando la red y la IP de origen. Este problema se identificó hace años en los inicios de Bitcoin. Esto permite relacionar transacciones cifradas con emisores concretos y con su historial.

• Remitente y datos de comisión/gas: Por último, las comisiones son un tipo de metadata propia de mempools cifrados. En Ethereum, la transacción incluye una dirección de remitente (que paga), así como un límite de gas y el precio aceptado por unidad. La dirección y el gas permiten vincular transacciones entre sí y con actores reales. El límite de gas puede indicar el tipo de operación subyacente.

Los searchers más sofisticados pueden combinar toda esta metadata para predecir el contenido de las transacciones.

Ocultar esta información es posible, pero implica coste y complejidad. Por ejemplo, rellenar las transacciones hasta un tamaño estándar oculta el tamaño real, pero derrocha ancho de banda y espacio en la cadena. Retrasar la difusión esconde el momento, pero aumenta la latencia. Enviar transacciones por redes de anonimato como Tor puede ocultar la IP, aunque con limitaciones propias.

La metadata más difícil de ocultar es la relativa a las comisiones. Encriptarla plantea retos importantes para los constructores. El primer problema es el spam: si los datos de comisión están cifrados, cualquiera puede emitir transacciones cifradas inválidas que serán ordenadas, pero no ejecutables ni penalizables tras el descifrado. Podría aliviarse mediante SNARKs que prueben la validez y financiación de la transacción, pero el coste sería elevado.

El segundo problema concierne a la construcción eficiente de bloques y las subastas de comisiones. Los constructores dependen de las comisiones para maximizar las ganancias y fijar precios en la cadena. Cifrar estos datos distorsiona ese proceso. Una posible solución sería fijar una comisión plana por bloque, pero resultaría ineficiente y fomentaría mercados secundarios de inclusión de transacciones, contrariando el objetivo del mempool cifrado. Las subastas de comisiones mediante cómputo multipartito seguro o hardware confiable son posibles, pero costosas.

Por último, los mempools cifrados generan sobrecostes de varios tipos. El cifrado añade latencia, carga computacional y de ancho de banda. Su integración con técnicas como el sharding o la ejecución paralela (claves para el futuro) es especialmente difícil. Se podrían crear puntos adicionales de fallo para la disponibilidad (por ejemplo, el comité encargado del descifrado en soluciones umbral, o el solucionador de la función de retardo) y, en todo caso, la complejidad de diseño y desarrollo aumenta.

Muchos de estos problemas también afectan a blockchains que buscan privacidad transaccional (por ejemplo, Zcash o Monero). La posible ventaja es que abordar los retos del cifrado para mitigar el MEV serviría, de paso, para allanar el camino hacia la privacidad en las transacciones.

Retos económicos de los mempools cifrados

Los mempools cifrados afrontan retos de tipo económico. A diferencia de los desafíos técnicos —que podrían resolverse con suficiente ingeniería—, estas limitaciones parecen difíciles de salvar.

El origen del MEV está en la asimetría de información entre los usuarios que generan transacciones y los searchers/constructores que identifican oportunidades de MEV. Normalmente, los usuarios desconocen el valor extraíble de sus propias transacciones, por lo que, incluso con un mempool cifrado perfecto, podrían verse tentados a revelar sus claves de descifrado a los constructores a cambio de un pago inferior al valor real extraído. A esto lo denominamos descifrado incentivado.

Este escenario ya existe en la práctica: MEV Share. MEV Share es una subasta de flujo de órdenes en la que los usuarios pueden enviar información selectiva sobre sus transacciones a un pool donde los searchers compiten por aprovechar la oportunidad de MEV de la transacción. El searcher adjudicatario extrae el MEV y transfiere parte de ese beneficio al usuario (la puja o una fracción de ésta).

Este modelo podría emplearse inmediatamente en el contexto de mempools cifrados, exigiendo a los usuarios revelar sus claves de descifrado (o parte de la información) para participar. Sin embargo, la mayoría de usuarios ignorará el coste de oportunidad de esta cesión y solo valorará la recompensa, sin dudar en compartir la información. Existen casos similares en las finanzas tradicionales (por ejemplo, servicios de trading sin comisiones como Robinhood) que obtienen ingresos vendiendo el flujo de órdenes de sus clientes a terceros, bajo el modelo de “pago por flujo de órdenes”.

También es posible que grandes constructores exijan a los usuarios revelar sus transacciones (o parte de los datos) por razones de censura. La resiliencia frente a la censura es un asunto central y polémico en web3, pero si grandes proponentes o constructores están legalmente obligados a mantener listas de censura (por ejemplo, por OFAC), pueden negarse a secuenciar transacciones cifradas. Quizá sería posible resolverlo si los usuarios pudieran aportar pruebas de conocimiento cero demostrando que su transacción cumple las restricciones, pero esto encarecería y complicaría el proceso. Incluso en redes muy resistentes a la censura, donde queda garantizada la inclusión de transacciones cifradas, los constructores seguirían dando prioridad a transacciones en claro y dejando a las cifradas al final del bloque. Así, quienes requieran ciertas garantías de ejecución podrían verse obligados a revelar información a los constructores.

Otros desafíos de eficiencia

Los mempools cifrados suponen una carga adicional para el sistema: los usuarios deben cifrar sus transacciones y el sistema debe descifrarlas. Esto genera costes computacionales y puede aumentar el tamaño de las transacciones. Además, como se comentó arriba, la gestión de la metadata puede incrementar esta sobrecarga. Pero existen otros costes menos evidentes: en mercados financieros, la eficiencia se define como la capacidad para reflejar toda la información en el precio; los retrasos y asimetrías, propios de los mempools cifrados, generan ineficiencias.

Uno de los efectos colaterales es la mayor incertidumbre de precios, causada por el retraso adicional que introduce el mempool cifrado. Esto puede incrementar el número de operaciones fallidas por superar la tolerancia de slippage, desperdiciando espacio en la cadena.

Igualmente, esta incertidumbre incentiva la aparición de operaciones MEV especulativas que buscan el arbitraje on-chain. Estas operaciones podrían volverse más frecuentes con mempools cifrados, ya que la mayor incertidumbre sobre el estado de los DEX, derivada del retraso en la ejecución, puede generar mercados menos eficientes y con mayores discrepancias de precios entre plataformas. Además, estos intentos de arbitraje suelen acabar en operaciones abortadas, desperdiciando espacio en bloque.

Aunque aquí hemos querido resaltar los retos de los mempools cifrados para enfocar el esfuerzo en posibles soluciones alternativas, estos pueden formar parte de la respuesta frente al MEV.

Una opción es el diseño híbrido, donde parte de las transacciones se ordenan a ciegas mediante mempool cifrado y parte bajo otros mecanismos. Para operaciones concretas —por ejemplo, órdenes de compraventa de grandes actores que pueden cifrarlas y padearlas cuidadosamente, y que están dispuestos a pagar más para evitar el MEV— pueden resultar idóneos. También pueden ser apropiados para transacciones altamente sensibles, como correcciones de vulnerabilidades críticas en contratos inteligentes.

No obstante, debido a limitaciones tecnológicas, complejidad de desarrollo y sobrecostes de rendimiento, es poco probable que los mempools cifrados sean la solución definitiva frente al MEV que a veces se sugiere. La comunidad debe avanzar en otras propuestas, como subastas MEV, defensas a nivel de aplicación y reducción del tiempo de finalización. El MEV continuará siendo un reto y será necesario seguir investigando para lograr el equilibrio óptimo en cada caso.

Pranav Garimidi es investigador asociado en a16z Crypto y estudia problemas de diseño de mecanismos y teoría algorítmica de juegos aplicados a sistemas blockchain, con especial interés en la interacción de incentivos a lo largo de la pila blockchain. Antes de incorporarse a a16z, fue estudiante en la Universidad de Columbia y se graduó en Informática.

Joseph Bonneau es profesor titular en el Departamento de Informática del Courant Institute (Universidad de Nueva York) y asesor técnico de a16z crypto. Sus investigaciones se centran en la criptografía aplicada y la seguridad blockchain. Ha impartido cursos sobre criptomonedas en la Universidad de Melbourne, NYU, Stanford y Princeton, es doctor por la Universidad de Cambridge y máster/licenciado por Stanford.

Lioba Heimbach es doctoranda de cuarto año bajo la supervisión del Prof. Dr. Roger Wattenhofer en el grupo de Computación Distribuida (Disco) de ETH Zúrich. Su trabajo se centra en protocolos blockchain y, en concreto, en el desarrollo de ecosistemas DeFi accesibles, descentralizados, justos y eficientes. En verano de 2024 realizó una estancia investigadora en a16z crypto.

Las opiniones expresadas pertenecen exclusivamente a los profesionales de AH Capital Management, L.L.C. (“a16z”) mencionados y no representan necesariamente las de a16z ni las de sus filiales. Cierta información proviene de terceros, incluidas empresas participadas por fondos gestionados por a16z. Si bien se considera fiable, a16z no la ha verificado de forma independiente ni garantiza su actualidad o idoneidad. El contenido puede incluir publicidad de terceros; a16z no la revisa ni la respalda.

Este contenido se facilita solo con fines informativos y no debe entenderse como asesoramiento legal, financiero, fiscal ni de inversión. Consulte a sus propios asesores para estas materias. Cualquier referencia a valores o activos digitales es meramente ilustrativa y no supone recomendación de inversión ni oferta de servicios de asesoramiento. Este contenido no está dirigido a inversores ni potenciales inversores y no puede emplearse en ninguna decisión de inversión en fondos gestionados por a16z. (Cualquier oferta de inversión en fondos de a16z se realizará solo mediante el folleto, acuerdo de suscripción y documentación pertinente, que deberán leerse íntegramente.) Las inversiones o empresas citadas no son representativas de todas las inversiones gestionadas por a16z, ni cabe asegurar resultados futuros similares. Puede consultarse el listado de inversiones de Andreessen Horowitz (exceptuando las no autorizadas públicamente y las aún no anunciadas en activos digitales cotizados) en https://a16z.com/investments/.

Este contenido es válido únicamente a la fecha indicada. Cualquier previsión, estimación, objetivo, perspectiva u opinión aquí recogida puede modificarse sin previo aviso y diferir o contradecir puntos de vista de otras fuentes. Consulte https://a16z.com/disclosures para información adicional relevante.

Aviso legal:

1. Este artículo se ha reproducido de [a16zcrypto]. Todos los derechos de autor pertenecen a los autores originales [Pranav GarimidiJoseph BonneauLioba Heimbach]. Si tiene alguna objeción a la reproducción, contacte con el equipo de Gate Learn y se atenderá a la mayor brevedad.
2. Descargo de responsabilidad: Los puntos de vista y opiniones presentados en este artículo son únicamente del autor y no constituyen asesoramiento de inversión.
3. Las traducciones a otros idiomas han sido realizadas por el equipo de Gate Learn. Salvo indicación en contrario, queda prohibida la copia, distribución o plagio de los artículos traducidos.