如何内行地评价公链（一）从真正的不可能三角谈起

最近几期，Conflux 计划推出一系列的科普文章，从一些简单的技术原理开始，帮助你们辨别一些项目宣传的概念中，哪些概念是可能实现的，哪些概念若是要实现，是须要有妥协的。

在第一期，咱们从区块链的“不可能三角”谈起，谈一谈若是要追求极致的效率，究竟要牺牲什么。目前在区块链媒体中，有一个流传很广的概念叫“不可能三角”，即效率、安全、去中心化三者不可并存。和“不可能三角”出现一样频繁的概念，是“不可能三角”被公链某个项目打破。在一些媒体宣传 Conflux 的时候，也曾经使用过这个说法。

不过，Conflux 从未在官方宣称“打破不可能三角”，咱们认为这并非一个严谨的概念。只能说，这个概念被提出来的时候，尚未人把这三件事情同时作好，并无人经过严谨的分析证实它不可能。

今天，咱们来介绍另外一个不可能三角。不管一个区块链是公有链仍是联盟链，是 PoW 仍是 PoS, 是采用中本聪共识仍是 BFT 仍是其余的什么方式，都绕不开它。这个不可能三角包括三个目标。（为了便于理解，咱们避免采起严谨的形式化语言去定义它，而是大概描述一下想法与思路）

1. 所有节点同步与验证

在公链网络中，公链网络的正确性与安全性依赖于一些节点的背书。例如，在比特币或以太坊中，根据协议，每个矿工挖出区块时，要保证新区块和历史上的每个区块每笔交易都是正确的。也就是说，比特币矿工出块时，在为以前全部的区块进行正确性背书。在 EOS 中，超级节点经过签名对区块的正确性背书。咱们这里称为“参与共识的节点”。

“所有节点同步与验证”要求每个被确认的交易，都获得过全部参与共识的节点（攻击者除外）的同步与验证。

这个目标是和安全相关的。咱们想象一个场景，有一我的想经过伪造无效签名，制造非法交易，盗走你的资产。若是只有一小部分参与共识的节点同步和验证了这个交易，而其余节点不一样步这个交易，直接采信那一小部分节点的判断结果。若是这样的话，将一笔非法交易混入交易历史的可能性，就会高于每一个参与共识的节点都进行同步和验证。两者的安全性是不同的。

2. 超高吞吐率

最终确认交易的平均吞吐率超过 11000 TPS 称之为超高吞吐率。 （每笔交易的大小按 250 字节计）

3. 低带宽要求

对于每个参与共识的节点，网络带宽的最低配置要求不高于 20 Mbps (2.5 MB/s)。

这个目标是和去中心化相关的，参与的门槛越低，能参与共识的人就越多，越有利于去中心化。

以上就是这个不可能三角的三个目标。缘由理解起来也很简单，若是一个节点只有 20 Mbps 的带宽，那么每秒只能下载 2.5 MB 的数据，大约是 10000 笔交易。若是网络中最终确认交易的平均吞吐率超过 11000 TPS, 这个只有 20 Mbps 带宽的节点是没有能力同步和验证每一笔交易的。

那么面对这个困难，作出取舍的方案又有哪些呢？

1. 放弃全节点同步与验证

在这些方案中，Sharding 是一个很著名的解决方案。Sharding 方案的大致思路是，整个区块链在逻辑上分出若干个 Shard, 将没有关联、互不冲突的交易分到不一样的 Shard 中去, 每一个 Shard 由一部分矿工负责同步和验证。对于矿工来讲，不须要为其余 Shard 中的交易正确性负责。

Sharding 方案是一个提升吞吐率的思路，但这个思路牺牲了一部分的安全性。毕竟，若是有一我的想经过伪造签名，制造非法交易盗窃你的资产，全网中每个节点都帮你防范非法交易，和只有一小部分节点帮你防范非法交易，两者的安全程度是不一样的。不过，对于只是存个零花钱的帐户地址，相对于安全性，可能用户对交易成本更敏感。因此这一方向是很是有探索价值的。

但若是用 Sharding 方案下的 TPS 和别人全节点同步与验证下的 TPS 比，就很不科学了。

另一个思路是，经过零知识证实或可验证计算等密码学工具，容许一个节点没必要同步每个交易，只须要同步区块头及一些密码学的元素，也能够验证一个区块的 Merkle Root 是正确的。固然，这个思路上有不少坑须要去解决，若是有机会，咱们会写一篇文章展开讨论一下。

2. 放弃高 TPS

这里的放弃高 TPS，是指在现有的网络条件下，放弃 10000 TPS 以上的吞吐率。Conflux 保留了去中心化和安全性，就须要保留全节点同步与验证和低带宽要求，以实现家用网络条件也能够当矿工，每一笔交易都获得了每个矿工的验证。若是要保留这两点，效率是有天花板的。

3. 低带宽要求

在一些共识机制中，普通用户不参与对交易的同步与验证，而是经过一些方式选出少数特殊的节点来进行共识。这时，咱们能够假设每个参选的节点都准备了足够的计算机资源，例如更好的 CPU, 更大的硬盘, 更大的网络带宽。这时，也就不必将“最低配置要求”设的很低了。

下一次，若是您看到一个项目声称大于 10000 TPS，甚至是喊出无限可扩展的口号时，您就须要来看一下在这个不可能三角中，它放弃了哪一角。是放弃了第一点仍是第三点？若是是放弃第一点，项目是采用了 Sharding 方案？仍是作出了其余的修改？这种修改会不会带来安全性问题，如何解决？若是是放弃第三点，高 TPS 是否基于更高的网络带宽要求？仍是说在网络带宽无限的条件下无限可扩展？

---

顺便推荐一下咱们的线下活动～在本期Conflux Meetup（杭州站），咱们为你们邀请到了Conflux CTO伍鸣、Conflux研究总监杨光、TOP Network Co-founder & CEO Steve Wei来一块儿聊一聊《下一代公链和DApps生态前景》。
点击报名