曌鏈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觀察網編輯修改或補充。