No Blockchain Oracles? Integration of Web3 and Web2 via HTTP

Building out Web3 and using blockchain technology to decentralize control over networks, platforms and data is a powerful idea that can help revive the open internet. But blockchain advocates believe smart contracts won’t eat the world until decentralized applications are able to connect directly to Web2, just as conventional consumer web services do today. Only then will blockchains onboard billions of Web2 users to Web3 services.

Blockchains typically cannot interact directly with systems and data hosted outside of their respective networks. Legacy web technology largely communicates via cloud infrastructure and servers using the standard web protocol HTTP, forcing dapps to rely on external “oracles” to communicate with HTTP-based sources. Oracles basically act as bridges that connect on-chain software with off-chain data and services.

Because blockchains like Ethereum (ETH) and Solana (SOL) cannot provide native oracle solutions, dapp developers deal with the added programming complexity, cost, latency, and security risk by using trusted middleware to query external data. They typically integrate centralized oracles and oracle networks such as Chainlink (LINK) to allow their smart contracts to access off-chain infrastructure, but they must regularly ensure that these oracle services reliably return valid responses that have not been compromised.

Smart contracts take advantage of the ability to ingest off-chain data from the real world. Decentralized exchanges, for example, often source exchange rates from centralized exchanges such as Coinbase. This is why financial smart contracts, automated market makers, and trading platforms generally rely on oracles while navigating associated vulnerabilities and exploits, such as price oracle manipulation. What if there was a direct API for dapps to access external data? What if developers no longer had to incorporate and pay for third-party intermediaries to send requests on-chain and relay responses off-chain?

In a sign of how blockchain technology continues to push forward, the Internet Computer (ICP) recently implemented an API that enables smart contracts and dapps to send HTTP calls directly, including secured HTTPS traffic. “If you develop a container smart contract on the Internet computer blockchain, it will be able to make HTTPS calls directly to Web2 servers and securely receive a direct response,” explains Dieter Sommer, technical program manager at the DFINITY Foundation, which contributes with R&D for the Internet computer. “From the developer perspective, the experience is closer to the familiar Web2 programming paradigm without oracles.”

An HTTP API

The way oracle projects like Chainlink, UMA (UMA) and API3 (API3) typically work involves an off-chain authority reading data from a specific external source and writing it to a unique smart contract to forward that data in response to – chain question. Smart contracts running on a blockchain can then be programmed to use the oracle as a substitute or translator for off-chain data.

The disadvantages include the involvement of an intermediary that aggravates the work of developers and increases the risk of service failure. Third parties may collaborate or conspire to manipulate data, and the oracles may also be hacked or compromised. It can take time to receive and send the data, which hurts the user experience, especially in the case of decentralized oracles that need to gather data from redundant sources and coordinate consensus. Chainlink is particularly dominant in the oracle space, being blockchain agnostic, but using the oracle network is also expensive for developers.

The introduction of a direct HTTP API for smart contracts opens a path for Web3 to seamlessly interoperate with established HTTP-based services and data sources, creating a variety of application possibilities that can efficiently utilize a vast amount of Web2 data. The HTTPS exclamation feature has recently been integrated into the Internet Computer Protocol stack, focusing on the consensus layer. Internet Computer smart contracts are distributed on subnetted blockchains, with each container’s code and state replicated across all of a given subnet’s nodes.

Most blockchains rely on oracles for intermediate HTTP requests because replication and consensus make it impractical to interact directly with HTTP. Replicas would make identical calls to an external service, and potential variations in timestamps or IDs would generate different responses, making it impossible for them to reach agreement.

“The IC protocol stack can be conceptually simply viewed as a communication pipe between the container and the conventional HTTP server that ensures that the HTTP response comes through consensus and that all honest replicas receive the exact same response during execution,” the documentation explains.

Each of a subnet’s nodes running a given smart contract on the Internet computer requests the URL, and if enough of them receive the same response, it is returned to the requesting container. If the replica responses are different—for example, due to contained timestamps, different order of response values, or different overlapping sets of response values—developers can simply code a transformation function. This standardizes the responses by eliminating parts that are unnecessary (such as timestamps or identifiers), sorting values, or trimming response values ​​- basically fulfilling all relevant transformations that make the responses of all replicas equal to finally reach consensus.

“The container smart contract itself is the HTTP client, so we give it the best possible flexibility and power to deliver the ability to integrate Web3 with Web2,” says Sommer. “With lower costs and fewer trust assumptions, dapp developers can prioritize their products and business logic, and users get stronger security and less waiting time.”

After the Oracles

Reducing external dependencies and intermediaries is a central principle behind blockchain, and is key to increasing the resilience and security of decentralized systems. Eliminating the need for smart contracts to rely on oracles can help developers more easily build and deploy a wide range of decentralized applications related to finance, insurance, communications, sports and logistics. One can imagine asking servers for Internet of Things (IoT) sensor data, as well as connecting to traditional email services and sending chat messages via message ports.

While achieving such real-world use cases is critical to the development of Web3, efforts today require both developers and users to rely on oracles, and rely on trusted intermediaries to access off-chain data to enable a Web3 dapp or blockchain-based service to operate. Compromised data or an exploit of the oracle by hackers – or simply an everyday, conventional technology breach – can destabilize the entire smart contract and dependent smart contracts, thus presenting a single point of failure. Developers and users will expect better experiences as Web3 continues to mature, and this underscores the need for a better approach to integrations.

Eliminating the complexity of current oracle solutions for off-chain data access can have the effect of accelerating Web3 development and user onboarding. HTTPS calls on the Internet computer show how developers can now create products and dapps that interact directly with conventional servers and enterprise infrastructure, effectively blurring the line between Web2 and Web3 while positioning smart contracts to truly eat the world.