Vitalik: Absolutely oppose the base layer price oracle machine, the functions of the Ethereum L1 layer should be clearly limited

Editor's Note: This article comes fromBabbitt Information (ID: bitcoin8btc)Editor's Note: This article comes from

Babbitt Information (ID: bitcoin8btc)

, Author: Justin Drake & Vitalik Buterin, Compiler: Free and Easy, Published with Authorization.

Written in the front: After watching the Bitcoin halving drama, let’s pay attention to Ethereum. Yesterday, Ethereum co-founder Vitalik Buterin wrote an article expressing firm opposition to the latest base layer price oracle proposal proposed by Ethereum 2.0 researcher Justin Drake , and put forward six major objections. In addition, he also said that the Ethereum ecosystem benefits from a strong application layer token ecosystem, rather than monopolizing all important functions through the L1 layer. Who do you support in this battle between the core figures of Ethereum 2.0?

image description

Note: The following proposal was proposed by Justin Drake:

Briefly, we propose to add a simple price feed service to the beacon chain to track a small set of key assets. The service allows for the creation of fully decentralized oracles that generate a price for each tracked asset at each epoch boundary (i.e. 6.4 minutes).

Thanks to @albert, @benjaminion, @dankrad, @danrobinson, @DCinvestor, @djrtwo, Eric Conner, Evan Van Ness, @karl, @khovratovich, Mehdi Zerouali, @mkoeppelmann, @paulhauser, @protolambda, @Robert, @ryanseanadams, Feedback and discussion from @sassal, @scott_lew_is, @vbuterin.

secondary title

structure

1. Add price_data: PriceData field to BeaconBlockBody, where:

2. From an Ethereum 2.0 consensus point of view, price_data objects are handled like graffiti strings. That is, price_data can be arbitrary data whose value is ignored by beacon chain state transition functions and fork selection rules.

3. Honest beacon block proposers must populate PriceData with the best prices possible for each tracked asset, and these prices must:

4. Baseline - 1 ETH representing the tracked asset;

5. Snapshot - Snapshot at the most recent PRICES_PER_ASSET epoch boundary (increasing age order in the AssetPrices vector);

6. Rounding - use half-down rounding (for example, if 1 ETH is 22,732.66 yen, then set it to Price(22733));

overflow - if uint64 overflows, set to Price(2**64 - 1);

Underflow - when the price is negative, it is set to Price(0);

secondary title

Example: Honest Majority ETH-USD Oracle

We can build a majority honest ETH-USD oracle at each epoch cycle boundary.

1. Consider a smart contract that takes the median of all prices corresponding to a given epoch boundary (up to SLOTS_PER_epoch*prices_PER_ASSET=256 price points).

2. If more than half of the corresponding beacon blocks were produced by honest validators, the intermediate price is safe, i.e. not manipulated by dishonest validators.

3. Basic Features The following are the basic features of this price feed service:

4. Consensus minimalism - By treating price_data as equal to graffiti, the impact on the beacon chain state transition function and fork selection rules is minimized.

5. Subsidy delivery - each beacon block contains a dedicated PriceData object, bypassing application layer block space restrictions and gas markets;

6. Bandwidth Efficiency - For each tracked asset, 320 bytes of overhead per BeaconBlock, serialized as type_byte_length(uint64) * PRICES_PER_ASSET = 64 bytes. The bandwidth overhead of block propagation is small, especially if the network is compressed.

Usable by other chains - This service is available not only for Ethereum 1.0 and Ethereum 2.0, but also for other blockchains. It can also be used off-chain, such as estimating fiat-denominated gas costs through a fully decentralized wallet.

Initial Deployment - This price feed service is an optional Ethereum 2.0 infrastructure that can be deployed when it is ready. The DeFi ecosystem of Ethereum 1.0 will benefit from it, such as in phase 1.

1. secondary title

2. Price feed governance

3. Minimum Viable — The set of tracked assets should be kept to a minimum viable level, i.e. only assets that are critical to the long-term health and success of Ethereum will be included. 5 initial assets (USD, EUR, RMB, JPY, GBP) reflect three key principles: (1. Credible neutrality; 2. High liquidity; 3. Wide application)

Coarse Consensus - New assets (e.g. gold, oil, bitcoin) can be added to the tracking set through hard forks driven by coarse consensus.

Backward Compatibility - Assets added for backward compatibility cannot be removed from the tracking set to maintain backward compatibility.

1. secondary title

2. Verify operator behavior

3. Honest Runners - Honest Runners, by definition, run validating nodes that comply with the consensus rules and report correct price data.

Lazy Runner - A lazy runner (e.g. a busy amateur staker) whose laziest behavior is to run the default validator client setup. Therefore, lazy operators should run validators that report correct price data. (Computational latency does not need to be considered since the computational overhead in terms of loans, CPU time, RAM, disk, etc. is small.)

Rational Operators - Rational operators seek to maximize revenue and will consider price data manipulation to achieve maximum extractable value for verification (VEV, similar to the concept of extractable value for miners). However, since the PriceData object is public and cryptographically signed, dishonest validators can be identified by the community. Potential penalties include: (1. Loss of reputation; 2. Forfeited verification balance; 3. Orphaned)

1. secondary title

2. Validator Client Guidelines

3. Validating clients must be able to query external sources to derive prices at epoch boundaries. Here are the client implementation guidelines:

4. Differentiation — various price sources must be queried for robustness, both on-chain sources (e.g. Uniswap V2, MakerDAO, Chainlink, see oracles.club) as well as off-chain sources (e.g. Coinbase, CoinMarketCap);

5. Security - attack vectors generated when querying untrusted APIs must be handled carefully;

Be aware of external issues - sources of anomalies must be adequately handled (e.g. using sanity checks and weighted medians);

1. Customizability - client operators should be able to easily change the default price derivation logic and customize their price sources;

2. decorrelation - implementations should strive to maximize decorrelation of price derivation logic (e.g., across implementations, versions, slots);

3. dApp guide

Historical Accumulator - Each PriceData object can be validated against historical_roots in BeaconState. In order to improve gas efficiency, SHA256 Merkle verification data (witnesses) can be effectively compressed into a SNARK (optimized by plookup and other technologies);

Risk analysis - dApps must carefully assess the risk of price manipulation by non-honest validators and make informed security assumptions (e.g. validator honesty assumption);

Hybrid Oracles - dApps should consider combining important price feed services with other price sources. The price feed service is an infrastructure designed to increase choice and robustness of the Ethereum ecosystem;

Below is the battle opinion from Ethereum co-founder Vitalik buterin:

"I am absolutely against it!

1. First of all, this is a fundamental change to the technical characteristics of the blockchain. We now have the feature that the correctness of blockchain progress is fully verifiable programmatically. Validity is a deterministic function, availability (i.e. non-censorship) can be verified by online nodes, and there are even techniques for low-latency online nodes to reach consensus on whether the blockchain censors transactions.

2. On the other hand, the purpose of this proposal is to introduce a chain property that, even in principle, cannot be programmatically verified under any assumptions. Even in future worlds where there is no apparent consensus on the correct value of inputs (e.g. civil war in one of the aforementioned countries and both sides claiming their currency is the "real" USD/CNY/JPY).

3. Second, the proposal relies on an honest majority, but a lot of what we're doing on Ethereum 2.0 is fundamentally about getting rid of the honest majority assumption and trying to create a "second line of defense" should the honest majority fail. ",For example:

4. Proof of Escrow, which attempts to change the security assumption of aggregates from "must be honest" to cover both non-evil, but lazy participants;

5. Data availability proof and fraud proof (fraud proof), allowing 51% attack chain to reject invalid or unavailable blocks;

Users can run full nodes, not just light nodes;

Censorship detection techniques mentioned above;

No activity disclosure mechanism, and its recovery operation in the case of >1/3 offline attacks;

Making a design that relies on an honest majority goes in the opposite direction of all of these advances.

Third, it undermines the neutrality of the agreement and opens up a slide into the abyss for further neutrality compromises. The proposal (1) elevates "defi" to a privileged application class, and (ii) elevates a specific set of asset/price indices. It will also introduce political risks of underlying governance, such as having to judge which currencies are important enough, which application classes are important enough, how to judge emergencies, and so on.

Fourth, it closes the door to innovations in oracle design, e.g. a natural alternative to this design is that the price at time T should only be agreed at Provides room for situations where things stop working for an extended period of time, and often when functional APIs go wrong unexpectedly. There are many ways to design an oracle, and dominating the ecosystem with an L1 approach does not seem to be the right answer.

Fifth, it increases the risk of centralization of staking validators, as clients require more automatic updates to maintain their oracles, which increases the risk of validators blindly following client developer instructions (or people giving up entirely Be a verification node yourself, and switch to the verification pool);

”

Sixth, compared with application-layer token-based oracles (such as Augur, etc.), it does not actually provide more security. MKR has a market cap of around 2 million ETH, so application layer tokens can clearly gain significant market cap. We predict that the initial staking coins of Ethereum 2.0 will be in the range of 2 million ETH (the long-term value may reach 10 million ETH). Therefore, the security level of the base-layer oracle is not much higher than that of the application-layer oracle, and it seems that the difference is only an order of magnitude at best.