Introducción a las intenciones y las Arquitecturas centradas en las intenciones
Por Awa Sun Yin In Anoma Basics — Sep 25, 2023
Artículo original: https://anoma.net/blog/an-introduction-to-intents-and-Intent-centric-architectures
Todas las aplicaciones tienen un elemento primitivo en común: la intención. Los mecanismos descentralizados de cumplimiento de intenciones son específicos de cada aplicación y, hasta ahora, nadie ha propuesto uno que sea generalizado y capaz de cumplir cualquier intención.
Todas las arquitecturas para aplicaciones descentralizadas hasta ahora son centradas en blockchain, donde todo gira en torno a la existencia y necesidad de una blockchain, lo que limita severamente el espacio de diseño, poniendo un techo a las propiedades que las arquitecturas pueden ofrecer y un límite a qué aplicaciones se puede construir sobre ellas.
Anoma es la primera arquitectura centrada en la intención que se libera de cualquier restricción existente, incluso si necesitamos una blockchain (para cualquier cosa fuera de la liquidación) para empezar. Más bien, el punto de partida es preguntarnos: ¿qué necesitan las aplicaciones? En esta búsqueda, tenemos en cuenta todo tipo de aplicaciones que existen hoy en día: descentralizadas, centralizadas e incluso aquellas que no se pueden construir sobre arquitecturas web2 ni web3.
Resulta que todas las aplicaciones tienen una primitiva en común: la intención.
Resumen:
- Las intenciones y las aplicaciones pueden tener complejidad arbitraria.
- Los mecanismos descentralizados de cumplimiento de intenciones son específicos de cada aplicación y aún no se ha propuesto uno que sea generalizado y capaz de cumplir cualquier intención.
- Un beneficio de una arquitectura centrada en intención es que proporciona las propiedades de intenciones generalizadas, descubrimiento de contrapartes, resolución y liquidación, lo que es suficiente para habilitar todas las aplicaciones existentes, pero con descentralización de extremo a extremo.
- Las arquitecturas centradas en intención son compatibles con las arquitecturas centradas en blockchain y se pueden usar de múltiples formas, como L1, L1.5 o incluso L2; depende de los desarrolladores de dApp.
- También ofrecen propiedades novedosas que pueden habilitar dApps que aún no hemos imaginado, y es demasiado temprano para decir dónde están los límites.
¿Qué son las intenciones?
Una intención es lo que el individuo desea que suceda. Siempre que una persona necesita algo, genera subconscientemente una intención. Esto puede ser cualquier cosa, desde querer pescado, café, una pizza, o incluso un NFT:
Las intenciones siempre han estado ahí, solo que no éramos conscientes de ellas. Los humanos empezaron a tener intenciones mucho antes de interactuar con software, computadoras, dinero o sistemas de trueque. Y ahora, todos estamos generando intenciones en nuestras mentes.
Lo que ha evolucionado drásticamente es la cantidad y diversidad de mecanismos que las personas pueden usar para cumplir sus intenciones. En comparación con el año 6000 a.C. en Mesopotamia, cuando apareció el primer sistema de trueque, hoy tenemos muchos más mecanismos, incluyendo monedas fiduciarias, infraestructura TradFi, Bitcoin y Ethereum:
Todos los mecanismos existentes para cumplir las intenciones son no fungibles, cada uno con diferentes propiedades y compensaciones. Además, son no excluyentes, lo que significa que los individuos pueden usar múltiples mecanismos simultáneamente, dependiendo de cuál ofrezca las mejores propiedades y compensaciones para cada intención que deseen cumplir.
Este artículo se centra en las intenciones relacionadas con aplicaciones descentralizadas (dApps) y los mecanismos descentralizados capaces de cumplir dichas intenciones.
Intenciones y aplicaciones descentralizadas
Existen aplicaciones lo suficientemente simples como para ser habilitadas con una sola intención. También hay aplicaciones más complejas que pueden ser habilitadas por una única intención, ya que una intención puede contener niveles arbitrarios de complejidad:
Puede que no estés de acuerdo con algunas comparaciones en la figura 3, pero al menos es fácil estar de acuerdo en que una intención de pago (compra de pizza con BTC) es mucho más sencillo que un voto de financiación cuadrática. Lo interesante es que la aplicación más simple que solo requiere una intención es un pago. Cualquier otra dApp requerirá más de una parte y también más clases de intenciones:
Puede ser difícil estar de acuerdo con la posición de cada dApp en la Figura 4, pero es fácil coincidir en que una dApp de pago en ETH es sustancialmente más sencilla que una ronda de financiación cuadrática de Gitcoin en Ethereum o que un sistema monetario basado en SALSA como Plural Money.
Otra observación es que, cuanto más simple es la dApp, más mecanismos existen para cumplirla; cuanto más compleja es la dApp, menos mecanismos existen hoy en día para cumplirla.
Por ejemplo, una intención de pago puede cumplirse a través de muchos mecanismos: monedas fiduciarias, sistemas TradFi como transferencias o tarjetas de crédito, o criptomonedas, por nombrar algunos, cada uno con diferentes propiedades y compensaciones. Pero las opciones disminuyen significativamente cuando se trata de mecanismos que pueden facilitar aplicaciones más complejas, como subastas combinatorias y sus intenciones, y las opciones se vuelven aún menos claras cuando hablamos de sistemas económicos de nueva era, como los de Game B, como Plural Money, CoFi o Heterotopia (dinero sin escalas).
Una observación muy crítica es que probablemente existan aplicaciones e intenciones aún más interesantes y complejas que aún no hemos considerado. Y una observación final, pero fundamental, es que cualquier aplicación puede ser representada por intenciones (ver intenciones como CSPs).
Existen muchos mecanismos descentralizados que pueden cumplir intenciones específicas de aplicaciones, pero aún no se ha propuesto un mecanismo que sea lo suficientemente general y escalable como para cumplir cualquier intención y habilitar cualquier dApp, sin importar la complejidad, el número de partes únicas involucradas, las categorías discretas de partes participantes, y el volumen total de intenciones involucrados en la aplicación.
Arquitecturas centradas en intenciones
Una arquitectura centrada en intenciones es aquella en la que la primitiva más fundamental es la intención y donde las intenciones no son específicas de una aplicación, sino generalizadas. En las arquitecturas centradas en intenciones, los usuarios definen uno o varios estados finales que desean alcanzar, y la arquitectura está diseñada para cumplir la intención respetando las restricciones que el usuario ha definido.
Otra forma de ver una arquitectura centrada en intenciones es como un diseño para un mecanismo de cumplimiento de intención generalizado.
Las arquitecturas centradas en las intenciones vienen con muchas ventajas:
- Proporcionan todas las propiedades que las dApps existentes necesitan: intenciones generalizadas, descubrimiento de contrapartes, resolución y liquidación.
- Proporcionan propiedades novedosas para las dApps: incluyendo escalabilidad local y global, control del flujo de información, ordenamiento configurable, liquidación configurable e identidad composicional.
- Imponen un paradigma declarativo para las aplicaciones.
- Resultan en estructuras de mercado tan descentralizadas como sea posible, sujetas a restricciones exógenas como los límites de los sistemas distribuidos y la física, donde los usuarios, a través de sus intenciones y acciones, definen qué estructuras de mercado desean.
Hay mucho que desglosar aquí, pero en este artículo me centraré en (1) las arquitecturas centradas en las intenciones que proporcionan todas las propiedades necesarias para las dApps existentes.
¿Qué propiedades necesitan las aplicaciones descentralizadas?
Defino propiedad como una característica que una arquitectura o protocolo de infraestructura proporciona a las dApps. Por ejemplo, la liquidación programable es la propiedad clave que las arquitecturas centradas en blockchain, como Ethereum, proporcionan a las dApps.
El punto de partida de una arquitectura centrada en la intención es: ¿qué propiedades necesitan las aplicaciones descentralizadas?
Una forma de responder a esta pregunta es observando la arquitectura de las dApps más complejas en el ecosistema de Ethereum: los mercados de NFT (OpenSea, Blur), los DEX basados en libros de órdenes o conscientes de MEV (0x, 1inch, CoWSwap), y el Financiamiento Cuadrático (Gitcoin). Todas ellas requieren las siguientes propiedades: intenciones, descubrimiento de contrapartes, resolución y liquidación.
Intenciones, descubrimiento de contrapartes, resolución y liquidación en arquitecturas centradas en blockchain
Las arquitecturas centradas en blockchain, como Ethereum, proporcionan una propiedad clave: la liquidación programable, que es suficiente para habilitar aplicaciones que sean descentralizadas de extremo a extremo, donde intenciones, descubrimiento de contrapartes y resolución se implementan en la blockchain. Esto es suficiente para algunas dApps, por ejemplo, la creación de tokens fungibles y no fungibles, DAOs o formas simples de DeFi como ventas de tokens, subastas o DEXs basados en AMM. Hasta ahora, los creadores de dApps han probado los límites de lo que se puede construir completamente en Ethereum, y la dApp más compleja y práctica para usar de extremo a extremo hasta la fecha es Uniswap 3.
Pero esta ruta no es viable para dApps más complejas en el ecosistema de Ethereum. En su lugar, persiguen lo que yo denomino arquitecturas Gen 2.5, donde la transacción final se liquida en Ethereum, pero dependen de componentes web2 para intenciones, descubrimiento de contrapartes y resolución.
Para mitigar los puntos de centralización, un número creciente de dApps Gen 2.5 están siguiendo el camino de diseño blockchain-to-decentralize-X, que consiste en desplegar una cadena soberana que proporcione las propiedades necesarias para la dApp además de la liquidación en Ethereum.
Desplegar una blockchain parece una solución fácil de adaptar que puede mitigar los problemas de centralización actuales, pero solo habilita intenciones específicas de la aplicación en un único modelo de seguridad (también conocido como dominio, por ejemplo, Ethereum), lo que también conlleva limitaciones estructurales: una pérdida de composabilidad y efectos de red, y una experiencia de usuario más desafiante debido a la mayor complejidad en las arquitecturas de las aplicaciones. Además, esto aumenta considerablemente el alcance de los problemas para cada equipo de dApp, que pasó de construir aplicaciones (Solidity y front-ends) a estar a cargo de toda una blockchain.
Intenciones, descubrimiento de contrapartes, resolución y liquidación en arquitecturas centradas en intenciones
Una de las ventajas de una arquitectura centrada en intenciones es que proporciona desde el principio las propiedades necesarias (intenciones, descubrimiento de contrapartes, resolución y liquidación) para cualquier dApp existente. Así es como defino las propiedades:
- Intenciones generalizadas: la capacidad de la arquitectura para procesar intenciones arbitrarias y no estar restringida a intenciones específicas de la aplicación o casos especiales.
- Descubrimiento de contrapartes: un proceso descentralizado mediante el cual las intenciones individuales pueden ser difundidas y accesibles para los solucionadores.
- Resolución: un proceso descentralizado mediante el cual las intenciones se combinan y se calculan a través de una solución válida (transacción) que puede ser liquidada.
- Liquidación: verificación y finalización de las soluciones en la cadena.
A medida que la arquitectura está diseñada para proporcionar más propiedades a las dApps, el alcance de los problemas de un creador de dApp centradas en intenciones se limita a las plantillas de intenciones y los respectivos predicados en la capa de liquidación. Los usuarios de una arquitectura centrada en intenciones solo tienen que preocuparse por definir sus intenciones, que son compromisos vinculantes con su(s) estado(s) final(es) deseado(s).
Las dApps en arquitecturas centradas en intenciones tienen muchas implicaciones, pero una diferencia clave es que las intenciones son completamente componibles. Dado que las intenciones son generalizables, corresponde a los solucionadores determinar qué intenciones pueden formar una solución válida. Esto significa que un solucionador podría proponer una solución que implique 10 intenciones limitadas al comercio de tokens fungibles, pero otro solucionador podría proponer una solución que implique 1.000 intenciones, donde algunos se asemejan a intercambios de tokens fungibles, otros a intercambios de NFTs, o combinaciones de estos, además de intenciones relacionadas con otras aplicaciones.
Otra implicación es que esto es generalizable a través de modelos de seguridad (también conocidos como dominios), lo que significa que las aplicaciones ya no son específicas de un dominio o blockchain, lo que es un resultado interesante de lo que llamo arquitecturas Gen 2++.
Las arquitecturas Gen 2++ se caracterizan por los mismos rasgos arquitectónicos que Ethereum, con variaciones en primitivas específicas, por ejemplo, un consenso diferente (de consenso Nakamoto a, por ejemplo, consenso BFT), mecanismo de resistencia a Sybil (de PoW a PoS), privacidad (de ejecución transparente a privada); u optimizaciones en propiedades específicas, como el rendimiento. Solana, Polkadot y Avalanche son ejemplos de arquitecturas Gen 2++. Sin embargo, la mayoría de las aplicaciones construidas en cada arquitectura Gen 2++ son lógicamente las mismas que las construidas en Ethereum, solo que con diferentes lenguajes para diferentes máquinas virtuales.
Incluso si los usuarios (A, B, C, D) y las dApps son los mismos (Uniswap, OpenSea, CoWSwap, Gitcoin), dado que las dApps son específicas de cada blockchain, las intenciones de los usuarios y las aplicaciones están fragmentados por cada dominio y no pueden ser combinados entre sí. En cambio, en una arquitectura centrada en intenciones, las dApps son completamente generalizables a través de modelos de seguridad. En lugar de obligar al usuario a interactuar con 4 arquitecturas diferentes con ligeras variaciones, es mucho más fácil estandarizar alrededor de un solo lenguaje para las intenciones y una sola interfaz para crear intenciones:
En los ejemplos anteriores, he estado pensando en la instauración de una arquitectura centrada en intenciones como una cadena soberana o L1. Pero otra ventaja de las arquitecturas centradas en intenciones es que ofrece un espectro de propiedades, pero depende de los creadores de dApps decidir qué propiedades tomar. Además, son compatibles con las arquitecturas existentes basadas en blockchain.
Por ejemplo, una dApp puede beneficiarse de las propiedades de intenciones generalizados, descubrimiento de contrapartes y resolución de una arquitectura centrada en intenciones, pero decidir usar la liquidación en otra cadena soberana, lo que significa que la arquitectura centrada en intenciones se utiliza como un L1.5:
Las aplicaciones en este modelo se escriben de manera estándar y no son específicas al modelo de despliegue ni a la capa de liquidación que se utilice, lo cual no es el caso con las dApps en Ethereum o en Solana.
Otra forma en que las dApps pueden usar arquitecturas centradas en intenciones es como un L2.0 o rollup. En este modelo, las dApps procesarían una transición de estado completa (de Anoma, Ethereum o cualquier otra cadena) en la arquitectura centrada en intenciones y desplegarían un verificador ZK para derivar la seguridad de otra blockchain, por ejemplo, Ethereum.
¿Qué aplicaciones pueden habilitar las arquitecturas centradas en intenciones?
La primera generación de arquitecturas fue pionera por Bitcoin y la principal propiedad que Bitcoin y otras criptomonedas proporcionaron a las dApps fue la liquidación programable. La liquidación programable permitió que algunas dApps prosperaran: la emisión descentralizada de monedas y pagos con criptomonedas con diferentes propiedades (por ejemplo, privacidad). Sin embargo, estas propiedades no fueron suficientes para otras dApps que muchos imaginaron, como las monedas coloreadas o la bolsa de valores de Bitcoin, que pueden construirse sobre arquitecturas de liquidación programable, pero que eran limitadas y complicadas.
Ethereum fue pionero en la segunda generación de arquitecturas de liquidación programables, que proporcionaron más expresividad a la capa de liquidación y permitieron más tipos de dApps que la Gen 1, como tokens fungibles y no fungibles, DAOs o formas simples de DeFi como ventas de tokens, subastas o DEX basados en AMM. Hasta ahora, los creadores de dApps han probado los límites de lo que se puede construir completamente en Ethereum (y que sean prácticas de usar), y la dApp más compleja y utilizada hasta la fecha es un AMM, específicamente Uniswap v3. Las arquitecturas Gen 2.5 son de aplicación específica, pero esta arquitectura permite más aplicaciones que no se pueden construir completamente en Ethereum, como los mercados de NFT, DEX basados en libros de órdenes o DEX conscientes de MEV.
La tercera generación de arquitecturas centradas en intenciones habilita todas las aplicaciones de las generaciones 1, 2 y 2.5 con descentralización de extremo a extremo, si sólo consideramos las propiedades básicas de intenciones generalizadas, descubrimiento de contrapartes, resolución y liquidación. Las arquitecturas centradas en intenciones también ofrecen propiedades novedosas que los creadores de dApps ni siquiera han considerado aún, incluyendo: escalabilidad local y global, control de flujo de información, ordenamiento configurable, liquidación configurable e identidad composicional, lo que puede habilitar dApps que son imposibles de construir en las arquitecturas existentes.
Conclusión
Similar a cuando Ethereum fue introducido en un mundo exclusivamente de Bitcoin, donde no estaba claro qué tipo de dApps se podrían construir con el nuevo paradigma, apenas hemos arañado la superficie de qué tipo de aplicaciones se pueden construir con intenciones y la tercera generación de arquitecturas.
