chore: add evm-v0.6.2 upgrade handler (donut) - #354
Merged
Conversation
No state migration: v0.6.0..v0.6.2 changed no proto, added or removed no store key, and bumped no module ConsensusVersion. StoreUpgrades is empty and RunMigrations should be a no-op; the plan exists so cosmovisor has a name to switch the binary on.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds the named upgrade plan for the cosmos/evm v0.6.0 → v0.6.2 binary that landed on
testnet/donutin #353.Why it is a no-op handler
Across v0.6.0..v0.6.2 upstream changed no
.protofile, added or removed no store key, and bumpedno module's
ConsensusVersion. SoStoreUpgradesis empty andRunMigrationsis expected to donothing. The plan exists purely so cosmovisor has a name to switch the binary on at a height — same shape
as the existing
evm-v0.6.0handler, minus its transfer v5→v6 migration (which was specific to thatrelease).
RunMigrationsis still called rather than skipped, so the stored version map stays consistent and anymigration bundled by a dependency runs instead of being silently dropped.
Behavioural changes carried by this binary
Documented in the handler's doc comment so it is discoverable from the code, not just the PR:
SubBalancenow panics on balance underflow instead of wrapping silently — upstream's equivalent ofour F-2026-18201 statedb fix (
x/vm/statedb/state_object.go; the diff is byte-identical to our evm Enable connecting with local node to read chains config #40).A panic fails the tx, it does not halt the chain. Anything currently underflowing silently would begin
failing visibly.
3524ebc6).Push is unaffected — verified:
value=0, so the module's EVM balance is never writtenDeductAndBurnFeesusesSendCoinsFromAccountToModule(SDK bank keeper), which never enters the EVMstatedb path
x/uvalidator/abci.go) isSendCoinsFromModuleToModule+AllocateTokensToValidatoronbankkeeper.BaseKeeper/ distribution keeper — also outside the EVM.This one matters because it runs in
BeginBlockerevery block.CallExecuteUniversalTx+DeductGasFeesFromReceiptcombination is exercised byTestInboundCEAGasAndPayload/TestInboundCEAFundsAndPayloadwith 0 occurrences ofnot allowed to receive fundsvm.ErrOutOfGas— different error on calls already running outof gas. No repricing; succeeding transactions consume identical gas.
ExtendedDenom == Denom == upc, and thenew code is guarded on the denoms differing) and the erc20 IBC v2 ack changes (no IBC v2 stack is wired).
Verified locally
go build ./app/...cleango test ./app/...greenevm-v0.6.2among themUpgradeNameacross all handlersNext
Localnet upgrade simulation across the height before the governance plan.