Difference between revisions of "HTTPS outcalls"
m |
|||
| Line 1: | Line 1: | ||
| − | '''On the Internet Computer blockchain, canister smart contracts can make HTTP outcalls to specified URLs, either to directly obtain off-chain data, or to interact with | + | '''On the Internet Computer blockchain, canister smart contracts can make HTTP outcalls to specified URLs, either to directly obtain off-chain data, or to interact with off-chain systems, such as Web 2.0 services or enterprise IT infrastructure. The results of these calls are processed and agreed by consensus, preventing indeterminism.''' |
| − | Many smart contracts need to obtain real-world data from outside the secure universe | + | Many smart contracts need to obtain real-world data from outside the secure blockchain universe that hosts them. Some also need to interact with off-chain systems that are not hosted on a blockchain. Historically, this has presented major hurdles to blockchain developers. For example, to obtain off-chain data, smart contracts often have to interact with trusted oracle services, such as [https://chain.link/ Chainlink]. The problem is that these services must a) be trusted be truthful, and b) be paid. Moreover, they do not help with smart contracts need to ''interact'' with off-chain services. To solve for both these needs, the Internet Computer provides an HTTPS outcall feature. |
| − | HTTPS outcalls allow canister smart contracts hosted on the Internet Computer to request a URL, such as the URL | + | HTTPS outcalls allow canister smart contracts hosted on the Internet Computer to request a URL, such as the URL of a price feed published by a centralized crypto financial exchange like [https://pro.coinbase.com/ Coinbase Pro]. When this occurs, every node in the subnet blockchain hosting the smart contract makes their own request for the URL. Each node then individually passes the result to a special function of the requesting canister smart contract locally, using a [[query call]], which pre-processes the result with the aim of making sure that it will be consistent with the results returned by other nodes (this is necessary, since, for example, each node will have requested the URL at slightly different times, and thus may have received different results). The pre-processed result is then agreed by consensus, if it is sufficiently consistent across the nodes, and then provided to the smart contract that requested the URL so that it can continue trustlessly processing the initiating TX. |
| − | In order to trigger an action on | + | In order to trigger an action on an off-chain system, a smart contract can include a cryptographic [[chain key]] signature in its request for a URL. This allows the service to know that the request it has received was generated by a smart contract execution agreed upon by blockchain consensus, and therefore that cannot have been forged. In such architectures, when an off-chain service receives a valid request for a URL, it must take care to only execute it once (since many nodes will make the same request), and for each subsequent request after the first, return exactly the same result. |
Revision as of 21:18, 25 July 2022
On the Internet Computer blockchain, canister smart contracts can make HTTP outcalls to specified URLs, either to directly obtain off-chain data, or to interact with off-chain systems, such as Web 2.0 services or enterprise IT infrastructure. The results of these calls are processed and agreed by consensus, preventing indeterminism.
Many smart contracts need to obtain real-world data from outside the secure blockchain universe that hosts them. Some also need to interact with off-chain systems that are not hosted on a blockchain. Historically, this has presented major hurdles to blockchain developers. For example, to obtain off-chain data, smart contracts often have to interact with trusted oracle services, such as Chainlink. The problem is that these services must a) be trusted be truthful, and b) be paid. Moreover, they do not help with smart contracts need to interact with off-chain services. To solve for both these needs, the Internet Computer provides an HTTPS outcall feature.
HTTPS outcalls allow canister smart contracts hosted on the Internet Computer to request a URL, such as the URL of a price feed published by a centralized crypto financial exchange like Coinbase Pro. When this occurs, every node in the subnet blockchain hosting the smart contract makes their own request for the URL. Each node then individually passes the result to a special function of the requesting canister smart contract locally, using a query call, which pre-processes the result with the aim of making sure that it will be consistent with the results returned by other nodes (this is necessary, since, for example, each node will have requested the URL at slightly different times, and thus may have received different results). The pre-processed result is then agreed by consensus, if it is sufficiently consistent across the nodes, and then provided to the smart contract that requested the URL so that it can continue trustlessly processing the initiating TX.
In order to trigger an action on an off-chain system, a smart contract can include a cryptographic chain key signature in its request for a URL. This allows the service to know that the request it has received was generated by a smart contract execution agreed upon by blockchain consensus, and therefore that cannot have been forged. In such architectures, when an off-chain service receives a valid request for a URL, it must take care to only execute it once (since many nodes will make the same request), and for each subsequent request after the first, return exactly the same result.