-
Notifications
You must be signed in to change notification settings - Fork 340
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CosmJS and Ethermint #1351
Labels
Comments
This was referenced Dec 13, 2022
Closed
Closed
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. |
@phips28 do you think you can share it anyway? or point me to the right resources? |
@phips28 thank you ser! Very clean :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
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.
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.
/ethermint.types.v1.EthAccount
can easily be integratedKey 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"
forAccountData
.type Algo
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.
The text was updated successfully, but these errors were encountered: