基于密碼累加器的無狀態區塊鏈性能優化

孫林昆，蔣文保，郭陽楠，李春強

（北京信息科技大學 信息管理學院，北京 100192）

0 概述

區塊鏈由于其去中心化、防篡改和可追溯等特點，引起了金融機構、投資機構、監管部門以及政府部門的廣泛關注。但目前區塊鏈仍存在較多技術難點，如性能問題就是其中之一。區塊鏈在不同場景下的應用都因高冗余存儲增強了數據的公開性、透明性和去中心化，提高了系統的可用性；但另一方面，每個節點都需要同步并保存系統中所有的賬本數據。此外，共識節點為了驗證交易，需要存儲賬戶余額以及系統中各種智能合約的當前狀態，這使得參與共識協議的成本更高，也給區塊鏈帶來性能問題和巨大的存儲壓力。

針對上述問題，許多學者進行了大量研究。與傳統的存儲方案不同，比特幣［1］采用一種SPV 的方式緩解存儲問題，但隨著存儲量的增多，會有更多的節點無法承擔全節點的存儲需求，從而轉變為輕節點，降低網絡的去中心化程度。文獻［2］通過IPFS協議將交易存儲進鏈下，鏈上保存交易的索引，該文主要針對基于UTXO 模型的區塊鏈設計，未考慮基于賬戶模型區塊鏈的存儲及智能合約執行情況。文獻［3］通過分片技術降低了單個節點的存儲負擔，同時提高了區塊鏈系統的吞吐量，然而該系統中的跨分片交易存在分叉攻擊的威脅，并且該系統需要執行一個代價高昂的節點重新分配協議，以增強系統安全性。文獻［4］提出在 DHT 網絡中驗證新交易和新區塊以保存區塊鏈數據，然而該系統需要頻繁訪問網絡來申請狀態數據，并且不具有數據緩存功能，具有較大的網絡開銷。文獻［5］采用糾刪碼的方法有效降低了系統中區塊數據的冗余存儲數量，然而共識節點在執行交易時需要進行頻繁的網絡請求來恢復區塊數據，給網絡帶來一定的負擔。

近年來，無狀態區塊鏈的概念［6-7］被提出，無狀態區塊鏈通過減少節點的狀態數據存儲量從而減少存儲負載。然而，現有的無狀態區塊鏈系統［7-8］大部分是為加密貨幣設計的，而試圖開發支持智能合約的通用無狀態區塊鏈將面臨新的問題。首先在一般應用程序中，由智能合約支持的事務可能包含任意邏輯，這需要新的證明技術來證明合約執行的完整性；其次智能合約交易會引入任意大小的讀寫集，這比簡單的加密貨幣交易復雜得多，需要額外設計來支持狀態承諾更新［9］。

本文提出一種基于密碼累加器的無狀態區塊鏈性能優化方案STiPChain。采用RSA 累加器生成具有分布式存儲能力的合約有效性證明（Contract Validity Proof，CVP）技術，并基于該技術構建無狀態區塊鏈，共識節點不再保存區塊數據，而只需保存合約累加值及合約有效性證明降低磁盤和內存的負擔。在此基礎上，STiPChain 將有效性證明與可驗證計算技術相結合，設計一種適用于智能合約的無狀態區塊鏈，以解決無狀態條件下智能合約運行驗證問題。

1 相關工作

1.1 無狀態區塊鏈

以Ethereum［10］為代表的區塊鏈2.0 是基于交易的狀態機，從創世區塊開始，通過交易持續不斷地改變區塊鏈狀態。區塊鏈狀態信息描述了系統中賬戶和余額的當前狀態，以及在區塊鏈虛擬機中部署和運行的所有智能合約的參數數據。鏈上每個最終確定的區塊都有且只有一個狀態，這是由網絡中的所有參與者共同確認的。每當有新的區塊產生時，系統狀態都會隨之更新。

在無狀態區塊鏈中，用戶和共識節點都不需要存儲完整的系統狀態。相反，所有賬戶的當前狀態以及在EVM 中部署和運行的所有智能合約的集體組成的狀態使用經過驗證的數據結構在所有節點中分配。通過這種方式，共識節點只存儲系統狀態的簡要摘要，每個用戶存儲他們的自身狀態數據。共識節點仍然可以驗證收集到的交易，這些交易中包含了合約的有效性證明。此外，共識節點仍然可以提出新的事務塊，用戶也可以在發布新塊時快速同步或更新他們的證明。

文獻［11］提出一種基于RSA 累加器的改進型輕節點，極大地優化了輕節點的存儲空間，但是并沒有解決全節點存儲問題。文獻［12］基于RSA 累加器提出一種適用于UTXO 模型的無狀態客戶端，可以較好地優化共識節點的存儲問題，但并不能適用于智能合約的驗證。文獻［6］提出一種無狀態交易驗證的通用框架EDRAX，所有節點只需持有最新被確認的區塊即可驗證交易并更新狀態，但是EDRAX 僅支持對賬號的余額進行驗證。文獻［7］首先針對通用累加器和向量承諾，提出了批處理技術，極大地提升了累加器的驗證效率并降低了傳輸開銷。然而，該累加器只適用于基于UTXO 模型的無狀態公有鏈，同時在不知道群階的情況下，RSA 累加器批量刪除操作的復雜度為O（n2），導致累加器更新效率低，無法適用于高吞吐量的環境。文獻［8］通過KZG 多項式承諾［13］構造新的向量承諾方案aSVC，使用一個更強的交叉承諾聚合概念，將不同向量承諾的多個子向量證明聚合為一個單一的、恒定大小的證明。該方法雖然可以高效地支持加密貨幣轉賬交易，卻不能支持智能合約所需的任意計算邏輯。

1.2 可驗證計算技術

可驗證計算技術［14］確保遠端計算機計算行為與期望一致，同時確保任意參與者可以檢測和監視整個過程，可驗證計算通常由基于密碼學和基于硬件2 種方式實現。以SNARKs［15］為代表的基于密碼學［16-17］的可驗證計算技術由于密碼原語的存在，通常具有較高的計算量。相比之下，基于安全硬件的解決方案效率更高，如以Intel Software Guard eXtension（SGX）［18］為代表的可信執行環境（TEE）［19］，可以將計算任務在可信執行環境中以保證數據完整性的方式執行。

文獻［20］提出將計算與共識解耦，計算節點在線下的TEE 環境中完成隱私數據的計算，并向區塊鏈提供正確計算的證明。共識節點維護區塊鏈賬本以及驗證計算節點計算的正確性，將可信執行環境和區塊鏈相結合，實現了高效的隱私數據處理。

本文主要考慮使用基于TEE 的解決方案，TEE提供了一個完全隔離的環境，可以防止其他軟件應用程序、操作系統和主機所有者了解甚至篡改在TEE 中運行的應用程序的狀態。例如SGX 提供了TEE 的實現，Keystone-enclave 項目［21］旨在提供開源TEE 設計。然而，值得注意的是：本文提出的性能優化方案可以與上述任何可驗證計算解決方案共同工作。

2 STiPChain 系統架構

STiPChain 將傳統區塊鏈中共識節點存儲系統中的全部智能合約的狀態數據轉變為存儲各合約的有效性證明，將智能合約的狀態數據抽象為hash 摘要，并通過RSA 累加器完成各智能合約摘要的累加與合約有效性證明的創建。同時，各節點不必存儲所有智能合約的有效性證明，而是可以根據節點本身需求存儲相對應合約的hash 摘要及有效性證明，從而極大地降低系統及系統中單個節點的存儲量。

此外，STiPChain 將區塊共識與區塊執行解耦，由提議節點執行合約事務并生成交易，共識節點負責提出區塊共識與新區塊。用戶在提交交易時，首先由提議節點在本地可驗證計算環境中執行智能合約，之后采用Remote Attention 機制對TEE 進行認證，系統中任意節點可以檢查提議節點是否正確地加載了智能合約與合約參數以及運算結果完整性的驗證。共識節點基于合約有效性證明生成技術快速驗證合約狀態摘要的合法性，并通過Remote Attention 機制驗證智能合約的執行情況，從而解決智能合約在無狀態環境下的驗證問題。可驗證計算確保了智能合約在提議節點本地得到了正確執行，共識節點不再需要在區塊鏈虛擬機中執行智能合約字節碼完成系統狀態更新，而只需要更新合約有效性證明即可完成，從而有效提高系統吞吐量。

1）提議節點：接收用戶交易請求，在本地TE 環境中運行智能合約并在交易中附上可驗證計算證明，使得共識節點可以在不保存合約狀態信息的情況下完成交易執行的驗證。

2）共識節點：運行共識協議并維護區塊鏈全局狀態的一致性。接收提議節點在區塊鏈網絡中廣播交易并存儲至交易池中，從交易池中打包一批交易組成候選區塊進行檢查與執行，并提出新的區塊。

STiPChain 系統架構如圖1 所示。

圖1 STiPChain 系統架構Fig.1 STiPChain system architecture

3 基于密碼累加器的合約有效性證明

密碼累加器技術由文獻［22］提出，目的是證明一個元素是否存在于集合中的問題。它將集合中的元素X=｛x1，x2，…，xn｝累加到一個值AAcc上，并為各元素生成存在性證明π，從而可以通過（AAcc，xi，πi）快速判斷元素存在性問題。當前很多學者基于不同的密碼工具給出了不同的構造，可分為基于RSA 的累加器、基于雙線性映射的累加器和基于Merkle 樹的累加器［23］。

合約有效性證明（CVP）基于RSA 累加器設計，重要符號說明如表1 所示。在CVP中，Alice 存儲n個元素xi的一個恒定大小的累加值AAcc。元素xi本身不是由Alice 存儲，而是分配給n個參與方，除元素xi外，每一個參與方都持有對AAcc的證明πi。當Alice 希望通過u′更新合約狀態u的累加元素時，其應該能夠通過僅訪問信息（u，u′）輕松地將AAcc更新為A′Acc。也就是說，與Merkle 樹不同，更新是獨立于其他元素的。類似地，當參與方i得知更新（u，u′）時，應該同樣能夠有效地只通過訪問（u，u′）更新證明（πi→）。

表1 符號說明 Table 1 Description of symbols

CVP 非常適合區塊鏈中的智能合約模式，共識節點存儲各合約的有效性證明累加值AAcc，每個智能合約有效性證明用πi標識，通過（πi，xi，u，πTEE→u′）的交易形式標識一條智能合約xi從狀態摘要u改變狀態到u′。在檢測πTEE是合法的情況下合約狀態證明更新πi→，同時共識節點更新AAcc→，以便將累加值包括在新區塊，使得所有其他提議節點同步它們的相應證明πi。

3.1 初始化Gen（λ）的設置

借鑒文獻［7］中的RSA 累加器設計，將累加器建立在未知階的群上，避免進行可信的初始化設置。通過參數λ，生成累加器初始值g，并隨機挑選2 個大素數p、q，生成N=p×q。

3.2 合約有效性證明WitAccCreate（Acci-1）的創建

提議節點將創建合約的請求打包進交易中發送至共識節點。設Acci-1為創建此合約時系統中保存的最新累加值。此時，Acci-1中不包括當前要創建的合約的狀態摘要。基于RSA 累加器特點，由RSA 累加器AAcc計算式（1）及證據計算式（2）定義得累加器中元素i的有效性證明，可由除i之外的其他元素集合來表示，因此合約xi的有效性證明可由Acci-1表示，通過文獻［24］完成hash 轉為素數。

3.3 合約有效性證明WitAccUpdate（AAcc，u′，N）的更新

當系統發布新區塊時，共識節點需要更新累加值AAcc，同時各提議節點需要完成其保存的合約有效性證明πi的更新。由于在不知道群階的情況下RSA累加器更新合約有效性證明的時間復雜度為O（n），而CVP 基于區塊鏈的區塊特性以及狀態驅動特點，使得合約有效性證明更新的時間復雜度降低為O（1）。在區塊鏈中，每當系統發布新的區塊時，各節點都需要接收該區塊并同步更新自身合約有效性證明。獲取合約i更新后的狀態摘要u′，通過式（3）將AAcc更新到，合約有效性證明通過式（4）更新至。

該方法可以有效防范惡意節點通過合約歷史有效性證明πoldi發起雙花攻擊。當產生新區塊后AAcc→，若惡意節點將πoldi作為當前合約的有效性證明，則根據式（5）及hash 函數的抗碰撞性，惡意節點很難成功發起雙花攻擊。

3.4 合約有效性證明WitAccVerify（AAcc，π，u）的驗證

共識節點需要完成合約狀態證據的合法性驗證。｛0，1｝←WitAccVerify（AAcc，π，u）：驗證者使用合約有效性證明累加值AAcc檢查合約狀態u的證據π是否有效。若等于AAcc，則表示證據有效輸出1，否則證據無效輸出0。

4 交易流程及關鍵算法

STiPChain 實現了由傳統區塊鏈中共識節點冗余存儲各合約的狀態數據轉變為保存各合約狀態證明，提議節點在TEE 中運行智能合約，共識節點檢查交易可驗證計算證明πTEE，從而使得各節點無須運行智能合約，也可以完成全局狀態的更新。

4.1 交易流程

本節介紹共識節點如何在不保存狀態信息的情況下完成交易的驗證與執行，以及如何在區塊鏈網絡中保持狀態信息的一致性。STiPChain 的交易處理流程如下：

1）用戶通過提議節點發起交易請求來調用智能合約，分別表示交易的輸入參數以及交易的簽名信息。

2）提議節點接收到交易請求后，提取本地狀態摘要、要執行的智能合約及相關參數，轉發到TEE 中進行計算，獲取交易讀寫集及改變后的合約狀態摘要。

3）執行完成后將可驗證計算證明、交易讀寫集及本地當前合約狀態摘要（u，u′）嵌入該交易中，將交易進行廣播發送。

4）共識節點接收候選交易，存入交易池中。滿足交易閾值后將交易池中的交易打包為候選區塊。在創建新區塊時，每個區塊頭除了包含交易的Merkle 樹根外，還包含了由所有智能合約狀態組成的CVP 累加值。當新區塊產生后，需要向CVP 中添加區塊中新的合約狀態，構造新的CVP 累加值。經過相應的共識算法后發布新區塊。

5）提議節點接收新發布的區塊，并更新本地CVP 承諾以及合約有效證明。

交易流程如圖2 所示。

圖2 STiPChain 交易流程Fig.2 STiPChain transaction procedure

4.2 交易創建

為了提供足夠的信息用于共識節點在無狀態環境下的合約驗證，提出一種新的基于TEE 的交易生成算法。如算法1 所示，它接收2 個輸入：1）來自用戶的交易請求txi；2）用戶對交易請求的簽名sign。

當提議節點發起交易時，首先在TEE 環境中執行交易所調用的智能合約，將生成的讀寫集寫回數據庫并重新計算此時的合約狀態摘要。此外，將提議節點中保存的合約狀態ui，以及更新后的合約狀態′ 一并通過Remote Attention 機制進行簽名，用于防止節點惡意篡改合約數據以及系統中其他節點對數據完整性的檢查。將運行后的結果打包進交易并廣播發送給共識節點。

算法1提議節點交易執行

4.3 區塊創建

共識節點完成區塊創建工作，在創建區塊時首先通過Remote Attention 機制驗證該條交易的可驗證計算證明。若驗證通過，則證明該交易被正確執行，即修改后的合約狀態可信，完成該條交易驗證。共識節點重復n次，完成區塊中所有交易的驗證，根據相應的共識算法發布區塊，并將該區塊添加到本地賬本中，其余節點同步更新本地合約狀態摘要。提議節點驗證通過后，從交易中取出合約狀態hash，通過CVP 驗證合約狀態摘要是否合法。引入緩存，使得交易可以在接下來的k個區塊時間內被處理，避免因為網絡延遲導致的交易驗證頻繁失敗的問題。k是一個系統參數，由系統中的所有參與者共同制定。

假設最后一個被計算的是blockt，而共識節點競爭的是blockt+1。共識節點收集新交易并打包為候選區塊，采用算法2 生成新區塊。在blockt+1中，需要包含新的累加值。其中，txs表示共識節點從交易池中打包的一批交易，h表示當前系統中的區塊高度（輸入）。算法流程如下：檢查該條交易是否屬于最近的k個區塊；解析交易并檢查sign 是否為該用戶下的有效簽名；檢查πTEE是否為可驗證計算的有效簽名；檢查πi是否為合約xi的有效證明，其中為區塊t的合約累加值；將AAcc更新參數放入緩存，該區塊驗證結束后進行更新并填入新區塊，同時節點可根據自己需要完成對智能合約i的證據更新。

算法2共識節點交易驗證

4.4 證據同步

Alice 在接收到新區塊后，運行區塊中的數據并更新本地合約有效證據。πi是合約xi的本地狀態證明，它對應到blockt之前的合約狀態。當系統中發生了新的交易并且創建了blockt+1時，系統的世界狀態發生改變，Alice 的本地驗證πi不再有效，持有合約xi的節點必須同步新的證明，以確保它包含所有更新。blockt+1中包含新的合約狀態（u1，′），（u2，u′2），…，（ui，）。為此，Alice 通過運行π←WitAccUpdate（AAcc，ui，N）并執行算法3，輸出一個新的同步驗證。Alice 從blockt+1中進行同步，基于Remote Attention 機制和本地存儲的合約狀態πi確保合約狀態進行正確的更新，然后更新本地證明。需要注意的是：Alice 在進行同步時運行與共識節點交易驗證相同的算法來驗證區塊合法性并完成狀態同步。此外，各提議節點并不需要保存系統中所有合約的有效性證明，可根據節點自身需求保存相應合約的有效性證明。

算法3提議節點合約有效性證明同步

5 性能測試

本節量化了STiPChain 每種優化的性能收益，測試了CVP 證據大小和CVP 更新效率以及系統吞吐量和節點的存儲開銷，評估了STiPChain 的5 個應用，1 個同臺加密計算合約，并通過Solidity 語言實現鏈上的基于同態加密的加減運算。ERC20 轉賬操作、鏈上文件保存操作、數據加密和鏈上明文計算5個合約運行在EVM中。與Ethereum 主網相比，STiPChain 可以在定長時間內完成交易驗證及狀態證明更新，支持吞吐量更高、存儲量更低的合約運算。表2 所示為STiPChain 與其他區塊鏈優化方案的對比，其中：√表示是；×表示否。

表2 STiPChain 與現有區塊鏈優化方案的對比 Table 2 Comparison between STiPChain and existing blockchain optimization schemes

5.1 實驗環境設置

將區塊鏈系統部署在4 臺阿里云ecs.c7t.large 服務器，每臺服務器運行4個節點，配置Intel Xeon（Ice Lake）Platinum 8369B 處理器，內存為4 GB，網絡帶寬為10 Gibit/s，安裝Alibaba Cloud Linux 操作系統。

5.2 合約有效性證明大小

本節主要完成不同狀態承諾技術的證據大小測試。實驗結果如圖3 所示，Boneh、Edrax 及STiPChain 的合約有效性證明大小隨著累加元素的增多一直維持在1 KB左右，不隨累加元素的增多而增大。然而，Merkle 樹產生的證據大小遠大于Boneh 及STiPChain，并且隨著累加元素的增多以lbN的增長速度增大，當累加元素個數為10 000時，證據大小達到了626 KB。Ethereum 普通區塊包含一個區塊頭和交易列表，其大小約為100 KB，這種大小可以使得區塊廣播速度較快。但若采用Merkle樹承諾方案會對網絡帶寬帶來較大負擔，系統中網絡延遲較高。

圖3 合約有效性證明大小測試結果Fig.3 Test results of contract validity certificate size

5.3 合約有效性證明更新

本節主要測試合約有效性證明的更新效率，該效率直接影響了系統的吞吐能力。Boneh 使用RSA 累加器構建 UTXO 承諾，承諾更新的時間復雜度為O（n），Edrax 基于向量承諾方案實現更新操作的時間復雜度為O（lognlog logn），而STiPChain 基于區塊鏈的全局狀態一致性，只需要進行添加操作即可完成合約的有效性證明更新，更新時間復雜度為O（1）。

圖4 所示為STiPChain、Edrax 與Boneh 累加器的更新效率對比。Boneh 更新時延隨著累加元素的增多明顯增高，當累加元素個數為1 600時，更新時延為17 033 μs。Edrax 方案隨著累加元素個數的增多增長緩慢，當累加元素個數為從100 增長到1 600時，更新時延從83 μs 增長到152 μs；STiPChain 的更新時延不隨元素個數的增多而增長，維持在24 μs 左右。實驗結果表明，CVP 更新時延最低，而Boneh 累加器更新時延遠大于STiPChain 與Edrax，并且隨著累積狀態數量的增多明顯增高。當操作數量達到1 400時，Boneh 累加器更新時間是CVP 的16 000倍，這就導致依賴于Boneh 狀態承諾的無狀態客戶端設計面臨嚴重的性能問題。

圖4 合約證明更新效率測試結果Fig.4 Test results of contract certification renewal efficiency

5.4 存儲開銷

本節主要評估系統的存儲開銷，分別測試了Ethereum Geth 模式下全節點、文獻［4］及STiPChain 中狀態數據的空間開銷。獲取了Ethereum從20190101—20220101 期間運行全節點所需存儲空間的數據變化（https：//etherscan.io/chartsync/chaindefault），并與文獻［4］和STiPChain 進行對比實驗。此外，本文將緩存參數k設置為16，可保證大多數交易被處理。

圖5 所示為狀態數據存儲開銷對比，Ethereum 在20220101已經超過了1 TB 并以極快的速度繼續增長。在20190101—20220101 期間，文獻［4］共識節點存儲量由17 743 553 KB 增長到89 506 154 KB，通過采用分布式哈希表的方法有效降低了節點的存儲負擔，但仍然遠高于STiPChain。相較于Ethereum 中全節點需要保存全部的區塊數據及狀態數據才可驗證與執行區塊中的任意交易，STiPChain 中共識節點保存AAcc，所占存儲空間不到1 KB。獲取要驗證交易中包含的合約有效性證明π，通過交易驗證算法即可完成交易驗證與狀態更新，從而有效降低共識節點的存儲需求。此外，通過僅存儲AAcc完成交易驗證，使得系統中的狀態存儲空間不隨運行時間的增長而明顯增長，從而降低共識節點99%的存儲壓力。

圖5 存儲空間優化測試結果Fig.5 Test results of storage space optimization

截止到20201006，以太坊中已經包含了31 949 110條智能合約以及87 570 650 條用戶地址信息。雖然STiPChain 將共識節點中的區塊及狀態數據采用合約有效性證明標識，并將合約有效性證明的存儲負擔轉移至提議節點，但對于整個系統來說，提議節點并不需要存儲全部智能合約的有效性證明，而是根據自身的需要存儲，從而降低系統中數據冗余程度。與Ethereum中全節點數據完全冗余方式相比，STiPChain不僅可以有效降低共識節點的存儲負擔，并且可以有效降低整個系統的數據存儲量。

5.5 吞吐量

為了測量STiPChain 的峰值性能，本文對16 個客戶端進行了實驗，每個客戶端向一個計算節點發送100 個串行請求。測試采用共識節點執行交易所需時間作為吞吐量測試樣本，并對每條合約實驗忽略測試起始與結束前10%的請求，測試平均穩定的性能。圖6 所示為吞吐量測試結果。STiPChain 的吞吐量一直高于2 000 T/s，各合約之間吞吐量變化不大。Ethereum 在ERC20 轉賬合約中達到了1 619 T/s，而在Encryption 合約測試中僅有67 T/s。實驗結果表明，STiPChain 相較于Ethereum 具有更高的吞吐量并且在處理復雜合約時更具有優勢。STiPChain 中的共識節點在修改全局狀態時只需要檢查合約有效性證明和可驗證計算證明，無須重復執行交易，通過該方式可以有效地提高系統的吞吐量。

圖6 吞吐量測試結果Fig.6 Test results of throughput

6 結束語

針對多數公有鏈低吞吐和數據增長問題，本文提出一種基于密碼累加器的無狀態區塊鏈性能優化方案STiPChain。STiPChain 通過CVP 狀態承諾和可驗證計算技術將狀態和交易執行轉移到提議節點，共識節點負責交易驗證及區塊提交，從而提高系統的可擴展性。在此基礎上，設計了新的狀態承諾方案以及鏈外事務執行、鏈上事務驗證和節點同步方案來支持無狀態交易執行與驗證。實驗結果表明，相較于Etherrum，STiPChain 能夠極大地降低共識節點的存儲壓力，并有效提高系統吞吐量。下一步將利用安全多方計算［25-26］技術實現RSA 累加器的可信初始化設置等關鍵功能，并通過狀態承諾［27-28］模型給出安全性更高的狀態承諾方案，從而提高的系統安全性與運行效率。