This article is from:CSDNThis article is from:liuchengxu,translate:
Original link:
Original link:https://medium.com/@icebearhww/ethereum-sharding-and-finality-65248951f649
existEthereum Casper 101exist
Blockchain scalability issuessharding doc .
Blockchain scalability issues
Blockchain scalability issues
Growing transactions.
The current block generation process results in limited scalability. The gas limit of the block constrains the computing capacity of the block. Either increasing the block gas limit or drastically reducing the block time will result in a high stale rate and weaken the network's ability to resist attacks.
the termEIP 648 — Easy parallelizability
the term
First, let's take a look at the difference between objects at different levels on the main chain (you can understand it as the current Mainnet chain) and the shard chain:
image description
It can be simply thought that transactions will be loaded into "collation". Similar to a block, a collation also points to its parent collation on the chain (referring to the shard chain). Becoming a "collator" means that you are eligible to nominate a new collation on the POS shard chain.
image description
Basic secondary sharding
The consensus of the shard chain depends on the main chain
The consensus of the shard chain depends on the main chain
Similar to sidechains, collations only have a small set of proofs that must be recorded on the mainchain - this is the basic idea of how we scale blockchains:
Transactions on the shard chain are in their own independent space, and shard validators only need to verify the shards they care about.
Validator Manager Contract (VMC)
Validator Manager Contract (VMC)
In order to add a shard chain to the main chain, a special contract called the Validator Manager Contract (VMC) is required on the main chain. VMC is the core of this sharding mechanism. The purpose of the VMC can be summarized as follows:
Proof of Stake system. If validators misbehave, their stake will be exploited.
Pseudo-random sampling. Eligible collators are sampled by using the current block hash as a seed. Basically, validators deposit their stake into VMC, and then their verification code address (validation code address) will be recorded in a global validators pool list inside VMC (a global validators pool list). The system will sample a shard chain certifier from the certifier list, and designate it as the certifier of the specified shard within the specified "period (period, what is period will be explained below)". This approach makes it impossible for validators to predict in advance when they will become validators or which shard they will become validators for.
Collation header validation. VMC has an addHeader(bytes collationHeader) function that validates the collation header with = and records the valid collation header hash. This function provides instant on-chain verification.
Cross-shard communication. Utilizing the UTXO model, and by making a transaction on the main chain and creating a receipt (with a receipt ID), users can deposit ether into a designated shard. Users on the shard chain can create a receipt-consuming transaction with a given receipt ID to spend the receipt.
How to nominate Collation within a shard?
How to nominate Collation within a shard?
A "period" is defined as a bounding a window of block times, e.g. PERIOD_LENGTH = 5 means 5 blocks per period. This means that there is no more than 1 valid collation per shard per epoch.
image description
Once validators are sampled as eligible collators to propose a new collation, the collator must verify the most recent collation and send a transaction to call the addHeader function. Note that if the collator cycle 10 is sampled to submit a new collation, this means that the addHeader transaction must be included in cycle 10, that is, the transaction must be between block number 10 * PERIOD_LENGTH to block number (10 + 1) * Between PERIOD_LENGTH - 1.
image description
-Picture 2(b). For a slice, a period has only one collation; a block can contain multiple addHeader transactions of different slices-
Fork choice rule for shard chains
Fork choice rule for shard chains
In the example in Figure 3(a), there are two forks on the main chain, and the second chain in the figure below is the longest valid main chain. Because block B3 is the head block, it is easy to see that collation C3 is the head collation.
image description
Then block B3' in Figure 3(b) arrives. Assuming that block B3 has a higher score than block B3', then the above chain is still the longest main chain:
image description
Finally, Figure 3(c) reaches block 4. Note that for this shard, although collation C3 has a higher score than collation C2, the lower chain is the longest effective main chain, so now collation C2 is the head collation:
image description
More on: Another Design - Vlad Zamfir'ssharded fork choice rule
image description
- An elegant design that guarantees that blockchains can be atomized before they are finalized -
The trade-off between scalability and security
— Blockchain Trilemma in Sharding FAQ
For the three attributes of decentralization, scalability and security, the blockchain system can only choose two of the three at most.3Due to the guarantee of system security, the scalability is limited
. While distributing transactions to shards in order to improve TPS (transactions per second), we also reduce the computing resources for each transaction.
One of the important mechanisms of sharding is how to generate random numbers on the chain.
The probability of the collator being selected should only be related to and proportional to the validator's deposit.
If validators can predict, or arbitrarily choose which shards they want to participate in, then dishonest validators can either collude with each other and launch an adaptive attack.control sharding.
-Picture 4. Traditional majority attack (51% attack)-
image description
-Picture 5. 1% attack on a shard-
Implicit finality vs explicit finality
Implicit finality vs explicit finality
First of all, I must declare that the sharding mechanism should be able to be applied to both POW and POS chains. Even so, the little thing of explicit finality, like Casper, can make sharding more robust.In a general POW chain, finality is probabilistic,implicitCasper the Friendly Finality Gadget (“FFG”). In simple terms, even if a block has thousands of confirmations, it is still possible to rewrite the chain. Instead, put
The encryption economic mechanism is applied to POS, explicitly in the protocol (in-protocol) to enforce the guarantee whether it is finalized for us (we-can-check-if-its-finalized-for-us).
The finality of the main chain depends on
The finality of the main chain depends on
In basic sharding, the shard chain is anchored to the main chain.
For shard validators, we want shards to expand the blockchain capacity by 100 times in phase 1, so all validators of these 100 shards will need to monitor the VMC status to obtain correct and effective head collation. It is important for validators to be convinced as soon as possible whether they are a collator. For ordinary users, if we apply cross-shard transactions in phase 2, ordinary users will also need to retrieve their deposit information (receipt ID) on VMC.
Explicit finality helps stateless clients
Explicit finality helps stateless clientsThe basic principle of a stateless client is that it does not store the entire state tree, instead, a stateless client only stores the state tree root. Archival clients store the entire state tree and provide the Merkle branches needed for a given collation. With these Merkle branches, stateless clients can build parts of the state tree and 。
Synchronization is triggered as soon as validators are sampled and reshuffled. With the stateless client mechanism, the cost of reshuffling (i.e. changing the shard detected by the validator, and synchronizing the shard chain) is low (close to) zero, because they only need to verify the latest collation (i.e. has the highest score collation) to synchronize shards.
image description
-Figure 6. Stateless client model Figure 6. Stateless client model-
Since the synchronization process can be very fast, the stateless client model can be shuffled between each collation. This will not only reduce storage pressure and overhead, but also make the system more secure, since frequent sampling can gain resistance to adaptive attacks.after about 2.5 “epoch times”Casper FFG will provide an explicit finality threshold, that is,125 block times
conclusion
conclusion
Hopefully I've given a brief introduction to the current concept of Ethereum's sharding design, and how explicit finality can benefit the sharding mechanism. For an in-depth look at protocol design, visitETHResear.chandsharding doc。
and
If there are any mistakes or unclear expressions, please correct me!
