[Consensus] Garbage Collection - 2

[akichidis]

Description

This is the second part of Garbage Collection which implements the following ticked next steps as outlined on the previous PR

• BlockManager to respect the gc_round when accepting blocks and trigger clean ups for new gc rounds
• Skip blocks that are received which are <= gc_round
• Not propose ancestors that are <= gc_round
• Subscriber to ask for blocks from gc_round when last_fetched_round < gc_round for a peer to prevent us from fetching unnecessary blocks

Next steps:

• Re-propose GC'ed transactions (probably not all of them)
• Implement new timestamp approach so ancestor verification is not needed
• Harden testing for GC & edge cases

Test plan

CI/PT

---

Release notes

Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.

For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.

• Protocol:
• Nodes (Validators and Full nodes):
• Indexer:
• JSON-RPC:
• GraphQL:
• CLI:
• Rust SDK:
• REST API:

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
sui-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 20, 2024 10:38am

3 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
multisig-toolkit	⬜️ Ignored (Inspect)	Visit Preview		Sep 20, 2024 10:38am
sui-kiosk	⬜️ Ignored (Inspect)	Visit Preview		Sep 20, 2024 10:38am
sui-typescript-docs	⬜️ Ignored (Inspect)	Visit Preview		Sep 20, 2024 10:38am

[akichidis]

Practically most of the previous code has been extracted to the verify_block_timestamps_and_accept method. This won't be needed once we refactor to the new timestamp approach

[akichidis]

I've made the decision to let received blocks with block.round <= gc_round to be allowed received up to here and not straight rejected on the AuthorityService mostly for two reasons:

1. round_prober: this is using the highest_received_rounds keeps getting updated on the received blocks. Dropping blocks early enough due to gc (ex let's assume that we indeed have a slow proposer A, or there was some temporary network issue) , will not update those structs and might effectively make the proposer A halt on propose and not be able to recover from that as received blocks will keep getting rejected.
2. metrics in block manager that are updated per received block. That's useful insight to have and we might don't want to lose at this point.

Another point to keep in mind, it's the amnesia recovery. Since now we'll not store blocks < gc_round we might have a case of a node whose blocks get rejected , and then tries to recover from a db wipe out. Since none of the earlier blocks would have been stored the node will try to propose from much earlier. That's quite nit and I wouldn't worry now. Just adding this here to keep in mind to show all the affected paths from this decision.