Ah, I see, that might actually work, although whether the extra complexity of doing it this way is worth it would need to be considered. A possible approach could be:
- Epoch blocks are distributed and if valid, automatically be made frontier blocks on the account (no receiving can be required for these because then issues with delaying upgrades become very problematic)
- Once the account owner attempts to generate another transaction, it uses the same previous hash the epoch block used
- When published, this block will only be validated if it is with the new format the epoch block defined
- Once confirmed it would replace the existing epoch block (all votes would have to favor non-epoch blocks in at least certain scenarios to avoid potential fork issues)
I don't believe we have the necessary details in the block itself to indicate which block version it is, but that was being explored alongside changes required for a new PoW format. If that is added, we would know which block version it is, but it could be tricky to determine which block in a chain was the first one of a particular version, which may or may not be required.
Given that a previously confirmed epoch block would be getting replaced in this scenario there may be some unique considerations with regards to bootstrapping, fork generation and resolution, etc. Additional disk checks may be required as well to determine whether a fork form a root was between a confirmed epoch or not - but this may already be done with any fork of an existing block, it would just mean there are more of these checks because it would be needed for each active account used post-epoch.
These are just some initial thoughts but this could be worth exploring further. Any other thoughts about the possibility of this to help avoid ledger bloat?