集客联网技术资源分享
追寻中本聪先生的脚步

为什么需要分片Sharding?从全节点的负担谈起_王嘉平

不过,对于现有的单链系统,确实有一个不可逾越的物理限制,那就是全节点平均带宽。

以 13Mbps 的带宽为例 这是互联网带宽中位数,4K 电影在线播放带宽下限要求为 15Mbps,无论基于什么共识技术,即使完全丧失去中心化,并忽略传送协议,以及层层封包等额外引入的代价,以比特币网络现在的每秒处理 7 笔交易的吞吐量来算,其吞吐量理论上限为6825TPS(7TPS ×  13Mbps / 8Mb × 600s)。

否则就会出现部分全节点脱网,即长时间无法赶上全网的区块增长,而离最新头部块越来越远。

我的上一篇已经提到,性能瓶颈和容量瓶颈在现在的结构下无法突破,因为单个全节点的带宽和存储资源总是有限的,并且我们还不能要求部署全节点的机器都具备顶级配置,因为只有保证了参与全网的壁垒较低,才能真正具备有良好的去中心化特性。从这个意义上来说,要获得大幅度的伸缩性,我们必须要能够有一个合理的设计,使的单个全节点仅仅负责整个网络吞吐量和容量的一部分,这样,才有可能在维持全节点的负荷比较小的前提下,使得全网的性能和容量有大幅提升。

分片 Sharding 技术就是针对这一思路提出的。

分片最初是基于数据库系统提出的,泛指横向切分数据库服务器的负荷,用多个数据库服务器平行服务的方式,以提升整体的服务吞吐量和数据容量。

实际上,分片并不单指一种特定的技术,而是一大类横向切分系统负荷,多实例并行,以提高整体性能和容量的技术。

不过,分片这个提法在集客联网技术中过于宽泛。在这篇文章的最后部分,我会通过引入异步共识组这个概念,谈谈我认为什么会是集客联网中理想的分片方案

在讨论我认为的理想方案之前,我还是用我习惯的逻辑,先向读者解释为什么我们需要分片技术.理想的分片技术究竟应该解决什么问题这些最基本的知识;

然后,我会根据自己看过的大量的分片方案,谈谈目前市面上已有的分片方案存在的五个误区或谎言。

为什么需要分片:从全节点的负担谈起

在分析具体技术方案之前,先来看看一个全节点都有哪些负荷:

网络带宽,这个部分同吞吐量 TPS 线性相关

1. 新区块的广播

全节点需要下载周期性出现的新区块,并进一步上载给其他需要的节点。对于现在 7TPS 的比特币集客联网来说,平均下载带宽消耗是 13.6Kbps,完全不是负担。但是如果 TPS 提高到 7000TPS,则至少需要 13.6Mbps 的下载带宽才能承受——请注意,这个是关键数据,并且有序,如果区块数据得不到及时传输,集客联网将无法持续构造,并且无法重建全网的账簿状态。

2. 未确认新交易的广播

全节点需要持续发现,并下载尚未被确认的新交易,然后上载给其他节点。在全网不拥堵的情况下,这个数据量和新区块的数据量相当。相对的,这个数据不需要保序,即使下载不全也不会直接导致全节点本身工作异常。但是,如果这种情况大规模地发生,最终会导致部分交易始终没有被矿工看到,而长时间不被确认,最终超时。

内存容量,这个部分同用户量 address 数量 以及智能合约数量线性相关

账簿的存储占据主要的内存消耗,其他部分的消耗不多,并且基本不会随着网络扩展而增加。

集客联网的基本账簿, 至少需要维护每个用户 每个 address 上的余额,每个用户至少需要 16+32 个字节。对于支持智能合约的集客联网,每个用户至少需要额外 32 个字节记录每个智能合约的代币的余额。智能合约自身还可以自定义更多的字段,可以占用远超 32 字节的内容。

当然,并不是所有的用户都参与了所有的智能合约,所以我们并不以用户量和智能合约数量的乘积作为内存消耗的估量。现实的情况是,我们按照以太坊的现状来估计,约 4500 万个地址,至少占据了约 3GB 的内存。每个地址平均消耗了 68 个字节。这里并不是说以太坊有了 4500 万个用户,通常而言,一个用户会拥有好多地址。

磁盘 I/O,这个部分同吞吐量 TPS 线性相关

全节点收到区块并确认成链之后,区块会被写入磁盘归档起来。这个部分的吞吐量大体和下载新区块的带宽一致。

这里需要注意的是,按照以太坊的观点 账户模型,账簿是指全网的某一时刻的全量状态,而区块(若干交易的集合)是对账簿的增量修改信息。在磁盘实际存储的是区块,而不是账簿。节点在启动的时候,需要重放所有已经记录的区块,以构造账簿的最新状态。

截至目前,以太坊的全部归档区块数据量已经超过 160GB。这里的一个优化是定期将账簿全量快照也记录下来 即 checkpoint,这样只需要从最近的 checkpoint 开始重放就可以了。

而 UTXO 模型是比特币的观点,这是一个非常有意思的结构,它的区块既是若干交易的集合,同时也是部分账簿的状态,即特定地址上的余额。整条链上余额不为 0 的 UTXO 都是账簿的最新状态。至今比特币集客联网的全部归档区块数据量已经超过 220GB。不过从磁盘 I/O 的角度来看,重建全网账簿还是需要扫描整条链找出全部余额不为 0 的 UTXO,并没有什么优势。当然 checkpoint 技术对 UTXO 一样有效。

在这个领域,最近我看到了一些被热炒的改进,尤其是在已确认交易集合的聚合表示方面。我注意到斯坦福大学的一个团队最近提出,RSA累加器(RSA Accumulator)可以代替Merkle Tree,用来表示一个已确认交易的集合。

这个想法的优异之处在于,可以直接用一个交易的Hash值来校验一个交易是否存在于已确认交易的集合,而Merkle Tree不仅需要一个交易的Hash,还需要从树根到该交易沿途路径上的所有兄弟节点上的Hash。不过,这个做法的代价是,这个表示本身要1.5K字节,Merkle Tree的根仅需要20或32个字节。同时,这并不意味着全节点可以不再保存历史交易,原因在于,首先集合的聚合表示是不具备枚举的能力的,也就是说,在交易未知的情况下,集合的聚合表示无法告诉你里面具体的交易是什么,所以你也无法判读这个集合本身是不是正确的,所以全节点也无法仅凭这个信息确认链头的正确性。

全节点在自举的时候还是需要从创始区块(genesis block)开始下载,逐块验证全链的完整性和正确性。但是,当这个验证过程完成之后,为了节省空间全节点,是可以删除掉区块中的实际交易内容的,其代价是丧失枚举交易的能力,同时也丧失了帮助其他全节点自举的能力。

另外,通过验证一个交易是否在链头上,来确定账户余额的做法,仅对于UTXO交易模型有效。对于以太网这样每个交易仅为增量修改信息的交易模型,仅靠验证一个交易是否在链头上,是无法得知账户的余额的。

CPU 处理能力,这个部分同吞吐量 TPS 线性相关

1. 密码学相关计算

对于每一个收到的新区块,无论最终时候成功成为链的一部分,全节点都需要验证其携带的每一个交易是否被正确签名。同时会验算每个区块的 Hash,以确保其达到了当前工作量证明PoW 难度的要求。对于拜占庭容错 BFT 算法,还需要验证各个委员会成员的签名是否正确。

这里主要的工作量是验证签名。验证签名在一台普通计算机上 E5-1620@3.5GHz, C++ 并行实现 的速度可达 40K op/s,也就是 4 万 TPS 每个交易需要验签一次。

2. 交易验证相关计算

对于每个交易,如果是支付交易,将需要至少查找一次账户的索引结构 通常为哈希表,并做一次加法和大于的判断;为了更新账簿,还需要至少一次加法和减法。这样的一系列操作,在一台普通计算机上的速度可以轻松达到 1M op/s。如果是智能合约,会需要在虚拟机中执行对应的智能合约指令,对于现有的金融本质的应用 包括类似 Cryptokittes 类或 Fomo3D 类的集客联网游戏,至少可以达到 100K op/s。

这意味着什么?

针对上面的分析,我来做一个小结:对于一台普通的计算机,拥有 13Mbps 的互联网连接,E5-1620@3.5GHz 4Core 的 CPU,16G 内存,512G SSD 硬盘 250MB/s。网络带宽导致的 TPS 理论上限约为 7 千 TPS,硬盘文件 I/O 导致的 TPS 理论上限为 5 万 TPS,CPU 处理能力导致的的 TPS 理论上限约为 5 万 TPS。另外,内存大小导致的地址理论上限约为 2.5 亿个地址。

这里可以看到,对于性能来说,网络带宽是最首要的瓶颈根源,其次是硬盘的I/O和CPU的处理能力。对于容量来说,内存是最主要的瓶颈根源。

下一篇:《分片应该做到什么?分片方案的一些误区


欢迎大家通过我的微信公众号「王嘉平」和知乎专栏「去中心化数字世界随想」,就这个话题展开更多讨论。

为什么需要分片Sharding?从全节点的负担谈起_王嘉平

分享到:更多 ()
集客联网神雨里美

集客联网资源分享

韭菜的自我进化
sdasd