Closed aakoshh closed 1 year ago
I think the checkpoint should look as follows:
struct BottomUpCheckpoint {
// Child subnet ID, for replay protection from other subnets where the exact same validators operate.
// Alternatively it can be appended to the hash before signing, similar to how we use the chain ID.
subnet_id: SubnetID,
// The height of the child subnet at which this checkpoint was cut.
// Has to follow the previous checkpoint by bottom_up_checkpoint_period
block_height: u64,
// The ID of the validator set which is going to sign the next checkpoint.
// This one expected to be signed by the ID reported in the previous checkpoint.
// 0 could mean "no change".
next_configuration_number: u64,
// Some kind of hash over the bottom-up messages.
// By not including cross messages here directly, we can be compatible with IPLD Resolver based
// approach where the messages are fetched with Bitswap and provided by Fendermint, or the full-fat
// approach we need with Lotus, where the messages are part of the relayed transaction.
cross_messages_hash: bytes32
}
The method signature to add such a checkpoint should look like this:
createCheckpoint(
checkpoint: Checkpoint,
// Root hash of the Merkle tree built from the validator public keys and their weight.
validator_set_root_hash: bytes32,
totalWeight: uint256
) external systemActorOnly
As a Fendermint interpreter, at the end of the checkpoint period, I will construct a
BottomUpCheckpoint
deterministically from the ledger, and I want to store this checkpoint in the Checkpoint actor created in consensus-shipyard/ipc-monorepo#207 , so that everyone can see what it is, and we have a place to accumulate signatures. To be able to check signatures the actor will also need to remember the validator set at the time the checkpoint was added.