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

异步共识组 Asynchronized Coeus Zones_王嘉平

可以说,以伸缩性为目标的公链研发项目,其方案中如果没有分片的设计,都是不切实际的,在未来的实际应用中必将面对性能瓶颈和容量瓶颈,至少会遭遇这两个瓶颈中的一个。

由于分片这个术语本身太过于宽泛,我想在下面引入异步共识组 Asynchronized Coeus Zones 这个概念来,大家讨论一下理想的分片设计究竟应该是什么样的。

异步共识组由多个同质的.功能上完全一致.地位上也完全平等,并逻辑上尽量隔离的独立共识系统的实例所构成,他们并行工作,分摊全网的吞吐压力,分摊全网状态的维护工作。

  • 具备独立的相对稳定的节点集合,逻辑上不要求一个节点参与到多个共识组。
  • 具备独立的账簿,承载全网的一部分用户 组内用户。各个共识组的组内用户没有交集。
  • 具备独立的 Chain of Blocks,仅记录已经确认的和组内用户相关的交易。
  • 具备独立的非阻塞的出块过程,各个组之间没有任何同步的需要 例如,需要锁定特定资源。
  • 具备独立的未确认交易集合,仅有和组内用户相关的未确认交易会被暂存。
  • 具备独立的出块候选或竞争机制,矿工仅限于组内竞争,和其他组的矿工无直接竞争关系。
  • 具备独立的 Gossip 网络,完成区块和未确认交易的广播,不波及其他共识组的节点。

异步共识组中每一个共识组采用具体的共识算法可以是 PoW/PoS,也可以是 BFT 类算法,或这些算法的改进。异步共识组的设计是如何让他们完全独立地并行工作,由于各个共识组在 IT 资源的消耗上是互相独立的,那么全网的吞吐性能和账簿容量将随着全网共识组的数量增加而线性增加,而参与其中的全节点的工作压力依旧是单个共识组的负荷。

异步共识组是共识算法中立的,并不限定具体的在各个分片中采用的共识算法。有很多团队在研究和改进共识算法,无论共识算法被改进到什么程度,任何已知的共识算法或者是今后的改进版本,都可以被应用在异步共识组这个技术架构之中,从而得几个数量级的性能和容量的提升。

假设我们用比特币PoW 算法,用同样的配置参数 1MB 块,10 分钟出块间隔 作为共识组的共识算法,对于一个具有 1024 个共识组的网络,全网将获得 7000 多 TPS 的吞吐性能。

分片的全节点按照一台普通的计算机来算,在 13Mbps 的互联网连接.E5-1620@3.5GHz的CPU.16G 内存.SSD 硬盘 250MB/s 的情况下,全网将具备等效的 13Gbps 带宽.16TB 内存.4096 个 Core 的计算能力,以及 250GB/s 的 I/O 能力,用来承载所有用户的账簿和 DApp 的状态,以及其中涉及的计算。

而对于每个共识组里面的每个节点,它们所负担的通讯.计算和存储的压力,仅同运行一个比特币系统的全节点的负荷相当。无论全网扩张到多大的程度,网络中的单个参与者始终不会有明显増大的负担。

异步共识组的挑战有哪些?

异步共识组是一个理想方式的模型,不仅概念简单,而且可以完美突破全网的性能瓶颈和容量瓶颈,实现高伸缩性的集客联网系统,并且对去中心化程度没有任何的牺牲。

但是,这个模型要成为切实可行的方案,正如上文提到的,需要让这样的一个系统正确工作并保障安全性。这里需要两个方面的设计巧思:

  1. 如何正确高效地完成跨共识组的交易;
  2. 如何保障每个共识组的安全性。

只有,解决了这两个挑战,才能使得异步共识组系统能够正确安全地工作,释放其强大的性能和容量,打破所谓的「不可能三角」,服务于大体量的集客联网应用DAPP

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


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


异步共识组 Asynchronized Coeus Zones

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

集客联网资源分享

韭菜的自我进化
sdasd