Oracles and bridges have been a trusted intermediary between blockchain and off-chain systems, which include data providers, cloud providers, payment systems, web APIs, and many more backend platforms. When exploring the blockchain ecosystem, one fundamental function we look out for is interoperability, this function has to do with the ability of computer systems or software to exchange and make use of information, and for this to be a success it needs to be secure and functioning for mainstream adoption of Web3 products and services.
How secure and convenient are oracles and bridges?
Oracle has its functional sides, but one of its major problem stems from the situation that: blockchains could not pull or push data to any external system as it has a built-in capability. As such, blockchains are isolated networks, similar to a computer without an Internet connection.
Lucky to say, NOT ANYMORE as the Internet Computer Protocol is the first blockchain platform with an On-chain functionality which is able to fetch API and other Off-chain data without the use of Oracle, limiting the hurdles that come with Web3 bridges through ICP HTTPS outcalls update. Limitations such as dependency on external data sources and their reliability, potential security vulnerabilities and risks of data manipulation, Oracle failure or malicious attacks compromising the integrity of smart contracts, additional complexity and cost of Oracle implementation and maintenance
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 upon by consensus, preventing non-determinism. This avoids the need for trusted oracles and bridges.
Oracles can be described as a tedious activity or workaround rather than a possible solution based on how they function. They serve as an off-chain authority that reads external data from a particular source and then writes that data to a special smart contract. Developers then write their smart contracts that interact with the Oracle smart contract, thus communicating with the original data source by proxy.
HTTPS outcalls, on the other hand, allow The Internet Computer's canister smart contracts to connect directly with off-chain data endpoints or terminals, such as requesting cryptocurrency market data or weather data. This allows access to all of the data that Web2 services could possibly provide and thus has significant implications for the future of the Internet Computer.
This is how HTTPs work on the Internet Computer Protocol; when an outcall is made, the communication procedure is not end to end from start to finish, rather, the outcall is placed in the replicated state of the canister subnet, and all replicas make the same call to the external data source. When all replicas make the same call and reach a consensus on the outcome, they store the data as a specific type of payload in an ICP block. Once the block is completed, the data is sent to the execution layer, which sends the HTTP response to the request canister. Because a consensus was established in both the requesting and fetching processes, the canister can use the HTTP response without fear of divergence amongst replicas.
This is a big deal for developers, as the Internet Computer is now a stop shop for both Off-chain and On-chain services. ICP is all about true interoperability, which means that all data irrespective of where they are stored can be communicable regardless of where the recipient is located.