CosmJS and Ethermint
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
- Pubkeys
- Addresses
- Transaction seralization
- Account type support
- Key storage
Pubkeys
Ethermint uses the uncompressed secp256k1 encoding from Ethereum, which is incompatible with Cosmos secp256k1 address derivation. https://github.com/cosmos/cosmjs/pull/1160 shows how this can be implemented using a different pubkey type. To make this work we need:
- [ ] Fix documentation of ethermint.crypto.v1.ethsecp256k1.PubKey: https://github.com/evmos/ethermint/issues/1158
- [ ] Add pubkey type to cosmjs-types: https://github.com/confio/cosmjs-types/issues/31
- [ ] Get a different Amino identifier than from 0xEB5AE987 (tendermint/PubKeySecp256k1) and ensure the length is correct (not 0x21)
- [ ] Add new EthSecp256k1 pubkey type (basically https://github.com/cosmos/cosmjs/pull/1160)
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 https://github.com/cosmos/cosmjs/pull/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.EthAccountcan 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.
Is it planned to add support for it?
We currently use cosmos-kit (that uses cosmjs) to interact with cosmos chains.
But it does not work for Evmos and Dymension (launched today). We get the following error:
Any idea how to solve it?
I'm having the same issue. Did you find a soluttion @phips28 ?
Yes, we "hardcoded" 🍝 a script for chains that use those ETH flow. Now we are able to estimate fee and sign. but its hard to share as its tied to our code 🙈
@phips28 do you think you can share it anyway? or point me to the right resources?
here you go: https://gist.github.com/phips28/bf157476a3c798b09c3edffa8a149996
@phips28 thank you ser! Very clean :)
Hi, know that the Amino prefix is the biggest blocker. Can you explain the blocker details to me? Im willing to contribute and push this forward.