How HTTPS Outcalls will Power the Evolution of the EVM

The IC blockchain has introduced a variety of innovative features that set it apart from its competition. One such innovation is the provision of HTTPS outcalls to web URLs by canister smart contracts. Through this method, it is possible for canister smart contracts to interact with off-chain systems, something that has immense value and a whole bunch of different use cases.

The results of these outcalls are processed and subsequently agreed upon by consensus, a system that prevents non-determinism. While other blockchains, such as Ethereum, require the use of third-party oracles and bridges in order to obtain trusted off-chain data, the IC can do without these providers thanks to HTTPS outcalls. This is yet another example of the integrated, unified manner in which the IC is built, making it a complete network that covers all requirements of developers and users.

Outcalls can be placed to various off-chain sources of information, such as web 2.0 services and enterprise IT infrastructure. There are many examples of dApps and on-chain services that require data from these sources, and having a method to obtain this data is crucial.

Trust Issues

The ethos of web3 is to be trustless and permissionless insofar as possible. Blockchain technology insisting on decentralization ensures that no man in the middle needs to be trusted to facilitate transactions. Using oracles such as Chainlink for off-chain information goes against the notion of trusting no one. The issue of trusting Oracle providers is resolved by making HTTPS outcalls part of the network.

In this sense, HTTPS outcalls will power the evolution of the EVM; they create a scenario where dApps can stay on-chain, start to finish, and not have to go against the principles of crypto in order to achieve functionality.

It is important to remember that not only does the oracle or bridge provider need to be trusted, but so too does their security. Hacks are another reason why it is better not to trust a third party if it is avoidable. Any other forms of fault can also affect the network adversely, making HTTPS outcalls a far better alternative.

Improved Communication

HTTPS outcalls can be used by canister smart contracts to perform a variety of different tasks. For example, outcalls can be used to download time series for the price performance of a given asset from a centralized exchange such as Coinbase. In this scenario, every node on the subnet blockchain which hosts the smart contract calls the URL separately. Each node then passes the result locally to a function that has been implemented by the requesting smart contract using a query call. This query call pre-processes the result in order to make it consistent with the results obtained by all of the other nodes on the subnet blockchain. As nodes may make requests at slightly different times, results obtained by nodes may be different.

Once results are agreed by nodes via consensus, the result is passed back to the requesting smart contract.

A chain-key signature may be included in an HTTPS outcall for a URL.  This allows a target service to verify that the request was genuine and was agreed by consensus on chain.

How HTTPS Outcalls Work

The HTTPS outcall process is split into several layers, which enable the process to function correctly.

The first step is for a canister to make the HTTPS outcall request to the execution layer's management canister smart contract. Once the request has been made it is stored in the replicated state of the required subnet.

The HTTP pool manager reads state changes as part of the consensus layer and keeps tabs on outstanding HTTPS outcall requests.

When the HTTP pool manager spots a new request, it forwards it to the networking layer, to a component called the HTTP adapter shim. This lightweight component is responsible for communicating with the HTTP adapter, which is a separate process kept isolated for security reasons.

The HTTP adapter shim then forwards the request via RPC to the HTTP adapter. The HTTPS request is then issued to the remote server, and a response is returned to the HTTP adapter. The request is returned to the HTTP pool manager.

A transform function is carried out on the calling canister, which makes requests exactly the same so that the subnet can reach a consensus.

The consensus layer distributes shares of the response so that the blockmaker can see what has been received by peers. After this, the block maker includes the response in a block.

The response is made available to the execution layer, and then a callback is invoked in order to return the response to the canister asynchronously.

How Consensus Is Reached

Although on the surface somewhat complicated, the mechanism by which HTTPS outcalls work is extremely efficient and practical for use as an integral piece of the blockchain.

Nodes achieve consensus by excluding nodes that have received differing or defective results. No transformation function is required for nodes as responses are replicas. Less than one third of responses can be defective or differing, and consensus can still be reached.

Cases of consensus in the context of HTTPS outcalls can be reached using an extension of the IC's native consensus protocol. Importantly, the canister developer must provide the transformation function if required, as is the case when using an API.

HTTPS Outcalls Will Power EVM Evolution

There is little doubt that HTTPS outcalls will provide more functionality and efficiency to the IC blockchain.

Given that the IC has worked hard to build a network that is more than just a blockchain, but a network that covers the full suite of developer needs such as on-stage storage and off-chain communication, HTTPS outcalls are a core pillar of what makes the IC great.

These extra tools can help the EVM level up and grow.

Connect with Bitfinity Network

Bitfinity Wallet |Bitfinity Network | Twitter | Website | Telegram | Discord | Github