-
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
Add support Ethermint #1106
Comments
👋 I'm not convinced we should add chain-specific types into any core component of the library. But let's see, maybe we can help here and there …
Do you need support for your own account type? This was recently implemented in #1102 |
No problem~~ For generating the address, it's all good. I can do it outside the library and keep the core component library clean. But for adding a new transaction signing method, Im wondering if I need to copy a set for code to do it because the signing method is shared across the code. Or is there any customize module for implementing it? |
Could you commit your local changed and create a draft PR with what you have? Maybe that helps understanding what you are doing and how to best collaborate. I worked on Ethereum client tech before but have no clue about Ethermint. |
Sure~ |
Hi, I just created a draft PR #1107. This is a quick draft from me and probably I will re-write and enhance it with pubkey type instead of coin type. Just let me know if there are any improvement or suggestions. Thank you! |
Thank you @vincentysc. I looked at your diff last week. That's very helpful. However, I don't think we want to integrate chain-specific functionality at that level. Sign Mode Direct is a Cosmos sign mode with Cosmos pubkeys and not made to add arbitrary secp256k1 signing. I think you can add Ethermint messages and queries in your client code. But if you need Ethereum signing tooling, you better use Ethereum libs for that. |
Fully understand. I'll give it a try. Thank you @webmaster128. |
Hi @webmaster128. Actually my project is running a in-app relayer(ts-relayer) to relay its own packets only. When it is Cosmos chains, use CosmJS at it is right now; On Ethermint based chain, switch to use another library. However, this would require quite some refactoring to the (ts-relayer) as it is highly dependant of CosmJs. So, is the previous approach is good enough for this project? Do you have any other suggestions in your mind? |
bringing this back, having the same issue with cosmjs signing client on an ethermint based chain. IMO, it stops being a chain-specific problem when multiple chains start trying to do this. would support for this to be re-opened so that ethermint developers dont have to maintain their own forks. I know its more of an ethos shift, @webmaster128 thoughts? |
See #1351 |
Hi!
I added the
Ethermint
support to cosmjs locally with the following functions:/ethermint.crypto.v1.ethsecp256k1.PubKey
/ethermint.crypto.v1.ethsecp256k1.PubKey
Is it ok to add a public key type flag to identify different decode/signing method in the following files? Any suggestions?
Generate address
In directsecp256k1hdwallet.js:
getAccountsWithPrivkeys(), getKeyPair()
In account.js:
accountFromAny()
Sign transaction
In pubkey.js:
decodePubkey(), decodeSinglePubkey(), encodePubkey()
In signingstargateclient.js:
signDirect()
The text was updated successfully, but these errors were encountered: