In -depth understanding of Polkadot cross-consensus message XCM (2)

In a recent episode of the Zero Knowledge podcast, Parity co-founder Rob Habermeier shared how XCM allows parachains to communicate with each other. This article is the second part of the podcast.

AnnaRose

There is a concept called fragmentation. For example, if you use multiple bridges between two chains to connect the same asset, and those assets are composited at one end, then if you have multiple versions of the bridged asset, it can lead to fragmentation. That could open up interesting arbitrage opportunities, but I think it also undercuts a lot of things. You guys have a concept of reserves, is it saying that there might be USDC on Statemine, and then other chains can use it directly through XCM, not through other bridges, it’s kind of like the canonical USDC in the network. Did you envision it this way?

Rob:

Yes, almost. Let’s take USDC as an example. What each chain gets is essentially the statement of USDC on Statemine, so you don’t need to have various wrapped (wrapped) versions of USDC, you only need to use Statemine as a credible USDC token. reserve.

AnnaRose

But if other bridges exist, the same problem will still be encountered. Like if you bridge USDC from Ethereum with another bridge, and you have the Statemine version of it, and both USDCs come, then you will still have the same shards on parachains X, Y, Z.

Rob:

I guess that will be the case. This is something the market needs to deal with.

AnnaRose

Will it be a problem if you have multiple hubs? It’s like you have some kind of canonical asset in Statemine, it moves to parachain A, and then XCM is used to move it further to another chain. Are these hubs causing some problems, or is it always pointing to the original source somehow?

Rob:

Yes. The way this application works is that you always touch the basics of the Statemine/Statemint chain. So any hub actually picks up the reserve asset and then goes out, rather than going directly from one link to another. Teleportation doesn’t work that way, but it does in reserve asset transfers.

AnnaRose

OK And you mentioned trusted transporters, does that mean the parachains themselves are trusted, is it that you whitelist some parachains for transport, but maybe there are other parachains that you haven’t whitelisted still Send something, you just don’t approve it. I actually don’t understand how you make it believable.

Rob:

Well, for example, in the Polkadot and Kusama ecosystems, the trusted transmitter chains of DOT and KSM are what we call system-level public interest chains, such as Statemint/Statemine, so only they are trusted by Polkdadot governance can be correct Mint and destroy DOT/KSM chain.

You might be able to build some kind of side channel or something, and one of the other features of XCM is that you can make arbitrary function calls from one chain to the other, so you can imagine two chains building a protocol through which they mint/ Destroy each other’s tokens. It depends on the governance of ecological parachains, which can decide which other ecosystems they trust to properly mint and burn their tokens. This is what I mean by “trusted”, which is not allowed unless approved by the governance of the issuance chain.

AnnaRose

I don’t understand where this process happens. Is this rule built into XCM? Like it says that the parachains can make this choice, or that the parachains themselves can decide this and exclude other chains. And I don’t understand how they exclude other chains.

Rob:

It mostly depends on what the classification of the token is. Because tokens, such as some on parachains, are usually used to issue some kind of service or process on the chain. Importantly, the tokens you own on another chain are, through a series of operations, a valid claim to those services or underlying assets stored on the issuing chain. To this end, for the issuing chain, the off-chain tokens must ultimately be identified as their own. Well, if it’s through the reserves method, then it always keeps track of the balance and knows exactly how much each other chain has. If it’s teleportation, like a chain comes to me and says, “I have a thousand of your tokens and I want to teleport”. You don’t have the power to do that, I don’t recognize these tokens. This means that tokens that exist on another chain are effectively worthless, they do not actually correspond to a claim to a service or asset.

AnnaRose

But how do you stop this? I was thinking if it was a smart contract parachain and a smart contract could be created, it would be like acting as one side of the bridge. Maybe that’s where I’m getting it wrong, I’ve always thought it’s like a smart contract, there’s also a smart contract on the other side, and the two can talk to each other, but maybe XCM actually works differently? Am I misunderstanding how teleporters work?

Rob:

First, you can build any kind of protocol on top of XCM because it supports any Turing-complete function call. One of the things it can do is support a fee payment mechanism, just like gas fees are paid on other chains. But when it comes to reserve assets and transfer assets, what is the priority in XCM. The way we approach chain design with Substrate is modularity. You have different components, such as a smart contract execution component, a governance component, etc., packaged together to form your chain, and one of these components is the XCM executor.

XCM is actually a programming language, it’s not a Turing-complete programming language, but it is. There is also a cross-consensus virtual machine, XCVM, to execute these instructions. When you make a chain written in Substrate use XCM, what you do is connect XCVM to your chain and make it part of your chain. You say “this is the thing that handles incoming XCM commands, it executes commands given to it by other chains”, and I’ll go ahead and pass some of that. Like for this function call, you might create some kind of custom adaptation, like “treat function calls as smart contract calls”, or you might say “treat them as buy orders”/”treat them as sell orders” and many more. So it’s pluggable, you can plug your own logic into it, you can bring this base level VM into your chain.

AnnaRose

Does XCM or XCVM have built-in whitelists and blacklists, does it already decide “this is a parachain, this is a native parachain token, they are allowed to exist in those places”. I don’t think so, I imagine it should be more permissionless? Kind of like each chain can decide who they feel is a trustworthy transmitter. I just don’t understand why you can’t inject these tokens into this new parachain, how do you prevent it? Because it seems to be permissionless.

Rob:

This is a good question. It’s a workaround on how one chain references and identifies another. So there is a concept of a source, the originator of a message. If you only look at a smart contract system, the source is its account. On Ethereum, they are called 20-byte hex strings, either a hash of a public key, or a hash of a bunch of contract creation parameters. So now, when you’re talking about receiving messages from other chains, you need to know which chain to receive from, and which account on that chain to receive messages from, and that’s how you do permissions. If you get a message, you will verify certain sources to do different things.

The origin system works a bit like a file path or URL. There is a universal source, kind of like the whole world. Then you have consensus mechanisms in it, like Polkdadot or Kusama, like sovereign zones. Then there are parachains below, and then there are accounts below. Chains are more flexible in how they determine their own origins, such as what their origins on the chain have, depends on them. You can make smart contracts a valid source of the chain, since this is just a sub-source of their own chain. One of XCMP’s responsibilities is to maintain the source – a message from parachain A and sent via XCMP to parachain B, which receives the data and the source of the message.

You can also have relative sources. For example, if I want to mention my neighbor, I don’t need to say which country, which town, which zip code, I just say “that’s Joe who lives three houses away from me”. So you can do the same thing with sources, i.e. relative sources, like “this is from parachain X within your sphere of influence”.

Coming back to how chains actually prohibit transfers, essentially what they can do is they can configure which sources are allowed to transfer assets to them. So I would say “I believe Joe will burn tokens on his side and send them to me”. But if I get a message from Bob, Alice, or Eve that says “Hey, I’ve burned tokens on my side, get this to your account”. I would say “I never gave you the keys to my house, who are you?”

Joe has no authority to give Alice, Bob or Eve my keys. This permission is non-transitive because ultimately these tokens must be recyclable on my chain. Now Joe can do silly things, so Joe has the ability to burn and mint tokens on his side. He could create a system with more tokens and derivatives on top of that, allowing other chains to participate, but that’s Joe’s business. If we don’t feel Joe is capable of doing this well, then we shouldn’t have given him the ability to mint and burn tokens in the first place.

AnnaRose

But just in case Joe does a really bad job and the derivatives get out of his control, they’re all over the place. Is it like another chain can go to get the derivative, and then take it back to you and say “this is from Joe”, will there be such an interconnected source? Can the original parachain really identify that the source is malicious? Or will it accept it? Like it’s a derivative-based derivative, it’s a synthetic asset, but it’s from Joe.

Rob:

I think your question might be, can they trick Joe into doing something wrong? Because actually if someone came to me and said, “Hey, I have a derivative of your token, please credit your token to my address”. I won’t do the same because that’s a different token. So they can only trick Joe into doing something wrong with these derivatives. But you can actually have other defensive measures, such as tracking the total issuance of tokens at the earliest, to ensure that it will never be over-issued, and there will be no infinite money printing.

If you use a teleportation-based system, once this thing enters the wider, complex, Turing-complete ecosystem, you can’t keep track of who claimed what and where. This is why transfers should only be used in rare cases, and the default should be to keep a reserve balance at all times. A parachain may become a reserve chain for its own token, which is a pattern we are seeing emerging; for secondary tokens issued on other chains that are not the primary token of that chain, you can use Statemint or Statemine, or use smart contracts to reserve assets in your own chain.

AnnaRose

I’m wondering if there is such a thing as ERC-20, is there XCM-20?

Rob:

There is the XC-20.

AnnaRose

What if there was something like ERC-20 on these existing parachains? So for parachains, they have their own reserves and base tokens. But if you build something on top of it, does that create more problems? Or can the reserve still exist on the first chain that deploys it?

Rob:

This is actually a design decision, up to the developer of the smart contract. But we are seeing some standards starting to emerge, like ERC-20 plus extras that are necessary to make tokens more compatible with the XCM environment and cross-chain native types. But any method has advantages and disadvantages. If you use smart contracts as reserves, you may end up paying more for gas. Whereas if you have a chain dedicated to reserves, reserve operations will be relatively cheap, but they exist elsewhere outside the actual logic of the token. So these are decisions that cross-chain app developers must make.

AnnaRose

I’m trying to keep up with your train of thought. Maybe I’ve done too many interviews before, I always imagine it’s like a bridge, like going from point A to point B, but in Polkadot it’s tied to the whole consensus, not just a message, More than just a token transfer. Can you help me sort out how the message goes from side to side and back?

Rob:

This is one of the reasons we differentiate between the messaging layer and the message itself.

AnnaRose

By the way, I know I’ve been confusing XCM and XCMP all the time, sorry for the audience.

Rob:

That’s why we’re considering changing the name. That’s why it’s important to make these decisions, because whenever you’re engineering anything, you’re going to use a black box. You need to understand your tools, what they do, not necessarily all the intricate details of how they work.

From the perspective of the person developing the app, it doesn’t really matter how a message is delivered, all you care about is whether it arrives, how fast it arrives, and how much you have to pay for it. And these things are abstracted into the XCMP protocol, and we guarantee that the message will indeed arrive. Except in some corner cases where the parachain fails, like the parachain’s lease ends and is not renewed, or they close the channel, then some messages at the end may be discarded. But in most cases, as long as both chains are up and the channel is still open, the message will arrive, and within a few blocks.

So you can have any kind of confirmation or callback or whatever you need to build on top of the protocol. So one of the cool things about XCM is, as I mentioned, it’s a programming language, so you can write If-Then, or If-Then-Else, i.e. I would try to do this, and then If it’s successful, I’ll do another thing, which is to send a message back. Or you can do Else, i.e. if it fails, then do another thing. You can string together these long sequences of conditional instructions that need to be executed on some remote chain. So it’s essentially like you’re programming another chain to do something, and you can build a bunch of more complex protocols on top of that.

AnnaRose

Wow, does that mean you don’t have to program on both ends? I’m obviously still used to thinking in a smart contract model, is it similar to if you have a smart contract platform, you’ve created a contract that interacts with XCMP. You can program this to do something on the other chain, but you don’t have to deploy anything on the other chain. Could you also just use this programming language to go on another chain and do something and bring back whatever you need.

Rob:

You can do a lot of things with it, right now it’s not Turing complete. One of the reasons for this is fee payments, because then you can predict ahead of time how much you will actually have to pay to the other chain to execute all the instructions you send, but you can build multipurpose applications that only use XCM program.

AnnaRose

There is no need to deploy something on another chain.

Rob:

right. I mean, that’s what it’s for, because if we look at our design philosophy, we don’t want smart contracts on every chain. Then you need a way to execute conditional logic on a chain that is not a smart contract platform.

For chains that are themselves smart contract platforms, you may have less complex XCM programs to interoperate with them, since the logic can be handled by your smart contracts sending messages on the receiving chain. But for chains that just do basic things, you can leverage XCM for more complex interactions with chains that do have conditions.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/in-depth-understanding-of-polkadot-cross-consensus-message-xcm-2/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-06-10 11:28
Next 2022-06-10 11:30

Related articles