Umbrella Network Architecture

Introduction

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 Feeds

The 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 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 the Merkle Tree Root hash on chain.

Merkle Tree Architecture

Merkle 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.

Validator Registry

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

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

Consensus

When 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.