[[354925]]

從數據庫的角度看待區塊鏈的存儲機制會簡單直觀很多。在一個標準的關系型數據庫中，存儲一般分為日志存儲、用戶數據存儲、以及索引存儲三大類(有些數據庫可能還包含大對象存儲等)。而區塊鏈項目中基本所有的“賬本”存儲其本質就是交易日志存儲。用戶數據存儲則根據項目不同而有選擇性地采用。譬如說對于UTXO結構的區塊鏈項目來說，其每個賬號對應的余額直接保存在內存哈希表中(或類似LevelDB等嵌入式KV數據庫中)，因此不需要一個獨立的外接用戶數據存儲模塊。而類似Hyperledger等通用區塊鏈框架則一般包含類似State Store等存儲最終結果數據的模塊。索引存儲則在當前大部分區塊鏈項目中均不存在。

1.賬本格式

區塊鏈的鏈式結構筆者在這里不再贅述，其每個塊包含上一個塊的哈希值，而內容則使用默克爾樹進行校驗以實現快速驗證，每條記錄則使用數字簽名的方式保證其一定來自擁有私鑰的用戶。

(圖1：區塊鏈數據結構)

對比傳統數據庫的日志結構，區塊鏈結構并不復雜。一般來說，所有傳統數據庫日志結構都比較相似，每個日志文件包含日志頭與多個日志數據頁，其中日志頭代表其起始交易號(Oracle中叫做SCN，DB2中叫做LSN)，也就是該日志文件中第一條日志記錄在整個日志空間中的起始字節數，以及日志文件大小，日志頁大小等元數據信息。緊接著真實的日志記錄則以二進制碼流的方式依次存放在文件中，每一條日志記錄頭包含該條記錄的交易號、事務號、同一事務中上一條記錄的交易號(反向指針)，以及變更前與變更后的數據(滿足回滾要求)。

因此，從結構上來看，區塊鏈賬本與數據庫日志本質上沒有任何區別，僅僅在數據結構上為了滿足一些特定要求做了部分優化。

2. 存儲內容

通用型數據庫與當前大部分區塊鏈賬本項目(例如比特幣、以太坊等，而Hyperledger這類區塊鏈平臺則不包含在內)從日志的角度看，最大的區別在于區塊鏈賬本項目對于日志格式進行了高度定制化與業務綁定。

一般來說，傳統的數據庫日志包含的是數據頁的變更信息，我們叫做“寫前鏡像”和“寫后鏡像”，代表新的數據寫入前這條記錄長什么樣子，同時新數據寫入后這個記錄長什么樣子。通過這種方式，可以很輕易地在磁盤中的某個數據頁的指定偏移上進行數據前滾與回滾操作。

譬如說一條數據庫日志并不會記錄一個INSERT操作的具體命令，而是以“X數據頁的第Y個槽位，其所對應的偏移地址數據由ABC變化為DEF，總長度Z”的方式體現出來。因此，數據庫的日志幾乎可以記錄任何信息，這也是為什么通用數據庫可以被用來實現任何業務邏輯的原因。

而大部分的賬本項目則高度定制化其日志結構，例如以太坊的每一條交易信息都會包含輸入金額、輸出金額、燃料等信息，然后每一個節點在進行驗證時必須判斷其符合某種規則，否則不予通過。這種機制可以看做是一個完全高度定制化的數據庫業務，每一條日志記錄不僅僅記錄數據內容的變更，而是與業務邏輯緊密耦合，記錄每個賬戶的余額變化。

因此，從可擴展性來看，盡管以太坊等項目支持“智能合約”，但是其核心本質還是一個高度定制化的賬本系統，其業務邏輯與交易結算進行了非常緊密的綁定。

3. 設計思路

從設計哲學上看，當前的區塊鏈與數據庫在對通用業務的支持上采用了兩種不同的策略。對于傳統數據庫來說，其秉承的設計理念是“業務與數據分離”的思路，也就是說數據庫僅負責數據的存放，通過提供一種靈活的查詢語言能夠讓應用程序直接訪問數據庫進行增刪改查，但是基本所有的業務邏輯由應用程序自行定義。

但是，對于區塊鏈來說則是存儲與業務邏輯緊耦合的思路。在區塊鏈，尤其是公鏈的設計哲學中，因為每個存儲節點和應用都是不可信的，因此大部分業務邏輯需要在協議層進行高度定制。一個區塊鏈節點即需要對協議層進行解析和封裝，同時也需要負責對數據本地化落盤和存儲。

因而，盡管站在高層面可以將區塊鏈看做是多活數據庫，但是如果從具體實現層面來看，每個區塊鏈節點又不能簡單地看做是一個傳統數據庫的多活替代品，而是一套包含協議解析封裝和一部分業務邏輯的應用軟件。

4. 用戶數據存儲

如果未來區塊鏈的目標是作為通用平臺，用以存儲多種類型的數據，則其日志格式與存儲必須回歸數據庫的通用性本源。當前的賬本模式可以作為該體系中的一個特別模塊存在用以進行賬戶間結算，但是無法將其擴展為通用業務平臺。

既然要成為通用數據存儲平臺，那么UTXO模型存在一定局限性。在一個典型的銀行業務中，零售業務可能會包含千萬甚至億級別的賬戶，不同賬戶可能使用不同的利息計算規則，也可能存在凍結等特殊狀態。而交易流水信息每天可能達到千萬筆，如果將其業務擴展到非金融行業，流水信息每天幾億也是可能的。因此，從一個通用賬戶+流水的業務模型中，一般企業會建立一個賬戶表與一個流水表，以不同的策略進行管理。

賬戶表俗稱余額類數據，在典型的數據治理體系中需要做到定期快照備份(例如月初數和月末數);而流水表則成為流水類數據，一般來說以原始交易格式直接存儲和備份。通過對余額類數據快照備份的恢復，對指定賬號重做某個時間范圍內的全部交易流水，可以得到該賬號任意時間點的余額信息。

而UTXO的本質在于日志存放的信息不是記錄的最終結果，而是變化行為。在傳統數據庫中，每條事務記錄的是數據的寫前與寫后內容。例如將一條記錄從5更改為8，其數據庫日志記錄原始數據為5且新數據為8，而不是記錄“+3”的操作。但是UTXO記錄的是變更信息，其主要的目的是解決雙花問題(例如對于一個有100塊錢的賬號，一個人在中國轉走10塊錢，另一個人在美國同時轉走10塊錢，如果記錄的是最終結果，那么中國的服務器會認為這個人有90塊，美國的服務器在沒有全局鎖的情況下也會認為這個人有90塊，最終寫到區塊中就變成90塊余額，而非80)。

UTXO的機制可以有效地在無鎖的情況下避免雙花問題，但是其劣勢則在于不存儲余額表，所有的信息均通過重做流水數據，從零開始生成。對于一個存在了十年以上，包含幾百億筆交易的系統來說，這樣的做法就好比每次重啟都要從都重做幾百筆交易并存入內存中(或KV數據庫里)，是一種非常原始且不經濟的方式。

另一方面，區塊鏈日志的結構看來，由于多活系統中全局鎖很難實現，因此需要通過交易日志結構的調整來滿足傳統數據庫中事務的功能。傳統數據庫中當涉及到兩賬戶之間轉賬操作時需要開啟一個事務。在事務日志中一個賬戶增加一個賬戶減少的業務邏輯，需要體現為包含三條記錄的鏈表(最后的提交操作也是一個記錄)。在數據庫崩潰或發生異常后，只要通過重做所有的任務，并最后對全部沒有提交記錄的事務進行反向操作，即可得到原子性(Atomic)與持久性(Durability)。

而在區塊鏈體系中由于不存在事務的概念，同時操作日志與結算業務進行了緊密耦合，因此每條交易記錄都會包含一個輸入賬號以及若干個輸出賬號，也就是說只要一條事務記錄被成功發送給一個節點，則可以保證在該記錄內部的全部輸入輸出賬戶統一進行了變更。可以說，區塊鏈通過定制化交易日志簡化了事務操作的復雜性，但是帶來的影響便在于業務與代碼的緊密耦合不可分割。

但是無論如何，首先UTXO并不是通用數據結構，而是為交易業務高度定制化的數據結構，如果想要運行圖靈完備的智能合約(或者說存儲過程)，使用UTXO會有很多局限性。第二，對長期運行的大型系統(相比起大中型銀行核心交易系統所產生的交易流水，比特幣從誕生到現在的交易量少得可以忽略不計)，UTXO每次初始化需要全部的歷史交易日志。這種模式完全不可能適用于大型交易系統。

因此，可以存在兩種做法解決該問題。第一種方式使用傳統賬戶表與流水表的機制，將UTXO以流水的方式體現出來，同時定期保存賬戶快照，以避免每次重構數據庫都需要重做全部交易(這種機制需要考慮到賬戶與流水表在多活系統中，沒有全局鎖的情況下如何實現一致性的問題)。而對于非結算類交易，通用型區塊鏈項目則可能采用日志結合用戶數據存儲的模式，才能夠普適性地滿足通用業務需求(這種機制需要依靠比nonce更好的排序機制避免雙花)。

5. 索引存儲

當前基本沒有任何區塊鏈項目支持用戶數據的自定義索引。這種機制在未來的通用型區塊鏈項目一定會被彌補。從本質上看當前的區塊鏈項目結構沒有任何理由無法在其上構建通用索引能力(包括B樹索引、位圖索引、全文檢索等)。

小結

區塊鏈的存儲體系現在還處于數據庫上世紀80年代的階段，其當前最大的問題在于日志結構與業務邏輯的緊密耦合(讀者可以理解為應用程序為每種業務邏輯都要從頭實現一遍Oracle)。而這樣做的本質原因在于多活數據庫中事務的原子性與鎖極難保障，因此當涉及到多個賬戶的轉賬原子操作時，當前大部分賬本類區塊鏈項目均不得不定制日志結構，將每一筆交易的全部信息放在一條記錄中。從數據庫的角度看，在區塊鏈項目中實現跨記錄的原子操作(包括全局鎖)極為復雜，而這也正是區塊鏈技術向通用型數據存儲進化的關鍵所在。

筆者認為，隨著區塊鏈應用越發廣泛，人們在不久的將來一定會將各類區塊鏈應用泛化出一系列典型的場景和需求。基于這些場景和需求，一定會出現一批優秀高效的多活數據存儲。不論這些機制的后臺到底是否基于“區塊”的架構實現，其這正需要突破的是現有數據庫體系中無法做到active-active的局限(也就是去中心化)。