HEAD:以太坊：Safe Head 机制介绍（一）_HEHE

作者：NicLin，imTokenLabs资深区块链工程师

本文受众：区块链开发者

如果想复习以太坊TheMerge的其他改动，可以参考这篇：

https://medium.com/taipei-ethereum-meetup/eth-2-0-cl-el-separation-and-impact-of-the-merge-dbeb6828c907

读者会需要对以太坊PoS的术语和机制有基本的了解。

SafeHead做什么用？

在PoW中，如果没有指定你要哪个区块的状态，节点预设就会回传给你latest区块的状态，也就是最新的状态。但是进到PoS后，PoS的区块比PoW区块更不可靠，因为PoS产生区块不需要任何「work」，而是只要是被指派的proposer都可以产生一个合法区块。这表示在PoS里取latest区块的状态会更容易发生区块、状态被回滚，也因此才会出现SafeHead这个BlockTag：一个比latest区块还旧一些些但是可靠许多的区块，让DApp呈现数据给使用者看的时候，不会因为区块不可靠、经常因为reorg而被revert导致使用体验变很差。

正常情况下对新区块而言，在出块后约四秒，即会被标为safe，成为safe区块，使该区块更可靠不过当网络出现问题或有攻击发生时，safe区块还是有可能revert回旧的区块ProofofStake

在介绍SafeHead之前，先快速复习一下以太坊的PoS共识机制。

在PoS中，时间被划分为每12秒为一个slot，每32个slot为一个epoch。PoS的Validator当前约有接近43.8万个，在每个epoch全部的Validator会被分配到不同的slot，并负责在该slot产生Attestation，产生Attestation可以视为投票的动作。此外，每个slot的Validator还会细分为64个不同的committee，这是为了支援Eth2计划中会有64个ShardChain的设计：每个committee分别投给不同ShardChain的区块，但在Sharding推出前这些committee可以先视为同一个committee。

每一个Validator在其Attestation中主要要填入两个投票的对象：他支持的区块及epoch。一个slot有13700个Validator，所以一个区块最多会有13700张选票投给它；一个epoch有43.8万个Validator，所以一个epoch最多会有43.8万张选票投给它。

针对区块及epoch的投票其实分别就是以太坊PoS中ForkChoiceRule及CasperFFG两层共识机制的核心，下面一层是持续不断在增长的区块，共识是靠ForkChoiceRule决定，以区块为单位，看的是每个区块的得票数及其子孙区块的得票数；搭建在上面的是运作比较缓慢的CasperFFG，以epoch为单位，看的是每个epoch的得票数。

不断增长的区块，使用的共识是ForkChoiceRule

CasperFFG是以epoch为单位的共识

两层共识是并行运作的

这篇分析五月PoSreorg的文章也有简短但是更细节的共识机制介绍。

ForkChoiceRule

你可能会好奇已经有ForkChoiceRule帮忙从多条分叉链中算出目前哪条才是最长链，为什么还会需要再算一个SafeHead？或是反过来，为什么不干脆用SafeHead算法取代ForkChoiceRule？

其实ForkChoiceRule和SafeHead可以视为两个不一样的机制。节点需要ForkChoiceRule来决定目前最长链是哪一条，proposer才能将区块建立在最长链之上，即便最新的区块获得的得票数不高，但节点算出的最长链就是这条，所以还是得接在这个最新区块后面。而SafeHead是给DApp、给使用者看的，是节点替他们找出的一个比较旧但是可靠许多的区块。

针对ForkChoiceRule其实有不少攻击，例如BalancingAttack会让节点不断在两条分叉链之间切换。其他攻击可以参考最下方SafeHead投影片里的第3页到第7页。这些攻击都有可能造成reorg，而SafeHead其实不是要算出一个区块是可以在攻击发生时还能不被影响，因为reorg是没办法避免的。

CasperFFG

因为接下来会提到CasperFFG的相关名词，所以在这里先做一个重点提要，在文章末段会有更深入的CasperFFG介绍。

CasperFFG有两个产物：JustifiedCheckpoint及FinalizedCheckpoint当Checkpoint获得超过2/3Validator投票会变成JustifiedCheckpoint，是很安全的区块当区块连续两个epoch都获得超过2/3Validator投票则会变成FinalizedCheckpoint，具有Finality性质，是非常非常安全的区块接下来将会进入今天的正题：SafeHead

SafeHead

在网络正常且没有攻击的情况下，在新区块出块后约四秒，即会被标为safe，成为safe区块，使该区块更可靠。这是因为SafeHead是基于每个区块的得票率去做计算，当网络出现问题或攻击正在进行时，一个正常节点所观察到的区块得票率会开始下降，因为那些消失的票数可能投给另一条分叉链上的区块。在这种情况出现时，SafeHead会停住或甚至revert回旧的区块。

PoS节点可以由观察到的得票率变化来做应对，相反的在PoW里攻击者暗中建造的链一但成为最长链，正常节点手上的区块就会直接被reorg掉，节点没有办法提前观察出异状。

使用范例

读取Vitalik最新的余额：awaitprovider.getBalance("vitalik.eth")读取Vitalik的余额：awaitprovider.getBalance("vitalik.eth","safe")要找出SafeHead主要分成两步骤：先算出区块得票率，再算出一个区块包含其所有子孙区块的得票率平均。

先算出区块得票率

要能算出SafeHead，首先第一步是算出每个区块的得票率。一开始有提到目前每个slot最多可以获得13700张选票，所以得票数除上13700就可以算出得票率。

注：如果某个slot被指派的proposer没有propose区块，则被分配到该slot的Validator就会投给前一个区块。所以其实一个区块的得票数是有可能会高于该slot所被分配到的Validator数量的。

每个Attestation里要填入的值会包含slot、index及beaconBlockRoot这三个。slot就是该Validator被分配到的slot，index是他被分到的committee编号，beaconBlockRoot是它投的区块的blockroot。有了这些资料我们就可以为每个区块算出得票数及得票率：针对每个区块找出所有beaconBlockRoot和它的blockroot一样的Attestation，接着要去掉重复的Validator，这是因为Validator签完Attestation后会广播到p2p网络中，然后这些Attestation会被合并起来，而因为负责合并的人可能有多个，所以同一个Attestation可能会出现在不同合并者合并后的Attestation中。去掉这些重复后的Attestation数量就是得票数。

接着算出一个区块包含其所有子孙区块的得票率平均

这里比较难解释，因此直接搭配图示解释比较清楚：

从JustifiedCheckpoint往后的区块开始计算一个区块本身得票率加上所有子孙区块的得票率平均就是一个区块的SafeHead分数当一个区块的SafeHead分数超过50则可视为SafeHead场景一

Block2的分数为其本身得票率加上每个子孙区块的得票率的平均：(95959590)/400=94%。以此类推，Block6是最新区块，没有得票率，所以Block5分数即为本身得票率。

场景二：Block4平均得票率为45%，没办法被视为SafeHead

即便子孙区块出现分叉也算，因为投给这些子孙区块都隐含投给这个区块本身没出块的slot的得票率只能打五折场景三：如果出现分叉，得票率可以相加，因为都隐含投给Block4及其祖先区块

场景四：Slot4没出块，在算它自身得票率时需打五折：55/2=27.5

场景五

以上是SafeHead的算法，看起来还算能理解，但每个新的区块的得票率都会影响所有祖先区块，且每个区块都要考虑所有的子孙区块的得票率，所以实践上其实不是这么简单。

还没实践的SafeHead算法

但目前这个SafeHead算法还没被实践，DApp如果现在使用safe这个BlockTag去查询链的状态，都会得到JustifiedCheckpoint那个时间点的状态，也就是目前的SafeHead等于JustifiedCheckpoint。

JustifiedCheckpoint太久了，如果使用JustifiedCheckpoint则DApp前端显示的是至少6.4分钟以前的信息，或者是使用者送出交易要6.4分钟才会显示出来，这都是非常糟糕的使用体验。所以现在还不适合用safe这个BlockTag，但只能用latest区块吗？其实到目前为止网络一直都正常且PoS运作也都非常顺利，每个区块得票率几乎都是九成以上，所以在过渡期内先用latest区块或BlockConfirmationRule也不需要担心会常常碰到reorg。

注：只单纯看区块数而不看区块「得票数」的方式都不可靠，例如PoS里用BlockConfirmationRule就不可靠。不过如同上述，PoS到现在都运作得非常好，所以不需太担心。

下一篇将介绍imToken尝试实践的SafeHead版本、除了SafeHead之外能做的事、CasperFFG以及该怎么使用Checkpoint和SafeHead。

参考资料

SafeBlockConfirmationRule-HackMDEthereumPoSAttackandDefense—jmcook.eth介绍SafeHead算法的投影片：

Highconfidenceblockconfirmations

特别感谢Chih-ChengLiang，Chang-WuChen，StevenWu和doublespending校对本文并提供改进建议。

风险提示：本文内容均不构成任何形式的投资意见或建议。imToken对本文所提及的第三方服务和产品不做任何保证和承诺，亦不承担任何责任。数字资产投资有风险，请谨慎评估该等投资风险，咨询相关专业人士后自行作出决定。

标签：HEADEHEPOSLOCKHEADZHEHEPOSS价格blockchains

欧易okex官网热门资讯