Skip to main content

cosmos/evm fork

Dchain replaces upstream github.com/cosmos/evm with the d-foundation fork via the go.mod replace directive:

github.com/cosmos/evm => github.com/d-foundation/evm v0.5.0-dchain-v1

Source: github.com/d-foundation/evm. The branch is pinned to the tag v0.5.0-dchain-v1.

Customisations​

ERC-20 precompile: remove value-case for bankkeeper.BaseKeeper​

Commit: a4e763d BankKeeper is used with pointer on dchain

File touched: precompiles/erc20/msgsrv.go

Surface change​

The upstream type switch in MsgServer.Send covers both a value bankkeeper.BaseKeeper arm and a pointer *bankkeeper.BaseKeeper arm, because upstream bankkeeper.NewMsgServerImpl takes the Keeper interface, which both forms satisfy:

// upstream cosmos/evm v0.5.0
switch keeper := m.BankKeeper.(type) {
case bankkeeper.BaseKeeper:        // value arm
    msgSrv := bankkeeper.NewMsgServerImpl(keeper)
    ...
case *bankkeeper.BaseKeeper:       // pointer arm
    msgSrv := bankkeeper.NewMsgServerImpl(keeper)
    ...
}

The dchain patch deletes the value arm and leaves a comment in its place:

// dchain patch: removed `case bankkeeper.BaseKeeper:` (value).
// The d-foundation/cosmos-sdk fork narrowed
// `bankkeeper.NewMsgServerImpl` to `*BaseKeeper` (pointer) only,
// making the value case fail to compile. dchain stores BankKeeper
// as `*BaseKeeper` exclusively, so the value case is unreachable.
case *bankkeeper.BaseKeeper:
    msgSrv := bankkeeper.NewMsgServerImpl(keeper)
    ...

Rationale​

This is a forced downstream consequence of the cosmos-sdk fork's bank keeper narrowing. The d-foundation cosmos-sdk fork changes bankkeeper.NewMsgServerImpl from func(keeper Keeper) types.MsgServer to func(keeper *BaseKeeper) types.MsgServer.

Go type-checks every arm of a type switch, not only the arm selected at runtime. Against the narrowed signature the value arm fails to compile with:

cannot use keeper (variable of type bankkeeper.BaseKeeper) as
*bankkeeper.BaseKeeper value in argument to bankkeeper.NewMsgServerImpl

The dchain application instantiates the bank keeper as *BaseKeeper exclusively (driven by the same cosmos-sdk fork's depinject change), so the value arm is also unreachable at runtime. Deleting it both restores compilation and removes dead code.

The pointer arm remains untouched and is the one that runs in production.

Version pin: implicit retention of x/precisebank​

Upstream cosmos/evm removed the x/precisebank module in #1019 chore!: Remove x/precisebank, which landed after v0.5.0. By pinning to v0.5.0-dchain-v1 the fork implicitly retains x/precisebank. This is a consequence of the version pin rather than an active patch — the dchain branch contains no commits that touch x/precisebank.

The two trailing arms of the ERC-20 precompile type switch (case precisebankkeeper.Keeper and case *precisebankkeeper.Keeper) therefore remain in the fork. They appear as additions when diffing against cosmos/evm main only because main is past #1019; they are part of the v0.5.0 base.

A future rebase past #1019 will require an explicit decision: drop x/precisebank from the dchain stack (and the two trailing type-switch arms with it), or carry the module forward as an additional dchain customisation. That decision is out of scope for this page.

Rebase strategy​

This customisation is one commit on top of a vanilla v0.5.0 base. When rebasing onto a new upstream cosmos/evm release:

  1. Pull the new upstream tag.
  2. Cherry-pick a4e763d and resolve conflicts in precompiles/erc20/msgsrv.go. The patch is a single arm deletion; if upstream has reshaped the type switch (for example, replaced it with an interface-driven dispatch), the patch needs re-deriving rather than re-applying.
  3. Re-verify the resulting file compiles against the current d-foundation/cosmos-sdk fork.
  4. Re-tag as vX.Y.Z-dchain-vN and bump the replace directive in protocol/go.mod.
  5. If the rebase target is past upstream #1019 (x/precisebank removal), resolve the precisebank question described above before merging.