本文摘要：上一期的研究院，我们讲解了在延后继续执行策略时，为了节约计算资源，在发送区块时可以只检查区块的格式和提到否合法（还包括工作量证明），而尽量少检查区块中存的状态根（State Root）。
上一期的研究院，我们讲解了在延后继续执行策略时，为了节约计算资源，在发送区块时可以只检查区块的格式和提到否合法（还包括工作量证明），而尽量少检查区块中存的状态根（State Root）。但是不强迫检查状态根在安全性上不会带给一些隐患，例如有些矿工可能会懒散，只包交易而不管实际继续执行交易，网卓新闻网，也不去检验接到的区块里的状态根的正确性——这样就可以省下继续执行交易、确保和改版状态的支出。当然，对于自己亲力亲为继续执行所有交易的全节点来说，即使有一小撮矿工懒散实质上也会影响他们对于当前共识状态的辨别。
只要懒散的矿工仍原始地继续执行共识层协议，按照协议拒绝检查区块间的提到关系和自由选择提到的区块，则他们的算力仍然为确保账本中的交易顺序不能伪造作出贡献。但是对于重节点来说，区块内的状态根不对就是一个相当严重的问题了。
这是因为重节点自己没能力确保当前整个共识系统里所有账户的状态——否则也就不是“重节点”了——不能自由选择信任仅有节点获取的（具有默克尔树根证明的）状态。如果多个仅有节点获取的状态不完全一致，重节点就无法辨别当前的现实状态。以比特币的重节点为事例，只必须保有每个区块的区块头（Block Header）就可以用 SPV（Simplified Payment Verification）的方式检验一笔交易否已被证实了。
比特币的 SPV 检验步骤如下：1）通过区块头中留存的默克尔树根（Merkle Root）和全节点获取的默克尔树根证明（Merkle Proof），可以非常容易地检验某个区块里包括特定的交易；2）如果包括交易的区块后面跟了充足多的区块（比如说6个）就可以指出这笔交易早已被证实了——实质上这里是区块被证实，但因为比特币最久链上的所有交易都会被继续执行，所以区块被证实等价于交易被证实。理论上，只要能分解充足多的比特币区块，因应对于网络连接的日食反击，就可以被骗过轻节点，让其以为一笔不出现实的比特币网络最久链上的交易早已被证实了，从而构建双花反击。
现在比特币的 UTXO 早已超过了数 GB 的规模，很多场合不能通过重节点用 SPV 的方式证实交易，理论上都会受到上述反击的威胁。但是事实上很少听闻因为 SPV 检验受到这种双花反击的案例，这又是为什么呢？主要的原因还是在于成本。以 6 个区块证实为事例，愚弄重节点构建双花反击必须攻击者最少凿到 7 个比特币区块，并且这些区块都不出比特币的最久链上——否则就变为知道证实交易了。
如果凿的这些区块可玩性和现实的比特币网络非常，则意味著攻击者要退出 7 个获得比特币区块奖励的机会。按照现在的比特币每个区块 12.5个比特币的奖励计算出来，除非双花反击的交易价值多达 75 个比特币，否则这样的反击就是亏本的，因此大自然会有人去实行。
如果再行再加实行日食反击的成本，则上述反击就更为无利可图了。所以在比特币网络中，重节点只需大体告诉准确的挖矿可玩性值，就不必担忧在金额不太多的交易中因为使用 SPV 证实规则而骗。通过 SPV 方式证实交易，最少在比特币的区块奖励再行减为几次之前都还是非常安全性的。当然，如果知道是大额比特币交易的话，就必须减少等候的区块数或者用全节点检验了。
以太坊的重节点也可以通过类似于的方式检验交易继续执行的结果或查找账户的状态，只需仅有节点根据节点中对应交易收据和账户状态的默克尔树根获取适当的证明才可。与比特币这样“一根筋”的区块链系统有所不同，Conflux 为了更高的系统性能使用了并收到块的树图结构以及更慢的出块速度（平均值每秒4块），并且增加了非必要情况下对于状态根的检验。
这些改动会影响仅有节点对于共识的辨别，却有可能为重节点检验当前状态带给艰难。为此，Conflux 引进了 Blaming 机制来协助重节点较慢地证实当前账户状态和每笔交易继续执行的结果。非常简单来说，每个区块自己区块头的 Blaming 域认为自己接纳的上一个“准确的主链区块”，这里的“准确”指区块的状态根和 Blaming 域都是准确的。例如如果一个区块指出自己的父区块就是完全正确的，则 Blaming 域就堆 0；如果指出父区块不准确，但是祖父区块准确，则堆 1；以此类推，如果指出祖父区块也不准确则适当地要堆一个小于1的整数用来命令最后一个准确区块的方位，即落在中间的所有区块都会被诬蔑“状态不准确的区块”。
对于状态根的辨别较为更容易解读：包新的区块的矿工节点必须沿着枢轴链继续执行每个 Epoch 中的交易，在这个过程中大自然不会告诉每个处在枢轴链上的“主链区块”应当有什么样的状态根，因此就可以辨别出有实际处在枢轴链上的区块否填对了这一项。而且因为按照枢轴链登录的顺序继续执行所有交易本来就是每个仅有节点都应当做到的，所以上述检查并不带给额外的开销。
检查过后，就早已可以确认哪些主链区块的状态根是准确的了。但是由于主链上有很多区块，似乎不有可能每次都一一罗列出有哪些区块的状态根是对的，哪些是错的。这就用到了 Blaming 机制的第二部分——关于之前区块 Blaming 域的 Blame。每个区块 A 在 Blaming 域都会说明它指出的主链上最后一个准确的区块 B，这回应区块 A 接纳区块 B 的所有观点：除了指出区块 B 的状态根准确以外，还接纳区块 B 的 Blaming 域是准确的。
这就意味著区块 A 也接纳了区块 B 所命令的在 B 之前的最后一个准确的主链区块 C，从而更进一步接纳了区块 C 所指的 C 之前最后一个准确区块 D，……以后创世纪块方位。因为创世纪块总是对的，所以上述 Blaming 的过程是受限的，每个区块在 Blaming 域堆的数也会多达该区块的高度。通过这种方式，就可以把每个区块 Blaming 域存的一个数字扩展到一组状态根获得当前区块接纳的主链区块。
右图的例子即说明了如何通过 Blaming 机制拓展对于“准确区块”的辨别。
本文来源：NG体育-www.ntmdyjf.com
