【转载】Casper和分片

在以太坊2.0当中,有一个被称为“beacon链”的核心系统链,这个beacon链负责存储和管理当前活跃PoS验证者的集合。而最初成为验证者的唯一机制,是在现有的以太坊1.0 PoW主链发送一笔包含 32 ETH 的交易至一个注册合约。当你这样做时,一旦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时间;

二、常量

P1

验证者状态码:

P1

特殊记录类型:

p2

验证者集增量标志:

p3

三、PoW主链注册合约

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

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

四、Beacon 链数据结构

Beacon链是PoS系统的“主链”,beacon链的主要职责是:

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

4、1 Beacon 链区块

一个 BeaconBlock 具有以下字段:

{ # Slot number ‘slot’: ‘int64’, # Proposer RANDAO reveal ‘randao_reveal’: ‘hash32’, # Recent PoW chain reference (block hash) ‘pow_chain_reference’: ‘hash32’, # Skip list of ancestor block hashes (i’th item is 2**i’th ancestor (or zero) for i = 0, …, 31) ‘ancestor_hashes’: [‘hash32’], # Active state root ‘active_state_root’: ‘hash32’, # Crystallized state root ‘crystallized_state_root’: ‘hash32’, # Attestations ‘attestations’: [AttestationRecord], # Specials (e.g. logouts, penalties) ‘specials’: [SpecialRecord] }

一个 AttestationRecord 具有以下字段:

{
    # Slot number
    'slot': 'int64',
    # Shard number
    'shard': 'int16',
    # Block hashes not part of the current chain, oldest to newest
    'oblique_parent_hashes': ['hash32'],
    # Shard block hash being attested to
    'shard_block_hash': 'hash32',
    # Attester participation bitfield (1 bit per attester)
    'attester_bitfield': 'bytes',
    # Slot of last justified block
    'justified_slot': 'int64',
    # Hash of last justified block
    'justified_block_hash': 'hash32',
    # BLS aggregate signature
    'aggregate_sig': ['int256']
}

一个 AttestationSignedData 具有以下字段:

{
    # Chain version
    'version': 'int64',
    # Slot number
    'slot': 'int64',
    # Shard number
    'shard': 'int16',
    # 31 parent hashes
    'parent_hashes': ['hash32'],
    # Shard block hash
    'shard_block_hash': 'hash32',
    # Slot of last justified block referenced in the attestation
    'justified_slot': 'int64'
}

一个 SpecialRecord 具有以下字段:

{
    # Kind
    'kind': 'int8',
    # Data
    'data': ['bytes']
}

4、2 Beacon链状态

beacon链状态分为了活跃状态(active state )和结晶状态(crystallized state)这两个部分;

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

{
    # Attestations not yet processed
    'pending_attestations': [AttestationRecord],
    # Specials not yet been processed
    'pending_specials': [SpecialRecord]
    # Most recent 2 * CYCLE_LENGTH block hashes, older to newer
    'recent_block_hashes': ['hash32'],
    # RANDAO state
    'randao_mix': 'hash32'
}

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

{
    # Dynasty number
    'dynasty': 'int64',
    # Dynasty seed (from randomness beacon)
    'dynasty_seed': 'hash32',
    # Dynasty start
    'dynasty_start_slot': 'int64',
    # List of validators
    'validators': [ValidatorRecord],
    # Most recent crosslink for each shard
    'crosslinks': [CrosslinkRecord],
    # Last crystallized state recalculation
    'last_state_recalculation_slot': 'int64',
    # Last finalized slot
    'last_finalized_slot': 'int64',
    # Last justified slot
    'last_justified_slot': 'int64',
    # Number of consecutive justified slots
    'justified_streak': 'int64',
    # Committee members and their assigned shard, per slot
    'shard_and_committee_for_slots': [[ShardAndCommittee]],
    # Total deposits penalized in the given withdrawal period
    'deposits_penalized_in_period': ['int32'],
    # Hash chain of validator set changes (for light clients to easily track deltas)
    'validator_set_delta_hash_chain': 'hash32'
    # Parameters relevant to hard forks / versioning.
    # Should be updated only by hard forks.
    'pre_fork_version': 'int32',
    'post_fork_version': 'int32',
    'fork_slot_number': 'int64',
}

一个ValidatorRecord具有以下字段:

{
    # BLS public key
    'pubkey': 'int256',
    # Withdrawal shard number
    'withdrawal_shard': 'int16',
    # Withdrawal address
    'withdrawal_address': 'address',
    # RANDAO commitment
    'randao_commitment': 'hash32',
    # Balance
    'balance': 'int64',
    # Status code
    'status': 'int8',
    # Slot when validator exited (or 0)
    'exit_slot': 'int64'
}

一个 CrosslinkRecord 具有以下字段:

{
    # Dynasty number
    'dynasty': 'int64',
    # Slot number
    'slot': 'int64',
    # Beacon chain block hash
    'shard_block_hash': 'hash32'
}

一个ShardAndCommittee 对象具有以下字段:

fields = {
# The shard ID
'shard_id': 'int16',
# Validator indices
'committee': ['int24']
}

4、3 Beacon链的处理

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

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

  1. ancestor_hashes[0] 指向的父对象已被处理及接受。
  2. pow_chain_ref 所指向的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

原文地址:https://www.ethchinese.com/?p=5118