Oracles Explored: Unpacking Oracle Scalability

The ethos of web3 embodies a philosophy rooted in decentralization and transparency. So why accept anything less when it comes to blockchain infrastructure? To have blockchain applications that are truly decentralized and transparent, users need enhanced insights into the data sources that power those applications. 

Where is the data coming from? 

Why should one trust those data sources?

Are there assurances regarding the sustained existence of these data sources? 

These pivotal inquiries pave the way for a truly robust blockchain ecosystem. Oracles, as one of blockchain’s primitive building blocks, are foundational in addressing and answering these questions.

The Oracle Problem

Blockchain networks operate around consensus. Blockchains comprise thousands of machines agreeing on a series of events. As such, all nodes on a blockchain must be able to reproduce all transactions. This means that transactions must be deterministic, ensuring all nodes have consistent outcomes. 

Nevertheless, the deterministic nature of blockchains presents a challenge when accessing offchain data.

Although all communication inside a blockchain network has strong guarantees around consistency, availability, and determinism, the real world and the wider internet do not. An API or a database can be updated, hacked, or deprecated. There is no assurance that they will work tomorrow, let alone forever. Therefore, having an entire blockchain network agree on the result of an unreliable outside communication is not a viable proposition. 

This is the nature of the Oracle problem. How can blockchains safely interact and access the offchain world?

Enter Oracles

Oracles are a piece of infrastructure that connects blockchains with offchain data points. You can think of them as blockchain middleware. They bridge the gap between the world outside of a blockchain and smart contracts. 

Oracle networks work by having a group of validators observe real-world data and then agree on a result to record on-chain, which will be considered the ‘truth’.  

Although this sounds somewhat simple, it is anything but. Oracle networks must contend with Sybil attacks, malfunctioning validators, and faulty data sources, all while providing perfect availability. It is a challenging task, and billions of dollars in on-chain transactions depend on the security of Oracle networks. 

Risks of existing solutions

To adequately secure DeFi, Oracles must overcome a significant challenge: scalability. Oracle reporting is a very gas-heavy endeavour as it requires constant updates. To put this in perspective, the gas usage of Oracle networks is similar to that of popular DEXs. 

Reducing this load is necessary to ensure the security and speed of these Oracle networks and their underlying blockchain ecosystems. 

To ensure accurate reporting, each validator must sign the data they provide so that each response can be traced back to its source. Storing all of these signatures on-chain is not gas-efficient and encourages unsafe cost-reduction practices such as reducing the size of validator sets or the frequency of responses. 

Tackling this challenge while ensuring the security and transparency of Oracle systems is a crucial problem to solve to keep the blockchain ecosystem moving forward. 

Chronicle’s Approach

Chronicle Protocol’s Oracle system, called Scribe, is a first of its kind. It uses an efficient Schnorr multi-signature aggregation mechanism. The signature aggregation scheme allows data compression, enabling multiple validators to produce a single Schnorr signature. This mechanism addresses the scalability issue of Oracles and helps save on gas fees by over 60% on L1 and over 68% on L2. 

Chronicle Scribe oracle rewrites the rules of blockchain data verification. At its core is a first-of-its-kind application of Schnorr Signature cryptography for Oracles, which decouples the relationship between validator count and gas costs.

While other oracles rely on the Elliptical Curve Digital Signature Algorithm (ECDSA), which creates a one-to-one relationship between validators and their signatures, Scribe utilizes a novel application of Schnorr signature cryptography. This allows to consolidation of signatures from a scalable set of validators into a single “super signature” that is then verified by ECDSA. The result? A near-constant gas cost for Oracle updates, regardless of how many validators are involved.

This approach addresses two key infrastructural challenges that have long plagued other oracles: decentralization and cost. By eliminating the linear relationship between the number of validators and operational costs, Chronicle delivers increased security, transparency, and resilience while keeping costs in check.

Chronicle also addresses the verifiability challenge. When using the Chronicle, users can see the origin of data, the reported values from each validator, and the sources the validators used to acquire the data. This feature enables end-to-end traceability and improves users’ understanding of data provenance. 

Additionally, Scribe enables users to verify the authenticity of each validator’s signature. This gives end-users complete confidence in the validity of the data provided.    

Closing Thoughts

Oracle networks are the critical infrastructure that bridges smart contracts on blockchains with the real world. They are the glue that allows DeFi to function on-chain. When developing dApps, it is crucial not only to consider the security and accuracy of Oracle networks but also how they will scale with your application and user base. Chronicle’s Scribe Oracle enables scalability without sacrificing security and transparency. To learn more about how you can integrate Scribe into your dApp, check out the documentation portal and join the community on Discord.