共计 2221 个字符，预计需要花费 6 分钟才能阅读完成。
最近几期，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 生态前景》。点击报名
