公链作为区块链世界的基础设施中的基石，极大地影响着上层应用的效率、成本以及用户体验。如果从比特币开始算起，公链一路走来已经 10 年了，但至今为止还远未到技术收敛的阶段。在这第 11 个年头，细数一下已经被大家广为关注的方向和一些尚未被大家关注的方向。
性能难点1——速度
性能问题从区块链最开始就被大家意识到，直观的体验就是速度，也就是一个交易多久能被确认。最初这个瓶颈是共识算法，Nakamoto 共识最初 10 分钟一次出块，平均交易确认延迟是 5 分钟。而后以太坊将出块间隔降到了 15 秒，期望平均交易确认延迟是 7 秒。但真的是 7 秒就能被确认了吗？其实并不是。这时，性能的瓶颈变成了吞吐量，虽然交易确认延迟是 7 秒，但是大多数交易在排队，除非给出很高的交易手续费来插队。
吞吐量之所以受到限制，是因为普通全节点的带宽，也就是互联网的平均带宽。这个限制和共识算法是本质无关的。这一点终于被很多团队认识到，避免设计出一些只能运行在本地数据中心内部的高吞吐量系统。要突破这个限制，唯一的出路是切分吞吐量，让不同的全节点负责不同的部分。分片（Sharding）就是完成这种切分的有效方案，当然未来也可能有其它的方案。
在吞吐量问题解决之后，速度上的体验又会回到交易确认延迟这个事情上。当然这个时候的要求就不是要达到几十秒，而是应用会希望可以达到更低的延迟，比如 1 秒甚至以下。计算机系统，在同一个层面的设计上，吞吐量和延迟通常会有矛盾。例如区块链这种分批交易确认方式，一个批次越大，也就是 block 越大，吞吐量就会越大，而这时出块的间隔就需要更长，也就使得交易确认延迟变大。
公链的 Layer 1 技术将工作量切分之后，吞吐量将获得几个数量级的提升，然而其交易确认延迟却没有显着的改善。我自己的预判是，这里才是 Layer 2 的侧链真正发挥作用的地方，而不是像现在很多侧链项目宣称的那样，所要攻克的问题几乎和 Layer 1 要攻克的问题完全一样。
性能难点2——容量
容量问题受到关注就少了很多。其实容量问题包含两个方面，一个是内存中的账簿状态，每个用户的余额以及智能合约的状态，另一个是磁盘中归档的历史交易记录。
比特币几乎没有被扩展用户状态，并且吞吐量又很低，所以在那个时候，这个容量完全不是问题。但是在吞吐量提升，并且 DApp 开始逐渐繁荣之后，容量问题便逐渐凸显出来。和吞吐量类似，这个问题之所以受到限制，是因为普通全节点的内存和硬盘的容量限制所致。这个限制也是和共识算法本质无关的。
突破这个限制，唯一的出路也是切分容量的负担，让不同的全节点负责不同部分的账簿状态以及交易归档。分片（Sharding）就是完成这种切分的有效方案，当然未来也可能有其他的方案。账簿状态压缩，历史交易压缩都是很好的实践，可以和分片方案一起用。但是这些方向始终受限于单个全节点的本地资源限制，能提高几倍已经是非常不易，而设计良好的分片系统可以提高成百上千倍。
性能难点3——分片
我最初来到这个领域，看其中的性能问题。按说分片是非常靠谱并且直接的解决方案。在区块链以外的计算系统，哪个不是通过划分工作量，分散到不同的计算单元，从而获得几个数量级的性能提升？GPU、Mapreduce、CDN 哪个商用高性能体系不是用这样的架构？当然最初是源自数据库领域。然而，当时圈子里的人却和我说分片是个伪科学，是一个不切实际的方案，无法为区块链扩容提供任何帮助。我当时是惊了，这区块链有什么特殊之处，使得切分工作量变得不可行了？
最后我发现了问题所在。并不是区块链有什么特别之处，而是有个叫 Z 的项目，做了一个不完整的分片方案，仅仅切分了交易处理的工作量，而交易仍旧需要广播给全网所有节点，每个节点仍旧需要维护全网的账簿状态，每个交易的对账簿状态更新计算，所有节点也都仍要算一遍。这意味着完全没有实现分片的好处，也没有吞吐量和容量的提升，同时还引入了额外的开销，导致其实际性能比不分片的系统还差。
但是，这个系统总体上安全性是没问题的，继承了之前共识算法的安全特性，所以他们的论文会被 ACM CCS 这样专注计算和通讯安全的会议接受，倒也不令人惊讶。而真正在性能和容量上有突破的工作，为什么要找安全领域专家去评审，难道不应该是找性能领域的专家去评审吗？例如 ACM SIGCOMM、OSDI、SOSP、NSDI 那样的网络系统的会议。当然，在那个空气币都飚上天的年份，出来用这样的技术方案，发个币毫无压力。
所以这里还是要给分片技术正名，虽然有相当难度，但这是正途。
同时隐私有两个方面的内涵，一是用户的状态，例如用户的账户余额，二是用户之间的活动记录，例如 A给B转了X个币。监管和隐私也许可以在这两个方面分开找到权衡的点。