如何内行地评价公链（一）：从真正的不可能三角谈起—2019.3.1
最近几期，Conflux 计划推出一系列的科普文章，从一些简单的技术原理开始，帮助大家辨别一些项目宣传的概念中，哪些概念是可能实现的，哪些概念如果要实现，是需要有妥协的。
在第一期，我们从区块链的“不可能三角”谈起，谈一谈如果要追求极致的效率，究竟要牺牲什么。目前在区块链媒体中，有一个流传很广的概念叫“不可能三角”，即效率、安全、去中心化三者不可并存。和“不可能三角”出现同样频繁的概念，是“不可能三角”被公链某个项目打破。在一些媒体宣传 Conflux 的时候，也曾经使用过这个说法。
不过，Conflux 从未在官方宣称“打破不可能三角”，我们认为这并不是一个严谨的概念。只能说，这个概念被提出来的时候，还没有人把这三件事情同时做好，并没有人通过严谨的分析证明它不可能。
今天，我们来介绍另一个不可能三角。无论一个区块链是公有链还是联盟链，是 PoW 还是 PoS, 是采用中本聪共识还是 BFT 还是其他的什么方式，都绕不开它。这个不可能三角包括三个目标。（为了便于理解，我们避免采取严谨的形式化语言去定义它，而是大概描述一下想法与思路）
- 全部节点同步与验证
在公链网络中，公链网络的正确性与安全性依赖于一些节点的背书。例如，在比特币或以太坊中，根据协议，每一个矿工挖出区块时，要保证新区块和历史上的每一个区块每笔交易都是正确的。也就是说，比特币矿工出块时，在为之前所有的区块进行正确性背书。在 EOS 中，超级节点通过签名对区块的正确性背书。我们这里称为“参与共识的节点”。
“全部节点同步与验证”要求每一个被确认的交易，都得到过所有参与共识的节点（攻击者除外）的同步与验证。
这个目标是和安全相关的。我们想象一个场景，有一个人想通过伪造无效签名，制造非法交易，盗走你的资产。如果只有一小部分参与共识的节点同步和验证了这个交易，而其他节点不同步这个交易，直接采信那一小部分节点的判断结果。如果这样的话，将一笔非法交易混入交易历史的可能性，就会高于每个参与共识的节点都进行同步和验证。二者的安全性是不一样的。
- 超高吞吐率
最终确认交易的平均吞吐率超过 11000 TPS 称之为超高吞吐率。 （每笔交易的大小按 250 字节计）
- 低带宽要求
对于每一个参与共识的节点，网络带宽的最低配置要求不高于 20 Mbps (2.5 MB/s)。
这个目标是和去中心化相关的，参与的门槛越低，能参与共识的人就越多，越有利于去中心化。
以上就是这个不可能三角的三个目标。原因理解起来也很简单，如果一个节点只有 20 Mbps 的带宽，那么每秒只能下载 2.5 MB 的数据，大约是 10000 笔交易。如果网络中最终确认交易的平均吞吐率超过 11000 TPS, 这个只有 20 Mbps 带宽的节点是没有能力同步和验证每一笔交易的。
那么面对这个困难，做出取舍的方案又有哪些呢？
- 放弃全节点同步与验证
在这些方案中，Sharding 是一个很著名的解决方案。Sharding 方案的大体思路是，整个区块链在逻辑上分出若干个 Shard, 将没有关联、互不冲突的交易分到不同的 Shard 中去, 每个 Shard 由一部分矿工负责同步和验证。对于矿工来说，不需要为其他 Shard 中的交易正确性负责。
Sharding 方案是一个提高吞吐率的思路，但这个思路牺牲了一部分的安全性。毕竟，如果有一个人想通过伪造签名，制造非法交易盗窃你的资产，全网中每一个节点都帮你防范非法交易，和只有一小部分节点帮你防范非法交易，二者的安全程度是不同的。不过，对于只是存个零花钱的账户地址，相对于安全性，可能用户对交易成本更敏感。所以这一方向是非常有探索价值的。
但如果用 Sharding 方案下的 TPS 和别人全节点同步与验证下的 TPS 比，就很不科学了。
另外一个思路是，通过零知识证明或可验证计算等密码学工具，允许一个节点不必同步每一个交易，只需要同步区块头及一些密码学的元素，也可以验证一个区块的 Merkle Root 是正确的。当然，这个思路上有很多坑需要去解决，如果有机会，我们会写一篇文章展开讨论一下。
- 放弃高 TPS
这里的放弃高 TPS，是指在现有的网络条件下，放弃 10000 TPS 以上的吞吐率。Conflux 保留了去中心化和安全性，就需要保留全节点同步与验证和低带宽要求，以实现家用网络条件也可以当矿工，每一笔交易都得到了每一个矿工的验证。如果要保留这两点，效率是有天花板的。
- 放弃低带宽要求
在一些共识机制中，普通用户不参与对交易的同步与验证，而是通过一些方式选出少数特殊的节点来进行共识。这时，我们可以假设每一个参选的节点都准备了足够的计算机资源，例如更好的 CPU, 更大的硬盘, 更大的网络带宽。这时，也就没必要将“最低配置要求”设的很低了。
下一次，如果您看到一个项目声称大于 10000 TPS，甚至是喊出无限可扩展的口号时，您就需要来看一下在这个不可能三角中，它放弃了哪一角。是放弃了第一点还是第三点？如果是放弃第一点，项目是采用了 Sharding 方案？还是做出了其他的修改？这种修改会不会带来安全性问题，如何解决？如果是放弃第三点，高 TPS 是否基于更高的网络带宽要求？还是说在网络带宽无限的条件下无限可扩展？