以太坊2.0规范：Casper和分片

译者按：以太坊2.0是指以Casper、分片等技术为核心，旨在大幅扩容以太坊平台的方案，而其中就涉及到一个称为“beacon链”的核心PoS链概念，而它与以太坊PoW主链之间会是什么样的关系呢？

据悉，这一概念最初是由以太坊创始人Vitalik Buterin在今年初时提出的，目前在JustinDrake、djrtwo以及mkalinin三人的帮助下继续完善。截至发稿时，以太坊2.0的规范完成度接近了60%。

注：文章中的内容反映的是以太坊研究人员和实施者正在进行当中的工作，但其需要不断地完善。

币**为规范译文：

在以太坊2.0当中，有一个被称为“beacon链”的核心系统链，这个beacon链负责存储和管理当前活跃PoS验证者的集合。而最初成为验证者的唯一机制，是在现有的以太坊1.0 PoW主链发送一笔包含的交易至一个注册合约。当你这样做时，一旦beacon?PoS链处理了该区块，你就会进入队列，并最终成为一名活跃验证者。当然，你也可以自愿注销验证者身份，或者因为自己的不当行为而被强行注销身份。

beacon链的主要负载来源是证明（attestation）。这些证明会同时确认一个分片区块，以及相对应的beacon链区块。对于相同的分片区块，足够数量的证明就创建了一个“交联”（crosslink）。“交联”用于“确认”分片链的片段进入了?beacon链，并且这也是不同分片之间互相通信的主要方式。

注：项目的python代码库地址为：https://github.com/ethereum/beacon_chain

1、验证者（Validator）：参与Casper/分片 共识系统的参与者。你可以通过将32 ETH存入这个Casper机制而成为一名验证者。

2、活跃验证者集（Active validator set）：指那些正在参与的验证者，Casper机制希望产生并证明区块、“交叉链接”以及其它共识对象；

3、委员会（Committee）：活跃验证者集的一个（伪）随机抽样子集。当一个委员会被集体提及时，正如“这个委员会证明了X”一样，这就意味着，该委员会的一些子集包含了足够的验证者，以致协议承认它代表着该委员会。

4、提出者（Proposer）：创建区块的验证者；

5、证明者（Attester）：它是委员会的验证成员，其需要在一个区块上进行签名操作；

6、Beacon链（Beacon chain）：分片系统的基础，即核心PoS链；

7、分片链（Shard chain）：处理用户交易的链之一，用于存储账户数据；

8、交联（Crosslink）：来自委员会的一组签名，其可证明一个分片链中的区块，它们可以被包含在beacon链当中。交联是beacon链“了解”分片链更新状态的主要手段；

9、Slot：SLOT_DURATION周期时间，在此期间，一个提出者有能力创建一个区块，而某些证明者能够进行证明工作；

10、朝代变迁（Dynasty transition）：验证者集的变化；

11、朝代（Dynasty）：自创世以来，在给定链中发生的朝代变迁的数量；

12、周期（Cycle）：在这个时期内，所有验证者都有一次投票的机会（除非一个朝代的转变发生在内部）

13、完成区块及合理区块（Finalized,?justified），见Casper FFG定稿：https://arxiv.org/abs/1710.09437

14、取款周期（Withdrawal period）：验证者退出与验证者余额可取款之间的slot数量；

15、创始时间（Genesis time）：beacon链在slot 为0时的创始区块UNIX时间；

验证者状态码：

特殊记录类型：

验证者集增量标志：

以太坊2.0的初始部署阶段，是不需要对PoW链进行共识更改的。相反的是，我们会向PoW链添加一个注册合约，以存入ETH。这个合约有一个注册函数，它采用了, , , 这些参数，正如下面的的ValidatorRecord中所定义的。

这个注册合约会通过beacon链发出一个带有各种参数的日志。它不会进行验证，而是把注册逻辑发送给beacon链。需要注意的是，注册合约不会去验证占有证明（基于BLS12-381曲线）。

Beacon链是PoS系统的“主链”，beacon链的主要职责是：

1. 存储并维护活跃、列队等待以及退出验证者的集合；
2. 处理交联（见上述文章）；
3. 处理逐块一致性，以及最终小工具（finality gadget）；

4、1 ? Beacon 链区块

一个具有币**字段：

一个具有币**字段：

一个具有币**字段：

一个具有币**字段：

4、2 ?Beacon链状态

beacon链状态分为了活跃状态（active state ）和结晶状态（crystallized state）这两个部分；

下面的是活跃状态ActiveState具有的字段：

下面的是结晶状态具有的字段：

一个ValidatorRecord具有币**字段：

一个具有币**字段：

一个ShardAndCommittee 对象具有币**字段：

4、3 ?Beacon链的处理

处理beacon链，在很多方面与处理PoW链有着相似之处。例如客户端下载、处理区块，维护当前的“权威链”，并终止于当前“头部”区块。然而，由于beacon链与现有PoW链之间的关系，并且beacon链是一种PoS链，两者还是有很大不同的。

对于beacon链上节点所处理的区块，必须要满足3个条件：

1. 由指向的父对象已被处理及接受。
2. 由所指向的PoW链区块已被处理及接受；
3. 节点的本地时间大于或等于由GENESIS_TIME + slot_number * SLOT_DURATION 计算得出的最小时间戳；

如果不满足这三个条件，则客户端应延迟处理区块，直到满足这几个条件为止。

在区块生产方面，由于PoS机制的原因，beacon链显然与PoW链存在着显著差异。客户端应检查权威链应该在什么时候创建区块，并查找它的slot（注：类似区块高度）数；当slot到达时，它会根据要求提出或证明一个区块；

4、4。Beacon链分叉选择规则

beacon链使用了Casper FFG分叉选择规则，即“支持包含**合理检查点（highest-epoch justified checkpoint）的区块链”。为了从相同合理检查点派生而出的两条链之间进行选择，区块链会使用即时消息驱动GHOST（IMD GHOST）方案来选择出权威链 。

具体描述参见：https://ethresear.ch/t/beacon-chain-casper-ffg-rpj-mini-spec/2760

相关模拟实现代码库，请参见：

https://github.com/ethereum/research/blob/master/clock_disparity/ghost_node.py

下图展示了系统工作的一个例子（绿色是完成区块，黄色代表合理区块，灰色代表证明）：

我们现在定义一下状态转移函数。从高层次讲，状态转换由两个部分组成：

1. 结晶状态重计算，这只有当时才会发生，而它会影响以及；
2. 每区块处理（per-block processing），它发生在每个区块，并且其只影响；

结晶状态重计算通常集中于对验证者集的更改，包括调整余额，添加和删除验证者，以及处理交联（ crosslink）和设置FFG检查点，而每区块处理通常集中于验证聚合签名并保存与区块内活动有关的临时记录。

5、1 ?辅助函数（Helper functions）

我们首先定义一些辅助算法。首先是，选择活跃验证者的函数：

下面的是洗牌这个列表的函数：

下面的是一个将列表拆分成N块的函数：

下面的，是我们的组合辅助函数：

下面的是一个关于正在发生的图解：

我们还定义了两个函数：

其中应该始终以slot 返回链中的区块，而get_shards_and_committees_for_slot(_, s)则不应该改变，除非朝代（dynasty）发生改变。

我们还定义了一个函数，为验证者哈希链“添加了一个link”，这在添加或移除一个验证者时使用：

**，我们抽象地将用于奖励/惩罚计算的int_sqrt(n)定义为**整数k，使得k**2<=n：

5、2 关于启动（On startup）

运行币**代码：

和构造函数应根据上下文将所有值初始化为零字节、空值或空数组。程序定义如下：

5、3 处理每个区块（Per-block processing）

这个程序应该在每个区块上执行。

首先，将recent_block_hashes设置为币**输出，其中parent_hash是前一个区块的哈希：

get_block_hash的输出不应该改变，除非它不再抛出 ，而是抛出

此外，使用币**算法检查区块的数组是否被正确更新：

区块可以有0个或多个AttestationRecord对象，其中每个AttestationRecord对象具有币**字段：

对于这些证明中的每一个：

1. 验证 以及；
2. 验证以及等于或早于结晶状态的
3. 计算
4. 让 成为,选择 那么 就等于 所提供的 值，以找到创建证明记录的验证者集；
5. 验证, 其中. 验证位…. 以及更高的, 如果出现的 (例如. )结果不是8的倍数), 则全为0
6. 让 .
7. 使用生成的公钥组以及序列化形式的 验证 ；

5、4 状态重计算

当时进行重复过程；

对于范围中所有的slot ；

1. 让成为活跃验证者的总余额；
2. 让成为beacon链区块在slot s 时验证者的总余额
3. 确定这些验证者的总余额，如果该值乘以3等于或超过所有活跃验证者乘以2的总余额（），则设置 以及。否则，则设置；
4. 如果justified_streak >=CYCLE_LENGTH + 1，则设置last_finalized_slot=max(last_finalized_slot, s – CYCLE_LENGTH – 1)；
5. 删除所有比 last_state_recalc slot更早的证明记录；

还有：

1、设置last_state_recalc +=CYCLE_LENGTH；
2、设置indices_for_slots[:CYCLE_LENGTH]=indices_for_slots[CYCLE_LENGTH:]；

对于所有(shard_id, shard_block_hash) 元组，计算为该分片区块哈希投票的验证者总存款大小。如果该值乘以3等于或超过委员会中所有验证者的总余额乘以2，并且当前朝代（dynasty）超过crosslink_records[shard_id].dynasty，则设置crosslink_records[shard_id]=CrosslinkRecord(dynasty=current_dynasty, hash=shard_block_hash)；

待办事项：

1. FFG参与奖励；
2. 委员会参与奖励；

如果满足下列所有标准，则在状态重新计算之后发生了朝代变迁：

3. 对于中的每一个分片数，crosslinks[shard].slot > dynasty_start_slot

然后，运行下面的的算法来更新验证者集合：

**：

1. 设置 last_dynasty_start_slot=crystallized_state.last_state_recalculation_slot
2. 设置 crystallized_state.dynasty +=1
3. 设置 next_start_shard=(shard_and_committee_for_slots[-1][-1].shard + 1) % SHARD_COUNT
4. 设置 shard_and_committee_for_slots[CYCLE_LENGTH:]=get_new_shuffling(active_state.randao_mix, validators, next_start_shard)

注：这个项目的完成度大约为60%，所缺少的主要部分为：

1. 具体讲解构造 crystallized_state_root以及active_state_root，包括用于轻客户端的默克尔化证明；
2. 关于pow_chain_reference可接受值的具体规则；
3. 关于分片链区块、提出者等具体规则；
4. 关于强制撤销登记的具体规则；
5. 关于（全局时钟、网络延迟、验证者诚实、验证者活跃度等）问题的各种假设；
6. 关于监护证明的逻辑，包括削减条件；
7. 添加BLS12-381曲线的附录；
8. 添加gossip网络以及链外签名聚合逻辑的附录；
9. 添加一个词汇表（在单独的词汇表中），以全面而准确地定义所有术语；
10. 进行同行评审、安全审核和形式验证；

可能的修订/增补 工作

1. 用LMD替换IMD分叉选择规则；
2. 将 以及 默克尔化成一个单独的根；
3. 用一个对STARK友好的哈希函数替换掉Blake；
4. 去掉朝代（dynasties）的概念；
5. 将slot直接换成8秒；
6. 允许延迟聚合签名的包含；
7. 引入一种RANDAO削减条件；
8. 对于占有证明，使用一种单独的哈希函数；
9. 修改数据结构；
10. 为历史beacon链区块添加一个双批（double-batched）的默克尔累加器；
11. 允许存款大于32ETH，并设置存款上限；
12. 对于存款低于32ETH（或其它阈值）的情况，设置一个罚金；
13. 为寄存器添加一个；
14. 重写文档可读性；
15. 清楚地记录各种边缘情况，例如委员会的大小；

附录A -哈希函数

我们的目标是在推出beacon链时，拥有一个对STARK友好的哈希函数。这个哈希函数的标准化过程，是由STARKware主导的，他们将制定详细的报告说明。我们会使用作为占位符。明确地说，我们设置了 ，其中算法是在RFC 7693中定义的。