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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

再一個(gè)，超級鏈底層的數(shù)據(jù)多版本機(jī)制實(shí)現(xiàn)也與數(shù)據(jù)庫不同。數(shù)據(jù)庫的一般做法是將邏輯Key+版本號(hào)拼接成物理Key，但是這個(gè)方式只能保留有限個(gè)版本，一旦版本太多，就會(huì)導(dǎo)致區(qū)間查詢迭代很慢，因?yàn)橐猄can大量無用的老版本。超級鏈用了一種鏈?zhǔn)焦５亩喟姹?a target="_blank">接口，在狀態(tài)樹中Key對應(yīng)的Value只是哈希指針，指向賬本中事務(wù)的Output字段，要回溯之前的老版本也只需要通過事務(wù)的Input指針再往前回溯。當(dāng)需要回滾事務(wù)或區(qū)塊的時(shí)候，產(chǎn)生的IO開銷也極低。

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

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

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

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

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

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