Si bien hay mucho optimismo en Web3 sobre un futuro en el que todo sucede en una cadena de bloques, estamos muy lejos de que eso se convierta en realidad. La gran mayoría de los datos útiles se generan en centros de datos tradicionales o infraestructuras de computación en la nube y se conectan con herramientas familiares que hacen un uso extensivo de HTTP o HTTPS.
Las aplicaciones descentralizadas que se ejecutan en una de las cadenas de bloques de capa 1, como Ethereum o Solana, interactúan con los servicios basados en HTTP a través del llamado oráculo. Estos oráculos actúan como middleware confiable para permitir la creación de un contacto inteligente híbrido, donde el código en la cadena puede interactuar con la infraestructura y los datos fuera de la cadena. Chainlink Network, una popular red Oracle descentralizada, ofrece un breve video que explica cómo se ve.
El problema de los oráculos
Si bien los oráculos son el medio principal para conectar dApps (aplicaciones descentralizadas) a datos e infraestructura fuera de la cadena, existen algunas desventajas. Las solicitudes son indirectas, lo que significa que no realiza una llamada API directamente a la fuente de los datos que desea consultar: el oráculo lo hace por usted y luego su dApp tiene que confiar en la respuesta que devuelve el oráculo. Este enfoque también conlleva tarifas asociadas con el uso de Oracle como intermediario de terceros.
La Fundación DFINITY, uno de los mayores contribuyentes a Internet Computer, una cadena de bloques de Capa 1, propone un enfoque alternativo en el que las dApps pueden realizar solicitudes HTTP directamente a través de una API integrada en la cadena de bloques.
En una entrevista con The New Stack, Dieter Sommer, Gerente de Programas Técnicos de la Fundación DFINITY, explica el desafío de confiar en los oráculos de esta manera. «Cualquiera que quiera hacer algo sensato necesita alguna forma de integración con la Web 2, y todas las demás cadenas de bloques usan oráculos para eso», dijo. “Los oráculos son servicios externos. Entonces, si confía en un oráculo para conectarse a la web 2, el oráculo hará todo el trabajo de HTTP. También significa que introduce muchos nuevos supuestos de confianza; Por ejemplo, en el modelo estándar de uso del oráculo de Chainlink, llamas a un proveedor de oráculo y tienes que confiar en ese proveedor, que es un modelo muy débil».
Una API para hacer llamadas HTTP directamente
La Fundación DFINITY utiliza una terminología ligeramente diferente para explicar cómo funciona la infraestructura de cadena de bloques de la computadora de Internet. Basado en el Protocolo de computadora de Internet, la computadora de Internet aloja contratos inteligentes llamados recipientes, que son una combinación de código de bytes de WebAssembly y páginas de memoria que ejecutan ese código. La implementación de un recipiente significa que el código y el estado correspondientes se replican en todos los nodos de la subred donde se implementa.
Este concepto de replicación es una de las razones por las que la mayoría de las cadenas de bloques hoy en día usan oráculos para realizar solicitudes HTTP. En el diseño actual de la computadora de Internet, cada copia haría la misma llamada HTTP a un servicio externo. Sin embargo, la respuesta HTTP devuelta a cada réplica puede ser diferente, ya que las marcas de tiempo o los ID pueden variar. Si todas las réplicas obtienen una respuesta ligeramente diferente, es imposible llegar a un consenso, lo que interrumpe efectivamente la subred.
En la próxima versión de Chromium de Internet Computer, hay un nuevo enfoque para resolver este problema y proporcionar a la cadena de bloques una integración directa a través de una API para llamadas HTTP. Esto elimina los supuestos de confianza necesarios para usar un oráculo y, en teoría, simplifica el proceso de acceso a datos fuera de la cadena.
Con una API asíncrona expuesta a través del contenedor de administración, cada nodo realiza la misma solicitud HTTP. Cuando cada nodo recibe una respuesta, firma la respuesta y la reenvía a los otros nodos. Una vez que la capa de consenso haya agregado suficientes firmas, agregará la respuesta a la cadena de bloques. Cuando se completa el bloque, la respuesta se devuelve a la capa de ejecución, que a su vez reanuda el cálculo que activó la solicitud HTTP.
Navegando a través de respuestas inconsistentes
Si todos los nodos obtienen la misma respuesta aproximadamente al mismo tiempo, este enfoque funciona bien. Esto también debería funcionar en escenarios en los que un nodo malicioso informa información incorrecta, siempre que suficientes nodos devuelvan la misma respuesta.
Como dice Sommer, “Todos los nodos en una subred hacen la solicitud, y solo si el consenso es exitoso, lo que significa que al menos dos tercios de las réplicas están de acuerdo con el resultado, se envía de vuelta al recipiente como resultado. Esto permite llamadas externas seguras sin tener que depender de terceros externos. Nuestro protocolo de consenso es lo suficientemente flexible como para permitir tal extensión”.
Un escenario más complicado es cuando los requisitos son semánticamente iguales pero pueden tener diferencias menores que no importan para el resultado del cálculo. En lugar de no llegar a un consenso, puede solucionar estas inconsistencias con una función que transforma la respuesta al mostrar solo la parte de la respuesta que se requiere para el cálculo. Tome un ejemplo como la necesidad de devolver una cadena de texto, con el texto envuelto en una respuesta con una marca de tiempo. Si la cadena de texto es la misma en todos los casos, no importa que las marcas de tiempo varíen y puedes usar la función para descartarlas.
Para la primera versión, solo se admiten solicitudes GET. El plan a más largo plazo también incluye soporte para solicitudes POST. Al ver el video de DFINITY Foundation que cubre esta nueva función con más detalle, Ivan Malison, ingeniero de software de DFINITY, explica que las solicitudes POST son más complicadas. Mostró un ejemplo de un pago con tarjeta de crédito. No desea intentar cargar la misma tarjeta varias veces u obtener una respuesta diferente a su solicitud POST, como: B. una vez un mensaje de éxito y la próxima vez un rechazo. El video proporcionó la idempotencia de Stripe para reintentos de API seguros como un ejemplo de cómo implementar esto correctamente en el futuro.
Declaración de la misión de Pexels.
