a16z Crypto Últimas investigaciones: ¿Cuál es la clave para la adopción masiva de DeFi?

Autor: PGarimidi, jneu_net, @MaxResnic

Compilación: Jiahán, ChainCatcher

Hoy en día, la blockchain puede afirmarse de forma tangible que ya cuenta con la capacidad necesaria para competir con la infraestructura financiera existente. Los sistemas de producción actuales pueden procesar decenas de miles de transacciones por segundo, y pronto se recibirá una mejora de órdenes de magnitud. Sin embargo, además del rendimiento bruto, las aplicaciones financieras también necesitan previsibilidad. Ya sea una compraventa, una puja de una subasta o el ejercicio de una opción, el funcionamiento normal de un sistema financiero requiere una respuesta determinista: ¿cuándo se ejecutará exactamente esta transacción? Si la transacción enfrenta retrasos impredecibles (ya sea maliciosos o accidentales), muchas aplicaciones se vuelven inutilizables.

Para que las aplicaciones financieras on-chain sean competitivas, la blockchain debe proporcionar garantías de empaquetado a corto plazo: es decir, si se envía una transacción válida a la red, debe poder garantizarse que se empaquetará lo antes posible. Por ejemplo, consideremos un libro de órdenes on-chain. Un libro de órdenes eficiente necesita que los market makers proporcionen liquidez de forma continua manteniendo órdenes de compra y venta de activos en el libro contable.

El principal reto al que se enfrentan los market makers es: por un lado, reducir al máximo el spread entre precios de compra y venta, y por otro, evitar el riesgo de “selección adversa” al cotizarse fuera de mercado. Para lograrlo, los market makers deben actualizar constantemente sus órdenes para reflejar el estado del mundo real. Por ejemplo, si un anuncio de la Reserva Federal provoca un salto inmediato en el precio de un activo, un market maker necesita reaccionar al instante y actualizar sus órdenes al nuevo precio. En este escenario, si la transacción mediante la cual el market maker actualiza sus órdenes no se incluye inmediatamente, perderán dinero debido a que los arbitrajistas ejecutan sus órdenes con precios obsoletos. Después, el market maker necesita ampliar el spread para reducir su exposición al riesgo en este tipo de eventos, lo que a su vez disminuye la competitividad del mercado de transacciones on-chain.

El empaquetado de transacciones predecible proporciona una garantía fuerte a los market makers, permitiéndoles reaccionar rápidamente ante eventos off-chain y mantener la eficiencia del mercado on-chain.

Qué tenemos y qué necesitamos

Hoy en día, las blockchains existentes solo proporcionan garantías sólidas de finalidad, que normalmente se activan en unos pocos segundos. Aunque estas garantías son suficientes para aplicaciones como pagos, son demasiado débiles para soportar aplicaciones financieras de gran escala que los participantes del mercado necesitan para reaccionar en tiempo real a la información.

Con el ejemplo del libro de órdenes: para un market maker, si la transacción de un arbitrajista puede caer en un bloque anterior, la garantía de que será empaquetada en “unos segundos en el futuro” no significa nada. Sin una garantía de empaquetado sólida, el market maker tiene que hacer frente al aumento del riesgo de selección adversa ampliando el spread y ofreciendo un precio peor a los usuarios. Esto, a su vez, hace que el atractivo del comercio on-chain se reduzca drásticamente frente a otros mercados que ofrecen garantías más fuertes.

Para que la blockchain alcance realmente la visión de modernización de los mercados de capitales como infraestructura, los constructores necesitan resolver estos problemas para que aplicaciones de alto valor como el libro de órdenes puedan prosperar.

¿Dónde está realmente lo difícil para lograr previsibilidad?

Reforzar las garantías de empaquetado de las blockchains existentes para soportar estos casos de uso es un desafío. Algunos protocolos de hoy pueden depender de un nodo que puede decidir en cualquier momento dado qué transacciones se empaquetan (un “líder”). Aunque esto simplifica el reto de ingeniería para construir blockchains de alto rendimiento, también introduce un posible cuello de botella económico: estos líderes pueden extraer valor en él. Normalmente, dentro de la ventana en la que el nodo es seleccionado como líder, tiene autoridad total sobre qué transacciones se incluyen en el bloque. Para una blockchain que gestione actividades financieras de cualquier escala, el líder ocupa una posición privilegiada. Si ese único líder decide no incluir una transacción, la única solución es esperar al siguiente líder que esté dispuesto a empaquetar esa transacción.

En redes sin permiso, los líderes tienen incentivos para extraer valor, comúnmente conocido como MEV. El MEV va mucho más allá del ámbito de front-running de operaciones AMM. Incluso si el líder solo puede retrasar el empaquetado de transacciones por decenas de milisegundos, puede obtener enormes beneficios y reducir la eficiencia de las aplicaciones subyacentes. Un libro de órdenes que prioriza procesar solo las transacciones de ciertos participantes colocará a todos los demás en un entorno de competencia injusta. En el peor de los casos, el líder puede volverse extremadamente hostil, hasta el punto de que los traders abandonen completamente la plataforma.

Supongamos que ocurre un aumento de tasas de interés y el precio de ETH cae inmediatamente un 5%. Cada market maker en el libro de órdenes compite por cancelar sus órdenes y enviar nuevas órdenes con el nuevo precio. Mientras tanto, cada arbitrajista envía órdenes para vender ETH al precio de las órdenes colgadas obsoletas. Si este libro de órdenes se ejecuta sobre un protocolo con un único líder, entonces ese líder tiene un poder enorme. El líder puede simplemente optar por revisar (no incluir) todas las cancelaciones de los market makers, permitiendo que los arbitrajistas obtengan grandes ganancias. O bien, el líder puede no revisar directamente las cancelaciones, sino retrasarlas hasta después de que las transacciones de los arbitrajistas se hagan efectivas. El líder incluso puede insertar sus propias operaciones de arbitraje para aprovechar plenamente la diferencia de precios.

Dos demandas fundamentales

Ante estas ventajas, la participación activa de los market makers deja de ser económicamente eficiente; siempre que el precio fluctúe, es posible que se queden en desventaja. El problema se reduce a que el líder tiene demasiados privilegios en dos aspectos clave: 1) el líder puede revisar las transacciones de cualquier otra persona y, 2) el líder puede ver las transacciones de otros y, con base en ello, presentar sus propias transacciones como respuesta. Cualquiera de estos dos problemas puede resultar catastrófico.

Un ejemplo

Podemos fijar de manera precisa el punto problemático mediante el siguiente ejemplo. Consideremos una subasta con dos postores, Alice y Bob, donde Bob también es el líder del bloque en el que ocurre la subasta. (El ajuste con solo dos postores es para ilustrar el problema; sin importar cuántos postores haya, se aplica el mismo razonamiento.)

La subasta acepta pujas durante el intervalo de tiempo necesario para que se genere el bloque; supongamos que va de tiempo t=0 a t=1. Alice envía una puja bA en el tiempo tA y Bob envía una puja bB en el tiempo tB > tA. Dado que Bob es el líder de ese bloque, siempre puede garantizar que actúa en último lugar. Alice y Bob también tienen una fuente de verdad de precios de activos que se actualiza constantemente y que pueden leer (por ejemplo, el precio medio de una exchange centralizada). En tiempo t, supongamos que este precio es pt. Supondremos que, en cualquier momento t, la expectativa del mercado sobre el precio del activo al finalizar la subasta (t=1) siempre es igual al precio en tiempo real pt. Las reglas de la subasta son simples: gana la subasta el que tenga la puja más alta entre Alice y Bob y paga el importe de su puja.

La necesidad de resistencia a la censura

Ahora veamos qué sucede cuando Bob puede aprovechar su ventaja de ser líder de esta subasta. Si Bob puede censurar la puja de Alice, es obvio que la subasta se desmorona. Dado que no hay otros postores, Bob solo necesita pujar por un importe arbitrariamente pequeño para garantizar ganar la subasta. Esto hace que, al liquidarse la subasta, la ganancia sea sustancialmente 0.

La necesidad oculta

El caso más complejo es si Bob no puede censurar directamente la puja de Alice, pero aun así puede ver la puja de Alice antes de enviar la suya. En esa situación, Bob tiene una estrategia simple. Cuando él puja, solo necesita comprobar si ptB > bA. Si es cierto, entonces la puja de Bob es solo ligeramente superior a bA; si no, entonces Bob no puja.

Al ejecutar esta estrategia, Bob somete a Alice a una selección adversa desfavorable. La única situación en la que Alice gana es cuando la actualización del precio hace que su puja termine siendo mayor que el valor esperado del activo. Cada vez que Alice gana la subasta, ella anticipará perder dinero, y ni siquiera le convendría participar. Con la desaparición de todos los competidores, Bob puede volver a pujar por un importe arbitrariamente pequeño y ganar, mientras que la subasta en realidad obtiene una ganancia de 0.

La clave aquí es que la duración de esta subasta no importa. Mientras Bob pueda censurar la puja de Alice, o ver la puja de Alice antes de pujar él mismo, esta subasta está destinada a fallar.

Los mismos principios de este ejemplo se aplican a cualquier entorno de activos de trading de alta frecuencia, ya sea trading spot, contratos perpetuos o exchanges de derivados: si existe un líder con el poder de Bob en este ejemplo, ese líder podría hacer que el mercado colapse por completo. Para que un producto on-chain que atienda estos casos de uso sea realmente viable, nunca debe otorgársele ese poder a los líderes.

¿Cómo surgen estos problemas en la práctica hoy?

El relato anterior dibuja una imagen sombría de la transacción on-chain sobre cualquier protocolo de líder único sin permiso. Sin embargo, ¿por qué el volumen de transacciones de los DEX (exchanges descentralizados) basados en protocolos de líder único sigue siendo saludable? En la práctica, dos fuerzas combinadas compensan los problemas anteriores:

• los líderes no aprovechan plenamente su poder económico porque, normalmente, ellos mismos invierten en gran medida en el éxito de la blockchain subyacente;
• las aplicaciones ya se han construido con soluciones alternativas para no ser tan frágiles ante estos problemas.

Aunque estos dos factores han mantenido el funcionamiento de las finanzas descentralizadas (DeFi) hasta ahora, a largo plazo no son suficientes para que los mercados on-chain compitan de verdad con los mercados off-chain.

Para obtener la posición de líder en una blockchain con actividad económica real, se necesita un gran monto de staking. Por tanto, o bien el líder posee una cantidad considerable de staking por sí mismo, o bien tiene suficiente reputación para que otros tenedores de tokens deleguen su staking en él. En cualquier caso, grandes operadores de nodos suelen ser entidades conocidas a las que se les puede poner en riesgo la reputación. No es solo la reputación: ese staking significa también que estos operadores tienen incentivos financieros para que su blockchain funcione bien. Justamente por eso, en gran medida aún no hemos visto que los líderes aprovechen su poder de mercado de la forma descrita anteriormente; pero eso no significa que estos problemas no existan.

Primero, basarse en la buena voluntad de los operadores de nodos mediante presión social y apelar a sus motivaciones de largo plazo no es una base sólida para el futuro financiero. A medida que aumenta la escala de la actividad financiera on-chain, las ganancias potenciales de los líderes también crecen. Cuanto mayor sea esa posibilidad de crecimiento, más difícil será que, desde la esfera social, se logre que el comportamiento del líder vaya en contra de sus intereses inmediatos directos.

En segundo lugar, el grado en que un líder puede aprovechar su poder de mercado es un espectro que va desde un resultado benigno hasta hacer que el mercado colapse completamente. Los operadores de nodos pueden, de forma unilateral, empujar el uso de su poder para obtener mayores ganancias. Cuando algunos operadores desafían los límites aceptados, otros operadores imitan rápidamente. El comportamiento de un nodo individual puede parecer insignificante, pero cuando todos cambian, su impacto se hace evidente.

Quizá el mejor ejemplo de este fenómeno sean los Timing Games: el líder intenta anunciar el bloque lo más tarde posible mientras el protocolo aún esté vigente, para ganar recompensas más altas. Cuando el líder es demasiado agresivo, esto provoca que el tiempo para producir bloques sea más largo y que haya saltos de bloques (jump blocks). Aunque la rentabilidad de estas estrategias es ampliamente conocida, el motivo por el que los líderes eligen no jugar estos juegos, principalmente, es para actuar como buenos administradores de la blockchain. Sin embargo, esta es una balanza social frágil. En cuanto un operador de nodos individual empiece a jugar estas estrategias para obtener recompensas más altas sin consecuencias, otros operadores se unirán rápidamente.

Los Timing Games son solo un ejemplo de cómo el líder puede aumentar sus ganancias sin aprovechar suficientemente su poder de mercado. Un líder también puede tomar muchas otras medidas que incrementen sus recompensas a expensas de las aplicaciones. Consideradas aisladamente, estas medidas pueden ser viables para las aplicaciones, pero eventualmente el balance se inclina hacia un punto en el que el costo de hacer operaciones on-chain supera los beneficios.

Otro factor que mantiene DeFi funcionando es que las aplicaciones mueven la lógica importante a off-chain y solo publican en on-chain el resultado. Por ejemplo, cualquier protocolo que necesite subastas rápidas las ejecuta en off-chain. Estas aplicaciones normalmente operan sus mecanismos requeridos en un conjunto de nodos con permisos para evitar problemas con líderes maliciosos. Por ejemplo, UniswapX ejecuta sus subastas holandesas fuera de la red principal de Ethereum para completar las operaciones; de manera similar, CowSwap ejecuta sus subastas por lotes fuera de la cadena.

Aunque esto funciona para las aplicaciones, deja la propuesta de valor que construye la capa base con la construcción on-chain en una posición precaria. En el mundo donde la lógica de ejecución está en off-chain, la capa base se convierte simplemente en una capa de liquidación. Uno de los puntos más fuertes de DeFi es la composabilidad. Cuando toda la ejecución ocurre en el mundo off-chain, estas aplicaciones esencialmente viven en un entorno aislado. Depender de la ejecución off-chain también añade nuevas suposiciones al modelo de confianza de estas aplicaciones. Ya no basta con que la cadena subyacente esté activa; esta infraestructura off-chain también debe operar correctamente.

Cómo lograr previsibilidad

Para resolver estos problemas, necesitamos que los protocolos cumplan dos propiedades: reglas consistentes de empaquetado y ordenamiento, y privacidad de las transacciones antes de su confirmación (para definiciones estrictas y discusión ampliada de estas propiedades, consulte este paper).

Demanda fundamental 1: resistencia a la censura

Resumimos la primera propiedad con la resistencia a la censura a corto plazo. Si cualquier transacción que llegue a un nodo honesto está garantizada para incluirse en el siguiente bloque posible, entonces el protocolo es resistente a la censura a corto plazo:

Resistencia a la censura a corto plazo: Cualquier transacción válida que llegue a tiempo a cualquier nodo honesto debe ser necesariamente empaquetada en el siguiente bloque posible.

Más precisamente, asumimos que el protocolo opera sobre un reloj fijo, donde cada bloque se genera en un tiempo establecido; por ejemplo, cada 100 milisegundos. Lo que necesitamos garantizar es que, si una transacción llega a un nodo honesto en t=250ms, se incluya en el bloque generado en t=300ms. El adversario no debe tener el poder de seleccionar y omitir de forma discrecional algunas de las transacciones que escucha.

El espíritu de esta definición es que los usuarios y las aplicaciones deberían tener una forma extremadamente confiable de hacer que las transacciones se materialicen en cualquier momento. No debería ocurrir que un nodo en particular, por casualidad, pierda paquetes (ya sea por mala intención o por un fallo simple de funcionamiento) y la transacción no pueda materializarse. Aunque esta definición exige garantías de empaquetado para transacciones que llegan a cualquier nodo honesto, en la práctica lograrlas puede ser demasiado costoso. Lo importante es que el protocolo sea robusto, de modo que el comportamiento en el punto de entrada on-chain sea altamente predecible y fácil de razonar.

Los protocolos de líder único sin permiso obviamente no satisfacen esta propiedad, porque si en cualquier momento el único líder es un nodo bizantino, no hay otra forma de que la transacción se materialice. Sin embargo, incluso un conjunto de cuatro nodos que pueda garantizar incluir transacciones en cada período mejora enormemente las opciones con las que los usuarios y las aplicaciones pueden hacer que sus transacciones se materialicen. Vale la pena sacrificar cierta cantidad de rendimiento a cambio de un protocolo que, de forma confiable, permita que las aplicaciones prosperen. Todavía hay más trabajo por hacer para encontrar el punto correcto de equilibrio entre robustez y rendimiento, pero las garantías proporcionadas por los protocolos actuales no son suficientes.

Dado que el protocolo puede garantizar el empaquetado, el ordenamiento es, en cierto sentido, algo natural. El protocolo puede usar libremente cualquier regla de ordenamiento determinista que desee para garantizar un orden consistente. La solución más simple es ordenar por prioridad de fee, o quizá permitir que las aplicaciones ordenen con flexibilidad las transacciones con las que interactúan según su estado. La mejor manera de ordenar transacciones sigue siendo un campo de investigación activo; de todos modos, las reglas de ordenamiento solo tienen sentido sobre la base de que haya transacciones cuyo empaquetado se requiera.

Demanda fundamental 2: ocultación

Después de la resistencia a la censura a corto plazo, la siguiente propiedad más importante es que el protocolo proporcione una forma de privacidad que llamamos “ocultación” (hidden).

Ocultación: Antes de que el protocolo finalice qué transacciones se empaquetarán, ninguna parte que no sea el nodo que recibe la transacción enviada puede obtener ninguna información sobre esa transacción.

Un protocolo con la propiedad de “ocultación” puede permitir que los nodos vean todas las transacciones que se les envían en texto plano, pero exige que el resto del protocolo permanezca ciego hasta que se alcance el consenso y el orden de las transacciones quede determinado en el registro final. Por ejemplo, el protocolo podría usar cifrado con un bloqueo temporal (time-lock) para ocultar todo el contenido del bloque hasta una fecha límite; o el protocolo podría usar cifrado por umbral (threshold) para que el bloque se descifre inmediatamente después de que el comité acuerde confirmarlo de forma irreversible.

Esto significa que los nodos podrían abusar de la información obtenida de cualquier transacción enviada a ellos, pero el resto del protocolo no sabrá el contenido en el que se alcanzó consenso hasta después del hecho. Cuando se divulga la información de la transacción al resto de la red, la transacción ya está ordenada y confirmada, por lo que ninguna otra parte puede adelantarse (front-run) en respuesta. Para que esta definición sea útil, de hecho significa que múltiples nodos pueden hacer que las transacciones se materialicen en cualquier período dado.

Renunciamos a utilizar un concepto más fuerte en el que los usuarios solo conocen alguna información de la transacción después de que esta se confirme (por ejemplo, en un mempool cifrado) porque el protocolo necesita tomar algunas medidas como filtro para transacciones basura. Si el contenido de una transacción está completamente oculto para toda la red, entonces la red no puede separar las transacciones basura de las transacciones con significado. La única forma de resolver este problema es revelar cierta metainformación no oculta como parte de la transacción; por ejemplo, la dirección del pagador de la tarifa, que se cobra independientemente de si la transacción es válida o no.

Sin embargo, esta metainformación podría filtrar suficiente información para que el adversario la utilice. Por ello, preferimos que un único nodo tenga visibilidad completa sobre las transacciones y que los demás nodos en la red no tengan visibilidad alguna. Pero esto también implica que, para que esta propiedad sea útil, los usuarios deben contar con al menos un nodo honesto como punto de entrada on-chain en cada período para materializar las transacciones.

Un protocolo que posea tanto resistencia a la censura a corto plazo como ocultación ofrece una base ideal para construir aplicaciones financieras. Volviendo al ejemplo de intentar ejecutar subastas on-chain: ambas propiedades resuelven directamente la forma en que Bob podría hacer que el mercado colapse. Bob no puede censurar la puja de Alice, ni puede usar la puja de Alice para proporcionarle información a su propia puja, lo cual resuelve exactamente el problema de nuestro ejemplo anterior.

Con resistencia a la censura a corto plazo, cualquiera que envíe una transacción (ya sea una transacción o una puja de subasta) puede garantizar que se empaquetará de inmediato. Los market makers pueden cambiar sus órdenes; los pujadores pueden ofertar rápidamente; la liquidación puede materializarse de forma eficiente. Los usuarios pueden estar seguros de que cualquier acción que tomen se ejecutará de inmediato. A su vez, esto permitirá que la próxima generación de aplicaciones financieras del mundo real con baja latencia se construya completamente sobre la cadena.

Para que una blockchain compita de verdad con la infraestructura financiera existente, e incluso la supere, no solo necesitamos resolver el problema del throughput. Además, debemos garantizar que las transacciones puedan ser empaquetadas y ordenadas de manera predecible y segura, incluso en presencia de líderes maliciosos o con incentivos perversos, y que la privacidad de las transacciones esté protegida hasta que se confirme su inclusión en la cadena. Solo así podremos construir una infraestructura financiera verdaderamente moderna, confiable y competitiva a nivel global, capaz de soportar las demandas de los mercados más sofisticados y de los casos de uso más exigentes, incluyendo los Jump blocks.