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

路线B：优化KV数据库存储，如实现键值分离、hash索引的KV数据库等(BadgerDB、ParityDB) ，接入通用分布式数据库(MySQL)等；
路线C：优化Merkle树，交易ID作为版本、树结构稀疏化，如DiemJMT 。
根据公开信息，目前区块链产品中主流的MPT+LevelDB、JMT+RocksDB、MySQL等存储架构，没有能全部解决上述5个问题的方案，难以在支持多版本和可验证的同时，满足10亿级账户规模下的高性能、易扩展、低成本的业务要求。
04我们做到了什么？我们自研了一套区块链存储引擎LETUS(Log-structuredEfficientTrustedUniversalStorage) ，保证完整的可验证、多版本能力，既满足区块数据不可篡改、可追溯、可验证等要求，也提供对合约数据友好访问、存储规模可分片扩展，高性能低成本等特性。同时也满足通用性，统一管理区块数据、状态数据。

文章图片
LETUS在2022云栖大会发布4年前不敢想象的能力，现在具备了（以下数据为统一环境下的测试结果）：
01大规模：通过存储集群扩展支持十亿账户规模， TPS超过12万，交易平均时延低于150ms；
02高性能：存储层IO吞吐相比以太坊MPT+LevelDB等架构提升10~20倍， IO延迟降低90%以上。链平台在7x24高压力压测中，端到端TPS不随数据量增加而衰减；
03低成本：相比MPT+LevelDB架构，磁盘带宽减少95%、空间占用减少60%；相比于DiemJMT+RocksDB架构，磁盘带宽减少约60%、空间占用降低约40%；
04进一步降成本方案，供用户选用：
(a)针对区块数据容量与成本持续增长，提供智能控温分层存储能力，并应用于存证等业务降低约70%存储成本，同时也降低运维成本。
(b)针对状态数据的历史版本容量与成本持续增长，提供范围扫描的批量裁剪能力，实现历史版本状态数据的裁剪和后台空间回收，在十亿账户规模时，使用链原生存储可以减少近90%状态存储空间。
但这背后是一个技术架构的跨越，从下图左边的可验证数据结构+KV数据库架构，升级为现在的LETUS存储引擎，架构更简洁，系统更高效。

文章图片
如Alice给Bob转账，只需要写增量数据，不需要写入7个Merkle树节点，数据局部性更友好，如Alice和Bob的账户数据，按区块号有序，不再hash随机。
05怎么做到的？回顾这四年，主要经历的三个大的阶段。
阶段一：开源思路优化
第一年里，为了满足业务急迫诉求，我们需要在有限时间内，实现亿级账户规模和交易TPS 。先从已有系统入手，深度优化了状态树，基于开源MPT到自研FDMT ，同时调优RocksDB数据库、增加并发、提升介质性能。
一系列优化措施缓解了问题，但依然无法根本解决，例如数据规模增加后，写放大依然有几十倍，数据在底层存储里依然随机分布。
阶段二：自研存储引擎
为了能彻底解决上述所有问题，我们不得不重新思考存储引擎的设计。
核心设计
针对读写放大（问题1）、数据局部性（问题2）和性能（问题3），我们结合区块链特征，如可验证数据结构的读写行为、链上数据的多版本诉求、只追加和不可篡改等，重新设计存储引擎的架构分层、关键组件、索引数据结构：
根据区块链特征，我们根据可验证数据结构的读写行为、链上数据的多版本诉求，重新设计存储引擎的架构分层、关键组件、索引数据结构：