Skip to content

CosmJS and Ethermint #1351

@webmaster128

Description

@webmaster128

Over the last couple of months, many users submitted issues or change requests regarding Ethermint support. I am not sure if supporting Ethermint is in scope of this project but the diffs at least help showing the compatibility problems. Some of those change requests go deep into the signing logic and fiddle with that in very problematic ways.

As of today, CosmJS does not support Ethermint.

The main areas of incompatibilities are

  1. Pubkeys
  2. Addresses
  3. Transaction seralization
  4. Account type support
  5. Key storage

Pubkeys

Ethermint uses the uncompressed secp256k1 encoding from Ethereum, which is incompatible with Cosmos secp256k1 address derivation. #1160 shows how this can be implemented using a different pubkey type. To make this work we need:

Addresses

I'm not sure how Ethermint address derivation works. Are there two addresses for the same pubkey (hex and bech32)? As soon as we have a dedicated pubkey type, the address derivation should be straight forward.

  • Add EthSecp256k1 support to pubkeyToRawAddress/pubkeyToAddress

Transaction seralization

Not sure if transactions are serialized the the Cosmos way or using RLP. Also how do account numbers and sequences work here?

In #1107 it seems like only the pre-hashing changes as part of the signing.

Account type support

We have support for various account types already and new types can be added by the user.

  • Figure out if /ethermint.types.v1.EthAccount can easily be integrated

Key storage

The wallet implementations we currently use return pubkeys of type Secp256k1, not EthSecp256k1. This also requires a new algorithm option in the type Algo = "secp256k1" | "ed25519" | "sr25519" for AccountData.

  • Add ethsecp256k1 to type Algo
  • Create new Ethermint wallet implementations
  • Test Keplr compatibility (out of scope for this codebase since we have no Keplr dependency but it should be tested and demod externally to ensure the interfaces are alright).

Overall I guess it can be done but I am an outside observe with almost zero knowledge how Ethermint works. The biggest problem I see is actually the Amino prefix, which can become a blocker for the whole ticket if it cannot be changed on the Ethermint side as it is already used for existing address generation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions