Meddelandehantering med Cross-Consensus (XCM)
Apr 14, 2022
Introduktion
Polkadots arkitektur gör det möjligt för parakedjor att samarbeta med varandra, vilket möjliggör överföringar mellan blockkedjor av alla typer av data eller tillgångar.
För att göra detta definierar ett XCM-format (Cross-Consensus Message) ett språk för hur meddelandeöverföringen mellan två samverkande blockkedjor ska utföras. XCM är inte specifikt för Polkadot, eftersom det syftar till att vara ett generiskt och utbyggbart språk mellan olika konsensus-system.
Den här sidan är en kort introduktion och översikt av XCM och andra relaterade element. Mer information finns i Polkadots wiki.
Allmänna XCM-definitioner
— XCM — står för cross-consensus message och är ett allmänt sätt för konsensussystem att kommunicera med varandra.
— VMP — står för vertical message passing (vertikal meddelandeöverföring) och gör det möjligt för parachains att utbyta meddelanden med reläkedjan. UMP (upward message passing) gör det möjligt för parachains att skicka meddelanden till sin reläkedja, medan DMP (downward message passing) gör det möjligt för reläkedjan att skicka meddelanden nedåt till en av sina parachains.
— XCMP — står för cross-consensus message passing och gör det möjligt för parachains att utbyta meddelanden med andra parachains i samma reläkedja.
— HRMP — står för horisontell relay-routed message passing, ett protokoll som är en nödlösning medan ett fullständigt XCMP-utförande lanseras. Samma gränssnitt som XCMP, men meddelanden lagras på reläkedjan.
— Multilocation — ett sätt att ange en punkt i hela reläkedjan/parachain-ekosystemet från ett givet ursprung, antingen relativt eller absolut. Det kan till exempel användas för att ange en specifik parachain, tillgång, konto eller till och med en pall inom en parachain. Generellt sett definieras en multiplacering med en parents och en interior. Parents hänvisar till hur många “hopp” till en överordnad blockkedja du måste ta från ett givet ursprung. Interiören, hänvisar till hur många fält du behöver för att definiera målpunkten. Om du till exempel vill rikta in dig på en parachain med ID 1000 från en annan parachain, skulle multilocation vara { "parents": 1, "interior": { "X1": [{ "Parachain": 1000 }]}}
XCM:s transportprotokoll
Polkadot implementerar två korsvisa konsensus- eller transportprotokoll för att hantera XCM-meddelanden mellan de ingående parachains, varav Moonbeam är det ena:
Vertical Message Passing (VMP) — delas upp i två typer av transportprotokoll för meddelandeöverföring:
— Upward Message Passing (UMP) — gör det möjligt för parachains att skicka meddelanden till sin reläkedja, till exempel från Moonbeam till Polkadot.
— Downward Message Passing (DMP) — gör det möjligt för reläkedjan att skicka meddelanden nedåt till en av sina parachains, t.ex. från Polkadot till Moonbeam.
Cross-Chain Message Passing (XCMP) — gör det möjligt för två parachains att utbyta meddelanden så länge de är anslutna till samma reläkedja. Transaktioner mellan kedjorna löses med hjälp av en enkel kömekanism som bygger på ett Merkle-träd för att garantera tillförlitlighet. Collators utbyter meddelanden mellan parachains, medan reläkedjans validerare kontrollerar att meddelandeöverföringen har ägt rum.
Observera
För närvarande, medan XCMP utvecklas, finns det ett provisoriskt protokoll som kallas Horizontal Relay-routed Message Passing (HRMP), där meddelandena lagras i och läses från reläkedjan. Detta kommer i framtiden att avskaffas för det fullständiga XCMP-implementet.
Dessutom är de två vanligaste användningsområdena för XCM-meddelanden, åtminstone i de tidiga skedena av dess genomförande, följande:
— Asset Teleporting — består av att flytta en tillgång från en blockkedja till en annan genom att förstöra det belopp som överförs i ursprungskedjan och skapa en klon (samma belopp som förstörts) i målkedjan. I sådana fall har varje kedja den ursprungliga tillgången som reserv, vilket liknar en bryggmekanism med brännmynt. Modellen kräver en viss grad av tillit, eftersom någon av de två kedjorna på ett illvilligt sätt skulle kunna lägga beslag på fler tillgångar.
— Fjärröverföringar — består av att flytta en tillgång från en blockkedja till en annan via ett mellanliggande konto i ursprungskedjan som utan förtroende ägs av målkedjan. Detta mellanliggande konto är känt som det “suveräna” kontot. I sådana fall förstörs inte tillgången i ursprungskedjan utan hålls av det suveräna kontot. XCM-utförandet i målkedjan myntar en inpackad (även kallad “virtuell” eller “kedjeöverskridande” tillgång) representation till en måladress. Den förpackade representationen är alltid utbytbar 1:1 mot den ursprungliga tillgången. Detta liknar en överbryggningsmekanism för lås- och myntning/bränn- och upplåsning.
En mycket mer detaljerad artikel om XCM finns i Polkadot Wiki.
Till en början kommer Moonbeam endast att stödja fjärröverföringar. Alla tillgångar över kedjan på Moonbeam kommer att kallas xc + TokenName. Till exempel kommer Kusamas KSM-representation på Moonbeam att kallas xcKSM. Du kan läsa mer om XC-20-standarden här.
Utvecklare måste förstå att om de skickar felaktiga XCM-meddelanden kan det leda till förlust av medel. Därför är det viktigt att testa XCM-funktioner på ett TestNet innan de flyttas till en produktionsmiljö.
Registrering av kanaler
Innan två kedjor kan börja kommunicera måste en meddelandekanal öppnas. Kanaler är enkelriktade, vilket innebär att en kanal från kedja A till kedja B endast kan överföra meddelanden från A till B. Följaktligen kan överföringar av tillgångar endast ske från kedja A till B. Därför måste två kanaler öppnas för att skicka meddelanden (eller överföra tillgångar) fram och tillbaka.
En kanal för XCM mellan reläkedjan och parakedjan öppnas automatiskt när en anslutning upprättas. Men när parachain A vill öppna en kommunikationskanal med parachain B måste parachain A skicka en öppen kanal extrinsic i sitt nätverk. Denna extrinsic är också en XCM! Mottagaren av denna XCM är reläkedjan, och extrinsicen innehåller information som t.ex:
— Destinationen där meddelandet kommer att utföras (i detta fall reläkedjan).
— Det konto som kommer att betala avgifterna (betalas med reläkedjans token).
— Avgifter som transaktionen kan förbruka när den utförs.
— Kodade samtalsdata, som erhålls genom att efterlikna extrinsic på reläkedjan. Detta omfattar följande kodade information:
— — Metod som ska anropas i reläkedjan (öppen kanal).
— — Parachain-ID för målkedjan (parachain B i detta exempel).
— — Maximalt antal meddelanden i målkön.
— — Maximal storlek på de meddelanden som skall sändas.
Transaktionsavgifterna betalas i den kedjeöverskridande (xc) representationen av reläkedjetillgången (xcRelayChainAsset). Till exempel för Kusama/Moonriver skulle transaktionsavgifterna betalas i xcKSM. Därför måste det konto som betalar avgifterna ha tillräckligt med xcRelayChainAsset. Detta kan hanteras på Moonbeam/Moonriver genom att avgifter från inkommande XCM-meddelanden, som betalas i ursprungskedjans tillgång, skickas till statskassan, och genom att använda statskassakontot för att betala för kanalregistreringens extrinsiska kostnad.
Även om parachain A har uttryckt sin avsikt att öppna en XCM-kanal med parachain B, har den senare inte signalerat till reläkedjan sin avsikt att ta emot meddelanden från parachain A. För att få en etablerad kanal måste därför parachain B också skicka ett extrinsic (som också är ett XCM) till reläkedjan. Den accepterande kanal extrinsic liknar den föregående. De kodade samtalsdata innehåller dock endast den nya metoden (acceptera kanal) och avsändarens parachain-ID (parachain A i detta exempel). När båda parachains har kommit överens öppnas kanalen vid nästa epokbyte.
Alla de åtgärder som nämns ovan kan genomföras via SUDO (om det finns tillgängligt) eller genom demokrati (teknisk kommitté eller folkomröstning).
När kanalen väl är etablerad måste tillgångarna registreras innan de överförs via XCM, antingen genom att de integreras i körtiden som en konstant eller genom en pall. Processen för registrering av tillgångar för Moonbeam förklaras i nästa avsnitt.
Registrering av XCM-tillgångar
När en kanal har upprättats mellan parachains (eller reläkedje-parachain) kan registrering av tillgångar ske.
I allmänhet kan tillgångsregistrering ske på en körtidsnivå, vilket innebär att en körtidsuppgradering krävs, varefter tillgången nu är registrerad och stöds av XCM. Moonbeam har dock inkluderat en Substrate-pallett för att hantera tillgångsregistrering utan behov av körtidsuppgraderingar, vilket gör processen mycket enklare.
När en XCM-tillgång registreras måste extrinsic-tillgången innehålla (bland annat):
— Parachain-ID för var ursprungstillgången finns.
— Typ av tillgång. I skrivande stund kan du registrera antingen den ursprungliga parachain-token eller en tillgång som skapats genom Pallet Assets genom att ange dess index.
— Ett tillgångsnamn, en symbol och ett decimalantal.
— Minsta saldo
När XCM-tillgången har registrerats kan enheterna per sekund för utförandet fastställas. Detta är ett mått som används för att debitera det inkommande XCM-meddelandet för dess utförande i målparachainen, liknande gasavgifter i Ethereums värld. Trots detta kan avgifter tas ut i en annan token, till exempel DOT. Om mängden tokens som skickas via XCM inte räcker till för att täcka XCM-utförandet misslyckas XCM-transaktionen och den använda avgiften återbetalas inte.
När kanalen väl har etablerats framgångsrikt, XCM-tillgången registrerats i målparachainen och enheterna per sekund för utförandet fastställts bör användarna kunna börja överföra tillgångar.
Alla åtgärder som nämns ovan kan utföras via SUDO (om tillgängligt) eller genom demokrati (teknisk kommitté eller folkomröstningar).
Moonbeam och XCM
Eftersom Moonbeam är en parachain inom Polkadots ekosystem är ett av de mest direkta genomförandena av XCM att möjliggöra överföring av tillgångar från Polkadot och andra parachainer från/till Moonbeam. Detta kommer att göra det möjligt för användare att föra sina tokens till Moonbeam och alla dess dApps.
Genom att utöka Moonbeams unika Ethereum-kompatibilitetsfunktioner kommer utländska tillgångar att representeras via ett standard ERC-20-gränssnitt genom ett förkompilerat kontrakt. XCM-tillgångar på Moonbeam kallas XC-20s, för att skilja inhemska XCM-tillgångar från ERC-20 som genereras via EVM. Det förkompilerade kontraktet kommer att få tillgång till de nödvändiga substratfunktionerna för att utföra de nödvändiga åtgärderna. Ur ett utvecklarperspektiv är XC-20s ändå ERC-20-token med den extra fördelen att vara en XCM-tillgång över kedjan, och dApps kan enkelt stödja dem genom ett välbekant ERC-20-gränssnitt.
Själva förkompileringen stöder inte överföringar över kedjan för att hålla sig så nära det ursprungliga ERC-20-gränssnittet som möjligt. Följaktligen måste utvecklare förlita sig på Substrate API och XCM för att flytta tillgångarna tillbaka till sin ursprungliga kedja, eller på ett annat precompile-kontrakt för att få tillgång till XCM-baserade funktioner från Ethereums API.
Beroende på målblockkedjan kan överföringen av tillgångar ske via teleportering eller fjärröverföring, där den senare är den vanligaste metoden. Initialt kommer Moonbeam endast att stödja fjärröverföringar.
Följande avsnitt ger en översikt på hög nivå över de två inledande användningsfallen för XCM på Moonbeam: överföringar av tillgångar från/till Polkadot (via VMP) och överföringar av tillgångar från/till andra parachains (via XCMP). Den här sidan kommer att utökas när fler driftskompatibilitetsfunktioner blir tillgängliga, t.ex. förflyttningar av ERC-20-token från Moonbeam till andra parachains, eller förflyttningar av andra tillgångar till Moonbeam som ERC-20-representationer.
Moonbeam och Polkadot
Eftersom Moonbeam är en parachain inom Polkadots ekosystem tillåter XCM + VMP DOT-överföringar från/till Polkadot/Moonbeam. I detta avsnitt ges en översikt på hög nivå över alla åtgärder som är involverade under utförandet av sådana XCM-meddelanden.
När ett projekt väl är ombord som en parakedja har det automatiskt en dubbelriktad kommunikationskanal med reläkedjan. Det finns därför inget behov av att registrera kedjan. Reläkedjans ursprungliga token måste dock registreras på parachainen.
Alice (Polkadot) vill överföra en viss mängd DOTs från Polkadot till sitt konto på Moonbeam, som heter Alith. Därför initierar hon en XCM som uttrycker hennes avsikter. För sådana överföringar äger Moonbeam ett suveränt konto på Polkadot.
Följaktligen kommer utförandet av XCM-meddelandet på Polkadot att överföra beloppet av DOTs till Moonbeams suveräna konto på Polkadot. När tillgångarna har deponerats skickas den andra delen av meddelandet till Moonbeam.
Moonbeam kommer lokalt att utföra den åtgärd som XCM-meddelandet är programmerat att utföra. I det här fallet handlar det om att prägla och överföra samma mängd xcDOTs (cross-chain DOTs) till det konto som definieras av Alice, vilket i det här fallet är Alith. Avgiften för att utföra XCM i målparachainen betalas i den tillgång som överförs (xcDOTs i detta exempel).
Observera följande:
— Alice- och Alith-konton kan vara olika. Till exempel är Polkadots konton SR25519 (eller ED25519), medan Moonbeams konton är ECDSA-konton (i Ethereums stil). De kan också ha olika ägare.
— Det finns en viss grad av tillit, där en kedja förlitar sig på att den andra ska utföra sin del av XCM-meddelandet. Detta är programmerat på runtime-nivå, så det kan lätt verifieras.
— I det här exemplet är DOTs över kedjan (xcDOTS) en inplastad representation av de ursprungliga DOTs som finns på Moonbeams Sovereign-konto på Polkadot. xcDOTs kan när som helst överföras inom Moonbeam, och de kan också lösas in för DOTs på en 1:1-basis.
Alith deponerade sina xcDOTs i en likviditetspool. Därefter förvärvar Charleth några xcDOTs genom att byta mot denna likviditetspool, och han vill överföra några xcDOTs till Charleys Polkadot-konto. Därför initierar han en XCM som uttrycker sina avsikter.
Följaktligen kommer utförandet av XCM-meddelandet på Moonbeam att bränna antalet xcDOTs. När tillgångarna har bränts skickas den andra delen av meddelandet till Polkadot.
Polkadot kommer att utföra den åtgärd lokalt som XCM-meddelandet är programmerat att utföra lokalt. I detta fall är det att överföra samma mängd xcDOTs som bränts från Moonbeam Sovereign-kontot till det konto som definierats av Charleth, vilket i detta fall är Charley.
Moonbeam och andra parachains
Eftersom Moonbeam är en parachain inom Polkadot-ekosystemet tillåter XCM + XCMP överföring av tillgångar från/till Moonbeam och andra parachains. Detta avsnitt går igenom en översikt på hög nivå av de viktigaste skillnaderna jämfört med XCM från/till Polkadot/Moonbeam.
Det första kravet är att det måste finnas en kanal mellan parachainerna och att den tillgång som överförs måste vara registrerad i målparachainen. Det är först när båda villkoren är uppfyllda som XCM kan skickas mellan parachains.
När Alith (Moonbeam) överför ett visst antal GLMR från Moonbeam till ett annat konto (Alice) i en målparachain skickas tokens till ett Sovereign Account som ägs av den målparachainen på Moonbeam.
När XCM-meddelandet utförs i målparachainen förväntas detta mynta och överföra samma mängd xcGLMRs (GLMRs över kedjan) till det konto som definieras av Alith, vilket i detta fall är Alice. Avgiften för att utföra XCM i målparachainen betalas i den överförda tillgången (xcGLMRs i detta exempel).
Processen är liknande för xcGLMRs för att flytta tillbaka till Moonbeam som förklaras i föregående avsnitt. Först bränner utförandet av XCM-meddelandet antalet xcGLMR som återvänder till Moonbeam. När meddelandet har bränts skickas den återstående delen av meddelandet till Moonbeam via reläkedjan. Moonbeam kommer lokalt att utföra XCM-meddelandet och överföra GLMRs (samma antal brända xcGLMRs) från målkontot i parachain Sovereign till den angivna adressen.
