Blockchain Direct HTTP Requests Through the Internet Computer – The New Stack

Blockchain Direct HTTP Requests Through the Internet Computer – The New Stack

Although there is a lot of optimism in Web3 about a future where everything happens on a blockchain, we are far from a reality. The vast majority of payload data is generated in traditional data centers or cloud computing infrastructure and interfaced using familiar tools that heavily leverage HTTP or HTTPS.

Decentralized applications running on one of the Layer 1 blockchains, like Ethereum or Solana, interface with HTTP-based services using something called an oracle. These oracles act as trusted middleware to enable the creation of hybrid smart contact, where on-chain code can interact with off-chain infrastructure and data. Chainlink Networka popular decentralized oracle network, has a short explainer video on what it looks like.

The problem with oracles

Although oracles are the primary means of connecting dApps (decentralized applications) with off-chain data and infrastructure, there are some drawbacks. The queries are indirect, which means you don’t call the API directly to the source of the data you want to query – the oracle does that for you, and then your dApp has to trust the response from the oracle. This approach also comes with costs associated with using Oracle as a third-party intermediary.

DFINITY Foundationone of the biggest contributors to Internet Computer, a Layer 1 blockchain, offers an alternative approach where dApps can make HTTP requests directly using an API built into the blockchain.

In an interview with The New Stack, Dieter Sommer, technical program manager for the DFINITY Foundation, explains the challenge of relying on oracles in this way. “Anyone who wants to do something reasonable needs some form of integration with Web 2, and all other blockchains use oracles for that,” he said. “Oracles are outside services, so if you rely on an oracle to connect to Web 2, the oracle does all the HTTP stuff. That also means you introduce a lot of new trust assumptions; for example, in the model standard of using Chainlink oracle, you call an oracle provider and you have to trust that provider, which is a very weak model.

An API to make HTTP calls directly

The DFINITY Foundation uses slightly different terminology to explain how the internet computer blockchain infrastructure works. With a foundation of the internet computer protocol, the internet computer hosts smart contracts called canisters which are a combination of WebAssembly bytecode and memory pages where that code runs. Deploying a canister means that the corresponding code and state is replicated to all nodes in the subnet on which it is deployed.

This concept of replication is one of the reasons why most blockchains today use oracles to make HTTP requests. In the current Internet computer design, each replica would make the same HTTP call to an external service. But the HTTP response returned to each replica may be different, as there may be variations in timestamps or IDs. When the replicas all get a slightly different response, consensus cannot be reached, effectively breaking the subnet.

In the upcoming Chromium version of the Internet Computer, there is a new approach to solving this problem and providing the blockchain with a direct integration using an API to make HTTP calls. This removes the trust assumptions required to use an oracle and theoretically simplifies the process of accessing off-chain data.

With an asynchronous API provided through the management canister, each node will make the same HTTP request. When each node receives a response, it signs the response and tells it to the other nodes. Once the consensus layer has aggregated enough signatures, it will include the response in the blockchain. When the block is finalized, the response is sent back to the execution layer, which in turn resumes the computation that originated the HTTP request.

Navigate inconsistent responses

When all nodes receive the same response around the same time, this approach works perfectly. This should work even in scenarios where a malicious node reports false information, as long as enough nodes come back with the same response.

As Sommer puts it, “All nodes in a subnet make the request and only if the consensus succeeds, which means at least two-thirds of the replicas agree on the result, then it is sent back to the canister accordingly. This allows a secure call to the outside, without any external third party to rely on. Our consensus protocol is flexible enough to allow such an extension.

A more complicated scenario is when the queries are semantically identical, but potentially have minor differences that don’t matter to the computational result. Instead of not coming to a consensus, you can code around these inconsistencies using a function that transforms the answer, showing only the part of the answer required for the calculation. Consider an example like needing to return a text string where the text is packed into a response with a timestamp. If the text string is the same in all cases, it doesn’t matter that the timestamps vary and you can use the function to eliminate them.

For the initial release, only GET requests are supported. The longer term plan is to support POST requests as well. Looking at the DFINITY Foundation Video covering this new feature in additional detail, Ivan Malison, a software engineer at DFINITY, explains that POST requests are more complicated. He showed an example of payment by credit card. You wouldn’t want to try to charge the same card multiple times or get a different response to your POST request, such as a success message once and a denial the next. The video provided Stripe’s idempotence for secure API attempts as an example of how to implement it properly in the future.

main picture via Pexels.