Autor | Pranav Garimidi, Joseph Bonneau, Lioba Heimbach, a16z
Compilado | Saoirse, Foresight News
En la blockchain, ganar dinero a través de decidir qué transacciones empaquetar en un bloque, cuáles excluir, o ajustar el orden de las transacciones, se conoce como "valor máximo extraíble", abreviado como MEV. El MEV es común en la mayoría de las blockchains y ha sido un tema de amplia atención y discusión en la industria.
Numerosos investigadores, al observar el fenómeno MEV, han planteado una pregunta clara: ¿puede la tecnología criptográfica resolver este problema? Una de las soluciones es utilizar un pool de memoria encriptada: los usuarios transmiten transacciones encriptadas, las cuales solo se desencriptan y revelan una vez que se completa el ordenamiento. De este modo, el protocolo de consenso debe "seleccionar ciegamente" el orden de las transacciones, lo que parece prevenir la obtención de ganancias a través de oportunidades MEV durante la fase de ordenamiento.
Pero, lamentablemente, tanto desde el punto de vista práctico como teórico, las memorias criptográficas no pueden proporcionar una solución general al problema de MEV. Este artículo explicará las dificultades involucradas y explorará las direcciones de diseño viables para las memorias criptográficas.
Cómo funciona el pool de memoria criptográfica
Hay muchas propuestas sobre el pool de memoria criptográfica, pero su marco general es el siguiente:
El usuario transmite la transacción encriptada.
Las transacciones de criptomonedas se envían a la cadena (en algunas propuestas, las transacciones deben pasar primero por un barajado aleatorio verificable).
Cuando el bloque que contiene estas transacciones se confirma finalmente, las transacciones se descifran.
Finalmente, ejecuta estas transacciones.
Es importante tener en cuenta que en el paso 3 (desencriptación de transacciones) hay un problema clave: ¿quién es responsable de la desencriptación? ¿Qué sucede si la desencriptación no se completa? Una idea sencilla es permitir que los usuarios desencripten sus propias transacciones (en este caso, incluso no sería necesaria la encriptación, solo ocultar el compromiso sería suficiente). Pero este enfoque tiene una vulnerabilidad: los atacantes podrían llevar a cabo MEV especulativo.
En el MEV especulativo, los atacantes intentan adivinar si una transacción de criptomonedas contiene oportunidades de MEV, luego encriptan su transacción y tratan de insertarla en una posición favorable (por ejemplo, antes o después de la transacción objetivo). Si las transacciones están dispuestas en el orden esperado, el atacante puede desencriptar y extraer MEV a través de su propia transacción; si no se cumple la expectativa, rechazarán desencriptar y su transacción no será incluida en la cadena de bloques final.
Quizás se podría imponer una sanción a los usuarios que fallan al descifrar, pero la implementación de este mecanismo es extremadamente difícil. La razón es que: la severidad de las sanciones para todas las transacciones cifradas debe ser uniforme (después de todo, no se puede distinguir entre transacciones una vez cifradas), y las sanciones deben ser lo suficientemente severas como para frenar el MEV especulativo incluso frente a objetivos de alto valor. Esto resultaría en una gran cantidad de fondos bloqueados, y esos fondos deben mantenerse en el anonimato (para evitar la divulgación de la relación entre las transacciones y los usuarios). Más complicado aún, si debido a un error de programación o a una falla de la red, los usuarios reales no pueden descifrar correctamente, también sufrirán pérdidas.
Por lo tanto, la mayoría de las soluciones sugieren que al cifrar las transacciones, se debe asegurar que en algún momento futuro se puedan descifrar, incluso si el usuario que inició la transacción está fuera de línea o se niega a cooperar. Este objetivo se puede lograr de las siguientes maneras:
Entornos de Ejecución Confiables (TEE): Los usuarios pueden cifrar transacciones con una clave almacenada en la zona segura del Entorno de Ejecución Confiable (TEE). En algunas versiones básicas, el TEE solo se utiliza para descifrar la transacción después de un momento específico (lo que requiere que el TEE tenga capacidad de percepción temporal). Soluciones más complejas permiten que el TEE se encargue de descifrar la transacción y construir bloques, ordenando las transacciones según criterios como el tiempo de llegada y las tarifas. En comparación con otras soluciones de memoria criptográfica, la ventaja del TEE radica en su capacidad para manejar transacciones en texto claro, reduciendo la información redundante en la cadena al filtrar transacciones que volverían a revertirse. Sin embargo, la desventaja de este método es su dependencia de la confiabilidad del hardware.
Compartición de secretos y cifrado umbral (Secret-sharing and threshold encryption): En este esquema, el usuario cifra la transacción con una clave que es poseída en conjunto por un comité específico (generalmente un subconjunto de validadores). La descifrado requiere cumplir con un umbral determinado (por ejemplo, se necesita el consentimiento de dos tercios de los miembros del comité).
Al utilizar el cifrado umbral, el portador de confianza pasa de ser el hardware a ser un comité. Los partidarios argumentan que, dado que la mayoría de los protocolos ya asumen que los validadores tienen la característica de "mayoría honesta" en el mecanismo de consenso, también podemos hacer una suposición similar, es decir, que la mayoría de los validadores se mantendrán honestos y no descifrarán las transacciones por adelantado.
Sin embargo, aquí hay que tener en cuenta una diferencia clave: estas dos suposiciones de confianza no son el mismo concepto. Los fracasos de consenso, como las bifurcaciones en la cadena de bloques, tienen visibilidad pública (pertenecen a la «suposición de confianza débil»), mientras que un comité malicioso que descifra transacciones en privado no dejará ninguna evidencia pública; este tipo de ataque no se puede detectar ni castigar (pertenece a la «suposición de confianza fuerte»). Por lo tanto, aunque a primera vista parece que el mecanismo de consenso y la suposición de seguridad del comité criptográfico son consistentes, en la práctica, la credibilidad de la suposición de que «el comité no conspirará» es mucho menor.
Bloqueo de tiempo y cifrado con retraso (Time-lock and delay encryption): como una alternativa al cifrado de umbral, el principio del cifrado con retraso es el siguiente: el usuario cifra la transacción con una clave pública, y la clave privada correspondiente a esa clave pública está oculta dentro de un rompecabezas de bloqueo de tiempo. Un rompecabezas de bloqueo de tiempo es un tipo de rompecabezas criptográfico que encapsula un secreto, cuya información secreta no puede ser revelada hasta después de un tiempo preestablecido; más específicamente, el proceso de descifrado requiere la ejecución repetida de una serie de cálculos que no pueden ser paralelizados. En este mecanismo, cualquier persona puede resolver el rompecabezas para obtener la clave y descifrar la transacción, pero con la condición de completar una serie de cálculos lentos (que son esencialmente de ejecución secuencial) diseñados para llevar un tiempo suficiente, asegurando que la transacción no pueda ser descifrada antes de su confirmación final. La forma más robusta de este primitivo criptográfico es generar públicamente tales rompecabezas a través de la tecnología de cifrado con retraso; también se puede aproximar este proceso mediante un comité de confianza utilizando cifrado con bloqueo de tiempo, aunque en este caso las ventajas relativas sobre el cifrado de umbral son discutibles.
Ya sea utilizando cifrado con retraso o mediante el cálculo ejecutado por un comité de confianza, este tipo de esquemas enfrenta numerosos desafíos prácticos: primero, dado que el retraso depende esencialmente del proceso de cálculo, es difícil garantizar la precisión del tiempo de descifrado; segundo, estos esquemas deben depender de entidades específicas que operen hardware de alto rendimiento para resolver eficientemente los acertijos, aunque cualquiera puede asumir este papel, no está claro cómo incentivar a dicha entidad a participar; finalmente, en este tipo de diseño, todas las transacciones transmitidas serán descifradas, incluidas aquellas que nunca fueron finalmente escritas en el bloque. Por otro lado, los esquemas basados en umbrales (o cifrado de testigos) podrían descifrar únicamente aquellas transacciones que han sido incluidas con éxito.
Cifrado con testigos (Witness encryption): La última y más avanzada solución criptográfica utiliza la tecnología de "cifrado con testigos". Teóricamente, el mecanismo del cifrado con testigos es: después de cifrar la información, solo aquellos que conocen la relación NP específica correspondiente a la "información de testigo" pueden descifrarla. Por ejemplo, la información puede ser cifrada de tal manera que solo quienes puedan resolver un rompecabezas de Sudoku o proporcionar una imagen de hash de un valor específico puedan completar el descifrado.
(Nota: la relación NP es la correspondencia entre "pregunta" y "respuesta que se puede verificar rápidamente")
Para cualquier relación NP, se puede implementar una lógica similar a través de SNARKs. Se puede decir que la encriptación de testigos es esencialmente la forma de encriptar datos de tal manera que solo los sujetos que pueden demostrar a través de SNARK que satisfacen ciertas condiciones puedan des-encriptarlos. En el escenario de memoria encriptada, un ejemplo típico de tales condiciones es: las transacciones solo pueden ser des-encriptadas después de que el bloque sea finalmente confirmado.
Esta es una teoría original con un gran potencial. De hecho, es un esquema de generalidad, donde los métodos basados en comités y los métodos basados en retrasos son solo formas específicas de su aplicación. Desafortunadamente, actualmente no tenemos ningún esquema criptográfico basado en testigos que se pueda implementar de manera práctica. Además, incluso si existiera tal esquema, sería difícil afirmar que tiene ventajas sobre el método basado en comités en una cadena de prueba de participación. Incluso si se establece que la criptografía de testigos se puede descifrar "solo cuando las transacciones se ordenan en bloques finalizados", un comité malicioso aún puede simular en privado el protocolo de consenso para falsificar el estado de confirmación final de las transacciones, y luego usar esta cadena privada como "testigo" para descifrar las transacciones. En este punto, el mismo comité podría utilizar el descifrado umbral, logrando el mismo nivel de seguridad y siendo mucho más simple de operar.
Sin embargo, en el protocolo de consenso de prueba de trabajo, las ventajas de la criptografía de testigos son aún más notables. Porque incluso si el comité es completamente malicioso, no puede extraer múltiples nuevos bloques en privado en la parte superior de la cadena de bloques actual para falsificar el estado de confirmación final.
Los desafíos técnicos que enfrenta el pool de memoria criptográfica
Varios desafíos prácticos limitan la capacidad de las piscinas de memoria criptográfica para prevenir el MEV. En general, la confidencialidad de la información es en sí misma un problema. Es notable que la aplicación de la tecnología criptográfica en el ámbito de Web3 no es amplia, pero las décadas de práctica en la implementación de tecnología criptográfica en redes (como TLS/HTTPS) y en comunicaciones privadas (desde PGP hasta plataformas modernas de mensajería cifrada como Signal y WhatsApp) han expuesto plenamente las dificultades: la criptografía, aunque es una herramienta para proteger la confidencialidad, no puede garantizarla de manera absoluta.
Primero, ciertos actores pueden acceder directamente a la información en texto claro de las transacciones de los usuarios. En un escenario típico, los usuarios generalmente no encriptan sus transacciones por sí mismos, sino que delegan esta tarea a un proveedor de servicios de billetera. De esta manera, el proveedor de servicios de billetera puede acceder al texto claro de la transacción e incluso puede utilizar o vender esta información para extraer MEV. La seguridad de la encriptación siempre depende de todos los actores que pueden acceder a la clave. El alcance del control de la clave es el límite de la seguridad.
Además, el mayor problema radica en los metadatos, es decir, los datos no cifrados que rodean la carga útil de la criptografía (transacciones). Los buscadores pueden utilizar estos metadatos para inferir la intención de la transacción y, a su vez, llevar a cabo MEV especulativo. Cabe destacar que los buscadores no necesitan comprender completamente el contenido de la transacción, ni tienen que adivinar correctamente cada vez. Por ejemplo, siempre que puedan juzgar con una probabilidad razonable que una transacción proviene de una orden de compra de un intercambio descentralizado (DEX) específico, eso es suficiente para iniciar un ataque.
Podemos clasificar los metadatos en varias categorías: una categoría son los clásicos problemas inherentes a la tecnología de criptografía, y la otra categoría son los problemas específicos del pool de memoria criptográfica.
Tamaño de transacción: la criptografía en sí no puede ocultar el tamaño del texto claro (es importante notar que la definición formal de seguridad semántica excluye explícitamente el ocultamiento del tamaño del texto claro). Este es un vector de ataque común en la comunicación cifrada; un caso típico es que, incluso después de cifrarse, un oyente puede determinar en tiempo real el contenido que se está reproduciendo en Netflix a través del tamaño de cada paquete de datos en el flujo de video. En el grupo de memoria cifrada, ciertos tipos de transacciones pueden tener tamaños únicos, lo que lleva a la filtración de información.
Hora de transmisión: La criptografía tampoco puede ocultar la información temporal (este es otro vector de ataque clásico). En el escenario de Web3, ciertos emisores (como en el caso de ventas estructuradas) pueden iniciar transacciones a intervalos fijos. El tiempo de transacción también puede estar relacionado con otra información, como la actividad de intercambios externos o eventos noticiosos. Una forma más encubierta de aprovechar la información temporal es el arbitraje entre intercambios centralizados (CEX) y descentralizados (DEX): el ordenante puede aprovechar la información de precios más reciente de CEX al insertar transacciones creadas lo más tarde posible; al mismo tiempo, el ordenante puede excluir todas las demás transacciones transmitidas después de un determinado momento (incluso si están cifradas), asegurando que su transacción obtenga la ventaja del precio más reciente.
Dirección IP de origen: los buscadores pueden inferir la identidad del remitente de una transacción al monitorear redes punto a punto y rastrear la dirección IP de origen. Este problema se descubrió en los primeros días de Bitcoin (hace más de diez años). Si un remitente específico tiene un patrón de comportamiento fijo, esto es de gran valor para los buscadores. Por ejemplo, al conocer la identidad del remitente, se pueden asociar transacciones criptográficas con transacciones históricas ya descifradas.
Información del remitente de la transacción y tarifas / gas: La tarifa de transacción es un tipo de metadato específico de la memoria de criptomonedas. En Ethereum, las transacciones tradicionales incluyen la dirección del remitente en la cadena (para pagar la tarifa), el presupuesto máximo de gas y la tarifa por unidad de gas que el remitente está dispuesto a pagar. Al igual que la dirección de la red de origen, la dirección del remitente puede usarse para asociar múltiples transacciones y entidades reales; el presupuesto de gas puede insinuar la intención de la transacción. Por ejemplo, interactuar con un DEX específico puede requerir una cantidad de gas fija reconocible.
Los buscadores complejos pueden combinar varios tipos de metadatos mencionados anteriormente para predecir el contenido de las transacciones.
En teoría, esta información se puede ocultar, pero a costa del rendimiento y la complejidad. Por ejemplo, rellenar las transacciones hasta una longitud estándar puede ocultar el tamaño, pero desperdiciará ancho de banda y espacio en la cadena; aumentar la latencia antes de enviar puede ocultar el tiempo, pero aumentará la latencia; enviar transacciones a través de redes anónimas como Tor puede ocultar la dirección IP, pero esto traerá nuevos desafíos.
Los metadatos más difíciles de ocultar son la información sobre las tarifas de transacción. Los datos de tarifas criptográficas presentan una serie de problemas para los constructores de bloques: primero, el problema de la información basura; si los datos de tarifas de transacción están encriptados, cualquier persona puede difundir transacciones encriptadas con un formato incorrecto. Estas transacciones, aunque serán ordenadas, no podrán pagar tarifas y no se podrán ejecutar después de ser desencriptadas, pero nadie podrá ser responsabilizado. Esto podría resolverse mediante SNARKs, es decir, probando que el formato de la transacción es correcto y que hay fondos suficientes, pero aumentaría significativamente los costos.
En segundo lugar, está el problema de la eficiencia en la construcción de bloques y la subasta de tarifas. Los constructores dependen de la información de tarifas para crear bloques que maximicen los beneficios y determinar el precio de mercado actual de los recursos en la cadena. Los datos de tarifas criptográficas socavan este proceso. Una solución es establecer una tarifa fija para cada bloque, pero esto es económicamente ineficiente y podría dar lugar a un mercado secundario para el empaquetado de transacciones, lo que contradice la intención original del pool de memoria criptográfica. Otra solución es realizar subastas de tarifas a través de cálculos seguros multiparte o hardware confiable, pero ambas opciones son extremadamente costosas.
Por último, un grupo de memoria cifrada seguro aumentará los costos del sistema desde múltiples perspectivas: la cifrado incrementará la latencia de la cadena, la carga computacional y el consumo de ancho de banda; cómo se combinará con objetivos futuros importantes como el sharding o la ejecución en paralelo aún no está claro; también podría introducir nuevos puntos de falla para la liveness (vitalidad) (como el comité de descifrado en esquemas de umbral, solucionadores de funciones de retardo); al mismo tiempo, la complejidad de diseño e implementación también aumentará significativamente.
Muchos de los problemas del pool de memoria criptográfica son similares a los desafíos que enfrentan las blockchains diseñadas para garantizar la privacidad de las transacciones, como Zcash y Monero. Si hay algún significado positivo, es que resolver todos los desafíos de la tecnología criptográfica en la mitigación de MEV también despejará obstáculos para la privacidad de las transacciones.
Los desafíos económicos que enfrenta la piscina de memoria criptográfica
Por último, la memoria criptográfica también enfrenta desafíos económicos. A diferencia de los desafíos técnicos, que pueden mitigarse gradualmente con suficientes inversiones en ingeniería, estos desafíos económicos son limitaciones fundamentales y su solución es extremadamente difícil.
El problema central del MEV proviene de la asimetría de información entre los creadores de transacciones (usuarios) y los explotadores de oportunidades de MEV (buscadores y constructores de bloques). Los usuarios a menudo no son conscientes de cuánto valor extraíble hay en sus transacciones, por lo que, incluso si existe una piscina de memoria criptográfica perfecta, pueden ser inducidos a revelar claves de descifrado a cambio de una recompensa inferior al valor real del MEV, fenómeno que se puede denominar "descifrado incentivado".
Este tipo de escenario no es difícil de imaginar, ya que mecanismos similares como MEV Share ya existen en la realidad. MEV Share es un mecanismo de subasta de flujo de órdenes que permite a los usuarios enviar información de transacciones a un fondo de manera selectiva, donde los buscadores compiten por obtener el derecho a aprovechar la oportunidad de MEV de esa transacción. El ganador, después de extraer el MEV, devolverá una parte de las ganancias (es decir, la cantidad de la oferta o un porcentaje de la misma) a los usuarios.
Este modelo se adapta directamente a las memorias criptográficas: los usuarios deben revelar la clave de descifrado (o parte de la información) para participar. Pero la mayoría de los usuarios no son conscientes del costo de oportunidad de participar en tales mecanismos, solo ven el retorno inmediato y están dispuestos a revelar información. También hay casos similares en las finanzas tradicionales: por ejemplo, la plataforma de trading sin comisiones Robinhood, cuyo modelo de negocio se basa en vender el flujo de órdenes de los usuarios a terceros a través del "pago por flujo de órdenes" (payment-for-order-flow).
Otro posible escenario es que los grandes constructores, bajo el pretexto de la revisión, obliguen a los usuarios a revelar el contenido de las transacciones (o información relacionada). La resistencia a la censura es un tema importante y controvertido en el ámbito de Web3, pero si los grandes validadores o constructores están obligados por la ley (como las regulaciones de la Oficina de Control de Activos Extranjeros de EE. UU., OFAC) a ejecutar una lista de censura, podrían negarse a procesar cualquier transacción criptográfica. Desde un punto de vista técnico, los usuarios podrían, en teoría, utilizar pruebas de conocimiento cero para demostrar que sus transacciones criptográficas cumplen con los requisitos de censura, pero esto aumentaría los costos y la complejidad adicionales. Incluso si la blockchain tiene una fuerte resistencia a la censura (asegurando que las transacciones criptográficas necesariamente sean incluidas), los constructores aún pueden priorizar las transacciones de texto plano conocidas en la parte delantera del bloque, mientras que las transacciones criptográficas se colocan al final. Por lo tanto, aquellos que necesiten asegurar la prioridad de ejecución de las transacciones, podrían verse obligados a revelar el contenido a los constructores.
Otros desafíos en términos de eficiencia
El pool de memoria criptográfica aumentará el costo del sistema de varias maneras evidentes. Los usuarios deben cifrar las transacciones, y el sistema también debe descifrarlas de alguna manera, lo que aumentará los costos de computación y puede aumentar el tamaño de las transacciones. Como se mencionó anteriormente, el procesamiento de metadatos agravará aún más estos costos. Sin embargo, hay algunos costos de eficiencia que no son tan evidentes. En el ámbito financiero, si los precios pueden reflejar toda la información disponible, el mercado se considera eficiente; sin embargo, los retrasos y la asimetría de la información pueden llevar a la ineficiencia del mercado. Este es precisamente el resultado inevitable que trae el pool de memoria criptográfica.
Este tipo de ineficiencia puede llevar a una consecuencia directa: el aumento de la incertidumbre de precios, que es un producto directo de la introducción de retrasos adicionales en el pool de memoria de criptomonedas. Por lo tanto, es posible que aumenten las transacciones que fallan debido a que superan la tolerancia al deslizamiento de precios, lo que a su vez desperdicia espacio en la cadena.
Del mismo modo, esta incertidumbre de precios también puede dar lugar a transacciones MEV especulativas, que intentan beneficiarse del arbitraje en la cadena. Es importante señalar que la memoria de criptomonedas puede hacer que estas oportunidades sean más comunes: debido a los retrasos en la ejecución, el estado actual de los intercambios descentralizados (DEX) se vuelve más confuso, lo que probablemente resulte en una disminución de la eficiencia del mercado y en diferencias de precios entre diferentes plataformas de trading. Este tipo de transacciones MEV especulativas también desperdician espacio en el bloque, ya que, una vez que no se detectan oportunidades de arbitraje, a menudo interrumpen su ejecución.
Resumen
El propósito de este artículo es resumir los desafíos que enfrenta el pool de memoria criptográfica, para que las personas puedan dirigir su atención al desarrollo de otras soluciones, aunque el pool de memoria criptográfica aún podría formar parte de un esquema de gobernanza de MEV.
Una idea viable es el diseño híbrido: parte de las transacciones se realizan a través de un pool de memoria encriptada para lograr "ordenamiento ciego", mientras que la otra parte utiliza otros esquemas de ordenamiento. Para tipos específicos de transacciones (como las órdenes de compra y venta de grandes participantes del mercado, que tienen la capacidad de encriptar cuidadosamente o llenar transacciones y están dispuestos a pagar un costo más alto para evitar MEV), el diseño híbrido puede ser la opción adecuada. Este diseño también tiene sentido práctico para transacciones altamente sensibles (como las transacciones de reparación de contratos de seguridad con vulnerabilidades).
Sin embargo, debido a las limitaciones tecnológicas, la alta complejidad de los proyectos y los costos de rendimiento, es poco probable que el pool de memoria criptográfica se convierta en la "solución universal para MEV" que la gente espera. La comunidad necesita desarrollar otras soluciones, incluyendo subastas de MEV, mecanismos de defensa en la capa de aplicación y la reducción del tiempo de confirmación final, entre otras. MEV seguirá siendo un desafío en el futuro cercano, y será necesario encontrar un equilibrio entre las diversas soluciones a través de una investigación profunda para abordar sus efectos negativos.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
a16z: ¿Por qué la encriptación memory pool es una solución mágica para el MEV?
Autor | Pranav Garimidi, Joseph Bonneau, Lioba Heimbach, a16z
Compilado | Saoirse, Foresight News
En la blockchain, ganar dinero a través de decidir qué transacciones empaquetar en un bloque, cuáles excluir, o ajustar el orden de las transacciones, se conoce como "valor máximo extraíble", abreviado como MEV. El MEV es común en la mayoría de las blockchains y ha sido un tema de amplia atención y discusión en la industria.
Numerosos investigadores, al observar el fenómeno MEV, han planteado una pregunta clara: ¿puede la tecnología criptográfica resolver este problema? Una de las soluciones es utilizar un pool de memoria encriptada: los usuarios transmiten transacciones encriptadas, las cuales solo se desencriptan y revelan una vez que se completa el ordenamiento. De este modo, el protocolo de consenso debe "seleccionar ciegamente" el orden de las transacciones, lo que parece prevenir la obtención de ganancias a través de oportunidades MEV durante la fase de ordenamiento.
Pero, lamentablemente, tanto desde el punto de vista práctico como teórico, las memorias criptográficas no pueden proporcionar una solución general al problema de MEV. Este artículo explicará las dificultades involucradas y explorará las direcciones de diseño viables para las memorias criptográficas.
Cómo funciona el pool de memoria criptográfica
Hay muchas propuestas sobre el pool de memoria criptográfica, pero su marco general es el siguiente:
El usuario transmite la transacción encriptada.
Las transacciones de criptomonedas se envían a la cadena (en algunas propuestas, las transacciones deben pasar primero por un barajado aleatorio verificable).
Cuando el bloque que contiene estas transacciones se confirma finalmente, las transacciones se descifran.
Finalmente, ejecuta estas transacciones.
Es importante tener en cuenta que en el paso 3 (desencriptación de transacciones) hay un problema clave: ¿quién es responsable de la desencriptación? ¿Qué sucede si la desencriptación no se completa? Una idea sencilla es permitir que los usuarios desencripten sus propias transacciones (en este caso, incluso no sería necesaria la encriptación, solo ocultar el compromiso sería suficiente). Pero este enfoque tiene una vulnerabilidad: los atacantes podrían llevar a cabo MEV especulativo.
En el MEV especulativo, los atacantes intentan adivinar si una transacción de criptomonedas contiene oportunidades de MEV, luego encriptan su transacción y tratan de insertarla en una posición favorable (por ejemplo, antes o después de la transacción objetivo). Si las transacciones están dispuestas en el orden esperado, el atacante puede desencriptar y extraer MEV a través de su propia transacción; si no se cumple la expectativa, rechazarán desencriptar y su transacción no será incluida en la cadena de bloques final.
Quizás se podría imponer una sanción a los usuarios que fallan al descifrar, pero la implementación de este mecanismo es extremadamente difícil. La razón es que: la severidad de las sanciones para todas las transacciones cifradas debe ser uniforme (después de todo, no se puede distinguir entre transacciones una vez cifradas), y las sanciones deben ser lo suficientemente severas como para frenar el MEV especulativo incluso frente a objetivos de alto valor. Esto resultaría en una gran cantidad de fondos bloqueados, y esos fondos deben mantenerse en el anonimato (para evitar la divulgación de la relación entre las transacciones y los usuarios). Más complicado aún, si debido a un error de programación o a una falla de la red, los usuarios reales no pueden descifrar correctamente, también sufrirán pérdidas.
Por lo tanto, la mayoría de las soluciones sugieren que al cifrar las transacciones, se debe asegurar que en algún momento futuro se puedan descifrar, incluso si el usuario que inició la transacción está fuera de línea o se niega a cooperar. Este objetivo se puede lograr de las siguientes maneras:
Entornos de Ejecución Confiables (TEE): Los usuarios pueden cifrar transacciones con una clave almacenada en la zona segura del Entorno de Ejecución Confiable (TEE). En algunas versiones básicas, el TEE solo se utiliza para descifrar la transacción después de un momento específico (lo que requiere que el TEE tenga capacidad de percepción temporal). Soluciones más complejas permiten que el TEE se encargue de descifrar la transacción y construir bloques, ordenando las transacciones según criterios como el tiempo de llegada y las tarifas. En comparación con otras soluciones de memoria criptográfica, la ventaja del TEE radica en su capacidad para manejar transacciones en texto claro, reduciendo la información redundante en la cadena al filtrar transacciones que volverían a revertirse. Sin embargo, la desventaja de este método es su dependencia de la confiabilidad del hardware.
Compartición de secretos y cifrado umbral (Secret-sharing and threshold encryption): En este esquema, el usuario cifra la transacción con una clave que es poseída en conjunto por un comité específico (generalmente un subconjunto de validadores). La descifrado requiere cumplir con un umbral determinado (por ejemplo, se necesita el consentimiento de dos tercios de los miembros del comité).
Al utilizar el cifrado umbral, el portador de confianza pasa de ser el hardware a ser un comité. Los partidarios argumentan que, dado que la mayoría de los protocolos ya asumen que los validadores tienen la característica de "mayoría honesta" en el mecanismo de consenso, también podemos hacer una suposición similar, es decir, que la mayoría de los validadores se mantendrán honestos y no descifrarán las transacciones por adelantado.
Sin embargo, aquí hay que tener en cuenta una diferencia clave: estas dos suposiciones de confianza no son el mismo concepto. Los fracasos de consenso, como las bifurcaciones en la cadena de bloques, tienen visibilidad pública (pertenecen a la «suposición de confianza débil»), mientras que un comité malicioso que descifra transacciones en privado no dejará ninguna evidencia pública; este tipo de ataque no se puede detectar ni castigar (pertenece a la «suposición de confianza fuerte»). Por lo tanto, aunque a primera vista parece que el mecanismo de consenso y la suposición de seguridad del comité criptográfico son consistentes, en la práctica, la credibilidad de la suposición de que «el comité no conspirará» es mucho menor.
Bloqueo de tiempo y cifrado con retraso (Time-lock and delay encryption): como una alternativa al cifrado de umbral, el principio del cifrado con retraso es el siguiente: el usuario cifra la transacción con una clave pública, y la clave privada correspondiente a esa clave pública está oculta dentro de un rompecabezas de bloqueo de tiempo. Un rompecabezas de bloqueo de tiempo es un tipo de rompecabezas criptográfico que encapsula un secreto, cuya información secreta no puede ser revelada hasta después de un tiempo preestablecido; más específicamente, el proceso de descifrado requiere la ejecución repetida de una serie de cálculos que no pueden ser paralelizados. En este mecanismo, cualquier persona puede resolver el rompecabezas para obtener la clave y descifrar la transacción, pero con la condición de completar una serie de cálculos lentos (que son esencialmente de ejecución secuencial) diseñados para llevar un tiempo suficiente, asegurando que la transacción no pueda ser descifrada antes de su confirmación final. La forma más robusta de este primitivo criptográfico es generar públicamente tales rompecabezas a través de la tecnología de cifrado con retraso; también se puede aproximar este proceso mediante un comité de confianza utilizando cifrado con bloqueo de tiempo, aunque en este caso las ventajas relativas sobre el cifrado de umbral son discutibles.
Ya sea utilizando cifrado con retraso o mediante el cálculo ejecutado por un comité de confianza, este tipo de esquemas enfrenta numerosos desafíos prácticos: primero, dado que el retraso depende esencialmente del proceso de cálculo, es difícil garantizar la precisión del tiempo de descifrado; segundo, estos esquemas deben depender de entidades específicas que operen hardware de alto rendimiento para resolver eficientemente los acertijos, aunque cualquiera puede asumir este papel, no está claro cómo incentivar a dicha entidad a participar; finalmente, en este tipo de diseño, todas las transacciones transmitidas serán descifradas, incluidas aquellas que nunca fueron finalmente escritas en el bloque. Por otro lado, los esquemas basados en umbrales (o cifrado de testigos) podrían descifrar únicamente aquellas transacciones que han sido incluidas con éxito.
Cifrado con testigos (Witness encryption): La última y más avanzada solución criptográfica utiliza la tecnología de "cifrado con testigos". Teóricamente, el mecanismo del cifrado con testigos es: después de cifrar la información, solo aquellos que conocen la relación NP específica correspondiente a la "información de testigo" pueden descifrarla. Por ejemplo, la información puede ser cifrada de tal manera que solo quienes puedan resolver un rompecabezas de Sudoku o proporcionar una imagen de hash de un valor específico puedan completar el descifrado.
(Nota: la relación NP es la correspondencia entre "pregunta" y "respuesta que se puede verificar rápidamente")
Para cualquier relación NP, se puede implementar una lógica similar a través de SNARKs. Se puede decir que la encriptación de testigos es esencialmente la forma de encriptar datos de tal manera que solo los sujetos que pueden demostrar a través de SNARK que satisfacen ciertas condiciones puedan des-encriptarlos. En el escenario de memoria encriptada, un ejemplo típico de tales condiciones es: las transacciones solo pueden ser des-encriptadas después de que el bloque sea finalmente confirmado.
Esta es una teoría original con un gran potencial. De hecho, es un esquema de generalidad, donde los métodos basados en comités y los métodos basados en retrasos son solo formas específicas de su aplicación. Desafortunadamente, actualmente no tenemos ningún esquema criptográfico basado en testigos que se pueda implementar de manera práctica. Además, incluso si existiera tal esquema, sería difícil afirmar que tiene ventajas sobre el método basado en comités en una cadena de prueba de participación. Incluso si se establece que la criptografía de testigos se puede descifrar "solo cuando las transacciones se ordenan en bloques finalizados", un comité malicioso aún puede simular en privado el protocolo de consenso para falsificar el estado de confirmación final de las transacciones, y luego usar esta cadena privada como "testigo" para descifrar las transacciones. En este punto, el mismo comité podría utilizar el descifrado umbral, logrando el mismo nivel de seguridad y siendo mucho más simple de operar.
Sin embargo, en el protocolo de consenso de prueba de trabajo, las ventajas de la criptografía de testigos son aún más notables. Porque incluso si el comité es completamente malicioso, no puede extraer múltiples nuevos bloques en privado en la parte superior de la cadena de bloques actual para falsificar el estado de confirmación final.
Los desafíos técnicos que enfrenta el pool de memoria criptográfica
Varios desafíos prácticos limitan la capacidad de las piscinas de memoria criptográfica para prevenir el MEV. En general, la confidencialidad de la información es en sí misma un problema. Es notable que la aplicación de la tecnología criptográfica en el ámbito de Web3 no es amplia, pero las décadas de práctica en la implementación de tecnología criptográfica en redes (como TLS/HTTPS) y en comunicaciones privadas (desde PGP hasta plataformas modernas de mensajería cifrada como Signal y WhatsApp) han expuesto plenamente las dificultades: la criptografía, aunque es una herramienta para proteger la confidencialidad, no puede garantizarla de manera absoluta.
Primero, ciertos actores pueden acceder directamente a la información en texto claro de las transacciones de los usuarios. En un escenario típico, los usuarios generalmente no encriptan sus transacciones por sí mismos, sino que delegan esta tarea a un proveedor de servicios de billetera. De esta manera, el proveedor de servicios de billetera puede acceder al texto claro de la transacción e incluso puede utilizar o vender esta información para extraer MEV. La seguridad de la encriptación siempre depende de todos los actores que pueden acceder a la clave. El alcance del control de la clave es el límite de la seguridad.
Además, el mayor problema radica en los metadatos, es decir, los datos no cifrados que rodean la carga útil de la criptografía (transacciones). Los buscadores pueden utilizar estos metadatos para inferir la intención de la transacción y, a su vez, llevar a cabo MEV especulativo. Cabe destacar que los buscadores no necesitan comprender completamente el contenido de la transacción, ni tienen que adivinar correctamente cada vez. Por ejemplo, siempre que puedan juzgar con una probabilidad razonable que una transacción proviene de una orden de compra de un intercambio descentralizado (DEX) específico, eso es suficiente para iniciar un ataque.
Podemos clasificar los metadatos en varias categorías: una categoría son los clásicos problemas inherentes a la tecnología de criptografía, y la otra categoría son los problemas específicos del pool de memoria criptográfica.
Tamaño de transacción: la criptografía en sí no puede ocultar el tamaño del texto claro (es importante notar que la definición formal de seguridad semántica excluye explícitamente el ocultamiento del tamaño del texto claro). Este es un vector de ataque común en la comunicación cifrada; un caso típico es que, incluso después de cifrarse, un oyente puede determinar en tiempo real el contenido que se está reproduciendo en Netflix a través del tamaño de cada paquete de datos en el flujo de video. En el grupo de memoria cifrada, ciertos tipos de transacciones pueden tener tamaños únicos, lo que lleva a la filtración de información.
Hora de transmisión: La criptografía tampoco puede ocultar la información temporal (este es otro vector de ataque clásico). En el escenario de Web3, ciertos emisores (como en el caso de ventas estructuradas) pueden iniciar transacciones a intervalos fijos. El tiempo de transacción también puede estar relacionado con otra información, como la actividad de intercambios externos o eventos noticiosos. Una forma más encubierta de aprovechar la información temporal es el arbitraje entre intercambios centralizados (CEX) y descentralizados (DEX): el ordenante puede aprovechar la información de precios más reciente de CEX al insertar transacciones creadas lo más tarde posible; al mismo tiempo, el ordenante puede excluir todas las demás transacciones transmitidas después de un determinado momento (incluso si están cifradas), asegurando que su transacción obtenga la ventaja del precio más reciente.
Dirección IP de origen: los buscadores pueden inferir la identidad del remitente de una transacción al monitorear redes punto a punto y rastrear la dirección IP de origen. Este problema se descubrió en los primeros días de Bitcoin (hace más de diez años). Si un remitente específico tiene un patrón de comportamiento fijo, esto es de gran valor para los buscadores. Por ejemplo, al conocer la identidad del remitente, se pueden asociar transacciones criptográficas con transacciones históricas ya descifradas.
Información del remitente de la transacción y tarifas / gas: La tarifa de transacción es un tipo de metadato específico de la memoria de criptomonedas. En Ethereum, las transacciones tradicionales incluyen la dirección del remitente en la cadena (para pagar la tarifa), el presupuesto máximo de gas y la tarifa por unidad de gas que el remitente está dispuesto a pagar. Al igual que la dirección de la red de origen, la dirección del remitente puede usarse para asociar múltiples transacciones y entidades reales; el presupuesto de gas puede insinuar la intención de la transacción. Por ejemplo, interactuar con un DEX específico puede requerir una cantidad de gas fija reconocible.
Los buscadores complejos pueden combinar varios tipos de metadatos mencionados anteriormente para predecir el contenido de las transacciones.
En teoría, esta información se puede ocultar, pero a costa del rendimiento y la complejidad. Por ejemplo, rellenar las transacciones hasta una longitud estándar puede ocultar el tamaño, pero desperdiciará ancho de banda y espacio en la cadena; aumentar la latencia antes de enviar puede ocultar el tiempo, pero aumentará la latencia; enviar transacciones a través de redes anónimas como Tor puede ocultar la dirección IP, pero esto traerá nuevos desafíos.
Los metadatos más difíciles de ocultar son la información sobre las tarifas de transacción. Los datos de tarifas criptográficas presentan una serie de problemas para los constructores de bloques: primero, el problema de la información basura; si los datos de tarifas de transacción están encriptados, cualquier persona puede difundir transacciones encriptadas con un formato incorrecto. Estas transacciones, aunque serán ordenadas, no podrán pagar tarifas y no se podrán ejecutar después de ser desencriptadas, pero nadie podrá ser responsabilizado. Esto podría resolverse mediante SNARKs, es decir, probando que el formato de la transacción es correcto y que hay fondos suficientes, pero aumentaría significativamente los costos.
En segundo lugar, está el problema de la eficiencia en la construcción de bloques y la subasta de tarifas. Los constructores dependen de la información de tarifas para crear bloques que maximicen los beneficios y determinar el precio de mercado actual de los recursos en la cadena. Los datos de tarifas criptográficas socavan este proceso. Una solución es establecer una tarifa fija para cada bloque, pero esto es económicamente ineficiente y podría dar lugar a un mercado secundario para el empaquetado de transacciones, lo que contradice la intención original del pool de memoria criptográfica. Otra solución es realizar subastas de tarifas a través de cálculos seguros multiparte o hardware confiable, pero ambas opciones son extremadamente costosas.
Por último, un grupo de memoria cifrada seguro aumentará los costos del sistema desde múltiples perspectivas: la cifrado incrementará la latencia de la cadena, la carga computacional y el consumo de ancho de banda; cómo se combinará con objetivos futuros importantes como el sharding o la ejecución en paralelo aún no está claro; también podría introducir nuevos puntos de falla para la liveness (vitalidad) (como el comité de descifrado en esquemas de umbral, solucionadores de funciones de retardo); al mismo tiempo, la complejidad de diseño e implementación también aumentará significativamente.
Muchos de los problemas del pool de memoria criptográfica son similares a los desafíos que enfrentan las blockchains diseñadas para garantizar la privacidad de las transacciones, como Zcash y Monero. Si hay algún significado positivo, es que resolver todos los desafíos de la tecnología criptográfica en la mitigación de MEV también despejará obstáculos para la privacidad de las transacciones.
Los desafíos económicos que enfrenta la piscina de memoria criptográfica
Por último, la memoria criptográfica también enfrenta desafíos económicos. A diferencia de los desafíos técnicos, que pueden mitigarse gradualmente con suficientes inversiones en ingeniería, estos desafíos económicos son limitaciones fundamentales y su solución es extremadamente difícil.
El problema central del MEV proviene de la asimetría de información entre los creadores de transacciones (usuarios) y los explotadores de oportunidades de MEV (buscadores y constructores de bloques). Los usuarios a menudo no son conscientes de cuánto valor extraíble hay en sus transacciones, por lo que, incluso si existe una piscina de memoria criptográfica perfecta, pueden ser inducidos a revelar claves de descifrado a cambio de una recompensa inferior al valor real del MEV, fenómeno que se puede denominar "descifrado incentivado".
Este tipo de escenario no es difícil de imaginar, ya que mecanismos similares como MEV Share ya existen en la realidad. MEV Share es un mecanismo de subasta de flujo de órdenes que permite a los usuarios enviar información de transacciones a un fondo de manera selectiva, donde los buscadores compiten por obtener el derecho a aprovechar la oportunidad de MEV de esa transacción. El ganador, después de extraer el MEV, devolverá una parte de las ganancias (es decir, la cantidad de la oferta o un porcentaje de la misma) a los usuarios.
Este modelo se adapta directamente a las memorias criptográficas: los usuarios deben revelar la clave de descifrado (o parte de la información) para participar. Pero la mayoría de los usuarios no son conscientes del costo de oportunidad de participar en tales mecanismos, solo ven el retorno inmediato y están dispuestos a revelar información. También hay casos similares en las finanzas tradicionales: por ejemplo, la plataforma de trading sin comisiones Robinhood, cuyo modelo de negocio se basa en vender el flujo de órdenes de los usuarios a terceros a través del "pago por flujo de órdenes" (payment-for-order-flow).
Otro posible escenario es que los grandes constructores, bajo el pretexto de la revisión, obliguen a los usuarios a revelar el contenido de las transacciones (o información relacionada). La resistencia a la censura es un tema importante y controvertido en el ámbito de Web3, pero si los grandes validadores o constructores están obligados por la ley (como las regulaciones de la Oficina de Control de Activos Extranjeros de EE. UU., OFAC) a ejecutar una lista de censura, podrían negarse a procesar cualquier transacción criptográfica. Desde un punto de vista técnico, los usuarios podrían, en teoría, utilizar pruebas de conocimiento cero para demostrar que sus transacciones criptográficas cumplen con los requisitos de censura, pero esto aumentaría los costos y la complejidad adicionales. Incluso si la blockchain tiene una fuerte resistencia a la censura (asegurando que las transacciones criptográficas necesariamente sean incluidas), los constructores aún pueden priorizar las transacciones de texto plano conocidas en la parte delantera del bloque, mientras que las transacciones criptográficas se colocan al final. Por lo tanto, aquellos que necesiten asegurar la prioridad de ejecución de las transacciones, podrían verse obligados a revelar el contenido a los constructores.
Otros desafíos en términos de eficiencia
El pool de memoria criptográfica aumentará el costo del sistema de varias maneras evidentes. Los usuarios deben cifrar las transacciones, y el sistema también debe descifrarlas de alguna manera, lo que aumentará los costos de computación y puede aumentar el tamaño de las transacciones. Como se mencionó anteriormente, el procesamiento de metadatos agravará aún más estos costos. Sin embargo, hay algunos costos de eficiencia que no son tan evidentes. En el ámbito financiero, si los precios pueden reflejar toda la información disponible, el mercado se considera eficiente; sin embargo, los retrasos y la asimetría de la información pueden llevar a la ineficiencia del mercado. Este es precisamente el resultado inevitable que trae el pool de memoria criptográfica.
Este tipo de ineficiencia puede llevar a una consecuencia directa: el aumento de la incertidumbre de precios, que es un producto directo de la introducción de retrasos adicionales en el pool de memoria de criptomonedas. Por lo tanto, es posible que aumenten las transacciones que fallan debido a que superan la tolerancia al deslizamiento de precios, lo que a su vez desperdicia espacio en la cadena.
Del mismo modo, esta incertidumbre de precios también puede dar lugar a transacciones MEV especulativas, que intentan beneficiarse del arbitraje en la cadena. Es importante señalar que la memoria de criptomonedas puede hacer que estas oportunidades sean más comunes: debido a los retrasos en la ejecución, el estado actual de los intercambios descentralizados (DEX) se vuelve más confuso, lo que probablemente resulte en una disminución de la eficiencia del mercado y en diferencias de precios entre diferentes plataformas de trading. Este tipo de transacciones MEV especulativas también desperdician espacio en el bloque, ya que, una vez que no se detectan oportunidades de arbitraje, a menudo interrumpen su ejecución.
Resumen
El propósito de este artículo es resumir los desafíos que enfrenta el pool de memoria criptográfica, para que las personas puedan dirigir su atención al desarrollo de otras soluciones, aunque el pool de memoria criptográfica aún podría formar parte de un esquema de gobernanza de MEV.
Una idea viable es el diseño híbrido: parte de las transacciones se realizan a través de un pool de memoria encriptada para lograr "ordenamiento ciego", mientras que la otra parte utiliza otros esquemas de ordenamiento. Para tipos específicos de transacciones (como las órdenes de compra y venta de grandes participantes del mercado, que tienen la capacidad de encriptar cuidadosamente o llenar transacciones y están dispuestos a pagar un costo más alto para evitar MEV), el diseño híbrido puede ser la opción adecuada. Este diseño también tiene sentido práctico para transacciones altamente sensibles (como las transacciones de reparación de contratos de seguridad con vulnerabilidades).
Sin embargo, debido a las limitaciones tecnológicas, la alta complejidad de los proyectos y los costos de rendimiento, es poco probable que el pool de memoria criptográfica se convierta en la "solución universal para MEV" que la gente espera. La comunidad necesita desarrollar otras soluciones, incluyendo subastas de MEV, mecanismos de defensa en la capa de aplicación y la reducción del tiempo de confirmación final, entre otras. MEV seguirá siendo un desafío en el futuro cercano, y será necesario encontrar un equilibrio entre las diversas soluciones a través de una investigación profunda para abordar sus efectos negativos.