Open dawsbot opened 1 year ago
@dawsbot I am wondering if it makes sense to reimplement them all from scratch, or maybe copy paste the decoders from ethers (https://github.com/ethers-io/ethers.js/tree/master/packages/abi/src.ts/coders) and replace the ethers specific things like BigInt etc.
Would you be open to such a PR, or would you prefer building the decoding logic from scratch?
@KeKs0r I'm open to being inspired by ethers
, but the current encode/decode is hand-written to be tiny. If you can recreate ethers' encode/decode but tiny, then that might as well be a separate npm module which you also PR to ethers ð
Let me know what you think!
Thanks for considering. I started to dive into the efforts and realized that even the encoders of ethers
are deeply entangled with a lot of code of their codebase. So might not be as simple as I thought. I might give it a try over the weekend anyways.
Hi @KeKs0r any thoughts on the above? I can help make suggestions or jump-in if you have anything mid-way completed on this ð
Hey @dawsbot, I migrated to ethers to build an initial feature, since I realized it would take quite some efforts to reimplement in essentia-eth. Sorry for dropping the ball on this.
All good, I still do that at-times too whenever it's too big of a lift to implement inside here. Could you help me out by linking me to a smart-contract which contains these data-types @KeKs0r ? I'll do the rest.
Unfortunately I dont remember which contracts exactly hit some issues, but I have a list of contracts that I am calling in my code and their abis. I uploaded the ABIs to this gist: https://gist.github.com/KeKs0r/84d77cfa8c4fdcfc22e2fef93b5bfda6 Those are contracts from Uniswap and Sushiswap.
Incredible, that should be plenty to help with debugging this @KeKs0r ð
There are several encoding + decoding types that are not yet working.
Enabling signing will be dangerous until most or all encoding/decoding types are working with
essential-eth
.To start, we should find production smart-contracts which have unique and difficult types then add support via jest tests like was done with the CRV smart-contract tests. The readme outlines types that are already covered properly. Assume all others will error and this issue is to track adding support.