Fix: chain: create a new VM for each epoch #7966
Conversation
Codecov Report
@@ Coverage Diff @@
## master #7966 +/- ##
==========================================
- Coverage 39.33% 39.17% -0.16%
==========================================
Files 658 658
Lines 71142 71135 -7
==========================================
- Hits 27985 27869 -116
- Misses 38341 38443 +102
- Partials 4816 4823 +7
Continue to review full report at Codecov.
|
| } | ||
|
|
||
| pstate, err = vmi.Flush(ctx) | ||
| pstate, err = vmCron.Flush(ctx) |
There was a problem hiding this comment.
I don't like the repeated use of the same pstate and err here -- would appreciate suggestions on how to clean this up / derisk this. Winding up with the wrong field in pstate would be very bad.
There was a problem hiding this comment.
We can always use a temporary then set pstate = newState. But this doesn't seem too bad.
| } | ||
|
|
||
| pstate, err = vmi.Flush(ctx) | ||
| pstate, err = vmCron.Flush(ctx) |
There was a problem hiding this comment.
We can always use a temporary then set pstate = newState. But this doesn't seem too bad.
Related Issues
Fixes bug introduced in #7818. The VM's network version was always being determined based on
epoch, the input to theApplyBlocksmethod, even though the vm executes (potentially) multiple epochs worth of messages. The result is that if there was a null epoch before the upgrade epoch, the VM used the wrong network version (the new version) for running cron before the migration.Proposed Changes
Although this was a fairly specific case, I think this issue shows the risks of trying to hamfistedly reuse the VM for multiple epochs of execution (see #7890 for a similar issue). This PR changes behaviour to make VMs one-per-epoch. We remove the old
SetBlockHeightmethod entirely, and always create a new VM when moving between epochs. The result is that fields that need updating between epochs (like network version) are guaranteed to update this way.Additional Info
Checklist
Before you mark the PR ready for review, please make sure that:
<PR type>: <area>: <change being made>fix: mempool: Introduce a cache for valid signaturesPR type: fix, feat, INTERFACE BREAKING CHANGE, CONSENSUS BREAKING, build, chore, ci, docs, misc,perf, refactor, revert, style, testarea: api, chain, state, vm, data transfer, market, mempool, message, block production, multisig, networking, paychan, proving, sealing, wallet