本文的目地是关于以太坊分片设计的概述,并且解释explicit finality如何能帮到区块链分片
为了全面更好的理解以太坊分片机制规范,强烈推荐阅读Vitalik的 sharding doc [2] by Vitalik.
区块链的扩容(Scalability)问题
- 交易增长
- Limitation of scalability with current block creation process. Block gas limit restricts the computational capacity of the block. Increasing block gas limit or decreasing block time too much would lead to high stale rate and weaken the ability of the network against attacks.
- 缺少并行性. 首先,当前EVM是以顺序方式操作事务. Second, every full node executes each transaction and store the whole (or pruned) state trie for security and decentralization.
Further reading: EIP 648 — Easy parallelizability for executing transactions in parallel.
To solve scalability problems, sharding is a solution that introduces to on-chain state partition and gains higher throughput.
术语(Terminology)
下面是主链和分片链的术语对照表:
Collation打包所有的事务,同时在链上,一个Collation也指向父Collation.Collator有权在POS分片链上提议一个新的Collation。
Basic Quadratic Sharding
The Consensus of Shard Chain Depends on Main Chain
与侧链相似,只有相对较小的proof of collations被记录到链上。这是我们扩容的基础:
- 分片链只管理本片里的交易,shard validators只验证他们监视的shard
- 分片链粘附在主链上通过POS机制到达高级别的共识.
Validator Manager Contract (VMC)
为了加入位于主链上的分片链,在主链上有一个特殊的合约 - 验证管理合约(VMC). VMC 是分片技术的核心,它的目标是:
- POS机制. 验证者的保证金会被没收如果他们恶意操作的话.
- 伪随机抽样. By applying recent block hash as the seed to sample the eligible collator. Basically, the validators deposit their stake in VMC, and then their validation code address would be recorded in a global validators pool list inside VMC. One shard chain validator would be sampled from validators pool list, and become the collator of thespecific shards in specific “period”(as it will be explained below). The idea is making validators unable to forecast when they would be the collator and in which shard many days ago.
- Collation header 验证. VMC contains an addHeader(bytes collationHeader) function to verify the collation header and writing a record of valid collation header hash. This function provides on-chain verification immediately.
- 跨片通信. By utilizing UTXO model, the user can deposit ether on a specific shard via transaction call and create a receipt (with a receipt ID) on main chain. The shard chain user can create a receipt-consuming transaction with the given receipt ID to spend this receipt.
- 线上治理. VMC的角色类似议会,使验证者可以在线上投票.
在分片上如何提议Collation?
In phase 1, VMC维护100个分片 (SHARD_COUNT = 100). 每个分片并行运行而且,分片I上的客户只能验证在分片I上的交易.
“period” 被定义为块数的窗口, 比如PERIOD_LENGTH = 5 意味着每个period5块. 这同时表明在每个period, 对每一个片,只有少于等于1个合法的collation.
Once the validator gets sampled to be eligible collator to propose a new collation, the collator has to validate the recent collations and send a transaction to call addHeader function. Note that if the collator is sampled to propose a new collation on period 10, that means the addHeader transaction has to be included in period 10, i.e., block number10 * PERIOD_LENGTH to block number (10 + 1) * PERIOD_LENGTH — 1.
The collation header hash must be recorded on VMC to prove its header is valid in global. Also, the other validators of the shard have to watch VMC all the time for getting latest status and then verify if the transactions are valid too.
Fork Choice Rule of Shard Chain
In basic sharding, the fork choice rule depends on the longest main chain. The valid head collation of the given shard is not simply the head collation of “longest valid shard chain” but the “the longest valid shard chain within the longest valid main chain”.
An example is described in Figure 3: in Figure 3(a), there are two forks of main chain and the second chain is the longest valid main chain in the following figure. Since block B3 is the head block, it’s easy to see that collation C3 is the head collation.
And then block B3' arrives in Figure 3 (b). Assume that the score of block B3 is higher than the score of block B3', so the upper chain is still the longest main chain:
Lastly, block 4 arrives in Figure 3 (c). Note that for this shard, collation C3 has a higher score than collation C2, but the below chain is the longest valid main chain, so collation C2 is the head collation now:
Further reading: another design — Vlad Zamfir’s sharded fork choice rule. ������
An ingenious design for guaranteeing blocks atomicity before they are finalized.
可伸缩性(Scalability)和安全性(Security)的损益比较
区块链系统最多可以获得以下3种属性里的2种: 去中心化(decentralization), 可伸缩性(scalability), 和安全性(security).
— Blockchain Trilemma in Sharding FAQ [3]
The limitation of scalability is based on the security guarantees of the system [3]. While we increased TPS (Transactions Per Second) by distributing transactions to shards, we also decreased computational resources for each transaction consequently.
One of the important mechanism of sharding is how to produce randomness on-chain.
- The chance of being selected as collator should only be relevant and proportional to the validator’s deposit.
- If the validators can predict or choose which shard they will participate in arbitrarily, the dishonest validators can collude with each other and start an adaptive attack.
If the sampling process fails to select with high randomness, it’s possible for an attacker to start 1% attack in the shard: if there are 100 shards, the attacker can focus on attack one particular shard, they only need 1% hash rate (PoW)/deposit (PoS) to control the shard [4].
Blockchain Explicit Finality for Sharding
Implicit Finality v.s. Explicit Finality
首先,分片机制应能够同时应用到POW链和POS链。尽管如此,explicit finality gadget 比如 Casper,能使分片更强壮.
一般的,POW链,finality是有概率的且不明朗的。简单的说,就是有可能重写整个链尽管这个块获得了上千的确认. 相对的,应用POS - Casper the Friendly Finality Gadget (“FFG”) 加密货币经济机制显式的强制finality - 我们能检查如果在协议定义的情况下交易已经终结(we-can-check-if-its-finalized-for-us in-protocol).
There’s an economic risk of in-protocol explicit finality threshold: it creates the ideal cartel sizes at 2/3 + 1 and 1/3 + 1. Accordingly, the marginal contribution to finality of any node which is not in 2/3 + 1 coalition becomes 0.
Dependency on Main Chain Finality
In basic sharding, the shard chains are pegging on main chain.
To the shard validators, we expect with sharding, the blockchain capacity became 100x higher in phase 1, thus all the validators of these 100 shards will need to watch VMC status to get the correct valid head collation. It’s important for validators to be certain of know they are the collator or not as soon as possible; to the normal users, if we apply cross-shard transactions in phase 2, the normal users will also need to retrieve their deposit information (receipt ID) on VMC.
Explicit finality would help for mitigating the uncertainty of syncing between main chain and massive shard chains.
Explicit Finality Helps for Stateless Client
The basic idea of stateless clients is that the stateless clients don’t store the whole state trie, instead, they only store the state trie root. The archival clients store the full state trie and provide the Merkle branches that the given collation needs. With these Merkle branches, the stateless clients are capable of building the partial state trie and verifying the collation [6].
The syncing process would be triggered once the validator gets sampled and starts reshuffling (i.e., changing the shards which the validators watch for and syncing the shard chains). With stateless client mechanism, the cost of reshuffling drops to (near) zero because they only have to validate the recent collations (i.e., collations with high score) to sync with the shard.
Since the syncing process could be much faster, stateless client model makes it possible to reshuffle between each collation. It not only reduces the storage burden and overhead but also makes the system more secure because frequent sampling gains adaptive attack resistance.
Although the syncing cost becomes much lower, the stateless validators still have to verify as more collations as they can within a certain period of time to confirm that they get the best valid collation with the highest score.
after about 2.5 “epoch times” (在大概2.5 个Epoch time后) Casper FFG 提供显示终结(explicit finality)门槛, biru, 125 block times [1] [7]. 如果在重新洗牌中,验证者能够验证多于125 / PERIOD_LENGHT = 25 collations , 分片系统就可以从explicit finality中获益,并且可以很自信从现在往前的25个collations是全部确定了的。
注:如果我们在同步时有更多的collation被验证,系统就会更安全.
参考
- Jon Choi. Casper 101: https://medium.com/@jonchoi/ethereum-casper-101-7a851a4f1eb0
- Vitalik Buterin. Sharding Document: https://github.com/ethereum/sharding/blob/develop/docs/doc.md
- Vitalik Buterin and the contributors. Sharding FAQ: https://github.com/ethereum/wiki/wiki/Sharding-FAQ
- Vitalik Buterin. Sharding Mindmap: https://www.mindomo.com/mindmap/sharding-d7cf8b6dee714d01a77388cb5d9d2a01
- Vitalik Buterin. On Settlement Finality: https://blog.ethereum.org/2016/05/09/on-settlement-finality/
- Ethresear.ch thread — The Stateless Client Concept: https://ethresear.ch/t/the-stateless-client-concept/172
- Ethresear.ch thread — Casper contract and full POS: https://ethresear.ch/t/casper-contract-and-full-pos/136/2
- ETHResear.ch
- sharding doc.
参考: Ethereum Sharding: Overview and Finality