10月19日，百度超級鏈與金色財經(jīng)在北京聯(lián)合主辦“區(qū)塊鏈與數(shù)據(jù)庫的融合碰撞”技術沙龍，IBM、眾享比特、conflux、covenantSQL等行業(yè)內合作伙伴，共聚一堂，對各自在公鏈、聯(lián)盟鏈等場景中的實際需求和經(jīng)驗，展開熱烈的討論和分享。不僅僅聚焦技術，話題還延展到了“在產業(yè)應用中遇到的困難與挑戰(zhàn)”。

首先百度資深工程師孫君意進行了《區(qū)塊鏈與數(shù)據(jù)庫技術對比及融合展望》主題分享，以下為演講整理。

主持人：“百度資深工程師，目前負責超級鏈的架構設計，對區(qū)塊鏈的賬本、事務模型有深入研究。在百度期間負責過萬億級網(wǎng)頁鏈接庫實時存儲，F(xiàn)eed統(tǒng)一內容池、垂搜多版本數(shù)據(jù)庫等項目，他今天帶來主題分享《區(qū)塊鏈與數(shù)據(jù)庫技術對比及融合展望》感謝君意。”

孫君意：大家好，很高興大家能夠參加我們的沙龍，抽出周末的寶貴時間，今天主要給大家分享“區(qū)塊鏈與數(shù)據(jù)庫技術對比及融合展望”。

首先我們來思考一個問題，區(qū)塊鏈和數(shù)據(jù)庫在哪些維度上有共性，我自己有一個簡單的定義，我認為區(qū)塊鏈和數(shù)據(jù)庫都是數(shù)據(jù)管理技術，數(shù)據(jù)管理并不高深，我們用一個Excel就可以進行。我們在項目實施過程中會被客戶問到一個問題，為什么這個項目非得用區(qū)塊鏈，因為區(qū)塊鏈難以篡改，比如說有密碼的支撐，比較方便實現(xiàn)多方共享。但是這些是不是足以說這個項目就可以用區(qū)塊鏈，我認為如果在應用層做很多間接改造也可以實現(xiàn)大部分功能，但是其中有一部分很難實現(xiàn)，就是在參與管理數(shù)據(jù)的多方存在不信任的場景下，這種場景下是很難用傳統(tǒng)數(shù)據(jù)庫解決的。除非多方之間選出大家都公信的“盟主”，讓它來管理這個數(shù)據(jù)庫，這個時候業(yè)務用數(shù)據(jù)庫就可以做，否則的話是行不通的。

我認為區(qū)塊鏈的革命性就是實現(xiàn)了可信的數(shù)據(jù)管理，有兩個方面，第一個是存儲的可信；第二個是數(shù)據(jù)處理過程的可信。通過區(qū)塊鏈的共識算法實現(xiàn)了在去中心的網(wǎng)絡環(huán)境下成百上千個節(jié)點維護一致性的數(shù)據(jù)副本。并且，數(shù)據(jù)的變更都是公開透明和可審計的，每個節(jié)點都會驗證，不管是密碼驗證還是合約執(zhí)行結果的驗證，都會在各個節(jié)點執(zhí)行。

網(wǎng)絡規(guī)模越大，公信力越強，事實上人們也愿意為可信帶來的溢價買單。一個簡單的例子，如果現(xiàn)在在亞馬遜的RDS存儲1GB的數(shù)據(jù)，成本大概是每月0.25美元，但是同樣如果存在以太坊上，大概需要三萬兩千個ETH，有7200多個節(jié)點分布式地在全球存儲其副本。區(qū)塊鏈通過共識算法和智能合約，在實踐層面真正實現(xiàn)了可信的數(shù)據(jù)管理，這是具有革命性的。

另外一方面，很多人也看到區(qū)塊鏈有很多的局限性，出現(xiàn)了一些悲觀的看法，比如認為區(qū)塊鏈都是更慢的數(shù)據(jù)庫，鏈式哈希不新鮮，Git中早就有了；絕大多數(shù)場景用數(shù)據(jù)庫就夠了， 不是剛需——Nice to Have ， Not musthave，但是我認為這種看法是錯誤的。

我總結一下區(qū)塊鏈適用的場景有三點：

數(shù)據(jù)的變更歷史需要透明、可審計的應用場景；

數(shù)據(jù)的處理過程需要按照多方約定并公示后的規(guī)則來執(zhí)行的場景；

數(shù)據(jù)的副本需要維護在多個不完全互信節(jié)點的場景。

本次分享內容會從三個關鍵的技術維度去對比：事務管理、共識算法和編程范式。從事務管理角度來看，區(qū)塊鏈真的很慢嗎？其實并不慢。為了性能，大多數(shù)數(shù)據(jù)庫的默認事務隔離級別較弱，而NUS最新研究表明：當Isolation Level設置為最高級別（SERIALIZABLE）情況下，主流分布式數(shù)據(jù)庫的性能和HyperLedger Fabric是一個數(shù)量級的（400 TPS左右），單一的這種場景下，傳統(tǒng)數(shù)據(jù)庫和區(qū)塊鏈相比并沒有性能上的絕對優(yōu)勢。

再一個我們來看一下如何實現(xiàn)多版本并發(fā)控制，數(shù)據(jù)庫一般有全局時間戳或者序號生成器，每個事務也有自己的序號，可以通過讓事務只能讀到序號比它序號小的數(shù)據(jù)版本實現(xiàn)不同事務的隔離。

由于要實現(xiàn)去中心化，區(qū)塊鏈一般沒有全局序號，而是通過顯式的Reference關系表達事務之間的“順序”。比如：比特幣中，交易的Input指向了其他交易，表達了一種”Happen Before”的語意，HyperLedger Fabric中，事務需要申明自己的“讀寫集”，其中，讀集的版本是通過（區(qū)塊高度， 塊內序號）二元組引用。

在我們超級鏈里面的事務模型是XuperModel，它是基于經(jīng)典的UTXO模型演化而來，經(jīng)典的UTXO模型只能描述轉賬場景，而XuperModel創(chuàng)新之處在于可以描述更加通用的數(shù)據(jù)變更。

舉個例子，這里有個“計數(shù)器”合約，調用一次，Counter變量就會加一。從上圖可以看到，每個事務的Input字段有個哈希指針指向其依賴的其他事務的Output。也就是說，事務的Input描述了它讀取的變量的舊版本，而Output體現(xiàn)了事務一旦成功后會賦予變量的新值。圖中，T2和T2’這兩個事務是沖突的，因為他們的Input引用了相同的變量的舊版本，但是輸出是賦值同一個變量。最終，T2和T2’只能有一筆上鏈，另外一筆會回滾。

再一個，超級鏈底層的數(shù)據(jù)多版本機制實現(xiàn)也與數(shù)據(jù)庫不同。數(shù)據(jù)庫的一般做法是將邏輯Key+版本號拼接成物理Key，但是這個方式只能保留有限個版本，一旦版本太多，就會導致區(qū)間查詢迭代很慢，因為要Scan大量無用的老版本。超級鏈用了一種鏈式哈希的多版本接口，在狀態(tài)樹中Key對應的Value只是哈希指針，指向賬本中事務的Output字段，要回溯之前的老版本也只需要通過事務的Input指針再往前回溯。當需要回滾事務或區(qū)塊的時候，產生的IO開銷也極低。

這里再舉一個簡單的例子，還是剛才那個“計數(shù)器”場景。假設Alice和Bob幾乎同時發(fā)起合約調用。合約執(zhí)行到Get調用，得到同樣的值是 42，版本也一樣是tx1。然后加一計算得到43，再分別進行Set提交，Alice先提交的就可以將值更新到43，版本更新到tx3，而對于Bob，雖然運算過程是對的，但是最終提交時候的版本已經(jīng)過期了，因為其依賴的版本等于tx1而現(xiàn)在最新的版本是tx3，所以就會失敗。

我們再看一下共識算法的詳細對比，說到共識算法不得不提一下FLP原理，原論文發(fā)表于1982年，大概是說：在異步網(wǎng)絡下，多個節(jié)點中就算只有一個錯誤節(jié)點，也無法找到確定性的算法保證同時滿足safety和liveness。這個FLP給大家提供了分布式系統(tǒng)設計的理論指導，而實踐中，數(shù)據(jù)庫的共識更多的是犧牲了liveness而確保saftey， 比如raft。相反地，區(qū)塊鏈尤其是公鏈則是犧牲了safety而優(yōu)先保證liveness比如，比特幣的交易如果是剛剛上鏈，那是有一定概率因為分叉被回滾掉的，不夠safety，但是好處是整個系統(tǒng)一直可以提交交易，就算有分叉，最終會通過最長鏈原則達到一致性。

上面的表格詳細對比了數(shù)據(jù)庫&區(qū)塊鏈在容錯、選主方式、日志復制、安全和活性等方面的差異，并且區(qū)分了公鏈和聯(lián)盟鏈。

下面看一下編程范式對比。數(shù)據(jù)庫領域已經(jīng)有統(tǒng)一的編程范式，就是SQL（Structured QueryLanguage），具體實現(xiàn)上有一些方言的差別。區(qū)塊鏈的編程范式是智能合約（Smart Contracts），然而其具體的實現(xiàn)千差萬別，比較有影響力的是以太坊的Solidity語言。

最后來做一下兩者未來融合展望。我認為區(qū)塊鏈和數(shù)據(jù)庫有融合的契機，我寫出來了兩種可能，有一種是把區(qū)塊鏈作為引擎接入到數(shù)據(jù)庫中，相當于從底層改造存儲引擎實現(xiàn)去中心化的數(shù)據(jù)庫。另外一個方向，區(qū)塊鏈借鑒一下數(shù)據(jù)庫好的東西，比如像SQL，將SQL語句翻譯為智能合約代碼。

百度超級鏈已經(jīng)在推進數(shù)據(jù)庫與區(qū)塊鏈技術的融合，在合約層面支持了Table，后續(xù)計劃在Table接口之上再引入SQL引擎，使得用戶大部分情況下可以用SQL語句寫智能合約，提升系統(tǒng)的易用性。
來源： 百度超級鏈?