本文，作者首先介紹了拜占庭問題和口頭訊息演算法；其次，詳細討論以HyperLedger1.0為基礎的系統架構和資料庫事務處理流程，並分析該架構與傳統中心化資料庫的主要區別；最後，以南京政務網建設為例子闡述區塊鏈技術的具體應用。

作者 | 丁藝明

拜占庭問題

探究區塊鏈其源頭，我們不得不追溯到“拜占庭將軍問題”。它是整個區塊鏈技術核心思想的真正根源，也直接決定了區塊鏈技術的種種與眾不同的顛覆性特質。

在2013年獲得電腦科學領域最高獎項圖靈獎的31年前，萊斯利·蘭伯特（Leslie Lamport）加入斯坦福國際研究院（SRI）。在SRI那段歲月裡， 有一個專案，要在美國航空航天局建立容錯型航電計算機系統。考慮到系統的工作性質，故障是不允許發生的。這段經歷孕育了兩篇旨在解決一種特殊故障的論文，由蘭伯特和SRI同事馬歇爾·皮斯（Marshall Pies）及羅伯特·肖斯塔克（Robert Shostak）合作完成。使用計算機術語，普通故障可能會導致資訊丟失或程序停止，但系統不會遭到破壞，因為這種普通故障屬於一出錯就會停下來的故障型別，剩下的備份的、正常的部分照樣可以運轉，發揮作用。就像戰場上的士兵，他們一旦受傷或陣亡就停止戰鬥，但並不妨礙他人繼續作戰。然而一旦發生“拜占庭故障”，就會非常麻煩，因為它們不會停下來，還會繼續運轉，並且給出錯誤訊息。就像戰爭中有人成了叛徒，會繼續假傳軍情，惑亂人心。使用三臺計算機進行萬一其中一臺出錯的備份工作，並不能完全解決這個問題。三臺獨立的計算機按照少數服從多數的原則“投票”。要求其中一臺機器提供了錯誤結果的情況下，其他兩臺仍然會提供正確答案。但是為了證明這種解決“拜占庭故障”方法的有效性，必須拿出證據。而在編寫證據的過程中，研究人員遇到了一個問題：“錯誤”的計算機可能給其他兩臺計算機發送互不相同的資訊，而後者卻無法區別正確性。這就需要使用第四臺計算機來應對這類“拜占庭故障”。

蘭伯特認為把問題以講故事的形式表達出來更能引起人們的關注。蘭伯特還聽吉姆·格雷談論過另一個性質大體相同的問題，這引起了蘭伯特有關司令將軍和叛徒將軍的聯想，於是他將這個問題及其解決方案命名為“拜占庭將軍問題”。

拜占庭帝國想要進攻一個強大的敵人，為此派出了10支軍隊去包圍這個敵人。這個敵人雖不比拜占庭帝國，但也足以抵禦5支常規拜占庭軍隊的同時襲擊。基於一些原因，這10支軍隊不能集合在一起單點突破，必須在分開的包圍狀態下同時攻擊。他們任一支軍隊單獨進攻都毫無勝算，除非有至少6支軍隊同時襲擊才能攻下敵國。他們分散在敵國的四周，依靠通訊兵相互通訊來協商進攻意向及進攻時間。困擾這些將軍的問題是，他們不確定其中是否有叛徒，叛徒可能擅自變更進攻意向或者進攻時間。在這種狀態下，拜占庭將軍們能否找到一種分散式的協議來讓他們能夠遠端協商，從而贏取戰鬥？這就是著名的拜占庭將軍問題。

應該明確的是，拜占庭將軍問題中並不去考慮通訊兵是否會被截獲或無法傳達資訊等問題，即訊息傳遞的通道絕無問題。蘭伯特已經證明了在訊息可能丟失的不可靠通道上試圖通過訊息傳遞的方式達到一致性是不可能的。所以，在研究拜占庭將軍問題的時候，我們已經假定了通道是沒有問題的，並在這個前提下，去做一致性和容錯性相關研究。

口頭訊息演算法，簡稱OM（m）

在原始的戰爭年代，將軍與將軍、將軍與下屬間只能採用原始的方式——“出行靠走，通訊靠吼”的口頭傳輸。這對應蘭伯特論文提出演算法中的第一部分的口頭訊息演算法，簡稱OM（m）演算法。這種情形，真偽很難辨別，只有當叛徒的總數不超過將軍總數的1/3，成為一個特殊的“拜占庭容錯系統”時，才能在很大的訊息驗證代價後，實現最終的一致行動。這個結果非常令人驚訝，如果將軍們只能傳送口頭訊息，除非超過2/3的將軍是忠誠的，否則該問題無解。尤其是，如果只有三個將軍，其中一個是叛變者，那麼此時無解。但這樣的錯誤，這樣的有意、無意的“叛徒”卻可能經常出現。

首先，我們明確什麼是口頭協議。我們將滿足以下三個條件的方式稱為口頭協議：

A1：每個被髮送的訊息都能夠被正確的投遞

A2：資訊接收者知道是誰傳送的訊息

A3：能夠知道缺少的訊息

簡而言之，通道絕對可信，且訊息來源可知。

定義一個變數vi（為不失一般性，並不要求vi是布林值），作為其他將軍收到的第i個將軍的命令值；i將軍會將把自己的判斷作為vi。可以想象，由於叛徒的存在，各個將軍收到的vi值不一定是相同的。之後，定義一個函式來處理向量(v1,v2,…,vn)，代表了多數人的意見，各將軍用這個函式的結果作為自己最終採用的命令。至此，我們可以利用這些定義來形式化這個問題，用以匹配一致性和正確性。

一致性

條件1：每一個忠誠的將軍必須得到相同的(v1,v2,…,vn)指令向量或者指令集合。

這意味著，忠誠的將軍並不一定使用i將軍送來的資訊作為vi，i將軍也可能是叛徒。但是僅靠這個條件，忠誠的將軍的資訊送來的資訊也可能被修改，這將影響到正確性。

正確性

條件2：若i將軍是忠誠的，其他忠誠的將軍必須以他送出的值作為vi。

OM(0)演算法

1. 司令將他的命令傳送給每個副官。

2. 每個副官採用從司令發來的命令；如果沒有收到命令，則預設為撤退命令。

OM(m)演算法

1. 司令將他的命令傳送給每個副官。

2. 對於每個i，vi是每個副官i從司令收到的命令，如果沒有收到命令，則預設為撤退命令。副官i在OM(m-1) 中作為發令者將之傳送給另外n-2 個副官。

3. 對於每個i，和每個j ≠ i，vj 是副官i 從第2步中的副官j （使用OM(m-1)演算法）傳送過來的命令，如果沒有收到第2步中副官j 的命令，則預設為撤退命令。最後副官i 使用majority(v1,…,vn-1)得到命令。

其中，majority(v1,…,vn-1)代表了大多數人的命令，若不存在則預設為撤退命令。

口頭訊息演算法例項推演

考慮m=1，n=4的情形：

n=4，意味著一個司令傳送命令給三個副官，m=1意味著他們中有一個叛徒。首先考慮司令忠誠而副官3是叛徒的情況。



圖1   m=1，n=4中司令忠誠而副官3是叛徒的情形

參考圖1，

L1收到：（A，A，R）=》輸出共識 majority(A，A，R) = A

L2收到：（A，A，R）=》輸出共識 majority(A，A，R) = A

L3收到：（A，A，A）=》輸出共識 majority(A，A，R) = A

那麼對於副官1（或副官2）來說將會採用A。

倘若司令是叛徒，為方便，我們假設叛徒司令在OM(1)會給三個副官傳送的資訊是(x,y,z)，其中x，y，z都可以是A或R的任意一種。之後，三位忠誠的副官將會按照OM(0)要求的那樣，交換他們收到的資訊。



圖2  m=1，n=4中司令是叛徒的情形

L1收到：（x，y，z）=》輸出共識 majority（x，y，z） ；

L2收到：（x，y，z）=》輸出共識 majority（x，y，z）；

L3收到：（x，y，z）=》輸出共識 majority（x，y，z）。

對於副官1，他綜合司令、副官2和副官3後得到的訊息向量將會是(x,y,z)，可以發現對於其他兩個忠實的副官，他們得到的訊息向量也將是(x,y,z)。不管x，y，z如何變化，majority(x,y,z)對於三人來說都是一樣的，所以三個副官將會採用一致的行動。

口頭訊息演算法證明

演算法的證明思路其實並不複雜，簡單的來說，對於一個遞迴演算法，基於一個叛徒情景下的例項推演，可使用數學歸納法來證明。考慮篇幅，這裡未提供完整的證明，可參考相關資料。

HyperLedger1.0系統架構

Hyperledger是被業界非常看到的聯盟鏈的實現，包括IBM、Intel、R3、各個大型商業銀行等都參與其中，帶給我們關於區塊鏈技術與軟體工業、金融、保險、物流等領域碰撞結合的想象空間；在這個聯盟中，有超過1/4的成員都來自中國，這更是我們對於它的一舉一動都非常關注。很大程度上，Hyperledger和它背後的聯盟體系就代表著區塊鏈在產業環境中的未來。

主要模組：

• 客戶端SDK（Client SDK）: 協助應用安全管理、和協助處理區塊鏈上交易事務。

• 節點是網路中的組成部分，負責維護節點的賬本和職能合約。

• 任意多個節點可參與到網路中。
  

• 節點型別可以是背書節點（endorser）、或交付節點（committer ）。背書節點必然是交付節點。
  

• 背書節點執行並對交易事務進行背書。

• 交付節點驗證背書結果並對交易事務進行驗證。

• 節點管理事件集線器（event hub）併發送事件給訂閱者。

• 節點組建成一P2P網路。

• 節點是無執行狀態的，事務與事務間是獨立的。

• 排序服務（Ordering Service）：是處於一個非中心化的網路中的一箇中心化的節點。其排序服務是一可插拔的元件，例如Kafka、或BFT等。

• 成員許可權管理：通過基於 PKI 的成員許可權管理，平臺可以對接入的節點和客戶端的能力進行限制。



圖3  HyperLedger1.0系統結構圖

事務交易流程

HyperLedger1.0的共識機制（Consensus）是通過事務背書策略（Transaction Endorsement Policy）、排序服務、和各提交節點Committer的校驗這三個措施保證的。

背書（Endorsement）: 每個背書節點（stakeholder ）決定是否接受或拒絕一事務。

排序服務（Ordering）: 對執行後的事務進行排序形成一即將提交的區塊。

校驗（Validation）: 所有提交節點（Committer ）都需校驗事務的背書是否滿足背書政策（Endorsement Policy），同時根據資料庫多版本併發控制MVCC，校驗事務轉換是否有效。

以背書節點n=4、提交節點數p=5為例子。背書策略設定為：4個背書節點中，允許1個拜占庭故障節點情況下，要求有3個以上的有效簽名。



圖4  事務交易流程

也就是，如果允許m個無效簽名的情況下，要求背書節點總數n>=3*m + 1，即需要有效簽名數n-m>=2*m+1。如圖4所示事務處理流程為：

步驟1：提交事務

客戶端SDK提交一報文為Propose的訊息的交易事務Transaction到客戶端選擇的背書節點E0，要求執行一智慧合約A。



圖5   步驟1提交事務

步驟2：第一個背書節點執行事務

被客戶端選中的背書節點E0模擬交易的執行。



圖6   步驟2第一個背書節點執行事務

步驟3：其他背書節點執行事務

客戶端根據背書策略，要求其他節點E1E2和E3進一步背書。



圖7   步驟3其他背書節點執行事務

步驟4：背書籤名

背書節點對智慧合約的執行結果進行簽名，併發送背書籤名給客戶端。



圖8  步驟5提交排序服務

步驟5：提交排序請求

最後，客戶端根據背書政策（Endorsement Policy）檢查是否滿足條件，若滿足條件則傳送給排序服務。



圖9  步驟6交付

步驟6：交付

排序服務叢集交付事務執行結果的下個版本的賬本資料塊給各節點。



圖10  步驟7校驗並更新

區塊鏈應用於政務網

傳統中心化的電子證照技術自2008年發展至今，解決了傳統模式下的資料歸集和中心化的資料標準與安全問題。但經過近十年的“網際網路+政務服務”的應用發展，該技術也凸顯它的侷限性。

• 跨部門的政務資料是否可信

• 資訊難以全面歸集

• 資訊難以快速檢索

• 資訊洩露安全隱患

• 系統穩定性難度大

• 金字塔模式效率低下

雖然已有的人口資訊、法人資訊實現了部分集中管理，但中心化系統存在資訊洩露，儲存丟失等風險，而且中心化系統的建設、維護成本非常高，無法互動驗證，無法實現各個部門真正意義上的資訊共享、共建。所以，如何在現有的電子政務基礎上，打破部門的資料壁壘，實現各部門之間的高效協作，實現真正意義的“一張網”，為群眾提供便利的服務，是政務工作迫切需要解決的問題。

另外，區塊鏈技術具有資訊共享、資訊透明、難以篡改的優勢。利用該優勢可打破原有資訊傳遞的壁壘，實現電子證照服務模式的創新，提升使用者體驗。

目前證照辦理過程中，大部分步驟需線上下處理，並且受到地域、時間的限制，需消耗較多的時間；同時紙質證明存在易偽造風險，相關證明接收機構還需核驗證明的真偽性。

通過區塊鏈技術打造各類證明的線上認證服務模式，可以提供證明從申請、開立、查詢、銷燬的全流程服務，打造電子證明生態圈。該創新將帶來巨大的社會效益：

對於證明所有者，無須在證明開立方和證明使用方來回傳遞紙質證明，省卻了物理地點（如異地）對證明開立及使用的限制；

對於證明提供方的權威機構，可通過自動化審批替代目前的人工審批，大大提高了工作效率和服務水平；

對於證明需求方，基於區塊鏈的電子證明難以偽造及篡改，大大降低了虛假證明的風險。



圖11  “我的南京”App政務辦理

在南京政府多部門的支援下，率先上線全國第一批基於區塊連結技術的電子證照共享平臺。參見圖11，市民可通過“我的南京”App進行政務的辦理，“我的南京”App是該電子證照共享平臺的資料訪問終端。電子證照共享平臺由政府職能部門共同組成的電子證照區塊鏈網路，建立起政府部門之間點對點的可信網路。採用區塊鏈的去中心化同步記帳、交易身份認證、資料不可篡改、以及資料加密等多種技術手段。參見圖12電子證照政務網結構圖，網路由資訊中心、公安、民政、社保、稅務、衛生等多個節點組成。共享賬本中儲存公民資訊和資料歸集記錄。在智慧合約中實現了資料目錄規則、和資料隱私管理規則。現有電子證照網路只支援南京市的資料，考慮到擴充套件性支援，通過全國索引節點，不同城市不同省份的資料索引到不同的電子證照區塊鏈子網。



圖12  電子證照政務網結構圖

基於區塊鏈技術的電子證照共享平臺與傳統的電子證照庫相比，具有更好的真實現、安全性、穩定性及可行性，解決了傳統中心化架構的電子證照庫採集和應用過程中權責不分的問題，徹底解決了資料被篡改的可能性，並通過激勵機制提升資料相關方共享資料的積極性，且具備資料不被篡改、去中心化、資料加密及信任傳遞的特徵，創新實現電子證照在全省、全市範圍內跨區域的資訊歸集、快速檢索和結果應用。透過任意職能部門提供照證證明服務，提高政務工作效率，提高市民、企業的辦事效率。對進一步推進南京“網際網路＋政務服務”，深化簡政放權、放管結合，實現各部門、各層級間政務服務資料共享，促進政府高效施政，提供了強有力的支援。

區塊鏈弱併發問題

在應用區塊鏈解決方案於政務網工程建設過程中，發現不少區別於傳統關係型資料庫的區塊鏈特點。

HyperLedger其設計目標主要包括一致性（共識）、保密性、可擴充套件性和安全性，但是對高併發寫事務的支援並不其主要目標。HyperLedger採用樂觀鎖（多版本併發控制）機制來支援併發，當交付節點（Submitter Peers）提交事務之前，如果發現ReadSet和WriteSet已經不一致了，將回滾事務。客戶端需要儘可能避免同一關鍵字的寫衝突，如果寫衝突，需要多次提交事務。

假設在同一時刻有10個事務同時提交，當時這10個事務讀取到的賬本的資料一致。第一階段，各背書節點執行事務，計算每個事務的讀集合ReadSet0~9（K,V）和寫集合WriteSet0~9（K,V），並提交到排序服務；第二階段，排序服務對10個事務進行排序，並依次提交到所有的交付節點（Submitter Peers），交付節點會根據當前賬本中的值檢查對應於某一事務的讀集合和寫集合。如果對於同一個鍵Key，被前一個事務修改了，則該事務的讀集合與當前賬本的讀集合不一致，則該事務不得不回滾。

為了避免並行執行的事務讀寫衝突，提升事務的併發執行效率。對於出現讀寫衝突的事務，採用拆分事務成為兩個階段的方法，在背書階段記錄事務的明細賬，在提交階段才進行彙總。例如對於會員積分變更的應用場景，在背書階段，記錄會員積分的變化明細，+ x1 + ... + xi 和 - y1 - ... - yi，在提交階段才進行彙總積分的變更 D += + x1 + ... + xi - y1 - ... - yi 。

關係型資料建模的支援

區塊鏈的底層資料模型為比較簡單的鍵值對Key/Value模型，對於現實中的結構化資料的建模一般採用關係資料模型，如果採用Key/Value模型，開發人員需要耗費很多精力用於各種應用場景下資料模型的建設，和資料的索引、查詢、統計等常規處理；同時儲存在區塊鏈中的資料需要進行進一步的大資料分析和資料探勘工作，需要支撐區塊鏈中的資料的匯入匯出到關係型資料庫。另外現有區塊鏈還沒有支援資料的隱私保護、資料的提交維護和訪問的許可權管理。需要一完善的區塊鏈資料建模基礎框架來解決這些基於區塊鏈的應用開發問題。

基於鍵值資料模型為基礎進行關係型資料建模，其支援的特徵包括：

基於鍵值資料模型，選擇一取值唯一的欄位作為鍵，包括多個屬性欄位的記錄作為值，記錄用獨立於語言的輕量級資料交換格式JSON進行編碼。

支援表結構、索引結構資料字典的維護；屬性欄位支援數值型別、字串型別、日期型別。這些型別的欄位是有序的、可建索引的；支援屬性索引，索引型別包括唯一索引、非唯一索引。索引的維護與記錄的增刪改同步，同時索引資料結構的維護對模型的使用者透明。對於複雜結構的欄位例如結構陣列，可用JSON編碼，只是該JSON型別欄位不支援索引。另外利用索引支援資料約束，例如屬性欄位取值的唯一性約束。

支援豐富的資料查詢方式，例如根據鍵的某一取值查詢記錄；根據鍵的取值範圍查詢多條記錄；根據已建立唯一索引的屬性欄位的某一取值查詢記錄；根據已建立非唯一索引的屬性的某一取值，或屬性欄位的取值範圍查詢多條記錄；支援分組統計，例如基於屬性欄位的非唯一索引進行分組統計，統計函式包括個數統計、取分組的最大值、最小值、平均值；支援分頁查詢和分頁統計；支援區塊鏈資料的匯入匯出到關係型資料庫，用於支撐資料分析。

後續豐富的政務網應用

本電子證照共享平臺還將實現更多政務事項線上辦理功能，如：“購車資格證明線上辦理”、“戶口線上遷入”、“社保線上轉移”、“公積金線上提取”、“護照線上辦理”、“出入境自助簽註”等。

作者簡介：丁藝明，榮澤科技區塊鏈高階諮詢顧問、高階架構師。

推薦閱讀

瞭解更多區塊鏈技術及應用內容

敬請關注：