Canister smart contracts on the Internet Computer have the ability to make direct calls to any Web 2.0 data source via HTTPS outcalls without introducing additional trust assumptions.
The explosive growth in the Web 3.0 space in recent years is testament to the power of smart contracts. Smart contracts running on a blockchain provide a reliable and trustworthy mechanism to carry out complex transactions in a decentralized manner. Their power lies in the fact that both the program code as well as the data they operate on reside on-chain. This entails that users can trust that transactions are executed as intended as long as the blockchain itself is trusted. For example, if a user wishes to swap some token for another one on a decentralized exchange (DEX), a smart contract that implements the functionality of an exchange, this user can be confident that he or she will get the other token at an appropriate exchange rate, and not lose the transferred token because of human error or malicious behavior.
While there are clear benefits to having all decisions in a smart contract be based on on-chain information, it is also a limiting factor. Smart contracts on their own cannot readily use the abundance of data available in the “traditional” Web 2.0 world. Think of all the powerful decentralized applications that could be built if external data such as weather forecasts, real-time stock market data, live scores of sporting events, and so on, could be used inside smart contracts!
Trustworthy DataIt is, in fact, possible on most blockchains to inject such data into smart contracts. However, the question is whether the data provider is trustworthy. In a truly decentralized platform, it is not possible to limit or determine who provides data to the system. On the other hand, using a known trusted party to provide external data severely diminishes the decentralized nature of the smart contract. Moreover, while decentralized applications are typically fault tolerant, the dependency on a centralized data provider further introduces an undesirable single point of failure.
What we need to solve this conundrum is a data oracle, an incorruptible, fault-tolerant mechanism that ensures the veracity of all data it provides.
The Oracle ProblemHow can such an oracle be built? As mentioned, having a single party that provides data shatters the decentralized nature of a smart contract as the single party becomes not only the single source of truth but also a single point of failure. From this observation, we conclude that an oracle must somehow consist of multiple data providers. In fact, current state-of-the-art oracle platforms are built around this observation — an oracle platform is itself a distributed, decentralized system with numerous individual nodes collecting information from multiple Web 2.0 sources. The oracle platform cleans and curates the collected information to obtain data that is as complete and accurate as possible. Blockchains integrate with oracle platforms to make their data available to smart contracts.
The approach to have dedicated oracle platforms is clearly superior to relying on centralized entities, but it has several flaws. First of all, data collection and curation in a decentralized system is itself a hard problem. It is often cumbersome to add other data types or sources, and it can be both time-consuming and costly. These operational challenges aside, there is also a fundamental shortcoming that cannot easily be overcome, which is the inherent dependency on the oracle platform. By design, a user must trust not only the blockchain the smart contract of interest is running on but also the oracle platform that feeds in the necessary data for the smart contract to function correctly. Having to trust additional entities is always a security concern, even if these entities are decentralized as well, simply because different entities are never equal in terms of the security they provide.
HTTPS Outcalls: An Essential Building BlockThe question is whether a smart contract can obtain oracular power in a different, smarter way. Fortunately, the answer is “yes”, at least on the Internet Computer. The Internet Computer has a unique “super power” referred to as HTTPS outcalls. This feature enables smart contracts to fetch data from regular (Web 2.0) web servers in a deterministic and yet decentralized fashion. The reader is strongly encouraged to read up on this groundbreaking feature, for example in this article!
It is important to understand that HTTPS outcalls provide access to Web 2.0 resources but nothing more. If a canister smart contract queries data from a particular endpoint, the smart contract may not be able to provide its service if this endpoint becomes unavailable. The smart contract also trusts the endpoint to provide accurate information. In other words, HTTPS outcalls do not provide oracle functionality but they are an essential building block to develop oracles that run entirely on-chain.
Introducing an On-chain OraclePutting theory into practice, we at DFINITY have built and released the Exchange Rate Canister, an on-chain pricing oracle. This canister smart contract provides a crucial piece of functionality for various types of applications. Essentially, for any pair of a base asset and a quote asset, where either asset can be a cryptocurrency or a fiat currency, it returns the exchange rate. The Exchange Rate Canister can return both the current rate as well as rates from the past (subject to the constraint that the data sources provide the necessary historical rates to serve the request). It interacts with the major cryptocurrency exchanges through public APIs to get current or historical pricing information. Additionally, it periodically queries public APIs of foreign exchange data providers around the world to get forex rates.
Technical DetailsGoing a bit deeper into the technical details, whenever the Exchange Rate Canister receives a request using the get_exchange_rate endpoint (the Candid file of the exchange rate canister is available here), it makes the necessary HTTPS outcalls to collect rates. Subsequently, the rates are cleaned by removing outliers and the median of the remaining rates is returned to the caller, along with metadata about the request, such as the number of sources that were queried, how many rates were received, etc.
It is worth noting that implementing such an oracle is no trivial task. A slew of optimizations and enhancements is needed to achieve the desired level of performance and security. For example, recent query results are placed in a least-recently-used cache so that rates can be returned quickly without repeating the same HTTPS outcalls for asset pairs that are requested frequently. Since the number of HTTPS outcalls that a subnet can handle at a time is bounded, there is also rate limiting in place to protect the subnet against a flood of requests. As an HTTPS outcall is an expensive operation in terms of the number of cycles consumed, the Exchange Rate Canister charges a fair price for its service in that the number of cycles it charges depends on the actual number of HTTPS outcalls that it makes to serve a request. If the response can be served from the cache, the cost is low at 200 million cycles (which corresponds roughly to 0.03 USD cents!), but it can cost up to 5 billion cycles (approximately 0.7 USD cents) for a cryptocurrency-cryptocurrency pair that is not cached.
The fact that requests are not free also provides a certain level of protection against denial-of-service attacks. For those who wish to dive a little deeper, the source code of the Exchange Rate Ranister is publicly available.
Oracle Capabilities in PracticeAs mentioned before, there are plenty of use cases for pricing oracles such as the Exchange Rate Canister. It is a desirable, if not required, feature for DEXs in order to compare the exchange rates within the DEXs against the market rate. It is also useful for canisters that hold certain funds as the exchange rate canister provides a simple way to determine the value of the assets under management, for example, with respect to a fiat currency.
Lastly, the Exchange Rate Canister plays an important role for the Internet Computer’s network nervous system (NNS). Since the price of cycles is pegged to the IMF SDR basket of currencies (currency symbol: XDR) at 1 XDR per 1 trillion cycles and the cycle-minting canister (CMC) burns ICP to generate cycles, the cycle-minting canister must have access to an accurate ICP/XDR conversion rate. This conversion rate was previously updated through NNS proposals, requiring 144 proposals a day at one proposal every 10 minutes. Since May 8, 2023, the CMC fetches the ICP/XDR rate from the exchange rate canister, making exchange rate proposals obsolete.
The exchange rate canister is a great example of a smart contract unleashing the power of HTTPS outcalls by offering an oracle service that runs entirely on-chain. Of course, there is plenty of room for many other use cases of on-chain oracles that correspond to the various types of Web 2.0 data. For example, the Internet Computer ecosystem could also benefit from more on-chain price oracles similar to the Exchange Rate Canister but tapping into different data sources or providing rates for different asset classes such as stocks or ETFs.
The Exchange Rate Canister is just the starting point for the next generation of canister smart contracts with oracle capabilities to reach a new level of reliability, accuracy, and trustworthiness. It’s certainly exciting to think about many more popping up in the future!
By Thomas Locher, Senior Researcher at DFINITY