Eagerly transition to SAE for state sync - #5916
Conversation
3093968 to
42fc8f1
Compare
There was a problem hiding this comment.
🔵 Needs a closer look
It changes startup-time VM transition behavior in a consensus-critical/state-sync path where incorrect behavior could strand nodes or affect network operability.
Pull request overview
This PR updates transitionvm to eagerly transition a fresh node to the post-transition VM (SAE) during Initialize when the wall clock is past the configured transition time and the node intends to state sync, avoiding failures caused by peers only serving post-transition state summaries after the network has transitioned.
Changes:
- Add an eager-transition path in
VM.Initializeto transition immediately (before any transition block is seen) for genesis-height nodes that will state sync and start aftertransitionTime. - Extend unit tests to cover eager-transition conditions, durability across restart, and error propagation from
StateSyncEnabled. - Document the eager-transition behavior and accepted failure modes in
vms/transitionvm/README.md.
File summaries
| File | Description |
|---|---|
vms/transitionvm/vm.go |
Adds eager-transition logic in Initialize based on wall-clock time, chain height, and StateSyncEnabled. |
vms/transitionvm/vm_test.go |
Adds/updates test scaffolding and new tests validating eager transition behavior and persistence. |
vms/transitionvm/README.md |
Documents eager transition for state sync and explicitly lists the one-way commitment and failure modes. |
Review details
- Files reviewed: 3/3 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
42fc8f1 to
908c9fd
Compare
908c9fd to
ed3f5f9
Compare
685cd63 to
95095ba
Compare
95095ba to
bf5a58d
Compare
bf5a58d to
afc6fcf
Compare
e6f1bef to
c143424
Compare
10d6151 to
c2e1237
Compare
c143424 to
f8cc34d
Compare
alarso16
left a comment
There was a problem hiding this comment.
In theory, I think it would be helpful to provide a warning for people currently state syncing that the network transitioned and they should restart, but it sounds logistically complicated.
| class E errCls; | ||
| ``` | ||
|
|
||
| ### Eager transition for state sync |
There was a problem hiding this comment.
I think there's a lot of this block is redundant with itself and/or the code, so I would maybe say:
- The requirements of the pre-VM and post-VM
- What errors could occur/expected weird behavior
- How to recover if there's a weird error
There was a problem hiding this comment.
simplified this quite a bit - let me know how it looks now
c2e1237 to
2006537
Compare
09939af to
cbb1e84
Compare
7eaa5d2 to
63cef6a
Compare
63cef6a to
c15da4b
Compare
4cde966 to
4d6509e
Compare
…tion time Lets a fresh node joining after the coreth-to-saevm transition state sync via saevm: - transitionvm: Initialize transitions eagerly when the wall clock is past the transition time, the local chain is still at the genesis, and the pre-transition chain reports StateSyncEnabled. A node that already accepted pre-transition blocks never transitions eagerly — the post-transition chain refuses to state sync over accepted blocks — and instead bootstrap-executes to the transition block. The transition marker is a one-way commitment; hazards, including configurations the post-transition chain can never sync (Firewood), documented in the README. - saevm/statesync: document the invariant the eager transition relies on: with state sync enabled, a node whose last accepted block is the genesis never skips a state sync to a non-genesis summary. (adapted from commit 5964266, reduced to the fresh-node case and the transitionvm package, and folding in fixes from adversarial review)
4d6509e to
ed46a48
Compare
Co-authored-by: Austin Larson <78000745+alarso16@users.noreply.github.com> Signed-off-by: Rahul Muttineni <rahul.muttineni@avalabs.org>
StephenButtolph
left a comment
There was a problem hiding this comment.
There are a number of subtle footguns here, but they are all only limited to a single node starting from scratch, so I think that this is OK to unblock state-sync.
Why this should be merged
Resolves #5875. when state syncing a fresh node, it'll start at the coreth vm and if state sync is enabled & transition has happened in the rest of the network, it must transition because the rest of network only supports the SAE state sync protocol.
How this works
Updates the transitionvm to perform the necessary checks described above.
How this was tested
Unit tests + tested on a live fuji network.
Need to be documented in RELEASES.md?
No