架构师深度拆解：Web3 需要什么样的存储系统？( 二 ) 写在前面文字产生以前

供应链金融是面向ToB的，不像ToC端随时都有数据，可能会在某个时刻（比如每天晚上）有一笔状态数据非常大的交易进来，跑了一个星期后发现性能越来越慢。
链平台TPS的衰减和存储直接相关，而与共识、虚拟机都无关，随着业务合约持续写入数据，存储性能大幅衰减。
如果要在技术上长时间支持亿级账户规模、每天能稳定支撑亿级交易量，存储的规模和性能问题必须要攻克。
期间，团队也曾试过各种技术方法对他进行优化，得到一些缓解。但多次尝试之后发现，随着数量增加而出现的性能衰减，是一个绕不开的瓶颈，需要从本质上解决。
我们需要从问题表象分析背后的原因。
区块链应用通过可验证数据结构实现可验证和可追溯，但是可验证数据结构会带来读写放大（问题1）和数据局部性（问题2）。
而存储系统为了实现数据管理，需要对数据分页/分层、排序，如KV数据库基于LSM-tree将数据分层有序存储，而MySQL之类的数据库将数据分页，也会基于B-tree数据结构来排序索引。

文章图片
业界现有的实现方式，大多采用基于LSM架构的通用Key-Value数据库，在数据库之上运行一个独立Merkle树来实现可验证，如：
以太坊：MPT(MerklePatriciaTree)+LevelDB
Diem：JMT(JellyfishMerkleTree)+RocksDB
背后的核心矛盾为：
01Merkle树每次状态数据修改，即使只改一个KV ，也需要从叶子节点到根节点，每一层节点都重新编码后，写到KV数据库，例如上图中Alice给Bob转账，需要写入Merkle树的2个叶子节点和3个中间节点，最坏情况需要写入数十个中间节点；
02Merkle树的节点的key完全随机(如对内容算hash ，再以hash为key) ，数据局部性（datalocality）非常不友好，如RocksDB里为了让Level内sst文件有序，即使没有垃圾依然需要层层进行数据压实（compaction），从而消耗了大部分的磁盘读写带宽；
03数据规模越大， Merkle树本身的层数越多，需要额外写入的key-value越多， DB里的数据量越多，后台数据管理的代价越大（如compaction流量），消耗大量的磁盘和CPU资源。
除此之外，吞吐、延时等存储性能（问题3）、持续增长下的存储成本（问题4）、单机存储下的规模瓶颈（问题5）也都是需要解决的问题。
03面临什么挑战？在过去几年的快速发展中，区块链的业务场景对交易吞吐量和响应时间要求越来越高，很多技术也被推动迭代发展，如PBFT、HoneyBadger、MyTumbler等高性能共识算法， BTN等网络基础设施， JIT加持的WASM虚拟机、以及高效的并行执行技术。
但比较而言，存储的性能对区块链平台整体性能影响非常大。对面向2C场景的数字藏品类业务（如鲸探，需支持秒杀），交易TPS与延时要求极为苛刻；而对需要在链上保存大量数据的存证类业务，大容量存储带来的成本又十分可观。
要支撑业务的长期可持续发展，我们归纳出区块链存储面临的核心挑战：
规模：业务账户规模可达数10亿，状态数据和历史版本规模分别需要支撑到十亿、千亿级；
性能：转账交易需求可达十万级TPS、百毫秒级延时，要求性能不能受制于单机瓶颈，数据规模持续增长下性能不衰减；
成本：随着交易增长，存储容量持续增加，存储空间占用、节点间带宽占用居高不下。业务持续增长要求低成本存储。
这些问题在行业内很普遍。业界技术路线主要分三条：
路线A：弱化可验证可追溯，如HyperLedgerFabric1.0开始不支持可验证和多版本，保存读写集、只持久化最新版本状态数据；