如何破解Web3的「存力」难题？

作者 | 蚂蚁链 LETUS 技术负责人 田世坤写在前面 文字产生以前，结绳记事是人类用来存储知识和信息的主要方式。此后，从竹简、纸张的发明，到工业时代的磁盘存储，再到信息时代的数据库，存储方式不断革新，“存力”不断提高。
11 月 3 日，在 2022 云栖大会上，蚂蚁链历经 4 年技术攻关与测试验证的区块链存储引擎 LETUS（Log-structured Efficient Trusted Universal Storage）正式发布。
这一款面向区块链可信数据存储的技术产品，不仅用来解决当前蚂蚁链及区块链产业的规模化发展问题，也面向 Web3 时代提供“可信存力”支撑。
我们认为，随着大量的数据和数字资产在数字化世界里流转，可信数据的“存力”将如同电力网络的承载力一样重要。
本文希望通过对 LETUS 的深入技术解读，回答读者们普遍关心的关键问题：LETUS 是什么？主要解决哪些问题？为什么坚持用“可验证结构”？为什么要自研？以及未来要走向何处？ 背景是什么？

从 2009 年序号为 0 的创世块诞生至今已过去十多年，“中本聪”依然神秘，但区块链技术的发展却因为公链、token、开源的推动，没有丝毫神秘感。

经过几代技术演进，在比特币的 UTXO 模型基础上诞生了应用更为广泛、支持可编程智能合约的区块链技术：通过密码学、共识算法、虚拟机、可信存储等技术，多个参与方执行相同的“指令”，来完成同一个业务逻辑，如账户转账，或者合约调用，维护不可篡改和不可伪造的业务数据。

简单讲，可将这类账本数据库，看作一个去中心化防作恶、防篡改的复制状态机，所执行的是智能合约描述的业务逻辑，而状态机通过日志 (区块数据）产生新的状态（状态数据）：

区块数据：包括交易、回执、世界状态 Root Hash 等信息，和数据库系统中的日志类似，但是块之间由 Hash 锚定防篡改，并且不会删除。（区块数据记录的是区块链上发生的每一笔交易，如：Alice 向 Bob 转账 xx）

状态数据：记录账户、资产、业务合约数据等状态信息，和数据库系统中表数据类似，需要实现可验证可追溯。（状态数据记录的是区块链上每个账户或智能合约的当前状态，如：Bob 账户剩余 xx）

链上数据的特点可以总结为以下三个：

持续增长：从创世块开始，账本数据随交易持续增长，保留周期长；

多版本：交易修改状态数据产生新版本，系统提供历史版本查询和验证功能；

可验证：交易和账户状态通过 Merkle 根哈希（Merkle Root Hash）锚定在区块头，通过 SPV（simple payment verification，简单支付证明）提供存在性证明；

区块链应用通过可验证数据结构（Authenticated Data Structure，如 Merkle tree）实现可验证和可追溯。我们认为，Web3“存力”一个非常重要的要素是可验证，而今天我们看到的区块链存储瓶颈大多来源于可验证结构 ADS（如 Merkle tree）的低效存取和查询，这正是蚂蚁链 LETUS 重点攻克的难题。

我们要什么？

随着时间推移和链上交易的增加，对存储容量的要求也不断增长，随之而来的是区块数据存储成本的大幅提升；与此同时，链上状态数据规模也持续增加，可验证数据结构持续膨胀，导致交易性能随账户规模提升和历史状态数据增加而持续下降。

2019 年，蚂蚁链上线了一个供应链金融业务，大家特别兴奋。但是，这种兴奋并没有维持多久，随着程序跑的时间越来越长，问题慢慢暴露出来。

供应链金融是面向 ToB 的，不像 ToC 端随时都有数据，可能会在某个时刻（比如每天晚上）有一笔状态数据非常大的交易进来，跑了一个星期后发现性能越来越慢。

链平台 TPS 的衰减和存储直接相关，而与共识、虚拟机都无关，随着业务合约持续写入数据，存储性能大幅衰减。

如果要在技术上长时间支持亿级账户规模、每天能稳定支撑亿级交易量，存储的规模和性能问题必须要攻克。

期间，团队也曾试过各种技术方法对他进行优化，得到一些缓解。但多次尝试之后发现，随着数量增加而出现的性能衰减，是一个绕不开的瓶颈，需要从本质上解决。

我们需要从问题表象分析背后的原因。

区块链应用通过可验证数据结构实现可验证和可追溯，但是可验证数据结构会带来读写放大（问题 1）和数据局部性（问题 2）。

而存储系统为了实现数据管理，需要对数据分页 / 分层、排序，如 KV 数据库基于 LSM-tree 将数据分层有序存储，而 MySQL 之类的数据库将数据分页，也会基于 B-tree 数据结构来排序索引。

业界现有的实现方式，大多采用基于 LSM 架构的通用 Key-Value 数据库，在数据库之上运行一个独立 Merkle 树来实现可验证，如：

以太坊：MPT(Merkle Patricia Tree)+LevelDB

Diem：JMT(Jellyfish Merkle Tree)+RocksDB

背后的核心矛盾为：

01
Merkle 树每次状态数据修改，即使只改一个 KV，也需要从叶子节点到根节点，每一层节点都重新编码后，写到 KV 数据库，例如上图中 Alice 给 Bob 转账，需要写入 Merkle 树的 2 个叶子节点和 3 个中间节点，最坏情况需要写入数十个中间节点；
02
Merkle 树的节点的 key 完全随机 (如对内容算 hash，再以 hash 为 key)，数据局部性（data locality）非常不友好，如 RocksDB 里为了让 Level 内 sst 文件有序，即使没有垃圾依然需要层层进行数据压实（compaction），从而消耗了大部分的磁盘读写带宽；
03
数据规模越大，Merkle 树本身的层数越多，需要额外写入的 key-value 越多，DB 里的数据量越多，后台数据管理的代价越大（如 compaction 流量），消耗大量的磁盘和 CPU 资源。

除此之外，吞吐、延时等存储性能（问题 3）、持续增长下的存储成本（问题 4）、单机存储下的规模瓶颈（问题 5）也都是需要解决的问题。

临什么挑战？

在过去几年的快速发展中，区块链的业务场景对交易吞吐量和响应时间要求越来越高，很多技术也被推动迭代发展，如 PBFT、HoneyBadger、MyTumbler 等高性能共识算法，BTN 等网络基础设施，JIT 加持的 WASM 虚拟机、以及高效的并行执行技术。

但比较而言，存储的性能对区块链平台整体性能影响非常大。对面向 2C 场景的数字藏品类业务（如鲸探，需支持秒杀），交易 TPS 与延时要求极为苛刻；而对需要在链上保存大量数据的存证类业务，大容量存储带来的成本又十分可观。

要支撑业务的长期可持续发展，我们归纳出区块链存储面临的核心挑战：

规模：业务账户规模可达数 10 亿，状态数据和历史版本规模分别需要支撑到十亿、千亿级；

性能：转账交易需求可达十万级 TPS、百毫秒级延时，要求性能不能受制于单机瓶颈，数据规模持续增长下性能不衰减；

成本：随着交易增长，存储容量持续增加，存储空间占用、节点间带宽占用居高不下。业务持续增长要求低成本存储。

这些问题在行业内很普遍。业界技术路线主要分三条：

路线 A：弱化可验证可追溯，如 HyperLedger Fabric 1.0 开始不支持可验证和多版本，保存读写集、只持久化最新版本状态数据；

路线 B：优化 KV 数据库存储，如实现键值分离、hash 索引的 KV 数据库等 (BadgerDB、ParityDB)，接入通用分布式数据库 (MySQL) 等；

路线 C：优化 Merkle 树，交易 ID 作为版本、树结构稀疏化，如 Diem JMT。

根据公开信息，目前区块链产品中主流的 MPT + LevelDB、JMT + RocksDB、MySQL 等存储架构，没有能全部解决上述 5 个问题的方案，难以在支持多版本和可验证的同时，满足 10 亿级账户规模下的高性能、易扩展、低成本的业务要求。

我们做到了什么？

我们自研了一套区块链存储引擎 LETUS(Log-structured Efficient Trusted Universal Storage)，保证完整的可验证、多版本能力，既满足区块数据不可篡改、可追溯、可验证等要求，也提供对合约数据友好访问、存储规模可分片扩展，高性能低成本等特性。同时也满足通用性，统一管理区块数据、状态数据。

4 年前不敢想象的能力现在具备了（以下数据为统一环境下的测试结果）

01
大规模：通过存储集群扩展支持十亿账户规模，TPS 超过 12 万，交易平均时延低于 150ms；02
高性能：存储层 IO 吞吐相比以太坊 MPT + LevelDB 等架构提升 10~20 倍，IO 延迟降低 90% 以上。链平台在 7x24 高压力压测中，端到端 TPS 不随数据量增加而衰减；

03
低成本：相比 MPT + LevelDB 架构，磁盘带宽减少 95%、空间占用减少 60%；相比于 Diem JMT + RocksDB 架构，磁盘带宽减少约 60%、空间占用降低约 40%；
04
进一步降成本方案，供用户选用：

a.针对区块数据容量与成本持续增长，提供智能控温分层存储能力，并应用于存证等业务降低约 70% 存储成本，同时也降低运维成本。

针对状态数据的历史版本容量与成本持续增长，提供范围扫描的批量裁剪能力，实现历史版本状态数据的裁剪和后台空间回收，在十亿账户规模时，使用链原生存储可以减少近 90% 状态存储空间。

但这背后是一个技术架构的跨越，从下图左边的可验证数据结构 +KV 数据库架构，升级为现在的 LETUS 存储引擎，架构更简洁，系统更高效。

如 Alice 给 Bob 转账，只需要写增量数据，不需要写入 7 个 Merkle 树节点，数据局部性更友好，如 Alice 和 Bob 的账户数据，按区块号有序，不再 hash 随机。

怎么做到的？

图片回顾这四年，主要经历的三个大的阶段。

阶段一：开源思路优化