ethereum
Update avax API supported chains
According to #2013 Ethereum Mainnet avalanche explorer's API stopped supporting and many other chains.
We should review them and remove "avalancheAPI: true" statement from them.
Even better if we can find an automated way to do this if they have a machine readable supported chains list. We recently found this for all major explorers so we can actually do this for all in build time. If we do so this should be well documented because currently sourcify-chains-default.json also serves as a place to look what the chain supports.
https://api.etherscan.io/v2/chainlist https://routescan.io/api/evm/all/explorers https://chains.blockscout.com/api/chains
Before I move on with this I wanted to double check and get your feedback.
The main idea here was to check which chains have "avax API" support. Since they seemed to change which chains they support, I thought we do it dynamically. Then, since we're on a dynamic API/Explorer support check, I thought it makes sense to do this for Etherscan, Routescan, and Blockscout too.
Checking the avax API as well as the others introduces asynchronicity to the ChainRepository building and requires us to change the way we do it. So if we are going to move to a dynamic way from the now "hardcoded" way, I thought we can also build fetch the chains.json dyanmically.
At the end we'd fetch everything at the start, then periodically like every hour (what's a sensible interval here?) we'd re-fetch and update all the chains. Still, our main source of truth will be sourcify-chains.json for which chains we support and extra info such as the non-public RPCs, or Etherscan API keys.
wdyt?
Yes, sounds reasonable to me. I think it can save some maintainence effort in the future if we fetch everything programmatically. I think you can move on with this.
For the timeout, I wouldn't go below 1 hour. 3 might even be enough.
The only concern I have is that this might increase the server start up time. We should run this concurrently with anything else that is asynchronous during server initialization.
Also, it might be worth to reconsider an asynchronous server creation method for this as in https://github.com/ethereum/sourcify/pull/1956 / https://github.com/ethereum/sourcify/commit/ed70da1ca57c30be2425a202bffe1a2ab8488ca7. I know this is a breaking change, but adding a the chain fetching will probably be a breaking change anyway. (also, this is only a breaking change for anyone who uses the Server class directly, the cli.ts will work the same.)
Ok then if you agree I'd deprioritize this. The reason I wanted to have this in the sprint was that it was supposed to be an easy implementation. I'd rather move forward with #1983
Yes, agreed. Seems reasonable to do a larger refactoring of the chain configuration set up, later with more time.