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

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

0 概述

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

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

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

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

1 相關工作

1.1 無狀態(tài)區(qū)塊鏈

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

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

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

1.2 可驗證計算技術

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

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

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

2 STiPChain 系統(tǒng)架構

STiPChain 將傳統(tǒng)區(qū)塊鏈中共識節(jié)點存儲系統(tǒng)中的全部智能合約的狀態(tài)數據轉變?yōu)榇鎯Ω骱霞s的有效性證明，將智能合約的狀態(tài)數據抽象為hash 摘要，并通過RSA 累加器完成各智能合約摘要的累加與合約有效性證明的創(chuàng)建。同時，各節(jié)點不必存儲所有智能合約的有效性證明，而是可以根據節(jié)點本身需求存儲相對應合約的hash 摘要及有效性證明，從而極大地降低系統(tǒng)及系統(tǒng)中單個節(jié)點的存儲量。

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

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

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

STiPChain 系統(tǒng)架構如圖1 所示。

圖1 STiPChain 系統(tǒng)架構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′更新合約狀態(tài)u的累加元素時，其應該能夠通過僅訪問信息（u，u′）輕松地將AAcc更新為A′Acc。也就是說，與Merkle 樹不同，更新是獨立于其他元素的。類似地，當參與方i得知更新（u，u′）時，應該同樣能夠有效地只通過訪問（u，u′）更新證明（πi→）。

表1 符號說明 Table 1 Description of symbols

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

3.1 初始化Gen（λ）的設置

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

3.2 合約有效性證明WitAccCreate（Acci-1）的創(chuàng)建

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

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

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

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

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

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

4 交易流程及關鍵算法

STiPChain 實現了由傳統(tǒng)區(qū)塊鏈中共識節(jié)點冗余存儲各合約的狀態(tài)數據轉變?yōu)楸４娓骱霞s狀態(tài)證明，提議節(jié)點在TEE 中運行智能合約，共識節(jié)點檢查交易可驗證計算證明πTEE，從而使得各節(jié)點無須運行智能合約，也可以完成全局狀態(tài)的更新。

4.1 交易流程

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

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

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

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

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

5）提議節(jié)點接收新發(fā)布的區(qū)塊，并更新本地CVP 承諾以及合約有效證明。

交易流程如圖2 所示。

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

4.2 交易創(chuàng)建

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

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

算法1提議節(jié)點交易執(zhí)行

4.3 區(qū)塊創(chuàng)建

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

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

算法2共識節(jié)點交易驗證

4.4 證據同步

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

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

5 性能測試

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

表2 STiPChain 與現有區(qū)塊鏈優(yōu)化方案的對比 Table 2 Comparison between STiPChain and existing blockchain optimization schemes

5.1 實驗環(huán)境設置

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

5.2 合約有效性證明大小

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

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

5.3 合約有效性證明更新

本節(jié)主要測試合約有效性證明的更新效率，該效率直接影響了系統(tǒng)的吞吐能力。Boneh 使用RSA 累加器構建 UTXO 承諾，承諾更新的時間復雜度為O（n），Edrax 基于向量承諾方案實現更新操作的時間復雜度為O（lognlog logn），而STiPChain 基于區(qū)塊鏈的全局狀態(tài)一致性，只需要進行添加操作即可完成合約的有效性證明更新，更新時間復雜度為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，并且隨著累積狀態(tài)數量的增多明顯增高。當操作數量達到1 400時，Boneh 累加器更新時間是CVP 的16 000倍，這就導致依賴于Boneh 狀態(tài)承諾的無狀態(tài)客戶端設計面臨嚴重的性能問題。

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

5.4 存儲開銷

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

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

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

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

5.5 吞吐量

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

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

6 結束語

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