Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Ergo namespace (CAIP2, CAIP10, CAIP19) #98
Add Ergo namespace (CAIP2, CAIP10, CAIP19) #98
Changes from 13 commits
1fdcb9f
4ec143c
e272066
8fcae18
3927026
3275f12
6e5efda
d3691c5
fb15142
178221d
4616406
134d4e6
f2c0dc0
4690aa9
aee083f
8d9a8a0
05cbd73
77e70fa
ae49988
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ineip155/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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 that0
and15
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 theblockchain 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.