Contratos inteligentes de contenedor en Internet La computadora tiene la capacidad de realizar llamadas directas a cualquier fuente de datos Web 2.0 a través de llamadas salientes HTTPS sin introducir suposiciones de confianza adicionales. Un caso de uso de DeFi totalmente en cadena es el nuevo Exchange Rate Canister.
Escrito por Thomas Locher
El crecimiento explosivo en el espacio Web 3.0 en los últimos años es testimonio del poder de los contratos inteligentes. Los contratos inteligentes que se ejecutan en una cadena de bloques brindan un mecanismo confiable para realizar transacciones complejas de manera descentralizada. Su poder radica en el hecho de que tanto el código del programa como los datos con los que operan residen en la cadena. Esto implica que los usuarios pueden confiar en que las transacciones se ejecutan según lo previsto, siempre que se confíe en la propia cadena de bloques. Por ejemplo, si un usuario desea intercambiar un token por otro en un intercambio descentralizado (DEX), un contrato inteligente que implementa la funcionalidad de un intercambio, este usuario puede estar seguro de que obtendrá el otro token en un momento apropiado. tipo de cambio, y no perder el token transferido debido a un error humano o comportamiento malicioso.
Si bien existen claros beneficios de que todas las decisiones en un contrato inteligente se basen en información en la cadena, también es un factor limitante. Los contratos inteligentes por sí solos no pueden usar fácilmente la abundancia de datos disponibles en el mundo “tradicional” de la Web 2.0. ¡Piense en todas las poderosas aplicaciones descentralizadas que podrían construirse si los datos externos, como pronósticos del tiempo, datos del mercado de valores en tiempo real, puntajes en vivo de eventos deportivos, etc., pudieran usarse dentro de contratos inteligentes!
Datos confiables
De hecho, es posible en la mayoría de las cadenas de bloques inyectar dichos datos en contratos inteligentes. Sin embargo, la pregunta es si el proveedor de datos es confiable. En una plataforma verdaderamente descentralizada, no es posible limitar o determinar quién proporciona datos al sistema. Por otro lado, el uso de una parte confiable conocida para proporcionar datos externos disminuye severamente la naturaleza descentralizada del contrato inteligente. Además, mientras que las aplicaciones descentralizadas suelen ser tolerantes a fallas, la dependencia de un proveedor de datos centralizado introduce aún más un punto único de falla indeseable.
Lo que necesitamos para resolver este enigma es un oráculo de datos, un mecanismo tolerante a fallas e incorruptible que garantice la veracidad de todos los datos que proporciona.
El problema del oráculo
¿Cómo se puede construir tal oráculo? Como se mencionó, tener una sola parte que proporcione datos destruye la naturaleza descentralizada de un contrato inteligente, ya que la parte única se convierte no solo en la única fuente de verdad, sino también en un único punto de falla. De esta observación, concluimos que un oráculo debe consistir de alguna manera en múltiples proveedores de datos. De hecho, las plataformas Oracle de última generación se construyen en torno a esta observación: una plataforma Oracle es en sí misma un sistema distribuido y descentralizado con numerosos nodos individuales que recopilan información de múltiples fuentes Web 2.0. La plataforma Oracle limpia y cura la información recopilada para obtener datos lo más completos y precisos posible. Las cadenas de bloques se integran con las plataformas de Oracle para que sus datos estén disponibles para los contratos inteligentes.
El enfoque de tener plataformas Oracle dedicadas es claramente superior a depender de entidades centralizadas, pero tiene varias fallas. En primer lugar, la recopilación y conservación de datos en un sistema descentralizado es en sí mismo un problema difícil. A menudo es engorroso agregar otros tipos de datos o fuentes, y puede llevar mucho tiempo y ser costoso. Aparte de estos desafíos operativos, también existe una deficiencia fundamental que no se puede superar fácilmente, que es la dependencia inherente de la plataforma de Oracle. Por diseño, un usuario debe confiar no solo en la cadena de bloques en la que se ejecuta el contrato inteligente de interés, sino también en la plataforma Oracle que alimenta los datos necesarios para que el contrato inteligente funcione correctamente. Tener que confiar en entidades adicionales siempre es un problema de seguridad, incluso si estas entidades también están descentralizadas, simplemente porque las diferentes entidades nunca son iguales en términos de seguridad que brindan.
Llamadas salientes HTTPS: un bloque de construcción esencial
La pregunta es si un contrato inteligente puede obtener poder oracular de una manera diferente y más inteligente. Afortunadamente, la respuesta es “sí”, al menos en la computadora de Internet. La computadora de Internet tiene un “superpoder” único denominado llamadas salientes HTTPS. Esta función permite que los contratos inteligentes obtengan datos de servidores web regulares (Web 2.0) de manera determinista y, sin embargo, descentralizada. Se recomienda encarecidamente al lector que lea sobre esta característica innovadora, por ejemplo, en este artículo.
Es importante comprender que las llamadas externas HTTPS brindan acceso a los recursos de la Web 2.0, pero nada más. Si un contrato inteligente de recipiente consulta datos de un punto final en particular, es posible que el contrato inteligente no pueda proporcionar su servicio si este punto final no está disponible. El contrato inteligente también confía en el punto final para proporcionar información precisa. En otras palabras, las llamadas externas de HTTPS no brindan la funcionalidad de Oracle, pero son un componente esencial para desarrollar Oracles que se ejecutan completamente en la cadena.
Presentamos un oráculo en cadena
Poniendo la teoría en práctica, en DFINITY hemos creado y lanzado Exchange Rate Canister, un oráculo de precios en cadena. Este contrato inteligente de recipiente proporciona una funcionalidad crucial para varios tipos de aplicaciones. Esencialmente, para cualquier par de un activo base y un activo cotizado, donde cualquiera de los activos puede ser una criptomoneda o una moneda fiduciaria, devuelve el tipo de cambio. Exchange Rate Canister puede devolver tanto la tasa actual como las tasas del pasado (sujeto a la restricción de que las fuentes de datos proporcionen las tasas históricas necesarias para atender la solicitud). Interactúa con los principales intercambios de criptomonedas a través de API públicas para obtener información de precios actual o histórica. Además, consulta periódicamente las API públicas de los proveedores de datos de divisas de todo el mundo para obtener las tasas de cambio.
Detalles técnicos
Profundizando un poco más en los detalles técnicos, cada vez que Exchange Rate Canister recibe una solicitud utilizando el punto final get_exchange_rate (el archivo Candid del contenedor de tipo de cambio está disponible aquí), realiza las llamadas externas HTTPS necesarias para recopilar tasas. Posteriormente, las tarifas se limpian eliminando los valores atípicos y la mediana de las tarifas restantes se devuelve a la persona que llama, junto con los metadatos sobre la solicitud, como la cantidad de fuentes que se consultaron, cuántas tarifas se recibieron, etc.
Vale la pena señalar que implementar un oráculo de este tipo no es una tarea trivial. Se necesita una gran cantidad de optimizaciones y mejoras para lograr el nivel deseado de rendimiento y seguridad. Por ejemplo, los resultados de consultas recientes se colocan en una caché de uso menos reciente para que las tarifas se puedan devolver rápidamente sin repetir las mismas llamadas salientes HTTPS para pares de activos que se solicitan con frecuencia. Dado que la cantidad de llamadas salientes HTTPS que una subred puede manejar a la vez está limitada, también existe una limitación de velocidad para proteger la subred contra una avalancha de solicitudes. Como una llamada externa HTTPS es una operación costosa en términos de la cantidad de ciclos consumidos, Exchange Rate Canister cobra un precio justo por su servicio en el sentido de que la cantidad de ciclos que cobra depende de la cantidad real de llamadas externas HTTPS que realiza para atender una pedido. Si la respuesta se puede servir desde el caché, el costo es bajo, 200 millones de ciclos (¡lo que corresponde aproximadamente a 0,03 centavos de dólar estadounidense!), pero puede costar hasta 5 mil millones de ciclos (aproximadamente 0,7 centavos de dólar estadounidense) para un par criptomoneda-criptomoneda. que no está en caché.
El hecho de que las solicitudes no sean gratuitas también proporciona un cierto nivel de protección contra los ataques de denegación de servicio. Para aquellos que deseen profundizar un poco más, el código fuente de Exchange Rate Ranister está disponible públicamente.
Capacidades de Oracle en la práctica
Como se mencionó anteriormente, hay muchos casos de uso para los oráculos de fijación de precios, como Exchange Rate Canister. Es una función deseable, si no obligatoria, para los DEX a fin de comparar los tipos de cambio dentro de los DEX con el tipo de cambio del mercado. También es útil para recipientes que contienen ciertos fondos, ya que el recipiente de tipo de cambio proporciona una forma sencilla de determinar el valor de los activos bajo administración, por ejemplo, con respecto a una moneda fiduciaria.
Por último, Exchange Rate Canister juega un papel importante para el sistema nervioso de red (NNS) de Internet Computer. Dado que el precio de los ciclos está vinculado a la canasta de monedas SDR del FMI (símbolo de moneda: XDR) a 1 XDR por 1 billón de ciclos y el recipiente de acuñación de ciclos (CMC) quema ICP para generar ciclos, el recipiente de acuñación de ciclos debe tener acceso a una tasa de conversión ICP/XDR precisa. Esta tasa de conversión se actualizó previamente a través de propuestas NNS, lo que requiere 144 propuestas por día en una propuesta cada 10 minutos. Desde el 8 de mayo de 2023, la CMC obtiene el tipo de cambio ICP/XDR del contenedor de tipo de cambio, lo que hace que las propuestas de tipo de cambio queden obsoletas.
El contenedor de tipo de cambio es un gran ejemplo de un contrato inteligente que libera el poder de las llamadas externas HTTPS al ofrecer un servicio de Oracle que se ejecuta completamente en cadena. Por supuesto, hay mucho espacio para muchos otros casos de uso de oráculos en cadena que corresponden a los diversos tipos de datos de la Web 2.0. Por ejemplo, el ecosistema de Internet Computer también podría beneficiarse de más oráculos de precios en cadena similares al Exchange Rate Canister pero aprovechando diferentes fuentes de datos o proporcionando tasas para diferentes clases de activos, como acciones o ETF.
Exchange Rate Canister es solo el punto de partida para la próxima generación de contratos inteligentes de contenedores con capacidades de Oracle para alcanzar un nuevo nivel de confiabilidad, precisión y confiabilidad. ¡Ciertamente es emocionante pensar en muchos más que aparecerán en el futuro!