首先是性能方面，性能问题从区块链最开始就被大家意识到，直观的体验就是速度，也就是一个交易多久能被确认。
最初这个瓶颈是共识算法，Nakamoto共识最初10分钟一次出块，平均交易确认延迟是5分钟。而后以太坊将出块间隔降到了15秒，期望平均交易确认延迟是7秒。但真的是7秒就能被确认了吗？其实并不是。
这时，性能的瓶颈变成了吞吐量，虽然交易确认延迟是7秒，但是大多数交易在排队，除非给出很高的交易手续费来插队。吞吐量之所以受到限制，是因为普通全节点的带宽，也就是互联网的平均带宽。这个限制和共识算法是本质无关的。很高兴这一点终于被很多团队认识到，避免设计出一些只能运行在本地数据中心内部的高吞吐量系统。
要突破这个限制，唯一的出路是切分吞吐量，让不同的全节点负责不同的部分。分片就是完成这种切分的有效方案，当然未来也可能有其它的方案。在吞吐量问题解决之后，速度上的体验又会回到交易确认延迟这个事情上。
当然这个时候的要求就不是要达到几十秒，而是应用会希望可以达到更低的延迟，比如1秒甚至以下。计算机系统，在同一个层面的设计上，吞吐量和延迟通常会有矛盾。
其次，便是容量问题，其实容量问题包含两个方面，一个是内存中的账簿状态，每个用户的余额以及智能合约的状态，另一个是磁盘中归档的历史交易记录。
比特币几乎没有被扩展用户状态，并且吞吐量又很低，所以在那个时候，这个容量完全不是问题。但是在吞吐量提升，并且DApp开始逐渐繁荣之后，容量问题便逐渐凸显出来。和吞吐量类似，这个问题之所以受到限制，是因为普通全节点的内存和硬盘的容量限制所致。
这个限制也是和共识算法本质无关的。突破这个限制，唯一的出路也是切分容量的负担，让不同的全节点负责不同部分的账簿状态以及交易归档。关于这点，很多人将希望寄托在了分片技术上，分片就是完成这种切分的有效方案，当然未来也可能有其他的方案。
账簿状态压缩，历史交易压缩都是很好的实践，可以和分片方案一起用。但是这些方向始终受限于单个全节点的本地资源限制，能提高几倍已经是非常不易，而设计良好的分片系统可以提高成百上千倍。交流请加笔者！
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。