Las blockchains ya pueden afirmar con fundamento que disponen de la capacidad necesaria para competir con la infraestructura financiera tradicional. Actualmente, los sistemas en producción son capaces de procesar decenas de miles de transacciones por segundo, y se prevén mejoras exponenciales en el futuro próximo.
Pero más allá del rendimiento puro, las aplicaciones financieras requieren previsibilidad. Cuando se envía una transacción (ya sea una operación, una puja en una subasta o el ejercicio de una opción), es imprescindible contar con una garantía fiable sobre el momento en que esa transacción se confirmará para el correcto funcionamiento de los sistemas financieros. Si las transacciones sufren retrasos imprevisibles (ya sea por motivos adversos o fortuitos), muchas aplicaciones dejan de ser funcionales. Para que las aplicaciones financieras onchain sean competitivas, la cadena debe ofrecer garantías de inclusión a corto plazo: si se envía una transacción válida a la red, debe garantizarse su inclusión lo antes posible.
Por ejemplo, pensemos en un libro de órdenes onchain. Para que un libro de órdenes sea eficiente, los market makers deben aportar liquidez de forma continua, manteniendo órdenes de compra y venta de los activos en el libro. El principal reto para los market makers es mantener un spread (la diferencia entre el precio de compra y de venta) lo más ajustado posible sin exponerse a una selección adversa ofreciendo precios desalineados con el mercado. Para lograrlo, tienen que actualizar constantemente sus órdenes reflejando el estado del mercado. Por ejemplo, si un anuncio de la Reserva Federal provoca una subida repentina de precios, los market makers deben reaccionar de inmediato actualizando sus órdenes al nuevo precio. Si las transacciones para actualizar esas órdenes no se confirman instantáneamente, sufrirán pérdidas al ejecutarse órdenes a precios desfasados por parte de arbitrajistas. Como consecuencia, los market makers se verán obligados a ampliar los spreads para reducir su exposición a estos eventos, lo que hace que los mercados onchain pierdan competitividad.
La inclusión predecible de transacciones es lo que permite a los market makers reaccionar rápidamente ante eventos offchain y mantener la eficiencia de los mercados onchain.
Qué tenemos frente a lo que necesitamos
Hoy en día, las cadenas existentes solo ofrecen garantías sólidas de inclusión eventual, que se cumplen en cuestión de segundos. Aunque estas garantías resultan adecuadas para aplicaciones como los pagos, son insuficientes para una gran variedad de aplicaciones financieras en las que los participantes necesitan reaccionar en tiempo real. Volviendo al ejemplo del libro de órdenes: para los market makers, una garantía de inclusión "en los próximos segundos" resulta irrelevante si las transacciones de los arbitrajistas pueden confirmarse en bloques anteriores. Sin garantías sólidas de inclusión, los market makers deben asumir un mayor riesgo de selección adversa, ampliando los spreads y ofreciendo peores precios a los usuarios. Esto, a su vez, reduce el atractivo del trading onchain frente a otras plataformas que sí ofrecen garantías más estrictas.
Para que las blockchains puedan cumplir realmente su función como infraestructura para la modernización de los mercados de capitales, es necesario resolver estos desafíos y permitir que aplicaciones de alto valor como los libros de órdenes prosperen.
¿Por qué es tan difícil lograr previsibilidad?
Reforzar la garantía de inclusión en las cadenas actuales para estos casos de uso es un reto. Algunos protocolos dependen de un único nodo (el "líder") que decide qué transacciones se incluyen en cada momento. Esto simplifica el desarrollo de una cadena eficiente, pero introduce un punto de control económico donde el líder puede extraer valor. Por lo general, mientras un nodo es líder, tiene control total sobre qué transacciones se incluyen en el bloque.
En una cadena con actividad financiera, el líder ocupa una posición privilegiada. Si decide no incluir una transacción, solo queda esperar al siguiente líder dispuesto a incluirla. En una red sin permisos, los líderes están incentivados a extraer valor, conocido como MEV. El MEV va mucho más allá de prácticas como el sandwiching en operaciones AMM. Incluso retrasar la inclusión de una transacción por unos milisegundos puede reportar grandes beneficios y reducir la eficiencia de las aplicaciones. Un libro de órdenes que prioriza solo ciertas transacciones deja al resto de traders en desventaja. En el peor de los casos, el líder puede actuar de forma tan adversa que los traders abandonen la plataforma.
Imaginemos una subida de tipos que provoca una caída inmediata del 5 % en el precio de ETH. Todos los market makers de un libro de órdenes se apresuran a cancelar sus órdenes pendientes y crear nuevas a los nuevos precios. Simultáneamente, los arbitrajistas envían órdenes para vender ETH a las órdenes antiguas. Si el libro de órdenes opera en un protocolo con un solo líder, este tiene un poder desmesurado: podría censurar todas las cancelaciones de los market makers, permitiendo así que los arbitrajistas obtengan enormes beneficios. O podría retrasar las cancelaciones hasta que los arbitrajistas hayan ejecutado sus transacciones. Incluso podría insertar sus propias operaciones de arbitraje para aprovechar la discrepancia de precios.
Una historia de dos desiderata: la necesidad de resistencia a la censura y de ocultación
Ante tales ventajas, para los market makers deja de ser rentable participar: cada vez que hay un movimiento de precio pueden ser perjudicados. El problema radica en que el líder cuenta con dos privilegios clave: 1) puede censurar transacciones de otros, y 2) puede ver las transacciones ajenas y responder enviando las suyas propias. Cualquiera de estos problemas puede ser catastrófico.
Un ejemplo
Ilustremos el problema con un ejemplo. Supongamos una subasta con dos postores, Alice y Bob, donde Bob es también el líder del bloque en el que se produce la subasta. (Que solo haya dos postores es por simplicidad; el razonamiento es válido con cualquier número de participantes).
La subasta acepta ofertas durante el tiempo de producción del bloque, por ejemplo de t=0 a t=1. Alice envía una oferta bA en tA y Bob una oferta bB en tB > tA. Como Bob es el líder, siempre puede actuar en último lugar. Ambos disponen de información continuamente actualizada sobre el precio del activo (por ejemplo, el precio medio en un exchange centralizado). En t, ese precio es pt. Suponemos que en t, el precio esperado del activo en t=1 (cuando concluye la subasta) es siempre pt. Es decir, en todo momento, el precio que esperan Alice y Bob al cierre de la subasta es igual al que ven en ese instante. Las reglas de la subasta son sencillas: quien haga la oferta más alta gana y paga su puja.
La necesidad de resistencia a la censura
Si Bob puede censurar la oferta de Alice, la subasta carece de sentido. Bob puede pujar una cantidad mínima y garantizar la victoria, ya que no hay competencia. Así, la subasta se cierra prácticamente sin ingresos.
La necesidad de ocultación
El caso más complejo es cuando Bob no puede censurar la oferta de Alice, pero sí verla antes de hacer la suya. En este caso, Bob sigue una estrategia simple: comprueba si ptB > bA. Si es así, puja apenas por encima de bA; si no, no puja. De este modo, Bob perjudica a Alice. La única vez que Alice gana es si el precio cambia y su oferta resulta superior al valor esperado del activo. Siempre que gane, espera perder dinero y le convendría no participar. Sin competencia, Bob puede volver a pujar una cantidad mínima y ganar, con la subasta quedando de nuevo sin ingresos.
La conclusión es que no importa cuánto dure la subasta. Mientras Bob pueda censurar la oferta de Alice o verla antes de pujar, la subasta está condenada.
Estos principios se aplican a cualquier entorno de negociación de activos a alta frecuencia, ya sea trading de spot, perps o exchanges de derivados: si existe un líder con el poder de Bob, puede hacer colapsar el mercado. Para que los productos onchain sean viables en estos casos de uso, no deben otorgar estos poderes al líder.
¿Cómo se manifiestan estos problemas en la práctica?
El panorama descrito es desalentador para el trading onchain en protocolos sin permisos y con un solo líder. Sin embargo, los volúmenes de los exchanges descentralizados (DEX) en muchos de estos protocolos siguen siendo elevados. ¿Por qué?
En la práctica, dos factores contrarrestan estos problemas:
-
Los líderes no explotan por completo su poder económico, ya que suelen estar fuertemente invertidos en el éxito de la cadena, y
-
Las aplicaciones han desarrollado soluciones para reducir su vulnerabilidad.
Estos factores han permitido que las finanzas descentralizadas (DeFi) funcionen hasta ahora, pero no bastarán para que los mercados onchain sean realmente competitivos frente a los offchain a largo plazo.
Para ser líder en una cadena con actividad económica relevante se requiere una gran cantidad de stake. Por tanto, el líder o bien posee mucho stake, o bien tiene la reputación suficiente para que otros holders le deleguen el suyo. En ambos casos, los grandes operadores de nodos suelen ser entidades conocidas y con reputación en juego. Más allá de la reputación, el stake implica que tienen incentivos financieros para que la cadena funcione bien. Por eso, hasta ahora, los líderes no han explotado plenamente su poder de mercado como se describe arriba, aunque eso no significa que el problema no exista.
Depender de la buena voluntad de los operadores de nodos y de sus incentivos a largo plazo no es una base robusta para el futuro de las finanzas. A medida que crece la actividad financiera onchain, los beneficios potenciales de los líderes aumentan. Cuanto mayor es este potencial, más difícil resulta que la presión social frene el comportamiento contrario a los intereses inmediatos de los líderes.
Además, el grado en que los líderes pueden usar su poder de mercado es un espectro, desde acciones benignas hasta provocar el colapso del mercado. Los operadores de nodos pueden tomar decisiones unilaterales para aumentar sus beneficios. Si algunos llevan al límite lo aceptable, otros les siguen. El comportamiento de un nodo puede parecer insignificante, pero cuando todos cambian, el impacto es evidente.
Quizá el mejor ejemplo sean los juegos de temporización: líderes que retrasan el anuncio de un bloque al máximo permitido para obtener mayores recompensas. Esto puede alargar los tiempos de bloque y provocar bloques saltados si el líder es demasiado agresivo. Aunque la rentabilidad de estas estrategias era conocida, los líderes preferían no usarlas por responsabilidad hacia la cadena. Pero este equilibrio social era frágil. Cuando un operador empezó a emplear estas estrategias sin consecuencias, otros se sumaron rápidamente. Los juegos de temporización son solo un ejemplo de cómo los líderes pueden aumentar sus beneficios sin explotar al máximo su poder de mercado. Hay muchas otras medidas que pueden tomar en detrimento de las aplicaciones. Por separado, pueden ser asumibles, pero con el tiempo los costes de operar onchain superan los beneficios.
El otro factor que ha mantenido funcional a DeFi es que las aplicaciones trasladan la lógica clave fuera de la cadena, publicando solo los resultados onchain. Por ejemplo, cualquier protocolo que necesite ejecutar una subasta rápidamente lo hace fuera de la cadena. Estas aplicaciones suelen operar sobre un conjunto de nodos con permisos para evitar problemas con líderes adversos. Por ejemplo, UniswapX realiza su subasta holandesa para completar operaciones en Ethereum mainnet fuera de la cadena, y Cowswap ejecuta su subasta por lotes también offchain. Aunque esto funciona para las aplicaciones, deja a la capa base y al valor de construir onchain en una posición precaria. Si toda la lógica de ejecución reside fuera de la cadena, la capa base se convierte en un mero sistema de liquidación. Uno de los grandes atractivos de DeFi es la composabilidad. Si toda la ejecución ocurre fuera de la cadena, estas aplicaciones quedan aisladas. Además, depender de la ejecución offchain añade nuevas dependencias al modelo de confianza: además de la disponibilidad de la cadena, la infraestructura offchain también debe estar operativa.
Cómo lograr previsibilidad
Para abordar estos retos, el protocolo debe cumplir dos propiedades: inclusión y ordenación de transacciones consistentes, y privacidad de las transacciones antes de la confirmación (para una definición rigurosa y discusión ampliada, véase https://arxiv.org/abs/2509.23984, especialmente definiciones 9 y 11).
Desiderátum n.º 1: Resistencia a la censura
La primera propiedad es la resistencia a la censura a corto plazo. Un protocolo es resistente a la censura a corto plazo si cualquier transacción que llega a un nodo honesto tiene garantizada su inclusión en el siguiente bloque posible:
Resistencia a la censura a corto plazo: cualquier transacción válida que llegue a un nodo honesto a tiempo será incluida con certeza en el siguiente bloque posible.
En detalle, supongamos que el protocolo opera con un reloj fijo y cada bloque se produce en momentos determinados, por ejemplo cada 100 ms. Queremos la garantía de que si una transacción llega a un nodo honesto en t=250 ms, se incluirá en el bloque producido en t=300 ms. Un adversario no debe poder incluir selectivamente unas transacciones y dejar fuera otras. El propósito de esta definición es que usuarios y aplicaciones dispongan de una vía extremadamente fiable para confirmar transacciones en cualquier momento. No debe suceder que un nodo, por malicia o por fallos operativos, provoque que una operación no se confirme.
Aunque esta definición exige garantías de inclusión para las transacciones que llegan a cualquier nodo honesto, en la práctica el coste puede ser elevado. Lo importante es que el protocolo sea robusto y que los puntos de entrada onchain se comporten de forma predecible y sencilla de entender. Un protocolo sin permisos y con un solo líder no cumple esta propiedad, porque si el líder es bizantino, no hay otra vía para confirmar una transacción. Sin embargo, incluso un conjunto de cuatro nodos que garantice la inclusión en cada slot mejora enormemente las opciones para usuarios y aplicaciones. Compensa sacrificar algo de rendimiento a cambio de un protocolo que permita prosperar a las aplicaciones. Aún queda trabajo para encontrar el equilibrio entre robustez y rendimiento, pero las garantías actuales no son suficientes.
Si un protocolo garantiza la inclusión, el ordenamiento viene casi por defecto. Los protocolos pueden emplear cualquier regla determinista para garantizar un orden consistente. La solución más sencilla es ordenar por prioridad de tarifa o permitir que las aplicaciones tengan flexibilidad para ordenar las transacciones que afectan a su estado. La forma óptima de ordenar sigue siendo objeto de investigación, pero en cualquier caso, las reglas de orden solo importan si las transacciones llegan a confirmarse.
Desiderátum n.º 2: Ocultación
La segunda propiedad clave es que el protocolo proporcione una forma de privacidad denominada ocultación.
Ocultación: ninguna parte, salvo el nodo al que se envía una transacción, conoce información alguna sobre la transacción antes de que su inclusión haya sido finalizada por el protocolo.
Un protocolo con ocultación puede permitir que los nodos vean todas las transacciones que reciben en texto claro, pero exige que el resto del protocolo permanezca ciego hasta que se alcance el consenso y el orden de la transacción ya esté determinado. Por ejemplo, el protocolo podría emplear cifrado con bloqueo temporal para ocultar el contenido del bloque hasta un momento concreto, o cifrado umbral para descifrar el bloque cuando un comité confirme su irreversibilidad.
Esto significa que un nodo puede abusar de la información de las transacciones que recibe, pero el resto del protocolo no conoce el contenido hasta después de alcanzar el consenso. Cuando la información se revela al resto de la red, la transacción ya ha sido ordenada y confirmada, así que nadie puede anticiparse. Para que esta definición sea útil, varios nodos deben poder confirmar transacciones en un mismo slot.
No se opta por la versión más estricta (donde solo el usuario conoce su transacción antes de la confirmación, como en los mempools cifrados), porque el protocolo necesita algún mecanismo para filtrar transacciones spam. Si el contenido está totalmente oculto, la red no puede filtrar las transacciones basura. La única alternativa sería filtrar algunos metadatos no cifrados, como una dirección pagadora de tarifas que se cobre independientemente de la validez de la transacción. Sin embargo, estos metadatos pueden revelar suficiente información para que un adversario se aproveche. Por eso se prefiere que un solo nodo tenga visibilidad total, pero el resto de la red no tenga ninguna. Para que esta propiedad sea útil, el usuario debe contar con al menos un nodo honesto como punto de entrada en cada slot.
Un protocolo que sea resistente a la censura a corto plazo y proporcione ocultación es la base ideal para construir aplicaciones financieras. Volviendo al ejemplo de la subasta onchain, estas dos propiedades abordan directamente las formas en que Bob podría hacer colapsar el mercado: Bob no puede censurar la oferta de Alice ni usarla para influir en la suya, resolviendo así los problemas 1) y 2) del ejemplo. (Para más detalles, véase este preprint reciente.)
Con resistencia a la censura a corto plazo, cualquiera que envíe una transacción (ya sea una operación o una puja) tiene garantizada la inclusión instantánea. Los market makers pueden modificar órdenes; los postores pueden pujar rápidamente; las liquidaciones se ejecutan de forma eficiente. Los usuarios pueden confiar en que cualquier acción será ejecutada de inmediato. Esto permitirá que la próxima generación de aplicaciones financieras de baja latencia y del mundo real se construyan totalmente onchain. Para que las blockchains compitan y superen el rendimiento de la infraestructura financiera existente, debemos resolver mucho más que el simple throughput.
Las opiniones expresadas aquí pertenecen únicamente al personal de AH Capital Management, L.L.C. (“a16z”) citado y no representan las opiniones de a16z ni de sus filiales. Parte de la información ha sido obtenida de fuentes externas, incluidas empresas de la cartera de fondos gestionados por a16z. Aunque se considera fiable, a16z no ha verificado la información ni ofrece garantías sobre su exactitud o idoneidad. Este contenido puede incluir anuncios de terceros; a16z no los ha revisado ni respalda su contenido.
Consulte a sus propios asesores sobre estos temas. Las referencias a valores o activos digitales son solo ilustrativas y no constituyen una recomendación de inversión ni una oferta de servicios de asesoramiento. Además, este contenido no está dirigido ni destinado a inversores o posibles inversores, y no puede considerarse base para invertir en ningún fondo gestionado por a16z. (La oferta de inversión en un fondo de a16z solo se realizará mediante el memorando de colocación privada, el acuerdo de suscripción y demás documentación relevante, que debe leerse en su totalidad). Las inversiones o empresas de cartera mencionadas no representan todas las inversiones de los vehículos gestionados por a16z, y no se garantiza que sean rentables ni que futuras inversiones tengan características similares. Puede consultar la lista de inversiones realizadas por fondos gestionados por Andreessen Horowitz (excluyendo aquellas no autorizadas para divulgación pública y las inversiones no anunciadas en activos digitales cotizados) en https://a16z.com/investment-list/.
El contenido solo es válido a la fecha indicada. Cualquier proyección, estimación, previsión, objetivo, expectativa u opinión expresada en estos materiales está sujeta a cambios sin previo aviso y puede diferir de otras opiniones. Consulte https://a16z.com/disclosures/ para más información importante.
Descargo de responsabilidad:
-
Este artículo es una reimpresión de [a16zcrypto]. Todos los derechos de autor pertenecen al autor original [@PGarimidi,@jneu_net, y @MaxResnick]. Si tiene alguna objeción a esta reimpresión, póngase en contacto con el equipo de Gate Learn, que lo gestionará de inmediato.
-
Descargo de responsabilidad: Las opiniones expresadas en este artículo pertenecen únicamente al autor y no constituyen asesoramiento de inversión.
-
Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. Salvo que se indique lo contrario, está prohibido copiar, distribuir o plagiar los artículos traducidos.
