UMA is scaling to every EVM compatible chain
TLDR: UMA is scaling to Polygon and laying the groundwork to support multiple Ethereum Virtual Machine (EVM) compatible scaling solutions.
Over the past few weeks, the team has been hard at work putting together our scaling strategy, and we are taking the first step with Polygon.
This article explains how our Polygon integration works and gives an overview of our broader scaling strategy. The aim is to empower developers to enjoy the benefits of scaling solutions while retaining the continuing assurance that UMA’s DVM secures their contracts.
How are we scaling?
The UMA ecosystem comprises a dispute resolution layer — the Data Verification Mechanism (DVM), and the financial contracts it secures. UMA’s architecture has from conception been decoupled, meaning the dispute layer and the contract layer do not need to live on the same chain.
Having a decoupled architecture gives the advantage of being able to deploy to any EVM chain efficiently. Our scaling strategy allows the contract layer on Polygon or any EVM scaling solution to access the same DVM any contract native to Ethereum has access to.
With the DVM on Ethereum and the contract living on Polygon, the next step is establishing a communication channel or bridge. The bridge is responsible for establishing two-way communication between both chains, enabling price requests to be escalated to the DVM on mainnet from contracts on Polygon and price resolutions from the DVM to be pushed back to the contract.
Let’s run through an example of how UMA’s system will work with an example.
In the natural lifecycle of a contract events like price requests generally settle without dispute. In the undisputed case, the contract calls the native Optimistic Oracle and settles with no need to escalate to the DVM. The vast majority of events have settled without disputes throughout UMA’s history.
In the event that something gets disputed, the DVM is required to resolve the dispute. Let’s walk through an example of how a dispute is bridged to the DVM, and the resolution is sent back to the Polygon chain.
- A Polygon contract, such as a prediction market, needs a price to settle a payout. The contract expects to get this price from an optimistic oracle (“Polygon Oracle”).
- For some reason, a user disagrees with the price returned by the Polygon Oracle and disputes the price.
- The disputed price request is passed from the Polygon Oracle to a contract called the “Oracle Child Tunnel”, whose sole responsibility is to communicate with an “Oracle Root Tunnel” on the Ethereum network. The Child Tunnel relays the dispute to Ethereum mainnet to the Root Tunnel.
- The Oracle Root Tunnel has special permission to request a price from the DVM, where the familiar voting and resolution process occurs amongst UMA voting token holders.
- Once the DVM has resolved a price request, the outcome of the vote is pushed to Oracle Root Tunnel. It is important to note that the DVM is not aware of which chain the request came from, nor does it need to.
- Like before, the Oracle Root Tunnel relays the result from the DVM to the Child Tunnel on Polygon.
- Finally, the Oracle Child Tunnel then sends a message back to the Polygon Oracle
- The outcome of the dispute is resolved.
Building a bridge
Polygon deployed an arbitrary message system that we will be used to allow communication between the Root and Child Oracles.
The advantage of using this bridge over a bespoke solution is that financial contracts on Polygon only need to trust the consensus security of Polygon itself, secured by a validator set using proof-of-stake consensus, and the DVM on Ethereum. Crucially, there is no need to trust a centralized actor to relay information between chains.
A key characteristic of UMA being able to, in a trustless way, relay messages between chains is to have a bridge that does not rely on centralized control. UMA strongly prefers to use an arbitrary bridge that shares the same security properties as the sidechain itself. Trustless communication will be a critical part of our approach as we extend to more scaling solutions.
Where are we scaling to next?
The DVM is source agnostic of the scaling solution. Developers and financial engineers can trust UMA’s proven mechanism in securing contracts and, soon, pick a scaling solution that best suits their product’s use case.
We will follow the same process as with our Polygon deployment by enabling UMA’s contracts locally to other EVM compatible scaling solutions and construct a trustless bridge. The visual below showcases that UMA’s DVM can be a trusted arbitrator for any and all scaling solutions.
Developers interested in building outside of Polygon are encouraged to reach out to the UMA team about their preferences.
Polygon is only the first scaling solution on the list, and UMA will be extending support to the other solutions. Priority is placed on chains that show the most substantial developer interest for UMA.
If you would like more information on how to get started, please reach out to the UMA team on Discord, Twitter, or by emailing: hello@umaproject.org.
UMA is always seeking uniquely qualified candidates. Come join us on our journey to making financial markets universally fair and accessible.
Below are our current open roles with UMA:
Senior Software Engineer: An engineer to work on our entire Ethereum-based web 3 stack.
Smart Contract Engineer: An engineer who’s an expert in solidity and smart contracts.
Launch Engineer: An engineer who can take internal and external products from ideation to mainnet (supporting external engineering teams to interact with our contracts and technology).
