An idea for automatic handling of EVM chains

[DefiDebauchery]

The README for EVM chain integration is slightly ambiguous - it first mentions that submissions are either based on SLIP44, or a bitwise OR using the chain ID. Later, under PR requirements, you mention that you check for a SLIP44 submission. It doesn't seem that SLIP44 was meant to be used this way for EVM networks that don't use a unique derivation path.

Given that you're already relying on third-party resources for this data, would it reduce overhead if ENS simply adopted ethereum-lists/chains? Other than the fact that it includes testnet networks (with no attribute to filter, which we could probably ask for), their 'mini' json endpoint has everything needed to incorporate chains quickly. This would be of great use on the ENS frontend, where perhaps we could specify chainId (instead of Cointype) for our address records.

I imagine this may come with a small risk of collisions of SLIP44, but with the EVM-specific methods, I feel like that could be mitigated. Even if you don't want to support every network by default, I still think more clarity and an easier integration process would be incredibly useful for ENS end-users.

[makoto]

Later, under PR requirements, you mention that you check for a SLIP44 submission.

that's just that the section is out of date. I just updated the README.

Adopting ethereum-lists/chains is good idea if it's available as npm module, but I am reluctant to relying on calling third party endpoint

[mmv08]

hey, @makoto, Mikhail from the Safe team here. @DefiDebauchery proposed to us an idea to utilize this for a better multi-chain Safe UX and we'd like to push this forward.

I've been looking into getting the chains package to npm, but I'm unsure whether it's a good idea because of the package's size, at the moment it includes 612 chains and growing rapidly (72 open PRs). So using this package would imply:

1. Downloading 11.6Mb JSON of chain data to the client
2. Adding a dropdown of 612 chains

Would you consider alternative solutions such as an input for chain id or a simple server with search endpoints or you'd still want to pursue leveraging the chains package?

[makoto]

11MB JSON to just store text data seems excessive. The lib definitely needs some tidying up.

In terms of alternative solutions, the only info ENS needs for EVM chain support is a chainId and coin/chain name.
chain id can be given as an input but I think we need store (or use other service) to lookup the name.

[mmv08]

11MB JSON to just store text data seems excessive. The lib definitely needs some tidying up.

In terms of alternative solutions, the only info ENS needs for EVM chain support is a chainId and coin/chain name. chain id can be given as an input but I think we need store (or use other service) to lookup the name.

I don't think it's the lib's fault, it's the world we live in, suddenly everyone needs their own chain 😂

Can ENS run a service if we create one? Would it use a third-party service? If yes, are there any requirements for the 3rd party? Because you mentioned previously you were reluctant to call a third-party endpoint.

[makoto]

I don't think it's the lib's fault, it's the world we live in, suddenly everyone needs their own chain 😂

json files alone is 2.5mb (still quit big). The rest of 7.5 MB are icons.

Can ENS run a service if we create one? Would it use a third-party service? If yes, are there any requirements for the 3rd party? Because you mentioned previously you were reluctant to call a third-party endpoint.

We host our own metadata service (https://metadata.ens.domains/docs) so it's technically possible to host one.

Maybe a sensible solution is to optionally allow users to include the list from API while the default is to work without it.

[DefiDebauchery]

The contracts don't have any validation of the leaf nodes, so it seems prudent to return the SLIP44 entries to non-EVM chains (BTC, LTC, etc), and then allow an additional text interface to allow an arbitrary chain_id. This could be enhanced with an autocomplete, which shouldn't be that much more difficult than a microservice (or an external indexing service like Algolia, which would be overkill, but fast).

[makoto]

@DefiDebauchery umm, I don't fully understand your rational of needing to add another field for chain_id when current chainId number transformation method (convertEVMChainIdToCoinType ()) convert chainId to numbers above 0x800000000 to avoid number collision with slip 44 (please read https://ens.mirror.xyz/K7z80JAsJmDSzgsp2-X8L3NPXPmkBc2i3-GNBXdcers for more details)

[DefiDebauchery]

@makoto - I understand that it converts, my thought process was that because there are so many EVM chains and would be infeasible to add them to the existing network dropdown, that a separate EVM field could be presented that would take chain_id as input (which of course would still do the leaf id conversion on the backend). Strictly a UI idea.

[mmv08]

I agree with @DefiDebauchery. Chain ids are easy to find on Google.

[makoto]

Just working on #374 at the lib level. Still TBD how to handle at UI level