Feature: Checkpoint refactor and cross-net message execution

[cryptoAtwill]

Update 04/2023: This PR has become the feature branch for all the checkpoints refactor. At a high-level this PR includes:

• A simplification of bottom-up messages removing the need for CrossMsgMeta and including in checkpoints the raw messages to allow the immediate execution of bottom-up messages without the need for off-chain message resolution that, while more performant, it could introduce some unexpected attacks. The design will be improved in the future.
• The use of cron_checkpoints as a top-down checkpoint used by subnet validators to report their perceived finality from the parent allowing the sync execution of top-down messages.
• Generalization and improvement of the voting system for checkpoints so cron and bottom-up checkpoints use the same voting scheme where checkpoints are committed and executed in order, and their commitment trigger directly the execution of the included cross-net messages.

Changes

Submit a new cron checkpoint.

It only accepts submission at multiples of cron_period since genesis_epoch, which are set during construction. Each checkpoint will have its number of submissions tracked. The same address cannot submit twice. Once the number of submissions is more than or equal to 2/3 of the total number of validators, the messages will be applied.

Each cron checkpoint will check its uniqueness against each other using blake hashing. To do that, we need to make sure the validators and top_down_msgs in CronCheckpoint are the same. However, the top_down_msgs and validators are vec, they may contain the same content, but their orders are different. In this case, we need to ensure the same order is maintained in the cron checkpoint submission. To ensure we have the same consistent output for different submissions, we require:

• validators are sorted by net_addr in string ascending order, assuming net_addr are unique for the validators
• top down messages are sorted by (from, to, nonce) in ascending order.

Actor will not perform sorting to save gas. Client should do it, actor just check.

A side note @adlrocha, what execution order do we have to enforce when the messages are applied? Currently it's enforced as the above top down message sorting order.

Update 20/03/2023:

• Add abort epoch functionality.

Tests

Not implemented yet, implementing

Issues to be ported to Lotus and go-ipc-types

• Updates in gateway state
• Updates in the construction of the gateway
• Implicit execution of updates of on-chain validation set: Update on-chain membership after reconfiguration in subnets lotus#125
• Update the IPC actor bundle

• add cron fields #64

[adlrocha]

Amazing job, Will. We are close. I think we can simplify the logic a bit (we can go without a lot of the linked HAMTs, I think they add unnecessary complexity). Let me know if my comments are clear enough, if not we can have a quick sync.

Next up:

• A PR including tests targeting this branch.
• A PR with the implementation of Tracking subnet membership from gateway or new membership actor #68

Thanks.

[adlrocha]

In the end you can remove validators from here, we will get the validator set from the new data structure introduced here: #68. Thanks!

[adlrocha]

This assignment is redundant, right?

[cryptoAtwill]

it returns the messages to be executed, should not be redundant?

[adlrocha]

Finally merging this one 🥳 Future changes and bug fixes will be done in follow-up PRs.