a. 主鏈和側鏈之間的區塊頭同步
在本體主鏈的共識治理模型中，本體網路每隔一定數量的區塊更換一次共識節點，在一個共識週期內，驗證者集合保持不變。因此，如果側鏈是同構鏈，那麼鏈區塊頭同步過程不需要同步所有區塊，只需要同步關鍵區塊（即切換驗證者集合的週期切換區塊）和跨鏈交易發生的區塊即可，這樣的設計大大減少了區塊頭的同步數量。
為了防止側鏈關鍵區塊頭同步在一個共識切換週期結束後沒有更新，而產生前一個側鏈共識週期驗證人構造惡意區塊頭的情況，本體在主鏈的多鏈管理合約中包含了側鏈共識週期管理。當前側鏈的驗證人可修改該屬性，若側鏈共識週期結束後，沒有新的關鍵區塊頭被提交，側鏈與主鏈間的跨鏈互動將會被終止。若新的側鏈驗證人發現在主鏈中的共識週期與側鏈實際的共識切換週期不符，可在主鏈上修改該屬性。同時，側鏈也會受到相應的懲罰。
b. 側鏈和側鏈之間的區塊頭同步
側鏈與側鏈之間和主鏈與側鏈之間的區塊頭同步過程有所不同，即關鍵區塊頭資訊取得方式的不同。但是，這兩者包含跨鏈交易的區塊頭同步過程相同。主鏈上記錄了所有側鏈的資訊，假定 A 鏈和 B 鏈兩條側鏈希望直接建立連線。可以看到， A 鏈和 B 鏈都可以從主鏈拿到對方關鍵的區塊頭資訊，並且這些資訊經過了主鏈的共識。因此， A 鏈和 B 鏈不需要互相註冊，也不需要從創世區塊開始同步對方的關鍵區塊頭資訊，只需要取得對方鏈需要跨鏈的前一個關鍵區塊頭資訊即可。
2.2 跨鏈管理合約
當 dApp 處理跨鏈互動時，dApp 合約先處理其在源鏈上的邏輯，需要跨鏈時呼叫跨鏈管理合約的跨連結口。狀態資訊同步者Relayer 將狀態資訊的證明同步給目標鏈（的跨鏈管理合約）後，dApp 將繼續處理其在目標鏈上的邏輯。具體流程如下：
✔ 源鏈的跨鏈管理合約會為每一筆跨鏈交易分配一個自增 ID，並將跨鏈交易放入 Merkle Tree，而 Merkle Root 會被放入當前區塊的區塊頭中，完成後會將該自增 ID 和區塊高度透過事件推送出去。同時，在發起跨鏈交易時，使用者需要將一部分的 ONG 作為礦工費用在源鏈上銷燬或凍結。
✔Relayer 負責監聽這些跨鏈事件，當監聽到一筆跨鏈交易時，Relayer 根據 ID 和區塊高度去源鏈上獲取 Merkle 證明。然後，Relayer 將 Merkle 證明提交到目標鏈，提交過程需要支付一筆目標鏈的礦工費。
✔目標鏈（的跨鏈管理合約）接收到該 Merkle 證明，向區塊頭同步合約獲取對應的區塊頭，得到 Merkle root 並驗證在源鏈上已完成的跨鏈交易的合法性，標記該交易 ID 為已花費，然後根據跨鏈交易的引數，跨合約呼叫目標鏈上的 dApp 合約，完成目標鏈上 dApp 合約的邏輯。
✔該跨鏈交易在目標鏈上被執行成功後，Relayer 會取得相應的礦工激勵。根據交易的不同，這可能是側鏈 ONGx 合約增發的 ONGx，也可能是主鏈多鏈管理合約中釋放的 ONG。
三、後記
透過區塊頭同步合約和跨鏈管理合約這兩個模組，本體可以實現鏈與鏈之間相互驗證對方交易的合法性，為跨鏈奠定基礎。
在以後的本體技術視點文章中，我們將給大家帶來更多關於本體跨鏈設計的具體細節。目前，本體跨鏈測試網已經上線，也提供了詳細的跨鏈使用教程和多鏈開發手冊，希望廣大技術愛好者來體驗本體跨鏈測試網路。
