search

freeverseio / laos

GNU General Public License v3.0
15 stars 5 forks source link

Proposal for Universal Location format across blockchains #177

Open tonimateos opened 7 months ago

tonimateos commented 7 months ago

Universal Location Format Across Blockchains

Objective

This specification defines a format for dApp developers to reference assets within consensus systems without a shared parent. To limit the scope, the task focuses on defining the string that should be returned by the method tokenURI of an ERC721 in Ethereum to refer to a resource in a Parachain in Polkadot, and vice versa.

Final Recommendation

The conclusion, based on the rationale described below, is to propose the following Universal Location Format for referencing ERC721 tokens across different consensus systems in an unambiguous way, adhering as closely as possible to the XCMv3 format:

uloc://GlobalConsensus(networkId)/Parachain(paraId)/PalletInstance(evmPalletId)/AccountKey20(smartContractAddress)/GeneralKey(tokenId)

where:

Examples

Considerations

This format is chosen for its compatibility with the existing ecosystem and its adherence to established practices within the XCM format and Polkadot community. However, it is recognized that this format may evolve as the technology and requirements of the ecosystem develop. We are committed to ensuring that future versions remain compatible and continue to serve the needs of dApp developers and the broader blockchain community.

As blockchain technology continues to advance, the necessity for such standardized formats becomes increasingly vital for ensuring seamless interoperability and efficient asset management across diverse blockchain systems. This Universal Location Format is a significant step towards achieving these objectives, and we welcome further discussion and refinement from the community to enhance its utility and adoption.

Rationale

MultiLocation Format

The rationale for defining the Universal Location string should leverage the already-in-use MultiLocation format within the Polkadot ecosystem, notably since version 3 of Cross-Consensus Messaging (XCMv3) was introduced.

MultiLocation is designed to identify any single location within the world of consensus, always relative to the current location; it is hierarchical in nature.

The MultiLocation struct in Rust is defined as follows:

pub struct MultiLocation {
    pub parents: u8,
    pub interior: Junctions,
}

This specifies the number of levels to go up until a shared parent, and then the junctions or how many levels we go down.

Example

image

I am in ParaB and I wish to locate AccountId32 from ParaA the MultiLocation would be: ../Parachain(1000)/AccountId32(0x00..)

More info on MultiLocation format can be found here:

Universal Location

Background & References

Conceptual Basis of Universal Location

Technical References

Proposed Universal Location Format:

Following the XCM format and the above example, a universal location for a specific location (e.g., ../PalletInstance(3)/GeneralIndex(42)) on the Kusama network could be GlobalConsensus(3)/PalletInstance(3)/GeneralIndex(42).

Essentially, a universal location format is a Multilocation with no parents, starting with the GlobalConsensus junction.

NFT Identification

Understanding MultiAsset

Before using the Universal Location format for NFT identification there is another type on XCM that does just that, This link discusses the use of Universal Location for fungible/non-fungible assets. The MultiAsset type is as a wrapper of the MultiLocation type that adds the ability to specify the fungibility of the target.

This is the relevenat MultiAsset struct in Rust.

pub struct MultiAsset {
    pub id: AssetId,
    pub fun: Fungibility,
}

To identify non-fungible assets in a concrete and unambiguous manner, a MultiAsset value is represented by an assetId, which is a MultiLocation (in this case, a universal location) and the type of fungibility.

The problem with the MultiAsset format is that it does not specifies a string format, unlike the MultiLocation/UniversalLocation case.

There are two ways we can go forward either by implicitly assuming that the Universal Location as a tokenURI is pointing to a non fungible token, or by creating a new format that explicitly states it.

Proposal for NFT identification

Option 1: Implicit Universal Location Format

Keeping the format as a "pure" universal location without additional tags. That would mean that the tokenURI returned within a Parachain will always implicitly assumed to be an Universal Location that points to a non fungible asset.

Examples

Option 2: Explicit Asset and Fungibility Tags

Adding new junctions tags to the Universal Location format to indicate that it refers to an asset and its fungibility type. However, this approach might result in interpretations misaligned with the XCM format and established Polkadot community practices, as it would deviate from the current XCM implementation.

Examples:

Prefix tag

It is recommended that the returned string includes a URI prefix signifying that its format adheres to the hereby specified Universal Location Protocol, ensuring proper recognition and processing within blockchain-related applications. We propose the uloc:// prefix.

Scheme Significance
http Hypertext Transfer Protocol
https HTTP Secure (HTTP over SSL/TLS)
ftp File Transfer Protocol
mailto Email address
file Access to local file system
data Embed data inline (base64 encoded)
tel Telephone number
sip Session Initiation Protocol (VoIP)
ipfs InterPlanetary File System
uloc Universal Location Protocol
franciscoaguirre commented 7 months ago

What does this propose? Only a string representation for XCM locations and assets?

The absolute location of any place is exactly as was described: A location with no parents that starts with the Global consensus junction.

XCM uses the string notation with .. indicating parents for lack of a better one, but it seems it is sufficient. There's no string representation for an asset's fungibility only because it has not been needed. Using nft (and ft maybe?) to indicate fungibility sounds okay.

What's the purpose of these strings? The most important thing for a standard is the bytes. XCM already has a way (SCALE) to code the bytes, which would be sufficient. Any string representation can be used as long as those are the actual bytes that get sent.

Also, instead of proposing a new standard, it looks like, and feels like, this would be better off as an RFC to the XCM standard, which can be done from the xcm-format repo