What is the Sharding (sharding) that Eth 2.0 will implement?

Editor's Note: This article comes fromBlockchain Camp (ID: blockchain_camp)Editor's Note: This article comes from

Blockchain Camp (ID: blockchain_camp)

Blockchain Camp (ID: blockchain_camp)

Ethereum is the underlying platform in all blockchains that has been in sync with the concept of sharding. To understand why the Ethereum developer community wants to implement sharding, it is important to understand what sharding is and why this solution is so attractive force.

According to statistics from ETH Gas Station, it takes about 1.78 minutes to add a transaction to the Ethereum blockchain, a new block is generated every 32 seconds, and an average of 15-20 transactions are processed per second. This ecosystem creates an environment that favors miners over users, who must increase their gas prices if they want their transactions to be processed first.

Since low throughput, high latency, and high prices limit the performance of the Ethereum network, Ethereum is currently not suitable for deploying services and applications that require strong scalability.

secondary title

Simply put, sharding is a partitioning method that can distribute computing tasks and storage workloads in a P2P network. After this processing method, each node is not responsible for processing the transaction load of the entire network, but only needs to maintain its partition (or Fragmentation) related information is fine.

To further explain sharding, we can look at the simplest example of sharding. Ethereum founder Vitalik Buterin called it "increased scalability by 1000 altcoins".

In this example, instead of running a single blockchain, we run multiple blockchains, and we refer to each blockchain as a shard, rather than as a blockchain. Conversely, each shard has its own validator network or node network, which can use the PoW algorithm to mine blocks, and can also mine blocks through staking or voting.

secondary title

Sharding Challenges

The first problem we face when trying to use sharding is that since each shard has its own set of nodes, each shard is less secure than a single chain like Ethereum.

So if Ethereum with x number of nodes decides to hard fork and split into a shard chain, and distribute the entire network over more than 10 shards, each shard will have 1% of the security of the original chain. This means that by controlling 5.1% (instead of 51%) of the nodes of the original chain, every shard can be corrupted.

The second question we had was: "How do we choose which nodes to validate which shard?" For a not-so-good actor, this only happens if 5.1% of the network's nodes are all validating in the same shard , controlling these nodes is a problem.

In fact, all sharding architectures randomly assign nodes to shards. Assigning nodes to shards requires non-shard-specific computation, and almost all of these designs use separate chains to handle maintaining the entire shard and node network. Known as the Beacon Chain in Ethereum, this chain is responsible for generating random numbers, assigning nodes to shards, capturing snapshots of individual shards, handling handshake stakes, and various other functions.

The beacon chain has some disadvantages. Because they are responsible for the record-keeping calculations mentioned earlier, the more shards the network uses, the more work the beacon chain needs to do, and the network without shards may experience low throughput and high latency. , so the scalability of sharded networks has its natural limitations.

However, sharded networks are multiplicative, so if network efficiency is improved such that nodes in the network process transactions four times faster, the beacon chain can handle four times the number of shards, increasing network speed by 16 times.

• secondary title

• How to split data into shards?

• Let's start by looking at the functions a node typically performs on a blockchain:

Process/Verify Transactions

• Relay these transactions and the blocks they mine to other nodes on the network

• store the history of all transactions

• As the network grows, nodes need to be able to keep up with the demands of the network and its evolving needs.

Increasing the number of transactions being processed requires each node to add more computing power.

The more transactions that are relayed, the greater the bandwidth that needs to be provided by the nodes.

To store all data on the blockchain requires nodes to gradually add more storage space.

Sharding storage but not transactions has been proposed before this post, and some projects have implemented sharding for transaction processing (rather than storage).

However, the most common type of sharding is called "State Sharding" and consists of nodes in each shard building its own blockchain containing all the nodes in the global network that affect only them. Partial transactions, which means that nodes only need to store the transaction history of their shards, process transactions that affect their shards, and relay those transactions in their shards.

Next, we cover cross-shard transactions, invalid transactions, and malicious behavior.

secondary title

Blockchain Sharding and Scaling

The basic type of sharding as described above is not a very efficient or practical approach to sharding, since they cannot communicate with each other, so they act like a single blockchain. Taking a simple payment as an example, if user A and user B are on the same shard, then the validators in the shard can process the transaction without any hindrance, but what happens when their accounts are on different shards Woolen cloth?

User A is on shard 1#, and user B is on shard 2#. Validators on individual shards will not be able to debit or credit a user's account because they do not have permissions to each other's shards.

However, there are solutions to this problem, so let's look at some of them in more detail:

secondary title

Back in early 2018, Vitalik Buterin had proposed merging blocks with this solution.https://ethresear.ch/）

Asynchronous cross-shard transactions

(see source:

secondary title

Asynchronous cross-shard transactions

This is an easier operation to complete and much simpler to coordinate, so it is preferred over synchronous transactions.

Similarly, we will use the example that user A on shard 1# wants to send money to user B on shard 2#. In this scenario, the shard responsible for crediting user B's account will only verify B's own part of the transaction after there is sufficient evidence to prove that the shard responsible for debiting user A's account has been completed.

However, this approach is not perfect, and there is a non-zero chance that a block from a shard will be discarded. When the probability is non-zero, no matter how small the probability is, it is still a weakness that cannot be ignored.

We can explain the reason in detail through the following figure:

When such a fork occurs, a shard must discard one chain and accept another. At this time, if chains A, B, etc. become accepted chains in 1# shard, and W', X', etc. become accepted chains in 2# shard, then the transaction will be successfully completed and everyone is happy.

If the 1# shard accepts A', B', etc., and the 2# shard accepts W, X, etc., then the entire transaction will fail, but this is also an acceptable result because the transaction can be resent.

But what happens if 1# fragment accepts chain A, B, etc., and 2# fragment accepts chain W, X, etc.? Part of the transaction (A, B, etc.) is completed, but another part (W, X, etc.) is discarded.

secondary title

Malicious nodes in a shard

Now that you have a better understanding of sharding and how it works, you may be satisfied, or you may have more questions, but there is at least one more thing to consider: malicious nodes.

1. Malicious nodes

This happens very often, when there is a possibility of a big trading day, no matter what the system is, someone will want to attack the system.

2. Approve invalid blocks

Malicious nodes may attack the network by creating blocks that attempt to change the network. Let's say user 1 has 10 coins and user 2 has 0 coins. When User 1 wants to send these 10 coins to User 2, a malicious node on the network may try to create a block, and in the end User 1 will lose all his coins, while User 2 will have 1000 coins.

In a non-sharded regular blockchain, this type of attack is impossible because every node validates every block, and if an invalid block is found, all nodes (whether they are miners or not) will reject the block.

For a classic blockchain, no matter how many blocks malicious nodes create, or how quickly they are created, the honest nodes of the network will always ignore these blocks and continue to build the honest blockchain.

If a malicious node wants to recharge a large number of tokens to its account by building an invalid block, it will cause a chain to split into two. In this case, the number of malicious nodes may even exceed the number of honest nodes. The shorter chain is the honest chain and the longer chain is the invalid chain.

In a regular non-sharded blockchain, each participant is responsible for validating all blocks they receive and confirming their status, so anyone with a vested interest in the blockchain will immediately recognize an invalid chain, and Ignore (in this case) shorter chains.

Sharded chains are slightly more complicated because participants cannot verify every transaction on every shard. So we have to figure out how to verify that there are no invalid blocks in the entire history of the shard.