Blockchain的鱼和熊掌系列（4）GHOST协议

It is well acknowledged that optimizing the tradeoff between performance and security in a given computing system is always a challenging work.



Perhaps the most important work in a Blockchain is the tradeoff as given: throughput and security. Aiming to gain a higher level of throughput while addressing security concerns, the Greedy Heaviest-Observed Sub-Tree protocol (GHOST) was proposed. One of the greatest contributions of the GHOST is that it introduces a chain-growth strategy which allows more transactions to take place on a main chain by the way of increasing the generation rate of blocks.

Q1: GHOST具体是什么鬼？

GHOST是一种主链选择协议（不是侧链选择协议）。举例来说：经典的Proof-of-Work协议是以取最长的主链为基本原则，进行下区块的选择；新的GHOST协议则是以包含子树数目最多为基本原则，进行下区块的选择——这可以说是GHOST协议和PoW协议的最大差异，甚至可以说是唯一差别。

Q2：GHOST协议和PoW协议之间的这一点点差别，为什么会导致二者性能的巨大差异呢？

PoW协议不能以太快的频率（上图的Block Generation Rate）发布新的区块，因为51%算力攻击一旦发生，double-spend等糟糕问题会出现，整个blockchain系统需要足够长的时间来处理和恢复黑客恶意攻击所造成的破坏——这段时间可以理解为系统的有效修复时间，也可以理解为交易信息被确认的等待时间，从安全的角度，显然这段时间越长，交易数据可靠性被验证的越多，所以越可靠。



PoW协议不敢太频繁地发布区块的原因在于：如果太快发布区块，区块中的数据重复验证6次（若干次）立即永久封存地区块中，一旦发生51%攻击，恶意的数据容易永久封存于区块中，所以PoW的系统的有效修复时间不敢太短。

相比而言，GHOST协议就没有这个问题了，因为在GHOST协议控制下， “区块发布太快” 和 “51%攻击持续性地控制主动权” 二者没有必然的关系，GHOST不是采用绝对算力优势获取主动权的协议。

上面是从安全性角度看问题，下面从性能的角度对比看看。公式（Throughput）交易能力：= Block Size * Block Generation Rate——这里GHOST的 Block Size和PoW差不多（严格地将稍微逊色一点，PoW长度是GHOST的最优解）， Block Generation Rate上GHOST远远胜于PoW（出于安全，PoW快不起来），所以，整体实验结果上看，GHOST的throughput相比于PoW有大幅的性能的提升。

Q3： 为什么GHOST能做到“区块发布太快” 和 “51%攻击持续性地控制主动权” 二者没有必然的关系？

GHOST协议的模型假设如下：

a. 攻击者会用全网大于等于51%的计算力进行攻击；

b. 大部分网络节点是被对等网络的诚信鼓励策略所推动的；

基于a,b可知：

c. 不诚信节点数目上占劣式。

d. 51%攻击发生时，不诚信节点计算力占优。

进一步：

d结合a可知：攻击链特征一：是最长的。

c结合b可知：攻击链特征二：被独立的。

GHOST协议是以包含子树数目最多为基本原则，而非最长链。

Q4： 更多信息

见Github开源社区，GHOST协议作为Ethereum项目的核心技术，以及第二代Blockchain中重要的一部分，代码已经被开源到了Github开源社区，包括C/C++，Go，Python等版本，地址：https://github.com/ethereum

欢迎关注“Aha实验室”微信公众号

参考

[1]. Nakamoto S. Bitcoin: A peer-to-peer electronic cash system[J]. 2008.

[2]. Sompolinsky Y, Zohar A. Secure high-rate transaction processing in bitcoin[C]//International Conference on Financial Cryptography and Data Security. Springer Berlin Heidelberg, 2015: 507-527.