Difference between revisions of "HTTPS outcalls"
m |
|||
| Line 3: | Line 3: | ||
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 for both these needs, the Internet Computer provides an HTTPS outcall feature. | 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 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 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 | + | 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 separate request for the URL. Each then passes the result to the canister smart contract locally, using a [[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 could be different on each node as they must have made their requests at slightly different times). The canonical results are then agreed by consensus, if they are consistent, and the agreed result provided to the smart contract so that it can continue trustless continue execution of the TX that wanted the URL. |
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 service must be careful to only execute functionality the first time the URL is requested, and to provide the same answer/result each time so that it can be agreed by consensus. | 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 service must be careful to only execute functionality the first time the URL is requested, and to provide the same answer/result each time so that it can be agreed by consensus. | ||
Revision as of 17:45, 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. 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 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 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 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 separate request for the URL. Each then passes the result to the canister smart contract locally, using a 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 could be different on each node as they must have made their requests at slightly different times). The canonical results are then agreed by consensus, if they are consistent, and the agreed result provided to the smart contract so that it can continue trustless continue execution of the TX that wanted the URL.
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 service must be careful to only execute functionality the first time the URL is requested, and to provide the same answer/result each time so that it can be agreed by consensus.