Blockchains and Oracles: Similarities, Differences, and Synergies

Blockchains and oracles are both critical network infrastructure to developing decentralized applications (dApps) and use similar security approaches like cryptography, decentralized consensus, and cryptoeconomic incentives. However, they also differ in network architecture, service offerings, node composition, and their overall purpose. These differences are synergistic and combine to form hybrid smart contracts—smart contracts that retain the security assumptions of blockchains while achieving extensive feature richness via oracles.

Blockchains introduce new backend infrastructure for running tamper-proof computation and storing data on immutable ledgers. Although initially used to create and manage decentralized forms of money, blockchains have evolved to now power smart contracts—deterministic programs with conditional logic (if/when x event happens, trigger y action). 

Like the Internet’s value to computers, oracles opened up the full potential of smart contracts by allowing them to execute using data and computation from outside the blockchain (off-chain). These hybrid smart contracts provide an advanced framework for supporting decentralized applications (dApps) where the similarities between blockchains and oracles ensure end-to-end decentralization while their combined differences make enhanced connectivity, scalability, privacy, and fairness possible without sacrificing the underlying security model. 

The following article will offer a deeper, more nuanced examination of the purpose and architecture of blockchains and oracles, along with the similarities, differences, and synergies between them.

Comparing the Purpose and Architecture of Blockchains and Oracles

Before diving into the similarities and differences, let’s define the purpose and generalized architecture of both blockchains and oracles in terms of the roles they serve for dApps.

Blockchains

The core purpose of blockchains is to maintain a persistent distributed ledger of data, often consisting of digital assets. A blockchain ledger stores users’ account balances and smart contract state and updates them when newly valid transactions are confirmed. Blockchains update their ledger using a decentralized network of miners/validators, which validate new transactions in batches, called blocks, for financial rewards. The validation rules are hardcoded into the software clients run by miners/validators and cannot change without a majority of the network participating in a hard fork. 

Miners/validators work towards a common goal of transaction validation involving binary (yes/no) confirmations where a few basic conditions must be satisfied: 1) private key signature matches the corresponding public key address, 2) user’s account balance is sufficient to cover the transaction payment and gas fee, and 3) the user’s nonce is next in the sequence. The only resources a miner/validator needs to participate are the current software client, high-enough performant hardware, and a copy of the current ledger—none of which require any special permissions to access.  

This general architecture showcases four key features of a blockchain: 

• Cryptographic Truth—validation of new transactions is based on verifying historical information in the ledger already deemed true and made public.
• The network is monolithic—all nodes work together as one towards a single source of global truth for all accounts and applications on the blockchain.
• Services are standardized—there is a standard set of computations available to users on the network, with all nodes performing the same service of validating transactions.
• Node requirements are universal—running a node involves the same resources for all jobs (e.g., computing power) with no external dependencies.

Oracles

The core purpose of oracles is to derive truth about the validity of off-chain data, events, or computation and then relay the results on-chain. Generating external truth about the real world is complex because it involves non-deterministic datasets that are not inherently verifiable using cryptography alone. Non-determinism is a process with an uncontrollable external variable, which in the case of oracles is relying on data that may change its value depending on what sources are queried and when they are queried. Such data cannot be validated by a blockchain network since the data’s validity does not depend on historical on-chain state.

Instead, generating truth from a non-deterministic environment involves creating a statistically high degree of confidence in the external state of something given a set budget, timeline, and list of resources. It’s why blockchains are separate from oracles, as disagreements about the external state of the real world can cause consensus failures of the blockchain, disrupting all dApps running on it even if most dApps have no association to the specific oracle report. Disagreements also necessitate extensive governance overhead, limiting potential oracle innovation and increasing costs.

There are many opinions about what users deem is true in the external world, as well as the confidence they assign to that truth and the method they use to verify it. For example, cryptocurrency prices or foreign exchange rates have a non-binary, range-bound sense of truth because financial markets are continuous (as compared to discrete values), leading to different notions of correct prices across exchanges, geographic locations, and calculation methodologies. 

The ability to generate truth can also be subject to someone’s available resources—a free data API may be less accurate and reliable than an authenticated data API people pay to access, while an aggregation of several authenticated APIs may be more reliable than just one. Resource availability also extends to whether users have access to information at all, such as private IoT networks limited to credentialed users and enterprise-backend systems with permissioned access. Additionally, considerations need to be made around how time and monetary value influence the reliability of external state verification, e.g., is verification needed in real-time or will days after origination suffice, and is the external data securing $10k USD in smart contract value or $10B USD? Different answers likely result in different oracle designs.

Because there is no single way to generate truth in non-deterministic environments, oracles are application-specific services for obtaining definitive truth—a predefined method of generating truth that all parties involved agree is authoritative for the purpose of settling their agreements. The true power of well-designed oracles is that they can generate definitive truth about external state in a tamper-proof and automated way and be customized according to users’ own trust assumptions, performance requirements, and budgets. Hence, why Chainlink supports a variety of oracle network customization techniques for obtaining definitive truth, including varying degrees of decentralization, choice of specific data sources and node operators, different levels of cryptoeconomic security, and various other adjustable security parameters.

Compared to blockchains, the architecture of a generalized oracle network like Chainlink differs in several ways: 

• Definitive truth—each smart contract application defines exactly how they will derive truth from the external world and what falls outside of those bounds.
• The network is heterogeneous—oracles perform specific jobs for applications but don’t operate as a unified monolithic network with cross-dependencies.
• Services are diverse—a limitless number of oracle services are possible for users, with nodes varying in the number and quality of jobs performed and revenue earned.
• Node requirements vary—each job has different requirements, which nodes compete for by differentiating themselves via distinct infrastructure, data access, reputation, etc.

Similarities in Blockchain and Oracle Designs

While there are various differences, both blockchain and oracles generate truth about the state of something and leverage many of the same security techniques. 

Open-source code

Secure blockchains and oracles are both written in open-source code (often under a permissive license like MIT), providing transparency into the backend processes of nodes and fostering innovation, iteration, and correctness of their networks.

Decentralized networks

Decentralized oracle networks (DONs) incorporate the same concept as blockchains of redundant computation by a diverse group of entities to generate tamper-resistance, availability, and correctness of services.

Cryptographic signatures

Nodes in both blockchains and DONs use public/private cryptography to sign all transactions they broadcast in order to verify identity, prove ownership, establish non-repudiation, and create transparency.

Cryptoeconomic security

Both networks use financial incentives to cultivate honest majority consensus and disincentivize malicious activity of individual nodes and the network as a whole. Nodes are rewarded for honest work and punished for malicious activity directly or indirectly. 

Differences in Blockchains and Oracle Designs

Less understood are the differences between blockchains and oracles, which is key to realizing why the synergies become possible when combining the two in hybrid smart contracts.

Cryptographic vs. Definitive Truth

Blockchains are purposely isolated networks with an internal source of truth based on fully known, verifiable, and accessible variables. Since each transaction from the genesis block is cryptographically signed, there is a publicly auditable transaction history of every public address. Thus, every new transaction needing to be validated simply involves going through a public address’ transaction history to verify they have accumulated enough funds to cover the transaction. In this sense, truth is based on information with a cryptographically verified origin within the specific blockchain, referred to as cryptographic truth.

Oracles are tasked with creating truth from non-deterministic environments with unknown variables. Instead of putting the blockchain’s consensus at risk, oracles are used to create isolated sets of truth that an application defines as sufficient. Definitive truth is not designed to keep a global state for all applications, but to prove that oracles execute exactly as intended by their creators. Built upon the foundation of cryptographic truth, definitive truth uses the public/private key cryptography of blockchains to ensure non-repudiation and transparency of off-chain oracle computation. Definitive truth also relies on blockchains to establish reward and penalty systems based on the performance of oracle networks, creating deterministic outcomes. The end result is a highly configurable way to generate truth about the world with strong cryptographic assurances it will execute as intended.

Having a method of generating definitive truth about the outside world allows dApps to overcome the oracle problem because they can configure the oracle network to their own trust assumptions. While users may differ in what they consider a trustworthy oracle network—which will depend on variables like the use case, value at stake, and method of generation—many standard frameworks are already emerging. For example, Chainlink Price Feeds are DONs that have become an industry standard for definitive truth regarding price data, already widely trusted across the DeFi industry to secure high amounts of on-chain value. 

Monolithic vs. Heterogeneous Network Architecture

Because cryptographic and definitive truth have different roles, blockchains and generalized oracle networks have different underlying architectures. A blockchain manages a single source of internal truth that needs to be globally accessible, hence why it uses a monolithic network to maintain. All blockchain nodes in the network come together to perform one standardized set of jobs for one specific reward—create valid blocks on a roughly standardized time interval to earn the block reward and user fees. There is no parallel processing of different jobs; i.e., sharding is parallel processing of the same job types, not different. It’s this purposeful specialization that makes blockchains very secure and reliable in their specific computation of transaction validation, but it’s also the feature that makes them very feature-limited.

Oracles can receive an unbounded set of diverse requests for generating definitive truth about any real-world event, data point, or computation. Each oracle request has varying costs and rewards associated with servicing it, depending on the difficulty of verification and degree of certainty a user wants. Oracle requests can also span many different blockchains and may involve data and services behind private paywalls or legal barriers that only certain permissioned nodes can access. 

The diversification in job costs, quality, and requirements make it nearly impossible from a technical, legal, and financial standpoint for a single network of nodes to access all the external resources required to service all the oracle requests made on the network and maintain the unique security guarantees needed by all users. Not only would a single network eliminate the possibility of satisfying certain oracle jobs involving permissioned resources, but there would be a very low upper bound on the decentralization each job could obtain given the immense resources required to service all jobs. Thus, an oracle network following a monolithic design has to optimize for the lowest common denominator of nodes with the least flexibility and data access, significantly reducing what services and quality are available to users.

It is for this reason that Chainlink employs a heterogeneous network design, where an unlimited number of nodes and DONs can perform a diverse set of jobs in parallel without cross-dependencies. It’s the only way to service all oracle use cases, as different jobs are serviced simultaneously along their own timelines. Chainlink’s heterogeneous architecture opens up a variety of services for hybrid smart contracts like data delivery, data aggregation, data signing, off-chain computation, privacy generation, transaction automation, verifiable randomness, L2 validation, cross-chain communication, off-chain payments, and more. Even further, Chainlink oracles can be run directly by the original data/service provider or be outsourced to professional oracle node operators such as traditional enterprises, creating extensive flexibility for hybrid smart contract developers.

Standard vs. Varying Service Quality and Node Requirements

Variations in network architecture lead to distinctions in blockchains and oracle networks in terms of the quality of their services and the requirements of nodes running them. Blockchains offer a standardized service within a binary validation framework, resulting in little to no deviation in node quality (note: Proof-of-Stake blockchains tend towards very small differences in node uptime and usually have preset staked amounts). The standardization in job specifications also means each blockchain node can perform all jobs on the network with one hardware setup. Since there is little differentiation between node quality, blockchains predominately scale at a network level by simply adding more independent nodes to increase Sybil resistance and decentralization. 

Oracle networks differ in that they don’t offer a standard list of services, creating variance in the performance quality of individual oracle nodes and DONs as a whole. The variance in nodes means that a DON’s quality is not guaranteed to increase by simply adding more nodes or allowing anyone to run a node. Permissionless decentralization in DONs can actually dilute data quality and security, as well as lead to uncertain service guarantees for users and unstable revenue guarantees for node operators. Oracles attempting this model often have weaker data quality guarantees, limited selection of oracle services, large time delays between updates, and/or Sybil attack vulnerabilities—making them impractical for most oracle use cases.

Overcoming quality variance in oracle networks makes it necessary to establish reputation frameworks and marketplaces where users can evaluate the quality of individual nodes and DONs based on the metrics they deem important. Node operators can list themselves on marketplaces and stand out by providing information regarding their on-chain job history, data resource connections, oracle services supported, real-world identities, geographic location, and infrastructure setup details. Reputation systems can also help filter node quality by tracking nodes’ on-chain performance such as their average response latency, average response deviation, and jobs serviced, as well as track the performance of entire DONs. 

Reputation systems and marketplaces enable users to make informed decisions about how to create a user-defined Schelling point for their own definite truth. They can increase their security guarantees by paying for higher quality data sources, more reputable nodes, faster update frequency, more decentralization of node and data sources, more efficient aggregation methodologies, more distributed infrastructure setups, incorporation of trust-minimized hardware, optional circuit breakers, software client diversity, zero-knowledge proofs, and more. Their DONs don’t have to be static either, they can be scaled up or down at any time to increase their robustness or lower costs. DONs can also become more robust when shared and collectively funded amongst a set of independent paying users, where each additional user increases the security budget of the DON, lowering the cost of all existing and future users. This shared usage and funding model is already seen across Chainlink Price Feeds today.

Blockchain + Oracles = Advanced Hybrid Smart Contracts

The overlapping similarities of blockchains and oracles, combined with their different advantages, enable the full potential of hybrid smart contracts to be realized. Blockchains are valuable as isolated and standardized computation networks, having a limited attack surface and extreme levels of tamper-resistance, censorship-resistance, availability, immutability, and correctness. These features make blockchains great digital asset ledgers, immutable data storage networks, and final settlement layers. 

Alternatively, oracles are valuable as a highly flexible, scalable, and low-cost computation substrate for performing all the services that smart contracts cannot obtain on their underlying blockchain due to technical, financial, or privacy constraints. Oracle security can be scaled by layering on multiple security techniques and fine-tuning each one so the oracle service reaches a level of reliability in alignment with the user’s trust assumptions. 

Combining the two technologies opens up the holy grail of decentralized application development—hybrid smart contract infrastructure that combines trust-minimized asset custody and final settlement with high-throughput computation and supplementary add-ons like external connectivity, privacy, fair ordering, transaction automation, verifiable randomness, and more. Hybrid smart contracts are the foundations for the next leap in blockchain application development, one where truth can be extended to a wider range of external environments and customized to serve the needs of a broader range of users and use cases. Only through a world built upon truth instead of trust can society move toward more fair social and economic systems.

If you want to start building hybrid smart contract applications today and need some type of external data or computation, refer to our documentation, ask a technical question in Discord, or set up a call with one of our experts.