曌鏈MIT核心技術之跨分片—Cross Sharding區塊鏈
曌鏈MIT跨分片合約以曌鏈MIT的多級名字空間機制作為基礎，這種解決方式是直觀顯而易見的，而別的區塊鏈項目因為沒有多級名字空間這個基礎設施，無法應用該方案。
跨分片合約難點
跨分片合約的難點在于：一個分片對于共同訪問的狀態的修改，需要及時地讓另一個分片知道，否則就容易出現狀態錯亂。任何支持合約的分片技術，都必須要解決這個問題。目前業界大致有以下幾種方案：
第一種方案：讓發出交易的客戶端主動維護一致性，典型的就是Omniledger。客戶端負責驅動這個過程，避免分片之間的協議通信。優點是分片協議不用考慮維護一致性的問題，技術簡單，且避免了分片之間一致性協議的開銷。缺點顯而易見，沒法做到交易丟出去不管，客戶端在這個過程中必須保持運行。另外，客戶端去做這個事，真的安全么？實際上這個方案很難為業界所接受。我更傾向于認為，由于分片機制不完善，解決不了狀態一致性而強行打的補丁。
第二種方案：基于trace對交易進行標注，典型的就是Chainspace。交易注入到網絡中之前，先模擬trace，并以此標注出可能與其他交易沖突的地方，然后再根據這些沖突發到相關的分片中處理，相關的分片之間再用S-BAC去共識。這種方法，我想應該還是不能完全依照trace，還必須在代碼層面進行標注，否則一個if/else語句在trace環境和實際環境下就可能走向了截然不同的分支。另外每一個交易可能的沖突都要相關的分片之間去跑一輪共識，一個分片如果牽涉到很多個這樣的交易，那每一次就要跟不同的分片跑很多個這樣的共識。
第三種方案：交易分裂，典型的就是Ethereum。首先要說明的是，這種方式交易只能類似于幣的轉移這種，從一個分片中的地址，轉移到另一個分片中的地址。合約內部狀態是不能共享的，必須要保證每個分片的狀態是私有的。具體的做法就是將這個幣的轉移過程切開，分成幣的發送 幣的接受，并且在不同的共識周期中完成。具體在Ethereum中的話，在一個共識周期中，分片中的地址發送幣，并在主鏈中產生一個收據，然后在下一個共識周期中，另一個分片中的地址依據這個收據接受幣。看起來簡單，然而并非如此，可以用火車和旅館問題來比喻。你要去另一個城市玩，要定火車票，還要定旅館。倘若你定了火車票，但是旅館沒訂到，那就麻煩了；倘若你旅館訂到了，但是火車票沒訂到，你也麻煩了。要么都訂到，要么都沒訂到，那才是良好的狀態。問題產生的原因就是交易分裂到多個共識周期，破壞了原子性。Ethereum目前在這一塊還處于初步的理論研究階段，計劃在分片的第四期中實現。
曌鏈MIT跨分片合約
具體做法就是，將跨分片的交易在他們的父級分片中處理。以曌鏈MIT的多級名字空間機制作為基礎，這種解決方式是直觀顯而易見的，而別的區塊鏈項目因為沒有多級名字空間這個基礎設施，無法應用該方案。這種方案實現相對簡單，穩定可靠，可以支持的交易比較靈活，適應面廣，并且只需要一個共識周期就可以確認。但是，這種方案一個明顯的缺點就是，父級分片存在處理壓力的匯聚問題，越是上級的分片對吞吐率的要求越高。曌鏈MIT的解決方案是鼓勵交易盡量在低層分片解決。一方面，多級分片結構具有過濾作用，需要處理的分片比例隨著分片層級的升高而越來越低。需要說明的是：名字空間非常有利于數據的局部性，類似于CPU的緩存；而Ethereum那種按照地址前綴分配分片的做法，數據完全是隨機的，沒有局部性。另一方面，越上級的名字空間處理費用越高，通過經濟激勵手段讓合約只在必要的時候才跨分片，只在非常必要的時候才跨高層次的分片。
圖1：曌鏈MIT跨片示意圖
跨分片消息傳遞
每個實體都有一個URN，結構是 : <protocol_id>:<shard_path>/<public_key_fingerprint>.
每個實習都有一個通過公鑰來識別身份的郵箱. RChain分片是通過channel實現的.
每個分片都運行著一個Mailman合約來路由消息.
每條消息都包含這三個字段: destination, signature & payload
描述
同一個分片的消息傳遞
Mailman從消息中提取到destination，然后發送到目標郵箱
準備跨分片消息
在消息發送到其他分片前要經過共識，發送消息的意圖將存儲在塊鏈中，并且只有在塊完成后才發送。
圖2：曌鏈MIT跨片消息傳遞
子分片到父分片交易
向父分片發送消息的總結如下：
1、就發送消息到父分片的決定達成共識；
2、validators簽名然后把消息發送給父分片；
3、消息需要至少k個validators的簽名；
4、獲得k個簽名之后，消息存儲在區塊鏈中；
5、共識達成之后，進行下一步；
圖3：向父分片發送消息流程圖
父分片向子分片交易
傳輸過程如下:
1、就發送消息的決定達成共識；
2、子分片的validators作為父分片的客戶端，收到了這條消息；
3、子分片的validators在子分片的區塊鏈上存儲這條消息；
4、共識達成之后進行下一步動作；
圖4：向子分片發送消息流程圖
散列鎖托管轉移（Hash-locked escrow transfer）
愛麗絲和鮑勃要通過代幣P來交易貨物，他們需要以下的一個交易機制來保證：
1、愛麗絲擁有代幣P有效
2、在交易過程當中，代幣P在愛麗絲的賬戶金額當中鎖定，并且不能被其他交易使用
3、當得到了K次確認之后，交易執行成功
4、交易被取消的話，如果時間少于T，則代幣會歸還到愛麗絲的賬戶當中
圖5：散列鎖托管轉移流程圖
相關名詞解釋
Shard - 有自己的一組驗證人的獨立網絡節點群；
Shard tree - 分片的結構；
Neighbour shards - 相鄰的分片；
Mailman - 發送消息給別的分片的智能合約；
Mailbox - 存儲消息. 也是分片的客戶端；
Address - 多分片的環境里的實體的唯一標識. 包括分片id和公鑰；
Mint - 在分片當中創建和銷毀Token的智能合約；
Depository - 存儲子分片當中的Token余額的智能合約；
1.TMT觀察網遵循行業規范，任何轉載的稿件都會明確標注作者和來源；
2.TMT觀察網的原創文章，請轉載時務必注明文章作者和"來源：TMT觀察網"，不尊重原創的行為TMT觀察網或將追究責任；
3.作者投稿可能會經TMT觀察網編輯修改或補充。
