XCM V3 and beyond - Polkadot Decoded

Here is the recap of Gavin Wood’s presentation from Polkadot Decoded’s last day.

He listed his presentation in three topics;

• A philosophical commentary about today and future

• Parity tech, Web3 and Polkadot

• XCM, XCM v3 and beyond

First Part- Really philosophical and abstract talking/ so take it as you wish:)

He defined thoughts on value-knowledge correlation.

When thinking about time in short and long term. When thinking about information source judged based on facts and people; “trust”.

Instead of making any claims he went with brainstorming added with his belief

Such as; People have different comfort/effort levels for trust or truth.

People don’t all think in the same time-period consistently. And with time passes, “someday” become now- “current”.

His takes on that is: The facts are not complicated instead they are simple and this technology could very well be as vital an addition to human civillisation as rule of itself. If we expect to avert dystopia in the tech age, it is invaluable.

Instead of a short ride, he rather envision a long ride.

Second Part - Thoughts on Ecosystem ; Parity Engineering, Parity Labs and Web3 Foundation

It is not a point to architect and build a vertically integrated model/product/company/enterprise with Parity nor Web3 Foundation. This is not a Microsoft-like vision.

With Parity Engineering, it is about building the core tech such as subsrate, Frame, Polkadot protocol design, engineering and nodes, limited & selected core features.

With Parity Labs, it is about connection and prototypes future Polkadot tech between Web3 Research and Parity Engineering

With Web3 Foundation, it is about ecosystem evangelism, education, grants&support and deep research

All together these means;

• Opportunity

• Flexibility

• Innovation

If one company does everything this, it compromise for things at some level at some point. You lose decentralisation, reliability, robustness, resilience and therefore long term success.

If you label and tag an ecosystem where it will go, where it will end; if you give a manuel as one optimal solution; these are not innovation.

Therefore, Gavin Wood deeply emphasized that they just don’t wanna see just one of

• Wallet

• NFT project

• Contract platforms

• Contract languages

• Chain Explorers

• Indexers

If anyone wants to change, upgrade, propose or build something, just do it. Never afraid to do it.

Don’t ask for permission because there is no authority to decide on that.

In that sense their role in this play is to build a strong, extensive and inclusive ecosystem by providing;

• Teach ( Parity Academy, Devhub, Web3 Research

• Open development on Github and internal channels

• Open discussions on Parity forums

• Support via grants, governance and facilitation

**Third Part -**XCM, XCM v3 and beyond

XCM is a living standard. But what it is actually, what it does and what it lacks.

XCM is a language for consensus for systems to make themselves understood between each other. Not even necessarily for chains.

Thinking XCM as a language that can be spoken in a call; while XCMP is like a kind of telephone.

And there can be many kinds of telephone.

• between sibling parachains

• VMP: between parachain and relay-chain

• GPMP; Grandpa protocol message passage; between subsrate chain and relay chain’s parachain and relay chain itself

• SCMP: Subsrate chain and smart contract

  and so on.

XCM Version 3features focuses on Programmability, Functional multichain decomposition and bridging.

By Programmability Features; allowing xcm messages to express and execute more sophisticated concepts such as expectations and branching; introspection and safe dispatches and asset exchange & NFTs

By Multichain Decomposition Features; allowing mechanisms to be built whose logic is spread over multi chains which is essential for Polkadot’s long term vision to be a functionally minimal Relay

Providing Remote locking. In situation’s like One chain use an asset exist in another chain and requesting that another chain to lock an asset.

By Bridging Features; allowing XCM to function transparently over bridges and other multi-hop routes.

Providing the universal location. Before XCM, you had to assume; you were in the location even this location is already in another consensus situation. With Universal location; a new and unique location defined as the parent of locations which generate their own consensus and by extension the only location which has no parent. It contains all consensus systems and by extension all conceptual locations held in global consensus.

XCM v3 Vision

A vision to use facilities on other networks through XCM. Including the defined Polkadot fellowship on yesterday’s presentation about Governance v2;

• to help oracilizing information regarding time integrality and safety;

• Bridging Polkadot and Kusama;

• Using XCM oracilized onto another network;

• Building rich application across shards, parachains and whole across ecosystems.

  These are all XCM v3 is intended to.

But there are issues XCM can not solve. Not because of the language, because of TRUST.

For example:

When a user on Phala wants to send AUSD to Moonbeam contract for execution.

AUSD is held as a reserve asset on Acala.

Phala, Acala and Moonbeam don’t trust eachother

What they do?

Phala (on behalf of user) sends message to Acala instructing transfer of AUSD to Moonbeam and then notify Moonbeam to credit Phala user’s account on Moonbeam with local AUSD

And then Phala (on behalf of user) sends message to Moonbeam instructing the execution of desired contract

It can not be done as Phala just sends message to Acala instructing transfer of AUSD and at the same time execute desired smart contract with it. Because of TRUST.

Message has to go as

Phala → Acala

Acala → Moonbeam

Moonbeam does not trust Acala to authorise instructions to be taken on behalf of Phala user and only Phala can speak for its users. In the end these are all independent seperate chains and Polkadot can not do or change anything with a chain.

Sending two messages as in this example defined provides communication and executions safely but it creates race condition, 2 signing steps and bad performance

To overcome this Trust issue, They will push forward SPREE (Shared Protected Runtime Execution Enclaves); trust wormholes.

SPREE

By this: They can add business logic that guarantees a message from certain point is not destined to you; instead it is destined to someone specific by providing final message is not tempered and not duplicated.

• These fragments have their own Seperate Wasm stack, heap, storage and channels for Parachain runtime and each SPREE runtime

• All instances across parachains have identical logic.

• It executes alongside parachain logic.

• Protected: storage can not be altered by parachain logic; messages can not be faked from them by parachains.

• Fast, synchronos message passing between runtimes

So that, regarding the example above;

Now messaging goes as:

Phala → AcalaSX (Involves Acala)

AcalaSX → MoonbeamSX (Involves Moonbeam)

sx refers the SPREE enclave for XCM

And this is in research and design phase yet. It is planned prototyping to begin this year though.