Key points and detail design of next Darwinia Ethereum-chains message protocol

[hackfisher]

According to the conclusions in darwinia-network/darwinia-messages-sol#76, we should use same frame message framework as substrate to substrate bridge to build the message protocol for bridges between Darwinia and Ethereum-chains. This benefit as following:

1. Eliminate the usage of MMR in message layer by switch proof model from (header_hash_in_mmr_root, event_in_reciept_root) to (account_in_header_state_root, storage_in_account)
2. Support confirm and return the delivery dispatch result in target chain back to source chain. This is important for application layer to build transactional businesses.
3. Unified message model for both substrate to substrate bridges and substrate to Ethereum chains.

Key points and detail design:

• We should use parity-bridge-common's substrate to substrate message pallet as a framework/template to develop the message pallet for the bridge between substrate and ethereum. The detail design and framework should be an important reference for the implementation of substrate-ethereum pallet. Due to following differences, we should develop separate pallet to accelerate the milestone instead of generalized pallet which will require upstream approve and merge. The generalization can be done in future. @AsceticBear @xiaoch05

  • Deprecated, cause both source chain and target chain will use smart contracts. ABI encode and SCALE encode conversion. In evm, the smart contracts might be hard to provide SCALE encode of remote calls, so the pallet might need to do conversion from ABI encode of call to SCALE encode before do runtime call dispatch in substrate side.
  • In the section Inbound MessageRoot Commitment Spec of Basic Message Channel, we've changed the leaf spec to (OutboundLandData_Hash, InboundLandData_Hash), and for message_proof() and devilvery_message_proof(), the proof will be Proof: merkle proof + OutboundLandData + InboundLandData_Hash and Proof: merkle proof + OutboundLandData_Hash + InboundLandData, for evm smart contract to save gas and easily decode OutboundLandData and InboundLandData from substrate, OutboundLandData and InboundLandData in storage might need to be encoded using ABI.
  • Related features for remote substrate chain, such as runtime call encode and fee weight calculation of remote chain call etc might not need in the pallet, and can be simplified and deleted.
  • Current ongoing pull request basic channel(substrate=>ethereum message) darwinia-common#793 should be replaced by this new approach, @hujw77 will help provide the next v2 version of the evm smart contract implementation of message protocol, current v1 version can be found here: https://github.com/darwinia-network/darwinia-bridge-sol/tree/master/contracts/bridge/contracts/binance

• We will need an alternative ethereum light client pallet for header sync and using (account_in_header_state_root, storage_in_account) to verify and decode messages and etheruem's InboundLaneData, instead of current version running in production which is using a. Include ethereum MMR b. (header_hash_in_mmr_root, event_in_reciept_root) as proof c. using txid to avoid replay attack instead of message nonce in new design.

  • We may choose to use new disign for BSC first, and replace current Ethereum implementation after BSC's bride is stable.
  • We may choose to not support Gringotts deposit further in wormhole after replace the message layer and truth layer for Ethereum.
  • We may need to implement new truth layer due to the upgrade plan of (Ethereum 2.0 Merge)[https://ethereum.org/en/eth2/merge/], expected to be before May of 2022.

• We need an v2 version of the evm smart contract implementation of message protocol, it will also reference the substrate InboundLaneData and OutboundLaneData as mentioned in Use s2s struct and framework to eliminate the requirement of MMR in message layer, and support receive_messages_delivery_proof(and app transactional support) darwinia-messages-sol#76 @hujw77

  • Current we might do have have support of simple solidity SCALE encode library according to https://substrate.dev/docs/en/knowledgebase/advanced/codec. To keep simple and consider the gas cost, we may choose to only use ABI encode/decode for message call and the OutboundLandData and InboundLandData decoded from the proof relayed from substrate.
  • Message hash and indexing details mentioned in Use s2s struct and framework to eliminate the requirement of MMR in message layer, and support receive_messages_delivery_proof(and app transactional support) darwinia-messages-sol#76 (comment)
  • Spec document need to updated.
  • Delivery message proof support, refer substrate message pallet framework.

• Shadow MMR services might not needed since the truth(on-chain light client) layer may not need mmr too, especially for chains like BSC etc. Thus, pull request feat: add heco and bsc mmr generation shadow#152 might not needed further, and hopefully, current mmr related codes/services in shadow and verification game can also be removed. cc @AurevoirXavier @xiaoch05 .

The changes mentioned in this issue required to be done in #714 (Darwinia <> Ethereum Bridge Upgrade CheckList), there are multiple instances in Ethereum chain family, the order may be as following:

1. Testnet Ropsten (and new truth layer for Ropsten)
2. (BSC truth layer)[https://github.com/darwinia-network/darwinia-common/tree/master/frame/bridge/bsc] and BSC bridge
3. Replace current Ethereum bridge.
4. Other instances.

[hujw77]

Consider replacing the MMR in BEEFY Commitment with Message Commitment in the s2b light client. The benefit is to reduce one MMR validation in the Message layer validation, but there may be other uses of MMR to consider.

[hackfisher]

Update: message layer for bridges between Ethereum Family chains(including Darwinia/Crab) will be implemented in smart contract.

[hackfisher]

The new proof model will use darwinia-network/darwinia-common#764

[hackfisher]

Will be fixed in #714 , duplicate