Use s2s struct and framework to eliminate the requirement of MMR in message layer, and support receive_messages_delivery_proof(and app transactional support)

[hackfisher]

This is a similar design from substrate to substrate, refer

https://github.com/darwinia-network/parity-bridges-common/blob/main/modules/messages/src/outbound_lane.rs#L94

and these message storage will be pruned when confirm_delivery:

https://github.com/darwinia-network/parity-bridges-common/blob/main/modules/messages/src/outbound_lane.rs#L145

But... verifying this storage require two layer of merkle tree, storage root and account root, this is the downside we need to consideration and not to do this for now?

This might not be a downside, since current verification also requires two layer: mmr root -> header hash, header receipt root -> event.

[hackfisher]

https://github.com/darwinia-network/darwinia-bridge-sol/blob/master/contracts/bridge/contracts/binance/BasicOutboundChannel.sol

[hackfisher]

If we are going to use new approach, we will need to switch current mmr + reciept proof to state proof:

async storageAgainstBlockHash(accountAddress, position, blockHash){}

https://github.com/zmitton/eth-proof

[hackfisher]

Do not require MMR will a huge advantage for design, it will improve safety by elimination the optimistic mmr verification logic, and the complexity of introducing shadow's mmr service.

[hackfisher]

Change from receipt proof to state proof look good.

Extra gas cost:

1. Storage read and write cost, to optimize this, we may only store hash of message_data instead of store entire data.
2. Cost of receive_messages_delivery_proof, but this new design can support batch confirm delivery. The should be OK for low gas price chains such as BSC, Heco, Polygon etc. But for Ethereum 1.0, we may need further optimization.(Without this, then Ethereum will not be able to have application layer transactional support, but anyway, this is already a enhancement compared to current design)

[xiaoch05]

Change from receipt proof to state proof look good.

Extra gas cost:

1. Storage read and write cost, to optimize this, we may only store hash of message_data instead of store entire data.
2. Cost of receive_messages_delivery_proof, but this new design can support batch confirm delivery. The should be OK for low gas price chains such as BSC, Heco, Polygon etc. But for Ethereum 1.0, we may need further optimization.(Without this, then Ethereum will not be able to have application layer transactional support, but anyway, this is already a enhancement compared to current design)

The item 1 do you mean the message_data is the application data, and the bridge only needs to store its hash? but how can the bridge transfer the application data to the target chain?

[hujw77]

Change from receipt proof to state proof look good. Extra gas cost:

1. Storage read and write cost, to optimize this, we may only store hash of message_data instead of store entire data.
2. Cost of receive_messages_delivery_proof, but this new design can support batch confirm delivery. The should be OK for low gas price chains such as BSC, Heco, Polygon etc. But for Ethereum 1.0, we may need further optimization.(Without this, then Ethereum will not be able to have application layer transactional support, but anyway, this is already a enhancement compared to current design)

The item 1 do you mean the message_data is the application data, and the bridge only needs to store its hash? but how can the bridge transfer the application data to the target chain?

message_data_hash_state_proof + message_data

[hackfisher]

do you mean the message_data is the application data, and the bridge only needs to store its hash?

Mainly opaque message payload, only store its hash is to save gas cost. On target chain, when verifying the message, aka.receive_messages_proof, the message data will be passed together in MessagesProofOf, e.g. in substrate it is an associate type defined in runtime.

verify_and_decode_messages_proof will require extra check that the hash of the message data matches the leave in the merkle proof.

Message data can be indexed from transactions using theGraph, so that relayers can easily query it and combine together with state proof.