Add Waves namespace

[msmolyakov]

No description provided.

[bumblefudge]

Hey there! We're off to a good start, but I had some questions and some advice.

As for CAIP-2, I would recommend reading around the other CAIP-2 profiles. You'll notice there are two patterns that all of them use one or both of:

1. unambiguous registries use the registry values for CAIP-2 identifiers,
2. a transformation of the genesis hash to identify chainIDs
   Since the goal of CAIP-2 is unambiguous cross-chain/offchain/multi-chain addressing, consumers of CAIP-10 and CAIP-19 addresses like to be able to "confirm" or "checksum" chainIDs, which is particularly hard for devs unfamiliar with that blockchain system. For this reason, combining First Namespace Reference - EIP155 and friends #1 and LAST CALL - READY to add eip155 #2, where space allows, might make the most sense for waves, since chains are identified by a single byte internally.

I noticed in the dev docs that custom networks (private ones, presumably) are allowed, but I don't entirely understand the address-scheme-character -- is this just a single ASCII character as "seed" to genesis block, or system-internal addressing scheme? Are there collisions if two different custom networks use the same character?

Also-- in many other chainID systems, there is a way to request the chainID from any node you're interacting with as a confirmation step, using that API's equivalent of a --help command. These often return a genesis block, or a genesis block can otherwise be requested, to confirm you've got the right node endpoint. Is this a direction you could explore for CAIP-2? This way, the second byte in a CAIP-10/19 and/or the address-scheme-character could be the prefix of the chainID, and a 4 or 8 character substring of the genesis hash could function as a "checksum", and new-to-waves implementers could use some kind of node command to confirm the checksum after using the chainID to connect to a node...

[msmolyakov]

Hi, @bumblefudge!

Thanks for the advice. We did just that: we got acquainted with all CAIP 2, 10 and 19 other blockchains, and based on them we created our own.

Regarding address-scheme-character, it is needed to distinguish addresses between different networks. In theory, there may be networks with the same Chain ID, but in practice this does not happen. Even so, each network has its own genesis and its own chain of blocks, so nodes are able to determine if a transaction is for them.

I also described how to determine the Chain ID through the API.

[msmolyakov]

I would also like some advice on the format of addresses and assets.

Do I understand correctly that both for addresses and assets, the CASA format must begin with a namespace and chain ID? Or is it optional?

In Waves, if the real asset ID has format "AB..." Base58 string, then in CAIP-19 it should be described as waves:87:AB..., is this right?
And if the real address has format "3P..." Base58 string, then in CAIP-10 it should be "waves:87:3P..."?

I ask because, as we described in CAIPs, chain ID is already encoded in address, so explicitly specifying the chain ID after the namespace seems a bit redundant.

We thought about options:

1. "waves:3P...". Seems the most logical, but doesn't match the format in CAIP-10 of other projects.
2. "waves:chainId:publicKeyHash". Waves nodes have a GRPC API, and it uses publicKeyHash instead of addresses. But this is rather an exception, and in this case the values are hard to read by users.

[bumblefudge]

The resolution section is great, thanks for that!

1.) Heh, a similar issue came up with Polkadot's addressing system, where a given private key/account expresses as a different address per chainID. There as well, the question of which to use (the universal pkh or the chainid-specific address) for CAIP-10/19 came up as well, and I'm a little undecided myself because both have pros and cons. one idea I have been debating is whether a "wildcard"/"null" value for chainID would be worth adding to polkadot and waves, where the universal, rather than chain-specific version of an account is being addressed or resolved. I believe there is a use-case for this kind of ecosystem-wide identification of wallets or assets (futureproofed against future chains being added), particularly across namespaces rather than within them, but I have yet to see demand for this use-case validated by wallet or dapp authors, so I am waiting for input from the ecosystems themselves (including you).

2.) Note that the minimum length of a CAIP-2 is 3 characters, as per the reg ex in the syntax section of CAIP-2. Thus, both a wildcard/null value (if you choose to specify one) and the normal one-character identifiers used internally and confirmed by the nodes would need to be "stretched" somewhere, whether by redundancy (waves:333:3NBNV8hiq8DTVF7UmzFLSUwud3h3pKZkVB3) or by trailing zeros (waves:003:3NBNV8hiq8DTVF7UmzFLSUwud3h3pKZkVB3).

3.) As for the inclusion of "chainID", it IS mandatory for conformance with CAIP-10 and CAIP-19. Much like the genesis hash versus chainID, redundancy here can be a virtue-- extra validation is particularly useful for non-native or multi-chain wallets and dapps! For example, it might be counterintuitive within the ecosystem (since waves:222:3NBNV8hiq8DTVF7UmzFLSUwud3h3pKZkVB3 would be patently nonsense), but offers an additional checkpoint to make sure chain selection is working as intended in cross-chain usecases! This is why so many CAIP-2 systems use a substring of a genesis hash rather than the self-attested chainID to handle hard forks or contested chainIDs, as a redundant check that forces wallet/callers to CONFIRM with the nodes that they're on the chain they think they're on, in systems where chainIDs can be self-attested! Think of the recent POW fork of Eth mainnet-- if the POW miners had followed through on their initial plan to keep chainID 1, you wouldn't know which chainID 1 you were on without querying the node for genesis hash 🙃

Which leads me to my last question: could I get a little more context on that "in theory/in practice" comment about two chains claiming the same ID?

[msmolyakov]

Hey @bumblefudge,

1.) So far I can’t say anything about the use cases now. But I changed the format to an explicit indication of chainID.

2.) Okay, I specified the chainId with leading zeros. But why is there such a restriction? What problem does it solve? Why can't ID be 1 or 2 characters? Is it possible to reconsider this limitation?

3.) As far as I know, nodes do not exchange information about genesis blocks. In short, they compare their last 100 blocks. If there is no similar chain of blocks among them, then the connection is refused.

[msmolyakov]

So we are ready for the final PR review and expect to be added to the registry as soon as possible.

[bumblefudge]

Excellent work, thanks so much! I had to open a separate PR to commit my edits, but nothing substantive, just formatting and clarity edits. Do reach out if protocol changes require a refresh of any of these documents, or if other CAIPs need profiles!

[msmolyakov]

Thank you for all your support!