to add polkadot.md #6

bumblefudge · 2022-03-05T01:01:11Z

I totally went out on a limb and defined CAIP-10 for this because it seemed so well-documented and straight-forward, although I had some questions:

Would it be clearer or more standard/intuitive for Polkadot developers to use the prefix registered in the SS58 directory as the chainID? if nothing else, it would shorten CAIP-10s
Even shorter would just be removing the chain reference from the CAIP-10s, since they are recoverable from the addresses! Is that... even an option, without updating CAIP-10? If so, would they look like
polkadot:EVH78gP5ATklKjHonVpxM8c1W6rWPKn5cAS14fXn4Ry5NxK
or
polkadot::EVH78gP5ATklKjHonVpxM8c1W6rWPKn5cAS14fXn4Ry5NxK
?
I didn't even touch NFTs or assets, but maybe I should open a tracking issue for it?

CC @pedrouid @joshua-mir @shawntabrizi

bumblefudge · 2022-03-07T20:13:32Z

@Jam10o are you the same Joshua Mir? Are you interested at all in contributing to this, or conversely, would you prefer I take your name off future iterations of your work as co-author? Feel free to backchannel me on Discord if you'd like to discuss in private, I'm {GH uname}#1488 there.

bumblefudge · 2022-03-10T16:38:18Z

notes from today's meeting:

chain id's omittable in polkadot's address system, should they be in this caip-10?
- polkadot:-: would not break existing reg-exs
- maybe referring to one of the relay-chains is better than not referring to anything, since it aids efficient discovery?
should caip-10 consider cases where the chain id is optional or recoverable from the expression of the address, as in polkadot's case?
- oed: if "caip-10" doesn't need to omit chain_id to fit in the maximum length of today's caip-10, maybe we can return to this "caip-10 without caip-2" corner case later, when someone actually raises an issue!

TimDaub · 2022-03-10T17:10:34Z

In today's call you, @bumblefudge, mentioned that polkadot's addressing scheme integrates the chainID into the address and makes it reproducible. Currently, the namespace is suggested as e.g. polkadot:..., whereas the logical equivalent to the addressing in the Ethereum namespace is prefixed by the EIP defining the chainID concept eip155:1:.

So to reduce redundancy, I'd suggest prefixing the polkadot namespace with the name of the standard document that defines how chainIDs are encoded into polkadot addresses. E.g. if Polkadot has a "Polkadot Improvement Proposal" process with a PID-XY defining how chainIDs are encoded into the address, we'd prefix with pid-xy:EVH78gP5ATklKjHonVpxM8c1W6rWPKn5cAS14fXn4Ry5NxK.

At least those were my thoughts from the top of my head. Haven't looked into Polkadot really but found this:

https://docs.substrate.io/v3/advanced/ss58/

bumblefudge · 2022-03-11T22:59:49Z

good point! The namespace is entirely governed by ss58 and its registry (which is in the same repo!) so ~~ss58:-:EVH78gP5ATklKjHonVpxM8c1W6rWPKn5cAS14fXn4Ry5NxK~~ (misunderstood)

polkadot:ss58:EVH78gP5ATklKjHonVpxM8c1W6rWPKn5cAS14fXn4Ry5NxK
sounds like a better name! I'll update my PR and await a confident 👍 or 👎 from someone with polkadot-building experience!

ntn-x2 · 2022-05-30T08:55:36Z

@bumblefudge how would this new proposed scheme to replace CAIP-10 play out with the CAIP-2 definition of a Polkadot-based chain? In that case, we are still using genesis hashes to identify a particular chain, and this, as far as I understand, would break the requirement that a CAIP-10 address is built on top of a CAIP-2 identifier.

EDIT: Ok I just saw the linked PR which raises the same issue. So, what is the way forward for this new propsal?

joepetrowski · 2022-05-31T06:02:50Z

polkadot/caip2.md

+This is a list of manually composed examples
+
+```
+# Kusama
+polkadot:b0a8d493285c2df73290dfb7e61f870f
+
+# Edgeware
+polkadot:742a2ca70c2fda6cee4f8df98d64c4c6
+
+# Kulupu
+polkadot:37e1f8125397a98630013a4dff89b54c
+```


"The namespace is called "polkadot" to refer to Polkadot-like "parachains,""

None of these are parachains :). Ideally namespaces would anchor at consensus systems, so e.g.:

polkadot:<statemint-genesis-hash> kusama:<statemine-genesis-hash>

Or, if you wanted to express that Kusama and Polkadot are connected, perhaps add another "relational" namespace in the path, like:

polkadot:canary:<kusama-genesis-hash> polkadot:para:<statemint-genesis-hash> polkadot:solo:<kulupu-genesis-hash>

The problem that will come up is migrations. For example, Centrifuge and Integritee (maybe some others, these two off the top of my head) were solo chains that became parachains. So if these identifiers are meant to last forever, there could be issues, but I'm really not that familiar with CAIP. You could also decide that migrated chains are two different chains, and have resources of one point to the other for the complete history.

Or, if you want to avoid migration issues entirely, just change the docs from "The namespace is called "polkadot" to refer to Polkadot-like "parachains,"" to something like, "The namespace is called "polkadot" to refer to blockchains whose state transition functions can execute on the Polkadot host API, for example parachains or Kusama."

In the latter example, would all chains then still use the polkadot namespace? I saw a comment about the MultiLocation struct that mentions forks also for (para)chains in the Polkadot space. If that is the case, I think having a genesis hash as a way to identify chains (as is the case now) is definitely not sufficient, as two forked chains would be identified by the same hash. To this point, would a combination of genesis hash and SS58 prefix be sufficient to uniquely identify all chains, including forks and migrated ones?

In the latter example, would all chains then still use the polkadot namespace?

Yes, as they are chains that execute on top of the Polkadot host API (which is not just expressed in Substrate, but also in other implementations like ChainSafe's Gossamer).

I saw a comment about the MultiLocation struct that mentions forks also for (para)chains in the Polkadot space. If that is the case, I think having a genesis hash as a way to identify chains (as is the case now) is definitely not sufficient, as two forked chains would be identified by the same hash.

How do you define a fork? A parachain should never fork, unless someone starts a new chain with a modified chainspec/runtime, but then that's just a new genesis. MultiLocations in general are relative location paths but don't actually know about a / location (although in practice it would be the governing consensus system). Since CAIP does seem to have a / location (the first namespace), MultiLocation could be mapped onto it from one chain ID to another.

would a combination of genesis hash and SS58 prefix be sufficient to uniquely identify all chains, including forks and migrated ones?

No, SS58 should probably not even come near this conversation. It's 99% for front end, there is no guarantee that it's unique (already, Polkadot and Statemint both use a prefix of 0), nor that it will stay the same in a chain's lifetime.

Sorry, my mistake. Forks could nevertheless still exist for standalone chains, and if they would be identified with the same polkadot namespace, then using the sole genesis hash would not be sufficient anymore.

No, SS58 should probably not even come near this conversation. It's 99% for front end, there is no guarantee that it's unique (already, Polkadot and Statemint both use a prefix of 0), nor that it will stay the same in a chain's lifetime.

Yeah that's what I thought. I wanted to make it clear as there has been conversation up above about using those to identify chains.

Forks could nevertheless still exist for standalone chains, and if they would be identified with the same polkadot namespace, then using the sole genesis hash would not be sufficient anymore.

Do you have any examples? I mean, the Polkadot host API assumes that you have some storage item called :code that contains a Wasm executable, and the chain defined by the genesis hash is the one that at each block height has executed that state transition function. To fork a chain, someone needs to manually force change that storage item and start a new chain, that's a new genesis hash.

That said, chain specs normally have an "id": "polkadot", entry that gets changed when a chain is restarted to avoid any confusion. This id is also something that a CLI would typically match on to start the correct chain. I'd probably go in this direction for a non-genesis-hash identifier. (Polkadot chain spec)

some time next month I'll devote a big bloc of time to overhauling all this and tag you both in the PR-- I clearly need to go back to the drawing board to map the CAIP mental model onto this VM!

Going to merge a straw man and invite PRs to improve, will return to this discussion

ntn-x2 · 2023-02-21T08:00:47Z

@bumblefudge is there anything I can do to resume the discussion in this PR and move it forward? I opened another issue in this repo which somehow seems to be related to having a definition for the Polkadot namespace. Would like some clarity both on this PR and on that issue 😁

bumblefudge · 2023-02-21T08:15:08Z

Hehe, yeah, that's fair. Two related issues:

1.) polkadot PRs have never seemed to get quorum/consensus because I don't understand polkadot from shinola and all attempts at reading enough to merge this PR end in my stuck in a rabbithole not understanding coordination chains or polkadot dev community needs. in particular, what's confusing to me is the difference between chainID systems and polkadot's system for addressing sidechains and private chains.

2.) As of last week, you are NO LONGER the only dev who has requested a CAIP for on-chain attestations. Let's try to merge a namespace for polkadot first (for my benefit, literally!) so that we can make sure the attestation CAIP we right after that makes sense across diff types of chains!

bumblefudge · 2023-02-21T08:27:27Z

In particular, I'd like help understanding this paragraph of Joe's, and the two links in it:

That said, chain specs normally have an "id": "polkadot", entry that gets changed when a chain is restarted to avoid any confusion. This id is also something that a CLI would typically match on to start the correct chain. I'd probably go in this direction for a non-genesis-hash identifier. (Polkadot chain spec)

If someone can ELI5 maybe I can overhaul this and have a CAIP-2 profile for polkadot that actually works soon. I am definitely leaning towards

polkadot:canary:{kusama-identifier}
polkadot:para:{statemint-identifier}
polkadot:solo:{kulupu-identifier}

though, one namespace for each consensus mechanism/coordination chain wouldn't make sense. from the links above it seems like there is a definitive registry somewhere that ensures a client will load the right wasm binary from :code per identifier, but what are those identifiers? can they be checksummed and/or validated with a regex? think of a CAIP-2 profile as needing to be relatively newbie-proof, as many of the people implementing against it will only need passive or high-level interop across chains!

ntn-x2 · 2023-02-21T09:00:21Z

in particular, what's confusing to me is the difference between chainID systems and polkadot's system for addressing sidechains and private chains.

Parachains are linked to a parachain ID, which is valid only within the context of a single relay chain. For instance, there could be a Polkadot parachain and Kusama parachain both with chain ID 2000, but belonging to two entirely different organizations. So a parachain ID is not an absolute identifier as the chain ID is for Ethereum. I am not super familiar with the Ethereum ecosystem, but as far as I can see from https://chainlist.org/, L2 chains also get a unique chain ID, which is the main difference from Polkadot parachains.

As Joe mentioned, one identifying component would be the chain spec name, which is supposed to match 1:1 to a given genesis (and its hash). Hence either of them could be used to identify any Polkadot-based chain, be it a relay chain, a parachain, or a solo chain. Also, it would support the migration of chains from solo chains to parachains and vice-versa. We at KILT also did something similar, where we migrated from the Kusama relaychain to the Polkadot relaychain, maintaining the same genesis hash.

So I would suggest that we can maybe use the following format:

polkadot:<chain_spec>, for instance polkadot:polkadot for the Polkadot relaychain, polkadot:kusama for the Kusama relaychain, or polkadot:kilt-spiritnet for the KILT Spiritnet parachain.

bumblefudge · 2023-02-21T19:55:45Z

Discussed out-of-band with @ntn-x2 -- Merging as-is to allow an overhaul in ongoing issues and PRs.

bumblefudge added 2 commits March 4, 2022 16:45

init polkadot.md

56a8bf2

to add caip-2 regex

66212fa

bumblefudge changed the title ~~init polkadot.md~~ to add polkadot.md Mar 5, 2022

bumblefudge requested a review from pedrouid March 5, 2022 01:01

bumblefudge mentioned this pull request Mar 9, 2022

Tracking issue: Editorial Overhaul to Namespaces ChainAgnostic/CAIPs#91

Closed

17 tasks

bumblefudge added the next meeting label Mar 10, 2022

bumblefudge added 4 commits March 26, 2022 16:23

to folderize

6699fc3

to simplify readme frontmatter

f7028b8

slight reorg for MD Header uniformity

2784e96

to fix frontmatter

bf9da5e

bumblefudge mentioned this pull request Mar 27, 2022

to extend polkadot/caip10 to include "implicit/not-yet-derived" CAIP-2 #20

Draft

oed mentioned this pull request May 30, 2022

CAIP-13 - Blockchain Reference for the Polkadot Namespace ChainAgnostic/CAIPs#14

Merged

joepetrowski reviewed May 31, 2022

View reviewed changes

bumblefudge added help wanted Extra attention is needed and removed next meeting labels Dec 6, 2022

bumblefudge added 3 commits February 21, 2023 20:36

tweak CAIP-2 rationale

9e53ac7

add newb-orientation graf to readme

8fd3e3c

refine caip-10 language

c60ba9e

bumblefudge merged commit 2e6cf3c into main Feb 21, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

to add polkadot.md #6

to add polkadot.md #6

bumblefudge commented Mar 5, 2022

bumblefudge commented Mar 7, 2022 •

edited

Loading

bumblefudge commented Mar 10, 2022 •

edited

Loading

TimDaub commented Mar 10, 2022 •

edited

Loading

bumblefudge commented Mar 11, 2022 •

edited

Loading

ntn-x2 commented May 30, 2022 •

edited

Loading

joepetrowski May 31, 2022 •

edited

Loading

ntn-x2 May 31, 2022 •

edited

Loading

joepetrowski May 31, 2022

ntn-x2 May 31, 2022

joepetrowski May 31, 2022

bumblefudge Sep 23, 2022

bumblefudge Feb 21, 2023

ntn-x2 commented Feb 21, 2023

bumblefudge commented Feb 21, 2023

bumblefudge commented Feb 21, 2023 •

edited

Loading

ntn-x2 commented Feb 21, 2023

bumblefudge commented Feb 21, 2023

to add polkadot.md #6

to add polkadot.md #6

Conversation

bumblefudge commented Mar 5, 2022

bumblefudge commented Mar 7, 2022 • edited Loading

bumblefudge commented Mar 10, 2022 • edited Loading

TimDaub commented Mar 10, 2022 • edited Loading

bumblefudge commented Mar 11, 2022 • edited Loading

ntn-x2 commented May 30, 2022 • edited Loading

joepetrowski May 31, 2022 • edited Loading

Choose a reason for hiding this comment

ntn-x2 May 31, 2022 • edited Loading

Choose a reason for hiding this comment

joepetrowski May 31, 2022

Choose a reason for hiding this comment

ntn-x2 May 31, 2022

Choose a reason for hiding this comment

joepetrowski May 31, 2022

Choose a reason for hiding this comment

bumblefudge Sep 23, 2022

Choose a reason for hiding this comment

bumblefudge Feb 21, 2023

Choose a reason for hiding this comment

ntn-x2 commented Feb 21, 2023

bumblefudge commented Feb 21, 2023

bumblefudge commented Feb 21, 2023 • edited Loading

ntn-x2 commented Feb 21, 2023

bumblefudge commented Feb 21, 2023

bumblefudge commented Mar 7, 2022 •

edited

Loading

bumblefudge commented Mar 10, 2022 •

edited

Loading

TimDaub commented Mar 10, 2022 •

edited

Loading

bumblefudge commented Mar 11, 2022 •

edited

Loading

ntn-x2 commented May 30, 2022 •

edited

Loading

joepetrowski May 31, 2022 •

edited

Loading

ntn-x2 May 31, 2022 •

edited

Loading

bumblefudge commented Feb 21, 2023 •

edited

Loading