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

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

主持人：“百度資深工程師，目前負責超級鏈的架構設計，對區塊鏈的賬本、事務模型有深入研究。在百度期間負責過萬億級網頁鏈接庫實時存儲，Feed統一內容池、垂搜多版本數據庫等項目，他今天帶來主題分享《區塊鏈與數據庫技術對比及融合展望》感謝君意?！?/p>

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

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

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

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

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

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

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

數據的處理過程需要按照多方約定并公示后的規則來執行的場景；

數據的副本需要維護在多個不完全互信節點的場景。

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

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

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

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

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

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

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

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

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

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

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

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