feat: add canPruneAtTime

[LHerskind]

A minor change to help on #9308. Instead of the archiver using the current time, it will use the time of the next ethereum block.

Also addresses an issue, where it would be possible to submit a proof for blocks that should have been pruned, but have not yet been because of no new publications.

[LHerskind]

• feat: add canPruneAtTime #9751 👈
• chore: update boundary in test #9728
• chore: Boring names #9725
• feat: lock to propose #9430
• fix: update solhint #9399
• feat: ownable sysstia #9398
• test: node follow prune and extend chain #9328
• feat: initial block reward + external libraries #9297
• feat: fee pricing to 0 for old instances #9296
• feat: sequencer cast votes #9247
• test: scenario for upgrading gerousia #9246
• feat: apella #9084
• feat: gerousia #8942
• feat: sysstia #8941
• feat: nomismatokopio #8940
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @LHerskind and the rest of your teammates on Graphite

[just-mitch]

I thought about making this change here when I added it to the quote validation stuff, but had a concern:

Suppose you're in the beginning of slot 12 of an epoch, and no proof quote has been claimed. Doesn't this change make it so that if a proof does land after I look, I've already unwound?

But considering further, even if that does happen, it should just rebuild the chain, so maybe it is fine?

Regardless, it almost seems like the current behavior is the correct one?

[LHerskind]

I thought about making this change here when I added it to the quote validation stuff, but had a concern:

Suppose you're in the beginning of slot 12 of an epoch, and no proof quote has been claimed. Doesn't this change make it so that if a proof does land after I look, I've already unwound?

But considering further, even if that does happen, it should just rebuild the chain, so maybe it is fine?

Regardless, it almost seems like the current behavior is the correct one?

I don't get what you say? If it lands after you looked, it landed after it should be pruned. There should be no time for a proof to land in between you looking and it pruning?

If we can do that, it is an inconsistency in the flow, e.g., a bug. Looking at submitEpochRootProof looks like it do not check at all if it should be pruned, which just seems plain wrong to me. If it is to "automatically" prune, it should always do it, any action that moves the chain any way should perform the check.

This nicely shows why #7868 is needed. Doing the change breaks 0 tests, so something is missing. Some of the tests also state they check pruning but don't actually do any pruning.

[github-actions]

Changes to public function bytecode sizes

Generated at commit: 3a8f209c5ce87e89f149a8510a3b671e1ca11493, compared to commit: d671af6cbaca7f644187cc3b110a93bbc3b24b14

🧾 Summary (100% most significant diffs)

Program	Bytecode size in bytes (+/-)	%
AvmTest::public_dispatch	+851 ❌	+1.43%

---

Full diff report 👇

Program	Bytecode size in bytes (+/-)	%
AvmTest::public_dispatch	60,539 (+851)	+1.43%