Add Ergo namespace (CAIP2, CAIP10, CAIP19) #98
Conversation
gagarin55
changed the title
gagarin55
changed the title
|
Dear @bumblefudge, any chance to be reviewed in the nearest future ? |
| ``` | ||
| chain_id: namespace + ":" + reference | ||
| namespace: ergo | ||
| reference: 32-character prefix from the hash of the genesis block |
There was a problem hiding this comment.
Why 32 characters? If you're already substringing out a prefix, you might be using up valuable characters that you could need for the address types (CAIP-10, CAIP-19) and possible paths or query parameters tacked on at the end. If you check out other CAIP-2 profiles that substring a hash, they tend to opt for 8 characters or even 4, if they're not anticipating too much collision-risk between hundreds of thousands of private networks and testnets :D
There was a problem hiding this comment.
(This is not to say 8 or 4 is optimal, just recommending you add a small ### Rationale section if there is, in fact, a meaning to using a 32char reference! )
There was a problem hiding this comment.
also, if there are only 16 possible chainIDs in the prefixes (half an 8bit unsigned --> 0-15, right?), chainId could also just that prefix? just a thought, no strong preference here just pointing out that 0 and 15 are both equally good values here, if you want to economize or use them as a checksum against the prefix in the CAIP-10/19 reference that follows!
There was a problem hiding this comment.
I borrowed the concept of using a 32-character identifier from another blockchain's CAIP-2.
Allow me to clarify the concept. In Ergo addresses, we should view the network type prefix not merely as a specific chain ID, but rather as a designation of the blockchain type—whether it's a testnet, mainnet, etc.
For example, if we were to fork the mainnet, we would create another chain with the same blockchain type but a different chain ID (similar to Bitcoin forks).
Alternatively, consider a scenario where someone decides to launch a new testnet with a new genesis block but the same address scheme.
I am not an Ergo core developer, so the current situation stands as described.
Terribly sorry for the delay, have been traveling and neglecting my github inbox. Please note that I also recommended some edits in a separate PR on your fork, which would probably be helpful to merge (or at least cherry pick the purely formatting-based commit) before making any content changes to triage/answer my questions above :D |
|
LGTM, modulo the suggestions above-- let me know if they're hard to understand or just wrong/not-helpful! |
Pardon, which suggestions? Seems I've merged your fixes. |
| equivalent) tokens is the same. The process for issuance of either is also the | ||
| same. The only difference is that NFTs must have specific values for certain | ||
| properties. | ||
|
|
There was a problem hiding this comment.
where are these values expressed, though? can you tell from looking at a CAIP-19 expression (or a native expression) which one it is? note that in the EVM profile of CAIP-19 this extra value is tacked onto the URI using a /, which seems handy enough if that info would be public anyways to all queriers?
There was a problem hiding this comment.
No, when you see at Ergo Token ID you can't say what kind of token it is. Ethereum has particular ERC for each token standard. But Ergo has only EIP-4 standard which describes additional registers for NFT-tokens. I think this is application task to receive token info from blockchain (or store it somewhere).
There was a problem hiding this comment.
Cool, there's a few other namespaces like that. I guess what I am trying to tease out (and suggesting you make explicit in the doc for future implementers with little context) is whether they can append, e.g. /1234 for #1234 in a serial NFT series like in eip155/caip-19 when your application has already retrieved that info from the blockchain before passing that CAIP-19 identifier to another application/counterparty, and conversely when a CAIP-19 received from a trusted counterparty with those additional registers/segments can be trusted versus when they should be validated by checking on-chain context. not blocking, just suggesting, since CAIP-19 strings are often passed around by folks in contexts quite distant from chains and deducing a lot from the strings themselves, like, for example, in dashboard dapps that aggregate data from various sources while minimizing the required roundtrips to nodes for onchain data.
There was a problem hiding this comment.
I understand what you are speaking about, but in Ergo there is no well defined NFT standard and particular it is unclear how to implement NFT Collections. There is no Collection/Series ID as we have contract address in Ethereum.
I suggest to proceed further. If someday the NFT problem in Ergo will have solid solution we are able to update specs.
There was a problem hiding this comment.
@gagarin55, there is this EIP-34, please check if it is suitable here. If not, please feel free to file a PR with the extension.
Dang it, my mistake, github dot com's new UX default keeps comments in "pending" state until you hit the review button. Sorry if that slowed you down-- should be quick fixes |
Co-authored-by: Bumblefudge <caballerojuan@pm.me>
Co-authored-by: Bumblefudge <caballerojuan@pm.me>
Co-authored-by: Bumblefudge <caballerojuan@pm.me>
Co-authored-by: Bumblefudge <caballerojuan@pm.me>
| equivalent) tokens is the same. The process for issuance of either is also the | ||
| same. The only difference is that NFTs must have specific values for certain | ||
| properties. | ||
|
|
There was a problem hiding this comment.
Cool, there's a few other namespaces like that. I guess what I am trying to tease out (and suggesting you make explicit in the doc for future implementers with little context) is whether they can append, e.g. /1234 for #1234 in a serial NFT series like in eip155/caip-19 when your application has already retrieved that info from the blockchain before passing that CAIP-19 identifier to another application/counterparty, and conversely when a CAIP-19 received from a trusted counterparty with those additional registers/segments can be trusted versus when they should be validated by checking on-chain context. not blocking, just suggesting, since CAIP-19 strings are often passed around by folks in contexts quite distant from chains and deducing a lot from the strings themselves, like, for example, in dashboard dapps that aggregate data from various sources while minimizing the required roundtrips to nodes for onchain data.
No description provided.