Is it possible to make external service calls from chaincode? For example, if I need to lookup the current exchange rate or today's temperature using a public API how can I make that call from the chaincode?
If external calls are allowed then there is a chance of each node providing a different output (non-deterministic behavior). So how will consensus be reached?
There is always the opportunity for two asset updates from different sources to hit two endorsers in a different order. That will create read/write sets that do not match. This can cause both to fail if the endorsement policy requires that all endorsers achieve the same r/w set. Adding reads of external data that can change or can fail owing to any number of momentary issues just exacerbates this issue.
But the changes will be handled correctly no matter which endorsement policy is in effect because only endorsed r/w sets get committed.
Now, if you decide to write to an external database from a chaincode, then all bets are off. A last minute failure because of key clashes in the same block (fabric v1 requires that updates targeting the same keys never be processed together and thus must be flow controlled) will cause the transaction to never get committed.
When that happens, the external writes should be rolled back, but the chaincode is long done executing and so the total dataset has now been corrupted. This is a non starter.
However, should someone decide to tempt fate and build an elaborate system where chaincode updates external data, the failure can be detected and the updates rolled back so long as the transaction ID is part of the journal entry for the update. This solution is unspeakably brittle, and if you try it then you will likely be sorry :-)
It is possible and doesn't break Fabric. Fabric doesn't have to be deterministic as the RW set is check on all endorsers but it's not replayed, only it's check that the READ replica set is the same when the transaction proposal is submited.
On the receivers endorser the READ replica is check and if the local and the proposed have same versions the transaction is valid.
On Solidity's smartcontracts the transaction is replayed, that's why it must be deterministic.
I think calling external APIs approach is not totally evil. It's perfect way to validate endorsing peers that really data retrieved from external source. i.e getting today's $/€ rate from a trusted global source. Parties cannot say that: "Hey you made up the currency, you're corrupt", if all endorsing peers got the same result from same source.
According to this Hyperledger-Composer Documentation, the section discusses: if external-api calls are possible, how and when to use it, when to avoid it, pros and cons, etc. I want to emphasize this section as an answer:
HTTP requests may result in different responses for multiple reasons:
- Peer nodes in different organisations may run in different data centers, in different countries, in different time zones.
- Peer nodes in different organisations may not have access to the HTTP server depending on public internet access and firewall restrictions.
- Peer nodes in different organisations may authenticate to the HTTP server as different users, resulting in different HTTP responses.
In order to minimize the risks of consensus failures when making HTTP requests from a transaction processor function, it is recommended you use make HTTP requests that are either:
- Safe, in that the HTTP request does not modify any state on the HTTP server.
- Idempotent, in that the same HTTP request can be made many times without different outcomes.
