Aperture está construyendo una novedosa experiencia de usuario de chatbot impulsada por una infraestructura subyacente de Intents que permitirá a los usuarios "declarar sus objetivos" en lenguaje natural y aprovechar una red de solucionadores para recibir una mejor ejecución y mejores precios de lo que es posible bajo el paradigma transaccional actual.
Para empezar, empezaremos por la piedra angular de cualquier movimiento de adopción masiva: la experiencia de usuario (UX).
La experiencia de usuario actual de DeFi se centra en un enfoque transaccional que requiere que los usuarios de diversa perspicacia técnica firmen un cambio delta o de estado con la esperanza de que el cambio produzca el "estado final" que tenían en mente. Con Intents, ponemos ese "estado final" al frente y al centro como el punto focal de la experiencia del usuario.
Mediante el uso del poder de los LLM modernos y un lenguaje de programación patentado orientado a las intenciones, buscamos mejorar la expresabilidad de las intenciones del usuario. Esto permitirá a los usuarios articular sus objetivos y preferencias transaccionales de manera más intuitiva y eficiente, aprovechando así el potencial de blockchain con mayor facilidad y precisión.
Imagínese a un usuario que no entiende los principios de la tecnología blockchain, enfrentándose a una gran cantidad de "perillas y botones" en la interfaz tradicional de DeFi. El enfoque de apertura de "permitir que el usuario exprese en lenguaje natural lo que quiere" es más simple. Detrás de esto está la necesidad de convertir el lenguaje natural en código blockchain: aquí es donde entran en juego los lenguajes específicos de dominio (DSL).
Un lenguaje específico de dominio (DSL) es un lenguaje informático especializado adaptado a un dominio de aplicación en particular, que lo distingue de los lenguajes de propósito general (GPL) que son aplicables en un amplio espectro de dominios. El diseño y la utilización de DSL son parte integral de la ingeniería de dominio, y a menudo implican la creación de nuevos DSL o la adaptación de los existentes para expresar problemas y soluciones de manera más efectiva dentro de un dominio específico.
En Aperture, el DSL está diseñado con un enfoque en la legibilidad humana, crucial para respaldar una expresión de intención clara e intuitiva. Este enfoque difiere de otros DSL que pueden priorizar aspectos como la eficiencia programática o la optimización a nivel de máquina.
En Aperture, el LLM cierra la brecha entre la funcionalidad técnica y las interfaces fáciles de usar al permitir que el usuario exprese en lenguaje natural su intención y que esa misma intención se refleje en un DSL altamente legible que luego se puede servir a los solucionadores como la "declaración de la verdad" de este usuario.
Usemos una analogía del mundo real: la experiencia de usuario de traducción de LLM a DSL es similar a la de un cliente que hace un pedido en una pizzería por teléfono. El cliente puede pedir en un lenguaje muy coloquial: "Dame tu pizza con todas las carnes en el tamaño más grande". El operador del otro lado podría replicarles: "¿Quieres nuestra pizza Meat Lover's en una Extra Grande?". El usuario entiende fácilmente esta conversión y acepta: "Sí, no sabía el nombre, pero ese es el que quiero".
En la cadena, esta interacción se desarrollaría de manera similar. El usuario puede comenzar declarando su objetivo final:
"¿Pueden reequilibrar mis LP ETH-GMX en todas mis cadenas EVM para que se concentren en un 80% en la configuración de mayor rendimiento y el 20% restante de mi capital LP se divida uniformemente entre los grupos restantes?"
La traducción DSL puede reflejarse en el usuario:
● Activos elegibles: pares ETH-GMX en Mainnet, Arbitrum y Avalanche;
● Acciones permitidas: Puente, Eliminar liquidez, Intercambiar ETH o GMX, Agregar liquidez;
● Objetivo final 1: Reequilibrar las posiciones de liquidez para concentrar el 80% del capital de activos elegibles en la posición con la APR al contado más alta según los datos de APY Vision;
● Objetivo final 2: Reequilibrar las posiciones de liquidez para concentrar el 20% del capital de activos admisibles en los fondos existentes no utilizados en el objetivo final 1;
● Firmar la declaración de intención si es correcta
La conversión de LLM codificará el lenguaje coloquial en la terminología estandarizada del DSL, que puede ser aprovechada por los solucionadores de una manera predecible y replicable.
La infraestructura de intención se puede dividir en varios componentes:
● Cámara de compensación de intenciones (Mempool): sirve como área de preparación preliminar para las intenciones de los usuarios. Está diseñado para organizar y poner en cola de manera eficiente estas intenciones para su procesamiento, mediante algoritmos que priorizan en función de varios criterios, como la urgencia y los requisitos de recursos. La Cámara de Compensación garantiza la gestión segura y ordenada de las intenciones antes de que se comprometan con la cadena de bloques.
● ZK-Simulate for Data Validity: este es un recurso necesario para validar ciertas intenciones y las soluciones correspondientes que se basarán en datos fuera de la cadena. Se puede utilizar una prueba de conocimiento cero para verificar la validez de estos datos. Utilizando herramientas criptográficas avanzadas como Brevis o Axiom, Aperture puede generar ZKP para datos históricos en cadena que forman parte de la solución propuesta por el solucionador. Este método permite la verificación rigurosa de los resultados del solucionador, lo que garantiza que sean precisos, completos y cumplan con las restricciones e intenciones especificadas, sin comprometer la confidencialidad de los datos de la transacción.
● Contratos inteligentes de verificación: cada tipo de caso de uso de intención requerirá un contrato inteligente para simular, verificar y vigilar la solución propuesta.
● Motor de clasificación y ejecución: cada grupo de intenciones verificadas deberá clasificarse en función de los resultados y la puntuación del solucionador y, posteriormente, ejecutarse. Un aspecto crucial de este motor de ejecución es su capacidad para hacer cumplir la responsabilidad. En caso de que se produzcan actividades nefastas, como transacciones revertidas u otros eventos maliciosos, el motor de ejecución está diseñado para penalizar a los solucionadores responsables mediante la barra diagonal u otros medios. Esto no solo salvaguarda la integridad de las transacciones, sino que también disuade posibles comportamientos maliciosos por parte de los solucionadores.
Solver DAO Network es una capa de aplicación única construida sobre Intents-Infra. Aperture Intents-Infra permite a las DAO de Solver centrarse en habilitar y resolver casos de uso únicos basados en intenciones sin tener que preocuparse por las necesidades de ejecución subyacentes.
Las DAO de Solver obtienen acceso a las intenciones de usuario que se encuentran dentro de la cámara de compensación de Aperture apostando una cantidad necesaria de $APTR y $ETH. Una DAO de Solver puede correlacionarse con un gran solucionador profesional con una solución patentada o una red de Solvers más pequeños.
Las soluciones de New Intent pueden provenir de Aperture o de una DAO de Solver de terceros. Las DAO de Solver agregan valor al habilitar el nuevo caso de uso de intención. Esto requeriría presentar la lógica de negocio necesaria para encajar en el diseño modular de Aperture. Una vez que esto se ha construido, el caso de uso ahora es "declarable" desde la interfaz de intenciones de apertura o una interfaz de terceros creada por Solver DAO.
La DAO de Aperture proporcionará asistencia $APTR a las DAO de Solver que buscan habilitar nuevos casos de uso de Intención.
En el competitivo ecosistema de Aperture Intents, los Solvers se diferencian por los métodos que emplean para publicar soluciones. Aunque no son obligatorios, los contratos inteligentes son los preferidos por su escalabilidad y velocidad. Sin embargo, los scripts fuera de la cadena son igualmente hábiles para publicar soluciones rápidamente, ofreciendo una ruta alternativa. Ciertas intenciones declaradas pueden incluso tener características que permitirían a los solucionadores enviar soluciones manualmente (por ejemplo, un vendedor que busca organizar una gran transacción OTC con una ventana de oferta de 3 días).
En el caso de los solucionadores con verdaderos métodos de generación de soluciones "alfa" o patentados, pueden evitar la utilización de un contrato inteligente para generar sus soluciones y, en su lugar, pueden confiar en el proceso de verificación ZK de Aperture para generar confianza en torno a su solución habilitada para scripts fuera de la cadena. Esto reforzará el efecto de volante de inercia para los solucionadores de incorporación (soluciones empresariales sostenibles, atrae más ingresos, atrae a más solucionadores).
Aunque no se requiere explícitamente, un Solver en un ecosistema determinado también podría optar por financiar colectivamente su requisito de participación a través de un mecanismo de bóveda a cambio de una participación en las ganancias de su Solver. Cada DAO de Solver puede abrir el código de un contrato de bóveda de rev-share para que sus solucionadores lo implementen (en caso de que deseen financiación de arranque).
Para hacer las cosas más digeribles, tomemos el ejemplo de la "intención de reclamo de airdrop" propuesta en nuestra primera publicación de blog. ¿Cómo declararía un usuario una intención de reclamación? ¿Cómo podría una DAO de Solver especializada en reclamar aprovechar el mercado de DAO de Solver de Aperture?
El usuario comenzaría declarando en lenguaje natural:
"Reclamar todos los lanzamientos aéreos elegibles en mi nombre, incluido el costo de gas asociado con la reclamación, a cambio de una tarifa de búsqueda del 1% o menos".
El chatbot puede hacer preguntas aclaratorias para desentrañar aún más la declaración del usuario.
Una vez realizada esta aclaración, la intención se traduciría del lenguaje natural al DSL de intenciones codificado y se enviaría de vuelta al usuario en un formato legible para que lo verifique. A partir de aquí, la expresión de intención se publicará en el Centro de compensación de intenciones, donde cualquier solucionador elegible podrá ver la declaración del usuario.
Cualquier solucionador ahora puede ver la dirección del usuario y hacer una referencia cruzada con cualquier airdrop o recompensa reclamable que sea elegible para dicha dirección. Una función de permiso impulsada por una billetera de abstracción de cuentas permitiría a los Solvers reclamar cualquier airdrop en nombre del usuario. Los solucionadores competirían entre ellos por la "tarifa de los buscadores" y su conocimiento general de los lanzamientos aéreos. Ahora, la belleza de las intenciones, podría haber múltiples soluciones que ganen y se ejecuten, si el solucionador A cubre un airdrop de Dymension y el solucionador B cubre un airdrop de Celestia, entonces ambos solucionadores podrían ganar una tarifa de búsqueda de nuestro usuario.
Todas las soluciones propuestas serán simuladas por los contratos inteligentes de Aperture para verificar los resultados propuestos y, posteriormente, se clasificarán todas las soluciones verificadas. Aperture se ejecutará en nombre del usuario, devolviendo todos los airdrops.
Compartir
Contenu
Aperture está construyendo una novedosa experiencia de usuario de chatbot impulsada por una infraestructura subyacente de Intents que permitirá a los usuarios "declarar sus objetivos" en lenguaje natural y aprovechar una red de solucionadores para recibir una mejor ejecución y mejores precios de lo que es posible bajo el paradigma transaccional actual.
Para empezar, empezaremos por la piedra angular de cualquier movimiento de adopción masiva: la experiencia de usuario (UX).
La experiencia de usuario actual de DeFi se centra en un enfoque transaccional que requiere que los usuarios de diversa perspicacia técnica firmen un cambio delta o de estado con la esperanza de que el cambio produzca el "estado final" que tenían en mente. Con Intents, ponemos ese "estado final" al frente y al centro como el punto focal de la experiencia del usuario.
Mediante el uso del poder de los LLM modernos y un lenguaje de programación patentado orientado a las intenciones, buscamos mejorar la expresabilidad de las intenciones del usuario. Esto permitirá a los usuarios articular sus objetivos y preferencias transaccionales de manera más intuitiva y eficiente, aprovechando así el potencial de blockchain con mayor facilidad y precisión.
Imagínese a un usuario que no entiende los principios de la tecnología blockchain, enfrentándose a una gran cantidad de "perillas y botones" en la interfaz tradicional de DeFi. El enfoque de apertura de "permitir que el usuario exprese en lenguaje natural lo que quiere" es más simple. Detrás de esto está la necesidad de convertir el lenguaje natural en código blockchain: aquí es donde entran en juego los lenguajes específicos de dominio (DSL).
Un lenguaje específico de dominio (DSL) es un lenguaje informático especializado adaptado a un dominio de aplicación en particular, que lo distingue de los lenguajes de propósito general (GPL) que son aplicables en un amplio espectro de dominios. El diseño y la utilización de DSL son parte integral de la ingeniería de dominio, y a menudo implican la creación de nuevos DSL o la adaptación de los existentes para expresar problemas y soluciones de manera más efectiva dentro de un dominio específico.
En Aperture, el DSL está diseñado con un enfoque en la legibilidad humana, crucial para respaldar una expresión de intención clara e intuitiva. Este enfoque difiere de otros DSL que pueden priorizar aspectos como la eficiencia programática o la optimización a nivel de máquina.
En Aperture, el LLM cierra la brecha entre la funcionalidad técnica y las interfaces fáciles de usar al permitir que el usuario exprese en lenguaje natural su intención y que esa misma intención se refleje en un DSL altamente legible que luego se puede servir a los solucionadores como la "declaración de la verdad" de este usuario.
Usemos una analogía del mundo real: la experiencia de usuario de traducción de LLM a DSL es similar a la de un cliente que hace un pedido en una pizzería por teléfono. El cliente puede pedir en un lenguaje muy coloquial: "Dame tu pizza con todas las carnes en el tamaño más grande". El operador del otro lado podría replicarles: "¿Quieres nuestra pizza Meat Lover's en una Extra Grande?". El usuario entiende fácilmente esta conversión y acepta: "Sí, no sabía el nombre, pero ese es el que quiero".
En la cadena, esta interacción se desarrollaría de manera similar. El usuario puede comenzar declarando su objetivo final:
"¿Pueden reequilibrar mis LP ETH-GMX en todas mis cadenas EVM para que se concentren en un 80% en la configuración de mayor rendimiento y el 20% restante de mi capital LP se divida uniformemente entre los grupos restantes?"
La traducción DSL puede reflejarse en el usuario:
● Activos elegibles: pares ETH-GMX en Mainnet, Arbitrum y Avalanche;
● Acciones permitidas: Puente, Eliminar liquidez, Intercambiar ETH o GMX, Agregar liquidez;
● Objetivo final 1: Reequilibrar las posiciones de liquidez para concentrar el 80% del capital de activos elegibles en la posición con la APR al contado más alta según los datos de APY Vision;
● Objetivo final 2: Reequilibrar las posiciones de liquidez para concentrar el 20% del capital de activos admisibles en los fondos existentes no utilizados en el objetivo final 1;
● Firmar la declaración de intención si es correcta
La conversión de LLM codificará el lenguaje coloquial en la terminología estandarizada del DSL, que puede ser aprovechada por los solucionadores de una manera predecible y replicable.
La infraestructura de intención se puede dividir en varios componentes:
● Cámara de compensación de intenciones (Mempool): sirve como área de preparación preliminar para las intenciones de los usuarios. Está diseñado para organizar y poner en cola de manera eficiente estas intenciones para su procesamiento, mediante algoritmos que priorizan en función de varios criterios, como la urgencia y los requisitos de recursos. La Cámara de Compensación garantiza la gestión segura y ordenada de las intenciones antes de que se comprometan con la cadena de bloques.
● ZK-Simulate for Data Validity: este es un recurso necesario para validar ciertas intenciones y las soluciones correspondientes que se basarán en datos fuera de la cadena. Se puede utilizar una prueba de conocimiento cero para verificar la validez de estos datos. Utilizando herramientas criptográficas avanzadas como Brevis o Axiom, Aperture puede generar ZKP para datos históricos en cadena que forman parte de la solución propuesta por el solucionador. Este método permite la verificación rigurosa de los resultados del solucionador, lo que garantiza que sean precisos, completos y cumplan con las restricciones e intenciones especificadas, sin comprometer la confidencialidad de los datos de la transacción.
● Contratos inteligentes de verificación: cada tipo de caso de uso de intención requerirá un contrato inteligente para simular, verificar y vigilar la solución propuesta.
● Motor de clasificación y ejecución: cada grupo de intenciones verificadas deberá clasificarse en función de los resultados y la puntuación del solucionador y, posteriormente, ejecutarse. Un aspecto crucial de este motor de ejecución es su capacidad para hacer cumplir la responsabilidad. En caso de que se produzcan actividades nefastas, como transacciones revertidas u otros eventos maliciosos, el motor de ejecución está diseñado para penalizar a los solucionadores responsables mediante la barra diagonal u otros medios. Esto no solo salvaguarda la integridad de las transacciones, sino que también disuade posibles comportamientos maliciosos por parte de los solucionadores.
Solver DAO Network es una capa de aplicación única construida sobre Intents-Infra. Aperture Intents-Infra permite a las DAO de Solver centrarse en habilitar y resolver casos de uso únicos basados en intenciones sin tener que preocuparse por las necesidades de ejecución subyacentes.
Las DAO de Solver obtienen acceso a las intenciones de usuario que se encuentran dentro de la cámara de compensación de Aperture apostando una cantidad necesaria de $APTR y $ETH. Una DAO de Solver puede correlacionarse con un gran solucionador profesional con una solución patentada o una red de Solvers más pequeños.
Las soluciones de New Intent pueden provenir de Aperture o de una DAO de Solver de terceros. Las DAO de Solver agregan valor al habilitar el nuevo caso de uso de intención. Esto requeriría presentar la lógica de negocio necesaria para encajar en el diseño modular de Aperture. Una vez que esto se ha construido, el caso de uso ahora es "declarable" desde la interfaz de intenciones de apertura o una interfaz de terceros creada por Solver DAO.
La DAO de Aperture proporcionará asistencia $APTR a las DAO de Solver que buscan habilitar nuevos casos de uso de Intención.
En el competitivo ecosistema de Aperture Intents, los Solvers se diferencian por los métodos que emplean para publicar soluciones. Aunque no son obligatorios, los contratos inteligentes son los preferidos por su escalabilidad y velocidad. Sin embargo, los scripts fuera de la cadena son igualmente hábiles para publicar soluciones rápidamente, ofreciendo una ruta alternativa. Ciertas intenciones declaradas pueden incluso tener características que permitirían a los solucionadores enviar soluciones manualmente (por ejemplo, un vendedor que busca organizar una gran transacción OTC con una ventana de oferta de 3 días).
En el caso de los solucionadores con verdaderos métodos de generación de soluciones "alfa" o patentados, pueden evitar la utilización de un contrato inteligente para generar sus soluciones y, en su lugar, pueden confiar en el proceso de verificación ZK de Aperture para generar confianza en torno a su solución habilitada para scripts fuera de la cadena. Esto reforzará el efecto de volante de inercia para los solucionadores de incorporación (soluciones empresariales sostenibles, atrae más ingresos, atrae a más solucionadores).
Aunque no se requiere explícitamente, un Solver en un ecosistema determinado también podría optar por financiar colectivamente su requisito de participación a través de un mecanismo de bóveda a cambio de una participación en las ganancias de su Solver. Cada DAO de Solver puede abrir el código de un contrato de bóveda de rev-share para que sus solucionadores lo implementen (en caso de que deseen financiación de arranque).
Para hacer las cosas más digeribles, tomemos el ejemplo de la "intención de reclamo de airdrop" propuesta en nuestra primera publicación de blog. ¿Cómo declararía un usuario una intención de reclamación? ¿Cómo podría una DAO de Solver especializada en reclamar aprovechar el mercado de DAO de Solver de Aperture?
El usuario comenzaría declarando en lenguaje natural:
"Reclamar todos los lanzamientos aéreos elegibles en mi nombre, incluido el costo de gas asociado con la reclamación, a cambio de una tarifa de búsqueda del 1% o menos".
El chatbot puede hacer preguntas aclaratorias para desentrañar aún más la declaración del usuario.
Una vez realizada esta aclaración, la intención se traduciría del lenguaje natural al DSL de intenciones codificado y se enviaría de vuelta al usuario en un formato legible para que lo verifique. A partir de aquí, la expresión de intención se publicará en el Centro de compensación de intenciones, donde cualquier solucionador elegible podrá ver la declaración del usuario.
Cualquier solucionador ahora puede ver la dirección del usuario y hacer una referencia cruzada con cualquier airdrop o recompensa reclamable que sea elegible para dicha dirección. Una función de permiso impulsada por una billetera de abstracción de cuentas permitiría a los Solvers reclamar cualquier airdrop en nombre del usuario. Los solucionadores competirían entre ellos por la "tarifa de los buscadores" y su conocimiento general de los lanzamientos aéreos. Ahora, la belleza de las intenciones, podría haber múltiples soluciones que ganen y se ejecuten, si el solucionador A cubre un airdrop de Dymension y el solucionador B cubre un airdrop de Celestia, entonces ambos solucionadores podrían ganar una tarifa de búsqueda de nuestro usuario.
Todas las soluciones propuestas serán simuladas por los contratos inteligentes de Aperture para verificar los resultados propuestos y, posteriormente, se clasificarán todas las soluciones verificadas. Aperture se ejecutará en nombre del usuario, devolviendo todos los airdrops.