User feedback: No way to address a specific transaction
bumblefudge opened this issue · comments
In the past, we've discussed block heights (whether as a new CAIP or as a "query parameter"). A more fundamental use case might be addressing across multiple namespaces a specific transaction, i.e. on both sides of an atomic swap or bridging transaction.
Another possible use-case, whether for the same or a separate CAIP, would be addressing the metadata of a specific transaction, such as transaction type, or even arbitrary metadata like input data, method calls, memos, etc. This could a path (i.e. another : followed by, say parameters[0] in the case of input data), a query param, or a separate CAIP. Would like to hear from more implementers before committing to anything that might be un-profilable or un-implementable on many namespaces, tho!
Perhaps related issue: How would we unambiguously address miner's/validators messages in blocks, i.e., The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.? straightforward pathing bip122:000000000019d6689c085ae165831e93:666666:op_return or bip122:000000000019d6689c085ae165831e93:op_return/666666 by analogy to CAIP-19 syntax ?
Shout out to @sposth for raising this.
To give another example for a potential use case:
ISCC is an upcoming ISO standard for decentralised content identification (ISO/CD 24138), also see: https://core.iscc.codes/ and https://github.com/iscc.
ISCC codes, which are content-derived identifiers and lightweight fingerprints, can be declared together with declaration metadata (that bind product metadata, rights and licenses) on public blockchain networks, e.g. Ethereum, Polygon, for any reason, e.g. timestamping, content licensing, copyright claim, etc.
The input data of the declaration transaction contain the ISCC code and the URI to primary declaration metadata on IPFS, see this example:
This means that the data is on-chain, but it is not stored in a smart contract, resulting in significantly reduced gas costs for content declarations, which might have to do with digital collectibles, compared to the minting of NFTs.
Example:
https://goerli.etherscan.io/tx/0x3edb98c24d46d148eb926c714f4fbaa117c47b0c0821f38bfce9763604457c33
| 0 | iscc | string | KACXDCTNRPRCRYPBDJNYOYLWTRAOKTTCAUS42ZO5T4IZVU467KHHNUY |
|---|---|---|---|
| 1 | url | string | https://ipfs.io/ipfs/QmSBF81KWqGANVCc8AxgRvyoD1kiTjhrc5MypLevJoguV8 |
An ISCC declaration will create a declaration ID (called ISCC-ID), for which we have designed a W3C-compatible 'did:iscc' method, see: https://ieps.iscc.codes/iep-0015/. did:iscc will resolve to the ISCC code, the declaring and signing wallet, and the primary declaration metadata provided with the transaction (see example of did:iscc at https://dev.uniresolver.io/). The registry of cross-chain content declarations is decentralised in such a way that anyone can set up a registry and pull and verify the data from the blockchains and IPFS, see https://iscc.id or https://testnet.iscc.id, which both are run by ISCC Foundation.
See registry entry from the example transaction, above: https://testnet.iscc.id/registry/iscc_registry/isccid/449695081398566975/change/
In my opinion it would be of value to be able to address specific declaration transactions on multiple chains in a uniform way, abstracting out the unique syntax of block explorers, to build a multi-chain index of data stored in transaction metadata.
Cross chain addressing of transactions should be fairly simple with a pattern like:
<chain-id>:tx:<tx-hash>
Examples:
eip155:1:tx:0x1cc5b5193db6f41c6b830660fe6e8e14a4c9bce66381956f065a5584272754b8
bip122:tx:f1d481508ce99ade1427b581ce0e240dd7258358bbfdee89ed08450de23c5e6c
Another possibility, to make references much shorter, one could take advantage of blockchain immutability and total ordering and use an index/location based addressing scheme:
<chain-id>:tx:<block-height>:<tx-index>
The above examples would be reduced to:
eip155:1:tx:15670909:268
bip122:tx:635359:1110
On UTXO chains you could also reference specific outputs (like an OP_RETURN) within a transaction by index:
<chain-id>:tx:<block-height>:<tx-index>:<output-index>
Example:
bip122:tx:635359:1110:0
would point to the first output within the transaction (an OP_RETURN in this case):
https://mempool.space/tx/f1d481508ce99ade1427b581ce0e240dd7258358bbfdee89ed08450de23c5e6c