戴 波，賴旬陽，胡 凱，馬 舒，陳 波，姜清妍，鄭 妘

(1.國網(wǎng)浙江電力有限公司 信息通信分公司，浙江 杭州 310019；2.國網(wǎng)浙江電力有限公司 浙江德清縣供電有限公司，浙江 德清 313200；3.浙江工業(yè)大學(xué) 計算機科學(xué)與技術(shù)學(xué)院，浙江 杭州 310023)

2009年，區(qū)塊鏈隨著比特幣[1]的出現(xiàn)初次被人知曉。此后，區(qū)塊鏈技術(shù)在包括金融、醫(yī)療、司法、教育、供應(yīng)鏈和電力等多個領(lǐng)域得到擴展應(yīng)用。區(qū)塊鏈技術(shù)是一種全新的分布式基礎(chǔ)架構(gòu)，采用一種基于時間戳的“區(qū)塊+鏈式”數(shù)據(jù)結(jié)構(gòu)，結(jié)合分布式共識算法、密碼學(xué)方法和智能合約等多種機制，能夠確保鏈上數(shù)據(jù)可信、安全，還能進行數(shù)據(jù)操作。近年來，涌現(xiàn)了很多區(qū)塊鏈框架[2-4]，現(xiàn)有的經(jīng)驗表明：要將區(qū)塊鏈大規(guī)模應(yīng)用于實際場景，仍存在許多挑戰(zhàn)[5]，主要表現(xiàn)在3個方面：1) 可擴展性，區(qū)塊鏈的擴展必須以增大交易吞吐量為代價，要滿足多鏈場景下的應(yīng)用需求同時必須滿足高性能和可擴展性兩方面的要求；2) 可監(jiān)管性，區(qū)塊鏈具有去中心化的特性，但常需一個中心化的監(jiān)管機構(gòu)用以保證對系統(tǒng)的控制，以便執(zhí)行特定的業(yè)務(wù)邏輯和策略；3) 隱私保護，區(qū)塊鏈上的交易是公開的，在實際應(yīng)用中要求數(shù)據(jù)只能與相關(guān)方分享。已有方案雖然提出加密交易，但此類方法要求密鑰管理基礎(chǔ)設(shè)施，且仍然允許系統(tǒng)中其余節(jié)點了解交易。

為解決上述問題，筆者提出了一種基于多角色節(jié)點的的區(qū)塊鏈可擴展方案，并將節(jié)點定義為多種角色，構(gòu)建相互聯(lián)系又相互獨立的子鏈，每條子鏈自行維護私有賬本，只有成員節(jié)點才能發(fā)起交易、訪問交易，以此保證交易的隱私性。同時，本方案支持不限數(shù)量的子鏈，不同子鏈可并行運行不同的共識協(xié)議，隨時進行跨鏈資產(chǎn)轉(zhuǎn)移，并能保證系統(tǒng)的安全性和可靠性，具有極大的可擴展性。此外，筆者方案中的監(jiān)管者角色可通過智能合約來執(zhí)行特定策略，負責監(jiān)管整個網(wǎng)絡(luò)的運行。

1 相關(guān)工作

1.1 區(qū)塊鏈監(jiān)管技術(shù)

在區(qū)塊鏈技術(shù)應(yīng)用中存在監(jiān)管體系缺失、數(shù)據(jù)分散和難以兼顧隱私保護等問題。在食品安全方面，Tao等[6]提出了層次化的多域區(qū)塊鏈(HMDBC)網(wǎng)絡(luò)結(jié)構(gòu)和2次檢查機制，可以支持對區(qū)塊鏈的及時糾正和替換。惡意監(jiān)督節(jié)點由區(qū)域節(jié)點共同管理，監(jiān)督節(jié)點進行輔助驗證以及上級區(qū)域的仲裁。Liu等[7]提出基于區(qū)塊鏈的草藥質(zhì)量和安全監(jiān)管模型，利用區(qū)塊鏈的不變性和可追溯性來管理草藥的生產(chǎn)、加工和交易流程，并結(jié)合分段信息加密方法，對企業(yè)的私人信息進行加密。

現(xiàn)有的區(qū)塊鏈監(jiān)管機制都在同一條鏈中進行，只能針對特定的領(lǐng)域進行管理，且無法根據(jù)實際情況進行特定的策略調(diào)整，存在不可擴展的弊端。

1.2 跨鏈技術(shù)

目前，區(qū)塊鏈行業(yè)被眾多平臺和協(xié)議所隔離，從而形成各式各樣的區(qū)塊鏈孤島，使得當前區(qū)塊鏈互操作性有限。不同區(qū)塊鏈之間資產(chǎn)轉(zhuǎn)移的限制降低了用戶的可用性和舒適度，并阻礙了區(qū)塊鏈生態(tài)系統(tǒng)的發(fā)展。

Gao等[8]探索了如何在資產(chǎn)轉(zhuǎn)移的背景下實現(xiàn)兩個異構(gòu)區(qū)塊鏈之間的相互操作，并提出基于數(shù)據(jù)遷移Oracle構(gòu)建跨鏈資產(chǎn)轉(zhuǎn)移架構(gòu)，在2個異構(gòu)區(qū)塊鏈之間打開通道進行資產(chǎn)轉(zhuǎn)移，但該架構(gòu)缺少身份驗證的環(huán)節(jié)，安全性較低。Borkowski等[9]提出DeXTT跨區(qū)塊鏈轉(zhuǎn)移協(xié)議，該協(xié)議可用于以分散的方式同時記錄任意數(shù)量的區(qū)塊鏈上的資產(chǎn)轉(zhuǎn)移。在DeXTT原型中，使用智能合約實現(xiàn)交易。Pang等[10]為區(qū)塊鏈互操作性架構(gòu)提出了一種新的共識協(xié)議MPoS，該協(xié)議能夠增強跨鏈系統(tǒng)中的令牌網(wǎng)絡(luò)效應(yīng)，并極大地擴展區(qū)塊鏈系統(tǒng)的用戶基礎(chǔ)。通過實驗分析，證明了MPoS協(xié)議相較于傳統(tǒng)的單令牌PoS共識協(xié)議，可以提供更好的安全性。

與上述方法不同，筆者提出的方案支持不限數(shù)量的子鏈，不同子鏈可并行運行不同的共識協(xié)議，隨時進行跨鏈資產(chǎn)轉(zhuǎn)移[11]，并能夠同時保證系統(tǒng)的安全性和可靠性。

1.3 隱私保護技術(shù)

An等[12]提出基于區(qū)塊鏈2次驗證和共識(TCNS)的去中心化隱私保護模型。TCNS的原型是通過一種橢圓曲線算法進行驗證的匿名策略，以保護用戶身份的隱私。Liu等[13]提出一種基于聯(lián)盟鏈的隱私保護的醫(yī)學(xué)數(shù)據(jù)共享方案，設(shè)計鏈上鏈下的存儲模型以減輕區(qū)塊鏈的存儲負擔，并引入一種改進的代理重加密方案，以確保數(shù)據(jù)僅可以由授權(quán)數(shù)據(jù)請求者訪問，達到保護數(shù)據(jù)隱私的目的。

區(qū)塊鏈技術(shù)在監(jiān)管技術(shù)、跨鏈以及隱私保護等方面雖然都得到了改進與發(fā)展，但是通過對上述現(xiàn)狀對比發(fā)現(xiàn)(表1)，相關(guān)學(xué)術(shù)研究無法兼顧3者的平衡。為此，筆者提出了一種基于多角色節(jié)點的區(qū)塊鏈可擴展方案，以此實現(xiàn)區(qū)塊鏈的可擴展和可監(jiān)管，并兼顧節(jié)點隱私保護。

表1 相關(guān)研究對比分析Table 1 Comparison of related studies

2 區(qū)塊鏈可擴展方案

2.1 總體架構(gòu)

系統(tǒng)模型中各類節(jié)點構(gòu)建起一個許可鏈網(wǎng)絡(luò)，并以分布式應(yīng)用的形式支持智能合約，例如以太坊和Fabric中的智能合約。

系統(tǒng)中的節(jié)點承擔以下角色：1) 客戶端(Clients)發(fā)布交易；2) 驗證者(Validators)參與共識；3) 審計員(Auditors)通過訂閱被動接收系統(tǒng)中的交易事件；4) 監(jiān)管者(Regulators)執(zhí)行策略進行管理，不必參與共識并且一個節(jié)點能同時承擔多種角色。

筆者設(shè)計的系統(tǒng)架構(gòu)如圖1所示，不同角色對應(yīng)不同職責。監(jiān)管者發(fā)布策略，統(tǒng)一管理子鏈；驗證節(jié)點參與共識并維護子鏈賬本，共享業(yè)務(wù)邏輯可以發(fā)生交易；審計節(jié)點訂閱并接收交易事件，進一步驗證交易。假定節(jié)點不會主動與無關(guān)節(jié)點分享交易信息。

圖1 基于多角色節(jié)點的區(qū)塊鏈可擴展架構(gòu)設(shè)計Fig.1 Blockchain extensible architecture design based on multi-role nodes

2.2 子鏈構(gòu)建

在本方案中，子鏈是一個自行維護的分布式私有賬本，由網(wǎng)絡(luò)中的一組節(jié)點組成，這些節(jié)點參與共識并維護賬本，一個節(jié)點可以同時加入多條子鏈。每條子鏈自行維護對私有賬本的訪問控制權(quán)限，訪問控制方法由鏈上的驗證節(jié)點和監(jiān)管者的策略定義。與側(cè)鏈[14-15]不同，筆者對子鏈使用的底層共識沒有限制，只要共識協(xié)議不違反監(jiān)管者的規(guī)定即可。此外，筆者方案還支持跨鏈資產(chǎn)轉(zhuǎn)移。子鏈構(gòu)建流程見圖2。

圖2 子鏈構(gòu)建流程圖Fig.2 Subchain construction flow chart

在構(gòu)建子鏈時，節(jié)點首先需要就鏈上的驗證節(jié)點、共識協(xié)議和訪問策略達成協(xié)議，圖2描述了用于選舉發(fā)起者、鏈ID和底層的共識協(xié)議的算法。首先，所有節(jié)點在鏈上廣播自己的ID和所選擇的共識協(xié)議，節(jié)點接收到來自各個其他節(jié)點的信息后，驗證所有的ID是否被驗證，并構(gòu)建子鏈數(shù)據(jù)結(jié)構(gòu)信息chain_info；其次，判斷ID信息是否從監(jiān)管者得到，若是，則對chain_info簽名得到sigi，并對多有節(jié)點同步和sigi，并收集sigk，若不是，則繼續(xù)等待，直到收到監(jiān)管者發(fā)送的信息，進行簽名，并向監(jiān)管者獲取所有節(jié)點的sigk；最后，驗證所有簽名是否準確，若準確，則構(gòu)建子鏈，并返回子鏈信息，否則產(chǎn)生錯誤。

需要說明的是，審計節(jié)點經(jīng)過子鏈批準后可訂閱其中的交易推送，并對交易進行審計管理，確保交易準確有效。

2.3 策略監(jiān)管

筆者方案中的監(jiān)管者節(jié)點負責驗證交易是否合法且遵循策略。監(jiān)管者不參與共識，只負責通過智能合約將監(jiān)管策略推送給特定子鏈。筆者引入的策略目錄合約(Policy directory contract)提供注冊、搜索和更新等功能，用于管理策略合約，該合約托管在監(jiān)管者中，部署在鏈上。目錄合約監(jiān)聽監(jiān)管者發(fā)布的策略發(fā)布或更新事件，自動將新的策略合約部署在各個子鏈上，并注冊在目錄合約中。

子鏈上的所有智能合約都包含一個到策略目錄合約的反饋。驗證交易時，交易會被轉(zhuǎn)發(fā)到策略目錄合約，目錄合約選擇合適的策略驗證交易，驗證通過后子鏈上的智能合約才能夠執(zhí)行。該方法保證只要有足夠多的誠實節(jié)點，監(jiān)管策略就能夠被正確執(zhí)行，不需要監(jiān)管者的主動干預(yù)。

2.4 跨鏈資產(chǎn)轉(zhuǎn)移

在某些應(yīng)用場景中，資產(chǎn)需要在不同子鏈之間流轉(zhuǎn)。例如，2個屬于不同區(qū)域(即位于不同子鏈)的工業(yè)互聯(lián)網(wǎng)廠區(qū)之間的資產(chǎn)轉(zhuǎn)移。為了解決這類問題，筆者提供了跨鏈資產(chǎn)轉(zhuǎn)移方案。

假定s和r屬于2條不同的子鏈，將資產(chǎn)m從發(fā)送者s轉(zhuǎn)移到接受者r的過程如圖3所示。s發(fā)起交易，先向它所屬的子鏈(以下簡稱s鏈)發(fā)出一個轉(zhuǎn)移資產(chǎn)的請求。s鏈上的所有驗證節(jié)點驗證該交易，包括檢查資產(chǎn)m的總量是否超過上限，s是否持有資產(chǎn)m等。如果驗證通過，驗證者節(jié)點將執(zhí)行交易，從s的賬戶上移除資產(chǎn)m，并返回許可給s。一旦s收集到足夠多(數(shù)量由底層共識協(xié)議決定)的許可，s就能構(gòu)建一個最終證明，證明s鏈批準該交易且此交易確實在該鏈上執(zhí)行。轉(zhuǎn)移令牌指定了資產(chǎn)的接收鏈，因此不會被其他鏈接收。接著，s向r所屬的鏈(以下簡稱r鏈)發(fā)送該最終證明。接收鏈驗證最終證明以及該交易是否符合監(jiān)管策略。驗證通過，r鏈將資產(chǎn)m移動到r的賬戶上，并返回一個帶有r鏈最終證明的收到令牌給s；否則r鏈會返回一個拒絕令牌，s可以用其來恢復(fù)自己的賬戶資產(chǎn)。發(fā)送鏈和接收鏈通過s和r間的直連通道進行通信。如果s在規(guī)定的時延內(nèi)既沒有收到接收令牌也沒有收到拒絕令牌，那么它可以向r鏈的另一個節(jié)點重新發(fā)送請求。轉(zhuǎn)移操作應(yīng)具有原子性[8]：發(fā)送者和接收者的賬戶需要同時更新，異步過程這時無法滿足原子性的要求，方案禁止，超時導(dǎo)致的隱式回滾是需要通過接收令牌進行回滾處理。如果交易成功，每條鏈內(nèi)就只需要進行一次共識；否則，發(fā)送鏈需額外執(zhí)行一次共識來回滾發(fā)送節(jié)點的賬戶資產(chǎn)。

1—s發(fā)布一個transfer交易；2—節(jié)點驗證并執(zhí)行transfer；3—s收集transfer的授權(quán)證書，并轉(zhuǎn)發(fā)給r；4—r發(fā)布一個transferf交易；5—節(jié)點驗證并執(zhí)行transferf；6—r收集授權(quán)證書，并返回receipt或reject令牌；7—如果交易在接收鏈上失敗了，s發(fā)布rejectf來恢復(fù)自己的賬戶。圖3 跨鏈資產(chǎn)轉(zhuǎn)移圖Fig.3 Cross-chain asset transfer diagram

3 設(shè)計與實現(xiàn)

筆者將方案與Hyperledger Fabric v0.6集成，進行了系統(tǒng)設(shè)計與實現(xiàn)。Hyperledger Fabric因不支持多賬本和跨鏈功能，所以要對Hyperledger Fabric進行功能擴展。

3.1 子鏈實現(xiàn)

子鏈通過擴展Fabric的成員服務(wù)實現(xiàn)。假定監(jiān)管者負責協(xié)調(diào)整個網(wǎng)絡(luò)的成員服務(wù)，用于記錄所有已注冊的子鏈和鏈上的成員信息(即IP地址、TCP端口和節(jié)點ID)。每條子鏈一經(jīng)形成，就需要向監(jiān)管者注冊。

一個節(jié)點可能需要維護多個獨立賬本，每個賬本對應(yīng)一條它們加入的子鏈。筆者修改Fabric節(jié)點的核心代碼，當節(jié)點加入一條新的子鏈時，它就會創(chuàng)建數(shù)據(jù)庫來存儲賬本。筆者使用Fabric的鍵值數(shù)據(jù)庫RocksDB來實現(xiàn)，節(jié)點將在Chain-to-ledgers數(shù)據(jù)結(jié)構(gòu)中維護一個指向新創(chuàng)建的數(shù)據(jù)庫的指針。Chain-to-ledgers是一個映射，它存儲(Chain_id, ledger_db)鍵值對，主要為該節(jié)點加入的子鏈以及指向數(shù)據(jù)庫的指針，數(shù)據(jù)庫中存儲了子鏈內(nèi)的交易。添加新驗證的交易時，就需要訪問該數(shù)據(jù)結(jié)構(gòu)。

除此之外，筆者還向節(jié)點的核心代碼中添加Chain-to-consensus和Chain-to-peers數(shù)據(jù)結(jié)構(gòu)。Chain-to-consenses是一個映射，存儲(Chain_id, consensus_plugin)鍵值對，主要為節(jié)點加入的子鏈和對應(yīng)的共識協(xié)議。以上提到子鏈的鏈ID和共識協(xié)議是由其成員節(jié)點商定的，當有節(jié)點加入時，它會將這些數(shù)據(jù)傳遞給Fabric中的對等節(jié)點，以便將其存儲在Chain-to-consensus中。Chain-to-peer也是一個映射，存儲(Chain_id, peers_list)鍵值對，主要為節(jié)點加入的子鏈以及這個子鏈的對等節(jié)點列表。節(jié)點在達成一致時，會得到一個同樣參與這條子鏈的對等節(jié)點列表。因此，當有節(jié)點加入新鏈時，也需要將對等節(jié)點列表傳遞給Fabric中的對等節(jié)點。

每當子鏈成功地驗證一個交易時，每個節(jié)點會訪問Chain-to-ledgers映射，查詢該鏈的數(shù)據(jù)庫指針，并訪問數(shù)據(jù)庫將交易記錄到私有賬本中。

3.2 監(jiān)管策略實施

監(jiān)管者通過鏈碼來執(zhí)行策略，監(jiān)管者需要為每個策略提供一個或多個鏈碼。每條子鏈必須將監(jiān)管者策略鏈碼與自己的鏈碼整合部署。

監(jiān)管者節(jié)點提供一個策略目錄鏈碼來管理策略鏈碼，這種特殊的鏈碼部署在每條子鏈中，用于監(jiān)聽監(jiān)管者發(fā)出的策略鏈碼更新事件(圖4)，通過Fabric的消息框架推送鏈碼更新來實現(xiàn)。監(jiān)聽到更新事件后，策略目錄鏈碼會下載新的策略鏈碼部署到子鏈中。

圖4 策略鏈碼圖Fig.4 Strategy chain code diagram

鏈碼執(zhí)行交易時，會將交易傳遞給策略目錄鏈碼，后者查找已部署的策略鏈碼列表，并轉(zhuǎn)發(fā)交易到具體策略鏈碼，策略鏈碼驗證交易，并將結(jié)果返回給策略目錄鏈碼。驗證過程中，只有所有的策略驗證都通過，這個交易才算被驗證合法，此時鏈碼會繼續(xù)處理交易。

3.3 資產(chǎn)轉(zhuǎn)移實現(xiàn)

筆者允許在交易雙方節(jié)點間建立直接通道，通過TLS發(fā)送資產(chǎn)轉(zhuǎn)移消息。交易在其數(shù)據(jù)中包含了目標子鏈的ID，接收者節(jié)點只會向目標鏈的成員節(jié)點廣播這個交易，該節(jié)點從Chain-to-peers映射中查找子鏈的對等節(jié)點列表，以便發(fā)送交易。然后，接收節(jié)點以Chain_id和Chaincode_id作為標識，向目標鏈碼發(fā)送一個調(diào)用請求。

4 性能評估

針對上述區(qū)塊鏈方案進行性能評估，本系統(tǒng)使用Golang語言實現(xiàn)，主要測試交易性能和系統(tǒng)性能開銷。實驗環(huán)境中，使用基于Windows 10操作系統(tǒng)的臺式機，處理器為Intel CoreTM I9 2.60 GHz，內(nèi)存為16 GB。下述實驗在筆者架構(gòu)與Hyperledger Fabric v0.6的集成版本上測試。

4.1 交易性能

交易性能是區(qū)塊鏈系統(tǒng)的一個重要指標，在實際運行中，可能會有大量交易同時并發(fā)執(zhí)行，其中主要性能消耗在于驗證對等節(jié)點執(zhí)行跨鏈共識、驗證交易并入鏈的過程。本實驗將設(shè)置16次，其中8次為入鏈交易，8次為查詢，交易并發(fā)量分別設(shè)定為50，100，150，200，250，300，350，400次/s，對比不同并發(fā)情況下交易確認的平均時延和吞吐量，以及交易的成功率，并監(jiān)控服務(wù)器cpu和內(nèi)存使用情況。實驗使用Hyperledger Caliper工具，該工具可對Hyperledger進行性能測試，適應(yīng)本方案需求。

圖5～7分別為實驗中每秒交易數(shù)與交易時延、吞吐量和交易成功率的關(guān)系，圖8為發(fā)送速率與服務(wù)器性能的關(guān)系。圖5顯示入鏈交易的時延與每秒交易并發(fā)量成正相關(guān)，且近似線性關(guān)系，查詢交易的時延隨著交易并發(fā)的上升有略微的波動，但幅度較小，且始終處于較低的數(shù)值；圖6顯示入鏈交易的吞吐量在50～150次/s始終是上升趨勢，在150次/s之后就不再大幅上升，查詢交易吞吐量則始終與每秒交易數(shù)成正相關(guān)增大；圖7顯示隨著每秒交易數(shù)的上升，交易成功率下降，經(jīng)分析造成該結(jié)果的原因可能是交易過程中數(shù)據(jù)量增大，消息阻塞，增大了響應(yīng)時延，導(dǎo)致用戶端接受交易信息超時，無法達成交易；圖8顯示隨著每秒交易數(shù)增大，服務(wù)器性能消耗也逐步上升。

圖5 交易時延Fig.5 Trading delay

圖6 交易吞吐量Fig.6 Transaction throughput

圖7 交易成功率Fig.7 Transaction success rate

圖8 交易性能消耗Fig.8 Trading performance consumption

提高交易性能的主要瓶頸在于需要入鏈的交易在發(fā)起后由節(jié)點進行共識，并打包成塊，影響因素主要是節(jié)點的數(shù)量和服務(wù)器性能等；不需要入鏈的查詢交易時延相對穩(wěn)定，且與吞吐量成正相關(guān)，因為查詢不需要通過區(qū)塊鏈的共識，只是獲取狀態(tài)信息，所以在性能影響上沒有太大波動。

對于交易性能的提升，主要可以從網(wǎng)絡(luò)架構(gòu)和服務(wù)器性能上著手。共識機制主要依賴于子鏈上節(jié)點的數(shù)量，節(jié)點數(shù)量越多，需要的網(wǎng)絡(luò)延遲和共識時間便越長，所以選擇合適數(shù)量的節(jié)點，對于系統(tǒng)性能提升有一定的幫助。同時，服務(wù)器配置的提高，也可以降低算法運行過程中的時延，提高交易吞吐量。

4.2 系統(tǒng)性能

在本系統(tǒng)中，除了交易之外，其他部分也會產(chǎn)生額外的開銷，例如對子鏈的構(gòu)建、共識機制的運行等會造成性能開銷，策略鏈碼目錄在監(jiān)聽監(jiān)管者發(fā)出的策略鏈碼更新事件后需要同步更新后的鏈碼，并部署到子鏈上，此時也產(chǎn)生額外的性能開銷。為了綜合評估系統(tǒng)性能，實驗?zāi)M仿真環(huán)境更新策略鏈碼事件，并測試查詢交易的時延、吞吐量和成功率等參數(shù)。本次實驗使用apache-jmeter發(fā)送交易請求，啟動1 000個并發(fā)線程發(fā)送請求，循環(huán)100次。

實驗總共發(fā)送了100 000個交易請求，其中有效樣本為93 252個，發(fā)送交易總耗時174 s，其中平均時延為1 265 ms，錯誤率為0%，交易吞吐量為548.4次/s。實驗雖然模擬仿真環(huán)境，但仍較理想化，實際運行中必然會有所延遲；考慮到網(wǎng)絡(luò)等因素，預(yù)計實際查詢交易吞吐量會降低，平均時延會延長到1.5 s，但足以滿足應(yīng)用需求。也可以通過提高硬件配置來降低算法運行時延或者采用負載均衡等提升系統(tǒng)性能。

結(jié)合交易性能測試和系統(tǒng)性能測試，該系統(tǒng)在一定的吞吐量下可以達到穩(wěn)定，并正常使用，符合預(yù)期設(shè)計目標，測試通過。

綜上所述，與已有Hyperledger Fabric v0.6版本比較，集成版本能夠私有地、并行地運行多個不同的共識協(xié)議來提高系統(tǒng)的可擴展性。同時，該解決方案包括一個“不介入”的監(jiān)管者，其負責高效管理整個網(wǎng)絡(luò)，并能夠使用智能合約執(zhí)行特定策略等工作，且交易性能和系統(tǒng)性能能夠達到預(yù)期水準，能夠兼顧隱私保護、可擴展和高管理效率[16]。

5 結(jié) 論

區(qū)塊鏈技術(shù)自提出以來便被廣泛應(yīng)用于教育、醫(yī)療、金融和工業(yè)等諸多領(lǐng)域，并不斷擴展到每個行業(yè)之中，隨著區(qū)塊鏈應(yīng)用的增加，不同區(qū)塊鏈之間產(chǎn)生的信息孤島問題也日益嚴重。筆者提出了一個基于多角色節(jié)點的區(qū)塊鏈可擴展方案，方案為系統(tǒng)中的節(jié)點設(shè)定不同的角色，組成若干個相互聯(lián)系又相互獨立的子鏈，子鏈的數(shù)量不受限制，不同的子鏈可運行不同的共識協(xié)議，子鏈間可通過跨鏈資產(chǎn)轉(zhuǎn)移實現(xiàn)價值流轉(zhuǎn)和信息交換。監(jiān)管者能夠在區(qū)塊鏈網(wǎng)絡(luò)中強制實施策略，以實現(xiàn)對系統(tǒng)的監(jiān)管。本方案不涉及底層共識協(xié)議，因此可以與現(xiàn)有的區(qū)塊鏈平臺集成。結(jié)果表明：筆者方案能夠更好地結(jié)合領(lǐng)域產(chǎn)業(yè)需求，實現(xiàn)定制化的應(yīng)用，為區(qū)塊鏈服務(wù)于各行各業(yè)及聯(lián)通各行各業(yè)提供新思路。