Opinion: ETH 2.0 is a form of Rollup

Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from

Ethereum enthusiasts (ID: ethfans)

, author: lightclient, translation & proofreading: Min Min & A Jian, reproduced by Odaily with authorization.

As we transition to a new scaling paradigm, it's good practice to look back at old ones that were abandoned.

This post aims to reassure the reader that a "rollup-centric" approach does not depart from sharding, and hopefully builds a more intuitive understanding of the entire (hypothetical) system.

first level title

• Definition of Optimistic Rollup

• For the purposes of this article, we first detail the simplest Optimistic Rollup (ORU) implementation.

• ORU needs to have the following characteristics:

• Submit all transaction data to the chain

• Assuming the state root is true

Some nodes are responsible for verifying the state transition of the ORU

Why sharding is not feasible

secondary title

Suppose there are 16384 validators on a blockchain and 64 shard chains, each shard chain is verified by a committee of 128 validators. The election of committee members is unpredictable: after each slot, all committees are disbanded, and 64 committees are randomly re-elected from all validators, so each validator does not know which committee other validators are on. Assuming that a block needs to be approved by 2/3 members of the committee (that is, not less than 86 members) before it can be added to the shard chain, this means that 1/3 of the malicious validators are included in all validators. In the case of , the probability of selecting a malicious committee by random means is:

Note that we can scale this parameter up or down by adjusting the size of the committee to achieve the desired level of security.

text

Due to the extremely low probability of electing a malicious committee and the negative incentive for not acting as a validator, the sharding system should inherit the security and liveness guarantees of its non-sharded coordinator. However, like most systems in the real world, achieving this is not trivial. Since committee members are selected in advance, malicious actors have the opportunity to bribe rational actors. More bribery would occur if it were trivial to create a mapping from validator public keys to IP addresses. Furthermore, in a permissionless system, verifiable voting is inherently unable to prevent bribery. In summary, the actual security of sharding is at least an order of magnitude lower than the theoretical one.

secondary title

Like Plasma, sharding also has data availability issues

Although sharding is less secure than the monolithic protocol, we can still ensure its security, i.e., use fraud proofs to undo invalid state transitions. However, if we do not introduce additional design for the simple sharding chain we imagined, then malicious verifiers can completely withhold the data and not release it, so that others do not have enough data to generate fraud proofs. Next, we will explain how to implement this attack.

1. Suppose there is a simple sharded blockchain B with two shard chains X and Y. Blockchain B runs a traditional Byzantine Fault Tolerant consensus algorithm in two committees to help run shards X and Y, Cx and Cy respectively. Each block on B contains two threshold signatures, that is, the witnesses of 2/3 members of the two committees Cx and Cy to the state root of the current block of the respective shard chains.

2. Assuming that each shard chain handles the same amount of data and transactions per second as a non-sharded system, the introduction of shard chains should provide about twice the throughput. In the optimistic case, it does.

3. Now, let's launch a data unavailability attack on B. Suppose a malicious entity can force 2/3 + 1 members in Cx to sign invalid state roots and not disclose the input data of the corresponding block. This invalid state root will then be included in the next block that will be added to B. At this time, there is no reasonable mechanism to return B to a valid state. We can give some mechanism examples:

4. The remaining 1/3 - 1 member in Cx can raise a data unavailable alert on B. Unfortunately, this is not an attributable error (Translator's Note: It is impossible to determine whether the attacker withheld the block, or some people have a bad network and did not receive it, or even bit others when they received it), Therefore B cannot determine which party is doing the evil. (If some members are recklessly punished) A malicious minority may use this to launch a zero-cost DDOS attack.

It's up to the entire community to spot the bug and step in proactively to roll B back to the latest valid state. This mode of handling is obviously bad.

Implementing a mass exit mechanism similar to Plasma, mass exiting from X to B will have associated negative effects.

As with Plasma, the real issue here is data availability.

first level title

Increase Data Availability Safely

I hope the above analysis can make you understand a truth: we should first focus on expanding the data availability of the base layer. Otherwise, the system will still suffer from data unavailability attacks.

The above mechanism mainly relaxes the requirement for participants in the network to download all data. Vitalik's proposal is to let participants in the network randomly select a small part of the data in the block to verify to ensure that the block proposer has disclosed the data. The risk is that a block proposer only needs to hide a small amount of data to mount a data unavailability attack. Therefore, participants must sample blocks multiple times to build sufficient confidence in the availability of blocks. In order to reduce the sampling times, Vitalik proposed to use two-dimensional Reed-Solomon coding to code the block data.

In this structure, the block is divided into N shares, and then encoded to generate M shares, as long as you have any N shares in M, you can rebuild the block. Assuming 2N=M, the block proposer needs to affect 1/2 of the block data in order to successfully launch the data unavailable attack. Coded Merkle Tree uses a similar structure, but uses O(b) decoding cost and O(1) hash commitment instead of O(b1.5) decoding cost and O() Hash Commitment (where b refers to the byte size of the block).

first level title

The shard design of ETH 2.0 obscures the fact that they are the ORU of the beacon chain. It becomes clear when the focus shifts from distributed processing to an ordered data availability layer.

1. As shown in the figure above, the validator set plays the following four roles:

2. Verify and execute the beacon chain

3. Sampling verification of data provided by shards

4. Form a shard committee

Submit fraud proofs on invalid state transitions

text

We have made two assumptions: i) data availability, and ii) the blockchain will fork from the most recent block with data availability. Then either people can construct fraud proofs, or the system blames the lack of data availability on the shard committee that signed the block, and rolls back the state transition.

secondary title

By definition, ETH 2.0 is an ORU

At this point, considering our previous definition of ORU, we should be able to prove that a shard is actually a rollup:

1. All transaction data are submitted to the chain

Fragment block data is concentrated on the data availability layer, which will be verified by the entire network with a certain probability.

2. The state root is committed to the chain

The shard committee provides attestation to the shard state root included in the beacon chain blocks.

3. The state root is assumed to be valid

Beacon chain assumes shard committee proofs are valid without additional verification

4. Some nodes are responsible for verifying the state transition of the ORU

The shard committee validates the state transitions of the shards.

The beacon chain supports shard state transition fraud proofs.

Deconstructing ETH 2.0

Now that we have explained the uncanny similarities between the ETH 2.0 and ORU systems, how can we use this information to better understand the design of the overall system? Let’s explore some of ETH 2.0’s design decisions through the lens of the ORU system:

secondary title

data throughput

One approach that can be taken here is to treat data availability checks as first-class citizens in the protocol. This allows for independent optimization of the data layer, and finer-grained control of the hardware requirements (participating in the protocol) at the execution layer.

For example, ETH 2.0 can provide 64 data centers and an ORU contract on the beacon chain instead of the shard chain. The ORU contract allows rollups to decide on the leader election mechanism, how many data centers they want to send data to, and whether they want to be bound to other rollups (for example, if a rollup rolls back, the rollup bound to it also rollback will occur). The more datacenters used, the higher the hardware requirements required to validate rollups.

Strictly speaking, the above system is a superset of the current sharding design. In addition to the 64 shards defined by the protocol, there will be other rollups with their own characteristics built on the secure data layer and independent of the protocol shards.

secondary title

In a simple ORU, the elected leader has the right to commit invalid state transitions. While this doesn't affect the security of the system, since invalid state transitions are reversible via fraud proofs, it does break the rollup process. Taken alone, this kind of damage is usually not cost-effective to the perpetrator. However, in ETH 2.0, cross-shard communication makes this problem particularly tricky. The shard in slot N expects itself to get the state of other shards in slot N-1. Assuming that shard Si commits an invalid state transition, there is no reasonable way to undo the state's negative impact on shard Sj (0≤j≤64; i≠j) other than unilaterally initiating a rollback.

To avoid catastrophic events, mechanisms must be in place to prevent such rollbacks. Two of the most obvious mechanisms are shard committees and custody bit checks. As mentioned in the section "Mathematically proving the security of sharding", even considering various attack vectors, the probability of bribing more than 2/3 of the members of the sharding committee is very low. Custodial bits ensure that honest validators cannot be tricked into signing invalid state transitions due to laziness.

If we consider that the purpose of these mechanisms is to prevent invalid state transitions, rather than to maintain system security, we can choose parameters that are both practical and achieve the same effect. For example, reducing the size of the shard committee to 64 people, the probability of randomly forming a malicious committee is still as low as 3.1×10-8. But from a network and signature aggregation point of view, this can greatly reduce the burden.

first level title

Rollup-centric Ethereum roadmap

This article was originally written during the Stanford Blockchain Conference 2020 (SBC20). That's when I started to fully appreciate the similarities between ETH 2.0 and ORU. After reading Vitalik's article, I decided to publish this article to express my support for Ethereum's future adoption of a rollup-centric expansion solution. However, as described in this article, the "rollup-centric" scaling scheme does not take us off course, but is a superset. The problems we encountered in sharding design are isomorphic to the problems we encountered in integrating cross-rollup communication. This means that much of the work already underway can continue without interruption.