作者 | 螞蟻鏈 LETUS 技術(shù)負責人 田世坤

寫在前面 文字產(chǎn)生以前，結(jié)繩記事是人類用來存儲知識和信息的主要方式。此后，從竹簡、紙張的發(fā)明，到工業(yè)時代的磁盤存儲，再到信息時代的數(shù)據(jù)庫，存儲方式不斷革新，“存力”不斷提高。

11 月 3 日，在 2022 云棲大會上，螞蟻鏈歷經(jīng) 4 年技術(shù)攻關(guān)與測試驗證的區(qū)塊鏈存儲引擎 LETUS（Log-structured Efficient Trusted Universal Storage）正式發(fā)布。
這一款面向區(qū)塊鏈可信數(shù)據(jù)存儲的技術(shù)產(chǎn)品，不僅用來解決當前螞蟻鏈及區(qū)塊鏈產(chǎn)業(yè)的規(guī)?；l(fā)展問題，也面向 Web3 時代提供“可信存力”支撐。
我們認為，隨著大量的數(shù)據(jù)和數(shù)字資產(chǎn)在數(shù)字化世界里流轉(zhuǎn)，可信數(shù)據(jù)的“存力”將如同電力網(wǎng)絡(luò)的承載力一樣重要。
本文希望通過對 LETUS 的深入技術(shù)解讀，回答讀者們普遍關(guān)心的關(guān)鍵問題：LETUS 是什么？主要解決哪些問題？為什么堅持用“可驗證結(jié)構(gòu)”？為什么要自研？以及未來要走向何處？ 背景是什么？

從 2009 年序號為 0 的創(chuàng)世塊誕生至今已過去十多年，“中本聰”依然神秘，但區(qū)塊鏈技術(shù)的發(fā)展卻因為公鏈、token、開源的推動，沒有絲毫神秘感。

經(jīng)過幾代技術(shù)演進，在比特幣的 UTXO 模型基礎(chǔ)上誕生了應(yīng)用更為廣泛、支持可編程智能合約的區(qū)塊鏈技術(shù)：通過密碼學、共識算法、虛擬機、可信存儲等技術(shù)，多個參與方執(zhí)行相同的“指令”，來完成同一個業(yè)務(wù)邏輯，如賬戶轉(zhuǎn)賬，或者合約調(diào)用，維護不可篡改和不可偽造的業(yè)務(wù)數(shù)據(jù)。

簡單講，可將這類賬本數(shù)據(jù)庫，看作一個去中心化防作惡、防篡改的復(fù)制狀態(tài)機，所執(zhí)行的是智能合約描述的業(yè)務(wù)邏輯，而狀態(tài)機通過日志 (區(qū)塊數(shù)據(jù)）產(chǎn)生新的狀態(tài)（狀態(tài)數(shù)據(jù)）：

區(qū)塊數(shù)據(jù)：包括交易、回執(zhí)、世界狀態(tài) Root Hash 等信息，和數(shù)據(jù)庫系統(tǒng)中的日志類似，但是塊之間由 Hash 錨定防篡改，并且不會刪除。（區(qū)塊數(shù)據(jù)記錄的是區(qū)塊鏈上發(fā)生的每一筆交易，如：Alice 向 Bob 轉(zhuǎn)賬 xx）

狀態(tài)數(shù)據(jù)：記錄賬戶、資產(chǎn)、業(yè)務(wù)合約數(shù)據(jù)等狀態(tài)信息，和數(shù)據(jù)庫系統(tǒng)中表數(shù)據(jù)類似，需要實現(xiàn)可驗證可追溯。（狀態(tài)數(shù)據(jù)記錄的是區(qū)塊鏈上每個賬戶或智能合約的當前狀態(tài)，如：Bob 賬戶剩余 xx）

鏈上數(shù)據(jù)的特點可以總結(jié)為以下三個：

持續(xù)增長：從創(chuàng)世塊開始，賬本數(shù)據(jù)隨交易持續(xù)增長，保留周期長；

多版本：交易修改狀態(tài)數(shù)據(jù)產(chǎn)生新版本，系統(tǒng)提供歷史版本查詢和驗證功能；

可驗證：交易和賬戶狀態(tài)通過 Merkle 根哈希（Merkle Root Hash）錨定在區(qū)塊頭，通過 SPV（simple payment verification，簡單支付證明）提供存在性證明；

區(qū)塊鏈應(yīng)用通過可驗證數(shù)據(jù)結(jié)構(gòu)（Authenticated Data Structure，如 Merkle tree）實現(xiàn)可驗證和可追溯。我們認為，Web3“存力”一個非常重要的要素是可驗證，而今天我們看到的區(qū)塊鏈存儲瓶頸大多來源于可驗證結(jié)構(gòu) ADS（如 Merkle tree）的低效存取和查詢，這正是螞蟻鏈 LETUS 重點攻克的難題。

我們要什么？

隨著時間推移和鏈上交易的增加，對存儲容量的要求也不斷增長，隨之而來的是區(qū)塊數(shù)據(jù)存儲成本的大幅提升；與此同時，鏈上狀態(tài)數(shù)據(jù)規(guī)模也持續(xù)增加，可驗證數(shù)據(jù)結(jié)構(gòu)持續(xù)膨脹，導(dǎo)致交易性能隨賬戶規(guī)模提升和歷史狀態(tài)數(shù)據(jù)增加而持續(xù)下降。

2019 年，螞蟻鏈上線了一個供應(yīng)鏈金融業(yè)務(wù)，大家特別興奮。但是，這種興奮并沒有維持多久，隨著程序跑的時間越來越長，問題慢慢暴露出來。

供應(yīng)鏈金融是面向 ToB 的，不像 ToC 端隨時都有數(shù)據(jù)，可能會在某個時刻（比如每天晚上）有一筆狀態(tài)數(shù)據(jù)非常大的交易進來，跑了一個星期后發(fā)現(xiàn)性能越來越慢。

鏈平臺 TPS 的衰減和存儲直接相關(guān)，而與共識、虛擬機都無關(guān)，隨著業(yè)務(wù)合約持續(xù)寫入數(shù)據(jù)，存儲性能大幅衰減。

如果要在技術(shù)上長時間支持億級賬戶規(guī)模、每天能穩(wěn)定支撐億級交易量，存儲的規(guī)模和性能問題必須要攻克。

期間，團隊也曾試過各種技術(shù)方法對他進行優(yōu)化，得到一些緩解。但多次嘗試之后發(fā)現(xiàn)，隨著數(shù)量增加而出現(xiàn)的性能衰減，是一個繞不開的瓶頸，需要從本質(zhì)上解決。

我們需要從問題表象分析背后的原因。

區(qū)塊鏈應(yīng)用通過可驗證數(shù)據(jù)結(jié)構(gòu)實現(xiàn)可驗證和可追溯，但是可驗證數(shù)據(jù)結(jié)構(gòu)會帶來讀寫放大（問題 1）和數(shù)據(jù)局部性（問題 2）。

而存儲系統(tǒng)為了實現(xiàn)數(shù)據(jù)管理，需要對數(shù)據(jù)分頁 / 分層、排序，如 KV 數(shù)據(jù)庫基于 LSM-tree 將數(shù)據(jù)分層有序存儲，而 MySQL 之類的數(shù)據(jù)庫將數(shù)據(jù)分頁，也會基于 B-tree 數(shù)據(jù)結(jié)構(gòu)來排序索引。

業(yè)界現(xiàn)有的實現(xiàn)方式，大多采用基于 LSM 架構(gòu)的通用 Key-Value 數(shù)據(jù)庫，在數(shù)據(jù)庫之上運行一個獨立 Merkle 樹來實現(xiàn)可驗證，如：

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

Diem：JMT(Jellyfish Merkle Tree)+RocksDB

背后的核心矛盾為：

01 Merkle 樹每次狀態(tài)數(shù)據(jù)修改，即使只改一個 KV，也需要從葉子節(jié)點到根節(jié)點，每一層節(jié)點都重新編碼后，寫到 KV 數(shù)據(jù)庫，例如上圖中 Alice 給 Bob 轉(zhuǎn)賬，需要寫入 Merkle 樹的 2 個葉子節(jié)點和 3 個中間節(jié)點，最壞情況需要寫入數(shù)十個中間節(jié)點； 02 Merkle 樹的節(jié)點的 key 完全隨機 (如對內(nèi)容算 hash，再以 hash 為 key)，數(shù)據(jù)局部性（data locality）非常不友好，如 RocksDB 里為了讓 Level 內(nèi) sst 文件有序，即使沒有垃圾依然需要層層進行數(shù)據(jù)壓實（compaction），從而消耗了大部分的磁盤讀寫帶寬； 03 數(shù)據(jù)規(guī)模越大，Merkle 樹本身的層數(shù)越多，需要額外寫入的 key-value 越多，DB 里的數(shù)據(jù)量越多，后臺數(shù)據(jù)管理的代價越大（如 compaction 流量），消耗大量的磁盤和 CPU 資源。

除此之外，吞吐、延時等存儲性能（問題 3）、持續(xù)增長下的存儲成本（問題 4）、單機存儲下的規(guī)模瓶頸（問題 5）也都是需要解決的問題。

面臨什么挑戰(zhàn)？

在過去幾年的快速發(fā)展中，區(qū)塊鏈的業(yè)務(wù)場景對交易吞吐量和響應(yīng)時間要求越來越高，很多技術(shù)也被推動迭代發(fā)展，如 PBFT、HoneyBadger、MyTumbler 等高性能共識算法，BTN 等網(wǎng)絡(luò)基礎(chǔ)設(shè)施，JIT 加持的 WASM 虛擬機、以及高效的并行執(zhí)行技術(shù)。

但比較而言，存儲的性能對區(qū)塊鏈平臺整體性能影響非常大。對面向 2C 場景的數(shù)字藏品類業(yè)務(wù)（如鯨探，需支持秒殺），交易 TPS 與延時要求極為苛刻；而對需要在鏈上保存大量數(shù)據(jù)的存證類業(yè)務(wù)，大容量存儲帶來的成本又十分可觀。

要支撐業(yè)務(wù)的長期可持續(xù)發(fā)展，我們歸納出區(qū)塊鏈存儲面臨的核心挑戰(zhàn)：

規(guī)模：業(yè)務(wù)賬戶規(guī)模可達數(shù) 10 億，狀態(tài)數(shù)據(jù)和歷史版本規(guī)模分別需要支撐到十億、千億級；

性能：轉(zhuǎn)賬交易需求可達十萬級 TPS、百毫秒級延時，要求性能不能受制于單機瓶頸，數(shù)據(jù)規(guī)模持續(xù)增長下性能不衰減；

成本：隨著交易增長，存儲容量持續(xù)增加，存儲空間占用、節(jié)點間帶寬占用居高不下。業(yè)務(wù)持續(xù)增長要求低成本存儲。

這些問題在行業(yè)內(nèi)很普遍。業(yè)界技術(shù)路線主要分三條：

路線 A：弱化可驗證可追溯，如 HyperLedger Fabric 1.0 開始不支持可驗證和多版本，保存讀寫集、只持久化最新版本狀態(tài)數(shù)據(jù)；

路線 B：優(yōu)化 KV 數(shù)據(jù)庫存儲，如實現(xiàn)鍵值分離、hash 索引的 KV 數(shù)據(jù)庫等 (BadgerDB、ParityDB)，接入通用分布式數(shù)據(jù)庫 (MySQL) 等；

路線 C：優(yōu)化 Merkle 樹，交易 ID 作為版本、樹結(jié)構(gòu)稀疏化，如 Diem JMT。

根據(jù)公開信息，目前區(qū)塊鏈產(chǎn)品中主流的 MPT + LevelDB、JMT + RocksDB、MySQL 等存儲架構(gòu)，沒有能全部解決上述 5 個問題的方案，難以在支持多版本和可驗證的同時，滿足 10 億級賬戶規(guī)模下的高性能、易擴展、低成本的業(yè)務(wù)要求。

我們做到了什么？

我們自研了一套區(qū)塊鏈存儲引擎 LETUS(Log-structured Efficient Trusted Universal Storage)，保證完整的可驗證、多版本能力，既滿足區(qū)塊數(shù)據(jù)不可篡改、可追溯、可驗證等要求，也提供對合約數(shù)據(jù)友好訪問、存儲規(guī)?？煞制瑪U展，高性能低成本等特性。同時也滿足通用性，統(tǒng)一管理區(qū)塊數(shù)據(jù)、狀態(tài)數(shù)據(jù)。

4 年前不敢想象的能力現(xiàn)在具備了（以下數(shù)據(jù)為統(tǒng)一環(huán)境下的測試結(jié)果）

01 大規(guī)模：通過存儲集群擴展支持十億賬戶規(guī)模，TPS 超過 12 萬，交易平均時延低于 150ms； 02 高性能：存儲層 IO 吞吐相比以太坊 MPT + LevelDB 等架構(gòu)提升 10~20 倍，IO 延遲降低 90% 以上。鏈平臺在 7x24 高壓力壓測中，端到端 TPS 不隨數(shù)據(jù)量增加而衰減；

03 低成本：相比 MPT + LevelDB 架構(gòu)，磁盤帶寬減少 95%、空間占用減少 60%；相比于 Diem JMT + RocksDB 架構(gòu)，磁盤帶寬減少約 60%、空間占用降低約 40%； 04 進一步降成本方案，供用戶選用：

a.針對區(qū)塊數(shù)據(jù)容量與成本持續(xù)增長，提供智能控溫分層存儲能力，并應(yīng)用于存證等業(yè)務(wù)降低約 70% 存儲成本，同時也降低運維成本。

針對狀態(tài)數(shù)據(jù)的歷史版本容量與成本持續(xù)增長，提供范圍掃描的批量裁剪能力，實現(xiàn)歷史版本狀態(tài)數(shù)據(jù)的裁剪和后臺空間回收，在十億賬戶規(guī)模時，使用鏈原生存儲可以減少近 90% 狀態(tài)存儲空間。

但這背后是一個技術(shù)架構(gòu)的跨越，從下圖左邊的可驗證數(shù)據(jù)結(jié)構(gòu) +KV 數(shù)據(jù)庫架構(gòu)，升級為現(xiàn)在的 LETUS 存儲引擎，架構(gòu)更簡潔，系統(tǒng)更高效。

如 Alice 給 Bob 轉(zhuǎn)賬，只需要寫增量數(shù)據(jù)，不需要寫入 7 個 Merkle 樹節(jié)點，數(shù)據(jù)局部性更友好，如 Alice 和 Bob 的賬戶數(shù)據(jù)，按區(qū)塊號有序，不再 hash 隨機。

怎么做到的？

圖片回顧這四年，主要經(jīng)歷的三個大的階段。

階段一：開源思路優(yōu)化

第一年里，為了滿足業(yè)務(wù)急迫訴求，我們需要在有限時間內(nèi)，實現(xiàn)億級賬戶規(guī)模和交易 TPS。先從已有系統(tǒng)入手，深度優(yōu)化了狀態(tài)樹，基于開源 MPT 到自研 FDMT，同時調(diào)優(yōu) RocksDB 數(shù)據(jù)庫、增加并發(fā)、提升介質(zhì)性能。

一系列優(yōu)化措施緩解了問題，但依然無法根本解決，例如數(shù)據(jù)規(guī)模增加后，寫放大依然有幾十倍，數(shù)據(jù)在底層存儲里依然隨機分布。

階段二：自研存儲引擎

為了能徹底解決上述所有問題，我們不得不重新思考存儲引擎的設(shè)計。

核心設(shè)計

針對讀寫放大（問題 1）、數(shù)據(jù)局部性（問題 2）和性能（問題 3），我們結(jié)合區(qū)塊鏈特征，如可驗證數(shù)據(jù)結(jié)構(gòu)的讀寫行為、鏈上數(shù)據(jù)的多版本訴求、只追加和不可篡改等，重新設(shè)計存儲引擎的架構(gòu)分層、關(guān)鍵組件、索引數(shù)據(jù)結(jié)構(gòu)：

根據(jù)區(qū)塊鏈特征，我們根據(jù)可驗證數(shù)據(jù)結(jié)構(gòu)的讀寫行為、鏈上數(shù)據(jù)的多版本訴求，重新設(shè)計存儲引擎的架構(gòu)分層、關(guān)鍵組件、索引數(shù)據(jù)結(jié)構(gòu)：

將可驗證特性下推到存儲引擎內(nèi)部，由內(nèi)置的 Version-based（區(qū)塊號）多版本 Merkle 樹提供可驗證可追溯，并且直接操作文件，從而縮短 IO 路徑；

01 將可驗證特性下推到存儲引擎內(nèi)部，由內(nèi)置的 Version-based（區(qū)塊號）多版本 Merkle 樹提供可驗證可追溯，并且直接操作文件，從而縮短 IO 路徑； 02 多版本 Merkle 樹的 Node 聚合為 page，提升磁盤友好性，page 存儲采用 Delta-encoding 思想避免 in-place 更新（結(jié)合 Bw-tree 思路），狀態(tài)數(shù)據(jù)修改時主要保存增量，定期保存基線，從而減少寫放大，也減少了空間占用； 03 為 page 存儲實現(xiàn) Version-based 的存儲與檢索，索引 page 都按區(qū)塊號有序?qū)懭?、在索引文件里有序總局，核心?shù)據(jù)結(jié)構(gòu)為 B 樹變種，從而實現(xiàn)有序數(shù)據(jù) locality； 04 利用區(qū)塊鏈場景數(shù)據(jù)的追加寫、Immutable 特點，架構(gòu)上采用 Log-Structured 思想，通過日志文件來組織數(shù)據(jù)； 05 數(shù)據(jù)與索引分離，數(shù)據(jù)按區(qū)塊號有序?qū)懭霐?shù)據(jù)文件，通過異步 IO、協(xié)程并發(fā)等提升系統(tǒng)并發(fā)度，索引多模，區(qū)塊 & 狀態(tài)通用，除 Merkle 樹支持狀態(tài)數(shù)據(jù)，實現(xiàn)有序 B 樹支持區(qū)塊數(shù)據(jù)； 06 當前最新版本 Merkle 樹優(yōu)先在內(nèi)存里緩存或者全部緩存，鏈上合約執(zhí)行時，如果存在則直接讀取，不需要訪問 page 來重放，從而加速合約執(zhí)行。

基于些核心設(shè)計，實現(xiàn)了成本降低的同時性能提升，鏈平臺交易 TPS、延時等性能指標不會隨著數(shù)據(jù)規(guī)模的提升而衰減。

降成本

雖然存儲資源占用大幅降低后，但是鏈上數(shù)據(jù)依然面臨持續(xù)增長帶來的高成本問題（問題 4）。

基于 LETUS 架構(gòu)的后臺數(shù)據(jù)治理框架，我們能很方便的擴展實現(xiàn)數(shù)據(jù)遷移 / 壓縮 / 垃圾回收等治理策略，基于這些策略，為用戶提供進一步降成本能力，并針對自己的業(yè)務(wù)特點來選擇使用：

（1）智能控溫分層存儲：存儲介質(zhì)按照性能、成本分層，通過智能控溫調(diào)度數(shù)據(jù)在不同介質(zhì)的分布量，將冷數(shù)據(jù)后臺自動遷移到廉價介質(zhì)（如 NAS），降低存儲整體成本，并實現(xiàn)容量擴展，不受單盤空間限制。

（2）范圍掃描的批量裁剪：對于歷史版本 Merkle 樹和狀態(tài)對象，基于版本有序性與內(nèi)置 Merkle 樹，讓用戶可以指定目標區(qū)塊號范圍裁剪，通過 Page 邊界掃描，批量索引與數(shù)據(jù)裁剪、垃圾回收實現(xiàn)存儲空間釋放，進一步降低狀態(tài)數(shù)據(jù)成本。

規(guī)模擴展

針對問題 5，LETUS 采用分布式存儲架構(gòu)，實現(xiàn)單個共識參與方計算和存儲分離，計算層和存儲層可分別部署獨立集群，通過高性能網(wǎng)絡(luò)通訊框架進行數(shù)據(jù)讀寫訪問。

為了對海量狀態(tài)數(shù)據(jù)進行靈活的數(shù)據(jù)分片，并且保證各個區(qū)塊鏈的參與方 hash 計算的一致性，將數(shù)據(jù)切片為 256 個最小存儲單元（msu），并將一個或者多個 msu 構(gòu)成一個狀態(tài)數(shù)據(jù)分片（partition），將所有數(shù)據(jù)分片調(diào)度到多個物理機器。從而實現(xiàn)規(guī)模彈性擴展，解決了單機存儲的容量瓶頸和帶寬瓶頸。

階段三：生產(chǎn)落地

為了全面落地鋪開的同時讓業(yè)務(wù)平穩(wěn)運行，能夠開著飛機換引擎，在這幾年的研發(fā)過程里，我們充分準備、循序漸進的分階段落地：

2021 年 5 月，基于 LETUS 存儲引擎的區(qū)塊數(shù)據(jù)冷熱分層，在版權(quán)存證業(yè)務(wù)灰度上線，存儲成本降低 71%，解決容量瓶頸并降低運維成本。

2021 年 8 月，基于 LETUS 存儲引擎的狀態(tài)數(shù)據(jù)，在數(shù)字藏品平臺“鯨探”雙寫灰度上線，并成功支撐秒殺場景；

2022 年 2-6 月，LETUS 引擎的歷史狀態(tài)數(shù)據(jù)裁剪、存儲服務(wù)架構(gòu)升級等生產(chǎn) ready，在數(shù)字藏品和版權(quán)存證等業(yè)務(wù)全面落地，并從灰度雙寫切為單寫；LETUS 單寫意味著對硬件資源要求大幅下降，我們將“鯨探”生產(chǎn)環(huán)境的云資源全面降配，降配后鏈平臺性能水位提升 200%，同時存儲成本下降 75%。

總結(jié)與展望

螞蟻一直堅持“成熟一個開放一個”的技術(shù)戰(zhàn)略。同樣的，LETUS 不只為螞蟻鏈定制，也同樣給其他聯(lián)盟鏈、公鏈提供高性能、低成本的支持。

螞蟻鏈堅持技術(shù)自研，確保在共識協(xié)議、智能合約、網(wǎng)絡(luò)傳輸、存儲引擎、跨鏈技術(shù)、區(qū)塊鏈隱私計算等領(lǐng)域處于全球領(lǐng)先水平。我們始終認為，堅持技術(shù)自主研發(fā)是建立長期可持續(xù)競爭力的關(guān)鍵。

在“可信存力”這條賽道上，我們也需要為進一步的技術(shù)壁壘提前布局，如合約結(jié)構(gòu)化查詢語言，為鏈上合約實現(xiàn)結(jié)構(gòu)化 + 可驗證的查詢能力, 提升開發(fā)者體驗；Fast-Sync 與節(jié)點多形態(tài)，提升組網(wǎng)效率和節(jié)點成本靈活性；以及 Web3 等潛在的技術(shù)生態(tài)。

編輯：黃飛