#前言
最开始BTC定义了分布式记账系统这个区块链的最主要功能，然后ETHER将DAPP引入了进来。到现在为止我们都在如何提高DAPP的性能的道路上蹒跚前行，本文尝试从区块链底层算法的角度去诠释这个问题的本质以及给出几个有意思的解决方案。大家会看到现有的各种所谓的公有链3.0都是在这个思路上的一种自然延伸，当然有些做得很傻有些很聪明。
#关于一致性的传说
在说一致性之前，我们来侃侃分布式系统节最有名的CAP理论：
2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后，麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP。之后，CAP理论正式成为分布式计算领域的公认定理。
#CAP理论概述
一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
这里就不展开描述CAP理论了，进一步的细节可以看这里CAP
#区块链的CAP理论
和大多数人的直觉相反，传统的公有区块链（BTC，ETHER等）满足了CAP里面的一致性和分区容错性，在上图的位置恰好就是问号部分。
选择CP代表区块链的最初决策者认为：
- 区块链的分区情况是会频繁发生的；
- 相对于可用性，我们要用某种处理来补偿分区情况下引入的错误；
- 一致性没什么好说的啦，分布式记账没有一致性还搞毛线；
一个有趣的事实，我们在区块链上的交易最好要等待N个块的去人才能认为这个交易成功了。这个基于大多数人都知道的事实区块链会在链分叉的时候自动抛弃短的那条链。这个处理其实就是对分区恢复后的补偿操作。
我们得到的明显副作用就是我们在链上的交易可用性到了惨不忍睹的地步：现在以BTC/太坊交易越来越慢动，交易所转账不动就等待半个小时。
#区块链交易好龟毛
区块链由于选择CAP里面的CP天生自带龟毛光环。难道无救了？我们在说区块链慢的时候我们其实在说某个具体的用户的主观感受：
- 等待打包好慢啊；
- 还要等待N个块确认；
- 为啥出块速度这么慢？
我们先不讨论出块速度的问题，专心解决下等待打包的问题。
对于一个大的并发系统来说，我们解决低延迟的最好办法就是在不牺牲一致性的前提下通过并行处理的方式增加系统的吞吐量
为啥不能通过提高单点执行速度来提高整个网络的事务吞吐量，我能甩一筐🙄给你不？根据木桶理论，整个系统的性能天花板是由最短的那块木板决定的。对于一个去中心化自治的系统来说要求所有参与的节点都具有高配置无疑是一种错误的决策选择；另一些联盟链其实是牺牲了去中心化或者CAP里面里面的分区容错性来达到提高系统吞吐量的目的的。
多说一句
*** 从经济学上来说，一个脱了裤子放屁的系统也注定会被淘汰掉。抛开区块链的概念，我们来设想改进一家公司的工作效率：肯定是让更多的人动起来并行的做事，而不是反过来要求能做事的人加班996不行还要007，这样的公司已经离死亡不远了。 ***
废话了很多，下面来说说正事。在前面的限制条件下提高系统吞吐量的不二法则就是：增加块的大小 同时让网络 并行的处理打包
看过这篇的朋友可能马上就反应过来了：zilliqa/DAG 都是在提高网络的并行打包能力。
废话一句：BTC扩容富了好多人啊。
#to be continue
由于前面已经有专门文章分析zilliqa之类的并行处理网络，这里就不展开描述并行处理网络的实现了。 zilliqa它其实已经证明了在不改变CP的选择以及POW的工作量证明的前提下实现并行打包处理是可行的。
区块链网络是一个巨大的计算/存储资源，仅仅用来做分布式记账太浪费了。在释放并行记账能力的基础上，进一步放宽事务一致性的限制让巨大的计算资源服务于通用计算其实是一个很好的发展方向😆😆