Entrega de Datos Basada en Intenciones: Por Qué Es Importante y Cómo Funciona

Los oráculos en el contexto de las cadenas de bloques deben traer datos del exterior hacia el mundo de la cadena de bloques. En nuestro [artículo anterior] discutimos los tres tipos diferentes de oráculos: el oráculo de extracción, el oráculo de envío y nuestro nuevo oráculo basado en la intención.

Resumamos rápidamente cómo funcionan, para que quede claro por qué necesitamos un nuevo tipo de oráculo, el basado en la intención.

Oráculos de Empuje

El "oráculo de empuje" es probablemente la idea más antigua. Con un oráculo de empuje, los datos están disponibles en la cadena y se actualizan después de un tiempo o cuando se alcanza un umbral. Por ejemplo, un componente fuera de la cadena observa la temperatura promedio en París. Al inicio, es de 25°C y escribe este punto de datos en la cadena. Ahora, todos en la cadena pueden acceder a estos datos. Puede establecerse como regla que los datos se actualicen en la cadena cuando la temperatura cambie 1°C o después de 60 minutos, lo que se llama un latido, para saber que el oráculo está funcionando en general. Supongamos que la temperatura cambia a 25.6, 25.7, 25.8°C, pero no hay cambios en la cadena. Fuera de la cadena, la tendencia se vuelve muy obvia. Finalmente, alcanza los 26°C y se envía una transacción a la blockchain para actualizar la temperatura en el llamado contrato de oráculo. 

La parte importante es entender lo que sucede allí: Se envía la transacción, pero no es inmediatamente visible en la cadena. Primero debe ser minada o confirmada. De hecho, dado que toda la información es pública, se sabe cuál será el nuevo punto de datos antes de que la transacción sea confirmada.

Supongamos que hay un gran mercado de derivados en la cadena que utiliza estos datos donde puedes apostar sobre la temperatura. Puede ser tan simple como: Apuestas que la temperatura subirá, pero siempre puedes salir de tu posición. Si alguna vez has negociado opciones, esto puede sonar muy familiar. Imagina que apuestas a que las temperaturas caerán y ves que hay una nueva transacción que llega con temperaturas más altas que podrían invalidar tu posición. Simplemente puedes enviar una transacción con un gas más alto para adelantarte a la actualización del oráculo, conseguir que se confirme con los antiguos 25°C justo antes de que el oráculo actualice a 26°C. 

Por lo tanto, los datos no son en tiempo real, según cualquier métrica común que definamos como "tiempo real". Los datos son en su mayoría obsoletos y son públicos y visibles antes de ser confirmados. 

Aun con umbrales cada vez más pequeños y/o latidos cada vez más rápidos, esta arquitectura no escala bien. Vamos al extremo y digamos que queremos llevar los datos tradicionales de acciones de EE. UU. a la cadena. No es raro que una acción se negocie varias miles o decenas de miles de veces por segundo, cambiando el precio muy ligeramente en centavos hacia arriba y hacia abajo. En Ethereum, una transacción (actualmente) se confirma cada ~14 segundos. En Polygon es mucho más rápido. No es solo el rendimiento de transacciones, también importa el tiempo de confirmación. Decenas de miles de actualizaciones por segundo - y por mercado - son inviables con esta arquitectura. Actualizar la información en la cadena basada en empuje simplemente no funciona si los datos necesitan estar en la cadena en tiempo real. Además de la congestión de la red, simplemente haciendo un cálculo aproximado sobre el costo de todas las transacciones, incluso si están en 0.001 centavos por transacción, no podrá manejar todas las actualizaciones de precios con una tasa de muestreo lo suficientemente alta para satisfacer a las empresas que dependen de datos en tiempo real.

Oráculos de extracción

Aquí es donde entran los oráculos de extracción. Un oráculo de extracción invierte el problema de la dependencia de datos. En lugar de hacer que los datos estén fácilmente disponibles en la cadena, un oráculo de extracción los pone a disposición fácilmente fuera de la cadena con mecanismos de firma para poder verificar que los datos son válidos.

Te suscribes a un flujo de datos regular http/websocket. Recibes actualizaciones en tiempo real. Y cuando necesitas un precio, utilizas los datos en tu propia transacción. Los datos te son proporcionados de manera que no puedes manipularlos.

Volvamos al ejemplo con la temperatura y la apuesta sobre la temperatura. Está el Oráculo (O), el Participante o Usuario (U) y el Mercado (M).

O tiene los datos. U quiere operar en M. En lugar de consultar los datos en la cadena, el Usuario U obtiene la temperatura de O fuera de la cadena. Pero O no simplemente envía la temperatura actual, sino que la envía con una firma criptográfica para que M (o cualquier otra persona) pueda verificar que no ha sido manipulada. Ahora el Usuario envía la transacción en la cadena, conteniendo los Datos del Oráculo al Mercado, que luego puede confirmar que el punto de datos realmente proviene del oráculo fuera de la cadena y te permite operar con lo que desees.

Esto escala bien, pero introduce otros dos problemas muy grandes:

1. Del lado del Usuario/Mercado, el Usuario puede ver los datos antes de que sean enviados. El usuario consulta los datos y, aunque no puede manipular (modificar) los datos, puede decidir enviar la transacción o no.
2. Los datos están disponibles públicamente, lo que es un problema para la concesión de licencias de datos y los derechos sobre los datos. Muchos datos, especialmente los datos financieros, tienen licencias restringidas para distribución, exhibición y otros derechos. Si el oráculo mismo necesita que los datos sean visibles y los distribuye a través de un socket, generalmente significa que los proveedores de datos tradicionales no pueden (y no querrán) proporcionar datos a través de ese oráculo.

El Oráculo Morpher es diferente de ambos enfoques.

El sistema basado en intenciones se basa en la abstracción de cuentas, también conocida como ERC4337. El ERC4337 en sí no tiene nada que ver con oráculos, pero es la tecnología que Morpher utiliza para construir su tecnología de oráculo sobre ella con el fin de resolver los dos problemas restantes de los oráculos de extracción.

Abstracción de Cuentas: un breve análisis profundo

La Abstracción de Cuentas resuelve un problema no relacionado con los oráculos, pero un problema de larga data para los sistemas basados en EVM (Máquina Virtual de Ethereum).

Con los sistemas basados en EVM, una transacción que se envía necesita "gas" - alguien que pague por la transacción. Las transacciones no son gratuitas y son una parte económica crucial de cómo opera la blockchain y paga a sus validadores o mineros.

En los sistemas actuales basados en EVM, hay dos tipos de cuentas: EOA (cuentas de propiedad externa) y cuentas de contrato. Las EOA son las que usualmente se ven en su billetera, que son controladas por una clave privada. Las cuentas de contrato son contratos inteligentes.

En Ethereum, únicamente las EOA pueden pagar por las transacciones. Y esto no puede ser delegado. No puedo decir: "Quiero enviar esta transacción, pero quiero que [otra cuenta] pague por ello". Se ha intentado resolver este problema durante años creando un constructo llamado "abstracción de cuentas". El término generalmente significa que la línea entre las EOA y los contratos se vuelve difusa, donde tal vez los contratos puedan pagar por las transacciones por sí mismos.

En los primeros borradores de la abstracción de cuentas (hubo muchos borradores que nunca llegaron a producción), un contrato podría pagar por las transacciones. Pero resulta que es un problema muy complejo de resolver, con cambios muy profundos en la arquitectura de la blockchain y de los nodos en sí, probablemente necesitando una serie de hard-forks y actualizaciones disruptivas y, en general, el consentimiento de la comunidad.

Entonces llegó otra propuesta - la propuesta número 4337, o ERC4337. Aquí, no fueron necesarios cambios en la blockchain en sí. Era completamente compatible hacia atrás y relativamente fácil de implementar.

La idea era utilizar una serie de diferentes mecanismos de firma y participantes tanto fuera de la cadena como en la cadena para delegar el envío de la transacción.

Cada uno de los participantes tendría una función distinta y o no podría manipular los datos, o, mayormente por teoría de juegos, no querría retener datos.

Hagamos un ejemplo concreto.

En el mundo de ERC4337 hay una serie de participantes.

1. Estás tú, el usuario que quiere enviar una transacción.
2. Hay un agrupador, que es un software que recibe las llamadas de operación del usuario, muy similar a las transacciones regulares, pero aún no pagadas.
3. Hay un pagador, que es alguien que podría pagar por tu transacción. Esta es la parte crucial donde puedes delegar el pago por las transacciones a otra persona. Esta persona puede asegurarse de recibir el pago de ti ya sea fuera de la cadena o directamente y de manera transparente en la cadena.
4. Hay un punto de entrada, que es un contrato inteligente que valida mayormente las firmas y se asegura de que todos sean pagados correctamente.
5. Hay una billetera en la cadena, una llamada cuenta inteligente, que es otro contrato inteligente. Las Cuentas Inteligentes ya existían antes de ERC4337 y se desarrollan en paralelo o de manera independiente a la abstracción de cuentas, simplemente se complementan entre sí. Son contratos inteligentes que se comportan como billeteras regulares, que son controladas simplemente por una cuenta de propiedad externa (una cuenta controlada por una clave privada).
6. Finalmente, está el contrato final con el que deseas interactuar.

La parte crucial de ERC4337 es que no eres tú, con tu cuenta de propiedad externa, quien interactúa con el contrato final, sino que instruyes a tu billetera en la cadena para interactuar con el contrato final con el que deseas interactuar.

En general, la recomendación común es usar billeteras en la cadena sobre las EOA, independientemente de usar o no la abstracción de cuentas. Por ejemplo https://safe.global/: tiene muchos beneficios, como autorización de múltiples firmas, recuperación social y muchos más. Si bien esto está más allá del alcance de este artículo, en general, el movimiento se dirige hacia las billeteras en la cadena.

Para nuestro ejemplo, digamos que deseas enviar 1 ETH desde tu billetera inteligente a otra persona. Pero en lugar de interactuar directamente con tu billetera inteligente, quieres enviarlo de una manera "sin gas". Eso significa que tu EOA podría tener 0 ETH para pagar por la transacción, pero aún así deseas instruir a tu billetera en la cadena de alguna manera para enviar el 1 ETH desde ella misma a otra persona en tu nombre.

Esto se logra creando una UserOperation (userOp). Una userOp se parece mucho a una transacción regular, estructuralmente.

Analicemos esto un poco más para una mejor comprensión:

1. Tiene un remitente, que es tu cuenta inteligente.
2. Tiene un nonce, que es un número que aumenta constantemente. Muy similar a una transacción normal, sin embargo, en lugar de obtener esto de los nodos de la blockchain, lo obtienes del punto de entrada.
3. Tiene un initCode, que crea una cuenta inteligente (billetera en la cadena) si aún no tienes una.
4. Tiene callData, que es similar a la parte de datos en una transacción regular. Esta parte instruye a tu billetera inteligente para hacer algo en tu nombre.
5. Luego tiene una serie de variables de gas para determinar cuánto pagar al agrupador.
6. Luego hay un pagador, que es otro participante que podría pagar por la transacción.
7. La firma es un mecanismo criptográfico para hacer la userOp a prueba de manipulaciones. Es un esquema de firma de mensaje de la cuenta de propiedad externa, donde firma toda la userOp sin enviarla como una transacción.

Luego hemos terminado. Esa se envía al agrupador.

Un agrupador es un software que tiene básicamente un solo propósito: Toma userOps (uno o varios de ellos, ¡eso es importante!), los envuelve en una transacción real por la que paga y los envía al punto de entrada. El agrupador no es una organización benéfica, no envía las userOps sin recibir pago. Aquí es donde entran en juego las variables de gas en la userOp. El punto de entrada utiliza estas variables para determinar cuánto "reembolsar" al agrupador.

Como eso se conoce de antemano, el agrupador también puede verificar antes de enviar la transacción real, que recibe suficiente pago (igual o más de lo que cuesta enviar la transacción real). Ejecutar un agrupador debería ser una operación económicamente viable, después de todo.

Luego, el punto de entrada reenvía la intención del usuario con el callData al remitente (la billetera inteligente del usuario) y la billetera inteligente ejecuta la acción que el usuario quería realizar. Por supuesto, todo está firmado, doblemente firmado y triplemente firmado, de modo que nadie puede manipular los datos. Dado que todos reciben un pequeño pero atractivo beneficio a lo largo del proceso, tampoco hay razón para creer que colaborarían intencionadamente para retener alguna transacción.

Los agrupadores en sí están conectados a través de un pool donde comparten operaciones pendientes de usuario, similar a un pool de transacciones real en Ethereum.

La parte interesante para el oráculo es: Un agrupador puede enviar una o varias userOps en la misma transacción. Así que es una transacción que envuelve varias userOps.

El Oráculo de Morpher

Esto es lo que utiliza el Oráculo de Morpher para inyectar información de precios o un punto de datos en el sistema.

En un esquema de abstracción de cuentas regular, el usuario interactúa con un agrupador enviando una solicitud POST a una cierta URL. El agrupador tomaría ese userOp y lo añadiría a su piscina de transacciones.

En el Oráculo de Morpher, el usuario también interactúa con un agrupador, sin embargo, en lugar de enviar un UserOp, el usuario envía una solicitud ligeramente diferente, que es un DataOp.

El dataOp se parece exactamente al userOp, pero antes de enviar la transacción al punto final tal como está, el agrupador inyectará ese punto de datos como un userOp antes del userOp real del usuario. Esto es determinado por el contrato con el que el usuario interactúa, el cual puede especificar un nuevo requisito para la interacción:

En el lado fuera de la cadena, antes de enviar la transacción, esto se verifica y luego se determina que el contrato necesita datos adicionales y luego se inyecta como un userOp.

Esta es una operación atómica, no hay dos transacciones, sino solo una única transacción enviada al punto de entrada con dos (o más) userOps. El primer userOp está actualizando el oráculo, muy similar a un oráculo de empuje, pero basado en la intención, donde los datos son en efecto en tiempo real desde el punto de vista del usuario. El segundo userOp es el userOp del Usuario que luego interactúa con su billetera inteligente, la cual interactúa con el contrato final, que lee los datos del oráculo del contrato del oráculo.

El oráculo en sí puede asegurarse de que también se le pague a través de un esquema de pago similar, transparente y en cadena, donde la interacción con el oráculo no es gratuita.

Los datos no solo son a prueba de manipulaciones desde el punto de vista del usuario y del contrato final. También es imposible retener datos, porque son privados. Un usuario no puede ver los datos antes de que sean enviados al contrato final en la cadena. Además, la mayoría, si no todos, los problemas de licencias para los proveedores de datos están resueltos, porque los datos permanecen privados. No necesita derechos de exhibición ni derechos de distribución. Los datos permanecen legibles solo para el contrato final receptor que necesita el punto de datos y paga por ello.

¿Tienes curiosidad por ver cómo funcionan los oráculos basados en la intención? Descúbrelo en vivo en el Oráculo de Morpher.

¿Quieres profundizar más en la discusión? Únete a nuestro grupo de Telegram.

Descargo de responsabilidad: Todas las inversiones conllevan riesgos y el rendimiento pasado de un valor, industria, sector, mercado, producto financiero, estrategia de trading o trading individual no garantiza resultados o rendimientos futuros. Los inversores son totalmente responsables de cualquier decisión de inversión que tomen. Tales decisiones deben basarse únicamente en una evaluación de sus circunstancias financieras, objetivos de inversión, tolerancia al riesgo y necesidades de liquidez. Esta publicación no constituye asesoramiento de inversión.