Difference between revisions of "HTTPS outcalls"

From Internet Computer Wiki
Jump to: navigation, search
m
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 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 non determinism.'''
 
'''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 non determinism.'''
  
Often, smart contract software needs to obtain real-world data from outside the secure blockchain universe that hosts it. Smart contracts may also need to interact with off-chain systems outside their secure universe. 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], which involve centralized actors who copy the off-chain data on-chain, so that it can be accessed. 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.
+
Often, smart contract software needs to obtain real-world data from outside the secure blockchain universe that hosts it. Smart contracts may also need to interact with off-chain systems outside their secure universe. 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]. These services are typically provided by centralized entities, such as corporations, which copy off-chain data onto the blockchain where it can be accessed by smart contracts. The problem is that these services must a) be trusted be truthful, and b) be paid. Moreover, when smart contracts need to ''interact'' with off-chain services, for example by calling functions they provide, they cannot help. 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 [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.
 
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 in an off-chain system, a smart contract may 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 genuine smart contract execution agreed upon by blockchain 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.
 
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 service to know that the request it has received was generated by a genuine smart contract execution agreed upon by blockchain 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.

Revision as of 21:47, 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 non determinism.

Often, smart contract software needs to obtain real-world data from outside the secure blockchain universe that hosts it. Smart contracts may also need to interact with off-chain systems outside their secure universe. 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. These services are typically provided by centralized entities, such as corporations, which copy off-chain data onto the blockchain where it can be accessed by smart contracts. The problem is that these services must a) be trusted be truthful, and b) be paid. Moreover, when smart contracts need to interact with off-chain services, for example by calling functions they provide, they cannot help. 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 in an off-chain system, a smart contract may 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 genuine smart contract execution agreed upon by blockchain 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.