鄧思佳 佟興 唐海波 張召 金澈清

摘要：作為一種去中心化的分布式賬本，區(qū)塊鏈被廣泛應(yīng)用于互不可信的多方之間共享數(shù)據(jù).相比于發(fā)展 多年的傳統(tǒng)數(shù)據(jù)庫(kù)，區(qū)塊鏈存在無(wú)法支持豐富查詢(xún)、對(duì)外提供查詢(xún)接口單一和查詢(xún)響應(yīng)慢的問(wèn)題.簡(jiǎn)單的 組織結(jié)構(gòu)和離散的存儲(chǔ)方式是限制交易數(shù)據(jù)表達(dá)的主要原因.為了彌補(bǔ)現(xiàn)有區(qū)塊鏈系統(tǒng)的不足，構(gòu)建抽象 模型、封裝易于使用的接口以及提升查詢(xún)效率是實(shí)現(xiàn)基于區(qū)塊鏈的高效應(yīng)用開(kāi)發(fā)的主要方式.鑒于此，提 出一種面向區(qū)塊鏈的通用數(shù)據(jù)管理中間件，具有如下特征：①支持自定義構(gòu)建數(shù)據(jù)模型，靈活地為交易數(shù) 據(jù)抽象新模型;②提供多種數(shù)據(jù)訪問(wèn)接口支持豐富查詢(xún)并采用同步緩存機(jī)制等優(yōu)化方式提升查詢(xún)效率; ③設(shè)計(jì)提前哈希計(jì)算和異步批處理策略?xún)?yōu)化交易的延遲和吞吐.提出的數(shù)據(jù)管理中間件已集成于開(kāi)源區(qū) 塊鏈CITA中，并通過(guò)實(shí)驗(yàn)驗(yàn)證其易用性與高效性.

關(guān)鍵詞：區(qū)塊鏈;數(shù)據(jù)管理;交易數(shù)據(jù);抽象模型

中圖分類(lèi)號(hào)：TP302?????? 文獻(xiàn)標(biāo)志碼：A?????? DOI： 10.3969/j.issn.1000-5641.2021.05.006

Blockchain-oriented data management middleware

DENG Sijia， TONG Xing， TANG Haibo， ZHANG Zhao， JIN Cheqing

（School of Data Science and Engineering， East China Normal University， Shanghai 200062， China）

Abstract： As a decentralized distributed ledger， blockchain technology is widely used to share data between untrusted parties. Compared with traditional databases that have been refined over many years， blockchains cannot support rich queries， are limited to single query interfaces， and suffer from slow response. Simple organizational structures and discrete storage limits are the main barriers that limit the expression of transaction data. In order to make up for the shortcomings of existing blockchain technology and achieve efficient application development， users can build abstract models， encapsulate easy-to-use interfaces， and improve the efficiency of queries. We also propose a general data management middleware for blockchain， which has the following characteristics：① Support for custom construction of data models and the flexibility to add new abstractions to transaction data;② Provide multiple data access interfaces to support rich queries and use optimization methods such as synchronous caching mechanisms to improve query efficiency;③ Design advance hash calculation and asynchronous batch processing strategies to optimize transaction latency and throughput. We integrated the proposed data management middleware with the open source blockchain CITA and verified its ease of use and efficiency through experiments. Keywords： blockchain; data management; transaction data; abstract model

收稿日期：2021-08-04

基金項(xiàng)目：國(guó)家自然科學(xué)基金（U1811264， U1911203， 6197215（2）

通信作者：張召，女，教授，博士生導(dǎo)師，研究方向?yàn)閰^(qū)塊鏈系統(tǒng)研發(fā)、海量數(shù)據(jù)管理與分析

E-mail： zhzhang@dase.ecnu.edu.cn

0引 言

在多方參與的交易、物流、金融服務(wù)等業(yè)務(wù)場(chǎng)景中，傳統(tǒng)集中式服務(wù)的弊端逐漸顯露，各個(gè)參與 系統(tǒng)較中心化，難以實(shí)現(xiàn)信息安全共享和跨機(jī)構(gòu)可信驗(yàn)證.區(qū)塊鏈作為一種去中心化、不可篡改、可 追溯的分布式賬本，在沒(méi)有第三方中介機(jī)構(gòu)協(xié)調(diào)的條件下，支持互不可信的參與方之間的數(shù)據(jù)共享， 為數(shù)據(jù)協(xié)作帶來(lái)了新機(jī)遇.例如，在基于區(qū)塊鏈的鋼鐵交易系統(tǒng)中，如圖1所示，在鋼鐵交易場(chǎng)景下以 鋼廠、交易中心、物流平臺(tái)和監(jiān)管機(jī)構(gòu)為核心節(jié)點(diǎn)搭建的許可鏈中，鋼廠、交易中心、物流平臺(tái)的大量 業(yè)務(wù)人員通過(guò)這些平臺(tái)存證訂單發(fā)售、訂單成交、訂單定貨、倉(cāng)庫(kù)入庫(kù)等數(shù)據(jù)來(lái)共享訂單的全周期狀 態(tài)信息.同時(shí)區(qū)塊鏈的完整性、不可篡改等特性保證了政府組織的監(jiān)管人員對(duì)訂單流程的有效跟蹤， 形成了鋼材交易的全流程監(jiān)管體系，助力金融交易模式的創(chuàng)新發(fā)展.

盡管區(qū)塊鏈系統(tǒng)吸引了廣泛的關(guān)注，但是和發(fā)展已趨成熟的傳統(tǒng)數(shù)據(jù)庫(kù)相比，區(qū)塊鏈技術(shù)尚處于 初期階段，正面臨著多方面的挑戰(zhàn).其中，無(wú)法支持復(fù)雜查詢(xún)、對(duì)外提供接口單一以及延遲高是限制區(qū) 塊鏈被大規(guī)模應(yīng)用于實(shí)際生產(chǎn)開(kāi)發(fā)的主要因素.

在區(qū)塊鏈中，交易是指操作區(qū)塊鏈的日志數(shù)據(jù)，其內(nèi)部沒(méi)有嚴(yán)格的數(shù)據(jù)模型，典型的交易為包含 多個(gè)屬性值的結(jié)構(gòu)化數(shù)據(jù).一段時(shí)間內(nèi)一定數(shù)量的交易被打包為區(qū)塊并在多個(gè)節(jié)點(diǎn)間達(dá)成共識(shí)，因此， 邏輯上屬于同一類(lèi)型的交易數(shù)據(jù)，往往分布在不同的區(qū)塊中;交易數(shù)據(jù)物理存儲(chǔ)在Key-Value數(shù)據(jù)庫(kù)， 如LevelDB，甚至文件系統(tǒng)中，僅對(duì)外提供有限的數(shù)據(jù)訪問(wèn)方法;除此之外，為了節(jié)省空間，數(shù)據(jù)通常 會(huì)被高度壓縮后同步到存儲(chǔ)磁盤(pán)，這種處理不利于用戶對(duì)區(qū)塊數(shù)據(jù)的訪問(wèn).正是這種簡(jiǎn)單的數(shù)據(jù)結(jié) 構(gòu)、離散的組織形式以及不易索引的底層存儲(chǔ)，限制了交易數(shù)據(jù)的語(yǔ)義表達(dá)，導(dǎo)致區(qū)塊鏈具備的數(shù)據(jù) 管理功能非常有限.

為了彌補(bǔ)區(qū)塊鏈在數(shù)據(jù)管理方面的不足，學(xué)術(shù)界和企業(yè)界在區(qū)塊鏈和管理技術(shù)融合方面做了許 多努力，如 BigChainDB[1]、SEBDB間、BlockchainDB[3]和 EtherQL⑷.BigChainDB[1]是基于 MongoDB 構(gòu)建的具有區(qū)塊鏈特點(diǎn)的數(shù)據(jù)庫(kù)的典型代表，但是，其查詢(xún)方式依賴(lài)于MongoDB原生接口，查詢(xún)性能 也受MongoDB制約.SEBDB[2]在區(qū)塊鏈系統(tǒng)中添加了支持關(guān)系語(yǔ)義的查詢(xún)處理引擎，并通過(guò)構(gòu)造索 引結(jié)構(gòu)加快查詢(xún)速度，但是，其支持的查詢(xún)功能有限，二次開(kāi)發(fā)難度大.BlockchainDB[3]在區(qū)塊鏈的上 層添加數(shù)據(jù)庫(kù)層，對(duì)內(nèi)在數(shù)據(jù)庫(kù)層使用基于哈希的分片方式將讀寫(xiě)請(qǐng)求分發(fā)到不同的數(shù)據(jù)節(jié)點(diǎn)上，對(duì) 外提供方便易用的查詢(xún)接口，但是，其僅支持單一的PUT/GET操作.EtherQL[4]在以太坊的上層設(shè)計(jì) 查詢(xún)層，將區(qū)塊鏈數(shù)據(jù)拷貝到查詢(xún)層中并通過(guò)查詢(xún)層提供接口實(shí)現(xiàn)豐富查詢(xún)，但是，其受限于底層存 儲(chǔ)MongoDB的有限查詢(xún)支持，并未充分發(fā)揮出區(qū)塊鏈的全部潛力.以上工作盡管從某一方面優(yōu)化了 區(qū)塊鏈的數(shù)據(jù)管理，但是并未兼顧區(qū)塊鏈應(yīng)用開(kāi)發(fā)的通用性和高效性.因此，實(shí)現(xiàn)對(duì)區(qū)塊鏈的高效管 理具有重要的現(xiàn)實(shí)意義.

在傳統(tǒng)數(shù)據(jù)庫(kù)中，高效的數(shù)據(jù)管理離不開(kāi)易于使用的抽象模型和豐富的語(yǔ)義描述.然而，區(qū)塊鏈 系統(tǒng)與傳統(tǒng)數(shù)據(jù)管理系統(tǒng)在體系結(jié)構(gòu)和存儲(chǔ)模型上存在顯著不同，提升區(qū)塊鏈的數(shù)據(jù)管理效率將面 臨以下3個(gè)挑戰(zhàn).

（1）如何對(duì)交易數(shù)據(jù)抽象建模根據(jù)應(yīng)用場(chǎng)景靈活地為交易數(shù)據(jù)添加抽象模型，將無(wú)序離散的交 易構(gòu)造成結(jié)構(gòu)化或非結(jié)構(gòu)化數(shù)據(jù).

（2）如何減少用戶的使用成本向上提供多種數(shù)據(jù)訪問(wèn)接口，向下抽象底層通信處理過(guò)程，降低 開(kāi)發(fā)人員使用區(qū)塊鏈共享數(shù)據(jù)的復(fù)雜度.

（3）如何優(yōu)化數(shù)據(jù)管理性能優(yōu)化區(qū)塊鏈交易處理以及數(shù)據(jù)查詢(xún)流程以提升基于區(qū)塊鏈的開(kāi)發(fā)應(yīng) 用效率.

本文提出了基于區(qū)塊鏈的數(shù)據(jù)管理架構(gòu)，將現(xiàn)有的區(qū)塊鏈系統(tǒng)作為防篡改和去中心化的存儲(chǔ)層， 無(wú)須對(duì)其進(jìn)行改動(dòng)，并在上層添加了數(shù)據(jù)管理中間件，針對(duì)上述挑戰(zhàn)提出相應(yīng)解決方案，提升數(shù)據(jù)管 理效率.數(shù)據(jù)管理中間件提供以下功能.

（1）自定義數(shù)據(jù)模型通過(guò)靈活的Schema將區(qū)塊鏈交易數(shù)據(jù)組織成各種抽象模型，同時(shí)，提供多 種數(shù)據(jù)訪問(wèn)接口支持豐富查詢(xún)，包括方便使用的SQL接口以及低耦合的REST接口.

（2）數(shù)據(jù)高效查詢(xún)查詢(xún)引擎可以依據(jù)同步緩存機(jī)制高效處理不同類(lèi)型的查詢(xún)請(qǐng)求.另外，同步 緩存機(jī)制的持久化存儲(chǔ)支持SQL數(shù)據(jù)庫(kù).

（3）交易處理優(yōu)化采用提前計(jì)算哈希的處理方式降低交易延遲，并通過(guò)異步批處理策略提升交 易吞吐，最大化利用系統(tǒng)資源.

面向區(qū)塊鏈的數(shù)據(jù)管理中間件具有通用性，為開(kāi)發(fā)人員提供了靈活的數(shù)據(jù)模型和用戶友好的訪 問(wèn)接口，并兼容多種區(qū)塊鏈系統(tǒng)和數(shù)據(jù)庫(kù)，降低對(duì)存儲(chǔ)層的依賴(lài).同時(shí)，數(shù)據(jù)管理中間件的維護(hù)開(kāi)銷(xiāo)不 會(huì)給整個(gè)架構(gòu)帶來(lái)額外影響.此外，數(shù)據(jù)管理架構(gòu)具有可擴(kuò)展性，開(kāi)發(fā)人員可部署多服務(wù)，以支持高可 用的多方協(xié)作并通過(guò)反向代理實(shí)現(xiàn)負(fù)載均衡.

1系統(tǒng)架構(gòu)概述

本文原型系統(tǒng)架構(gòu)如圖2所示，包括數(shù)據(jù)管理中間件和存儲(chǔ)層.數(shù)據(jù)管理中間件由5個(gè)模塊組成： 數(shù)據(jù)訪問(wèn)接口、數(shù)據(jù)管理器、交易處理器、查詢(xún)引擎以及RPC連接器.其中，數(shù)據(jù)訪問(wèn)接口對(duì)外提供 SQL接口，與客戶端進(jìn)行交互;數(shù)據(jù)管理器負(fù)責(zé)命令解析以及數(shù)據(jù)建模;交易處理器負(fù)責(zé)構(gòu)造交易和 優(yōu)化交易處理流程;查詢(xún)引擎提供索引和同步緩存機(jī)制，負(fù)責(zé)數(shù)據(jù)同步與交易解析;此外，RPC連接 器負(fù)責(zé)與區(qū)塊鏈間的通信，數(shù)據(jù)的讀寫(xiě)均來(lái)源于由區(qū)塊鏈和外部存儲(chǔ)組成的存儲(chǔ)層.

在此架構(gòu)下，數(shù)據(jù)管理中間件對(duì)外提供SQL接口與數(shù)據(jù)模型交互，封裝復(fù)雜的內(nèi)部實(shí)現(xiàn)，支持包 括關(guān)系模型在內(nèi)的多種抽象數(shù)據(jù)的構(gòu)造與維護(hù)，并且依據(jù)Schema檢查或解析交易字段，執(zhí)行來(lái)自應(yīng)用程序的讀寫(xiě)請(qǐng)求.當(dāng)數(shù)據(jù)管理中間件接收到客戶端發(fā)來(lái)的查詢(xún)請(qǐng)求時(shí)，直接調(diào)用查詢(xún)引擎中同步緩 存到外部數(shù)據(jù)庫(kù)的結(jié)構(gòu)化數(shù)據(jù)加速讀取;當(dāng)數(shù)據(jù)管理中間件接收到客戶端發(fā)來(lái)的上鏈請(qǐng)求時(shí)，交易處 理器采用的提前哈希計(jì)算以及異步批處理的優(yōu)化策略會(huì)大大加快整個(gè)交易執(zhí)行過(guò)程，進(jìn)一步提高效 率.此外，數(shù)據(jù)管理中間件還設(shè)計(jì)了 RPC連接器抽象化與RPC接口的通信過(guò)程，以減少對(duì)存儲(chǔ)層的 依賴(lài)性.存儲(chǔ)層采用現(xiàn)有的區(qū)塊鏈系統(tǒng)來(lái)存儲(chǔ)數(shù)據(jù)，保留區(qū)塊鏈系統(tǒng)基本的安全性特征，如不可篡改 和去中心化等，同時(shí)提供數(shù)據(jù)管理中間件的數(shù)據(jù)持久化存儲(chǔ)，通過(guò)簡(jiǎn)單配置實(shí)現(xiàn)伸縮性.

2自定義數(shù)據(jù)模型

2.1數(shù)據(jù)建模

圖3給出了一般區(qū)塊鏈的鏈?zhǔn)浇Y(jié)構(gòu)，區(qū)塊鏈的基本單位是區(qū)塊，區(qū)塊由區(qū)塊頭和區(qū)塊體組成，其 中，區(qū)塊頭記錄了前一區(qū)塊的哈希值、區(qū)塊生成時(shí)間、交易默克爾樹(shù)根等信息.每個(gè)區(qū)塊都包含前塊 哈希，一旦一個(gè)區(qū)塊的內(nèi)容被篡改，就需要更改所有后續(xù)的區(qū)塊哈希，區(qū)塊鏈通過(guò)這種鏈?zhǔn)浇Y(jié)構(gòu)保證 了數(shù)據(jù)的防篡改特性.區(qū)塊體內(nèi)包含一組以默克爾樹(shù)的結(jié)構(gòu)組織的交易，其中，默克爾樹(shù)根是對(duì)區(qū)塊 內(nèi)所有交易的證明，保證了數(shù)據(jù)的可驗(yàn)證.交易記錄了用戶的更新操作，以比特幣為例，交易中包含了 轉(zhuǎn)賬信息，包括轉(zhuǎn)賬接收者、交易金額等.對(duì)于支持智能合約的以太坊，交易中還記錄了智能合約的調(diào) 用參數(shù).

在區(qū)塊鏈中，交易可以視為包含多個(gè)屬性值的結(jié)構(gòu)化數(shù)據(jù)，除交易ID、交易生成時(shí)間、交易簽名 等系統(tǒng)屬性值外，與實(shí)際應(yīng)用相關(guān)的參數(shù)都記錄于數(shù)據(jù)（Data）字段中，而且調(diào)用同一智能合約生成的 交易具有相同的數(shù)據(jù)結(jié)構(gòu).因此，數(shù)據(jù)管理中間件采用統(tǒng)一的語(yǔ)義——Schema聲明來(lái)描述這種交易 關(guān)系，根據(jù)交易中數(shù)據(jù)字段的屬性值與Schema中的屬性名，將交易數(shù)據(jù)抽象為邏輯數(shù)據(jù)模型，這種建 模大大降低了區(qū)塊鏈的應(yīng)用開(kāi)發(fā)難度.同時(shí)，數(shù)據(jù)建模十分靈活，交易數(shù)據(jù)可以抽象為關(guān)系模型，支 持SQL語(yǔ)言對(duì)區(qū)塊鏈做豐富查詢(xún);也可以抽象為鍵值對(duì)形式，其中鍵表示主鍵，值表示元組的有效負(fù)載.

圖4所示為發(fā)票數(shù)據(jù)建模示例，開(kāi)發(fā)人員將應(yīng)用信息組織成關(guān)系模型寫(xiě)入Schema，構(gòu)造為一張由 票頭（InvoiceNo）、客戶名稱(chēng)（ClientName）、金額（Amount）以及開(kāi)票日期（Date）等屬性名組成的關(guān) 系表Invoice，并調(diào)用智能合約將發(fā)票上鏈存證，具體發(fā)票信息存儲(chǔ)在區(qū)塊^的交易m和區(qū)塊^的交 易n中.交易經(jīng)過(guò)Schema檢查后，Data字段中的屬性值邏輯映射為表Invoice的元組.Invoice_Table表中的兩行記錄分別表示交易m中的一張2021年1月1日由Alice開(kāi)具的票頭為IN00001、交 易金額為10000的發(fā)票信息和交易W中的一張2021年2月2日由Allen開(kāi)具的票頭為IN00002、交易 金額為20000的發(fā)票信息.

Schema

TR交易

TA 表

Id， Time， Signature， Data

m 2020-01-01? 0x123456789a..

... IN00001Alice100002020-01-01..

n 2020-02-02?? 0xfedcba9876...

... IN00002Allen200002020-02-02...

Date

2.2 SQL與數(shù)據(jù)處理

區(qū)塊鏈的底層存儲(chǔ)形式十分簡(jiǎn)單（例如，以太坊使用鍵值數(shù)據(jù)庫(kù)LevelDB存儲(chǔ)交易數(shù)據(jù)），而且僅 向上層應(yīng)用提供RPC接口，支持簡(jiǎn)單的查詢(xún)邏輯.因此，基于區(qū)塊鏈的數(shù)據(jù)查詢(xún)十分受限于其底層原 生支持，不僅支持的查詢(xún)功能有限，對(duì)開(kāi)發(fā)人員也有更高的技術(shù)要求.

SQL查詢(xún)是一種高效的查詢(xún)方法，通過(guò)SQL接口可以支持復(fù)雜的查詢(xún)邏輯，也能有效解決區(qū)塊 鏈在數(shù)據(jù)管理方面存在的無(wú)法支持復(fù)雜查詢(xún)和查詢(xún)接口單一兩大問(wèn)題.因此，數(shù)據(jù)管理中間件利用區(qū) 塊鏈系統(tǒng)提供的基于RPC的接口封裝了一組SQL接口支持豐富高效的查詢(xún)操作.開(kāi)發(fā)人員可以使 用SQL語(yǔ)言管理區(qū)塊鏈，無(wú)須考慮區(qū)塊鏈的底層存儲(chǔ)細(xì)節(jié)，即可進(jìn)行便捷的上層應(yīng)用開(kāi)發(fā).表1列出 了開(kāi)發(fā)人員能夠?qū)?shù)據(jù)模型執(zhí)行的3種主要管理操作CREATE/ALTER、INSERT和SELECT以及 它們?cè)跀?shù)據(jù)管理中間件內(nèi)部的主要處理流程.

圖5展示了 SQL請(qǐng)求在數(shù)據(jù)管理中間件中的數(shù)據(jù)處理流程，該流程可分為數(shù)據(jù)建模、數(shù)據(jù)上鏈以 及數(shù)據(jù)查詢(xún)3步.當(dāng)上層應(yīng)用發(fā)起CREATE/ALTER請(qǐng)求與數(shù)據(jù)管理中間件進(jìn)行建模交互時(shí)，數(shù)據(jù) 管理器在解析請(qǐng)求后，將表名、屬性約束等信息組織成數(shù)據(jù)模型的結(jié)構(gòu)，并將結(jié)構(gòu)體中的有效數(shù)據(jù)寫(xiě)入Schema文件中.Schema通常很小且更新頻率低，一次更新可以處理多次讀寫(xiě)，因此Schema的存 儲(chǔ)和維護(hù)不會(huì)給整個(gè)系統(tǒng)架構(gòu)帶來(lái)額外影響.此外，數(shù)據(jù)管理中間件用字典樹(shù)對(duì)Schema名進(jìn)行索引， 這種組織方式可以加速在需要多種Schema的業(yè)務(wù)場(chǎng)景下的Schema快速匹配.

一旦數(shù)據(jù)管理器成功創(chuàng)建或更新Schema，就可以基于抽象模型處理應(yīng)用場(chǎng)景下的一系列數(shù)據(jù)管 理請(qǐng)求.當(dāng)處理數(shù)據(jù)上鏈情況時(shí)，數(shù)據(jù)管理器根據(jù)Schema規(guī)則檢查INSERT請(qǐng)求的完整性和準(zhǔn)確性， 只有符合Schema描述的所有約束條件的數(shù)據(jù)才能被驗(yàn)證為合法數(shù)據(jù)并轉(zhuǎn)發(fā)到交易處理器中，交易處 理器將其構(gòu)造成交易并插入交易隊(duì)列中.當(dāng)處理數(shù)據(jù)查詢(xún)情況時(shí)，查詢(xún)引擎直接查取按照Schema規(guī) 則解析為抽象模型并存入同步緩存中的交易數(shù)據(jù).Schema機(jī)制在整個(gè)處理過(guò)程中不但可以靈活地抽 象應(yīng)用場(chǎng)景，不需要考慮數(shù)據(jù)模型結(jié)構(gòu)化與否，而且可以將數(shù)據(jù)模型組織成任意區(qū)塊鏈系統(tǒng)的交易結(jié) 構(gòu)，對(duì)底層沒(méi)有依賴(lài)性，具有通用價(jià)值，是實(shí)現(xiàn)通用高效的區(qū)塊鏈數(shù)據(jù)管理的核心.

3高效查詢(xún)處理

區(qū)塊鏈系統(tǒng)與傳統(tǒng)數(shù)據(jù)庫(kù)在數(shù)據(jù)存儲(chǔ)方面存在巨大差異.從打包方式來(lái)看，區(qū)塊鏈中的數(shù)據(jù)以交 易的形式存放，交易通過(guò)共識(shí)方可生效，共識(shí)通過(guò)的一些交易在某個(gè)時(shí)間點(diǎn)被打包成區(qū)塊.由于交易 是按照時(shí)間順序被打包到區(qū)塊中的，因此單個(gè)區(qū)塊內(nèi)可能含有不同類(lèi)型（調(diào)用了不同的智能合約函 數(shù)）的交易，即相同類(lèi)型的交易數(shù)據(jù)通常分布在不同區(qū)塊，當(dāng)查詢(xún)同一類(lèi)型的交易時(shí)需要遍歷整個(gè)賬 本才能確保查詢(xún)結(jié)果的完整性，這種離散的數(shù)據(jù)分布降低了區(qū)塊鏈I/O訪問(wèn)效率.隨著區(qū)塊鏈系統(tǒng)的 運(yùn)行，交易的不斷產(chǎn)生會(huì)導(dǎo)致區(qū)塊鏈越來(lái)越長(zhǎng)，因此查詢(xún)單一類(lèi)型交易的時(shí)間也會(huì)越來(lái)越久;從底層 存儲(chǔ)來(lái)看，區(qū)塊數(shù)據(jù)物理存放在簡(jiǎn)單的Key-Value數(shù)據(jù)庫(kù)中，如LevelDB，這類(lèi)數(shù)據(jù)庫(kù)會(huì)定期將數(shù)據(jù) 同步到磁盤(pán)，同時(shí)為了節(jié)省存儲(chǔ)開(kāi)銷(xiāo)將對(duì)這些數(shù)據(jù)進(jìn)行自適應(yīng)壓縮，數(shù)據(jù)的實(shí)際組織變得難以預(yù)測(cè). 這種方式不利于對(duì)區(qū)塊鏈進(jìn)行復(fù)雜查詢(xún)，因?yàn)樵L問(wèn)區(qū)塊中的交易數(shù)據(jù)十分耗時(shí)，往往需要從散布在整 個(gè)磁盤(pán)上的數(shù)十萬(wàn)個(gè)文件中隨機(jī)讀取.

為解決交易離散式分布存儲(chǔ)帶來(lái)的查詢(xún)效率低下問(wèn)題，數(shù)據(jù)管理中間件在查詢(xún)引擎模塊中設(shè)計(jì) 了索引結(jié)構(gòu)和同步緩存機(jī)制，并且可以根據(jù)不同應(yīng)用場(chǎng)景的安全要求和工作負(fù)載靈活使用優(yōu)化方法， 在提升查詢(xún)性能的同時(shí)，減少數(shù)據(jù)更新對(duì)整個(gè)架構(gòu)存儲(chǔ)帶來(lái)的影響.在某些期望使用豐富的查詢(xún)和統(tǒng) 計(jì)功能（如聚集查詢(xún)等）的場(chǎng)景下，同時(shí)允許適當(dāng)放寬安全性級(jí)別的要求，那么考慮到兼容性以及查詢(xún) 效率，相比索引等優(yōu)化方法，更通用的一種方式是采取同步緩存機(jī)制.

數(shù)據(jù)管理中間件主動(dòng)地將最新區(qū)塊數(shù)據(jù)實(shí)時(shí)同步，并調(diào)用Schema將交易構(gòu)造為數(shù)據(jù)模型的結(jié)構(gòu) 存儲(chǔ)于數(shù)據(jù)庫(kù)中，從根本上優(yōu)化了在物理存儲(chǔ)上的查詢(xún)性能，確保查詢(xún)既準(zhǔn)確又高效.同步緩存機(jī)制 設(shè)置一個(gè)獨(dú)立的配置文件負(fù)責(zé)維護(hù)當(dāng)前區(qū)塊高度信息，查詢(xún)引擎僅允許開(kāi)發(fā)人員通過(guò)指定的SQL-like 請(qǐng)求UPDATE HEIGHTSCAN更新配置，不設(shè)置其他配置更改方式，以保證其安全性.當(dāng)區(qū)塊鏈運(yùn)行 時(shí)，啟動(dòng)單獨(dú)工作的同步監(jiān)聽(tīng)線程讀取配置文件中的塊高作為初始值掃描區(qū)塊（系統(tǒng)剛啟動(dòng)時(shí)初始值 為O，確保同步完整的歷史區(qū)塊），每掃描況個(gè)區(qū)塊周期觸發(fā)檢查點(diǎn)，更新配置信息，重復(fù)上述過(guò)程直 到請(qǐng)求到最高塊.同步任務(wù)設(shè)置空閑檢測(cè)來(lái)保證實(shí)時(shí)通信，并保持每3 s請(qǐng)求一次區(qū)塊高度的輪詢(xún).

目前大多數(shù)區(qū)塊鏈均采用虛擬機(jī)（Ethereum Virtual Machine， EVM）來(lái)屏蔽節(jié)點(diǎn)底層的實(shí)現(xiàn)差 異，向上層只提供RPC接口完成與節(jié)點(diǎn)的交互.在數(shù)據(jù)管理中間件中，交易管理器將成功通過(guò) Schema檢查的數(shù)據(jù)構(gòu)造成交易的形式并對(duì)其簽名，隨后通過(guò)RPC連接器訪問(wèn)區(qū)塊鏈.RPC連接器的 功能是為數(shù)據(jù)管理層封裝一個(gè)抽象存儲(chǔ)接口，減少對(duì)底層區(qū)塊鏈類(lèi)型的依賴(lài).如表2所示，RPC連接 器實(shí)現(xiàn)的3種主要方法為Read、Write和Check.

Read方法根據(jù)交易哈?；驂K高讀取交易數(shù)據(jù)并將其以字節(jié)形式反序列化后轉(zhuǎn)發(fā)給數(shù)據(jù)管理中間 件.Write方法將交易數(shù)據(jù)序列化為字節(jié)形式，再將其發(fā)送到區(qū)塊鏈進(jìn)行處理，并返回唯一交易哈希 值tx-hash到數(shù)據(jù)管理中間件.此外，RPC連接器通過(guò)Check方法查詢(xún)交易哈希為tx-hash的交易的 上鏈狀態(tài).

數(shù)據(jù)管理中間件將最新交易數(shù)據(jù)從區(qū)塊鏈同步到緩存后，對(duì)緩存中的數(shù)據(jù)進(jìn)行處理并將其持久 化.這一同步過(guò)程中存在兩個(gè)問(wèn)題：①中間件可能緩存或者持久化了沒(méi)有上鏈成功的交易，造成讀取 不正確;②中間件中并未緩存最新的交易數(shù)據(jù)，導(dǎo)致讀取不到最新數(shù)據(jù).

為了解決上述問(wèn)題，查詢(xún)處理器與交易處理器進(jìn)行協(xié)調(diào)處理.具體處理過(guò)程：當(dāng)中間件處理 INSERT請(qǐng)求進(jìn)行數(shù)據(jù)上鏈后，交易處理器調(diào)用RPC接口的Check函數(shù)檢查交易數(shù)據(jù)是否上鏈.如 果上鏈則表示交易成功，此時(shí)在同步緩存機(jī)制下，數(shù)據(jù)管理中間件通過(guò)RPC接口的Read方法掃描區(qū) 塊，將交易數(shù)據(jù)同步到查詢(xún)引擎的緩存中，然后利用Schema解析交易數(shù)據(jù)，按抽象的數(shù)據(jù)模型對(duì)交易 數(shù)據(jù)進(jìn)行持久化.這樣既保證了緩存中不會(huì)出現(xiàn)未上鏈的交易又保證了最新數(shù)據(jù)的同步，同步之后的 查詢(xún)請(qǐng)求就可以根據(jù)持久化的數(shù)據(jù)模型進(jìn)行相應(yīng)的SELECT操作.

此外，數(shù)據(jù)管理中間件使用Schema解析交易為抽象數(shù)據(jù)類(lèi)型后可以根據(jù)配置進(jìn)行全量同步或部 分同步，如在上文提到的發(fā)票數(shù)據(jù)上鏈場(chǎng)景中，用戶可以選擇僅同步開(kāi)票時(shí)間為2020年以后的發(fā)票 信息，以減少冗余寫(xiě)入，更靈活地適應(yīng)多方協(xié)作下的業(yè)務(wù)場(chǎng)景.同步緩存機(jī)制保證絕大多數(shù)區(qū)塊僅需 被掃描一次，實(shí)質(zhì)上，是對(duì)數(shù)據(jù)管理中間件中的持久化的數(shù)據(jù)進(jìn)行查詢(xún)，從而避免重復(fù)冗余掃描，降低 通信開(kāi)銷(xiāo)和區(qū)塊讀取延遲，在讀密集型工作負(fù)載下，數(shù)據(jù)管理中間件的查詢(xún)性能將得到顯著提升.

4交易處理優(yōu)化

當(dāng)數(shù)據(jù)管理中間件執(zhí)行來(lái)自應(yīng)用程序的INSERT請(qǐng)求時(shí)，調(diào)用Write方法訪問(wèn)區(qū)塊鏈并等待交易 哈希tx-hash返回，這個(gè)過(guò)程會(huì)阻塞系統(tǒng)其他讀寫(xiě)操作，從而導(dǎo)致整個(gè)系統(tǒng)響應(yīng)緩慢.基于此，我們提 出一種提前計(jì)算哈希的優(yōu)化策略加速交易處理過(guò)程，在調(diào)用Write方法后立即使用與上鏈過(guò)程相同的 哈希算法計(jì)算tx-hash值并返回上層.對(duì)于數(shù)據(jù)管理中間件而言，在交易上鏈階段主要消耗網(wǎng)絡(luò)帶寬， 而CPU資源相對(duì)空閑，因此提前計(jì)算哈希與交易上鏈可以并行執(zhí)行.與原始的高延遲低吞吐的串行化 處理相比，提前進(jìn)行哈希計(jì)算大大縮短了上層響應(yīng)時(shí)間.然而，異步處理方式不能保證所有INSERT 請(qǐng)求的交易成功上鏈，在此基礎(chǔ)上，為了確保異步通信數(shù)據(jù)的完整性，交易處理器將提前計(jì)算哈希值 tx-hash放入交易隊(duì)列中，檢查線程輪詢(xún)交易隊(duì)列并調(diào)用Check方法檢查交易狀態(tài)，判斷交易數(shù)據(jù)是 否上鏈.

為了提升數(shù)據(jù)管理中間件與存儲(chǔ)層之間的吞吐，采用工業(yè)生產(chǎn)常用處理方式，對(duì)交易進(jìn)行異步批 量處理.批處理在寫(xiě)密集型工作負(fù)載下對(duì)數(shù)據(jù)管理中間件到區(qū)塊鏈節(jié)點(diǎn)的吞吐提升效果顯著，但這可 能會(huì)導(dǎo)致兩個(gè)問(wèn)題：首先，在讀密集型工作負(fù)載下，批處理方式可能導(dǎo)致交易隊(duì)列一段時(shí)間內(nèi)處于休 眠狀態(tài);其次，當(dāng)對(duì)INSERT的數(shù)據(jù)立即執(zhí)行SELECT操作時(shí)，區(qū)塊鏈可能返回的不是完整的數(shù)據(jù)集.

數(shù)據(jù)管理中間件的優(yōu)化方式是在交易處理器中定義隊(duì)列最大等待長(zhǎng)度以及最長(zhǎng)等待時(shí)間，采用 計(jì)數(shù)器和計(jì)時(shí)器動(dòng)態(tài)設(shè)置隊(duì)列長(zhǎng)度從而控制等待延遲.具體批處理策略與區(qū)塊鏈的交易打包策略保 持一致，這樣的好處是當(dāng)同一類(lèi)型的交易大規(guī)模上鏈時(shí)，經(jīng)過(guò)交易管理器處理后可以打包為同一區(qū)塊， 在提高資源利用率的同時(shí)，大大降低交易離散程度，這些交易密集分布在同一個(gè)或相鄰的幾個(gè)區(qū)塊， 降低了后續(xù)查詢(xún)處理過(guò)程中掃描區(qū)塊的開(kāi)銷(xiāo).雖然這種最終一致性的處理方式不能保證開(kāi)發(fā)人員實(shí) 時(shí)查詢(xún)到交易最新值，但是它比同步阻塞查詢(xún)延遲要低很多，在實(shí)際應(yīng)用環(huán)境中更有生產(chǎn)價(jià)值，具體 描述如算法1所示.

算法1提前哈希計(jì)算和異步批處理

輸人：Metadata交易數(shù)據(jù)，Tx交易 輸出：Txhash交易哈希，Txset交易集合

1： Function EARLYHASHCOMPUTE （Metadata）

2：????? If check （Metadata）==true then//通過(guò)Schema機(jī)制驗(yàn)證為合法交易數(shù)據(jù)

3：????? Tx — construct （Metadata）//構(gòu)造交易并簽名

4：????? Txhash —prehash （Tx）//提前計(jì)算哈希名

5：????? End if

6：????? Return Txhash//將交易哈希值返回客戶端

7： End function

8： Function BATCHPROCESSING Tx 9：????? O — Counter//批處理策略計(jì)數(shù)器

10：?? O —T皿er//批處理策略計(jì)時(shí)器

11：?? While Counter <=WriteQueue.maxsize and Timer <= WriteQueue.maxtime do

12：?? Tx — Writequeue.push（）

13：?? End while

14：?? If Counter == WriteQueue.maxsize or Timer == WriteQueue.maxtime then

15：?? Txhead — WriteQueue.front（）

16：?? While WriteQueue.empty（）??????? do

17：?? Txset — WriteQueue.pop（）

18：?? End while

19：?? 0 — Counter

20：?? 0 ^ Timer

21：?? End if

22：?? Return Txset//將交易集發(fā)送到區(qū)塊鏈

23： End function

算法1描述了提前哈希計(jì)算和異步批處理策略的過(guò)程，輸入?yún)?shù)為交易數(shù)據(jù)Metadata，輸出參數(shù) 為交易哈希Txsethash.算法第1 一2行描述了數(shù)據(jù)管理器將Schema檢查的合法交易數(shù)據(jù)Metadata 轉(zhuǎn)發(fā)到交易處理器，第3—7行表示對(duì)經(jīng)過(guò)交易處理器簽名后的交易數(shù)據(jù)Tx執(zhí)行提前哈希計(jì)算并將 哈希值Txhash返回上層，哈希計(jì)算延遲遠(yuǎn)遠(yuǎn)小于數(shù)據(jù)管理中間件與區(qū)塊鏈之間的通信延遲，因此提 前哈希計(jì)算可以提高應(yīng)用開(kāi)發(fā)效率.第8—11行將交易數(shù)據(jù)加入交易隊(duì)列，計(jì)時(shí)器/計(jì)數(shù)器負(fù)責(zé)動(dòng)態(tài) 評(píng)測(cè)當(dāng)前隊(duì)列的負(fù)載.第12—17行表示一旦發(fā)現(xiàn)計(jì)時(shí)器或計(jì)數(shù)器達(dá)到閾值，從交易隊(duì)列中依次調(diào)度 任務(wù)并將其批量處理打包為交易集合Txset.第18—21行表示數(shù)據(jù)管理器將交易集合發(fā)送到區(qū)塊鏈， 區(qū)塊鏈對(duì)交易進(jìn)行處理并將哈希Txsethash返回至數(shù)據(jù)管理中間件，批處理策略在保證延遲低的前提 下極大地提升了系統(tǒng)吞吐.

5實(shí)驗(yàn)評(píng)估

5.1實(shí)驗(yàn)環(huán)境

本文將提出的數(shù)據(jù)管理中間件應(yīng)用到開(kāi)源區(qū)塊鏈CITA中，實(shí)現(xiàn)了數(shù)據(jù)管理架構(gòu)SQL-CITA以 驗(yàn)證本文所提出方法的有效性.實(shí)驗(yàn)在配備Intel Xeon（R） 3.00 GHz的CPU、16 G的RAM和1 TB 的硬盤(pán)上進(jìn)行，運(yùn)行在Ubuntu16.04上，CITA默認(rèn)3 s出一個(gè)塊，啟動(dòng)4個(gè)節(jié)點(diǎn).另外，我們基于數(shù)據(jù) 管理中間件開(kāi)發(fā)了一個(gè)客戶端，其他系統(tǒng)也可以通過(guò)POST請(qǐng)求訪問(wèn)SQL-CITA.

以鋼鐵期限聯(lián)動(dòng)場(chǎng)景為例：鋼鐵交易中心將數(shù)據(jù)上鏈存證實(shí)現(xiàn)信息安全共享;商委監(jiān)管平臺(tái)對(duì)鏈 上數(shù)據(jù)進(jìn)行查詢(xún)實(shí)現(xiàn)鋼材交易全流程監(jiān)管.如圖6所示，Invioce表記錄了期現(xiàn)聯(lián)動(dòng)場(chǎng)景下訂單的發(fā)票 信息，原型支持?jǐn)?shù)據(jù)表創(chuàng)建與修改、表數(shù)據(jù)的添加及查詢(xún).通過(guò)演示SQL-CITA的上鏈存證和數(shù)據(jù)查 詢(xún)功能，展現(xiàn)面向區(qū)塊鏈的通用高效數(shù)據(jù)管理架構(gòu)在金融產(chǎn)業(yè)鏈服務(wù)中的價(jià)值.

由于系統(tǒng)原型的局限性，這里工作負(fù)載涉及的創(chuàng)表、上鏈和查詢(xún)執(zhí)行的相關(guān)語(yǔ)句均為表3所示的 形式.為了構(gòu)造大量的測(cè)試數(shù)據(jù)，我們?cè)O(shè)計(jì)并實(shí)現(xiàn)了一個(gè)數(shù)據(jù)生成器，模擬真實(shí)場(chǎng)景下隨機(jī)生成的發(fā) 票信息.將從SQL-CITA的整體讀寫(xiě)性能以及數(shù)據(jù)管理中間件中的Schema建模、同步緩存機(jī)制以及 交易優(yōu)化處理技術(shù)多個(gè)角度進(jìn)行實(shí)驗(yàn)對(duì)比，從而論證數(shù)據(jù)管理中間件的有效性.

5.2讀寫(xiě)性能對(duì)比

本節(jié)將數(shù)據(jù)管理中間件與CITA工具cita-sdk-java進(jìn)行上鏈與查詢(xún)性能對(duì)比，其中，cita-sdk-java 集成了與CITA客戶端交互的功能，兩者皆采用相同的數(shù)據(jù)集.交易個(gè)數(shù)從1000筆增長(zhǎng)到10000筆. 圖7顯示，對(duì)于I形式的上鏈，SQL-CITA處理上鏈操作的時(shí)延高于CITA，造成高時(shí)延的原因可以從 SQL-CITA為了支持復(fù)雜查詢(xún)?cè)跀?shù)據(jù)管理中間件中引入的數(shù)據(jù)管理器和交易處理器兩個(gè)方面去分析. 雖然SQL-CITA采用了交易優(yōu)化處理手段減少延遲，但數(shù)據(jù)上鏈過(guò)程中的網(wǎng)絡(luò)通信、請(qǐng)求解析和交易 構(gòu)造均需要額外的時(shí)間開(kāi)銷(xiāo).從圖中可以看出，使用SQL-CITA工具的上鏈時(shí)間增長(zhǎng)緩慢，與使用CITA 工具鏈的上鏈時(shí)間相比也沒(méi)有遜色很多，從開(kāi)發(fā)人員的角度來(lái)看，在可接受的額外開(kāi)銷(xiāo)內(nèi)SQL-CITA 大大提升了用戶體驗(yàn)，因此SQL-CITA具有更好的實(shí)際應(yīng)用性.

圖8顯示，對(duì)于Q形式的查詢(xún)，使用SQL-CITA工具的查詢(xún)響應(yīng)時(shí)間遠(yuǎn)遠(yuǎn)小于直接使用CITA工 具的響應(yīng)時(shí)間，且SQL-CITA增長(zhǎng)緩慢，而使用CITA客戶端的查詢(xún)響應(yīng)時(shí)間增長(zhǎng)迅速.這是因?yàn)?SQL-CITA使用的同步緩存機(jī)制有效降低了查詢(xún)延遲，使基于CITA的數(shù)據(jù)查詢(xún)性能得到顯著提升.

5.3 Schema維護(hù)性能

我們通過(guò)創(chuàng)建C形式的Schema來(lái)比較上鏈過(guò)程與Schema檢查所需要的時(shí)間.圖9顯示了數(shù)據(jù) 量規(guī)模在1萬(wàn)?2萬(wàn)條記錄的情況下的整個(gè)數(shù)據(jù)上鏈過(guò)程和Schema檢查過(guò)程的時(shí)間開(kāi)銷(xiāo).如圖9 所示，對(duì)于I形式上鏈的交易，Schema檢查在數(shù)據(jù)上鏈中所占時(shí)間非常有限，即使系統(tǒng)一次上鏈2萬(wàn) 條數(shù)據(jù)記錄，也僅需要2 s的時(shí)間，因此，Schema檢查過(guò)程對(duì)SQL-CITA數(shù)據(jù)上鏈的時(shí)間影響非常小， 在5.2節(jié)的上鏈性能對(duì)比實(shí)驗(yàn)中，導(dǎo)致SQL-CITA略高于CITA的延遲的瓶頸并不是Schema處理與 維護(hù).

圖10顯示了數(shù)據(jù)量規(guī)模在1萬(wàn)?2萬(wàn)條記錄的情況下的數(shù)據(jù)同步和Schema解析的時(shí)間開(kāi)銷(xiāo). 如圖10所示，Schema解析的時(shí)間開(kāi)銷(xiāo)不足整個(gè)數(shù)據(jù)同步的時(shí)間開(kāi)銷(xiāo)的一半，即使系統(tǒng)同步2萬(wàn)條數(shù) 據(jù)，也僅需要3500 ms的時(shí)間.因此，Schema解析過(guò)程對(duì)SQL-CITA同步緩存機(jī)制的影響非常小，結(jié) 合本節(jié)的兩個(gè)實(shí)驗(yàn)可得，在整個(gè)數(shù)據(jù)管理中間件的執(zhí)行過(guò)程中Schema處理與維護(hù)并不會(huì)造成系統(tǒng)的 性能瓶頸.

5.4同步緩存機(jī)制性能

對(duì)于使用SQL-CITA的數(shù)據(jù)查詢(xún)請(qǐng)求，我們?cè)赟QL-CITA中實(shí)現(xiàn)了通用的同步緩存機(jī)制.實(shí)驗(yàn)設(shè) 置單個(gè)區(qū)塊包含的交易筆數(shù)，固定交易集為20000個(gè)，其中通過(guò)配置CITA單個(gè)區(qū)塊內(nèi)可消耗的 Quota值動(dòng)態(tài)設(shè)置區(qū)塊大小從包含50筆交易、100筆交易到包含150筆交易，每筆交易均為通過(guò)I形 式上鏈的交易.交易個(gè)數(shù)從2000筆到20000筆增長(zhǎng)，以對(duì)比單個(gè)區(qū)塊不同大小下的同步緩存機(jī)制性能. 如圖11所示，在Q查詢(xún)形式下，隨著單個(gè)區(qū)塊存放的交易筆數(shù)的增加，同步的響應(yīng)時(shí)間減少.這是因?yàn)橥骄彺鏅C(jī)制通過(guò)實(shí)時(shí)跟蹤區(qū)塊塊高、同步最新交易以減少數(shù)據(jù)查詢(xún)時(shí)掃描整個(gè)區(qū)塊造成的 延遲，在待上鏈交易數(shù)量相同的情況下，單個(gè)區(qū)塊可存放的交易數(shù)越多，最后共識(shí)生成的區(qū)塊越少，因 此同步緩存機(jī)制掃描區(qū)塊的延遲越低.

5.5交易優(yōu)化處理性能

在數(shù)據(jù)管理中間件中，我們使用了提前哈希計(jì)算和批處理的方法來(lái)優(yōu)化數(shù)據(jù)插入過(guò)程，以減少頻 繁網(wǎng)絡(luò)通信所帶來(lái)的開(kāi)銷(xiāo).本節(jié)對(duì)I形式上鏈的交易分別使用SQL-CITA的同步處理和異步處理，固 定交易集為20 000筆，交易筆數(shù)從2000筆增長(zhǎng)到20000筆.圖12顯示，同步處理上鏈的響應(yīng)時(shí)間一 直高于異步處理上鏈的響應(yīng)時(shí)間，這是因?yàn)橥教幚硗ㄐ艜r(shí)，數(shù)據(jù)管理中間件要等待交易上鏈并返回 結(jié)果后才能繼續(xù)執(zhí)行下一筆交易，這種處理方式執(zhí)行效率低，而提前哈希計(jì)算大大縮短了上層響應(yīng)時(shí)間.

總結(jié)以上實(shí)驗(yàn)，本文提出的面向區(qū)塊鏈的數(shù)據(jù)管理中間件不僅降低了區(qū)塊鏈的使用成本，而且很 好地優(yōu)化了區(qū)塊鏈數(shù)據(jù)管理性能，大大提升了區(qū)塊鏈的應(yīng)用開(kāi)發(fā)效率.

6相關(guān)工作

隨著區(qū)塊鏈在金融、供應(yīng)鏈等數(shù)據(jù)密集型應(yīng)用中被廣泛采用，對(duì)存儲(chǔ)在區(qū)塊鏈中的數(shù)據(jù)的查詢(xún)需 求日益增長(zhǎng)[5].早期的區(qū)塊鏈所支持的數(shù)據(jù)管理能力有限[6]，通常只在銀行金融系統(tǒng)中被大量使用.為 了擴(kuò)展區(qū)塊鏈平臺(tái)上的數(shù)據(jù)管理功能，學(xué)術(shù)界越來(lái)越多的專(zhuān)家學(xué)者開(kāi)始對(duì)區(qū)塊鏈進(jìn)行深入研究，嘗試 將傳統(tǒng)數(shù)據(jù)庫(kù)和區(qū)塊鏈的優(yōu)點(diǎn)結(jié)合起來(lái)，設(shè)計(jì)出一個(gè)兼具安全可信性和管理高效性的系統(tǒng).

區(qū)塊鏈技術(shù)與數(shù)據(jù)管理工作融合的一個(gè)方向是向現(xiàn)有的分布式數(shù)據(jù)庫(kù)中添加區(qū)塊鏈的功能.基 于MongoDB構(gòu)建的BigChainDB[1]是一個(gè)典型的具有區(qū)塊鏈特點(diǎn)的數(shù)據(jù)庫(kù)，但是，其查詢(xún)方式依賴(lài) 于MongoDB原生接口，查詢(xún)性能也受限于MongoDB. ChainSQL構(gòu)建了一種基于區(qū)塊鏈網(wǎng)絡(luò)的日志 數(shù)據(jù)庫(kù)，豐富了區(qū)塊鏈的查詢(xún)接口，但其僅對(duì)外提供直接的函數(shù)方法而不是易于使用的接口.除此之 夕卜，還有Blockchain Relational Database161及FalconDB171等，這些區(qū)塊鏈數(shù)據(jù)庫(kù)雖然一·定程度上提升 了原區(qū)塊鏈的數(shù)據(jù)管理能力，但是其受限于底層存儲(chǔ)的有限查詢(xún)支持，未充分發(fā)揮出區(qū)塊鏈的全部 優(yōu)勢(shì).

區(qū)塊鏈與數(shù)據(jù)庫(kù)相結(jié)合的另一條探索路線是直接在區(qū)塊鏈系統(tǒng)及其可信賴(lài)的執(zhí)行模型之上建立 數(shù)據(jù)管理優(yōu)化技術(shù).相比前者，在區(qū)塊鏈的基礎(chǔ)上添加傳統(tǒng)數(shù)據(jù)庫(kù)的優(yōu)勢(shì)是提升數(shù)據(jù)管理性能更直接 的辦法，但將區(qū)塊鏈系統(tǒng)作為底層數(shù)據(jù)存儲(chǔ)平臺(tái)也會(huì)帶來(lái)新的問(wèn)題.其大體可分為兩種類(lèi)型.第一種 類(lèi)型的方法是采用分層架構(gòu).例如，BlockchainDB[3]在區(qū)塊鏈的上層添加了數(shù)據(jù)庫(kù)層，對(duì)內(nèi)提升區(qū)塊 鏈系統(tǒng)性能，對(duì)外提供方便易用的查詢(xún)接口，但是，其僅支持單一的PUT/GET操作.EtherQL[4]在底 層以太坊的上層設(shè)計(jì)了查詢(xún)層，將區(qū)塊鏈數(shù)據(jù)拷貝到查詢(xún)層中，通過(guò)查詢(xún)層提供的API接口實(shí)現(xiàn)查 詢(xún)功能，但是查詢(xún)層僅支持MongoDB作為外部數(shù)據(jù)存儲(chǔ)，不支持MySQL等關(guān)系數(shù)據(jù)庫(kù).第二種類(lèi)型 的方法則是將數(shù)據(jù)庫(kù)核心技術(shù)集成到區(qū)塊鏈系統(tǒng)中.SEBDB[2]是該類(lèi)方法的典型代表之一，在區(qū)塊鏈 系統(tǒng)中添加支持關(guān)系語(yǔ)義的查詢(xún)處理引擎，將交易數(shù)據(jù)組織成關(guān)系表的形式，并在區(qū)塊數(shù)據(jù)內(nèi)部添加 了索引結(jié)構(gòu)來(lái)加快查詢(xún)速度，但SEBDB[2]所支持的查詢(xún)功能有限，對(duì)其二次開(kāi)發(fā)難度大.

關(guān)于區(qū)塊鏈數(shù)據(jù)管理方面的研究工作涉及很廣泛，文獻(xiàn)[8-11]是關(guān)于區(qū)塊鏈在可信環(huán)境下的數(shù)據(jù) 管理問(wèn)題.除了數(shù)據(jù)管理的工作，區(qū)塊鏈系統(tǒng)在性能[12-15]、安全[16-18]和存儲(chǔ)[19-21]方面都取得了一定的發(fā)展.

7結(jié)束語(yǔ)

本文針對(duì)區(qū)塊鏈系統(tǒng)無(wú)法支持復(fù)雜查詢(xún)、對(duì)外提供查詢(xún)接口單一以及延遲高的問(wèn)題，提出了面向 區(qū)塊鏈的通用高效數(shù)據(jù)管理中間件.首先，本文采用自定義構(gòu)建數(shù)據(jù)模型的方式處理交易數(shù)據(jù)并對(duì)外 提供靈活的數(shù)據(jù)訪問(wèn)接口;其次，本文實(shí)現(xiàn)了同步緩存機(jī)制提升查詢(xún)效率;最后，本文設(shè)計(jì)異步批量處 理策略和提前哈希計(jì)算方法優(yōu)化吞吐和延遲.

本文還實(shí)現(xiàn)了以開(kāi)源區(qū)塊鏈系統(tǒng)CITA為底層的通用高效數(shù)據(jù)管理架構(gòu)SQL-CITA.實(shí)驗(yàn)結(jié)果表 明，本文的方法高效可行.但是在采用賬戶模型的區(qū)塊鏈中，除記錄日志的交易數(shù)據(jù)外還有狀態(tài)數(shù)據(jù). 因此，我們下一步工作重點(diǎn)是基于狀態(tài)數(shù)據(jù)優(yōu)化區(qū)塊鏈數(shù)據(jù)管理性能，并將繼續(xù)深入探究數(shù)據(jù)管理與 區(qū)塊鏈的融合，如統(tǒng)計(jì)計(jì)數(shù)、訪問(wèn)控制等技術(shù)的通用化設(shè)計(jì)開(kāi)發(fā)，我們也將進(jìn)一步探討查詢(xún)優(yōu)化與多 重加密策略.

[參考文獻(xiàn)]

[1]MCCONAGHY T，MARQUES R，MULLER A，et al. Bigchaindb： A scalable blockchain database [R]. White Paper，BigChainDB， 2016.

[2]ZHU Y，ZHANG Z，JIN C，et al. SEBDB： Semantics empowered blockchain database [C]//35th IEEE International Conference on Data Engineering. 2019： 1820-1831.

[3]ELHINDI M， BINNIG C， ARASU A， et al. Blockchaindb - A shared database on blockchains [J]. Proceedings of the VLDB Endowment，2019， 12（1（1）： 1597-1609.

[4] LI Y，ZHENG K，YAN Y，et al. Etherql： A query layer for blockchain system [C]//Database Systems for Advanced Applications 22nd International Conference. 2017： 556-567.

[5] LUU L，CHU D，OLICKEL H，et al. Making smart contracts smarter [C]//Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communi cations Security. 2016： 254-269.

[6] NATHAN S，GOVINDARAJAN C，SARAF A，et al. Blockchain meets database： Design and implementation of a blockchain relational

database [J]. Proceedings of the VLDB Endowment， 2019， 12（1（1）： 1539-1552.

[7] PENG Y， DU M， LI F， et al. Falcondb： Blockchain-based collaborative database [C]//Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data. 2020： 637-652.

[8]邵奇峰，金澈清，張召，等.區(qū)塊鏈技術(shù)：架構(gòu)及進(jìn)展[J].計(jì)算機(jī)學(xué)報(bào)，2018， 41（5）： 3-22.

[9]邵奇峰，張召，朱燕超，等.企業(yè)級(jí)區(qū)塊鏈技術(shù)綜述[J].軟件學(xué)報(bào)，2019， 30（9）： 2571-2592.

[10]錢(qián)衛(wèi)寧，邵奇峰，朱燕超，等.區(qū)塊鏈與可信數(shù)據(jù)管理：?jiǎn)栴}與方法[J].軟件學(xué)報(bào)，2018， 29（1）： 150-159.

[11]蔡磊，朱燕超，郭慶興，等.面向區(qū)塊鏈的高效物化視圖維護(hù)和可信查詢(xún)[J].軟件學(xué)報(bào)，2020， 31（3）： 680-694.

[12]SHARMA A， SCHUHKNECHT F M， AGRAWAL D， et al. Blurring the lines between blockchains and database systems： The case of hyperledger fabric [C]//SIGMOD Conference. 2019： 105-122.

[13]RUAN P， CHEN G， DINH T T A， et al. Finegrained， secure and efficient data provenance on blockchain systems [J] . Proceedings of the VLDB Endowment， 2019， 12（1（1）： 975-988.

[14]WANG J， WANG H. Monoxide： Scale out blockchains with asynchronous consensus zones [C]//USENIX Symposium on Networked Systems Design and Implementation. 2019： 95-112.

[15]DANG H， DINH T T A， LOGHIN D， et al. Towards scaling blockchain systems via sharding [C]//SIGMOD Conference. 2019： 123140.

[16]WANG H， XU C， ZHANG C， et al. Vchain： A blockchain system ensuring query integrity [C]//Proceedings of the 2020 International Conference on Management of Data. 2020： 2693-2696.

[17]AMIRI M J， AGRAWAL D， ABBADI A E. CAPER： A cross-application permissioned blockchain [J]. Proceedings of the VLDB Endowment， 2019， 12（1（1）： 1385-1398.

[18]XU Z， HAN S， CHEN L. Cub， aconsensusunit-based storage scheme for blockchain system [C] //34th IEEE International Conference on Data Engineering. 2018： 173-184.

[19]ZHANG C， XU C， XU J， et al. Gem2-tree： A gas-efficient structure for authenticated range queries in blockchain [C]//35th IEEE International Conference on Data Engineering. 2019： 842-853.

[20]WANG S， DINH T T A， LIN Q， et al. Forkbase： An efficient storage engine for blockchain and forkable applications [J]. Proceedings of the VLDB Endowment， 2018， 11（10）： 1137-1150.

[21]AL-BASSAM M， SONNINO A， BANO S， et al. Chainspace： A sharded smart contracts platform [C] //25th Annual Network and Distributed System Security Symposium： abs/1708.03778. 2018.

（責(zé)任編輯：李萬(wàn)會(huì)）