Umbrella Network Architecture

Understanding the architecture behind the Umbrella Network

Umbrella Network is a Layer-2, community-owned, decentralized oracle solution. Umbrella leverages Merkle trees to anchor data to Layer-1 Network to ensure that the data points Umbrella provides are cryptographically verifiable and the oracle itself is highly scalable. A key problem with the current oracle solutions is that their entire logic, storage, and transmission works on the Layer-1 itself. Theoretically, that sounds good but when every data point is processed as a different transaction, the costs quickly add up making practical usage infeasible.For example, the largest Layer-1 Networks - Bitcoin and Ethereum cannot handle more than 20 transactions per second. The transaction throughput is so small that it is impossible for oracles to be comprehensive on just Layer-1.

This is why Umbrella Network leverages a Layer-2 architecture to scale their decentralized oracles. This makes our decentralized oracles faster, more authentic, cryptographically verifiable, offer very comprehensive data points, at a cost that is a minute fraction of a Layer-1 transaction. Let's take a look at how Umbrella achieves all of these. Faster: Umbrella's Layer-2 network ensures that Umbrella Network can process transactions much faster than other oracles. More authentic: Umbrella has a consensus system where validators check for the authenticity of data and the rewards/slashing ensure that validators are checking the data to be correct.Cryptographically Verifiable: A cryptographic proof is appended to every data point so that it cannot be tampered with, even after it has been received by smart contracts.Affordable: Layer-2 network ensures that data is at-least 1/20th of the cost of Layer-1. Additionally, we process transactions in batches - which helps save even more costs.More Comprehensive: Being faster and inexpensive enables us to process more data points and also update them more frequently. This makes the data offered by Umbrella Network fresher and encompass the long-tail and mid-tail data points.


The Problem with Layer-1 Data FeedsThe problem with the current oracle system is that whenever data is requested, the oracle incurs a transaction fee and passes it to the dApp/smart contract.

(The nodes in the oracle work in the background and form a consensus to write data. Oracles write each data request to on-chain and incur a fee.)


The current Oracle System

The fees quickly go out of control with each request and the on-chain data becomes very costly for developers to use.## The SolutionThe Umbrella solution uses a sidechain that has decentralized nodes, which pull the data from off-chain sources and arrive at consensus via an on-chain smart contract. The reason it is better is that sidechain operations are very affordable and scalable.

  • A sidechain composed of decentralized nodes
  • The nodes pull data from various APIs
  • Nodes arrive at consensus via on-chain smart contract
  • Designated leader node stores Layer-2 data on the Merkel Tree and First-Class data on chain

Merkle Tree ArchitectureMerkle trees allow decentralized applications to scale without sacrificing security or data integrity.Each leaf on the Merkle Tree represents a data point from an oracle.The leaves are rolled from the lowest leaf up to the Root Hash.The final Root Hash is a unique representation of the entire Merkle Tree.


Merkle Root Hash

Validator Registry

Validator Registry is a Smart Contract to manage sidechain's validators.


Validator Registry

Contract owner manages validators:

  • Creating
  • RemovingEach validator has a set of properties
  • Name
  • Ethereum public address
  • HTTP(S) location of node## The Staking Bank Validators deposit tokens into the staking bank
  • During consensus, the weight of their vote is determined by the amount of tokens they have staked
  • Delegators can choose a validator who will cast votes on their behalf## The chainThe chain contract is where sidechain blocks are mined and stored- Every sidechain block is allowed to be mined after "N" seconds (we call this padding)- For each sidechain block a leader is computed from all available validators- A Sidechain Block ID is just a numeric value that is incremented by 1

ConsensusWhen it’s the leader’s turn to mine a sidechain block they must first gather enough “power” from other validators.First, the validator retrieves results from HTTP(S) requests and builds a block.Then the validator presents the blocks to other validators. The validators double-check the block by independently executing the HTTP(S) requests and verifying the leader’s results. Results are acceptable within an error rate. A validator then signs the block if it’s acceptable and correct.Majority validator stake must sign off on the block and then it’s accepted by chain contract.