./prysm.sh validator accounts create
可以看到，由于合约吸收的参数是牢靠的名目和语义的，所以直接将各部门 pack 成 32 bytes，然后做 merkleize 求值，最后与吸收到的 deposit_data_root 举办较量，假如沟通则说明数据没有被改动。
（向左滑动，查察完整代码）
建设验证者密钥对一个验证人需要建设两对密钥对，一对用作验证人出块和见证，另一对用于打点存入合约的资金。运行如下呼吁来建设密钥：
参考资料：
对付上述第 3 部门数据完整性的校验与结构生意业务数据一致，校验的逻辑干系参考下图：
reward_numerator = get_base_reward(state, index) * (attesting_balance // increment) rewards[index] += reward_numerator // (total_balance // increment)
新建验证者的配置如下：
2. h(s1) < h(s2) < h(t2) < h(t1)
def get_attestation_component_deltas(state: BeaconState, attestations: Sequence[PendingAttestation] ) -> Tuple[Sequence[Gwei], Sequence[Gwei]]: """ Helper with shared logic for use by get source, target, and head deltas functions """ rewards = [Gwei(0)] * len(state.validators) penalties = [Gwei(0)] * len(state.validators) total_balance = get_total_active_balance(state) unslashed_attesting_indices = get_unslashed_attesting_indices(state, attestations) attesting_balance = get_total_balance(state, unslashed_attesting_indices) for index in get_eligible_validator_indices(state): if index in unslashed_attesting_indices: increment = EFFECTIVE_BALANCE_INCREMENT # Factored out from balance totals to avoid uint64 overflow if is_in_inactivity_leak(state): # Since full base reward will be canceled out by inactivity penalty deltas, # optimal participation receives full base reward compensation here. rewards[index] += get_base_reward(state, index) else: reward_numerator = get_base_reward(state, index) * (attesting_balance // increment) rewards[index] += reward_numerator // (total_balance // increment) else: penalties[index] += get_base_reward(state, index)
在生成上述的参数后，会凭据合约接口编码成必然的名目，然后发送给存款合约完成挪用。
mkdir prysm && cd prysm curl https://raw.githubusercontent.com/prysmaticlabs/prysm/master/prysm.sh --output prysm.sh && chmod +x prysm.sh
预备（prepare_req）：每个预备讯息只能指向某个也具有 2/3 节点预备讯息的高度（Epoch），且这些预备讯息也必需都指向同一个高度。
Slot 和 Epoch 暗示信标链的出块时间和共鸣结算周期。按最新的信标链的技能类型 v0.12，一个 Slot 的时间是 12 秒。每一个 Epoch 由 32 个 Slot 构成，约莫 6.4 分钟。也就是说在正常环境下，信标链每 12 秒就产出一个区块。每 6.4 分钟是一个新的共鸣周期。
（向左滑动，查察完整代码）
LMD GHOST
⻅证中包括了正确的最新区块
作为广受瞩目标全球顶尖公链项目，以太坊 2.0 完全颠覆了从前的设计，旨在最洪流平地同时实现去中心化和扩容方针。与以太坊 1.0 差异的是，以太坊 2.0 利用 PoS （权益证明）算法来敦促区块链的运行，并通过「信标链+多分片链」 的架构来提高可扩展性。
可以看到：
验证人的投票在信标链中称为⻅证动静（Attestation），在尺度中一条⻅证动静由三个投票构成：
def get_proposer_reward(state: BeaconState, attesting_index: ValidatorIndex) -> Gwei: return Gwei(get_base_reward(state, attesting_index) // PROPOSER_REWARD_QUOTIENT)
（向左滑动，查察完整代码）
HashTreeRoot 提供了将一个工具按必然名目构建默克尔树、并求得树的默克尔根值的要领。HashTreeRoot 可以将一个工具（bit、bytes、vector、list、containers 等等）的各个部门按序分列然后构建默克尔树，得到根值。详细类型参考：https://github.com/ethereum/eth2.0-specs/blob/dev/ssz/simple-serialize.md
预备提交一致性（prepare_commit_consistency）：任何新的预备讯息只能指向最后一个已提交的或其他比其更新的高度。
⻅证中包罗了正确的查抄点的投票
[m / 0] - [m / 0 / 0] / \ / [m / 0 / 1] [m] - [m / 1] \ ... [m / i]
来历：https://ethos.dev/beacon-chain/
（向左滑动，查察完整代码）
解答开拓者最体贴的以太坊 2.0 Staking 要害问题：用代码解读成为以太坊 2.0 验证人的进程，探秘信标链共鸣与鼓励机制。
def process_registry_updates(state: BeaconState) -> None: # Process activation eligibility and ejections for index, validator in enumerate(state.validators): # 能否进入期待行列 if is_eligible_for_activation_queue(validator): validator.activation_eligibility_epoch = get_current_epoch(state) + 1 # 能否成为活泼的验证者 if is_active_validator(validator, get_current_epoch(state)) and validator.effective_balance <= EJECTION_BALANCE: initiate_validator_exit(state, ValidatorIndex(index)) # 限制每周期成为验证者数量 # Queue validators eligible for activation and not yet dequeued for activation 15. activation_queue = sorted([ index for index, validator in enumerate(state.validators) if is_eligible_for_activation(state, validator) # Order by the sequence of activation_eligibility_epoch setting and then index ], key=lambda index: (state.validators[index].activation_eligibility_epoch, index)) # Dequeued validators for activation up to churn limit for index in activation_queue[:get_validator_churn_limit(state)]: validator = state.validators[index] validator.activation_epoch = compute_activation_exit_epoch(get_current_epoch(state))
除此之外，我们还需要至少 32 ETH 的以太坊账户和欣赏器插件 metamask 以便发送生意业务。可以在测试网上申请一些测试币，如下图所示：
如何成为验证人？以太坊回收存款合约（deposit contract）作为以太坊 1.0 与以太坊 2.0 之间的桥梁，当用户向存款合约存入 32 ETH 后，便可以作为以太坊 2.0 的验证者参加事情，并得到以太坊 2.0 嘉奖。
在处理惩罚新增加的验证者时，会凭据必然比例配置一个期待行列，这会限制同一时间可以增加的新的验证者数量，也可以或许防备一瞬间涌入的大批新的验证者对付网络安详和协议的影响，担保必然的不变和安详性。
焦点代码行：
这是按照上面的密钥对生成的生意业务信息，我们将它复制到网页上的生意业务数据部门：
生成数据挪用合约挪用合约除了凡是的合约地点、金额参数外，还需要结构要挪用的合约要领的参数：pubkey （验证者公钥）、withdrawal_credentials (提取存款权限信息)，signature （签名）和 deposit_data_root （防备改动标识）。在用户生成两对密钥后，就可以生成上面这些参数来结构要发送的生意业务数据，参考下图：
Vitalik 总结了四条法则，任何违反此四条法则的行为都要被取走押金。
*提交（commit_req）：收到 2/3 节点的预备讯息后才气提交。
⻅证被很快地包括到链上
Casper FFG
LMD GHOST 和 Casper FFG所有 PoS 范例的区块链都面对着两个最重要的安详问题 :
https://github.com/ethereum/eth2.0-specs/blob/dev/deposit_contract/contracts/validator_registration.vy
验证人委员会（Committee）
信标链的处理惩罚当存款生意业务乐成被以太坊 1.0 链上执行后，以太坊 2.0 的信标链接下来如那里理惩罚？
之后再处理惩罚这些新注册的验证者：
以太坊 2.0 的研发和陈设打算历时已久。在所有客户端均顺利实现类型的最终版本 v0.12.1 后，6 月底将启动一个实现最终版本类型的多客户端测试网，7 月则可启动最后的民众测试网。从此，最终版本的大浩瀚客户端测试网若能不变运行两至三个月，则可开始筹备以太坊 2.0 的主网启动事情。若一切顺利，阶段 0 将于 11 月上线。但若版本类型仍有待修复，且所有客户端需再次实现新类型，则上线时间大概推迟到 2021 年。
出块人将会获得 BaseReward / 8 的出块嘉奖：
上图浮现了由最新动静驱动的分叉选择法则：绿色区块暗示经过 LMD GHOST 分叉选择法则证明白的区块，笑脸标记暗示最新的验证者证明 (attestations)，某个区块中的 证明总量 (笑脸总数) 就是该区块的权重，用区块中的数字暗示。
尽量位于上方的分叉链是最⻓的链，但下方由绿色区块构成的链才是主链，因为绿色区块包括了最多的证明，也就是拥有最多的验证者投票。
（向左滑动，查察完整代码）
⻅证包括正确的分片区块（Phase1 阶段实现）
可以看到，假如存入的已经是一个验证者，只需增加其余额便可。假如存入的是新的验证者，会在举办须要的校验后，在全局状态注册一个新的验证者。
Casper FFG 运作
withdrawal_crendentials 由一个牢靠前缀拼接 Withdrawal PubKey 的哈希（sha256）组成
今朝抉择一个验证人基本嘉奖的计较公式如下尺度代码所示：
https://www.chainnews.com/articles/502750353901.htm
常识点密钥对打点方案
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
