Adding support for okexchain?

[summerpro]

Hello ethers.js developers, we are from the okexchain team, we are looking forward to ethers.js to support okexchain. If you agree to cooperate with okexchain, you can check the detailed requirements below.

The problem we are encountering now is this: When a user uses ethers.js to send a transaction to OKExChain, an error occurs. The reason for the error is that the transaction hash returned by the OKExChain is inconsistent with the hash that ethers.js expects.

OKExChain is a public chain based on CosmosSDK and compatible with Ethereum. We basically implement all the functionalities and interfaces of Ethereum, so users can deploy and interact with smart contracts on OKExChain like in Ethereum. However, the way OKExChain calculates transaction hash is different from the way Ethereum does, so the same transaction will get different transaction hashes on OKExChain and Ethereum. We guess that the error mentioned above is because ethers.js uses the same transaction hash calculation method as Ethereum does.

Users will not get into this error when using Truffle to send transactions to OKExChain, perhaps because Truffle does not calculate the transaction hash locally and compare it with the return value of the OKExCHain. So in order to allow users to better use ethers.js in the OKExChain ecosystem, some adaptation work would be preferred? We have three suggestionsyou’re your reference:

1. When sending a transaction, do not perform local hash calculation, but directly use the transaction hash returned by the OKEexChain.

2. Add the method to calculate the transaction hash in the way OKExChain does, and allow users to choose which way of transaction hash calculation they want.

3. When sending a transaction, determine the chain id passed by the user is the one used by OKExChain's (65, 66). If it is the case, the transaction hash returned by the interface will be used directly.

Thanks.

[ricmoo]

This is unlikely something I would add to ethers, but is certainly something you could consider adding an ancillary package for. You could implement your changes as a sub-class of BaseProvider, notably overriding the Formatter instance to one which is compatible with your network, overriding the Formatter.hash method.

I have tried in the past to add functionality to aid alternate and fringe chains, but unfortunately the code's cleanliness suffers and providing support and maintaining the feature becomes quite time consuming.

It also tends to add bloat, including code that only a small subsection of users require, but that all users must incur the download costs and code complexity costs for.

Does that make sense?

[summerpro]

I think that suggestion 1 will not affect all the old users of ethers.js, and it can also be extended to new users, which is compatible. Looking forward to your support

[summerpro]

@ricmoo hi, Formatter.hash only implements the hex format of the hash. What we want to change is not this. We need to modify the sha3 to sha256, and change the transaction serialization before calculating the hash from the rlp encoding to the cosmosaminoencoding. May I ask what you need Where to modify?

[summerpro]

@ricmoo hi, I have modified the code according to our needs to be compatible with exchain. How to use it as an ancillary package for ethers.js?
This is the commit okblockchainlab@6f67d2c

[ricmoo]

I’m working on two ancillary packages now and breaking out some build logic into its own tool right now. These will be able to serve as examples on creating ancillary packages.

I’ll try to remember to post to this thread but I’ll post a tweet (https://twitter.com/ricmoo) when I get some ancillary packages out too. :)

[summerpro]

ok，thanks a lot

[ricmoo]

(moving to discussions)