基于區(qū)塊鏈的學位證書存證系統(tǒng)設計與實現(xiàn)

劉東偉，張學旺，郭曉金

(1.重慶郵電大學 通信與信息工程學院，重慶 400065；2.重慶郵電大學 軟件工程學院，重慶 400065)

0 引 言

隨著比特幣的興起，區(qū)塊鏈技術受到了各行各業(yè)的廣泛關注。2016年，國務院印發(fā)的《“十三五”國家信息化規(guī)劃》首次將區(qū)塊鏈列為我國的國家信息化規(guī)劃，并將其作為戰(zhàn)略前沿技術之一?！皡^(qū)塊鏈+教育”也逐漸成為國內外教育學領域專家關注的一個研究發(fā)展方向，依據(jù)區(qū)塊鏈技術所具有的數(shù)據(jù)公開透明和不可篡改特性，將其應用于教育的學信管理、資質證明等方面，有助于教育領域的改革發(fā)展。

目前國外的部分教育機構已經開始利用區(qū)塊鏈技術進行學位證書的頒發(fā)。文獻[1]提出了基于以太坊的教育記錄方案系統(tǒng)設計，該方案系統(tǒng)能夠實現(xiàn)學位證書信息的存儲和驗證，但基于挖礦機制，交易處理效率低。文獻[2]提出了基于區(qū)塊鏈平臺多鏈的學位證書驗證方案，該方案系統(tǒng)仍然基于挖礦機制，交易處理效率仍不高。而本文針對學位證書存證的教育業(yè)務場景，為解決交易吞吐量低以及中心化存儲所具有的單點故障問題，采用了超級賬本作為底層區(qū)塊鏈技術平臺，并利用Kafka技術實現(xiàn)交易的快速分發(fā)處理，以此提高學位證書存儲的交易吞吐量。

1 技術背景

1.1 區(qū)塊鏈簡介

區(qū)塊鏈基于圖1所示的鏈式區(qū)塊數(shù)據(jù)結構，一個區(qū)塊中包含了區(qū)塊頭和區(qū)塊體兩部分[3]。區(qū)塊頭中包含了前一個區(qū)塊的哈希散列值、Merkle根、時間戳、版本號和其它信息。其中Merkle根是由區(qū)塊體中所有交易信息的總哈希值生成，前一個區(qū)塊的哈希散列值作為區(qū)塊間的連接索引，將區(qū)塊按照時間順序連接起來，形成一條主鏈。時間戳用于給每一個生成的區(qū)塊確定時間，確保該區(qū)塊無法偽造。其它信息根據(jù)共識機制[4]的不同可能會含有隨機數(shù)、目標哈希值等數(shù)據(jù)。而區(qū)塊體中的交易信息由Merkle樹[5]進行存儲，這種存儲結構能夠確保交易信息篡改后Merkle根值發(fā)生變化，確保交易信息無法篡改。區(qū)塊鏈底層依托于P2P網絡[6]，每一個節(jié)點都持有該賬本的副本，所有副本同步更新。除非擁有網絡中絕大部分節(jié)點的控制權，否則更改網絡中單個節(jié)點的數(shù)據(jù)毫無意義。

圖1 區(qū)塊結構

1.2 Kafka簡介

Kafka作為一個分布式、可分區(qū)和可復制的消息系統(tǒng)[7]，具有高吞吐量和低延遲特性，其架構如圖2所示。將Kafka機制應用于區(qū)塊鏈網絡的交易共識，能夠提高區(qū)塊鏈網絡的交易處理速度。

Kafka以主題為單位區(qū)分所發(fā)消息的類別，每個主題包含一個或多個分區(qū)，每個分區(qū)都是一個順序的、不可變的消息隊列，用于存儲新增的消息。Producer和Consumer異步生產和消費消息，Producer負責向Broker發(fā)送消息，Consumer負責從Broker消費消息。Kafka通過分區(qū)備份機制實現(xiàn)Broker集群的可靠性和穩(wěn)定性，每個分區(qū)的數(shù)據(jù)副本存儲到多個Broker上。通過選舉機制將其中一個Broker作為該分區(qū)的主節(jié)點，其余的Broker作為從節(jié)點，主節(jié)點負責處理所有的讀寫請求，從節(jié)點存儲一個副本并和主節(jié)點保持數(shù)據(jù)同步。

Broker集群狀態(tài)需要通過Zookeeper進行管理維護，通過Zookeeper watch機制監(jiān)測Consumer和Broker元數(shù)據(jù)信息的變更。當主節(jié)點宕機，Zookeeper會監(jiān)測到變化信息并通過選舉機制從剩下的Broker中重新產生一個主節(jié)點，以此確保主節(jié)點宕機后并不會影響集群工作。Zookeeper集群管理服務要求集群中半數(shù)以上的節(jié)點處于可用狀態(tài)，在兼顧工作效率與節(jié)約資源的情況下，Zookeeper集群節(jié)點應設置為奇數(shù)個，滿足2*n+1個，其中n為容錯節(jié)點數(shù)，集群節(jié)點數(shù)最小為3。一般來說，Broker數(shù)量越多，數(shù)據(jù)可靠性越高，但是數(shù)量過多也會影響整體性能。

圖2 Kafka消息訂閱與發(fā)布

2 系統(tǒng)設計

目前的區(qū)塊鏈平臺主要有比特幣、以太坊和Linux基金會的開源項目超級賬本。其中比特幣和以太坊作為公有鏈，基于挖礦共識機制，交易處理效率低。任意節(jié)點都可以加入網絡并共享賬本，不利于數(shù)據(jù)的隱私保護。而超級賬本作為許可鏈，通過成員管理服務和通道隔離機制實現(xiàn)網絡節(jié)點身份認證和賬本數(shù)據(jù)的隱私保密，并將節(jié)點進行角色分類和職責分工，具有更高的交易處理能力。

2.1 系統(tǒng)層次架構

本系統(tǒng)設計以Hyperledger Fabric作為區(qū)塊鏈平臺，通過web前臺系統(tǒng)實現(xiàn)用戶交互。前臺系統(tǒng)用戶主要分為系統(tǒng)管理員、普通用戶和審核機構用戶。系統(tǒng)管理員主要實現(xiàn)前臺系統(tǒng)的用戶管理和權限分配等功能。普通用戶主要為學生用戶，負責發(fā)起學位證書信息的登記、查詢、更改等交易提案。審核機構用戶主要為各大高校用戶，負責審核登記、更改、吊銷學位證書信息世界狀態(tài)。圖3為本系統(tǒng)的層次結構設計，主要由區(qū)塊鏈底層平臺、智能合約、業(yè)務層和應用層組成。

圖3 系統(tǒng)結構層次

應用層采用Jquery+Bootstrap+HTML5等前端框架實現(xiàn)前臺系統(tǒng)用戶交互的WEB頁面，主要功能有：用戶注冊登錄，學位證書信息的登記更改、詳情查看、吊銷、歷史記錄和學位證書信息所屬高校類別、學位類別和年月等維度的統(tǒng)計分析。業(yè)務層作為后端服務，負責給Web前端功能提供Restful接口，通過Fabric-Java-SDK與區(qū)塊鏈網絡交互，實現(xiàn)賬本狀態(tài)的寫入和更新，同時負責對接其它業(yè)務系統(tǒng)。智能合約通過GRPC接口與區(qū)塊鏈底層平臺交互，實現(xiàn)對學位證書信息的賬本狀態(tài)更改。Hyperledger Fabric主要提供成員管理服務、共識服務、鏈碼服務和安全密碼服務。CA(certificate authority)模塊主要提供成員管理服務，為節(jié)點的加入和離開提供成員身份證書注冊和注銷功能。共識服務主要實現(xiàn)交易提案的分階段驗證，并采用Gossip協(xié)議實現(xiàn)數(shù)據(jù)分發(fā)，保證同一個鏈上不同節(jié)點區(qū)塊數(shù)據(jù)的一致性。鏈碼服務通過合約程序執(zhí)行學位證書相關業(yè)務邏輯。密碼安全服務主要提供密鑰生成、哈希運算、簽名校驗和加解密等基礎功能。賬本狀態(tài)由CounchDB存儲，與默認LevelDB數(shù)據(jù)庫相比，其支持富查詢和建立索引，查詢效率更高。

2.2 網絡節(jié)點架構

本設計為了兼顧系統(tǒng)的高可用性和高交易吞吐量，采用圖4所示的含有3個組織和Kafka集群的系統(tǒng)網絡節(jié)點架構[8]。根據(jù)業(yè)務合約方法和賬本狀態(tài)變化，圖4中前臺系統(tǒng)的交易提案主要劃分見表1。

圖4中的CA節(jié)點作為成員服務提供商(membership service provider，MSP)，結合PKI(public key infrastructure)技術，基于標準的X.509證書格式為節(jié)點成員提供注冊、數(shù)字證書發(fā)行和數(shù)字證書延期與吊銷，實現(xiàn)節(jié)點之間數(shù)據(jù)傳輸?shù)暮灻万炞C。記賬節(jié)點負責驗證區(qū)塊交易并記賬，維護狀態(tài)數(shù)據(jù)和賬本副本。同時在鏈碼實例化的時候，背書策略會指定每個組織中的一個記賬節(jié)點動態(tài)充當背書節(jié)點角色，用于接收前臺系統(tǒng)的交易背書請求，模擬執(zhí)行交易提案并對結果進行簽名背書。主節(jié)點是由每個組織通過選舉機制產生并與排序服務節(jié)點通信，負責接收排序服務廣播的新區(qū)塊，并通過Gossip協(xié)議實現(xiàn)組織內各記賬節(jié)點賬本數(shù)據(jù)的同步。記賬節(jié)點數(shù)據(jù)同步過程大體如下：

圖4 系統(tǒng)節(jié)點架構

表1 系統(tǒng)交易提案類型

一個記賬節(jié)點接收到消息后，隨機地選擇K個節(jié)點進行消息發(fā)送。節(jié)點之間會有一個基于反熵的狀態(tài)同步過程，每個節(jié)點周期性地與鄰居節(jié)點交換保存的數(shù)據(jù)并對比本地數(shù)據(jù)和鄰居節(jié)點保存的數(shù)據(jù)，檢查是否有缺失或過期的數(shù)據(jù)，并進行本地節(jié)點數(shù)據(jù)的更新。

Kafka集群主要用于提高區(qū)塊鏈網絡的交易處理速度，由于Kafka無法保證一個主題中多個分區(qū)間消息的有序性，本系統(tǒng)通過在區(qū)塊鏈網絡啟動時創(chuàng)建一個編號為0的分區(qū)，確保從排序服務節(jié)點提交到Kafka的交易消息有序性。同時區(qū)塊鏈網絡中只創(chuàng)建一個通道，確保圖中3個組織節(jié)點都屬于一條鏈，實現(xiàn)不同組織節(jié)點賬本數(shù)據(jù)和狀態(tài)數(shù)據(jù)的同步共享。圖4中一個通道對應Kafka的一個主題，排序服務節(jié)點在不同階段充當不同的角色。接收交易階段時，排序服務節(jié)點充當生產者，負責將交易轉發(fā)給Kafka集群，并通過權限檢查轉發(fā)給對應通道的主題。消息處理階段時，排序服務節(jié)點充當消費者，從Kafka集群中獲取交易信息，并把交易排序、分割打包成區(qū)塊，通過原子廣播給組織內的主節(jié)點。

其中Kafka集群應滿足條件1N為了當任意一個節(jié)點出現(xiàn)故障時，仍能繼續(xù)創(chuàng)建新通道，提交新交易進行排序生成新區(qū)塊。

2.3 系統(tǒng)交易共識過程

前臺系統(tǒng)發(fā)起表1中的交易提案后，直到賬本狀態(tài)發(fā)生變化或返回學位證書信息的世界狀態(tài)，經歷了圖5所示的共識過程[9]。

圖5 交易共識過程

(1)交易背書

交易背書是對交易進行背書的規(guī)則，本文以大多數(shù)子規(guī)則成立的隱含元策略作為背書策略，滿足背書策略才是有效的交易。圖5中，有3個背書節(jié)點，當前臺系統(tǒng)提交學位證書交易提案后，背書節(jié)點會調用鏈碼模擬執(zhí)行交易提案的內容并生成讀寫集，同時調用交易系統(tǒng)鏈碼ESCC(endorsement system chaincode)對讀寫集結果進行結構轉換和簽名背書，只有交易獲得2個及以上的背書數(shù)量才會標記為有效的交易。

(2)構造交易請求并發(fā)送給排序服務節(jié)點

前臺系統(tǒng)收集交易背書并進行簽名驗證，如果交易提案只是進行賬本查詢，則不會構造交易發(fā)送給排序節(jié)點。如果交易提案對賬本狀態(tài)進行更改，則會重新構造該交易并發(fā)送給排序服務。排序服務會根據(jù)交易信封中的指定通道名稱，在通道內按照時間順序對接收到的交易進行排序并生成區(qū)塊。

(3)交易驗證并同步區(qū)塊

記賬節(jié)點負責對接收到的區(qū)塊交易進行有效性驗證，主要包括背書策略驗證和雙花檢測。校驗時會對模擬執(zhí)行時狀態(tài)數(shù)據(jù)版本和提交交易時狀態(tài)數(shù)據(jù)版本進行比較，如果版本不一致，則校驗失敗，標記為無效交易。同時會驗證是否符合指定的背書策略，不滿足也標記為無效的交易。對于區(qū)塊中有效的交易，記賬節(jié)點會記錄到賬本數(shù)據(jù)并同步更新狀態(tài)數(shù)據(jù)庫的世界狀態(tài)。

3 系統(tǒng)智能合約

智能合約也稱為鏈碼，運行在由背書節(jié)點進程獨立出的安全Docker容器中，用于處理被網絡成員認可的業(yè)務邏輯，對鏈碼執(zhí)行結果達成一致后才能實現(xiàn)賬本狀態(tài)的更改。網絡中每個記賬節(jié)點都會存儲圖3中的賬本數(shù)據(jù)和狀態(tài)數(shù)據(jù)，驗證通過的交易最終會打包生成區(qū)塊，并以區(qū)塊文件的形式存儲在每個記賬節(jié)點的賬本數(shù)據(jù)中，而基于Key-Value存儲結構的狀態(tài)數(shù)據(jù)庫負責記錄交易執(zhí)行的狀態(tài)結果。本文以學位證書編號作為唯一鍵值，保證每條數(shù)據(jù)記錄的唯一性。合約中建立了圖6所示的學位證書DegreeInfo結構，承載學位證書信息的具體屬性。

圖6 學位證書屬性結構

結合表1中的交易提案，對于驗證通過的交易，鏈碼可以通過PutState(key，value)、GetState(key)、DelState(key)、GetHistoryForKey(key)等方法實現(xiàn)學位證書的登記、修改、吊銷和歷史狀態(tài)查詢等功能，其中key為學位證書編碼，value為序列化的DegreeInfo結構信息。以上對學位信息的增刪改是指在區(qū)塊鏈中記錄下對數(shù)據(jù)所發(fā)生的交易，即作為一筆交易記錄在賬本數(shù)據(jù)中[10]，而狀態(tài)數(shù)據(jù)只是記錄交易執(zhí)行的結果。

4 系統(tǒng)驗證

4.1 系統(tǒng)測試環(huán)境

依照圖4，采用Kafka集群、Orderer排序節(jié)點集群和3個組織方式驗證本系統(tǒng)設計的可行性和正確性。其中為了避免單點故障和腦裂問題，選擇3個Zookeeper節(jié)點，為了滿足容錯的最小節(jié)點數(shù)，選擇4個Kafka節(jié)點，共使用表2所示的19臺PC機作為網絡節(jié)點，測試環(huán)境配置見表3。

表2 系統(tǒng)節(jié)點

表3 實驗配置

4.2 系統(tǒng)測試用例及結果

針對不同的高校類別和學位類型，測試用例分別采集了50張學士學位證書、30張碩士學位證書和30張博士學位證書。因篇幅原因，這里以東北師范大學的學士學位證書為例。

系統(tǒng)用戶通過前臺系統(tǒng)發(fā)起證書登記請求，登記成功后會在區(qū)塊鏈網絡中生成一筆交易。圖7左邊為測試用例上鏈后的世界狀態(tài)，圖7右上角為該筆交易在賬本數(shù)據(jù)的交易記錄詳情，從圖7中可以看出兩者的交易號一致。

圖7 測試用例及驗證結果

4.3 系統(tǒng)交易吞吐量測試

交易吞吐量是指單位時間能夠完成交易的最高個數(shù)，本系統(tǒng)交易吞吐量的測試方法為：通過頻率可調的交易生成器隨機生成交易，以每300筆交易為單位，依次向區(qū)塊鏈網絡節(jié)點發(fā)送300-1200筆交易，并在統(tǒng)計時間內記錄區(qū)塊鏈上的交易數(shù)量，通過取平均數(shù)方式得到穩(wěn)定的網絡交易吞吐量。圖8是交易數(shù)量分別為300、600、900和1200筆的4組測試實驗，每組交易重復執(zhí)行30次的實驗結果，表4為4組實驗穩(wěn)定交易吞吐量結果。

從圖8和表4可以看出，除了網絡波動造成的個別組次結果差異較大，系統(tǒng)交易吞吐量維持在180-250Tps，而比特幣區(qū)塊鏈的每秒交易是7筆，以太坊區(qū)塊鏈交易每秒大約為幾十筆，本系統(tǒng)設計的交易吞吐量更高。

圖8 交易吞吐量測試結果

表4 穩(wěn)定吞吐量結果

5 結束語

本文結合區(qū)塊鏈技術所具有的優(yōu)點，提出了一種基于區(qū)塊鏈的學位證書信息存證系統(tǒng)設計。學位證書信息由區(qū)塊鏈網絡節(jié)點共同維護，安全性更高。將Kafka機制應用于區(qū)塊鏈交易信息處理，能夠提升區(qū)塊鏈的交易處理速度，相比于使用比特幣區(qū)塊鏈和以太坊區(qū)塊鏈實現(xiàn)學位證書信息存儲驗證，本系統(tǒng)的交易吞吐量性能表現(xiàn)更優(yōu)。實際生產環(huán)境下，區(qū)塊鏈網絡節(jié)點數(shù)量將更多，將進一步考慮節(jié)點的數(shù)量對交易速度的影響。