Difference between revisions of "HTTPS outcalls"
(Created page 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 tradit...") |
|||
| 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 traditional off-chain Web 2.0 services or enterprise systems. These results of these calls are processed and agreed by consensus, preventing indeterminism.''' | '''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 traditional off-chain Web 2.0 services or enterprise systems. These 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 provided to them by their blockchain. Some also need to interact with traditional systems, which may not be hosted on blockchain. Historically this 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 | + | Many smart contracts need to obtain real-world data from outside the secure universe provided to them by their blockchain. Some also need to interact with traditional systems, which may not be hosted on blockchain. Historically, this 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 solve the problem of actually ''interacting'' with off-chain services. To solve these problems, 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 for a price feed provided by a centralized off-chain crypto exchange like [https://pro.coinbase.com/ Coinbase Pro]. When this occurs, every node in the subnet blockchain hosting the smart contract makes a request to the URL. The result is then passed to the canister smart contract locally using a special [[query call]], which pre-processes the result into a consistent canonical form (for example, selecting a specific time slice from a price time series | + | HTTPS outcalls allow canister smart contracts hosted on the Internet Computer to request a URL, such as the URL for a price feed provided by a centralized off-chain crypto exchange like [https://pro.coinbase.com/ Coinbase Pro]. When this occurs, every node in the subnet blockchain hosting the smart contract makes a request to the URL. The result is then passed to the canister smart contract locally using a special [[query call]], which pre-processes the result into a consistent canonical form (for example, selecting a specific time slice from a price time series which might be different on each node). The canonical result is then agreed by consensus, and provided to the smart contract, so that it can continue trustless execution of the TX. |
| − | In order to trigger an action on a traditional Web 2.0 service, a smart contract can include | + | In order to trigger an action on a traditional Web 2.0 service, or an enterprise system, say, a smart contract can include a cryptographic [[chain key]] signature in its request for a URL served by the service. This allows the service to know that the request it has received was generated by a smart contract execution agreed by blockchain consensus, and thus cannot have been forged. In such architectures, the Web 2.0 service must be careful to only execute the request the first time the URL request is received, yet provide the same answer/result each time. |
Revision as of 17:39, 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 traditional off-chain Web 2.0 services or enterprise systems. These 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 provided to them by their blockchain. Some also need to interact with traditional systems, which may not be hosted on blockchain. Historically, this 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 solve the problem of actually interacting with off-chain services. To solve these problems, 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 for a price feed provided by a centralized off-chain crypto exchange like Coinbase Pro. When this occurs, every node in the subnet blockchain hosting the smart contract makes a request to the URL. The result is then passed to the canister smart contract locally using a special query call, which pre-processes the result into a consistent canonical form (for example, selecting a specific time slice from a price time series which might be different on each node). The canonical result is then agreed by consensus, and provided to the smart contract, so that it can continue trustless execution of the TX.
In order to trigger an action on a traditional Web 2.0 service, or an enterprise system, say, a smart contract can include a cryptographic chain key signature in its request for a URL served by the service. This allows the service to know that the request it has received was generated by a smart contract execution agreed by blockchain consensus, and thus cannot have been forged. In such architectures, the Web 2.0 service must be careful to only execute the request the first time the URL request is received, yet provide the same answer/result each time.