#设计目标

  • 让公有区块链能够支持1000+TX/s的事务处理速度；
  • 在尽量不牺牲传统区块链安全性的基础上达成以上目标

#怎么干的

传统软件架构里面有一句经典台词

通过简单地增加另外一个间接层就可以解决软件的任何问题

zilliqa在整个系统的架构设计上充分的利用这一点来对传统的区块链进行改造。

一个假设

现有的公有区块链的节点规模已经远远超过了整个链进行安全交易所需的最小数目集

下面围绕这两个方面来展开描述zilliqa的软件架构设计

###如何提高链的事务吞吐量

一般来说提高系统事务吞吐量无非两种方法：

  1. 调高单个节点的处理速度；
  2. 将事务处理并行化；

zilliqa聪明的利用了之前提及的假设将整个区块链网络划分为若干个子网络独立的进行事务处理。以此来达到提高整个网络事务吞吐量的目的

zilliqa测试网（4 Shards, 2,400 Nodes）已经能够达到1389TX/s,是现有eth网络的100倍

PS：daglabs采用相同的思路来提高网络吞吐，但是它采用了在算法上比链更复杂的DAG结构来实现，这个在工程实现上没有zilliqa来得直观和有效

后面我们统一用共识组来指代zilliqa中的子网络

#共识组之间的共识

类似于大数据处理中的MapReduce算法，共识组是并行的Map处理单元。为了得到最终的结果也就是一条单一的区块链，我们需要一个Reduce过程。这个过程需要共识组之外的一个协调者来完成这个过程，zilliqa的解决方案是再增加一层管理网络。

这种架构风格熟悉传统分布式数据库的同学一定不会陌生：

  1. Raft/Paxos协议实现一个小的分布式元数据库，负责元数据存储以及分布式事务调度管理；
  2. 大量其它节点，负责具体数据的存储分布式索引的建立等等；

#zilliqa管理层网络

再一次引用

通过简单地增加另外一个间接层就可以解决软件的任何问题

现在zilliqa要解决的问题有：

  1. 如何产生管理层网络？
  2. 这个网络能不能抵抗女巫攻击？
  3. 这个网络会不会被少数人控制？
  4. 它是一个严格的去区中心化实现吗？

要解答上面问题其实都涉及到随机性以及多数人共识的问题：

  1. 这个管理层节点集合不能是固定不变的；
  2. 同时这个管理层节点集合是随机的不可预期的；
  3. 作为一个去中心化的组织，多数人的共识让这个组织显得更纯粹；

上面1，2两点保证了zilliqa管理层网络的流动性，避免了任何僵化组织都会面对的弊端：垄断和既得利益层作恶

zilliqa网络巧妙的通过一个独立的PoW1共识层算法来选举这个管理层网络。所有zilliqa节点都可以公平的通过PoW1挖矿进入管理层网络候选列表；

现在来解决管理层流动性的问题：

  1. zilliqa规定整个网络的拓扑不是固定不变的。每隔t时间间隔需要重新选举管理层网络，并且重新划分共识组；按照zilliqa白皮书这段时间称为DS-epoch；
  2. zilliqa预设了管理层网络的大小为n，它永远指向完成了PoW1挖矿算法的候选节点列表的前N个；
  3. 管理层网络候选列表是一个先进先出的FIFO队列，每个DS-epoch阶段开始zilliqa自动将header节点移除列表；

这里出现的PoW1以及后面出现的PoW2 指的是两种不同的PoW算法

zilliqa管理层网络是有leader的网络。默认最新加入的节点为当前DS-epoch的leader，同时zilliqa通过一个复议协议将作恶的leader投票出管理层；

#zilliqa共识组

如前所述共识组的划分也不是一直不变的，为了更好的抵御攻击提高随机性zilliqa再次拿起了PoW算法：

  1. 所有要参与共识组挖矿的节点，在每个DS-epoch阶段开始前要先完成一个额外的挖矿过程——PoW2挖矿
  2. 所有完成PoW2挖矿的节点，被提交到管理层网络。由管理层网络根据时间顺序分组；

共识组内部采用改进的PBFT共识协议，具体详情参看白皮书（p7）

#双花问题

所有分布式事务都是在解决事务的原子性问题，并行处理本质上和原子性是对立的两方面；zilliqa在解决这个问题上用了一个小的技巧，漂亮的解决了这个问题：

  1. 我们的目标是提高系统的事务处理能；
  2. 对于强调一致性的系统来说，单个用户的事务排队处理是一个完全能够接受的限制；
  3. 那么zilliqa就规定某个用户在一个特定的DS-epoch，它所有的事务都必须路由到同一个共识组处理

这样zilliqa将问题简化为在某个共识组内部如何解决双花问题

#zilliqa节点角色总结

  • 作为管理层节点
  • 作为管理层leader节点
  • 作为共识组节点
  • 作为共识组leader节点

zilliqa节点在每个DS-epoch随机的转换角色

#共识算法终结

  1. 产生管理层的共识算法PoW1
  2. 产生共识组的共识算法Pow2
  3. 共识组内部执行具体事务的改进版PBFT

#合约很重要

zilliqa的合约采用dataflow范式的语言编写，它不是图灵完备的

zilliqa认为区块链的计算更接近于传统的数据流处理程序，因此它的整个合约的计算更接近于Hadoop/MaxCompute(aliyun)的计算模型——所有节点都分阶段的参与计算的某个步骤，然后由某个节点来汇总结果。

注意zilliqa合约的计算是完全并行化的，这个与传统的eth合约完全不同。它能够充分利用网络的计算资源，来进行大批量的数据处理工作，这个是eth合约无法做到的。

PS：这部分还未看到实际代码，具体实现的细节需要进一步研究。这里还遗留了一些问题，例如：安全怎么保证，如何防止女巫节点串改中间数据等等？