{
  "type": "IBCPackage",
  "attributes":
  [
    {
      "key": "IBCPackageInfo",
      "value": "96::8::19"
    }
  ]
}

其中：

• type 為 "IBCPackage"，表示跨鏈包；
• key 為 "IBCPackageInfo"，表示跨鏈包的信息；
• value 通過(guò)“::”分隔為3個(gè)字段，分別為 CrossChainID of destination chain、channel id、sequence；

1. CrossChainID
   對(duì)于 bsc-relayer 來(lái)說(shuō)，srcCrossChainID 為 BC 的 ChainID，destCrossChainID 為 BSC 的 ChainID。
2. channel id
   channel id 為跨鏈調(diào)用 BSC 系統(tǒng)合約（solidity）的 id，bsc-relayer 中包含有以下 4 個(gè) id：

3. sequence
   每個(gè) channel id 都對(duì)應(yīng)有一個(gè) sequence，用來(lái)計(jì)數(shù)。

（BSC 相關(guān)系統(tǒng)合約邏輯將在后續(xù)章節(jié)中進(jìn)行介紹）

3.2 拉取跨鏈?zhǔn)录?payload

bsc-relayer 根據(jù) channel id 和 sequence 組合生成唯一標(biāo)識(shí)，通過(guò) RPC 向 BC 請(qǐng)求對(duì)應(yīng)的 payload，這些 payload 以 bytes 的形式傳到 bsc-relayer。

3.3 同步

bsc-relayer 將上述的 payload 生成調(diào)用 CrossChain.sol 的 tx ，通過(guò) RPC 發(fā)送到 BSC。

4 拉取、同步 BC 塊頭

bsc-relayer 拉取的是 BC 的塊頭，BC 的塊頭本質(zhì)上是 Tendermint 塊頭，這里就不得不先介紹一下 Tendermint 的相關(guān)特性了：

In Tendermint, validators agree on a block before processing it. This means that the signatures and state root for that block aren't included until the next block. Thus, each block contains a field called LastCommit, which contains the votes responsible for committing the previous block, and a field in the block header called AppHash, which refers to the Merkle root hash of the application after processing the transactions from the previous block. So, if we want to verify the AppHash from height H, we need the signatures from LastCommit at height H+1. (And remember that this AppHash only contains the results from all transactions up to and including block H-1)

上文的大概意思是說(shuō)，一個(gè)塊的 狀態(tài) 和 簽名 等數(shù)據(jù)需要至少等到下一個(gè)塊才能得到，所以如果需要驗(yàn)證高度為 H 的塊，需要等到高度為 H+1 的塊的 LastCommit 信息（聲明一下，本人不是很了解 Tendermint 的算法，如果某些地方說(shuō)的不正確請(qǐng)及時(shí)指明）。

bsc-relayer 拉取 BC 塊頭的行為完全是 自身驅(qū)動(dòng) 的，當(dāng)出現(xiàn)以下兩種情況時(shí)進(jìn)行觸發(fā)：

1. BC validator 集合更新
   BC 本地會(huì)定期更新 bc-validator 集合，BSC 需要獲取每一輪的 bc-validator 集合信息，用于驗(yàn)證跨鏈數(shù)據(jù)，bc-validator 集合信息包括所有 bc-validator 的賬號(hào)、公鑰、投票（VotingPower）等。
   bsc-relayer 會(huì)一直輪詢每個(gè)高度的 BC 塊的 bc-validator 集合是否發(fā)生變化（包括當(dāng)前正在工作的 bc-validator 集合和下一輪即將更新的 bc-validator 集合），如果發(fā)生變化，則會(huì)打包 當(dāng)前工作的 bc-validator 集合信息、下一輪更新的 bc-validator 集合信息、當(dāng)前查詢的 BC 高度的塊頭，將其生成調(diào)用 TendermintLightClient.sol 的 tx，并發(fā)送到 BSC。
2. 查到跨鏈數(shù)據(jù)包
   bsc-relayer 會(huì)一直輪詢每個(gè)高度的 BC 塊是否有跨鏈數(shù)據(jù)包，如果在高度 H 查到了跨鏈數(shù)據(jù)包，如前文所述，則會(huì)先打包高度為 H+1 的塊頭 和 validator 集合信息，將其生成調(diào)用 TendermintLightClient.sol 的 tx，并發(fā)送到 BSC。

5 gas 問(wèn)題

上述可知 bsc-relayer 會(huì)不停向 BSC 發(fā)送交易，相當(dāng)于中繼自己出 gas 進(jìn)行工作。為了彌補(bǔ)這一損失，BSC 會(huì)在 RelayerIncentivize.sol 系統(tǒng)合約中向 bsc-relayer 發(fā)放系統(tǒng) reward，reward 應(yīng)該會(huì)遠(yuǎn)高于扣掉的 gas，否則就虧本 gg 了。

6 總結(jié)

bsc-relayer 作為中繼，不參與處理具體的數(shù)據(jù)結(jié)構(gòu)，只是作為數(shù)據(jù)的監(jiān)控者和搬運(yùn)工。

參考

https://github.com/bnb-chain/bsc-relayer.git