Smart contracts on the Internet Computer, like on any other blockchain, cannot communicate with external servers per se, e.g., via making HTTP(S) requests. Enabling canisters to make HTTP(S) requests will help integrate the Internet Computer with the Web 2.0 world. This allows for a plurality of new use cases, e.g., obtaining exchange rate data from external servers for DeFi applications, obtaining weather data for decentralized insurance services, or sending notifications to users via traditional communications channels. The first version of this feature will cover a subset of the functionalities that are typically provided by oracle services, but will do so in a trustless manner.
Key people involved
Yotam Harchol, Ivan Malison, Islam El-Ashi, Manu Drijvers, Thomas Locher, Akhi Singhania, Alexa Smith, Dieter Sommer
It is not possible for canisters currently to make HTTP(S) requests to servers outside the Internet Computer. This limits what canisters can do as it lacks an integration with the Web 2.0 world. The reason that it is not easy to let canisters make HTTP(S) requests to any external system is that this is a non-deterministic process and all replicas in a subnet need to operate in a completely deterministic manner. A subset of the HTTP(S) scenarios can be captured with an approach of every replica making the same request and then achieving consensus on the response. This is not straightforward as responses for the same call, e.g., to a price API, may differ in some parts, e.g., identifiers or timestamps. Doing a transformation on the HTTP(S) responses before feeding them into consensus can solve this problem.
According to the current thinking, the first MVP for this feature should comprise the ability to make HTTP(S) GET requests, specify a transformation to be applied to the responses by each replica, and then running consensus over the responses. This will already allow for a large set of use cases.
State-changing requests to standard services are problematic in this model as the request is executed by every replica. If the external service, or a fronting service built for the IC interaction, is aware of this model, state-changing calls can be done as well once POST/PUT calls are available.
Later extensions may comprise, among other things, the following:
- POST/PUT requests: enables updates to the outside world if the call model of every replica making the request is accounted for.
- Customizable quorum (“unsafe mode”), where only one replica or a specified number of replicas make(s) the request, with the inherent reduction in security. This maybe useful for less critical interactions and will easily allow for making state changing requests to the outside world in the case of a single replica making the request.
- Allowing for slightly different numerical values in responses, e.g., relevant for fast-changing data that are to be queried.
- Persistent connections (for better performance for periodically executed queries)
Enabling canisters to make HTTP(S) requests is one of the topics of the larger long-term R&D motion proposal on General Integrations (see Long Term R&D: General Integration (Proposal)). It has also been picked up by the community in another topic in the dev part of the forum (IC-530 "Canister can make HTTP requests") after it has been “leaked” as part of an Inside DFINITY episode (see Direct Integration with Bitcoin - #70 by skilesare, Idempotent egress messages (e.g send an email) - #2 by wang) where it has already been discussed in an internal DFINITY meeting in the context of the Bitcoin integration feature because of possible architecture synergies.
Some other related discussion has already been ongoing in multiple other places in the forum.
- Idempotent egress messages (e.g send an email)
- Make external (non-IC) HTTP request from backend canister?
This is a cross-cutting feature requiring work in the networking, consensus, message routing, and execution layers. Engineers from each of the teams will join the discussion here so we can answer any question that comes up.