UNI should become an oracle token

Chainlink introduced a staking mechanism in their new whitepaper, in which nodes would have to put up a bond (stake) that could be automatically slashed for faulty oracle reports as outlined in an on-chain service agreement. It uses a two-tier system to achieve an efficient first-layer of security where the bribe needs to be larger than the combined bonds of all nodes. The larger, highly decentralized second tier would resolve disputes of the first tier should they arise. This would provide a lot of cryptoeconomic security while removing burdensome escalation periods that are only reserved for major large disputes, which could be user-defined in how they are resolved.

Have you considered a solution similar to Compound’s Open Price Feed? Compound | Docs - Open Price Feed (using signed APIs with smart contract verification to update on-chain price feeds/oracles)

I see no benefit of a fully decentralized Augur-like solution when there are multiple direct sources of off-chain price data available. Realistically all data in an Augur-like solution would be retrieved from the same CEX APIs anyways. Creating a consortium of CEXs (Coinbase/Binance/Huobi/Kraken/Bitfinex/++) to support signed API price data and incentivized medianizer/aggregator smart contracts that anyone can update for a reward may be a better use of resources. (for now)

I suggest those who haven’t go and skim through the Chainlink 2.0 whitepaper summary on their blog for the sake of better discourse on the pros/cons of each. Even better if you can read section 9 (staking) in the actual whitepaper.

This proposal and subsequent discussion feels largely unware of Chainlink’s current design plans, given most of what’s outlined here is very similar to their multi tier staking arbitration model but less performant and less capital efficient.

3 Likes

So what would this mean for UNI token holders? Would we have to pay for the oracles(gas fee via voting? or other fee) or would this system provide an added benefit to the UNI token. Im essentially asking whether this proposal proposes to make a subsidy from the UNI´s value or not.

2 Likes

This is a great idea and makes a tremendous amount of sense for next-level usage of UNI and Uniswap’s price mechanism.

Too many people here are reading this as an attack on Chainlink. However, Vitalik actually appears to be praising Chainlink while also suggesting that a more lightweight alternative may be useful in certain cases. He’s right.

What’s wrong with projects having a choice? There is no monopoly on oracle services and Uniswap can fill a gap that Vitalik has identified here.

Solid points have been raised and addressed so far. I haven’t seen any real deal-killers yet. I would definitely like to see this fleshed out some more, and I’d like to find a way to discuss it where conflicts of interest are filtered out as efficiently as possible.

The real problem here is that this proposal itself is yet another situation that UNI holders probably don’t have any meaningful power to resolve. It seems that this would realistically be up to the core team and could require quite a shift to its roadmap (unless this was already somehow in the works).

4 Likes

I just signed up to express my support for this idea.

I had thought by myself something similar because Chainlink does not provide sufficient decentralization and Uniswap cannot indeed provide true USD oracle prices.

Augur-style oracle would be great and I would be looking forward to use it.

1 Like

These two statements seem in opposition to each other:

If the main way to keep the system honest is coordinating hardforks that is a much more involved and energy consuming process for oracles than Chainlink’s token slashing and reputation systems. This is one monolothic oracle network vs the isolated and customizable oracle networks of Chainlink so also less minimalistic from an architecture standpoint as well.

Your design works with LINK token as well which has a bigger market cap and would therefore be more secure so why not propose using that token?

Chainlink and UNI holder here

I disagree with people saying the Chainlink staking mechanism already solves what Vitalik outlines in his proposal. The CL 2.0 staking mechanism is clearly an improvement over their current system and a step in the right direction, but ultimately depends on the Tier 2 robustness, which as of right now and with the little information we have about it does not seem to offer the same cryptoeconomic guarantees than the mechanism proposed by Vitalik here (no Augur style token voting for tier 2), to the benefit however of a greater flexibility that this mechanism could not offer. Like mentioned in the proposal, different use cases = flexibility vs laser-focused. This might change with future development about Chainlink Tier 2, though.

And to answer Kiba’s point, I would think UNI is better for token voting as a large amount of LINK tokens would already need to be staked in DONs, requiring tier 2 operators to unstake their tier 1 tokens each time there is a vote, which would probably be an issue if they have to vote often (possible if they act as tier 2 for several tier 1s).

My doubts are more about time/ressource allocation, possible voters apathy that could be higher than we might anticipate thus decreasing the perceived amount of cryptoeconomic security, questions related to the collateral needing to be provided by liquidators, and also Micah’s points raised above.

I don’t have a strong opinion for now but I’m interested in seeing these details ironed out.

4 Likes

My concern is that for price oracles that need to care exclusively about maximizing cost of attack, monolithicness is actually good. You want to use an oracle system where, in the case where an attacker buys up 51% of the oracle tokens and uses them to cause a single incorrect price to be reported, the oracle token blows up completely and goes to zero (the market value going into a fork that zeroes out the attacker). You don’t want an oracle system where if an attacker takes over a large share of the system (including the reputation layer, including…), they can just interfere with one result and there isn’t that strong social contract of tight coupling that even one incorrect result is unacceptable.

Chainlink has always seemed to me to have more of a “choose and pay for the level of security you want” ethos and relies on quick automated responses, which is really nice for a lot of applications but is somewhat opposed to what ultra-high-value defi oracles need. In addition to the security issue above, you want delayed and even human-mediated responses in case the centralized APIs of the markets are attacked. Though if Chainlink does change itself in a direction that supports maximum-cost-of-attack-demanding oracles, I would definitely be happy with that too!

4 Likes

The staking mechanism proposed in the Chainlink 2.0 whitepaper addresses exactly what you’re talking about and creates a mechanism that not only STRONGLY disincentivizes even one node to erroneously report but also if a SINGLE node answers incorrectly, the next node is responsible for making the decision of whether or not that answer is correct & if they say it is incorrect there is a resolution layer. This creates a situation where only one node needs to be honest, and while there is still a need for consensus it puts in check any incorrect answer so that this answer is not reported/accepted to/on the blockchain. Therefore every single node would need to be compromised, thus making an attack way more expensive than what you’d gain from that attack. Creating a “maximum-cost-of-attack” oracle as you put it here appears to be one of the main intentions (and one they’re most excited about) of their staking mechanism and upcoming infrastructure advancements.

For a quick version I would strongly recommend watching the “Chainlink 2.0 Whitepaper | Research Panel” and watching the “Understanding super-linear staking” section.

Whether the system actually winds up working as intended time is yet to tell but we know the team already has the majority of this work completed.

1 Like

Will this fix Eth Scalability? :thinking:

If not, why are you thinking about it? :face_with_raised_eyebrow:

Or is this a security measure for something bigger you may not be identifying directly?

1 Like

Agree with the concept and importance here.

A few points to consider:

#1 - What can we expect users to responsibly and rationally dispute on:

#1A - Irrationality in dispute outcomes:

Even in cases like Augur where they have binary non-ephemeral outcomes (like who won the election) we’ve seen users dispute the outcome for far longer and to far higher a cost to them than is rational.

#1B - Exactness in ephemeral disputes:

Since oracles are commonly used for liquidation points, and each user has different positions on different protocols where collateral value down to the cent could mean the difference between liquidation or not, it seems likely that any average ‘real world’ price of the USD/ETH rate averaged from multiple sources (and excluding of spurious outliers) would still likely be contested at times when it is economically of value to that user.

Let’s imagine a scenario where there are 10 price points being used, and 9 of them are $4000 - $4002 but one of them is at $3960, and the average price shows $3996.

A user in turn disputes the price, and argues the price of ETH was clearly $4000 and that the other source had failed to update, lacked volume, or simply wasn’t representative.

Is that user right?

By the letter of the law, no.

But, by the spirit of what the oracle is supposed to represent? Maybe.

Oracles of non-binary outcomes should not expect that the vast majority of users act in a rational, letter of the law, technical code as law kind of manner. It’s much more of a subjective jury trying to interpret “what is real and accurate as they understand it”

Given the points in #1 I think you likely don’t want users being able to dispute the specific price. Instead the minimal governance path is probably the election and removal of acceptable providers.

Or, we need to begin to rethink not only how we think of oracles, but also smart contracts, and take a lesson from finance where we aren’t just returning a single price and saying “this was the price in this moment” but giving an OCHL (open, close, high, low) bounds and letting defi contracts deal within a range.

#2 - How can disputes be secured and yet accessible?

#2A - Engagement vs Thresholds
We can say that the cost to attack a system of disputes that involves staking requires a >51% of the token supply but this can be done of two ways:

A) Hard voting threshold conditions.
B) Subjective voting threshold conditions.

In hard voting conditions we say that you must have >XX% token vote in favor of adoption of a change resolution for it to be enacted. This is commonly denounced in the token space right now because it sets thresholds that are too high and make it hard to enact governance change.

But, the flip side on the dispute case is >51% of votes in favor of the corrupt price for it to be corrupted, which is extremely secure.

The hard voting thresholds have some issues:

  • They assume that all tokens still exist, are accessible and in circulation.
  • They assume all tokens are held by individuals who are aware of their governance authority, obligation and have a willingness to participate.
  • They assume that current holding of the token means a wallet is the token owner and has the right to vote with it (cough cough - exchanges)
  • They assume that a token holder always wants the positive outcome for the ecosystem (cash and carry shorts, etc)
  • In the event a bad actor needs to be removed from the system it creates an extremely high bar to enact.

In subjective voting thresholds we say, the majority out come of all voters who vote (usually over some small quorum threshold) decide the outcome. Most projects set that governance threshold far too low so that most of the time their day to day governance can be managed by the fractional set of users who actually become engaged.

In such a governance model, you’d likely want subjective threshold voting, but on a fairly high (but still accessible) minimum quorum. This should act as a model to motivate small governance itself where in disputes aren’t for minor infractions or inaccuracies, but for clear malicious behavior and such the governance votes will only take place when it truly matters.

#2B - Incentive Models vs Demographics

Assuming that the desire is for a readable price feed, we would assume that elected producers are writing prices to the feed, paying a gas fee, and the read result is just returning the most recent price average.

As we’ve seen with Chainlink, this creates a set of sponsored feed providers who have some other broader ecosystem interest, such as exchanges and protocols.

This is not a bad thing per se, but it does create a poorly representative interests system.

If we ask ourselves “Could we imagine a scenario in which the price interest of exchanges (many of whom have futures) and defi protocols (who use collateral) could diverge from the interests of users (who have open those positions) by even just a few basis points?” the answer is yes.

It’s entirely feasible that the interests of millions of dollars could be divided by such a small amount of market movement that it would be in the interest of a few providers to under report the price within an acceptable variance bounds so that it is almost undetectable or undisputable, but still meets their needs.

The penalty models of stake and slash producing, and of paying recurring gas fees make being a provider inaccessible for communities or users (whom to be fair, may lack the technical expertise to maintain an oracle provider). But it does create a lopsided interest group managing the price feed.

#3 - Liveness of dispute vs Liveness of outcome and how it can still encourage corruption:

As a final footnote, perhaps more for defi protocols than for the oracle itself, it raises interesting debates about a liveness/finality of oracles.

In either example, where users can dispute on producers or price, we run into this interesting condition of deciding “If a bad actor influenced the price in a corrupt manner, should protocols a) ignore it, b) settle it based on the report live price that as corrupt, c) settle it based on the outcome price after the dispute”

The only manner I can consider in which C) is possible is if a protocol held liquidations delayed by two days, which would take on a signifgant amount of risk.

So then this creates a state in which a protocol must subjectively ignore an oracle and is thus no longer centralized, or it must act on a corrupted price which will later be corrected.

Imagine we have an oracle feed in which two producers open up massive shorts across collateralized assets. In turn, they both report the ETH/USD price as $1 in a block. The system doesn’t view it as outliers since there is more than one report (or whatever theoretical threshold) and inturn the Ethereum price massively under reports.

Being the most popular defi oracle service by a major provider, this sets off a cascading impact of liquidations and sells across the sector.

Users vote to contest the price and to remove the corrupt producers. They do so in a successful manner.

But, the corrupt actor still made off with their payday and users still suffered large losses.

Now this is an extreme theoretically and something that is probably a similar risk model with current day oracles, but if we are talking about designing a better governance minimized oracle, then it is worth considering how that is prevented.

2 Likes

Interesting timing for the xSNXa / xBNTa exploits which took advantage of Uniswap not having a sufficient oracle solution in place. Whatever happens ultimately I do hope UNI can find an oracle solution that makes sense so we don’t continue to see these kinds of attacks damage the reputation of the protocol. Utilizing Chainlink price feeds would be a very simple short term solution at least.

1 Like

You want to use an oracle system where, in the case where an attacker buys up 51% of the oracle tokens and uses them to cause a single incorrect price to be reported, the oracle token blows up completely and goes to zero (the market value going into a fork that zeroes out the attacker).

Would this be true of UNI? If UNI accrues value by taking fees off of each trade, would one expect a bad oracle response to be that detrimental to its value? I would assume that its value would still mostly be based on the amount of volume on Uniswap, which would be pretty unrelated to its price responses.

1 Like

I’m the co-founder of UMA. I think the ideas Vitalik presents here are very good.

Some context: UMA is based on Vitalik’s Schellingcoin idea from 2014. UMA implemented this idea because we think this is a critical piece of DeFi infrastructure, for many of the same reasons Vitalik already mentioned.

The UMA system has been in production for about a year now, and we’ve shown that this type of oracle design really does work in real life, for real world DeFi contracts.

A number of very smart folks (@g_dip, @Micah, adamscochran) have commented that the type of voting oracle Vitalik is suggesting doesn’t work well with current DeFi design patterns. The biggest concern is generally around how to liquidate contracts if you have to wait for a price to get verified. UMA has spend the last ~2 years figuring this out, but we haven’t done a good job communicating to the broader DeFi community how these “priceless” contract designs work.

What I would like to propose is that we (UMA) write a proposal for how a mature protocol like Maker or Compound could be written “optimistically” and be enforced with an UMA-like oracle system. This may be clarifying for this broader discussion, and help articulate the advantages of this approach.

13 Likes

Also @haydenadams I think it would be fun to do a “Should UNI fork UMA” panel moderated by V.

EDIT: To be clear, I think what UMA has built is quite unique and would be very difficult to fork. But I would love the opportunity to explain the virtues of the design with Hayden and V.

7 Likes

Looking forward to it!

2 Likes

Cool proposal, and I think it could get some traction/ some decent usage for the UNI token, but I think it fails for the same reason Augur sort of hasn’t taken off or Gnosis for that matter.
The way I envision it working from vitaliks post would be:

  • simple uniswap oracle (twap)
  • if someone thinks it’s corrupted, you can pay a fee to dispute the result
  • goes to a 1 day vote
  • if that vote is still wrong (or right), someone can pay more of a dispute fee to push it to the next vote (like a 2 day vote)
  • the next vote costs more to initiate and is longer…and so on and so on
    eventually you have everyone in the system “staking” which is the right value (which is why the cost to break is 51% of the mkt cap)

I run Tellor and we use roughly the same thing. I think you could make the argument (like Gnosis did)…why not just use a bigger mkt cap coin of ETH?
The reason is that you hope a community that votes and is active in what a “proper” value is will be a better oracle than just allowing ETH whales (exchanges) to control the vote.
Overall it never really comes down to these scenarios though. The real “oracle” problem is figuring out how to find the tradeoffs between speed, decentralization/liveness and slight manipulability (moving the price by 1%). The current Uniswap twap oracle really bangs on the first 2, but sort of falls sort on the last one. LINK rocks on 1/3 and others like Tellor find different mixes. Handling for the long tail of preventing 51% attacks of oracle coins is a job that should be done at the user level as there are a range of appetites depending on use case for waiting weeks vs liquidating or adding penalties.

1 Like

The cost of such an attack is thus half the market cap of the token , minus some amount to account for very lazy holders who are not willing to participate in a vote even in an extreme emergency that could cost them their coins.

Can anyone help me understand why the cost is half market cap but not the amount of token of corrupted holders?

@phuqle Just a basic assumption in all of this crypto stuff. You assume there are no angels. Obviously if 51% of the supply is held by outstanding, incorruptible citizens of the world, you’ll be fine. But for the sake of doing complex and impressive looking security analyses/game theory, we like to model that everyone is a nihilistic degen that can be bought out at market price.

2 Likes