|
|
| (31 intermediate revisions by 6 users not shown) |
| 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.'''
| + | Please see [https://internetcomputer.org/docs/current/references/https-outcalls-how-it-works How HTTPS outcalls work] |
| − | | |
| − | 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 challenge is that, ultimately, 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, which may be different for each node). The canonical result is then agreed by consensus, and provided to the smart contract, so that it can continue its TX.
| |
| − | | |
| − | In order to trigger an action on a traditional Web 2.0 service, a smart contract can include, a cryptographic 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 executing through blockchain consensus, and thus cannot be 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.
| |
Latest revision as of 21:15, 8 March 2024