Synced node POV: Know when there is a new revision and hard fork.
Syncing node POV (i.e., a node which is still not on the tip): Follow the right revisions along the way so you can reject obsolete blocks.
Example: The chain hard forked at heights 100, 200, and 300, with revisions 0, 1, and 2 respectively. Upon the first fork, the sequencer found out about the fork only when it was at height 120, so it had to rollback to height 100 and start with the new revision 1. The problem is that there are blocks from 101-120 with revision 0 which may still be "floating" in the P2P network.
A syncing full node now starts, and it doesn’t need to "fork" per se, just follow the height. But at height 100, it needs to know that it should only accept blocks from revision 1 (otherwise it may get obsolete blocks for revision 0 which are floating in the network).
So the gist is, as I see it, that we always need to know the revision per height, and by that decide:
Do we accept or reject a block (as a full node which is not at the tip)?
Do we fork (as a full-node/sequencer which is indeed at the tip)?
The general idea:
This field's purpose is twofold:
Example: The chain hard forked at heights 100, 200, and 300, with revisions 0, 1, and 2 respectively. Upon the first fork, the sequencer found out about the fork only when it was at height 120, so it had to rollback to height 100 and start with the new revision 1. The problem is that there are blocks from 101-120 with revision 0 which may still be "floating" in the P2P network.
A syncing full node now starts, and it doesn’t need to "fork" per se, just follow the height. But at height 100, it needs to know that it should only accept blocks from revision 1 (otherwise it may get obsolete blocks for revision 0 which are floating in the network).
So the gist is, as I see it, that we always need to know the revision per height, and by that decide: