|
|
| (12 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 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 nondeterminism. This avoids the need for trusted oracles and bridges.'''
| + | Please see [https://internetcomputer.org/docs/current/references/https-outcalls-how-it-works How HTTPS outcalls work] |
| − | | |
| − | Often, smart contract software needs to obtain real-world data, which originates from outside the secure and unstoppable on-chain blockchain universe that hosts them. Smart contracts may also need to interact with off-chain systems that are outside their secure blockchain universe. Because of the way blockchains work, historically this has presented major hurdles to blockchain developers. For example, to obtain off-chain data, smart contract have traditionally interacted with centrally-operated oracle services, such as [https://chain.link/ Chainlink]. These services are provided by trusted intermediaries, such as corporations, which perform the role of copying off-chain data onto the blockchain where it can be accessed by smart contracts. The problem is that these services must a) be trusted to remain honest, and not get hacked or otherwise become faulty, and b) be paid. Moreover, they cannot help when smart contracts need to ''interact'' with off-chain services, for example by calling their functions. 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, for example to download a time series for the price of an asset, which is published by a centralized crypto exchange such as [https://pro.coinbase.com/ Coinbase Pro]. When this occurs, every node in the subnet blockchain hosting the smart contract requests the URL separately. Each node then locally passes the result they obtained to a special function implemented by the requesting canister smart contract using a [[query call]], which pre-processes the result with the aim of making it consistent with the results the other nodes have obtained and pre-processed (for example, since each node would request the time series at a very slightly different times, they might cover slightly different durations, and the pre-processing could address this by extracting a specific time slice that is likely to be common). If the pre-processed result is sufficiently consistent across all the nodes, it is agreed by consensus, and provided back to the smart contract that requested the URL so that it can continue trustlessly processing the smart contract call (TX).
| |
| − | | |
| − | In order to trigger an action in an off-chain system, a smart contract may include a cryptographic [[chain key]] signature in its request for a URL. This allows the target service to validate that the request it has received was generated by a genuine smart contract execution that was agreed by consensus. 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, it should return exactly the same result.
| |