Fabric，全稱 Hyperledger fabric，中文稱“超級賬本” ，它是以區(qū)塊鏈技術(shù)為基礎(chǔ)設(shè)計的去中心化底層架構(gòu)，是Linux基金會于2015年發(fā)起的推進區(qū)塊鏈數(shù)字技術(shù)和交易驗證的開源項目。

在接觸區(qū)塊鏈時，我們是從以太坊開始研究學(xué)習(xí)的，后續(xù)還了解學(xué)習(xí)了比特幣、小蟻、超級賬本等區(qū)塊鏈相關(guān)項目。對于金融業(yè)務(wù)，因其對系統(tǒng)的穩(wěn)定性，健壯性，處理性能以及應(yīng)用的可擴展性等方面有很高的要求，通過從各方面對比，最終選擇了超級賬本作為項目的底層框架。在我們深入研究超級賬本的過程中，發(fā)現(xiàn)其并不是一個完善的框架，還存在著很多問題。

上圖為0.6版本整體架構(gòu)圖，被標(biāo)記部分是經(jīng)過我們改良的模塊，主要有以下幾點：

改良共識通道及消息處理機制

在進行性能測試時，我們發(fā)現(xiàn)超級賬本網(wǎng)絡(luò)對高并發(fā)交易的處理能力存在瓶頸。通過深入分析，發(fā)現(xiàn)在整個底層系統(tǒng)中存在多種不同類型的消息流，例如節(jié)點間用于廣播交易的消息和共識的消息等，而每個節(jié)點處理這些消息流的管道卻只有一個，這就好比一條高速路上只有一個檢票口一樣，檢票口的處理能力直接影響到高速的堵車概率。而在系統(tǒng)中，由于消息處理管道很容易被阻塞，導(dǎo)致優(yōu)先級高的消息因無法及時被處理而大量堆積，從而導(dǎo)致整個系統(tǒng)宕機。

通過分析，我們使用分流的方式來解決管道阻塞的問題（如上圖）。用單獨的A號管道去處理優(yōu)先級低但調(diào)用頻率高的消息（例如節(jié)點間的廣播消息），而一些優(yōu)先級高的消息（例如共識消息）則通過B號管道去處理，當(dāng)A號管道出現(xiàn)阻塞時，通過B號管道及時處理，可以逐漸消耗并恢復(fù)A號管道的能力。通過分流方式，保證各類消息能被及時處理，進而提高了系統(tǒng)的處理能力，也提升了系統(tǒng)的穩(wěn)定性。

我們知道，最小的超級賬本網(wǎng)絡(luò)需要四個節(jié)點才能正常運行，所以這些節(jié)點之間的通信能力就成了影響該網(wǎng)絡(luò)能力的一個重要因素。在測試中，我們也發(fā)現(xiàn)節(jié)點之間的各類通信都是通過一個通道進行處理的，當(dāng)有大并發(fā)量的交易進入網(wǎng)絡(luò)，節(jié)點之間大部分時間都在進行頻繁的交易廣播（將自己收到的交易信息發(fā)送給其他節(jié)點，以保障交易不被丟失），無法及時處理共識，這直接影響了該網(wǎng)絡(luò)處理交易的能力，所以，我們通過使用雙通道，將消息分開進行處理，使消息能夠被及時處理，進一步提升系統(tǒng)的處理能力及穩(wěn)定性。

改良內(nèi)存溢出

通過前面的修改，我們的重點開始落在系統(tǒng)對交易處理的能力上，而這個現(xiàn)象就是在壓力測試時出現(xiàn)的。當(dāng)我們以400筆每秒的速度向底層寫入數(shù)據(jù)時，隨著數(shù)據(jù)量的增加，某個節(jié)點就會出現(xiàn)宕機的現(xiàn)象，并且無法恢復(fù)，影響了系統(tǒng)的健壯性。通過分析日志、代碼，我們發(fā)現(xiàn)當(dāng)系統(tǒng)重啟時，會加載大量的已被存儲的數(shù)據(jù)，這使得大量的內(nèi)存被消耗，沒有資源去處理其他操作，導(dǎo)致系統(tǒng)宕機。

我們通過修改加載數(shù)據(jù)的邏輯，在保證對數(shù)據(jù)無影響的情況下，使系統(tǒng)快速恢復(fù)運行，提高了系統(tǒng)的健壯性。

改良視圖異常

視圖是共識中一個比較重要的概念，用于網(wǎng)絡(luò)中各節(jié)點的共識，其主要包含共識過程中產(chǎn)生的所有信息及狀態(tài)。在穩(wěn)定性測試過程中，當(dāng)長時間向超級賬本系統(tǒng)寫入大量數(shù)據(jù)時，會出現(xiàn)網(wǎng)絡(luò)中節(jié)點之間共識失敗，無法記錄交易的現(xiàn)象，通過跟蹤分析輸出日志，我們發(fā)現(xiàn)是由于各節(jié)點之間所存儲的視圖信息不一致而導(dǎo)致的。

修改代碼邏輯之后，通過將視圖階段性標(biāo)識（即每執(zhí)行一定量的交易后記一個標(biāo)識）和添加證書的方式來保證各節(jié)點所記錄的視圖信息的一致性，這樣使得網(wǎng)絡(luò)中各節(jié)點能夠穩(wěn)定運行，即使出現(xiàn)視圖紊亂，也會很快達成一致，恢復(fù)正常。

改良交易處理異常

對于一個金融系統(tǒng)，最不能容忍的就是丟失交易或出現(xiàn)“雙花”的現(xiàn)象，而超級賬本存在丟交易和“雙花”問題。主要是因為當(dāng)大量交易涌入到系統(tǒng)中，超出了系統(tǒng)的處理能力，部分交易的丟失就成為可能。為了防止這種現(xiàn)象的產(chǎn)生，我們通過增加中間層服務(wù)，控制流向底層網(wǎng)絡(luò)的數(shù)據(jù)量；啟用非驗證節(jié)點，使交易均等分發(fā)至其他節(jié)點，進而保證底層網(wǎng)絡(luò)中的節(jié)點能夠處理所有的交易，防止交易丟失。

而對于“雙花”現(xiàn)象，由于超級賬本網(wǎng)絡(luò)中各節(jié)點處理交易的延時，會導(dǎo)致部分交易被重復(fù)提交。經(jīng)過分析，我們通過調(diào)整過濾機制及過濾的時機，保證一筆交易只執(zhí)行一次， 進而防止“雙花”現(xiàn)象的出現(xiàn)。

改良讀寫異常

在進行壓力測試時，起初只是關(guān)注了底層系統(tǒng)對寫數(shù)據(jù)的能力，并未關(guān)注對數(shù)據(jù)讀取的能力。在后續(xù)進行并發(fā)讀寫數(shù)據(jù)操作時，發(fā)現(xiàn)一段時間后節(jié)點與合約之間的通信會斷開，導(dǎo)致進入網(wǎng)絡(luò)的數(shù)據(jù)無法記，而查詢操作也會失敗。深入剖析代碼，發(fā)現(xiàn)主要原因是由于原版設(shè)計中讀寫鎖設(shè)計不合理所導(dǎo)致的，通過修改讀寫部分的代碼邏輯，在不影響最終結(jié)果的情況下，將通信斷開的問題進行修復(fù)，進而保證了系統(tǒng)的穩(wěn)定性及功能的完善。并且將讀寫鎖的修改方案提交到github上，為超級賬本的發(fā)展貢獻了自己的一份力量。

就現(xiàn)在而言，超級賬本仍處于概念驗證階段，0.6版本不能在生產(chǎn)環(huán)境實施運行。而通過我們團隊不懈的努力，改進后的0.6版本已經(jīng)具備了上線運行的條件。隨著技術(shù)的成熟，我們推出的fabric1.0 Alpha 版本新增了許多新特性，并且此版本是官方推出可用于生產(chǎn)環(huán)境部署的商業(yè)級應(yīng)用，期待1.0版本為我們帶來的驚喜。