[Protocol Versioning M3] protocol-defined Stop View for empty blocks on consensus nodes #8081

[based on conversation with @peterargue Oct, 23, 2025]

Goal: During a spork, we want to make sure that no transactions are lost, while we shutdown the network. As the network becomes more open, it becomes useful to automate shutdown on the software level vs leaving it to human coordination (current shortcut).

Details: At the moment, during a spork, we generally have to consider the possibility of finalized blocks that are truncated in the sporking process. Currently, we manage to shutdown transaction ingestion on the operator level and after some wait period just shutdown nodes. Formally, we would want to make sure no more transactions are in the entire verification sealing pipeline. Therefore, it is helpful to suspend transaction ingestions on the block-level. And then let the execution-verification-sealing pipeline run empty, yielding a latest finalized result.
Then, we still run the risk of truncating finalized blocks (creates many difficulties in other areas and should be avoided). But at least, we are statistically certain that after some time (e.g. 200 blocks, roughly two and a half minutes) no more transactions are in the pipeline.

Stage 1: The protocol state should contain a flag:

• optional
• view, above which all blocks cannot contain collections anymore.

Note: all other protocol functions persist

Remaining operations on the protocol state happen during the system chunk. Generally, we have system-level transactions (think "root process") and user-level transactions (probably mainly scheduled transactions).

Stage 2: The protocol state should contain a flag:

• optional
• view $v_1$, above which all blocks cannot contain collection guarantees anymore
• view $v_2$, above which all blocks are no longer voted for, thereby the main consensus will enter consistent timeout mode. It would be permissible for each leader to continue to propose, but their blocks not being voted for. Ideally, all what the nodes would remain doing would be broadcasting timeouts containing the QC of the their latest block certified by a supermajority of consensus nodes. This would uniquely and cleanly generate a parent block for the new spork's root block. There would be no risk of finalized blocks being truncated.
• Additionally we could control the execution of the system chunk through parameters in the protocol state. There is a large spectrum of possibilities. For example, we the protocol state could include a n optional view above which the system chunk is no longer executed, or certain parts of the system chunk are no longer be executed, or maybe scheduled transactions could be stopped ... large spectrum of possibilities. Nevertheless, we are making a bit more of a fundamental decision: the execution of certain part of the system is controlled externally through the protocol state vs internally through information from within the execution state.
  • Comment: the strong benefit we get through this versioning with the protocol state is that we can ship large parts of logic and reference it, essentially following the natural increments of our work.