Beyond Oracles: Direct HTTPS Outcalls From Canister Smart Contracts on the Internet Computer
Internet Computer canisters can now directly make HTTPS outcalls to any data source without using oracles.
Blockchains generally provide smart contracts with access to external data via oracles. Though oracles can be based on a variety of architectures, in each case the oracle provides data as an external party, which requires additional trust assumptions, complicates the programming model, increases operational costs, and adds complexity.
An HTTPS outcall mechanism for smart contracts enables a wide range of applications — for example, oracle services directly integrated into the Internet Computer in a trustless manner, user notifications, and anything else that requires communication with servers on the internet.
Enabling canister smart contracts to make HTTPS outcalls is a key element of a larger R&D focus on general integrations for the Internet Computer. The ICP community overwhelmingly adopted an NNS design proposal for this feature in February. It is now available on mainnet, with detailed documentation. (See below to learn more about a related sample dapp.)
Until now, the limitation that canister smart contracts could only speak with other services that are built on the IC has prevented the development of canisters that can be deployed for several important use cases. These include:
- Getting real-time exchange rates for cryptocurrencies to build DeFi applications, querying weather data for decentralized insurance services, as well as accessing things like sports scores, voting results, stock prices, and the wealth of data that Web2 services have to offer.
- Sending push notifications and email via traditional communications channels.
- Integrating with other blockchains by communicating with multiple corresponding HTTP-based cloud nodes.
Blockchains often rely on oracles where an off-chain authority reads from a specific external data source and writes data to a special smart contract for that data source. Developers are then able to write their own smart contracts that interact with the data source by using the oracle smart contract as a proxy. This approach has a few downsides:
- Because it typically lives off-chain, the authority responsible for populating the smart contract is another entity that must be trusted.
- It’s also another entity that could possibly fail, even without any maliciousness on the operator’s part.
- Furthermore, off-chain setup is probably too costly for use cases that aren’t widely needed.
We’ve taken a different approach to solving this problem on the IC. From the perspective of the API that is exposed, this essentially involves allowing canisters to directly make HTTPS outcalls to any external HTTP-based data source.
This feature covers a primary subset of functionalities that are typically provided by oracle services, but it does so in a trustless manner, i.e., without enabling further parties like oracles that require further trust assumptions to be introduced into the overall trust model.
The code snippet shown in the above slide shows how easy it is, but what’s happening behind the scenes is a bit more complicated.
When the outcall is made, it is actually placed in the subnet’s replicated state. Once a replica sees the call in the replicated state, it makes the call that the canister made to the external data source. This applies to all replicas.
The replicas of the IC each need to make the same call and obtain consensus over the result. Once the replicas are able to reach consensus on what the response to the request was, they include it as a special type of payload in an IC block. Finally, once this block is finalized, it is passed on to the execution layer, which will deliver the HTTP response to the canister that made the HTTP request. The canister can now safely use the HTTP response to change its state, without risking divergence across replicas.
In order to be able to reach consensus on what the response was, it may be necessary that the canister expose a transformation function that normalizes the responses received by the different replicas by removing parts that may be different in the different responses, e.g., timestamps or per-response identifiers. Having to provide a transformation function is a difference in the programming model when compared to how you make an HTTP request in a Web2 application.
To demonstrate this feature in action, we built an exchange-rate sample dapp, the canister of which makes direct HTTP calls to an off-chain service directly from the Internet Computer (the preceding link directs you to the relevant piece of code making the HTTP call). This sample dapp pulls the ICP-to-USDC exchange rate from a Coinbase API directly, without middleman infrastructure — which is just one example of a vast array of data sources that can be called using this feature.
You can review the code of the deployed sample dapp and related documentation by clicking below:
The source code is open-sourced on GitHub under the DFINITY examples repository.
We eagerly look forward to seeing how the delivery of this feature accelerates Web3 innovation on the Internet Computer.
____
