Index top-down cross-net messages by height

[adlrocha]

When a new top-down cross-net message is committed in the parent is currently indexed by nonce in an array. We don't keep any information about the height in the parent where the message was committed.

As we are moving into a new design for top-down cross-net execution based on proofs of finality, it simplifies a lot the logic to track at what height messages were committed in the parent. Thus, we will index them by height through a mapping(height -> []CrossMsg) so we can easily query the messages committed at each height

[aakoshh]

As a side note, to avoid bloating the state tree with the message payloads, in IBC only the hash of the message is added to the outbox, while the message itself is emitted as an event, which is stored by Tendermint Core in the transaction event log. The relayers reconstruct the message from the event log and attach it to the relayed transaction, and the IBC contract compares it to the hash, for which it has a Merkle proof of inclusion in the committed state.

Once again this way the payload itself would not be part of the above mapping itself, reducing the cost of the transaction by not storing this for eternity.

[aakoshh]

A similar approach would be possible in our case as well. If the contract emits the CrossMsg as an event, then

• the IPC Agent can pick it up from the Ethereum formatted logs in Lotus, collect them and submit them along with the hashes in the array,
• Fendermint itself can pick it up in deliver_tx and put them into a separate IPLD BlockStore from which the IPLD Resolver is allowed to serve them

In both cases they don't have to weigh down on the Ethereum contract storage.

[cryptoAtwill]

Evm should have provided api to query the events by topic id, there should have no need to use lotus apis.

Just that using this approach, the messages will not be available in contract or available for other contracts. Do we need the messages to be available for other contracts? We might also need a way to validate these are the messages that are committed in a block height in parent or it's completely relying on fendermint parent finality?

Also, unit testing would be quite difficult I guess if the top down messages are not off chain considering we are using forge sol tests.

[adlrocha]

closing this one as it has been addressed differently in https://github.com/consensus-shipyard/ipc-solidity-actors/pull/285 (@cryptoAtwill, feel free to reopen if this is not the case)