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

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

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

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

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

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

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

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

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

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

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

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

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

我們要什么？

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

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

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

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

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

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

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

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

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

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

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

Diem：JMT(Jellyfish Merkle Tree)+RocksDB

背后的核心矛盾為：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們做到了什么？

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

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

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

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

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

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

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

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

怎么做到的？

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

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

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

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

階段二：自研存儲(chǔ)引擎

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

核心設(shè)計(jì)

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

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

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

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

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

降成本

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

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

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

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

規(guī)模擴(kuò)展

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

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

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

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

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

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

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

總結(jié)與展望

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

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

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

編輯：黃飛