I’m definitely quite opposed!
First of all this is a fundamental change to the technical properties of what a blockchain is trying to do. Right now, we have the property that the correctness of a blockchain’s progress can be verified fully programmatically. Validity is a deterministic function, and availability (ie. non-censorship) can be verified by online nodes, and there are even techniques for online nodes with low latency to reach consensus on whether or not a blockchain is censoring transactions. This proposal, on the other hand, aims to introduce a property of the chain that cannot be programmatically verified under any assumption even in principle. There’s even possible future worlds where there’s no obvious consensus on what correct value to put in (eg. one of the above countries has a civil war and both sides claim to be maintaining the “real” USD/CNY/JPY).
Second, it relies on honest majority, but so much of what we are trying to do with eth2 is fundamentally about moving away from the honest majority assumption and trying to create “second lines of defense” in case honest majority fails. For instance:
- Proof of custody, trying to change the security assumption on aggregation from “must be honest” to also covering not-evil-but-lazy actors.
- Data availability proofs and fraud proofs, allowing for 51% attack chains that push invalid or unavailable blocks to be rejected
- The fact that users can run full nodes and not just light nodes generally
- The censorship detection technique linked above
- The inactivity leak mechanism and its use for recovering from >1/3 offline attacks
Making a critical functionality that depends on honest majority goes in the opposite direction of all of these advancements.
Third, it compromises protocol neutrality and opens a slippery slope toward further compromises of neutrality. This proposal (1) elevates “defi” as a privileged application class, and (ii) elevates a particular set of assets / price indices. Demand for more assets will inevitably appear, and eventually demand for oracles for things other than prices. It also opens base-layer governance to political risk; base-layer governance will have to judge (i) which currencies are “sufficiently important”, (ii) which application classes are sufficiently important, (iii) how to adjudicate emergencies…
Fourth, it closes the door to innovation in oracle designs, eg. one natural alternative to this design is that the price at time T should only be agreed upon at time T + 1 day, to give room for on-chain attacks, situations where exchanges stop working for an extended duration, and situations where ordinarily functional APIs give unexpectedly wrong answers… there’s a lot of ways to design an oracle, and it doesn’t seem right for L1 to dominate the ecosystem with one approach.
Fifth, it increases the risk of staking validator centralization, as clients will require more automatic updates to maintain their oracles, increasing the risk that validators will just blindly follow instructions from client developers (or that people will give up outright and switch to pools).
Sixth, it doesn’t actually offer much more security compared to application-layer token-based oracles (eg. Augur and the like). The MKR market cap is ~2 million ETH, so application-layer tokens can clearly get significant market caps. We expect initial staking ETH to also… be in the ~2 million range (maybe ~10 million longer term). So it’s definitely not the case that base-layer oracles are in a fundamentally much higher security class than application-layer oracles that become sufficiently popular; seems more like a single order of magnitude difference at best.
I actually think that we should be moving in the opposite direction, explicitly limiting and circumscribing the function of the base layer, so as to deliberately leave space for the application-layer ecosystem to come up with these other tools. Augur has been functioning well as an oracle, and other designs (UMA, MKR, Chainlink…) exist.
The Ethereum ecosystem benefits from having a strong application-layer token ecosystem, as opposed to a L1/ETH monopoly on all important functions. This is because the Ethereum ecosystem has a large need for public goods, and there is a limited supply of ETH ready to provide those public goods (the ~590k ETH in the EF plus some whales), and it is politically difficult (for good reasons) to modify the Ethereum protocol to print more ETH for these purposes. However, application-layer tokens can provide these public goods; eg. Gnosis has done a lot in smart contract wallets and now maintaining openethereum already, etc etc. Application-layer tokens can even directly bake in quadratic funding to fund public goods. So we should be deliberately seeking and engineering for symbiosis with such application-layer tokens, not seeing them as just an experimentation ground where the base layer sucks up anything truly important that they develop.