FM-254: Create checkpoint #273
Conversation
aakoshh
force-pushed
the
fm-254-create-checkpoint
branch
from
07f6e4f to
d9f7c8e
Compare
| block_height: height.value(), | ||
| block_hash, | ||
| next_configuration_number, | ||
| cross_messages_hash: et::H256::zero().0, |
There was a problem hiding this comment.
For the "beefy"-checkpoint, are we going to also propagate a hash and let the relayer populate the messages inside the checkpoint for submission?
Should we also add a //TODO comment here and assign a ticket to remind ourselves?
There was a problem hiding this comment.
Thanks for pointing this out. I was hoping that you guys can tell me in the review where to get this from. Is there a method to call to retrieve all the messages?
There was a problem hiding this comment.
I created https://github.com/consensus-shipyard/fendermint/issues/281 to assign a value to this field.
@adlrocha yes, the relayer is expected to retrieve the cross-messages and send them with the checkpoint in https://github.com/consensus-shipyard/fendermint/issues/257
The parent gateway is expected to hash the messages and compare them to the inside the checkpoint.
| let power_updates = PowerUpdates(Vec::new()); | ||
|
|
||
| // TODO: #252: Take the configuration number of the last change. | ||
| let next_configuration_number = 0; |
There was a problem hiding this comment.
This is the config number for the next configuration to be adopted by the child subnet, right?
There was a problem hiding this comment.
That's right, this will be the configuration number from the latest update stored by the gateway. I started implementing in #272 but ended up being blocked on the lack of a parseable public key in the changeset. So currently no changes are applied, indicated by zero.
| .context("failed to get the power table")?; | ||
|
|
||
| // TODO #252: Take the next changes from the gateway. | ||
| let power_updates = PowerUpdates(Vec::new()); |
There was a problem hiding this comment.
We assume that the updates have already been submitted and queued in the child's gateway through the top-down proof of finality, right?
There was a problem hiding this comment.
Yes, this takes the updates placed in the gateway by the top-down syncer.
Closes consensus-shipyard/ipc#303
Depends on consensus-shipyard/ipc-solidity-actors#202
Changes:
I created a support data structure called
ValidatorMerkleTreeusing the library we found. Had to fork it to update it to the latest ethers. There are many things we could change in that library to avoid the multitude of panic conditions. It only works for the happy path, but for now that is all we need. It's also a bit annoying that it converts resulting bytes into strings that I have to parse back bytes, but we can deal with these later.ABI bindings built with:
export IPC_ACTORS_TAG=origin/fendermint247 make clean-ipc-actors-abi ipc-actors-abi