FM-281: Retrieve cross messages and put their hash into the checkpoint

[aakoshh]

Closes consensus-shipyard/ipc#284

The PR populates BottomUpCheckpointNew::cross_messages_hash with the hash of the ABI encoded Vec<CrossMsg> retrieved by calling the new bottomUpMessages on GatewayGetterFacet with the height of the current checkpoint, which was added in consensus-shipyard/ipc-solidity-actors#214

This is based on my assumption how the contract works:

• getNextEpoch calculates the next checkpoint height based on the current one as ((height / period) + 1) * period which gives some multiple of period, which should match the way we check for the end-of-period height: height % period == 0, so we'll use the same height values.
• commitBottomUpMsg pushes the message into the next checkpointed height

[dnkolegov]

Closes consensus-shipyard/ipc#284

The PR populates BottomUpCheckpointNew::cross_messages_hash with the hash of the ABI encoded Vec<CrossMsg> retrieved by calling bottomUpCheckpoints on GatewayGetterFacet with the height of the current checkpoint.

This is based on my assumption how the contract works:

• getCurrentBottomUpCheckpoint inserts a checkpoint at the given block height if it doesn't exist
• commitBottomUpMsg pushes the message into the checkpoint
• getNextEpoch calculates the next checkpoint height based on the current one as ((height / period) + 1) * period which gives some multiple of period, which should match the way we check for the end-of-period height: height % period == 0, so we'll use the same height values.

Why is createBottomUpCheckpoint not used to create a checkpoint?

[dnkolegov]

• is there some method in the contract to call to get the cross messages?
• plus the getCurrentBottomUpCheckpoint is internal. How does one go about retrieving them to Rust?

@aakoshh It would be very helpful if you could describe the flow of creating, populating, and signing a checkpoint from "Fendermint as a client" perspective.

I am afraid the current implementation (from Limechain) is incompatible with what you want to do, and we must reimplement Gateway API.

Another question is, is there any relation between populating BottomUpCheckpoint with cross messages and collecting signatures for this checkpoint from validators?

[aakoshh]

Why is createBottomUpCheckpoint not used to create a checkpoint?

@dnkolegov it is used, here, with the Solidity method called by the GatewayCaller.

What I was trying to describe there were my understanding of why, when a contract calls commitBottomUpMsg, a legacy checkpoint will be automatically created with empty fields, and the cross-message appended to it. It looks like it will be retrievable with the height that I will actually create the new checkpoint with, at which point I can retrieve the accumulated cross messages from it.

[aakoshh]

It would be very helpful if you could describe the flow of creating, populating, and signing a checkpoint from "Fendermint as a client" perspective.

Okay, I will open another PR with a sequence diagram.

The conceptual overview in the IPLD Resolver repo is still valid.

[aakoshh]

I am afraid the current implementation (from Limechain) is incompatible with what you want to do, and we must reimplement Gateway API.

Can you explain why it's incompatible? I may be misunderstanding what the code is doing, but like I said commitBottomUpMsg does not inspect the exists return value, so it looks like this is normal behaviour and it will stash the messages as intended. I have no argument against reimplementing it, but it looks like it should technically work this way as well.

[aakoshh]

Another question is, is there any relation between populating BottomUpCheckpoint with cross messages and collecting signatures for this checkpoint from validators?

As you can see in #276, the signatures are over the hash of the checkpoint, which incorporates the hash of the cross messages, so the signatures are implicitly over the cross messages as well.