Ethereum 2.0 will be accelerated, and the simplification of the splicing scheme will be freshly released.

At the Devcon 5 conference held in Osaka, Japan yesterday, the founder of ConsenSys revealed that Phase 1-2 of Ethereum 2.0 will be launched ahead of schedule and may be launched by the end of 2020, which is nearly two years ahead of schedule.

So what is this all about? Is the developer so powerful that the team can complete the task ahead of time?

Of course, this is not the reason. The real reason is that the implementation of the Ethereum 2.0 original sharding scheme is too difficult. In order to speed up the landing, the R&D team has simplified it.

To this end, Ethereum founder Vitalik has just released a hot proposal to reduce the number of shards and speed up cross-chip communication.

• The future of Bitcoin under the Great Depression
• Full-text translation + interpretation | New rules of the US Internal Revenue Service: income tax due to forked virtual currency
• Wu Jihan's latest share: 2-4 million users worldwide, cryptocurrency will soon be widely adopted

What are the specific contents of this new proposal?

The original text is here: https://notes.ethereum.org/@vbuterin/HkiULaluS

Too lazy to watch? Give you the core points:

1. There is no longer a concept of a persistent shard chain. Instead, each tile is a direct crosslink. The proponent issues a proposal, the cross-linking committee is responsible for approval, and then completes the task;
2. The number of fragments is reduced from the previous 1024 to 64, and the tile size is increased from (16 target value, 64 upper limit value) kB to (128 target value, 512 upper limit value) kB, and the total slice capacity is 1.3-2.7 MB. /s, depending on the slot time. If needed, the number of tiles and the size of the block can increase over time, say 10 frames later, eventually reaching 1024 slices, and 1 MB blocks.
3. The L1 and L2 layers are simplified in many ways: (i) fewer fragmentation logic required, and (ii) no layer-2 cross-slice acceleration, because "local" cross-sliced ​​communication occurs within 1 slot time (iii) does not require DEX to facilitate payment across fragmentation txfee (transaction fee), (iv) EE (execution environment) can be made simpler, (v) no need for serialization and hashing;
4. Main disadvantages: (i) beacon chain overhead will be large, (ii) fragmentation time will be longer, (iii) higher "bursty" bandwidth requirements, but "average" bandwidth requirements will be lower .

(Note: The following is a description of the specific program)

Preface / root cause

The current Ethereum 2.0 architecture is too complex, especially at the expense market level, which is caused by the layer-2 solution created for major failures in the eth2 base layer: although the block time within the slice is very low (3-6s), but the underlying communication time between shards is very high, which takes 1-16 epoch cycles, and if more than 1/3 of the certifiers are offline, this time will be even more. This makes the "optimistic" solution a necessary prerequisite: a sub-system subsystem "pretends" to know the state roots of other shards in advance, learning them through some medium-security mechanism (such as a light client), and passing Use these (possible, but not sure) state roots to process transactions to calculate your own state. After a while, a "defender" process traverses all the shards, checks which calculations use "correct" information about the status of other shards, and throws out all calculations that do not use these "correct" information.

And this process is problematic because, although it can effectively simulate ultra-high-speed communication time in many cases, the complicated situation is caused by the gap between "optimistic" ETH and "real" ETH. of. Specifically, we cannot reasonably expect the block proposer to "know" optimistic ETH, so if the user on slice A sends ETH to the user on slice B, then the user on slice B has the protocol layer ETH There is a time delay before (this is the only thing that can be used to send transaction fees). To get around this, you either need to decentralize the exchanges (they have their own complexity and inefficiencies) or they need to relay the market (which raises concerns about monopoly repeaters reviewing users).

In addition, the current cross-linking mechanism adds a lot of complexity. In fact, it requires a whole set of blockchain logic, including reward and punishment calculations, fork selection rules, etc., which need to be included in the slice chain and used as Phase. Part of 1 (stage 1).

This document presents a thorough alternative that eliminates all of these issues, allowing Ethereum 2.0 to be used faster and reducing risk (some compromises are documented in the documentation).

Program details

We reduced SHARD_COUNT (sharding count) from 1024 to 64 and increased the maximum number of shards per slot from 16 to 64. This means that the "optimal" workflow is now between each beacon chain block, and each previous slice will issue a crosslink (for clarity, let's cancel the word "crosslink"). Because we don't "link" to the slice chain, we use the word " shards " directly.

Note a key detail: there is now a path, and all slot-N+1 blocks of any slice can know all slot-N blocks of all slices. Therefore, we now have a class of single-slot cross-sliced ​​communication (via the Merkle receipt).

Status (approximate map)

New proposal

We changed the structure of the proof link: it no longer contains "crosslinks" (including "data roots" that represent many fragmented blocks in some complex serialization form), but only the data roots of a single block of content, its contents It is entirely up to the "proposer". The tiled block will also include the signature from the proposer. The proposer's calculation method is the same as before, and is based on the persistent-committee (standing committee) algorithm, which is to encourage the stability of the p2p network. If no proposal is available, members of the Cross-Link Committee may vote for an empty “zero proposal”.

In this state, we store a map latest_shard_blocks: shard -> (block, slot) as before, except that the storage period becomes epoch instead of the previous slot . In the "optimistic situation", we hope that this map can update each slot.

Define online_validators as a online_validators of active verifiers (one of the last eight epoch periods, at least one of which is included). If 2/3 of online_validators (calculated by total balance) agrees to the same new block for a given slice, the map will be updated.

If the current slot is n , but for a given slice i , latest_shard_blocks[i].slot < n-1 (that is, the slice has a skipped block in the previous slot cycle), we need the slice Proof of the data root of all slots in the range [latest_shard_blocks[i].slot + 1....min(latest_shard_blocks[i].slot + 8, n-1)] . The fragmentation block still needs to point to the "previous fragmentation block", and we still have to enforce consistency, so the protocol requires such multi-slot proof to be consistent. We hope that the committee will use the following "forking selection rules":

1. For each valid + available fragment block B (the ancestor block of the block must also be valid + available), calculate the total weight of the verifier of the most recent message supporting the B or B descendants, which we call B Score", the empty block can also have a score.
2. Select the tile with the highest score for latest_shard_blocks[i].slot + 1 ;

Select the slice block with the highest score for latest_shard_blocks[i].slot + k (k > 1);

Overview

The process of issuing the beacon block N and the beacon block N+1 is as follows:

1. Beacon block N is released;
2. For any given slice i, the proposer of slice i proposes a slice block. The execution of this block can see the beacon block N and the root of the old block (if needed, we can reduce the visibility to block N-1 and the old block, which allows the beacon block and the slice area Blocks are presented in parallel);
3. Proof by the certifier mapped to slice i, including comments on the slot N beacon block and the slot N slice block on slice i (in special cases, also including the old slice block on slice i) );
4. The beacon block N+1 is released, including the proof of all the fragments, and the state transition function of the block N+1 processes the certificates and updates the "latest state" of all the fragments;

Cost analysis

Note that there is no need for participants to actively download the tiled block data. Instead, the proposer only needs to upload up to 512 kB of data in less than 3 seconds when publishing the proposal (assuming there are 4 million validators) Each proposer uploads an average of 128,000 slot cycles.) Then the committee can download the highest 512 kB of data in less than 3 seconds to verify the proposal (each certifier will be required to be in each The epoch cycle performs this operation once).

Note that this is lower than the average load per current certifier (ie about 2MB per epoch period). However, the "bursty" load will be higher: it was up to 64KB in 3 seconds, and now it is up to 512KB in 3 seconds.

The beacon chain data loaded from the proof (from 4 million verifiers) is changed as follows: each fixed data of approximately 300 bytes, plus a bit field, ie 4 million bits per epoch period, or each slot 8192 byte. Therefore, the maximum load of the current scheme is 128 * 300 + 8192 = 46592, although the average load may be more like 32 * 300 + 8192 = 17792, even reduced by compression (providing that redundant information is included).

And in this proposal, we will see two loads:

The maximum load is 128 * 300 + 128 * 200 + 8192 = 72192, and the average load may be 80 * 300 + 10 * 200 + 8192 = 34192.

Also note that the overhead of the aggregate for each slot in each shard is 65536 * 300 / 64 = 307200 bytes. This provides a basis for the requirements of the system running the node, so making the block data much smaller than this is of little value.

Computationally, the only significant increase in overhead is more pairing (more specifically, more Miller loops), while the specific data is increased from up to 128 per block to a maximum of 192, and this A block processing time of approximately 200 ms will be added.

Fragment "basic operating system"

Each ExecEnvID -> (state_hash, balance) has a state that maps ExecEnvID -> (state_hash, balance) . A tile is divided into chunks , each of which specifies an execution environment (EE). The execution of the chunk takes as input the state root and the contents of the chunk (ie, a part of the fragmented block data), and outputs a list of [shard, EE_id, value, msg_hash] tuples, each of which can only be a maximum of There is an EE_id (we add two "virtual" shards: the transfer to shard -1 represents the certifier's deposit to the beacon chain, and the transfer to shard -2 pays the offer). We also subtract the sum of the value from the EE balance.

In the slice block header, we placed a "receipt root" with a mapping shard -> [[EE_id, value, msg_hash]...] (up to 8 elements per shard -> [[EE_id, value, msg_hash]...] ).

The fragmentation block on slice i needs to contain the Merkle branch of the fragmented j receipt of each other, which is located in the "receipt root" of the other fragments (any fragment i knows any fragment j) Receipt root). The accepted value is assigned to its EE (execution environment), and the EE implementation has access to msg_hash .

This allows ETH to be transmitted instantaneously between EEs between slices, with the overhead of each block being (32 * log(64) + 48) * 64 = 15360 bytes. msg_hash can be used to reduce the amount of authentication required to pass cross-sharding information, so in a highly active system, 15360 bytes are usually essential.

The main benefit: a simpler cost market

We can modify the Execution Environment (EE) in the following way: Each shard has a state that contains the state root and the balance of the execution environment (EE). The execution environment will be able to send receipts, thus sending the coins directly to the same execution environment on other shards. This will be done using a Merkle branch processing mechanism, where each slice EE state stores a nonce for other slices as a replay protection. The EE can also pay the block proposer directly.

In this way, in addition to providing sufficient functionality (allowing users to deposit coins on shards, using these coins to send transaction fees, and easily moving these coins within the shards), it also eliminates the need for the relay market. The urgent need also eliminates the burden on the execution environment (EE) to assume an optimistic implementation across the fragmentation state.

Optimization certificate

To improve efficiency, we have also made the following optimizations: As mentioned earlier, the proof of looking at slot n can be completely included in slot n+1. However, if such a proof is included in a later slot, it must be included in a "simplified form" that contains only the beacon block (head, target, source) without any crosslinks (crosslink) )data.

This approach not only reduces the data, but it is also important to preserve the same data by forcing the "old proof", which reduces the number of pairings required to verify the proof: in most cases, all from the same slot Old proofs can be verified by a single pairing. If the chain is not forked, in the worst case, the number of pairs required to verify the old proof is limited to twice the length of the epoch. If the chain does have a fork, then the ability to include all the proofs will depend on a higher percentage of the proposer (eg 1/32 instead of 1/64) being an honest condition and also requiring an earlier proof .

Keep support for light clients

Every day, we randomly select a committee of 256 verifiers who can sign each block and whose signature can be included in block n+1 for reward. This is done to make low-right light clients work as well.

Other possible extensions

1. The fragmented block of slot n shall query the beacon chain block of slot n-1 (instead of slot n). This will allow each slot to occur in parallel rather than in series, thereby reducing the slot time at the expense of increasing the cross-sliced ​​communication time from 1 slot time to 2 slot times;
2. If the block proposer wants to make the block larger than 64KB (note: the target is 128KB), then it first needs to generate 64KB of data, then let the cross-linking committee sign it, then they can add another part of the reference A signed 64 kB, and so on. This will encourage block producers to publish a partial completion version of their block every few seconds to create a pre-acknowledgment;
3. Speed ​​up the development of secret leader elections (for simplicity, even an anonymous collection of 8-16 based ring signature technology versions will help);

For this new sharding program, community members have also raised their own questions, such as Raymond Durk wrote:

"If you do this now, then the number of shards (Ethereum 2.0) will be expanded to 1024, will its implementation be complicated?"

In this regard, Vitalik's reply is "not complicated."

What is your opinion?

We will continue to update Blocking; if you have any questions or suggestions, please contact us!