Article: Joe Petrowski, Head of Parallel Chain Team, Web3 Foundation

Translation: OneBlock Community

Most people are used to identifying assets by name or symbol, such as "Tether" or "USDT". If you are familiar with Ethereum, you should be accustomed to the 0x contract address.

In Polkadot, the Asset Hub directly hosts asset functionality in the protocol, using simple integers as asset IDs. The name "1984" may seem audacious, but it is certainly easier for humans to remember (and verify) than 0xdAC17F958D2ee523a2206206994597C13D831ec7.

Now Polkadot has another parallel instance with the same asset functionality, but this instance uses a XCM primitive called "multilocation" to identify assets. Through this explanation, I hope to convey how this feature has created expressive and powerful patterns for asset utilization within the Polkadot network and the assets reachable within the network.

"Multilocation" Identifies Local and External Assets

When the Asset Hub first launched, it only hosted an instance of the Assets pallet, allowing anyone to claim an available asset ID and create their assets. The Asset Hub did not create custom contracts for each asset, embedding asset logic as a first-class primitive. Each asset has the same functionality.

These claimable, integer-based asset IDs are called "local assets". The Asset Hub is primarily used by creators of these assets, typically stablecoins backed by reserves, such as USDT. However, the protocol only enforces the uniqueness of the asset ID (in this case, an integer). Creators can set metadata such as asset symbols. Therefore, users still need to do some due diligence; anyone can name their asset USDT, but users typically want the one created by Tether.

The Asset Hub acts as a "management portal" for asset creators, enabling them to mint and burn tokens and understand the total supply across the entire Polkadot network, including tokens sent to other locations in the network.

However, the asset ID itself is not very expressive. While it is easier to verify than a contract address, the ID does not convey any information to the user about the asset. This is where XCM (Cross-Consensus Message) comes into play.

Multilocations can express relative paths. They are relative to the interpreting location: "How do I get to the supermarket" will have different directions based on the starting location. At the most basic level, these paths represent directions to other chains and can express directions for almost anything: assets, contracts, pallet indices, governance entities, accounts, and so on.

Multilocations have a series of intersections, typically divided into two parts: "parents" and an extended path, for example, "parents: 1, interior: Parachain(9,000)". This indicates "go to my parent, then turn to Parachain 9,000". Here, "parent" is a consensus-containing system. For example, a relay chain is a consensus system containing parachains, and a parachain can be a consensus system containing smart contracts. In this example, the multilocation can come from another parachain, such as the Asset Hub. Parachain 9,000 would be a sibling because they share the same parent, the relay chain.

As an asset identifier, multilocations have significant advantages over absolute identifiers (such as addresses, hashes, integers). First, the multilocation of an asset itself indicates the controlling entity. In the example above, it indicates the governance of Parachain 9,000. When viewing absolute identifiers, users must trust the issuing entity and its claims, such as the one-to-one correspondence between on-chain tokens and off-chain assets. Multilocations contain parachains, smart contracts, or other protocols, which actually indicate the logic controlling the asset. However, this does not mean users can forgo all necessary due diligence; for example, Parachain 9,000 may have a trusted "super user". But multilocations can convey to the user which protocol controls the asset.

Beyond the endpoint of the multilocation, it actually specifies the "command chain". For a longer example, an asset with ID 42 on Parachain 9,000: "parents: 1, interior: Parachain(9,000), PalletIndex(99), GeneralIndex(42)". This asset is controlled by a pallet located within the consensus of the parachain, which is in turn within the consensus of the shared parent (the relay chain). Multilocations can even represent completely external consensus systems, such as "parents: 2, interior: GlobalConsensus(Ethereum)". "From the perspective of the parachain, this means "up two levels (i.e., above the relay chain), then enter the consensus of Ethereum".

These locations are very similar to Unix file paths, such as "../Parachain (9000)/PalletIndex (99)/GeneralIndex (42)" or "../../GlobalConsensus (Ethereum)".

Ultimately, Polkadot's Asset Hub can represent any asset accessible from Polkadot. Whether through local pallets or contract calls, XCMP, or bridges, native protocol tokens or local assets from other chains, the Asset Hub provides a common interface for all assets, and the identifier of the asset conveys its sovereign location.

Two Types of Asset Transfer Relationships: Teleports and Reserves

The XCM language has two ways of expressing asset transfer relationships for location/asset pairs: teleports and reserves. These define the relationships between the Asset Hub and other chains and how they interact.

Teleports are simple. When two chains trust each other with a given asset, the sender can simply destroy it and issue an instruction to the receiver to mint it. As long as the sender trusts that the receiver will not mint more than the amount sent, the sender can accept the same teleport instruction.

Reserves are more complex. When the chain of origin does not trust another chain, it can place the asset in the target chain's sovereign account and send a message to the target chain indicating that the asset has been recorded in its local account. The target chain can then mint derivative assets for its users. After the reserve is completed, the target chain can send a reply message instructing the source chain to move the asset out of its account (assuming it has destroyed the corresponding derivative assets).

In the case of reserves, the trust relationship is one-way. The chain minting derivative assets trusts the issuing chain to maintain its sovereign account balance and respects redemption. However, the issuing chain does not trust the target chain to handle the assets truthfully.

One point to note here is that the trust relationship exists within the location/asset pair: that is, one chain can trust another to teleport certain assets but not trust to teleport other things.

So, who trusts whom? What do entities trust? Entities always trust the "parent" in their multilocation example. For example, a smart contract on Parachain 8,000 trusts the governance of Parachain 8,000, while Parachain 8,000 trusts the Polkadot relay chain. The Polkadot relay chain is governed by the "root origin", which can execute any instruction, including kicking out parachains. The root origin of Polkadot also manages all its system parachains (in fact, the relay chain plus all system parachains can be seen as a single "Polkadot protocol").

All chains and sub-protocols (such as smart contracts) in the Polkadot network trust the Polkadot protocol, so they should be able to teleport assets with the protocol. In fact, using reserves would be very foolish: if the Polkadot protocol does not like the reserve balance on its origin chain, it can directly rewrite it to its liking through a root origin referendum.

On the other hand, the Polkadot protocol cannot extend this universal trust to its members. However, it can trust a location to manage assets originating from that location. The protocol can trust Parachain 9,000 to manage its native token (PNT, "Pint"?) as well as assets created within it, such as locally issued tokens. Therefore, when interacting with Parachain 9,000, the Asset Hub will teleport PNT to acknowledge that PNT originates from that parachain. And for Parachain 9,000, the Asset Hub will use reserves for PET (Parachain 8,000's token, pronounced less ambiguously) transfers.

Asset Hub as a Reserve Location, Enabling Infinite Asset Interactions

The creation of PET is controlled by the governance of Parachain 8,000, which accepts governance from the Polkadot protocol. Therefore, Polkadot naturally trusts PET from Parachain 8,000, as PET is part of the Parachain 8,000 protocol. However, both Polkadot and Parachain 8,000 do not trust other parallel chains* to act as reserve locations for PET.

(*Note: However, it could also choose to trust: Parachain 8,000 may have other sibling parachains that recognize its governance origin, just as many system chains recognize the Polkadot OpenGov origin. In this regard, it is best to consider sovereign systems that can contain multiple chains, rather than individual chains.)

This concept extends along the command chain to other assets created within Parachain 8,000. In fact, this has nothing to do with independent chains or asynchrony; two smart contracts on the same chain may not trust each other to manage each other's assets, but they both trust the chain they exist on.

Given this bidirectional trust relationship, the Asset Hub can act as a destination for reserve assets. Parachain 8,000 can teleport its PET to the Asset Hub, and then the Asset Hub can act as a reserve location for transfers between other locations. This means that Parachain 9,000 can use the Asset Hub as a reserve location for its PET to send to other parallel chains.

However, these other locations can now consider both Parachain 8,000 and the Asset Hub as reserve locations for PET.

In practice, protocols (such as parachains, smart contracts, etc.) that wish to use the Asset Hub in this way will need to manage multiple reserve locations for a given asset. In fact, this may mean selecting a reserve location for each asset, and common protocols and standards between parachains and other protocols will simplify their interactions.

With thousands of protocols in the Polkadot network, establishing communication channels with all protocols is cumbersome, impractical, or unfeasible. Just because a protocol does not want to establish communication channels with every protocol, it may still want free access to assets. Since the Asset Hub can represent and act as a reserve location for any reachable asset from the Polkadot network, not just internal assets of the Polkadot network, the Asset Hub can act as a single reserve location from which a protocol can manage and interact with almost an unlimited number of assets.

Code Implementation: Transferring Parallel Chain Assets to the Asset Hub

Let's look at an example of how to write an XCM program to transfer assets from a parallel chain to the Asset Hub. For developers looking to add this logic to a parallel chain, there are two key points to note.

First, the execution of the XCM program is from the perspective of the executing program instance, not the origin of the program. This means that the application should send a program from the perspective of the Asset Hub, referencing the assets and locations.

Second, paying fees may not be straightforward. When transferring DOT between system chains, or using reserve instructions for chains holding DOT in sovereign accounts, these applications can use the assets they are transacting with to pay fees. However, the Asset Hub may not accept the application's assets for fee payment, so the application will need to pay fees with an acceptable asset. Adding asset conversion will make this process simpler and more flexible, but the chain still needs to initiate trading pairs that can pay fees.

First, define some assets: DOT and the native assets PINTs of Parachain 9,000, as well as the beneficiary to receive the assets:

Before constructing the program to send to the Asset Hub, the sender needs to account for the assets they are teleporting. A chain can also configure its XCM executor to handle this more gracefully.

Now, let's start building the XCM program to send to the Asset Hub:

This program will withdraw DOT from the parallel chain's sovereign account to purchase the weight required to execute this program, receive the teleported PINTs, refund any unused weight, and finally deposit the changes of both assets (withdrawn DOT plus received PINTs) into the beneficiary's account.

Please note that the sender may need to do some accounting work before sending this message. This type of program construction should not be directly provided to users, but should be offered after appropriate checks of external programs. It is almost certain that the sender is not a trusted teleporter of DOT; instead, the sender may be teleporting two assets and may not hold DOT in its sovereign account for withdrawal.

This means that their local chain may have a derivative DOT supported by reserves. Extracting this DOT from their sovereign account and transferring it for fee payment, the beneficiary will reduce their reserves. Therefore, the sender should destroy this reserve-supported derivative before sending this message, to avoid their chain not having full collateral in reserves. The sender can deduct from the user initiating the teleport, or retain their own DOT pool for withdrawal (occasionally replenishing reserves). For a more complete example, see the accounting completed in Trappist:

?https://github.com/paritytech/trappist/pull/266?ref=cms.polkadot.network

Conclusion

Adding external assets to the Asset Hub opens up a new paradigm, such as using multilocations as asset identifiers and multiple reserve locations, enabling expressive and convenient interactions within the network.

Parity will release more examples and tutorials in the coming months to showcase common patterns for using external assets. Parallel chain developers should keep an eye on Trappist on Rococo, while wallet/integration developers should focus on the asset transfer API:

?https://github.com/paritytech/asset-transfer-api?ref=cms.polkadot.network

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。