BlockExplorer API Routes

[ligi]

This CAIP is inspired by EIP-3091 by @pedrouid
As a maintainer of ethereum-lists/chains I regularly check for compatibility with EIP-3091 and over the time noticed several things:

• the only real usages I have seen in the wild are address and transaction - token and block are also defined but I have not seen this used
• block is a bit problematic for L2s as they often refer to it as batch
• as block accepts number and hash and token needs me to find a deployed token on a chain they are time-consuming to verify (and then not really used)

So I create this CAIP which only contains address and transaction - this allows also block explorers to be under some standard that do not support token or block and saves me time verifying compatibility.
Also having this as a CAIP is good as it can be used for chains other than Ethereum.
If we find usages for blocks or tokens there can then also create a CAIP that inherits from this one and extends it with these routes. This way we can also distinguish between explorers with different feature-sets.

#200

[bumblefudge]

Actually, I would push back a little on token not being used, because Centre.io would greatly prefer this be used more to differentiate official from unofficial/copycat/impersonated tokens! I wish the designers/implementers of block explorers had seen Pedro's EIP before diverging wildly. Here, for example, is a list of explorer links to the USDC contract on various chains where it is deployed as a ERC20-or-equivalent:

• https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48
• https://algoexplorer.io/asset/31566704
• https://explorer.solana.com/address/EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v
• https://stellar.expert/explorer/public/asset/USDC-GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN-1
• https://tronscan.org/#/token20/TEkxiTehnzSmSe2XqrBj4w32RUN966rdz8
• https://app.dragonglass.me/hedera/tokens/0.0.456858
• https://snowtrace.io/token/0xB97EF9Ef8734C71904D8002F8b6Bc66Dd9c48a6E
• https://flowscan.org/contract/A.b19436aae4d94622.FiatToken
• https://polygonscan.com/address/0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174

I'm not saying all VMs/block explorers should distinguish erc20-or-equivalents from other contracts in their pathing, necessarily, but if you consider USDC as an example of a succesful cross-chain/cross-VM ERC20-based system, you can see why the issuers and governance body of USDC would want such a distinction to be standardized and popularized!

I would also note that in some namespaces, deployed contracts and EOA are expressed differently, so it might make sense for contract or token to be distinct from address? I fully recognize that in EVM,
https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48
and
https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48
are both valid URLs that take you to different pages, but I believe there are systems where one would redirect you to the latter

[bumblefudge]

(More generally, though, it probably bears saying explicitly that I love the idea and intention of this CAIP and look forward to refining it and publishing it!)

[bumblefudge]

I'm still thinking about the backwards compat section of EIP-3091 -- pragmatically, how do we influence block explorer design -- do the people tasked with standing up explorers for new chains, particularly non-EVM and L2s with weird structures like epochs and batches and anchors, even know EIP-3091 exists? is it something people design with cross-chain interop in mind, or do the usually grant-funded teams just leave that for V2?