Designing the most secure oracle for the Decentralized Finance
If you have been active in blockchain space for a while, you must have heard about oracles. If you haven’t…
What is an oracle?
Oracle is something that reports external data to a blockchain.
Blockchains are deterministic systems. This means that all of the data in the blockchain must be verifiable at any moment. Hence, they can’t rely on external data, which can change at any time.
This problem is solved by an entity called ‘Oracle’, which reports the external data to the blockchain. But how do we do this without requiring trust in oracles?
This problem is known as the Oracle problem. Oracle problem is a well-known problem amongst blockchain developers and researchers. While many projects have tried to solve the problem, they have substantial tradeoffs.
Is DeFi decentralized?
Decentralized Finance (aka DeFi) is proving to be the most significant use case for public blockchains. With over 800M USD worth of value locked and growing, things are looking exciting.
Seven of the top ten DeFi applications by Total Value Locked (TVL) rely on some form of external data. Oracles fulfill this need. Due to the lack of secure and fast decentralized oracles, these applications rely on centralized and semi-centralized oracles. This means that most of the top ‘Decentralized Finance’ apps aren’t entirely decentralized.
Existing oracle solutions
The oracle solutions available today can be categorized as:
- Fast but insecure
- Secure but slow
Fast but insecure
Most decentralized finance require data reported with low latency. Due to this, most DeFi applications today rely on centralized or semi-centralized oracles.
The centralized oracles possess counterparty risk and reduce the security of the whole system to a centralized one. Since centralized entities are easily corruptible, these oracles are not ‘game-theoretically secure.’
Semi-centralized and fast oracles trade game-theoretical security and decentralization for speed.
Most of the decentralized oracles available today fall in this category. These are not entirely ‘insecure’ but vulnerable to various game-theoretical attacks.
Secure but slow
Oracles in this category are game-theoretically robust. They use manual voting and dispute rounds to prevent manipulation by attackers. However, due to the manual voting and long dispute periods, these can take from a few days to a few weeks to resolve. This higher latency makes them unsuitable for many DeFi applications.
Why multiple dispute rounds are necessary
Most of the decentralized oracles use some form of SchellingCoin mechanism. In the SchellingCoin game, the agents report the data independently without the possibility of coordinating with each other. Due to a lack of coordination, agents try their best to report the ‘true’ data, because they believe that other agents will do the same.
However, a single round of SchellingCoin game is vulnerable to various attacks such as bribing, signaling, collusion, etc. If an attacker attacks the game, there is no mechanism to retaliate against the attack. A single misreported value can have devastating consequences for applications relying on the oracle.
To counter such attacks, we can introduce dispute rounds, where any result of the oracle can be disputed by locking in a ‘Dispute Bond’. If the dispute is successful, the disputer earns a reward.
However, the attacker can attack the dispute round itself, making multiple dispute rounds necessary.
Razor Network: Fast and Secure Oracle
Razor provides robust game-theoretical security without compromising speed.
Razor uses a modified version of the Schelling coin game. Validators lock their tokens as a ‘stake’. They are incentivized to stay online and report the ‘true’ data. Reporting incorrect data can lead to the slashing of their stake while behaving honestly can earn them rewards.
This mechanism is proven to be robust and secure against various forms of game-theoretical attacks such as bribing, collusion, signaling, invalid source, etc.
The first round in Razor is automated. In this round, the validators automatically report the data from a URL. Due to the mechanical nature, this round is quick. The incentives of the network and the possibility of dispute rounds deter the validators from any manipulation.
In case of an attack, the result can be disputed by anyone, triggering a manual dispute round. The attacker may also attack the dispute round, requiring repeated disputed rounds. The participating stake in every round is doubled, doubling the economic security.
The final dispute round can be a ‘fork’ round. This is the market resolution method of last resort. The protocol and the tokens of the protocol fork in two versions and market decides the ‘honest fork’. Since this round is immune to manipulations, it deters attackers from attacking all the previous rounds, since they know they are unlikely to be successful.
Due to this design, Razor is robust against various forms of game theoretical attacks and provides maximum decentralization and economic security. Thanks to the automated rounds, Razor can respond at speeds much faster than manual oracles, but with the same game-theoretical security.
Razor network is currently live on görli testnet.
Would you like to
- Follow us on Medium
- Join our Telegram
- Follow us on Twitter
- Read our Explainer and Whitepaper
- Explore the Network
- Visit our Website
- Try DeltaOne, Our synthetic assets platform
- Reach out — hello@razor.network
v
