CAIPs
CAIPs copied to clipboard
ChainAgnostic
A block identifier is missing
Over the last weeks, I've been busy figuring out
- https://github.com/ChainAgnostic/CAIPs/pull/119
- and #87
But now the more I think about it, the better it'd be if we had a unique identifier for blocks.
So far, in CAIP19 and the #119, I had proposed adding a #123 (aka #<block number) fragment to the identifier. But really, the block number isn't just a place in time like e.g. 2022-07-08. A block number plus a network name also refers to a piece of data on a blockchain. And a block number by itself, e.g. "123" isn't all that useful without the respective network.
In https://github.com/ChainAgnostic/CAIPs/pull/119, I did a survey for how block numbers on different networks look like and it suggests that it's a natural & incrementing number. Similar to CAIP-19 on asset types/ids, should we have a block number?
# Ether Token
eip155:1#block:123
# Bitcoin Token
bip122:000000000019d6689c085ae165831e93#block:123
# ATOM Token
cosmos:cosmoshub-3#block:123
So what would be the benefit of having a block number? What problem is it trying to solve?
1234, is a block number. But in which blockchain? We can't figure it out. So it' be good if we could post a structured identifier of e.g. a block for eip115:1#1234
Yes, but would the block number be part of the CAIP-2 spec? Or only of the CAIP-19 as an add-on for the CAIP-2 part? What would be then the meaning of a chain+block number? It would still not solve the unicity problem as two forked chains might still have been the same (+ same genesis hash) at that block number.
IMO it's useful to have an id that points directly at a block (not caip19) but then once we had that we could also use it to filter/point to a specific block state of an asset on a chain (e.g. in caip19 &blockNumber=eip115:1:1234).
Unicity problem: Is this universally true? I think ETC has a different chainId comparred to ETH. Is the same true for other chains?
Not all chains are represented by a chain ID. Some are represented by genesis hash, for instance BTC and BCH.
If we decide to register the caip:// URI scheme (or something like that, not up-to-date with the latest developments there), then we could leverage the query or fragment components to "restrict" the result of a given URI. This is something the DID standard does, distinguishing between DIDs (which is the actual identifier), and the DID URL (which is used to query parts or specific state of a DID Document).