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;
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
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.
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.
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.
Coming from a background of Computer Science and Cinematography, I've found my niche in this space, blending technical know-how with storytelling.
Much as films tell stories, blockchains craft their own narratives, complete with innovation, culture, believers and emotions.
In this space, I connect the dots, bridging the gap between technology and story, making it relatable for everyone.
As a filmmaker in real life with a background in computer science, here I am, primarily conducting research in this wild wild space.
Often agnostic in my interests and inquiries, I regularly delve into cross-research, exploring both past and future narratives, trends, and developments in the broader blockchain space.
And in this particular space, I try to connect the dots, bridging the gap between technology and story, making it relatable and digestable for all.