由于當前智能合約多為串行執(zhí)行和串行驗證，導致性能一般，無法滿足業(yè)務(wù)需求。百度超級鏈提出了一種新的區(qū)塊鏈數(shù)據(jù)模型：XuperModel?；谶@

由于當前智能合約多為串行執(zhí)行和串行驗證，導致性能一般，無法滿足業(yè)務(wù)需求。百度超級鏈提出了一種新的區(qū)塊鏈數(shù)據(jù)模型：XuperModel?；谶@樣的底層數(shù)據(jù)模型，XuperChain可以使用多核計算能力來同時執(zhí)行和驗證智能合約，大大提升效率。

本期超級鏈學院微課堂的主題就是“為你揭開智能合約的高并發(fā)面紗——XuperModel”!明星講師超哥先來為你劃重點啦，本次課程會講清楚以下幾點：

1. 底層的數(shù)據(jù)模型對于區(qū)塊鏈系統(tǒng)的重要性

2. 超級鏈獨創(chuàng)數(shù)據(jù)模型——XuperModel詳解2

3. 智能合約的性能瓶頸問題超級鏈如何解決

4. XuperModel與其他數(shù)據(jù)模型的異同點

5. XuperModel為開發(fā)者提供了哪些能力

Q1：數(shù)據(jù)模型對一個區(qū)塊鏈系統(tǒng)而言重要么?

非常重要。數(shù)據(jù)模型體現(xiàn)了一個區(qū)塊鏈系統(tǒng)對數(shù)據(jù)的組織方式，屬于核心設(shè)計，是其區(qū)別于其他系統(tǒng)的重要特征。例如，比特幣的UTXO，以太坊的MPT，HyperLedger Fabric的讀寫集，都是大家所熟知的區(qū)塊鏈數(shù)據(jù)模型。

Q2：超級鏈的數(shù)據(jù)模型是什么?

超級鏈的數(shù)據(jù)模型是XuperModel，是基于UTXO模型進一步泛化、抽象而來的一種通用數(shù)據(jù)模型。經(jīng)典的UTXO模型只能描述數(shù)字資產(chǎn)的轉(zhuǎn)移，而XuperModel可以描述由智能合約執(zhí)行而引起的數(shù)據(jù)變更， 同時又沒有犧牲掉UTXO并發(fā)性能好的優(yōu)點。

Q3: XuperModel和UTXO相比，相同點和不同點是什么?

相同點是每筆交易都會引用和它相關(guān)的之前發(fā)生的交易。只不過，UTXO模型中，交易的引用關(guān)系表明了資金的來源，而XuperModel中存在兩種引用關(guān)系：一種是表述數(shù)字資產(chǎn)的來源，另一種是表述數(shù)據(jù)的版本依賴關(guān)系。兩種引用關(guān)系分別用TxInput和TxInputExt兩個字段來表示。當交易中只存在數(shù)字資產(chǎn)轉(zhuǎn)移時，XuperModel就退化為UTXO模型。

Q4: 如何知道智能合約執(zhí)行依賴的數(shù)據(jù)版本呢?

在超級鏈中通過預(yù)執(zhí)行來確定智能合約依賴的數(shù)據(jù)版本。在預(yù)執(zhí)行階段，超級鏈內(nèi)核會為每個智能合約的請求構(gòu)造一個“沙箱”環(huán)境，其發(fā)起的讀取和寫入請求都會被內(nèi)核捕獲，從而可以記錄到它讀取的數(shù)據(jù)的版本和即將寫入的數(shù)據(jù)內(nèi)容。

Q5: 其他節(jié)點如何驗證智能合約的正確性呢?

每個交易都是自描述的，其他節(jié)點可以根據(jù)交易中的引用信息復(fù)原智能合約的“沙箱”環(huán)境，復(fù)原的過程中需要檢測其依賴的資產(chǎn)來源和數(shù)據(jù)版本是否仍然有效。如果是過期的版本，或者資產(chǎn)已經(jīng)被其他交易使用，那么復(fù)原沙箱失敗。如果復(fù)原環(huán)境成功，接下來就會調(diào)用虛擬機去執(zhí)行這個合約，執(zhí)行合約的過程是Lock-Free的，因此并發(fā)性能好。最后，在內(nèi)核數(shù)據(jù)生效時，會Double-Check引用關(guān)系的有效性，最終生效到狀態(tài)機里面。

Q6: 那么各個節(jié)點如何最終達成一致的狀態(tài)呢?

主要是解決判斷沖突的問題。大家應(yīng)該都用過git，當我們運行g(shù)it pull的時候，經(jīng)常會發(fā)生你的本地內(nèi)容和他人沖突，而需要手動介入解決沖突。XuperModel的原理很類似，數(shù)據(jù)的唯一標識是Bucket + Key， 其中Bucket對應(yīng)合約名字，Key對應(yīng)存取的變量名。如果多個交易都修改了同一個數(shù)據(jù)，且他們不存在父子引用的話，那么就是互相沖突的。在XuperModel中，區(qū)塊中的交易擁有更高優(yōu)先權(quán)，可以回滾掉和它沖突的未確認交易。

Q7: 超級鏈中的數(shù)據(jù)底層是怎么存儲的呢?

底層有兩個DB，一個DB記錄了賬本，另一個DB維護著狀態(tài)機。數(shù)據(jù)每個版本的變更的詳細內(nèi)容都是記錄在賬本中的，狀態(tài)機中只是為每個變量存儲了一個Hash指針，這個Hash指針可以定位到賬本中的某個交易的某項輸出，體現(xiàn)的是這個變量的最新內(nèi)容。

Q8： 這種模型是支持多版本的么?

是的。默認情況下狀態(tài)機中的變量的Hash指針式指向最新版本的，通過交易的TxInputExt字段，可以往前回溯到更早的版本。這種多版本機制的優(yōu)勢是對迭代查詢、區(qū)間查詢也很友好，可以避免因遍歷無效版本而產(chǎn)生的IO開銷。同時，超級鏈節(jié)點也提供了賬本對齊的功能，類似于“git checkout”， 可以切換到歷史上任意區(qū)塊對應(yīng)的狀態(tài)。

Q9： XuperModel和Fabric的數(shù)據(jù)模型有什么異同?

首先，F(xiàn)abric的數(shù)據(jù)模型是不內(nèi)置數(shù)字資產(chǎn)轉(zhuǎn)移的描述的， 而XuperModel則是UTXO模型的泛化，天然支持了數(shù)字資產(chǎn)轉(zhuǎn)移的場景。其次，F(xiàn)abric的數(shù)據(jù)模型中，數(shù)據(jù)的版本是綁定到區(qū)塊高度的，因此對同一個Key的多次修改不能發(fā)生在一個區(qū)塊，就導致他不能實現(xiàn)“Read Your Own Update”的場景。XuperModel中數(shù)據(jù)的版本是直接引用前置交易的，因此可以立即生效，在同一個區(qū)塊中可以打包相關(guān)聯(lián)的對同一個數(shù)據(jù)的一系列修改行為。

Q10： 對于應(yīng)用開發(fā)者而言，基于XuperModel可以獲得哪些能力?

首先，獲得了天然的數(shù)據(jù)回溯能力。智能合約中的變量會隨著合約的調(diào)用不斷地發(fā)生變更，由于XuperModel維護了每次變更的前一個版本的哈希指針，可以順藤摸瓜得到之前這個合約變量的所有版本。例如，我們之前曾經(jīng)有篇小短文介紹了如何用200行智能合約代碼實現(xiàn)一個可回溯的文件系統(tǒng)：

https://mp.weixin.qq.com/s/8CWKX92WRkeG6MMXkPZmVQ。其次， XuperModel 解耦了智能合約的計算和存儲，使得智能合約的執(zhí)行可以利用上CPU多核的算力，提升整體的性能。

分享結(jié)束后，群里也涌現(xiàn)出了一些精彩問題，摘取部分分享給各位。

問：「 請問XuperModel和超級鏈說的DAG有什么關(guān)系?」

答：DAG是有向無環(huán)圖，是多個交易根據(jù)依賴關(guān)系構(gòu)成的。那么，如何構(gòu)建這種依賴關(guān)系呢?就需要借助XuperModel的能力為智能合約執(zhí)行構(gòu)造一個沙箱，為其捕獲到依賴關(guān)系，最終把這些交易串起來，形成DAG。

問：「XuperModel是每個節(jié)點一直維持著一張大圖還是每個交易都需要回溯?如果是前者，那賬本大了之后新節(jié)點加入需要花費很大時間，而且賬本大了這個表會很占內(nèi)存，該如何解決?」

答：在超級鏈里面，要想構(gòu)造交易，需要先“預(yù)執(zhí)行”，預(yù)執(zhí)行就錨定了交易依賴的數(shù)據(jù)版本，開銷相當于在DB中的隨機查(點查)。狀態(tài)機DB默認是leveldb，不需要長駐內(nèi)存。

問：「那是每個交易數(shù)據(jù)之中就寫好了前向的交易，需要預(yù)執(zhí)行的時候進行遞歸搜索，還是在leveldb中專門維持了一種聯(lián)系表?」

答：前半句對。交易的TxInputExt是這樣的：(ref_txid, ref_offset), 根據(jù)ref_txid可以反查到賬本中的這個被依賴的交易內(nèi)容，通過ref_offset可以拿到這個交易的TxOutput[ref_offset]這條數(shù)據(jù)內(nèi)容。因此不需要遍歷。

問：「 兩個DB如何保證事務(wù) 」

答：超級鏈中，一個DB是賬本，相當于binlog， 一個DB是狀態(tài)機，里面有個Hash指針指向最后一次執(zhí)行成功的區(qū)塊。狀態(tài)生效的粒度是區(qū)塊，通過Batch寫保證原子性，只要當區(qū)塊中的交易數(shù)據(jù)變更全部成功寫入狀態(tài)機后，這個Hash指針才會往后『滑動』。Hash指針本身也存儲在狀態(tài)DB中，隨同一個Batch刷下去。

問：「 智能交通業(yè)務(wù)中，節(jié)點的數(shù)據(jù)是否可以漂移在各共識節(jié)點?如果是秒級業(yè)務(wù)又該如何解決?」

答：數(shù)據(jù)的傳播通路有兩個：交易的廣播和區(qū)塊的廣播。

區(qū)塊的廣播是線性的，交易的廣播是亂序的。因此，可能出現(xiàn)交易對象構(gòu)造的交易依賴了一個對方節(jié)點還沒同步到的版本。但是，每個節(jié)點都會有例程廣播自己本地未確認的交易。

如果是秒級業(yè)務(wù)的話，就要看交易依賴的數(shù)據(jù)量有多大了，還有網(wǎng)絡(luò)的帶寬是公網(wǎng)環(huán)節(jié)還是內(nèi)網(wǎng)環(huán)境。在超級鏈中，首先是交易廣播先行(盡最大努力、立即廣播)，然后是區(qū)塊作為定序后的兜底，確保數(shù)據(jù)的最終一致性。

問：「使用UTXO數(shù)據(jù)模型，當區(qū)塊數(shù)據(jù)很多的時候，查找某個區(qū)塊中的交易ID所對應(yīng)的時間消耗就比較大，需要遍歷每個區(qū)塊，效率低，那么百度超級鏈，在交易信息查詢方面做了哪些優(yōu)化?」

答：在超級鏈是這樣存儲的：

Block Namespace：

blockid ->. (block header, txid[N])

Tx Namespace:

txid -> (blockid, tx content....)

因此，查一個交易，不用遍歷區(qū)塊，而是一次『點查』。（超哥）

關(guān)鍵詞： 百度超級鏈 XuperModel 數(shù)據(jù)模型