Opinion: why oracles with economic guarantees are necessary components to create large-scale DeFi products

Author: Hart Lambur

Translation: A Jian

Source: Ethereum enthusiasts

Editor's Note: The original title was "Data Verification Mechanism for UMA"

• 0.1% – 0.9% – 99% of blockchain rules
• Featured Twitter | A detailed article on 2019: What progress have been made by Bitcoin and Ethereum?
• DeFi Week Selection 丨 Siege or Hug? A different DeFi road for tech giants

Abstract: We are developing a decentralized oracle to solve the huge pain point faced by most DeFi projects-a centralized, possibly manipulated oracle, when entering asset prices into smart contracts .

Three weeks ago (Editor's note: author wrote on August 6, 19), we introduced our Data Verification Mechanism, a blockchain oracle service, and we are around the corrupt oracle The cost of the system is designed for its economic guarantee .

This article will briefly describe this system and explain why we believe that oracles with economic guarantees are a necessary part of creating large-scale DeFi products.

The essence of the oracle problem is … all oracles have the potential to be corrupted!

We strongly advocate that all blockchain oracles can be corrupted. Therefore, all smart contracts that require the use of off-chain data can be bribed and manipulated, as long as the benefits are large enough . Therefore, the DeFi smart contract you use may also be at risk.

Our logic is: on an open, non-access blockchain (such as Ethereum), there are no rules and no laws to resist bribery and corruption; and because all oracle systems are essentially one or a group The data is composed of reporters, so there is always a certain price , which can buy all reporters in a system.

The analogy between DeFi and the real world is clear. Suppose Alice and Bob each paid $ 500,000 to conclude a legal contract in the real world and agreed to allocate the $ 1 million based on the output of a data source (the data source here is the "predictor" in the real world). Now, assuming Bob wants to cheat, he can bribe this data source and let the latter give him the entire $ 1 million (that is, cheat Alice for $ 500,000). As long as the bribe was less than $ 500,000, he was fully motivated to bribe.

Had it not been for Alice to take him to court and send him to jail, Bob would have been happily going to this data source to pay a bribe. That's why Bob is acting honestly.

-Because of the deterrence of imprisonment, the real world is not full of fraud. But there is no such powerful deterrent on the blockchain! –

Obviously, there is no such thing as imprisonment on the blockchain . Bribery cannot be said to be "illegal". Bob can bribe any oracle and any participant at will.

Because of the pseudo-anonymity of the blockchain, this becomes a big problem . Suppose Bob participates in 10 contracts, and each of them can make $ 500,000 by bribing these oracles that deliver the price of the contract, then he has an incentive of $ 5 million to bribe this oracle. What if there are 10,000 contracts and 100,000 contracts using this oracle? Bob can set up a round, use this single point of failure with relatively few bribes, and make a lot of money.

-On the blockchain, Bob with quasi-anonymity cover can join many contracts using the same oracle. So Bob was motivated to corrupt this oracle. –

The point is, as long as the scale of DeFi continues to expand, the incentive to attack oracles that provide prices for these DeFi contracts will also increase. Eventually, it will become a limitation on the scale of DeFi. Unless we can prove that attacking a oracle machine can't get oil and water, don't try to bring trillions of dollars of assets to the DeFi world.

This is the problem that the DVM oracle design wants to solve.

Defining "honest" oracles

 

To say that all oracles can be corrupted at a certain price means that there must be a bribe price for any oracle to corrupt the oracles and induce dishonesty. We define this minimum price of possible bribery as "Cost of Corruption (CoC)."

Then, there must be some maximum benefit that can be stolen through bribery. We call this maximum benefit "Profit from Corruption (PfC)."

Therefore, in order for an oracle to remain honest, the cost of corruption must always be higher than the benefit of bribery, that is, CoC> PfC .

This is what we mean by economic guarantee : If we can prove that CoC> PfC is established, we can prove that no one has financial incentives to corrupt the system, and Bob the liar should not want to benefit from it, no matter how much he buys quietly. contract.

Creating a predictor with economic guarantee

 

So how does this work?

In summary, there are three requirements for building a predictor system that requires economic guarantee:

1. Design a system that can measure the cost of corruption
2. Create a system that measures the benefits of bribery
3. Design a mechanism to guarantee CoC> PfC and prove it is feasible

For details, we have already written it in the DVM white paper, and it is highly recommended that you read it. To save time, here is a concise overview:

Step 1: In order to measure the cost of corruption, DVM uses a Schelling-Point type voting system, and uses the number of tokens to define the voting weight. Token holders vote on controversial prices. Honest votes are rewarded, otherwise they are punished. As long as most of the participants are honest, the vote will determine a correct result. This means that the cost of corruption is the market price of 51% of the voting tokens bought.

Step 2: In order to measure the benefits of bribery, all contracts using this system must register with the DVM and report how much money will be stolen if the price is manipulated (that is, the contract's PfC). DVM will aggregate the PfC of each contract to get a system-level PfC.

Step 3: Use dynamic fees to ensure CoC> PfC. This is also an interesting design for DVM.

Examples are as follows:

Assuming a system-level PfC of $ 100 million, it means that in the worst case, if the attacker Bob successfully corrupts the oracle, he can make a profit of $ 100 million. In order to corrupt this system, Bob needs to buy or control 51% of the voting tokens, so the CoC of the system is the money spent to buy 51% of the tokens.

To ensure CoC> PfC, it is necessary to ensure that 51% of the voting tokens are worth more than $ 100 million. In other words, we want to ensure that the market value of voting tokens is higher than $ 200 million. If the market cap falls below this value, Bob can benefit from the attack.

DVM's measures to ensure this are: continuously monitor the size relationship between CoC and PfC, and start a programmatic, repeated token repurchase once the token price is below the target value. All repurchased tokens will be destroyed, reducing the supply of tokens (increasing the market value of tokens). The funds used to implement the repurchase are raised from the contracts using the system, and they are charged a proportional commission.

It is important that the DVM system is also designed to reduce the handling fee as much as possible under the constraint of CoC> PfC. As a result, the system does not seek rent —its handling fee is designed to the minimum required to maintain system security. The wonderful result of this design is that when market participants expect DVM usage to increase, this growth expectation will enable DVM to guarantee CoC> PfC without having to charge any fees at all .

A full analysis of the design is in the white paper.

Next step

 

We will soon release a contract writing framework that will tell you about best practices for writing financial contracts using DVM. These contract templates will enable developers to create bilateral swaps of arbitrary assets , decentralized derivatives exchanges (think decentralized BitMEX), and almost everything else you can imagine Financial product.

(Finish)

We will continue to update Blocking; if you have any questions or suggestions, please contact us!