Decentralized Oracles: Supercharging the Enterprise Rollup Adoption

Zeeve - Jan 25 - - Dev Community

Blockchain rollups are the most promising solutions available right now to scale Ethereum and other Layer1 blockchains. All kinds of rollups– be it based on finance use cases, gaming, digital identity, payment, or supply chain; need to interact with real-world data available off-chain. However, retrieving off-chain data is complicated due to its decentralized nature. They need a reliable channel to be able to get accurate and trustworthy real-world data with compromising security. That’s where decentralized oracles help. With blockchain oracles, rollups networks can efficiently retrieve data from external resources for the smooth working of their blockchain network

This article explains the need of decentralized Oracles for layer2 rollups, allowing everyone to understand how blockchain-based oracles are supercharging adoption of enterprise rollup while tackling all the data extraction challenges. Also, we will get a brief overview of decentralized oracles’ basics like meaning, their need, and working mechanism.

What are Decentralized Oracles?

Decentralized oracles are the blockchain-powered system that connects the blockchain ecosystem with various external data sources, allowing them to fetch off-chain or real-world data such as tamper-proof price feed data, external APIs, verifiable randomness, and a lot more. Decentralized oracles basically bring all such data on-chain for blockchain networks’ seamless operations. In this way, they help create one expansive blockchain network for all the blockchain ecosystems to relay data among themselves for their smooth operation. 

Also, decentralized oracles are better off when compared to centralized oracles because they extract data from multiple checkpoints to provide an average aggregated price range of the assets. Plus, it tackles the challenge like a single point of failure with blockchain’s distributed nature. Thereby, decentralized oracles decentralize the entire approach of off-chain data fetching, making the process reliable, safe, and effortless. 

Why Do We Need Them? 

Decentralized oracles are needed to prevent catastrophic events which might be triggered in the absence of better connection and exchange of  on-chain and off-chain data. To better explain this statement, we are referring to an incident which might have been averted had there been a decentralized oracle network. 

In November 2020, on the Compound Lending & Borrowing protocols, the users witnessed a major glitch that cost $96.4 million to users in a matter of just a few minutes. The incident happened in the following manner. The Compound Protocol was using the Coinbase Pro as a sole oracle network for extracting the price discrepancies across multiple protocols.

However, due to some glitch in the network, the Compound Protocol got a wrong price feed that DAI has appreciated by 30%. In the absence of multiple oracle networks to cross-check and verify the data, the protocol liquidated all the users whose collaterals fell below a specific threshold. Additionally, even DYDX suffered along with Compound, but their losses were small in comparison to Compound, standing at $8 million. From this example, it is evident that enterprises should consider using a decentralized  oracle network for your applications. And, therefore, decentralized oracles are getting huge traction in the web3 space. Decentralized oracles for layer2 rollups, high-traffic dApps, and enterprise solutions, and more… the use cases are numerous.

How Do They Work?

The oracles work by forming a bridge between three of its integral parts: (i) Users (ii) Oracle Contract (iii) Oracle Node 

The user will send a data request to answer some of their questions like; 

  • The source the off-chain node consults for requested information gathering 

  • The manner the data is extracted from various sources and assembled at a common checkpoint

  • The number of oracles nodes that can participate in the data gathering 

  • The manner in which the discrepancies in the information can be managed 

  • The methods used to filter the information and submit the consensus as a single value. 
  • It will be followed by the Oracle Contract; 

    The oracle contract will process the request as mentioned above and relay all that data to the oracle nodes and the output data will be broadcasted back to the client’s contract. Thereafter, all the data are computed and an aggregated value is derived to send the same to the request contract. It will be sending the data with the event log that mentions all the data requests. The off-chain nodes which are subscribed to this event log will retrieve the data through a JSON-RPC eth_subscribe command. 

    The Oracle Node will extract information from external sources like APIs on the third party servers and such information is fed on-chain for the smart-contracts to consume that information. These nodes will run the event logs and verify all the requests and pull the answers that match with the request from the Oracle Node. For example, if Alice has requested to open a contract with Bob, where if the price of BTC reaches $50,000, Alice will get 2 ETH deducted from Bob’s balance and vice versa. The oracle nodes will verify the price of the Bitcoin and relay that information to the Oracle Contract. The oracle contract will subsequently relay the information to the protocol smart-contract that will trigger the function if such events are met. In this way, the oracles bridge the off-chain and on-chain ecosystem as mentioned below in the given image. 

    Image description

    How Do Decentralized Oracles Supercharge the Rollup Environment?

    When thinking of building a scalable, enterprise-grade rollup ecosystem, you first have to understand that over-burdening the Base L1 chain might increasingly make operations complex. For context, even Vitalik Buterin, the founder of Ethereum has reiterated that subjectivity-exploitability trade-off is the need of the hour for scaling the rollup ecosystem. Why? Because, it provides the subjectivocratic security function that Oracle Governance provides. How? For context, as you know that L2 chains/rollup chains have a separate ledger. So, if you are planning to bridge the assets of the L1 chain with the L2 chain, the L2 chain will have to pass the validity proofs for token minting and burning on the L1 chain.

    However, there’s a possibility that a malicious actor can fork an L2 chain and create a parallel chain that duplicates the original chain to mint new assets or burn assets on the main chain. To avoid such a situation, decentralized oracles in layer2 rollups drive the possibility of Oracle Governance by offloading excessive computation from the main L1 chain. In this regard, the Oracle Network can be used for routing upgrades to the L2/rollup chain. 

    If a new chain is forked or created, it can import the state of the ledger from the Oracle Network Governance and create a new state of the roll-up that continues from the last state of the erstwhile rollup network. The decisions can be easily governed by enshrined oracles that will form a governance protocol with token bound governance and it could even help forking specific scenarios instead of the entire chains and taking necessary actions to resolve disputes. 

    These aspects are very much needed when you are running an enterprise grade rollups because there might be times when you need to resolve a particular event and not completely fork the chain. In this regard, the dependency on the Oracle Network Governance will be paramount in building the next generation of enterprise grade rollup solutions which are scalable, cost-efficient and secure for enterprise grade adoption. 

    Chainlink is a decentralized oracle network that allows smart-contracts to automate the transfer of data between blockchains. Chainlink uses a decentralized network of independent entities or oracles to collectively retrieve data from multiple checkpoints/ Chainlink Oracles Nodes, bundle them together, compute the same data and produce a validated single output to the smart-contract to execute a function. 

    Red Stone 

    Red Stone is another next-gen oracle solution that offers affordable storage, on-demand fetching , flexible data streams, data integrity and cross-chain oracle solution to help scale the decentralized ecosystem. It uses a smooth data relay function to empower the blockchain ecosystem which significantly lowers the cost because Redstone uses a meta-transaction pattern which verifies  data integrity through signature checking. Hence, smart-contracts can check the signature and execute the function. 

    Use Zeeve's RaaS to Launch Production-Grade Rollups in a Few Clicks

    Zeeve enables creation of L2 rollups at significantly low-cost and faster time-to-market with its vast network of integration partners and modular RaaS stack. Zeeve supports access to decentralized oracles for layer2 rollups as an easily pluggable component. Developers or businesses launching their Optimistic or ZK Rollups with Zeeve can integrate reliable oracles like RedStone and ChainLink oracle with their L2/L3 rollups or appchains

    Also, Zeeve has added supports for the leading Ethereum rollup framework, such as OP Stack, Arbitrum Orbit, Polygon CDK and zkStack. You can launch a rollup chain from scratch with Zeeve’s modular RaaS offering one-click deployment Sandbox along with a range of other important integration options such as DA layer from Avail, Eigen Layer, and Celestia, Biconomy and Halliday for Account Abstraction (AA), and Radius for Decentralized Sequencer, Subgraph for data indexers, etc. For more information on Zeeve’s rollup-based services and other  blockchain solutions, talk to our experts. Schedule one-to-one call or drop your queries via email on this page.

    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .