范俊松，陳建海，沈 睿，劉振廣，何欽銘，黃步添

1.浙江大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，浙江杭州310027

2.杭州云象網(wǎng)絡(luò)技術(shù)有限公司，浙江杭州310012

3.浙江工商大學(xué)計(jì)算機(jī)與信息工程學(xué)院，浙江杭州310018

區(qū)塊鏈技術(shù)提供去中心化的信任機(jī)制以確保數(shù)據(jù)存儲(chǔ)的安全性和可靠性，能依靠去中心化的節(jié)點(diǎn)處理以及自動(dòng)執(zhí)行的智能合約來防止用戶的請(qǐng)求歷史與習(xí)慣等被特定的第3 方獲取。與傳統(tǒng)交易方式相比，基于區(qū)塊鏈的交易在保護(hù)用戶隱私安全方面更具優(yōu)勢。大量不同規(guī)模的區(qū)塊鏈網(wǎng)絡(luò)在比特幣[1]、以太坊[2]、超級(jí)賬本[3]等典型區(qū)塊鏈架構(gòu)的基礎(chǔ)上誕生并逐漸投入實(shí)際應(yīng)用，為多個(gè)領(lǐng)域的從業(yè)者和開發(fā)者提供服務(wù)。

在移動(dòng)支付盛行的當(dāng)下，區(qū)塊鏈系統(tǒng)也需要提供移動(dòng)端的交易發(fā)起功能與交易確認(rèn)機(jī)制，但大部分移動(dòng)設(shè)備無法支持存儲(chǔ)區(qū)塊鏈全部數(shù)據(jù)的空間需求，因而大多數(shù)區(qū)塊鏈系統(tǒng)根據(jù)簡單支付驗(yàn)證（simple payment verification,SPV）模式[1]為區(qū)塊鏈網(wǎng)絡(luò)使用者提供輕量型客戶端的解決方案。移動(dòng)設(shè)備運(yùn)行的客戶端只存儲(chǔ)區(qū)塊鏈網(wǎng)絡(luò)的極少部分索引數(shù)據(jù)，依靠存儲(chǔ)著區(qū)塊鏈全部數(shù)據(jù)的全節(jié)點(diǎn)完成區(qū)塊鏈交易功能。然而，簡單運(yùn)用SPV 模式帶來了一定風(fēng)險(xiǎn)，如果大量輕量型客戶端接入同一個(gè)全節(jié)點(diǎn)，區(qū)塊鏈網(wǎng)絡(luò)就在全節(jié)點(diǎn)處產(chǎn)生中心化現(xiàn)象，此時(shí)用戶的交易請(qǐng)求記錄會(huì)被全節(jié)點(diǎn)獲取。在這種情景下，提供全節(jié)點(diǎn)服務(wù)的系統(tǒng)或者與全節(jié)點(diǎn)在同一物理平臺(tái)上的特權(quán)軟件能夠收集區(qū)塊鏈用戶的請(qǐng)求，匹配用戶信息與用戶請(qǐng)求內(nèi)容，而這些相關(guān)性正是區(qū)塊鏈系統(tǒng)所極力避免的。此外，區(qū)塊鏈的地址等密碼學(xué)信息提高了區(qū)塊鏈系統(tǒng)的入門門檻，不利于區(qū)塊鏈技術(shù)的推廣。因此，區(qū)塊鏈系統(tǒng)急需輕量型客戶端解決方案來兼顧隱私安全性和使用便利性。

1 研究現(xiàn)狀與存在問題

關(guān)于簡單運(yùn)用SPV 模式帶來的隱私安全風(fēng)險(xiǎn)，之前的研究在一定程度上給出了解決方案。Hearn 和Corallo 在BIP-37[4]中介紹了Bloom 過濾器，在SPV 模式的基礎(chǔ)上提出了改進(jìn)措施?？蛻舳藢⑸梢粋€(gè)Bloom 過濾器并發(fā)送給區(qū)塊鏈的全節(jié)點(diǎn)，凡是在全節(jié)點(diǎn)上符合該過濾器條件的交易都會(huì)發(fā)送給對(duì)應(yīng)的客戶端，從而將用戶真實(shí)需求的交易隱藏在更大的交易集合中達(dá)到隱藏用戶地址的目的，因此基于Bloom 過濾器的方案已用于大部分區(qū)塊鏈系統(tǒng)。此外，文獻(xiàn)[5] 也提出了一種修改方案，由全節(jié)點(diǎn)創(chuàng)建過濾器發(fā)送給客戶端，再由客戶端檢查該過濾器處理后的交易集合中是否包含特定交易，從而決定是否還要向該全節(jié)點(diǎn)請(qǐng)求交易集合。文獻(xiàn)[6] 提出了BITE 系統(tǒng)，以軟件防護(hù)擴(kuò)展（software guard executions,SGX）機(jī)制和茫然隨機(jī)訪問機(jī)（oblivious random access machine,ORAM）的思路保護(hù)比特幣輕量型客戶端，對(duì)訪問和存儲(chǔ)進(jìn)行茫然化處理后將數(shù)據(jù)處理部分放置在安全區(qū)中加以保護(hù)。

上述方案雖然在一定程度上為區(qū)塊鏈交易提供了隱私安全保護(hù)，但在隱私安全性和用戶友好性方面仍存在局限性。

1.1 隱私安全性有待提高

文獻(xiàn)[7] 指出，Bloom 過濾器的原理是將目標(biāo)地址隱藏在一系列地址中，但攻擊者仍能以很高的正確率猜測出用戶的目標(biāo)地址，這對(duì)于交易的隱私性來說是致命的。如果在云服務(wù)器上架設(shè)全節(jié)點(diǎn)服務(wù)器，那么用戶的請(qǐng)求數(shù)據(jù)最終仍以明文方式存放在用戶級(jí)內(nèi)存上，不可避免地遭到惡意軟件、特權(quán)軟件和操作系統(tǒng)的窺探和竊取，可見這類系統(tǒng)存在著暴露用戶信息的風(fēng)險(xiǎn)。

與Bloom 過濾器的方式相比，基于SGX 的BITE 系統(tǒng)為比特幣交易提供了更好的安全防護(hù)和更少的性能開銷，但尚未在比特幣以外以智能合約為主導(dǎo)的主流區(qū)塊鏈系統(tǒng)中實(shí)現(xiàn)。

1.2 用戶友好性存在缺陷

現(xiàn)有的區(qū)塊鏈錢包具有一定的入門門檻，而提高用戶友好性又會(huì)帶來安全問題。在以分層確定性（hierarchical deterministic,HD）錢包[8]為代表的協(xié)議中，根據(jù)區(qū)塊鏈的隱私性設(shè)計(jì)要求可知區(qū)塊鏈用戶錢包無法直接與用戶身份相綁定，其地址也不支持掛失和找回功能。在一般情況下，用戶會(huì)選擇使用輔助記憶工具（例如隨身便簽、其他網(wǎng)絡(luò)存儲(chǔ)服務(wù)等）來保存生成錢包的助記詞，因?yàn)樵撦o助工具的安全性直接影響錢包的安全性。

在實(shí)際使用中，接收交易的用戶通常對(duì)外公開地址的公鑰。因?yàn)槎鄠€(gè)交易使用同一個(gè)地址可能暴露用戶隱私，所以安全交易的最佳方案就是為每次交易創(chuàng)建地址并發(fā)送給交易對(duì)象，但嚴(yán)重影響了交易效率。對(duì)于Trezor 等支持?jǐn)U展公鑰的錢包，可以使用擴(kuò)展公鑰為每次交易自動(dòng)生成獨(dú)立的地址，但是將該擴(kuò)展公鑰公開給第3 方會(huì)暴露用戶的所有交易歷史，在滿足使用便利性要求的同時(shí)也引起了安全性問題。

2 關(guān)鍵技術(shù)

2.1 Intel SGX 安全保護(hù)技術(shù)

Intel 于2013年提出了SGX[9]，包括基于Intel CPU 的SGX 指令及其對(duì)應(yīng)的安全保護(hù)機(jī)制。在SGX 提供的設(shè)計(jì)理念中，程序可分為可信部分和不可信部分。SGX 能夠?yàn)榭尚挪糠值拇a和數(shù)據(jù)創(chuàng)建可信的加密內(nèi)存區(qū)域—— 安全區(qū)，從而保證運(yùn)行過程中代碼的完整性和數(shù)據(jù)的一致性。安全區(qū)基于硬件支持提供加密和安全保護(hù)，其數(shù)據(jù)只允許授權(quán)部分的代碼訪問，而任何同一平臺(tái)上的惡意軟件、特權(quán)軟件甚至是操作系統(tǒng)本身都無法在未經(jīng)授權(quán)的前提下訪問，從而防止安全區(qū)內(nèi)部的數(shù)據(jù)泄露，杜絕安全區(qū)執(zhí)行過程中的數(shù)據(jù)和代碼的惡意篡改。SGX采用遠(yuǎn)程認(rèn)證機(jī)制確保安全區(qū)本身是可信的，于是通信發(fā)起方可根據(jù)官方提供的認(rèn)證服務(wù)器驗(yàn)證SGX 安全區(qū)是否正確運(yùn)行。為了在SGX 內(nèi)部實(shí)現(xiàn)加密，Intel 提供了基于開源密碼學(xué)庫OpenSSL 的SGX SSL 庫，為SGX 安全區(qū)提供密碼學(xué)支持，因此對(duì)數(shù)據(jù)的加解密操作不再需要外部不可信部分的支持。

基于SGX SSL 加密庫，Intel 為SGX 提供了受保護(hù)的文件系統(tǒng)庫（SGX protected file system library,SGX PFS）。通過SGX PFS 生成與訪問的文件只能使用在安全區(qū)內(nèi)隨機(jī)生成的密鑰進(jìn)行加密，經(jīng)加密后的文件存放于本地存儲(chǔ)介質(zhì)。若不通過額外渠道保存密鑰，則該加密文件只能由生成該文件的安全區(qū)在一次生命周期中訪問，而其他安全區(qū)以及安全區(qū)外的不可信部分都無權(quán)訪問；該安全區(qū)在重啟后將會(huì)丟失密鑰，也無權(quán)再訪問該文件，從而確保文件讀寫的機(jī)密性。

上述措施并不能完全保證數(shù)據(jù)的安全性，雖然使用了SGX PFS 但也可能有部分信息被外部程序與操作系統(tǒng)所探知。在本系統(tǒng)涉及的數(shù)據(jù)訪問要素中，僅憑SGX PFS 無法保護(hù)讀寫操作時(shí)涉及到的訪問偏移量，以致暴露此次訪問對(duì)象的數(shù)據(jù)訪問模式—— 存儲(chǔ)位置信息。惡意攻擊者即使無法獲知信息的確切內(nèi)容也能根據(jù)統(tǒng)計(jì)學(xué)原理推斷出用戶隱私，必須采用額外的保護(hù)措施來隱藏隱私數(shù)據(jù)的訪問模式。

2.2 ORAM 技術(shù)與應(yīng)用現(xiàn)狀

ORAM 最初由Goldreich 等[10]提出，是一種由數(shù)據(jù)混洗與再加密等技術(shù)組成的算法。當(dāng)客戶端訪問遠(yuǎn)程服務(wù)器上的數(shù)據(jù)時(shí)，該算法可以隱藏?cái)?shù)據(jù)訪問模式，保證了客戶端訪問的安全性。ORAM 算法的基本思路如下：對(duì)數(shù)據(jù)進(jìn)行訪問時(shí)附帶對(duì)大量冗余數(shù)據(jù)的請(qǐng)求，因此在數(shù)據(jù)存儲(chǔ)的服務(wù)端側(cè)，即使攻擊者在數(shù)據(jù)存儲(chǔ)的服務(wù)端側(cè)觀察到物理存儲(chǔ)的訪問位置，也無法了解到客戶端真實(shí)的數(shù)據(jù)訪問模式，而客戶端側(cè)可以從返回的大量數(shù)據(jù)中挑選真實(shí)需求的數(shù)據(jù)。

目前已有多種基于ORAM 的改進(jìn)算法[11]，但ORAM 本身的應(yīng)用存在局限性。與直接進(jìn)行文件訪問相比，ORAM 方法在提高安全性的同時(shí)卻帶來了巨額的性能開銷。在ORAM算法中，即使是性能最優(yōu)的Path ORAM[12]算法，在磁盤讀寫和網(wǎng)絡(luò)通信方面也會(huì)帶來lbN級(jí)別的開銷[11]。鑒于磁盤讀寫速度遠(yuǎn)大于網(wǎng)絡(luò)通信速度，成倍的磁盤讀寫需求對(duì)系統(tǒng)執(zhí)行效率的影響微乎其微，而成倍的網(wǎng)絡(luò)通信需求將直接影響系統(tǒng)處理請(qǐng)求的最大并行量，因此系統(tǒng)產(chǎn)生的額外通信帶寬將成為ORAM 算法實(shí)用化的最大瓶頸。

當(dāng)改變系統(tǒng)環(huán)境的安全假設(shè)，將安全可信的粒度從單個(gè)物理系統(tǒng)細(xì)化到單個(gè)應(yīng)用程序甚至應(yīng)用程序的單個(gè)部分時(shí)，網(wǎng)絡(luò)通信將不再成為性能評(píng)估需要考慮的部分，且額外的磁盤讀寫需求也是實(shí)際可容忍的性能開銷。在之前有關(guān)SGX 的研究中，就有Oblix[13]、ZeroTrace[14]以及OBLIVIATE[15]等在SGX 內(nèi)采用ORAM 算法實(shí)現(xiàn)相關(guān)功能，這也給本文的系統(tǒng)設(shè)計(jì)提供了思路。因此，在可信執(zhí)行環(huán)境所構(gòu)筑的安全假設(shè)中，ORAM 技術(shù)成了隱藏?cái)?shù)據(jù)訪問模式、實(shí)現(xiàn)安全數(shù)據(jù)訪問的一種可能的解決方案。

3 SGXTrans 系統(tǒng)設(shè)計(jì)

3.1 系統(tǒng)模型

本文提出的系統(tǒng)包含四部分：區(qū)塊鏈客戶端及其用戶C、提供密鑰托管服務(wù)的服務(wù)器S1（又稱為密鑰服務(wù)器）、運(yùn)行區(qū)塊鏈全節(jié)點(diǎn)并提供交易驗(yàn)證服務(wù)的服務(wù)器S2（又稱為交易服務(wù)器）以及區(qū)塊鏈網(wǎng)絡(luò)B。其中，服務(wù)器S1與S2不必在物理層面上分離，服務(wù)提供者可以在同一臺(tái)服務(wù)器上同時(shí)運(yùn)行密鑰托管服務(wù)和交易驗(yàn)證服務(wù)。服務(wù)器S1與S2的核心安全程序分別運(yùn)行在安全區(qū)E1與E2中。系統(tǒng)的簡要模型如圖1所示。

圖1 SGXTrans 系統(tǒng)架構(gòu)Figure 1 SGXTrans architecture

本文為SGXTrans 的具體實(shí)行方式提出了以下2 種可行的方案：密鑰托管方案和全權(quán)托管方案。對(duì)于第1 種方案，密鑰服務(wù)器S1僅為用戶存儲(chǔ)密鑰，而與交易服務(wù)器S2的交互由客戶端C獨(dú)立完成。對(duì)于第2 種方案，客戶端C將與區(qū)塊鏈相關(guān)的功能全權(quán)托管給密鑰服務(wù)器S1。用戶在進(jìn)行區(qū)塊鏈相關(guān)請(qǐng)求的過程中，所有的實(shí)際請(qǐng)求內(nèi)容均由密鑰服務(wù)器S1代為生成。密鑰服務(wù)器S1作為客戶端用戶的代理人，持有用戶的密鑰，可以根據(jù)客戶端C的指示請(qǐng)求生成實(shí)際請(qǐng)求后與交易服務(wù)器S2進(jìn)行通信。

以上2 種方案的關(guān)鍵區(qū)別如下：第1 種方案的密鑰最終交由用戶自行處理，這便于用戶對(duì)自身密鑰以及交易采取不受本系統(tǒng)約束的操作行為，為用戶尤其是該領(lǐng)域?qū)＜以谑褂帽鞠到y(tǒng)提供安全保障的同時(shí)并不限制他們的操作行為。第2 種方案的用戶在整個(gè)請(qǐng)求過程中均不會(huì)獲得與用戶密鑰相關(guān)的任何數(shù)據(jù)，降低了用戶密鑰在客戶端側(cè)被竊取的可能性；此外，與密鑰相關(guān)的請(qǐng)求交由服務(wù)器安全區(qū)自動(dòng)運(yùn)行，于是區(qū)塊鏈服務(wù)的提供者可以在服務(wù)端側(cè)添加用戶密鑰相關(guān)的管理功能而不必?fù)?dān)心用戶隱私問題，因此區(qū)塊鏈上的交易與用戶行為經(jīng)過程序封裝后更貼近傳統(tǒng)交易方式，且用戶友好性高。

3.2 安全假設(shè)

本節(jié)將對(duì)SGXTrans 系統(tǒng)的安全性范圍以及相關(guān)系統(tǒng)假設(shè)給出如下說明：

1）客戶端安全性

本文假設(shè)用戶側(cè)的客戶端本地環(huán)境是安全的，客戶端的請(qǐng)求在經(jīng)過HTTPS 協(xié)議打包之前不會(huì)泄露。

2）安全區(qū)安全性

本文假設(shè)Intel 提供的SGX 安全保護(hù)機(jī)制是安全的，安全區(qū)內(nèi)的數(shù)據(jù)和代碼既不會(huì)被任何不可信的外部程序訪問又不會(huì)在攻擊者的攻擊下泄露。

3）服務(wù)器安全性

在本文設(shè)想的安全環(huán)境中，服務(wù)器S1與S2可運(yùn)行不可信的操作系統(tǒng)與惡意攻擊軟件，而在服務(wù)器上運(yùn)行的安全區(qū)E1與E2則運(yùn)行SGXTrans 核心程序，由SGX 安全保護(hù)機(jī)制確?？尚?。此外，允許網(wǎng)絡(luò)通信環(huán)境不可信。

4 運(yùn)行過程及安全分析

本節(jié)闡述了SGXTrans 系統(tǒng)的整個(gè)運(yùn)行過程，包含初始化階段、密鑰托管階段和交易處理階段，分析了運(yùn)行流程的數(shù)據(jù)安全性以及潛在攻擊場景，從而闡明了系統(tǒng)的安全性。

4.1 初始化階段

在初始化階段，密鑰服務(wù)器和交易服務(wù)器執(zhí)行相似的初始化過程，主要包括SGX 程序的環(huán)境監(jiān)測和本地文件的創(chuàng)建。特別地，系統(tǒng)需要通過加密存儲(chǔ)模塊為安全區(qū)處理數(shù)據(jù)過程中產(chǎn)生的持久化數(shù)據(jù)和狀態(tài)提供本地介質(zhì)的存儲(chǔ)功能，以減少占用的內(nèi)存。

在文件的讀寫過程中，使用SGX PFS 確保秘密讀寫，根據(jù)Path ORAM 算法將所讀寫的數(shù)據(jù)以鍵值對(duì)的形式存儲(chǔ)在加密文件中，避免數(shù)據(jù)訪問模式造成的隱私泄露。密鑰服務(wù)器S1存儲(chǔ)用戶身份驗(yàn)證信息與對(duì)應(yīng)的區(qū)塊鏈密鑰，交易服務(wù)器S2存儲(chǔ)區(qū)塊鏈地址和包含該地址的交易信息。每個(gè)鍵值對(duì)為一條記錄，存放在Path ORAM 的二叉樹節(jié)點(diǎn)的數(shù)據(jù)塊中，記錄的ORAM 位置圖信息和記錄緩存都存放在SGX 安全區(qū)的可信內(nèi)存中，無法被外部程序訪問。

由于數(shù)據(jù)按塊存儲(chǔ)，存在單條記錄過長而無法存入單個(gè)數(shù)據(jù)塊中的情況。在本文系統(tǒng)中，這通常意味著單個(gè)用戶持有過多區(qū)塊鏈密鑰或單個(gè)區(qū)塊鏈地址關(guān)聯(lián)過多交易，因而并非常見現(xiàn)象，且能通過設(shè)計(jì)單個(gè)數(shù)據(jù)塊和單條記錄的長度上限而減小發(fā)生的可能性。本文為每條記錄加入了參數(shù)group，能使過長的數(shù)據(jù)分段存儲(chǔ)與讀寫。同時(shí)，為了減少數(shù)據(jù)分段、提高系統(tǒng)運(yùn)行效率，根據(jù)大部分區(qū)塊鏈系統(tǒng)的實(shí)踐調(diào)研評(píng)估結(jié)果，最終采用32 kB 的數(shù)據(jù)塊、每塊包含16 條記錄的形式進(jìn)行數(shù)據(jù)存儲(chǔ)。

在系統(tǒng)運(yùn)行過程中，密鑰服務(wù)器S1的數(shù)據(jù)由用戶請(qǐng)求來更新，而交易服務(wù)器S2的數(shù)據(jù)由區(qū)塊鏈中新區(qū)塊的產(chǎn)生來更新。這意味著交易服務(wù)器S2需要監(jiān)聽區(qū)塊鏈的區(qū)塊更新，當(dāng)產(chǎn)生新區(qū)塊時(shí)，需要及時(shí)解析區(qū)塊中的交易內(nèi)容并更新至本地存儲(chǔ)。關(guān)于更新過程中產(chǎn)生的數(shù)據(jù)不一致性可能會(huì)造成的影響，本文將于第5 節(jié)的實(shí)驗(yàn)部分進(jìn)行說明。

4.2 密鑰托管階段

在密鑰托管階段，用戶側(cè)客戶端C向密鑰服務(wù)器S1發(fā)起密鑰托管請(qǐng)求。用戶的請(qǐng)求數(shù)據(jù)包括以下3 項(xiàng)內(nèi)容：1）用戶的密鑰服務(wù)請(qǐng)求類型，在這里為密鑰托管請(qǐng)求；2）用戶的身份驗(yàn)證數(shù)據(jù)；3）用戶的公私密鑰地址。特別是當(dāng)用戶的密鑰地址為空時(shí)，密鑰服務(wù)器S1可為用戶生成對(duì)應(yīng)區(qū)塊鏈上新的密鑰地址。

密鑰托管階段涉及到用戶側(cè)客戶端C向服務(wù)器發(fā)送隱私信息的過程。在本系統(tǒng)所設(shè)想的安全環(huán)境中，各端之間的通信網(wǎng)絡(luò)是不可信的。為了確保用戶的數(shù)據(jù)在通信過程中不被第3方監(jiān)聽、竊取與篡改，本系統(tǒng)采用HTTPS 協(xié)議防止隱私數(shù)據(jù)泄露。

然而，若直接運(yùn)用HTTPS 協(xié)議，那么服務(wù)器上的惡意軟件等仍然能夠在通信數(shù)據(jù)經(jīng)協(xié)議解密后以直接讀取內(nèi)存的方式獲取通信數(shù)據(jù)的明文內(nèi)容，因而數(shù)據(jù)的解密過程必須在SGX安全區(qū)提供的可信內(nèi)存空間中進(jìn)行。本系統(tǒng)引入并修改了OpenSSL 庫的HTTPS 通信相關(guān)函數(shù)，在確保HTTPS 協(xié)議正確執(zhí)行的同時(shí)將用于加密的公私密鑰置于SGX 安全區(qū)內(nèi)，且服務(wù)端側(cè)的數(shù)據(jù)加密與解密過程均移至SGX 安全區(qū)內(nèi)進(jìn)行。

除此以外，本文系統(tǒng)采用統(tǒng)一包格式以及隨機(jī)時(shí)間發(fā)送無效數(shù)據(jù)包的方式來防止基于數(shù)據(jù)包大小和請(qǐng)求時(shí)間的攻擊。統(tǒng)一包格式指數(shù)據(jù)包大小全部統(tǒng)一為固定值，不會(huì)因請(qǐng)求中數(shù)據(jù)長度而發(fā)生變化，于是對(duì)小于該固定值的數(shù)據(jù)進(jìn)行填充，對(duì)大于該固定值的數(shù)據(jù)分割后分別填充。隨機(jī)時(shí)間發(fā)送無效數(shù)據(jù)包的方式可以防止攻擊者通過用戶請(qǐng)求時(shí)間和區(qū)塊鏈上交易產(chǎn)生時(shí)間的比對(duì)來縮小用戶密鑰范圍，從而防止攻擊者多次嘗試后推斷出用戶密鑰。

基于上述安全措施，用戶通過特制的用戶側(cè)客戶端向密鑰服務(wù)器S1發(fā)起密鑰托管請(qǐng)求，將用戶身份驗(yàn)證數(shù)據(jù)與用戶密鑰發(fā)送給密鑰服務(wù)器。密鑰服務(wù)器S1利用4.1 節(jié)所述的本地加密存儲(chǔ)方式將用戶密鑰進(jìn)行本地存儲(chǔ)。之后，用戶可通過之前提供的用戶身份驗(yàn)證數(shù)據(jù)來訪問獲取對(duì)應(yīng)的用戶密鑰，用該密鑰參與區(qū)塊鏈交易。

4.3 交易請(qǐng)求階段

在密鑰服務(wù)器S1提取到用戶密鑰以后，由于用戶的密鑰托管方案以及交易請(qǐng)求類型的不同，客戶端與服務(wù)器之間將產(chǎn)生不同的數(shù)據(jù)流。

4.3.1 密鑰托管方案

在密鑰托管方案中，用戶首先向密鑰服務(wù)器S1發(fā)送密鑰獲取請(qǐng)求，隨后密鑰服務(wù)器S1根據(jù)用戶請(qǐng)求附帶的用戶身份信息提取到用戶密鑰。通過HTTPS 通信將用戶密鑰返回給用戶側(cè)客戶端之后，密鑰服務(wù)器S1不再參與數(shù)據(jù)處理。用戶獲取到用戶密鑰后，通過用戶密鑰獨(dú)自與交易服務(wù)器S2進(jìn)行HTTPS 通信。

在交易驗(yàn)證請(qǐng)求中，用戶側(cè)客戶端C向交易服務(wù)器S2發(fā)送請(qǐng)求的內(nèi)容包括交易驗(yàn)證請(qǐng)求標(biāo)識(shí)和請(qǐng)求驗(yàn)證的公鑰列表。交易服務(wù)器一旦接收到交易驗(yàn)證請(qǐng)求，便會(huì)根據(jù)請(qǐng)求驗(yàn)證的公鑰列表從本地加密存儲(chǔ)中提取對(duì)應(yīng)的交易列表，將其打包后返回給用戶。該過程以及后續(xù)所述通信過程的安全保護(hù)措施均與密鑰托管階段相同。用戶側(cè)的客戶端接收到交易列表后，即可進(jìn)行交易驗(yàn)證。

在交易構(gòu)造請(qǐng)求中，用戶側(cè)客戶端C向交易服務(wù)器S2發(fā)送請(qǐng)求的內(nèi)容包括交易構(gòu)造請(qǐng)求標(biāo)識(shí)、用戶的公私鑰數(shù)據(jù)、用戶的交易內(nèi)容。用戶的交易具體內(nèi)容由區(qū)塊鏈具體數(shù)據(jù)結(jié)構(gòu)來決定。交易服務(wù)器S2接收到交易構(gòu)造請(qǐng)求后，首先檢查交易內(nèi)容所包含的各項(xiàng)數(shù)據(jù)是否滿足交易構(gòu)造條件；然后根據(jù)用戶提交的交易輸入方密鑰列表，在本地加密存儲(chǔ)的交易數(shù)據(jù)庫中查詢密鑰對(duì)應(yīng)的所有交易，從而單獨(dú)執(zhí)行交易可行性的驗(yàn)證。若交易構(gòu)造請(qǐng)求內(nèi)容滿足交易構(gòu)造條件并通過了交易可行性驗(yàn)證，則根據(jù)區(qū)塊鏈具體設(shè)計(jì)方案生成對(duì)應(yīng)的區(qū)塊鏈交易請(qǐng)求，再由交易服務(wù)器S2上運(yùn)行的全節(jié)點(diǎn)發(fā)布到區(qū)塊鏈網(wǎng)絡(luò)上。

4.3.2 全權(quán)托管方案

全權(quán)托管方案與密鑰托管方案的核心不同點(diǎn)在于：由密鑰服務(wù)器S1直接與交易服務(wù)器S2進(jìn)行交互，而用戶側(cè)客戶端C只接收由密鑰服務(wù)器S1發(fā)回的信息對(duì)請(qǐng)求處理結(jié)果進(jìn)行確認(rèn)。

在交易驗(yàn)證請(qǐng)求中，用戶側(cè)客戶端C直接向密鑰服務(wù)器S1發(fā)送交易驗(yàn)證請(qǐng)求，請(qǐng)求的內(nèi)容包括交易驗(yàn)證請(qǐng)求標(biāo)識(shí)和用戶的身份驗(yàn)證數(shù)據(jù)。密鑰服務(wù)器根據(jù)用戶身份信息提取到密鑰后直接向交易服務(wù)器發(fā)送交易驗(yàn)證請(qǐng)求，之后的過程與密鑰托管方案的交易驗(yàn)證請(qǐng)求處理過程相同。在收到交易服務(wù)器S2返回的交易列表后，密鑰服務(wù)器S1可以對(duì)交易信息進(jìn)行再處理，有選擇地將處理結(jié)果返回給用戶。

在交易構(gòu)造請(qǐng)求過程中，用戶側(cè)客戶端C直接向密鑰服務(wù)器S1發(fā)送交易構(gòu)造請(qǐng)求，請(qǐng)求的內(nèi)容包括交易構(gòu)造請(qǐng)求標(biāo)識(shí)、用戶的身份驗(yàn)證數(shù)據(jù)、用戶的交易內(nèi)容。密鑰服務(wù)器S1根據(jù)用戶身份信息提取密鑰后向交易服務(wù)器S2發(fā)送交易構(gòu)造請(qǐng)求，之后的過程與密鑰托管方案的交易構(gòu)造請(qǐng)求處理過程相同。值得注意的是：由于交易內(nèi)容會(huì)提交到密鑰服務(wù)器S1，密鑰服務(wù)器S1可以對(duì)交易內(nèi)容進(jìn)行二次處理，這意味著可以通過密鑰服務(wù)器S1的額外設(shè)計(jì)提供密鑰共享、額度管理等賬戶操作。由于此類行為可在安全區(qū)內(nèi)獨(dú)立完成，不必讓用戶承擔(dān)額外的密鑰泄露風(fēng)險(xiǎn)。

4.4 關(guān)鍵數(shù)據(jù)流分析

本節(jié)將分析SGXTrans 中的關(guān)鍵數(shù)據(jù)流，進(jìn)而闡明SGXTrans 系統(tǒng)是如何確保數(shù)據(jù)可信的。圖2展示了SGXTrans 中的關(guān)鍵數(shù)據(jù)流，但省略了建立可信通道以及SGXTrans 所用安全區(qū)以外的應(yīng)用程序部分的數(shù)據(jù)交互過程。當(dāng)采用全權(quán)托管方案時(shí)，g、h的數(shù)據(jù)流如實(shí)線所示；當(dāng)采用托管密鑰方案時(shí)，g、h的數(shù)據(jù)流如虛線所示。接下來對(duì)兩端之間或服務(wù)器內(nèi)部的數(shù)據(jù)流分別進(jìn)行分析。

圖2 SGXTrans 的關(guān)鍵數(shù)據(jù)流Figure 2 SGXTrans critical data flow

1）客戶端C與服務(wù)器S1

客戶端C與服務(wù)器S1之間涉及數(shù)據(jù)a、b。數(shù)據(jù)a為客戶端發(fā)起的請(qǐng)求，包含了用戶的身份驗(yàn)證信息，在全權(quán)托管方案中還額外包含了對(duì)服務(wù)器S2的請(qǐng)求數(shù)據(jù)。這些內(nèi)容將在客戶端側(cè)根據(jù)HTTPS 協(xié)議使用約定的加密密鑰進(jìn)行加密。數(shù)據(jù)b包含安全區(qū)E1生成的請(qǐng)求處理結(jié)果，該結(jié)果在安全區(qū)內(nèi)根據(jù)HTTPS 協(xié)議使用約定的加密密鑰進(jìn)行加密。因此，在服務(wù)器S1上安全區(qū)E1以外的部分無法訪問到這些信息，而在與客戶端C的通信過程中只能得知請(qǐng)求發(fā)起的時(shí)間。

2）客戶端C與服務(wù)器S2

客戶端C與服務(wù)器S2之間涉及密鑰托管方案中的數(shù)據(jù)g、h。數(shù)據(jù)均以HTTPS 協(xié)議加密傳輸，但不在安全區(qū)外進(jìn)行解密操作。因此，服務(wù)器S1上的其他程序在與客戶端C的通信過程中只能得知請(qǐng)求發(fā)起的時(shí)間。

3）服務(wù)器S1與S2

服務(wù)器S1與S2之間涉及全權(quán)托管方案中的數(shù)據(jù)g、h。數(shù)據(jù)均以HTTPS 協(xié)議加密傳輸，且不在安全區(qū)外進(jìn)行解密操作。在此過程中，服務(wù)器S2無法得知該數(shù)據(jù)與哪一個(gè)客戶端關(guān)聯(lián)。因此，服務(wù)器S1上的其他程序在與服務(wù)器S2的通信過程中只能得知請(qǐng)求發(fā)起的時(shí)間，而無法得知該訪問的最初發(fā)起客戶端。

4）服務(wù)器S1和S2內(nèi)部

服務(wù)器S1和S2內(nèi)部之間涉及數(shù)據(jù)c、d、e、f和i、j、k、l。數(shù)據(jù)c和i將HTTPS 協(xié)議的加密數(shù)據(jù)送往安全區(qū)；數(shù)據(jù)d和j（不包括交易明文內(nèi)容）將依照HTTPS 協(xié)議要求加密后的數(shù)據(jù)送至安全區(qū)外。在這兩個(gè)過程中，系統(tǒng)都無法得知數(shù)據(jù)的明文內(nèi)容。數(shù)據(jù)e、f、k、l涉及對(duì)本地存儲(chǔ)介質(zhì)的讀寫過程。由于SGXTrans 結(jié)合了SGX PFS 與ORAM 算法，外部程序無法得知本地文件的明文內(nèi)容，也無法得知安全區(qū)真實(shí)需求的數(shù)據(jù)所在位置，因此服務(wù)器上的其他程序在服務(wù)器內(nèi)部處理過程中只能得知數(shù)據(jù)訪問的時(shí)間以及數(shù)據(jù)j中由安全區(qū)程序構(gòu)造完成的交易明文內(nèi)容，但無法得知該訪問的最初發(fā)起客戶端。

5）服務(wù)器S2和區(qū)塊鏈網(wǎng)絡(luò)B

服務(wù)器S2和區(qū)塊鏈網(wǎng)絡(luò)B之間涉及數(shù)據(jù)m和n。數(shù)據(jù)m是服務(wù)器S2向區(qū)塊鏈網(wǎng)絡(luò)廣播明文的交易內(nèi)容，由于區(qū)塊鏈網(wǎng)絡(luò)中存在大量交易轉(zhuǎn)發(fā)現(xiàn)象，任一區(qū)塊鏈節(jié)點(diǎn)都無法得知該交易的最初發(fā)起者。數(shù)據(jù)n是服務(wù)器S2與區(qū)塊鏈網(wǎng)絡(luò)同步區(qū)塊的數(shù)據(jù)，該過程不存在任何隱私數(shù)據(jù)。

綜上所述，在本系統(tǒng)的數(shù)據(jù)流中位于不可信部分的數(shù)據(jù)，除了最終生成的交易內(nèi)容之外均以密文的形式存在。在真實(shí)請(qǐng)求以外存在一定量頻率的無效請(qǐng)求，因此針對(duì)時(shí)間的攻擊難以獲得成效，所有加密數(shù)據(jù)也難以與發(fā)起請(qǐng)求的客戶端產(chǎn)生關(guān)聯(lián)。最終生成明文交易的請(qǐng)求都已經(jīng)過安全區(qū)的處理，并在全權(quán)托管方案中經(jīng)過密鑰服務(wù)器的處理，故真實(shí)請(qǐng)求發(fā)起的最初來源和時(shí)間難以被惡意攻擊者探知，也就無法將該交易聯(lián)系到任一客戶端。

4.5 潛在攻擊場景分析

由于確保了數(shù)據(jù)流的安全，SGXTrans 排除了第3 方監(jiān)聽造成隱私泄露的可能性，但仍無法說明其他積極性攻擊行為對(duì)該系統(tǒng)可能造成的影響。本節(jié)將闡述并分析可能的攻擊場景，從而進(jìn)一步闡明SGXTrans 的安全性與可靠性。

4.5.1 偽造請(qǐng)求

攻擊者嘗試通過偽造合法請(qǐng)求來獲取其他用戶的數(shù)據(jù)，在本系統(tǒng)的場景中分為2 種攻擊方式：1）嘗試偽造其他用戶身份來獲取用戶數(shù)據(jù)，2）嘗試使用合法客戶端來獲取其他用戶數(shù)據(jù)。對(duì)于第1 種攻擊方式，SGXTrans 確保了安全的數(shù)據(jù)流，使攻擊者無法從本系統(tǒng)的數(shù)據(jù)流中直接獲取用戶身份。即便使用重放攻擊，攻擊者也只能接收到加密的響應(yīng)包而無法獲取具體的用戶數(shù)據(jù)。對(duì)于第2 種攻擊方式，即使攻擊者持有合法的身份，本系統(tǒng)也只會(huì)返回與該攻擊者合法用戶身份對(duì)應(yīng)的用戶數(shù)據(jù)，因此攻擊者無法獲取其他用戶的數(shù)據(jù)，也無法通過偽造請(qǐng)求發(fā)動(dòng)有效攻擊。

4.5.2 系統(tǒng)偽裝

在一個(gè)已運(yùn)行有SGXTrans 的服務(wù)器上，攻擊者會(huì)嘗試另行開啟一個(gè)經(jīng)過惡意修改的SGXTrans 系統(tǒng)，從而嘗試以下2 種攻擊方式：1）偽造本系統(tǒng)與用戶客戶端建立聯(lián)系而直接獲取用戶請(qǐng)求內(nèi)容；2）偽造本系統(tǒng)讀取本地存儲(chǔ)的加密用戶密鑰數(shù)據(jù)庫與加密交易數(shù)據(jù)庫。對(duì)于第1 種攻擊方式，客戶端可憑借遠(yuǎn)程認(rèn)證機(jī)制檢查該安全區(qū)中運(yùn)行代碼的摘要，確保安全區(qū)內(nèi)代碼不會(huì)遭到惡意修改。只要安全區(qū)內(nèi)代碼正常執(zhí)行，改造系統(tǒng)的持有者就無法獲得用戶的任何信息。對(duì)于第2 種攻擊方式，鑒于各安全區(qū)的加密文件相互獨(dú)立，加密文件所需密鑰也只在安全區(qū)代碼運(yùn)行過程的可信內(nèi)存中隨機(jī)生成而不會(huì)泄露給外部，即使運(yùn)行一個(gè)偽造系統(tǒng)也無法讀取現(xiàn)有加密文件的真實(shí)內(nèi)容。因此，攻擊者無法通過系統(tǒng)偽裝方法發(fā)動(dòng)有效攻擊。

4.5.3 本地文件破壞

系統(tǒng)在運(yùn)行過程中會(huì)生成加密的持久化數(shù)據(jù)。若攻擊者嘗試直接刪除這部分文件，則會(huì)對(duì)系統(tǒng)的運(yùn)行造成影響。在實(shí)際部署過程中，可以在同一個(gè)區(qū)塊鏈網(wǎng)絡(luò)中部署多個(gè)獨(dú)立運(yùn)行本系統(tǒng)的交易服務(wù)器，以避免服務(wù)的失效。針對(duì)密鑰托管功能，客戶端可搜索具有該功能的服務(wù)器，將自身的密鑰在不同服務(wù)器上備份；針對(duì)交易驗(yàn)證和構(gòu)造功能，服務(wù)器的加密交易數(shù)據(jù)庫由區(qū)塊鏈數(shù)據(jù)產(chǎn)生，即使本地文件遭到破壞，系統(tǒng)檢測到該情況后也可以通過掃描區(qū)塊鏈來重新生成該加密文件。因此，本地文件的破壞雖然對(duì)系統(tǒng)的響應(yīng)能力產(chǎn)生影響，但不會(huì)對(duì)系統(tǒng)的安全性造成影響。

5 實(shí)驗(yàn)與分析

本文基于上述內(nèi)容實(shí)現(xiàn)了SGXTrans 的原型系統(tǒng)，該系統(tǒng)使用SGX SDK 2.9.1 版本、SGX SSL 2.9 版本（基于openssl-1.1.1d 重構(gòu)）、gcc 7.5.0 版本構(gòu)建，運(yùn)行于Docker 提供的Ubuntu18.04（64 bit）鏡像中。隨后根據(jù)VNTChain[16]的主網(wǎng)交易數(shù)據(jù)歷史進(jìn)行存儲(chǔ)性能分析，并運(yùn)用該系統(tǒng)在VNTChain 的測試網(wǎng)上進(jìn)行請(qǐng)求測試。測試部分將系統(tǒng)架設(shè)于Intel(R)Xeon(R) E3-1240 v6 CPU(3.70 GHz) 以及16 GB 內(nèi)存的支持SGX 功能的服務(wù)器上。

5.1 存儲(chǔ)能力測試

本文系統(tǒng)需要在內(nèi)存中存放各類臨時(shí)數(shù)據(jù)和持久數(shù)據(jù)，由于臨時(shí)數(shù)據(jù)數(shù)量少、其空間能夠反復(fù)利用，本節(jié)將僅討論持久數(shù)據(jù)，主要為各服務(wù)器上的ORAM 位置圖信息。密鑰服務(wù)器S1以及交易服務(wù)器S2的內(nèi)存持久數(shù)據(jù)存儲(chǔ)能力與SGXTrans 安全區(qū)內(nèi)存堆大小的關(guān)系如圖3所示，圖中采用了對(duì)數(shù)坐標(biāo)軸，可見其基本為線性關(guān)系。因?yàn)閷?duì)于絕大部分區(qū)塊鏈地址，單個(gè)數(shù)據(jù)塊足以存下對(duì)應(yīng)交易，所以對(duì)應(yīng)位置數(shù)組中只存儲(chǔ)了一條ORAM 路徑。當(dāng)安全區(qū)內(nèi)存為64 MB 時(shí)，交易服務(wù)器內(nèi)存中的最大索引數(shù)量約為260 000 個(gè)交易地址，這超過了VNTChain 現(xiàn)有的賬戶數(shù)量。對(duì)于密鑰服務(wù)器，由于一個(gè)用戶通常擁有數(shù)個(gè)甚至數(shù)十個(gè)交易地址，密鑰服務(wù)器的存儲(chǔ)需求遠(yuǎn)小于交易服務(wù)器。因此，本系統(tǒng)可以安全地存儲(chǔ)所有數(shù)據(jù)。對(duì)于需要存儲(chǔ)更多索引數(shù)量的區(qū)塊鏈網(wǎng)絡(luò)（如以太坊等），可以采用二次ORAM 方法將位置圖信息也在本地存儲(chǔ)介質(zhì)上加密保存。

圖3 服務(wù)器內(nèi)存持久數(shù)據(jù)記錄數(shù)量與安全區(qū)內(nèi)存堆大小關(guān)系Figure 3 Relation between persistent data in server memory and heap size of enclave

在SGXTrans 系統(tǒng)，安全區(qū)除了內(nèi)存存儲(chǔ)以外還要在本地介質(zhì)維護(hù)持久化數(shù)據(jù)，因此需要考慮系統(tǒng)產(chǎn)生的額外磁盤存儲(chǔ)需求。本文基于VNTChain 的交易歷史統(tǒng)計(jì)了交易量和存儲(chǔ)空間的對(duì)比情況，對(duì)總交易量N，大約需要O(lbN) 的存儲(chǔ)空間才能滿足對(duì)交易的本地存儲(chǔ)。在VNTChain 主網(wǎng)上，當(dāng)本地存儲(chǔ)空間為26.3 GB 時(shí)，進(jìn)行SGXTrans 部署所消耗的額外存儲(chǔ)空間為256 MB。由此可見，在VNTChain 主網(wǎng)節(jié)點(diǎn)上部署SGXTrans 帶來的額外空間開銷僅為1%。由于不同區(qū)塊鏈系統(tǒng)的交易與地址之間的比率也不同，預(yù)計(jì)其他以太坊架構(gòu)的區(qū)塊鏈系統(tǒng)使用SGXTrans 在全節(jié)點(diǎn)服務(wù)器上的額外空間開銷不超過5%。

5.2 數(shù)據(jù)更新測試

本文針對(duì)SGXTrans 系統(tǒng)運(yùn)行過程中產(chǎn)生的不同深度的ORAM 二叉樹分別構(gòu)建1 000次數(shù)據(jù)更新請(qǐng)求，最后計(jì)算其平均值從而獲得單次數(shù)據(jù)更新耗時(shí)的測試結(jié)果。圖4展示了ORAM 數(shù)據(jù)庫二叉樹深度與平均每次數(shù)據(jù)更新的關(guān)系。

圖4 ORAM 二叉樹深度與平均每次數(shù)據(jù)更新耗時(shí)的關(guān)系Figure 4 Relation between ORAM binary tree depth and time per data updating

隨著區(qū)塊鏈用戶和區(qū)塊鏈上交易數(shù)據(jù)的增多，ORAM 數(shù)據(jù)庫二叉樹深度將逐步增加，單個(gè)數(shù)據(jù)更新耗時(shí)與二叉樹深度基本呈線性關(guān)系。由于用戶密鑰的產(chǎn)生速度遠(yuǎn)低于區(qū)塊鏈交易產(chǎn)生的速度，因而只需重點(diǎn)考慮區(qū)塊鏈交易數(shù)據(jù)更新對(duì)服務(wù)器性能的影響。以平均每秒產(chǎn)生15 個(gè)交易、平均每次數(shù)據(jù)更新花費(fèi)20 ms 來估計(jì)，服務(wù)器每秒需要花費(fèi)約1/3 的時(shí)間來更新區(qū)塊鏈數(shù)據(jù)。一方面，這意味著SGXTrans 能夠普遍支持區(qū)塊鏈數(shù)據(jù)的處理，如以太坊大約需要13 s 產(chǎn)生一個(gè)平均包含200 個(gè)交易的新區(qū)塊；另一方面，由于該處理時(shí)間會(huì)對(duì)用戶請(qǐng)求處理造成影響，本文推薦采用多個(gè)系統(tǒng)交叉并行的方式。

5.3 請(qǐng)求處理測試

表1和2 展示了本文提出的兩種方案在VNTChain 上進(jìn)行300 次模擬請(qǐng)求的平均測試結(jié)果，包括各階段的網(wǎng)絡(luò)通信、外部程序本地處理、安全區(qū)加密數(shù)據(jù)讀寫、安全區(qū)其他處理等耗時(shí)。

表1 密鑰服務(wù)器請(qǐng)求處理耗時(shí)測試Table 1 Cost time of key server request handling test ms

表2 交易服務(wù)器請(qǐng)求處理耗時(shí)測試Table 2 Cost time of transaction server request handling test ms

由表1和2 可知，在本系統(tǒng)執(zhí)行過程中，網(wǎng)絡(luò)通信占據(jù)了大部分時(shí)間，而安全區(qū)的處理時(shí)間僅占總時(shí)間的4%。加密讀寫以外的操作復(fù)雜度均為O(1)，不會(huì)對(duì)系統(tǒng)運(yùn)行總耗時(shí)造成較大的影響。隨著區(qū)塊鏈系統(tǒng)上數(shù)據(jù)量的增加，加密讀寫過程的時(shí)間耗時(shí)也隨之增加。由5.2 節(jié)測試數(shù)據(jù)推算，SGXTrans 在現(xiàn)有的各類區(qū)塊鏈系統(tǒng)上擁有不超過10%的額外時(shí)間開銷。

考慮到網(wǎng)絡(luò)通信占比較大，將密鑰服務(wù)器與交易服務(wù)器合并于同一臺(tái)物理設(shè)備。以本地通信代替網(wǎng)絡(luò)通信能大幅減少全權(quán)托管方案的系統(tǒng)運(yùn)行耗時(shí)，但是對(duì)密鑰托管方案沒有幫助，這也是本文更推薦全權(quán)托管方案的另一個(gè)原因。開發(fā)者可根據(jù)測試結(jié)果和實(shí)際需要綜合考慮實(shí)施方案。

6 結(jié) 語

本文針對(duì)區(qū)塊鏈技術(shù)在實(shí)踐過程中出現(xiàn)的使用性問題與隱私安全性問題，在探索已有解決方法時(shí)發(fā)現(xiàn)現(xiàn)行的區(qū)塊鏈輕量型客戶端及其改進(jìn)方案并不能有效解決上述問題，于是在前人研究的基礎(chǔ)上使用SGX 安全保護(hù)機(jī)制和ORAM 技術(shù)給區(qū)塊鏈交易設(shè)計(jì)了SGXTrans系統(tǒng)，不但為區(qū)塊鏈用戶從密鑰管理到交易請(qǐng)求等一系列過程提供了強(qiáng)大的隱私安全保護(hù)，而且安全地向?qū)τ脩綦[藏了區(qū)塊鏈的密碼學(xué)細(xì)節(jié)，提高了系統(tǒng)的實(shí)用性。經(jīng)分析和實(shí)驗(yàn)表明：SGXTrans 系統(tǒng)具有良好的性能，有望成為區(qū)塊鏈交易隱私安全保護(hù)的一種行之有效的解決方案。