Repository navigation
docs(migration): memIAVL reserve node guides for v6.7.0 on testnet and mainnet - #4460
Conversation
…miavl-reserve Point the build at v6.7.0-memiavl-reserve (2bff7d5), the reserve patch rebased onto the final v6.7.0 tag, and record what changed since rc3: - the expected `seid version --long` output, including the space-separated build_tags that GNU Make 4.x produces - atlantic-2 may still report v6.7.0-rc4, which executes blocks the same way as v6.7.0 - the pinned-mode kick-off error is logged once per batch size (#4411), not on every block - `evm-logical-digest --memiavl-open-mode changelog` (#4419) replaces replay for the composite digest on a normal node - the halt message is quoted as `UPGRADE "<name>" NEEDED at height: <height>` Co-authored-by: alexander-sei <alexander-sei@users.noreply.github.com>
Mirror the testnet guide for pacific-1 on v6.7.0-memiavl-reserve and cross-link the two. Mainnet differs in how a reserve comes into being: pacific-1 is still on v6.6, which has no governance-driven migration and no reserve build, so the guide covers - preparing a node on the normal v6.6 binary and switching it to the reserve build at the v6.7 upgrade height - the `migration: unknown subspace` answer before the upgrade - state-syncing a new reserve only from a snapshot taken after the upgrade, since the reserve build swallows BINARY UPDATED BEFORE TRIGGER - not starting the reserve build before the upgrade height, when no plan exists and nothing at all is logged Co-authored-by: alexander-sei <alexander-sei@users.noreply.github.com>
The previous commit dropped the title change and the cross-link to memiavl_reserve_node_mainnet.md from the testnet guide while adding the mainnet guide. Co-authored-by: alexander-sei <alexander-sei@users.noreply.github.com>
![seidroid[bot]](https://avatars.githubusercontent.com/in/2745135?s=60&v=4){kind=small}
There was a problem hiding this comment.
This retargets the testnet memIAVL reserve guide to v6.7.0-memiavl-reserve and adds a pacific-1 guide where the node runs v6.6 until the v6.7 upgrade height and the reserve build after it. One finding blocks: the mainnet guide's build step replaces the running v6.6 node's seid before the upgrade. Codex raised both points below, and I checked and kept both; nothing from the reading was dropped.
Blocking
1 finding on the changed lines, as inline comments.
Non-blocking
1 finding on the changed lines, as inline comments.
Pre-existing
Already true on the base branch, not introduced here.
- suggestion —
docs/migration/memiavl_reserve_node.md, "Comparing EVM state" section: the testnet guide already buildsbuild/seidband then calls bareseidb, which has the same PATH problem as the mainnet copy.
seidroid review · decision request_changes · session 8b500bb8f62e4a42857abb7cec2fde14 · turn resp_claude_b320683f0a5953b44347651b00240999 · item 1968faee345256f48ae1ce8ce0be5180
Findings: 1 blocking | 1 non-blocking | 2 posted inline | 1 pre-existing
| git clone https://github.com/sei-protocol/sei-chain.git | ||
| cd sei-chain | ||
| git checkout v6.7.0-memiavl-reserve | ||
| make install BUILD_TAGS=mock_chain_validation |
There was a problem hiding this comment.
blocker — On the v6.6 node that step 3 tells you to start from, make install in step 1 overwrites $GOPATH/bin/seid with the v6.7.0 reserve build before the upgrade. If that service restarts before the v6.7 height, the reserve build runs v6.6 blocks and logs nothing, since no plan exists yet. That is the failure this guide warns about at lines 248 and 295. Build into an isolated path (for example go build -tags ... -o build/seid-reserve ./cmd/seid, or make build) and replace the daemon's binary only at the upgrade halt or in Cosmovisor's upgrades/v6.7/bin/. (Raised by codex.)
| On the reserve: | ||
|
|
||
| ```bash | ||
| seidb evm-logical-digest --backend memiavl \ |
There was a problem hiding this comment.
suggestion — Line 259 builds the tool to build/seidb, but the digest commands call bare seidb. That is command not found on a fresh machine, and on a machine with an older seidb on PATH it silently runs that version. Use ./build/seidb here and at line 280, or add an install step. (Raised by codex.)
6b19339
into
alexanderh/memiavl-reserve-node-guide
|
The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).
|
There was a problem hiding this comment.
This PR moves the testnet memIAVL reserve guide to the v6.7.0-memiavl-reserve branch and adds a mainnet guide for pacific-1, where operators run the normal v6.6 binary until the v6.7 upgrade height and then switch to the reserve build. I'm requesting changes because the mainnet guide's build step installs the v6.7.0 reserve binary over the running v6.6 binary before the upgrade, which leads straight into the silent early-execution hazard the guide warns against elsewhere. Reconciliation: the tree came from the PR head (5b0e910) because no merge ref exists; I kept both codex findings, the first as a blocker and the second as a suggestion; no other scout contributed.
Blocking
1 finding on the changed lines, as inline comments.
Non-blocking
1 finding on the changed lines, as inline comments.
Pre-existing
Already true on the base branch, not introduced here.
- suggestion — The testnet guide
docs/migration/memiavl_reserve_node.mdhas the same mismatch: it buildsbuild/seidband then calls a bareseidbin its digest commands.
seidroid review · decision request_changes · session fe317a929fa74ad88e3b6fc0f8cbc702 · turn resp_claude_37a4232be8d9cbb456f70b97ef4e23b4 · item dd02955b69295bf3b0fa3a2589b5ec18
Findings: 1 blocking | 1 non-blocking | 2 posted inline | 1 pre-existing
| git clone https://github.com/sei-protocol/sei-chain.git | ||
| cd sei-chain | ||
| git checkout v6.7.0-memiavl-reserve | ||
| make install BUILD_TAGS=mock_chain_validation |
There was a problem hiding this comment.
blocker — (Raised by codex too.) Step 1 runs make install before step 3, which tells operators to keep running the normal v6.6 binary until the v6.7 height. On a v6.6 node this overwrites the seid in $GOPATH/bin that the service usually runs, so any restart before the upgrade launches the v6.7.0 reserve build early. The guide itself says that build logs nothing and quietly executes v6.6 blocks with v6.7 code. For the pre-upgrade path, build into a staging location (for example go build/make build into build/, or straight into Cosmovisor's upgrades/v6.7/bin/) and install only at the upgrade height.
| On the reserve: | ||
|
|
||
| ```bash | ||
| seidb evm-logical-digest --backend memiavl \ |
There was a problem hiding this comment.
suggestion — (Raised by codex too.) The tool is built to build/seidb at line 164, but the digest commands call a bare seidb. On a fresh host that command isn't found, or it picks up a different seidb from PATH. Call ./build/seidb (or the full path to it) here and at line 185, or add an install step.
2 participants
The memIAVL reserve node guide on this branch builds from
v6.7.0-rc3-memiavl-reserveand only covers testnet.v6.7.0is now tagged with its own reserve branch,v6.7.0-memiavl-reserve(2bff7d5a9, the same reserve patch rebased onto the final tag), and mainnet operators need a version of the guide forpacific-1.docs/migration/memiavl_reserve_node.mdnow builds fromv6.7.0-memiavl-reserveand picks up what changed in the release since rc3. The pinned-mode kick-off error is logged once per batch size (#4411) instead of on every block. The composite digest uses--memiavl-open-mode changelog(#4419), which reads the same rows as replay. The expectedbuild_tagsline now matches what GNU Make 4.x prints. The guide also notes thatatlantic-2may still reportv6.7.0-rc4, which executes blocks the same way asv6.7.0. The newdocs/migration/memiavl_reserve_node_mainnet.mdmirrors it forpacific-1, which is still onv6.6.3with no upgrade plan. A reserve prepared now runs the normalv6.6binary and switches to the reserve build at thev6.7upgrade height. The parameter query answersmigration: unknown subspaceuntil then, and a reserve state-synced after the upgrade must restore a snapshot from after it.Docs only. The part to scrutinise is the mainnet sequencing. The reserve build swallows
ErrUpgradeBeforeTrigger, so starting it onpacific-1before thev6.7height, or restoring an older snapshot, quietly executesv6.6blocks withv6.7code. Before a plan exists it logs nothing at all. The guide covers this in step 3, Upgrades, Don't, and Troubleshooting. I checked the guides by buildingseidandseidbfrom2bff7d5a9, runningseid initfor both chain IDs, and triggering each startup-guard message on a throwaway home. I also ran the parameter and upgrade-plan queries read-only against publicpacific-1andatlantic-2RPCs. Thedocker buildline was checked against the Dockerfile but not run.