从Solana和DAG说起

早几天有社区的网友让我看一个项目,说跟DAG很像。作为DAG技术热心网友,跟DAG有关这点儿瞬间就吸引到我了。

这个项目叫Solana(后简称Sol)[1], 现在颇有名气。“TPS50000”,“以太杀手”,众多头衔确实很吸引眼球。对这些头衔,我的直觉并不感冒,因为片面追求高TPS(交易吞吐量)其实意义不大。因为之前也出现过许多所谓的“以太杀手”,往往以牺牲去中心化这个区块链最核心的设定为代价,其实也算不上经典意义的区块链了,从我的角度看来是舍本逐末了。这也是Qitmeer一直坚持在保证安全和去中心化的前提下追求扩容的经典区块链设定的原因。

回到Solana, 我更关心的是为什么会有社区朋友认为其像DAG,然后是通过哪些技术达到这么高的吞吐量,这些都是值得Qitmeer去学习以及改进的。

首先针对Sol与DAG有什么关系,我学习了下Sol的文档[7]以及白皮书[8],并加入Sol的技术社区和许多朋友交流下,我的结论是有关系但是也可以说没有关系。

要想说清两者的关系有必要介绍下Sol的历史证明(Proof of History,后简称PoH)[2]的分布式时钟机制。PoH可以说是Sol最大的技术亮点,也是Sol的TowerBFT[3]共识的基础。PoH其实借助了可验证延时函数(Verifiable Delay Function, VDF)[4]的思想,VDF简而言之就是一种无法进行并行化进行加速的函数。这个特性非常重要,比特币目前导致算力越来越集中也跟这个有关。众所周知,比特币的工作量证明(Proof of Work, 后简称PoW)就是CPU通过散列函数不断随机产生散列值,直到找到符合要求的散列值则代表挖矿成功。而这个过程可以并行化的,如果有多个CPU核心,则可以把任务平摊到每个核心上,这样挖矿效率可以大幅度提升。这也是为什么GPU以及更专业的FPGA或者ASIC的挖矿效率能远大于家用CPU的原因。

这里还要补充一点就是如果任务本身是可以分割的,例如上述PoW,则提高N倍CPU的计算频率和N个CPU核心并行计算对于任务加速来说是等效的。但是现在CPU的集成度已经逼近物理极限了,相信很多人都感知到,摩尔定律(Moore’s law)早就失效了。除了集成度的原因,更大的制约CPU频率升高的是CPU的散热问题。CPU的热功耗设计(Thermal Design Power,TDP)[5]规定了CPU能产生的最大热量,而增加单位计算频率会产生指数级的热量,所以CPU的单核计算频率很难做到很高,这样性能卓越的专业CPU和普通的家用CPU在计算能力上不会有太大的差别。这也是为什么处理器往多核方向发展以及GPU开始往通用计算GPU(GPGPU)[6]发展的原因。

从上述分析可知,如果函数能防止并行化,则可以极大地降低GPU或ASIC等专业设备的计算优势,这样参与共识的设备门槛就会降低,更多的机器就能参与共识,奖励分配也更均匀,则可以实现更高程度的去中心化。而VDF就是这样的函数,Sol的PoH的就是一个非常简单的VDF,原理就是不断地递归计算SHA256散列,也就是说上一个散列函数结果是下一个散列函数的输入,然后下个散列函数的输出又是下下个散列函数的输入,不断重复下去。值得说明一点儿的是PoH并不是严格意义上的VDF,VDF是要求生成的难度远大于验证的难度,但是从PoH的原理可知,生成和验证都是计算散列,难度并没有差别。Sol给出的解释[9]是,生成PoH只能用CPU单核,但是验证PoH可以利用GPU多核并行加速,挺有趣的思路。

从PoH的原理我们可以知道,这样的函数是无法进行并行化加速的,因为在上一个结果还没计算出来是无法进行下一步的计算的,所以无论有多少个CPU,同时只能有一个工作。细心的朋友可能已经发现了PoH其实生成的就是一条散列链,而区块链其实也是一条散列链,或者我们可以认为其上PoH产生的是一条简化的区块链。从区块链的特性也可以知道,虽然挖矿是可以通过并行优化加速,但是区块还是得一个一个的产生,无论多快的ASIC矿机,也没法并行挖出多个连续的区块。

既然我们把PoH产生散列链理解为一条简化的区块链,对于我们理解Sol就方便多了。这里我们首先要理解什么是共识,简单点说就是解决全网交易排序的问题,只是这个最后排序的结果要通过某种机制让全网的节点都能认可,也就是达成共识了。最简单能想到的方案就是用交易的时间戳排序,但是这里有两个问题,一是大家的本地时钟可能会有误差,二是节点可能作弊,故意把交易的时间修改得比真实的靠前。虽然用全局的原子钟可以解决第一个问题,但是仍然无法解决第二个问题。所以假设有这么一个全局时钟,而且节点还没法伪造交易时间,那交易排序的问题其实就解决了。这样的共识成本极低,把所有交易发给全网任意一个节点,该节点根据交易的时间排序好,然后打成区块然后分发给全网就好了。试想下,假设比特币的每个节点都是诚实的,然后全网指定一个节点专门负责打包区块,区块满了就广播给所有节点,那比特币的交易速度得多快。

Sol之所以快,也就是因为PoH就是这么一个无法伪造的“全局时钟”。这里的“全局时钟”是有缺陷的,因为PoH只是解决了交易无法伪造的问题,但是全网节点时钟的误差问题是没法解决的,只能最大程度的降低这种误差。比如说之前提到的VDF就是减少了不同节点的计算速度的差异,这样PoH链的产生速度差异大致能在一个可控的范围之内,然后再加上Sol的TowerBFT共识,只要保证全网活跃节点的2/3投票[3]能达成共识即可。

不得不承认Sol的想法是很好的,也确实能提升交易吞吐量,而且这种提升是实实在在的去中心化,但是2/3投票能达成共识仍然是比较理想的设定,因为这是基于全网节点的单核计算能力差别不会太大。Sol白皮书的评估是30%,个人持保留意见。不过观察到Sol官网上对于验证节点的非常高的启动门槛[10]要求,也觉得可能有一定的道理。毕竟达到这个门槛的可以说都是比较专业的机器了,单核配置应该差别不会太大。但是这就带来了一个去中心化的两难,从协议的设计来说验证节点的加入和退出都是自由的,所以是Sol确实是去中心化的非许可链,这和同样可以代理投票的EoS的DPoS有本质的不同,因为DPoS的验证节点选举是许可制的。过高的门槛其实增加了节点的中心化程度,而且如果全网的节点都是高配置,那TPS高是很正常的,PoH贡献的比例有待观察。此外,TowerBFT虽然提高了节点计算速度差异而导致PoH时钟的误差的容差度,但是TowerBFT的投票机制会导致大量的与真实交易无关的投票交易,所以表面上TPS很高,但是其中包含真实交易的有效TPS的比例并不高[11]。综上,TPS50000应该是基于比较理想的实验环境,从官网上的数据来看,可以稳定在1000左右[1],是非常合理的数据,其实也是非常不错的成绩了。

说到这里,丝毫没有提到DAG。也确实,我当初也疑惑,Solana跟DAG的关系是怎么来的。这也是为什么我最开始说Sol跟DAG有关系也没关系的原因。但是对Qitmeer以及DAG关注的朋友应该知道,区块链和DAG并没有本质的区别。区块链是简化的区块链,而DAG是泛化的区块链。既然PoH链可以认为是一条简化区块链,那如果存在多条PoH链并存在彼此引用呢?那不就是DAG了么,那Sol从存在这样的PoH多链么?事实上Sol确实存在,白皮书[8]里面就提到了这样的情况。

0924034831973.png)

PoH的目的是给交易的确定时间,但是PoH确定交易时间并不是生成一个固定刻度的时间,而是通过将交易框定在两个相邻的散列生成时间的区间内。如上面的表格所示,A节点正在计算参数为hash2a的散列,在结果hash3a计算出来之前,接收到来自B的散列hash1b,则交易就可以确定hash1b肯定是在hash3a之前。我们把上面的表格转化一下,很明显就是DAG。DAG的结构优势也很明显,相对于单一的PoH链可以给交易提供更精确的时间。

至此,总算是从我个人的角度解答了Qitmeer社区朋友Solana和DAG的关系,一家之言,或许是过度解读。DAG仅仅是PoH多链融合的一个副产品,Sol高TPS最核心的还是PoH这种全局分布式时钟降低了共识成本。在分享Qitmeer的MeerDAG共识时我就提到过,DAG其中的一个亮点就是因为DAG是一种数据结构,工作在非常底层,因此有较强的可扩展性(extensibility), 可以和多种扩容(Scalability)技术融合,Sol的PoH的多链融合的DAG恰好就是很好的例证。Qitmeer一直关注着VDF技术的发展,Sol的PoH提供了很好的启发,为Qitmeer后续改进又提供多了一种思路。

参考文献

[1] https://solana.com/
[2] Proof of History: A Clock for Blockchain | by Anatoly Yakovenko | Solana | Medium
[3] Tower BFT: Solana’s High Performance Implementation of PBFT | by Anatoly Yakovenko | Solana | Medium
[4] https://eprint.iacr.org/2018/601.pdf
[5] Thermal design power - Wikipedia
[6] General-purpose computing on graphics processing units - Wikipedia
[7] https://docs.solana.com/
[8] https://solana.com/solana-whitepaper.pdf
[9] Readme remove mentions of verifiable delay functions · Issue #388 · solana-labs/solana · GitHub
[10] Validator Requirements | Solana Docs
[11] Rekt - Spotlight on Solana

2 Likes

前排学习