- Tema
36k Popularidad
13k Popularidad
6k Popularidad
16k Popularidad
62k Popularidad
31k Popularidad
2k Popularidad
113k Popularidad
27k Popularidad
27k Popularidad
- Anclado
36k Popularidad
13k Popularidad
6k Popularidad
16k Popularidad
62k Popularidad
31k Popularidad
2k Popularidad
113k Popularidad
27k Popularidad
27k Popularidad
a16z: ¿Por qué la encriptación del memory pool es difícil de convertirse en la cura universal para el MEV?
Escrito por: Pranav Garimidi, Joseph Bonneau, Lioba Heimbach, a16z
Compilado por: Saoirse, Foresight News
En la blockchain, ganar dinero a través de decidir qué transacciones se empaquetan en un bloque, cuáles se excluyen o ajustando 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 amplio interés y discusión en la industria.
Nota: Este artículo asume que el lector tiene un conocimiento básico sobre MEV. Algunos lectores pueden leer primero nuestro artículo de divulgación sobre MEV*.*
Muchos 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, y estas transacciones solo se desvelan una vez que se completa el ordenamiento. De esta manera, el protocolo de consenso debe "elegir al azar" el orden de las transacciones, lo que parece prevenir la posibilidad de obtener ganancias a partir de oportunidades MEV durante la fase de ordenamiento.
Sin embargo, lamentablemente, tanto desde el punto de vista práctico como teórico, el grupo de memoria criptográfica no puede proporcionar una solución universal para el problema de MEV. Este artículo explicará las dificultades involucradas y explorará las direcciones de diseño viables para el grupo de memoria criptográfica.
Cómo funciona el pool de memoria criptográfica
Sobre el grupo de memoria criptográfica ya hay muchas propuestas, pero su marco general es el siguiente:
Es importante tener en cuenta que hay un problema clave en el paso 3 (desencriptación de transacciones): ¿quién es responsable de desencriptar? ¿Qué sucede si la desencriptación no se completa? Una idea simple es permitir que el usuario desencripte sus propias transacciones (en este caso, ni siquiera es necesario encriptar, solo ocultar el compromiso). Pero este enfoque tiene vulnerabilidades: un atacante podría llevar a cabo MEV especulativo.
En el MEV especulativo, el atacante intentará adivinar si una transacción criptográfica contiene oportunidades de MEV, luego encriptará su transacción y tratará de insertarla en una posición favorable (por ejemplo, delante o detrás de la transacción objetivo). Si las transacciones están ordenadas como se esperaba, el atacante podrá desencriptar y extraer MEV a través de su transacción; si no se alcanza lo esperado, se negarán a 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 no logren descifrar, pero la implementación de este mecanismo es extremadamente difícil. La razón es: la severidad de la sanción por todas las transacciones encriptadas debe ser uniforme (después de todo, no se pueden distinguir las transacciones una vez encriptadas), y la sanción debe ser lo suficientemente severa como para frenar el MEV especulativo, incluso frente a objetivos de alto valor. Esto llevaría a que una gran cantidad de fondos queden bloqueados, y estos fondos deben mantenerse en el anonimato (para evitar la filtración de la relación entre las transacciones y los usuarios). Lo más complicado es que, si debido a un fallo en el programa o en la red, los usuarios reales no pueden descifrar correctamente, también sufrirían pérdidas.
Por lo tanto, la mayoría de las propuestas sugieren que al cifrar las transacciones, se debe garantizar que en algún momento futuro puedan ser descifradas, incluso si el usuario que inicia 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 utilizando claves mantenidas en un área segura de un entorno de ejecución confiable (TEE). En algunas versiones básicas, el TEE solo se utiliza para descifrar transacciones 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 descifre transacciones y construya bloques, ordenando las transacciones según criterios como el tiempo de llegada y tarifas. En comparación con otros esquemas de memoria criptográfica, la ventaja del TEE radica en que puede procesar directamente transacciones en texto claro, reduciendo la información redundante en la cadena al filtrar transacciones que serían revertidas. 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 conjuntamente por un comité específico (normalmente un subconjunto de validadores). Para la descifrado, se debe cumplir con ciertas condiciones de umbral (por ejemplo, dos tercios de los miembros del comité deben estar de acuerdo).
Al adoptar el cifrado umbral, el portador de confianza pasa de ser hardware a un comité. Los partidarios sostienen que, dado que la mayoría de los protocolos ya asumen de forma predeterminada que los validadores poseen 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 desencriptarán las transacciones por adelantado.
Sin embargo, aquí hay que tener en cuenta una distinción clave: estas dos suposiciones de confianza no son el mismo concepto. Los fallos de consenso, como las bifurcaciones de blockchain, tienen visibilidad pública (pertenecen a la "suposición de confianza débil"), mientras que un comité malicioso que descifra transacciones en privado no deja evidencia pública, este tipo de ataque no puede ser detectado ni castigado (pertenece a la "suposición de confianza fuerte"). Por lo tanto, aunque a simple vista los mecanismos de consenso y las suposiciones de seguridad del comité criptográfico parecen coincidir, en la práctica, la credibilidad de la suposición de que "el comité no conspirará" es mucho menor.
Bloqueo temporal y cifrado de retraso (Time-lock and delay encryption): Como una alternativa al cifrado umbral, el principio del cifrado de 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 en un rompecabezas de bloqueo temporal. Un rompecabezas de bloqueo temporal es un rompecabezas criptográfico que encapsula un secreto, cuyo contenido secreto no puede ser revelado hasta que haya pasado un tiempo preestablecido. Más concretamente, el proceso de descifrado requiere la ejecución repetida de una serie de cálculos que no pueden ser paralelizados. Con este mecanismo, cualquiera 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 (en esencia, ejecutados de forma secuencial) que consumen un tiempo diseñado lo suficientemente largo, garantizando que la transacción no pueda ser descifrada antes de su confirmación final. La forma más fuerte de este primitivo de cifrado se genera públicamente mediante la tecnología de cifrado de retraso; también se puede aproximar a este proceso mediante un comité de confianza utilizando cifrado de bloqueo temporal, aunque en este caso las ventajas relativas sobre el cifrado umbral son discutibles.
Tanto si se utiliza cifrado por retraso como si se realizan cálculos por un comité de confianza, estos esquemas enfrentan numerosos desafíos prácticos: primero, dado que el retraso depende en esencia del proceso de cálculo, es difícil garantizar la precisión del tiempo de descifrado; en segundo lugar, estos esquemas necesitan depender de entidades específicas que operen hardware de alto rendimiento para resolver eficientemente los acertijos, aunque cualquiera puede asumir este papel, cómo motivar a esa entidad a participar sigue siendo incierto; finalmente, en este tipo de diseño, todas las transacciones transmitidas serán descifradas, incluidas aquellas que nunca se escribieron finalmente en un bloque. Por otro lado, los esquemas basados en umbrales (o cifrado de testigos) podrían descifrar únicamente aquellas transacciones que se incluyeron con éxito.
Encriptación de testigos (Witness encryption): La última y más avanzada solución criptográfica utiliza la tecnología de "encriptación de testigos". Teóricamente, el mecanismo de la encriptación de testigos es: después de encriptar la información, solo las personas que conocen la "información testigo" correspondiente a una relación NP específica pueden descifrarla. Por ejemplo, se puede encriptar información de tal manera que solo aquellos que pueden resolver un rompecabezas de Sudoku o proporcionar una imagen previa de un hash de cierto valor 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 criptografía de testigos es esencialmente la forma de cifrar datos de tal manera que solo los sujetos que pueden demostrar a través de SNARK que cumplen con ciertas condiciones puedan descifrarlos. En el escenario de la memoria de criptomonedas, un ejemplo típico de tales condiciones es: las transacciones solo pueden ser descifradas después de que el bloque haya sido confirmado de manera definitiva.
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 aplicación. Desafortunadamente, actualmente no tenemos ningún esquema criptográfico basado en testigos que sea práctico. Además, incluso si existiera tal esquema, sería difícil afirmar que tiene más ventajas que el método basado en comités en una cadena de prueba de participación. Incluso si se establece la criptografía de testigos como "solo se puede descifrar cuando las transacciones se ordenan en bloques finalizados", un comité malicioso aún puede simular el protocolo de consenso en privado para falsificar el estado de confirmación final de las transacciones, y luego usar esta cadena privada como "testigo" para descifrar la transacción. En este momento, el mismo comité puede utilizar el descifrado umbral, logrando la misma seguridad con una operación mucho más simple.
Sin embargo, en el protocolo de consenso de prueba de trabajo, las ventajas de la criptografía de testigos son aún más evidentes. Porque incluso si el comité es completamente malicioso, no puede minar en secreto múltiples nuevos bloques en la cabeza de la cadena de bloques actual para falsificar el estado de confirmación final.
Desafíos técnicos que enfrenta el pool de memoria criptográfica
Varios desafíos prácticos limitan la capacidad de los grupos de memoria criptográfica para prevenir el MEV. En general, la confidencialidad de la información es en sí misma un problema. Es importante destacar que la aplicación de tecnologías criptográficas en el ámbito de Web3 no es amplia, pero las décadas de práctica de implementación de tecnología criptográfica en redes (como TLS/HTTPS) y comunicaciones privadas (desde PGP hasta Signal, WhatsApp y otras plataformas de mensajería encriptada modernas) han expuesto plenamente las dificultades: aunque la criptografía es una herramienta para proteger la confidencialidad, no puede garantizarla de manera absoluta.
Primero, ciertos actores pueden obtener directamente la información en texto claro de las transacciones de los usuarios. En un escenario típico, los usuarios generalmente no cifran las transacciones por sí mismos, sino que delegan esta tarea a los proveedores de servicios de billetera. De esta manera, los proveedores de servicios de billetera pueden acceder al texto claro de las transacciones e incluso pueden utilizar o vender esta información para extraer MEV. La seguridad del cifrado siempre depende de todos los actores que pueden acceder a las claves. El alcance del control de las claves es el límite de la seguridad.
Además de esto, el mayor problema radica en los metadatos, es decir, los datos no encriptados que rodean la carga útil encriptada (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 señalar que los buscadores no necesitan comprender completamente el contenido de la transacción, ni tienen que acertar 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 intrínsecos a la tecnología de criptografía, y la otra categoría son los problemas específicos de la memoria de criptografía.
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 también traerá nuevos desafíos.
La información de las tarifas de transacción es la metadata más difícil de ocultar. 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 formato incorrecto. Estas transacciones pueden ser ordenadas, pero no pueden pagar las tarifas, y al ser desencriptadas no pueden ejecutarse sin que nadie asuma la responsabilidad. Esto podría resolverse mediante SNARKs, que demuestran 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 pueden socavar 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 de empaquetado de transacciones, contraviniendo el propósito de diseño del pool de memoria criptográfica. Otra solución es realizar subastas de tarifas mediante cálculos seguros multipartitos o hardware confiable, pero ambas opciones son extremadamente costosas.
Finalmente, un pool de memoria encriptada seguro aumentará el costo del sistema desde múltiples perspectivas: la encriptación aumentará la latencia de la cadena, la carga computacional y el consumo de ancho de banda; no está claro cómo se combinará con objetivos futuros importantes como el sharding o la ejecución paralela; también podría introducir nuevos puntos de falla para la liveness (vivacidad) (como los comités de desencriptación en esquemas de umbral, o los solucionadores de funciones de retraso); al mismo tiempo, la complejidad de diseño e implementación también aumentará significativamente.
Muchos de los problemas de los pools 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, 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á el camino para la privacidad de las transacciones.
Desafíos económicos que enfrenta la memoria criptográfica
Finalmente, la memoria criptográfica también enfrenta desafíos económicos. A diferencia de los desafíos tecnológicos, que se pueden mitigar gradualmente con suficiente inversión en ingeniería, estos desafíos económicos son limitaciones fundamentales y son extremadamente difíciles de resolver.
El problema central del MEV proviene de la asimetría de información entre los creadores de transacciones (usuarios) y los extractores 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 en 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 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 las oportunidades de MEV de esa transacción. El ganador, después de extraer el MEV, devolverá una parte de las ganancias (es decir, el monto de la oferta o un cierto porcentaje de este) a los usuarios.
Este modelo se adapta directamente a la memoria criptográfica: los usuarios deben revelar la clave de descifrado (o parte de la información) para participar. Sin embargo, la mayoría de los usuarios no son conscientes del costo de oportunidad de participar en este tipo de 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 comercio 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 escenario posible es que los grandes constructores, bajo el pretexto de la censura, 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 legalmente obligados (como las regulaciones de la Oficina de Control de Activos Extranjeros de EE. UU., OFAC) a hacer cumplir listas de censura, pueden negarse a procesar cualquier transacción criptográfica. Técnicamente, los usuarios pueden ser capaces de demostrar que sus transacciones criptográficas cumplen con los requisitos de censura a través de pruebas de conocimiento cero, 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 serán incluidas), los constructores aún pueden priorizar las transacciones de texto claro conocidas en la parte delantera del bloque, mientras que las transacciones criptográficas se colocan al final. Por lo tanto, aquellos que necesitan garantizar 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á los costos 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á el costo computacional y podría aumentar el tamaño de las transacciones. Como se mencionó anteriormente, el procesamiento de metadatos agravará aún más estos costos. Sin embargo, también 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; mientras que las demoras y la asimetría de información pueden llevar a una ineficiencia del mercado. Este es precisamente el resultado inevitable que trae el pool de memoria criptográfica.
Este tipo de ineficiencia conduce a una consecuencia directa: el aumento de la incertidumbre de precios, que es un producto directo del retraso adicional introducido por 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 en los precios también puede dar lugar a transacciones MEV especulativas, que intentan beneficiarse del arbitraje en la cadena. Cabe destacar que el grupo de 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 difuso, lo que probablemente conduce a una disminución de la eficiencia del mercado y a diferencias de precios entre diferentes plataformas de trading. Este tipo de transacciones MEV especulativas también desperdician espacio en los bloques, ya que una vez que no se encuentran oportunidades de arbitraje, a menudo terminan la ejecución.
Resumen
El objetivo de este artículo es analizar los desafíos que enfrenta el pool de memoria criptográfica, para que las personas puedan redirigir su energía hacia el desarrollo de otras soluciones, pero el pool de memoria criptográfica aún podría ser parte de una solución de gobernanza MEV.
Una posible solución es un diseño híbrido: una parte de las transacciones se lleva a cabo a través de un grupo de memoria criptográfica para realizar "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 el MEV), el diseño híbrido puede ser la elección adecuada. Para transacciones altamente sensibles (como las transacciones de reparación de contratos de seguridad con vulnerabilidades), este diseño también tiene sentido práctico.
Sin embargo, debido a las limitaciones tecnológicas, la alta complejidad de ingeniería y el costo de rendimiento, es poco probable que el pool de memoria cifrada 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 a nivel de aplicación y la reducción del tiempo de confirmación final, entre otros. MEV seguirá siendo un desafío durante un tiempo, y será necesario encontrar un equilibrio en las diversas soluciones a través de una investigación profunda para abordar sus impactos negativos.