Ethereum's Important Expansion Plan: Optimistic Rollup Status Report (Part 1)

DAOSquare

特邀专栏作者

2020-02-29 18:50 (UTC+8)

This article is about 4419 words, reading the full article takes about 7 minutes

Optimistic Rollup is Considered the Most Promising Ethereum Scaling Solution

AI Summary

Expand

Optimistic Rollup is Considered the Most Promising Ethereum Scaling Solution

Author: Daniel Goldman (Daniel Goldman) freelance software engineer, technical consultant, author

Proofreading: Samuel

A Technical Overview of Ethereum's Emerging Optimistic Rollup Ecosystem

Optimistic Rollerball (Daniel Goldman original, 2020)

The following report was made byMolochDAOauthorized production,John AdlerProvide relevant opinions/review; but all opinions in this article represent my own. Furthermore, the program evaluation is only a snapshot of the status at the time of publication of this report (February 2020). Everything is changing, don't over promise.

The Haze Over the Ethereum Scaling Community--Optimsitc Rollup

here

Fuel Labs
ANON
Whitehat, Cellani, Lim ( hereby “WCL”)
Pinkiebell
Offchain Labs
Interstate Network
Optimism
IDEX
Celer

clickhereReview their differences. Finally, we will delve into some qualitative questions around how the above projects will play their role in the space.

Background & Theory

Despite the good name, open and permissionless blockchains have many problems: all full nodes in the network must be visible and verify every transaction processed by the system; ultra-inefficient (compared to centralized digital payment systems) is at the heart of the much-debated scaling challenge of cryptocurrencies.

Layer 2 protocols are one class of ways to alleviate this burden. Going from all nodes validating all transactions to local validation of only some subset of transactions by interested parties (e.g. those wishing to secure their own funds) so that (in some way, shape or form) ) to shift this burden. Importantly, they preserve the trustless security model of the base layer, while eliminating the need to rely onrun by the userResources other than software.

Data Availability: Resolved

In the early stages of Ethereum's Layer 2 development, developers planned to operate under the implicit assumption that the base layer's "offload of verification" was to completely isolate (certain) transaction data from the blockchain. (see Josh Stark's early 2018 articleMaking Sense of Ethereum’s Layer 2to understand the way of thinking at the time).

Cryptocurrency protocols have inherent economic properties that incentivize block producers to share blocks in a timely manner and widely (barring edge cases such as selfish miningselfish-mining edge cases); the blockchain base layer is sometimes referred to as the "Data Availability Engine". Ensuring the data is (fully) public ensures that it can be verified and invalid transactions are virtually impossible to pass.

Therefore, in a Layer 2 scenario, if the data were to be completely isolated off-chain, we would no longer be able to guarantee that we have this kind of data availability; because those who are concerned about the validity of the data may conceal the data. So we have to figure out how to somehow ensure that invalid state updates don't happen in this corner case. For Layer 2 systems, the data concealment problem is always the hardest and worst case; because the worst thing is to find the facts without information.

If our definition is loose enough, all solutions to this data concealment problem can be grouped into two broad categories: state channels and Plasma (channels and Plasma). If the two parties are in the same channel, the update of off-chain data will be truly effective after both parties agree. Therefore, if Alice chooses to keep Bob's data, Alice will be up to date; it does her no good to keep the data. In contrast, Plasma does not have this requirement of mutual agreement. This leads directly to the fact that in Plasma, invalid updates can happen if the user doesn't have any direct proof. Even in this case, Plasma can still guarantee that users hold the necessary off-chain data to prove and ensure the ownership of their assets during the interactive challenge period.

In terms of practical results, state channels have become the first Layer 2 construct. It's easy for people to understand, and state channels (probably) do solve some fundamental research challenges, and we do see state channels used in Bitcoin and Ethereum. State channels have some useful properties, such as instant transactions, which are very suitable for the needs of some specific applications. Although it is a more general expansion solution, it is still limited to some extent. Channels are inherently independent of each other, and trustless connections would be capital inefficient and/or constrained by available flow paths. (I was inBitcoin’s Lightning NetworkRelevant limitations and workaround strategies are published. )

herehereandhereThe publication analyzes the plausible progress of Plasma Cash and its variants and the challenges they present.

Plasma's problems have even led some to think it will disappear (declare its demise). Even if someone thinks it's premature (like me), there's no question that Plasma is more difficult and complex than anticipated, and the resulting spatial velocity is transmitted slower than initially hoped. With Plasma stalling, the Ethereum community yearns for something similar to non-custodial sidechains. At this point, in terms of research and implementation status, Optimistic Rollup emerges.

Data Availability: A Concession

We can find traces of the current Optimistic Rollup construction in various previous proposals, such asShadowchains, Coinwitness, bulk validation with ZK-SNARKS (nowcall it ZK-Rollup),as well aswait.wait.

As far as we know so far,John Adlerand Mikerah Quintyne-Collins (aka ""Bad Crypto Bitch”) refer to the protocol foundation as “merged consensusMerged Consensusblog postblog postA similar principle was described in , and framed in Optimistic Layer 2 Game Semantic Analysis, named Optimistic Rollup (for whatever reason), and finalized.

Optimitic Rollup takes the framework described in the previous paragraph and flips it; ORU does not intend to remain non-custodial in the face of data withholding, but instead takes a more direct approach of directly requiring transaction data to be published in On-chain, more specifically, requires that enough data be published on-chain so that anyone running an Ethereum node can reconstruct the state of the ORU. The advantage of scaling is that Layer 1 only needs to discover the data and Merkle tree it into a block root without doing anything; (ideally) the calculation is only performed at Layer 2. Therefore, transaction data is published on the chain as call data, and is not stored in the state; because state capacity growth and computational cost (possibly) are the core bottlenecks of Ethereum expansion, there is no small room for growth.

As with Plasma, the inability of the base layer to directly verify transactions means that there will be some invalid transactions. Under ORU, any party will witness the update of the invalid transaction, and then present the fraud proof to the base layer through the fraud proof, and the fraud proof will restore the fraudulent block and the subsequent block update. Once sufficient time has passed without submitting a fraud proof, blocks can be determined and aggregated, and withdrawals initiated from those blocks can be completed. To curb malicious damage to the community by intentionally publishing invalid blocks, block submitters post a bond that is slashed if the fraud proves valid. The precise manner in which this fraud prevention is handled is at the heart of any particular ORU structure.

Compared with Plasma, ORU has an unavoidable fundamental disadvantage, that is, its relatively low scalability. Assuming that the data on the chain is proportional to the data in the ORU block, the ORU construction will be limited by the maximum amount of data in the base layer. However, ORU also has many benefits in other aspects, including:

Easier/broader support for smart contracts
Easier support for arbitrary payment denominations
Permissionless block production
Simpler Game Exit Mechanism
relatively simple operation

As we expected, even the above factors need to be traded off in different ORU structures. (For more information on what is behind ORU, see John Adler's "The Why’s of Optimistic Rollup”。）

Projects Overview Project Overview

Link to spreadsheet

This report interviewed 9 projects using the ORU design pattern, one of which chose to remain pseudo-anonymous (hereafter referred to as "ANON") when publishing.

Only projects that are in scope for an Optimistic Rollup are considered, that is, they must all be "Optimistic", including some kind of assumption that "the assumption is valid unless or until a fraud proof is submitted" (i.e., notZK-rollup) and includes "Rollup", i.e., enough data is published on-chain that any observer can reconstruct the state and detect invalidity (i.e., not Plasma). Most of the projects discussed strictly conform to these parameters, with the only exception being IDEX 2.0, the details of which are discussed below. Various other projects working on Plasma or Plasma-adjacent builds are in the early stages of researching ORU, including Matic, LeapDAO, and Cryptoeconomics Lab.

Smart contract support and fraud proof interactivity

The core difference between ORU projects is the degree to which they support smart contract scripts, and the nature of the verification and fraud proofs they require. Among the 9 projects surveyed in this survey, 5 projects have realized the complete function of the Ethereum virtual machine in their Rollup, and the rollup side chain has Solidity smart contract support, and its support level is (roughly) the same as that of the Ethereum base layer. Smart contract support is comparable, while the rest of the projects tend to support more limited, restricted functionality.

Broadly speaking, beyond the smart contract functionality itself, supporting a full EVM ensures technical consistency between rollups and the main chain, promises easier integration with infrastructure tools, and eases the transition for developers who are used to Smart contracts compiled with Solidity on Layer1. Conversely, projects that favor more limited, restricted functionality have the following advantages: cheaper (more or less) fraud proofs, easier verification, straightforward optimizations for specific users, and general simplification.

Open topics for research/discussion