camaraproject / BlockchainPublicAddress

Repository to describe, develop, document and test the Blockchain Public Address API family
Apache License 2.0
6 stars 4 forks source link

Solving the chain identification issue #19

Closed ghost closed 10 months ago

ghost commented 1 year ago

Problem description We currently do not have an effective way to identify different blockchains without running into many questions, issues, and inefficiencies.

We can't just use EVM chainIDs because this would not account for other L1 ecosystems like Bitcoin, Cardano, Solana etc.

Using string-based identifiers (the current approach) like "ethereum", "polygon", "celo", "bitcoin" is inefficient because this would require us to add every single chain manually, and this is not viable, especially since Layer 2s, rollups, and app-chains are on the rise.

And it seems like there is no already existing open standard to identify different blockchains which hasn't been abandoned. Developing such a standard ourselves is not in the scope of this WG.

Possible evolution Instead of indexing every chain ourselves, let's only consider layer 1 ecosystems like "bitcoin", "ethereum", "solana" etc. which we add to the API manually. And then add an additional, optional parameter to indentify specific chains within that ecosystem. For example, most activity will be covered by EVM-Blockchains and Bitcoin. Bitcoin only has one chain, so the optional parameter would be empty. I'd suggest using the term "EVM" (i.e. Ethereum Virtual Machine) instead of "Ethereum" because Ethereum L1 forks like Avalance or BNB Chain also use the EVM and thus the same address format but are not inherently connected to Ethereum.

Examples:

  1. If the user would add an Ethereum address, the API call would have EVM as chain parameter, and the optional chainID parameter would be "1" (for Ethereum Mainnet).

  2. If the user would add a Polygon zkEVM address, the API call would have EVM as chain parameter, and the optional chainID parameter would be "1101".

  3. If the user would add a Binance Smart Chain address, the API call would have EVM as chain parameter, and the optional chainID parameter would be "56".

  4. If the user would add a Bitcoin address, the API call would have Bitcoin as chain parameter, and the optional chainID parameter would be empty.

I think you get the point. A comprehensive list of all EVM chain identifiers can be found at https://chainlist.org/.

And since we would now have covered the majority of popular chains, we could add other Layer 1 chains manually and use the optional parameter for their respective ecosystem, using their chain identification system (just like we did with EVM). Possible applications would be for Cardano's side chain model or Polkadot's parachain model. And some L1s don't need the optional parameter at all, like Bitcoin, Solana, or Litecoin.

Please don't hesitate to ask questions and I'm happy to read your comments :)

PedroDiez commented 1 year ago

Agree this is a flexible way to identify blockchains. We "loss" some part of user-firendly description for layer 2 blockchains (as we would use the chainId, however with good description and referencing https://chainlist.org/ (also have dived into https://chainid.network/). This would be enough to have the key principles

Some comments:

Some doubts for clarification:

ghost commented 1 year ago
  • To refer to L1 Blockchains would like to keep current "blockchain" parameter . So in the next version, provide suitable description. For initial L1 blockchains, what would be the initial ones to be considered? (Open here to receive inputs)

Sure, let's keep calling this parameter "blockchain".

  • ethereum (would also like to keep this name as is more user friendly, including some description to the context/term of EVM)

I definetely get your point here. But the reason I advocate for "EVM" instead of "Ethereum" is because we could instantly have support for hundreds of chains that use the EVM, the "Ethereum clones" basically. That includes all EVM chains which are listed on https://chainlist.org/. If we were to use "ethereum" as base value, we would be limited to testnets and Layer 2s. Would you still add the chainID parameter "1" when you call an Ethereum address? Also, all these Ethereum clones (alternative EVM chains) like BNB Chain, Avalanche, etc. would have to be added separately as L1 chains. What about future EVM chains? Would you like to add them manually too each time they grow to a certain size where it makes sense to include them? Another part of why I think "EVM" fits better is because they all use the same address format ("0x", followed by 40 alphanumeric characters). So I guess you could say I advocate for grouping blockchains by adress format and equal chainID system instead of actual L1 ecosystems, which I think is your approach.

  • bitcoin

Should be included as L1 value, initially.

  • solana

Same here.

  • cardano

(See below).

  • Add new parameter "chainId" or "blockchainId" that refers to the chain identification ecosystem within a given L1 Blockchain

Let's call it chainID. Keeping things simple.

Some doubts for clarification:

  • Have found different links for L1 blockchains, and not seeing same response. Is there a place where an oficial list of L1 blockchain are hosted?

There's no entity that could put together an "official" list of L1s. But I like this one: https://coinranking.com/coins/layer-1.

Yep.

  • For bitcoin, solana, cardano do not have different chainIds. We can document that in the API description.

Bitcoin and Solana are monolithic blockchains, so they don't have a chainID. I wouldn't put Cardano in the same bucket though. They have a side chain architecture, but I couldn't find a proper id system for those. Open for input here. I'm pretty sure the optional chainID parameter would be sufficient to address those as well, though.

No, definetely not. Bitcoin is its own thing. The chain you found is something completely different.

ghost commented 12 months ago

@PedroDiez After careful consideration, I would like to second your suggestion to use "ethereum" instead of "EVM". I think it would be better to categorize chains by their respective L1 ecosystem instead of their identifier system.

Also, I would like to propose to enable the optional chainID parameter only for EVM-L1s for now (until we better understand other L1 identifier conventions).

For Ethereum Mainnet, we'd set blockchain="ethereum", chainId="1". For Polygon, we'd set blockchain="ethereum", chainId="137".

And for other L1 ecosystems that use the EVM as well, it would look like this for example: For Avalance C-Chain, we'd set blockchain="avalanche", chainId="43114". For Avalanche Fuji Testnet, we'd set blockchain="avalanche", chainId="43113".

And a non-EVM chain like Bitcoin would thus just be blockchain="bitcoin".

PedroDiez commented 11 months ago

@sebKoeller It looks good to me.

so in "blockchain" we can have as initial values: ethereum, bitcoin, (solana, cardano as well if everyone seems good approach). So here, it would be to agree in the initial L1 ecosystems we would like to consider initially.

And use "chainId" referred to chainID parameter only for EVM-L1s for now.

PedroDiez commented 11 months ago

Initially to consider:

Only one parameter to identify the blockchain. Name To Be Defined

Considerations - Supported values so far: evm-chainId naming model for EVM-based networks. Reference to https://chainid.network/ bitcoin solana cardano

Consider an exception for business scenarios where a given value is not supported in the BE logic.

PedroDiez commented 10 months ago

Pending Point: name for blockchain field.

Some suggestions:

PedroDiez commented 10 months ago

@grgpapadopoulos comments his preference is blockchainNetworkId

PedroDiez commented 10 months ago

@sebKoeller which is your preference?

ghost commented 10 months ago

I don't really have a preference. I think all suggestions would be a good fit. What about you @PedroDiez @rartych @ksl4dtit ?

PedroDiez commented 10 months ago

Given the fact "blockchain" was not seen the more suitable one during this issue discussion, my preference would be blockchainNetworkId as well

PedroDiez commented 10 months ago

Let's see other views until this thursday, then will take the value with more support for updating the PR

PedroDiez commented 10 months ago

@grgpapadopoulos, @sebKoeller, @rartych, @ksl4dtit moving forward with blockchainNetworkId

Will update PR#30