Open okwme opened 3 years ago
Problem: CAIP-19 AssetID current formatting doesn’t provide much consideration for multi-hop assets with IBC
Proposed Solutions:
My personal conclusion of these 3 solutions could be defined in a table as follows: Approach | Readability | Registry Requirement | ID Format | Bandwidth Requirement | Provenance Guarantees |
---|---|---|---|---|---|
Ticker-based | easy | yes | short | low | low |
Multi-query | hard | no | short | high | high |
Single-query | hard | no | long | low | low |
Keep in mind that these asset namespace approaches are not necessarily exclusive as they can be used in parallel as different applications will optimize for different use-cases
After discussing it with @antoineherzog on the ticker-based approach he clarified that the solution is actually intended for the assets issued at their native chain and not necessarily to tackle the multi-hop assets. So the ticker-based could warrant it's own namespace similar to SLIP-44 but with improved readability
Regarding both multi-query and single-query approaches to multi-hop assets, from my POV I can see the being referenced with CAIP-19 as follows:
Requires specification of an ICS standard to determine asset resolution from the chain. Let's call it ICS-30 which will map to the asset namespace ics30
. Let's say that standard defines an endpoint called getOriginAsset
that returns if the asset has been minted from an IBC transfer and if so it would return its origin assetId.
Example:
we have asset with denom abc
and it was natively minted on cosmos chainId yolo-chain
and therefore it would have a CAIP-19 assetId cosmos:yolo-chain/ics30:abc
when you query the endpoint getOriginAsset
it would return a falsy value indicating that this asset is indeed native to this chain
now let's perform an asset transfer of the asset abc
to another chain with cosmos chainid carpediem-mainnet
and it will mint this asset in its own chain with the denom yabc
therefore it would have a CAIP-19. assetId cosmos:carpediem-mainnet/ics30:yabc
when you query the endpoint getOriginAsset
it would return a truthy value with the respective assetId of the native chain (cosmos:yolo-chain/ics30:abc
)
cosmos:carpediem-mainnet/ics30:yabc
-> carpediem-mainnet.getOriginAsset("yabc")
-> cosmos:yolo-chain/ics30:abc
-> yolo-chain.getOriginAsset("abc")
-> undefined
This way we make two queries to complete the full provenance of the asset with guarantees of the whole path is live all the way to the native chain. This increases the network bandwidth but also shortens the id format
Requires specifrication of an CAIP standard to define how multi-hop assets should be formatted with the whole provenance detailed on the ID itself. Let's call it CAIP-30 which will map to the asset namespace caip30
. Let's say that the last asset at the native chain is specified with the namespace denom
as it reached the origin of its provenance
Example: let's use the same asset denominations and cosmos chainId's specified above for this example as well
CAIP-19: cosmos:carpediem-mainnet/caip30:cosmos:yolo-chain/denom:abc
the advantage of the single-query approach is that reduces the network bandwidth to evaluate the provenance of the asset since it's clearly specified on its longer format id
Josh proposed a single-step solution that required only querying the origin chain since the long format ID would be able to reduce bandwidth requirements and be more decentralized as wallets can easily query a single chain directly
That is not technically feasible unless you use a relayer service. For example, consider a token that has been sent A -> B -> C-> D. Chain D that received the token might not be connected to chain A, so any query would return not found. Even in the case that they are connected, the path representation between each chain could be fundamentally different. I wrote some UX suggestions for clients on the ICS 20 - Fungible token transfer spec.
I really like your approach Pedro of Multi-Query. It is really simple and beautifull.
Following this conversation, I have a question which pops into my mind (maybe the question is more an IBC question): What happens to all the linked blockchains and their respective assets if a blockchain decides to rename his native mint asset from cosmos:yolo-chain/ics30:abc to cosmos:yolo-chain/ics30:bettercooltickername
Does it break all the dependencies like everything?
Pedantic example, but how would something like the following be represented?
BTC
via renBTC to Ethereum
via Peggy to Cosmos Hub
via IBC to Kava
BTC via renBTC to Ethereum via Peggy to Cosmos Hub via IBC to Kava
BTC via renBTC would essentially be a ERC20 then via Peggy it would be minted as the fictional ICS30 asset denom on Cosmos Hub which then would refer to another ICS30 denom on Kava
Essentially the assets would refer different namespaces from their origin
slip44 (BTC) -> erc20 (renBTC) -> ics30 (cosmosBTC) -> ics30 (kavaBTC)
we're gonna need a lot of room on the screen to show the wrapped path
For IBC assets this is pretty straight forward, but there are some weird edge cases that I'm not totally sure how to handle. For instance renBTC actually uses a separate blockchain to assemble secret fragments, so is BTC first "transferred" to the Ren blockchain or directly to Ethereum? Or what if someone uses state channels to transfer an asset between chains. Is this a direct transfer? Or Celer, which also has a blockchain that "co-signs" events? Solana is even considering using its base layer chain to record rollup transfers that would then ultimately be settled on Ethereum. Not to throw a wrench in things, rather trying to think through how best to generalize.
Began discussing this topic within the document for the Interchain UX working group here.
Basically CAIP-19 identifies an asset by its origin but doesn't include anything about whether the asset is being accessed in it's native setting or in a new setting, reached via bridges or IBC. An ATOM that is on the Cosmos Hub is similar but fundamentally different from an ATOM that has been moved to Kava via IBC. It is also different from an ATOM which has been moved to Terra after being moved to Kava. There will likely be multiple bridges to the Cosmos ecosystem from Bitcoin and Ethereum, which means there will be different versions of Eth and BTC that have different features and security assumptions based on the path they took.
This information is important for a user to understand for the sake of valuing the assets properly, but also for client software to understand how to interact with the assets.
Should CAIP-19 be extended to contain asset path information? Should there be a new CAIP for asset path resolution? What should be the recommended method for resolving an asset's path? What should be the recommended method for user interfaces to display the different varieties of non-native assets?