Why will the IC be able to call external APIs while other blockchains can't do that?

General
1

Would someone be so kind to help me understand why the IC is able to do that or point me towards good resources on the topic?

This will be a game changer as far as I understand.

Thank you in advance

2

Hi @Mathias

Thanks for your interest in this topic. This will indeed be a game changer as it will allow for many exciting scenarios to be realized.

To answer your question: There are two potential reasons that come to my mind why the IC can do that, but other blockchains cannot or do not:

  • Thanks to the subnet-based architecture of the IC, only the replicas of one subnet handle an HTTP(S) request, and not all replicas of the blockchain. This is definitely a big advantage in terms of scalability. More detail: For making the HTTP request, each replica of the subnet, e.g., 13 replicas in a standard-size subnet, make the same request, optionally apply a transformation on the response to normalize it to not contain any per-request-variable items any more, and then run consensus over the transformed responses.
  • Our consensus implementation is rather flexible in terms of handling different kinds of payload that require different processing. E.g., ingress messages, Xnet messages, DKG-related and soon also threshold-ECDSA-related messages and HTTP(S) messages. Not sure, whether the consensus layer of every blockchain provides that much flexibility. Any experience here?

There is a separate topic on Canisters making HTTP requests and the same question has been asked there as well. I copied the answer over, but would like to point you to the other topic for the other interesting discussions there.

3 Likes
3

Hello Mathias,

Adding to @dieter.sommer’s reply.

Web2 and blockchains(IC) are two “seperate” trust domains. Simply put for them to talk to each other you have to solve the following 2 trust questions.

  1. Can a Web2 server verify its interacting with the IC
  2. Can IC verify its indeed talking to the right Web2 service

For point 1, the example usecase is twitter displaying your display image sourced from your owned IC NFT. Twitter can verify that the image indeed came from IC, by checking IC signatures. This feature is UNIQUE to the IC by virtue of chain key technology.

For point 2, the example usecase is you want to save a news article in from a prominent website in a canister for legal reasons. This is tricky as any end-user can present a fake html page present it to the canister saying it originated from news website. IC’s solution is to have multiple replica nodes fetch the data from the website and corroborate the authencity of data using the existing consenus algorithm. Naively, this is not possible on ETH without some sharded consensus, for eth to attempt something like this would mean each validator (1000’s of them) talking to the web2 service.

Point 2 is more complicated in advanced settings where web2 data is not static, viz. personalized or authenticated.

1 Like
4

Thank you very much @dieter.sommer and @faraz.shaikh!

I will definitely read the forum discussion on the topic (I did not see that there is one unfortunately).

It makes sense that it’s simply not feasible to send requests from all the validators of the network.

That websites can just authenticate messages form the IC is a really nice solution. As far as I understand
a front-end for an Ethereum based dapp just sends requests to many different nodes hoping that not all of them are malicious or it has to run its own node. The IC definitely solves that better.

Thanks again for the answers, I will read the forum discussion and think some more about the different cases where web2 data is not static for example.

5

Actually, the reality is worse than that. Many frontends actually rely on Ethereum nodes run by a centralized provider like Infura. Running your own node is a pain since you need to download the entire >300 GB blockchain to disk and keep it in sync.

So not only are many Ethereum-based dapp frontends served from AWS, they also interact with a centralized backend that happens to host a decentralized blockchain. This problem is discussed in this article, which blew up a couple weeks ago: Moxie Marlinspike >> Blog >> My first impressions of web3

But… the Internet Computer fixes both issues. It can serve frontends directly to clients AND removes the need to trust intermediaries like Infura thanks to chain key cryptography, which signs responses that can be verified with just a single 48-byte public key. (Actually, the reality is more nuanced, as queries aren’t signed by default without certified variables.)

This was slightly off-topic, as this thread is more about smart contracts making requests to centralized services, i.e. web3 calling web2 instead of web2 calling web3.

1 Like
6

Thank you very much for the reply!

The article really is great. You’re right, verified responses and certified variables are another game changer of the IC.