由于當前智能合約多為串行執行和串行驗證，導致性能一般，無法滿足業務需求。百度超級鏈提出了一種新的區塊鏈數據模型：XuperModel。基于這
由于當前智能合約多為串行執行和串行驗證，導致性能一般，無法滿足業務需求。百度超級鏈提出了一種新的區塊鏈數據模型：XuperModel。基于這樣的底層數據模型，XuperChain可以使用多核計算能力來同時執行和驗證智能合約，大大提升效率。
本期超級鏈學院微課堂的主題就是“為你揭開智能合約的高并發面紗——XuperModel”!明星講師超哥先來為你劃重點啦，本次課程會講清楚以下幾點：
1. 底層的數據模型對于區塊鏈系統的重要性
2. 超級鏈獨創數據模型——XuperModel詳解2
3. 智能合約的性能瓶頸問題超級鏈如何解決
4. XuperModel與其他數據模型的異同點
5. XuperModel為開發者提供了哪些能力
Q1：數據模型對一個區塊鏈系統而言重要么?
非常重要。數據模型體現了一個區塊鏈系統對數據的組織方式，屬于核心設計，是其區別于其他系統的重要特征。例如，比特幣的UTXO，以太坊的MPT，HyperLedger Fabric的讀寫集，都是大家所熟知的區塊鏈數據模型。
Q2：超級鏈的數據模型是什么?
超級鏈的數據模型是XuperModel，是基于UTXO模型進一步泛化、抽象而來的一種通用數據模型。經典的UTXO模型只能描述數字資產的轉移，而XuperModel可以描述由智能合約執行而引起的數據變更， 同時又沒有犧牲掉UTXO并發性能好的優點。
Q3: XuperModel和UTXO相比，相同點和不同點是什么?
相同點是每筆交易都會引用和它相關的之前發生的交易。只不過，UTXO模型中，交易的引用關系表明了資金的來源，而XuperModel中存在兩種引用關系：一種是表述數字資產的來源，另一種是表述數據的版本依賴關系。兩種引用關系分別用TxInput和TxInputExt兩個字段來表示。當交易中只存在數字資產轉移時，XuperModel就退化為UTXO模型。
Q4: 如何知道智能合約執行依賴的數據版本呢?
在超級鏈中通過預執行來確定智能合約依賴的數據版本。在預執行階段，超級鏈內核會為每個智能合約的請求構造一個“沙箱”環境，其發起的讀取和寫入請求都會被內核捕獲，從而可以記錄到它讀取的數據的版本和即將寫入的數據內容。
Q5: 其他節點如何驗證智能合約的正確性呢?
每個交易都是自描述的，其他節點可以根據交易中的引用信息復原智能合約的“沙箱”環境，復原的過程中需要檢測其依賴的資產來源和數據版本是否仍然有效。如果是過期的版本，或者資產已經被其他交易使用，那么復原沙箱失敗。如果復原環境成功，接下來就會調用虛擬機去執行這個合約，執行合約的過程是Lock-Free的，因此并發性能好。最后，在內核數據生效時，會Double-Check引用關系的有效性，最終生效到狀態機里面。
Q6: 那么各個節點如何最終達成一致的狀態呢?
主要是解決判斷沖突的問題。大家應該都用過git，當我們運行git pull的時候，經常會發生你的本地內容和他人沖突，而需要手動介入解決沖突。XuperModel的原理很類似，數據的唯一標識是Bucket + Key， 其中Bucket對應合約名字，Key對應存取的變量名。如果多個交易都修改了同一個數據，且他們不存在父子引用的話，那么就是互相沖突的。在XuperModel中，區塊中的交易擁有更高優先權，可以回滾掉和它沖突的未確認交易。
Q7: 超級鏈中的數據底層是怎么存儲的呢?
底層有兩個DB，一個DB記錄了賬本，另一個DB維護著狀態機。數據每個版本的變更的詳細內容都是記錄在賬本中的，狀態機中只是為每個變量存儲了一個Hash指針，這個Hash指針可以定位到賬本中的某個交易的某項輸出，體現的是這個變量的最新內容。
Q8： 這種模型是支持多版本的么?
是的。默認情況下狀態機中的變量的Hash指針式指向最新版本的，通過交易的TxInputExt字段，可以往前回溯到更早的版本。這種多版本機制的優勢是對迭代查詢、區間查詢也很友好，可以避免因遍歷無效版本而產生的IO開銷。同時，超級鏈節點也提供了賬本對齊的功能，類似于“git checkout”， 可以切換到歷史上任意區塊對應的狀態。
Q9： XuperModel和Fabric的數據模型有什么異同?
首先，Fabric的數據模型是不內置數字資產轉移的描述的， 而XuperModel則是UTXO模型的泛化，天然支持了數字資產轉移的場景。其次，Fabric的數據模型中，數據的版本是綁定到區塊高度的，因此對同一個Key的多次修改不能發生在一個區塊，就導致他不能實現“Read Your Own Update”的場景。XuperModel中數據的版本是直接引用前置交易的，因此可以立即生效，在同一個區塊中可以打包相關聯的對同一個數據的一系列修改行為。
Q10： 對于應用開發者而言，基于XuperModel可以獲得哪些能力?
首先，獲得了天然的數據回溯能力。智能合約中的變量會隨著合約的調用不斷地發生變更，由于XuperModel維護了每次變更的前一個版本的哈希指針，可以順藤摸瓜得到之前這個合約變量的所有版本。例如，我們之前曾經有篇小短文介紹了如何用200行智能合約代碼實現一個可回溯的文件系統：
https://mp.weixin.qq.com/s/8CWKX92WRkeG6MMXkPZmVQ。其次， XuperModel 解耦了智能合約的計算和存儲，使得智能合約的執行可以利用上CPU多核的算力，提升整體的性能。
分享結束后，群里也涌現出了一些精彩問題，摘取部分分享給各位。
問：「 請問XuperModel和超級鏈說的DAG有什么關系?」
答：DAG是有向無環圖，是多個交易根據依賴關系構成的。那么，如何構建這種依賴關系呢?就需要借助XuperModel的能力為智能合約執行構造一個沙箱，為其捕獲到依賴關系，最終把這些交易串起來，形成DAG。
問：「XuperModel是每個節點一直維持著一張大圖還是每個交易都需要回溯?如果是前者，那賬本大了之后新節點加入需要花費很大時間，而且賬本大了這個表會很占內存，該如何解決?」
答：在超級鏈里面，要想構造交易，需要先“預執行”，預執行就錨定了交易依賴的數據版本，開銷相當于在DB中的隨機查(點查)。狀態機DB默認是leveldb，不需要長駐內存。
問：「那是每個交易數據之中就寫好了前向的交易，需要預執行的時候進行遞歸搜索，還是在leveldb中專門維持了一種聯系表?」
答：前半句對。交易的TxInputExt是這樣的：(ref_txid, ref_offset), 根據ref_txid可以反查到賬本中的這個被依賴的交易內容，通過ref_offset可以拿到這個交易的TxOutput[ref_offset]這條數據內容。因此不需要遍歷。
問：「 兩個DB如何保證事務 」
答：超級鏈中，一個DB是賬本，相當于binlog， 一個DB是狀態機，里面有個Hash指針指向最后一次執行成功的區塊。狀態生效的粒度是區塊，通過Batch寫保證原子性，只要當區塊中的交易數據變更全部成功寫入狀態機后，這個Hash指針才會往后『滑動』。Hash指針本身也存儲在狀態DB中，隨同一個Batch刷下去。
問：「 智能交通業務中，節點的數據是否可以漂移在各共識節點?如果是秒級業務又該如何解決?」
答：數據的傳播通路有兩個：交易的廣播和區塊的廣播。
區塊的廣播是線性的，交易的廣播是亂序的。因此，可能出現交易對象構造的交易依賴了一個對方節點還沒同步到的版本。但是，每個節點都會有例程廣播自己本地未確認的交易。
如果是秒級業務的話，就要看交易依賴的數據量有多大了，還有網絡的帶寬是公網環節還是內網環境。在超級鏈中，首先是交易廣播先行(盡最大努力、立即廣播)，然后是區塊作為定序后的兜底，確保數據的最終一致性。
問：「使用UTXO數據模型，當區塊數據很多的時候，查找某個區塊中的交易ID所對應的時間消耗就比較大，需要遍歷每個區塊，效率低，那么百度超級鏈，在交易信息查詢方面做了哪些優化?」
答：在超級鏈是這樣存儲的：
Block Namespace：
blockid ->. (block header, txid[N])
Tx Namespace:
txid -> (blockid, tx content....)
因此，查一個交易，不用遍歷區塊，而是一次『點查』。（超哥）
關鍵詞： 百度超級鏈 XuperModel 數據模型
