Przesyłanie komunikatów w ramach Cross-Konsensusu (XCM)

Wprowadzenie

Architektura Polkadot pozwala parachainom na naturalną interoperacyjność, umożliwiając cross-blockchainowe przesyłanie dowolnego typu danych lub aktywów.

Aby to osiągnąć, format Przesyłania komunikatów w ramach Cross-Konsensusu (XCM) definiuje język, za pomocą którego należy przekazywać komunikaty pomiędzy dwoma współdziałającymi blockchainami. XCM nie jest specyficzny dla Polkadot, ponieważ ma on być ogólnym i rozszerzalnym językiem pomiędzy różnymi systemami konsensusu.

Niniejsza strona stanowi krótkie wprowadzenie i przegląd XCM oraz innych powiązanych elementów. Więcej informacji można znaleźć w Wiki Polkadot.

Ogólne definicje XCM

• XCM — skrót od cross-consensus message, jest to ogólny sposób komunikacji między systemami konsensualnymi
• VMP — skrót od vertical message passing, pozwala parachainom na wymianę komunikatów z relay chainem. UMP (upward message passing) pozwala parachainom wysyłać komunikaty do ich relay chainu, natomiast DMP (downward message passing) pozwala relay chainowi przekazywać komunikaty w dół do jednego z ich parachainów
• XCMP — skrót od cross-consensus message passing, umożliwia parachainom wymianę komunikatów z innymi parachainami w tym samym relay chainie
• HRMP — skrót od horizontal relay-routed message passing, protokół tymczasowy do czasu uruchomienia pełnej implementacji XCMP. Ten sam interfejs co XCMP, ale komunikaty są przechowywane w relay chainie
• Multilokalizacja — sposób na określenie punktu w całym ekosystemie relay chain/parachain z danego miejsca pochodzenia, relatywnego lub absolutnego. Na przykład można ją wykorzystać do określenia konkretnego parachainu, aktywu, konta, a nawet palety wewnątrz parachainu. Ogólnie rzecz biorąc, multilokalizacja jest definiowana za pomocą parents i interior. Parents odnosi się do tego, ile “skoków” do macierzystego blockchainu trzeba wykonać z danego źródła. Interior odnosi się do liczby obszarów potrzebnych do zdefiniowania punktu docelowego. Na przykład, aby wycelować w parachain o ID 1000 z innego parachainu, multilokalizacja będzie wyglądać następująco { “parents”: 1, “interior”: { “X1”: [{ “Parachain”: 1000 }]}}

Protokoły przesyłania XCM

Polkadot implementuje dwa protokoły cross-konsensusu, czyli protokoły przesyłania komunikatów XCM pomiędzy parachainami wchodzącymi w jego skład, jednym z nich jest Moonbeam:

• Vertical Message Passing (VMP) — podzielony na dwa rodzaje protokołów przesyłania komunikatów:
• Upward Message Passing (UMP) — umożliwia parachainom wysyłanie komunikatów do ich relay chainu, np. z Moonbeam do Polkadot
• Downward Message Passing (DMP) — umożliwia relay chainowi przekazywanie komunikatów w dół do jednego z jego parachainów, np. z Polkadot do Moonbeam
• Cross-Chain Message Passing (XCMP) — umożliwia dwu parachainom wymianę komunikatów, o ile są one podłączone do tego samego relay chainu. Transakcje cross-chainowe są rozwiązywane przy użyciu prostego mechanizmu kolejkowania opartego na drzewie Merkle’a w celu zapewnienia spójności. Kolatorzy wymieniają komunikaty między parachainami, podczas gdy walidatory relay chainu sprawdzają, czy transmisja komunikatu się odbyła

Notatka

Obecnie, podczas rozwijania XCMP, zaimplementowany jest protokół tymczasowy o nazwie Horizontal Relay-routed Message Passing (HRMP), w którym komunikaty są przechowywane w relay chainie i z niego odczytywane. Protokół ten zostanie w przyszłości wycofany z pełnej implementacji XCMP

Ponadto dwa najczęstsze przypadki użycia komunikatów XCM, przynajmniej na wczesnych etapach ich implementacji, to:

• Teleportacja aktywów — polega na przeniesieniu aktywów z jednego blockchainu na drugi poprzez zniszczenie przenoszonej kwoty w chainie źródłowym i stworzenie klonu (tej samej kwoty co zniszczona) w chainie docelowym. W takich przypadkach każdy chain utrzymuje aktywa natywne jako rezerwę, podobnie jak w mechanizmie pomostowym burn-mint. Model ten wymaga pewnego stopnia zaufania, ponieważ każdy z dwóch chainów może nieuczciwie zmintować więcej aktywów
• Zdalne przesyłanie — polega na przenoszeniu aktywów z jednego blockchainu do drugiego za pośrednictwem konta pośredniego w chainie źródłowym, które jest w zaufaniu własnością chainu docelowego. Takie konto pośrednie znane jest jako konto “suwerenne”. W takich przypadkach aktywa chainu źródłowego nie ulegają zniszczeniu, lecz są przechowywane na koncie Suwerennym. Realizacja XCM w chainie docelowym mintuje wrapowaną reprezentację (zwaną również “wirtualną” lub “cross-chainową”) pod adresem docelowym. Reprezentacja wrapowana jest zawsze wymienna na zasadzie 1:1 z aktywami natywnymi. Jest to podobne do mechanizmu pomostowego lock-mint / burn-unlock

O wiele więcej szczegółów na temat XCM można znaleźć w Polkadot Wiki.

Początkowo Moonbeam będzie obsługiwał tylko przesyłanie zdalne. Wszystkie aktywa cross-chain na Moonbeam będą znane jako xc + TokenName. Na przykład, reprezentacja KSM Kusamy na Moonriver będzie znana jako xcKSM. Więcej o standardzie XC-20 można przeczytać tutaj.

Programiści muszą zrozumieć, że przesyłanie nieprawidłowych komunikatów XCM może spowodować utratę środków. W związku z tym przed przeniesieniem do środowiska produkcyjnego należy koniecznie przetestować funkcje XCM w sieci testowej (TestNet).

Rejestracja kanału komunikacyjnego

Zanim dwa chainy zaczną się komunikować, musi zostać otwarty kanał komunikacyjny. Kanały są jednokierunkowe, co oznacza, że kanał z chainu A do chainu B będzie przekazywał tylko komunikaty z A do B. W związku z tym przesyłanie aktywów będzie możliwe tylko z chainu A do B. Dlatego muszą być otwarte dwa kanały, aby można było przesyłać komunikaty (lub przekazywać aktywa) tam i z powrotem.

Kanał dla XCM pomiędzy relay chainem a parachainem jest otwierany automatycznie po nawiązaniu połączenia. Jednak, gdy parachain A chce otworzyć kanał komunikacyjny z parachainem B, parachain A musi przesłać eksternistykę otwartego kanału w swojej sieci. Ta eksternistyka jest również XCM! Odbiorcą tego XCM jest relay chain, a eksternistyka zawiera takie informacje, jak:

• Miejsce docelowe, w którym komunikat zostanie wykonany (w tym przypadku relay chain)
• Konto, z którego będą pobierane opłaty (płatne w tokenie relay chainu)
• Opłaty, które transakcja może skonsumować podczas realizacji
• Zakodowane dane połączenia, uzyskane przez naśladowanie zewnętrznego relay chainu. Obejmują one następujące zakodowane informacje:
• Metoda, która ma być wywołana w relay chainie (kanał otwarty)
• Identyfikator parachainowy chainu docelowego (w tym przykładzie jest to parachain B)
• Maksymalna liczba komunikatów w kolejce docelowej
• Maksymalny rozmiar wiadomości do wysłania

Opłaty za transakcje są wnoszone w reprezentacji xc (cross-chain) aktywa relay chainu (xcRelayChainAsset). Na przykład, w przypadku Kusama/Moonriver, opłaty za transakcje będą uiszczane w xcKSM. Dlatego konto płacące za opłaty musi mieć wystarczającą ilość xcRelayChainAsset. W przypadku Moonbeam/Moonriver można to rozwiązać w ten sposób, że opłaty z przychodzących komunikatów XCM, które są opłacane w aktywach chainu źródłowego, będą przesyłane do skarbca, a konto skarbca będzie wykorzystywane do opłacania eksternistycznych opłat za rejestrację kanału.

Mimo że parachain A wyraził zamiar otwarcia kanału XCM z parachainem B, ten ostatni nie zasygnalizował relay chainowi zamiaru otrzymywania wiadomości od parachainu A. Dlatego, aby kanał został ustanowiony, parachain B musi również wysłać eksternistykę (która również jest XCM) do relay chainu. Eksternisytka akceptująca kanał jest podobna do poprzedniej. Jednak zakodowane dane wywołania zawierają tylko nową metodę (akceptacja kanału) i identyfikator parachainu nadawcy (w tym przykładzie jest to parachain A). Gdy oba parachainy wyrażą zgodę, kanał jest otwierany w ramach następnej zmiany epoki.

Wszystkie wyżej wymienione czynności mogą być realizowane przez SUDO (jeśli jest dostępne) lub przez Demokrację (komitet techniczny lub referenda).

Po ustanowieniu kanału, aktywa muszą zostać zarejestrowane przed przekazaniem ich za pomocą XCM, albo poprzez włączenie ich do runtime w postaci stałej, albo poprzez paletę. Proces rejestracji aktywów w Moonbeam jest wyjaśniony w następnej sekcji.

Rejestracja aktywów XCM

Po ustanowieniu kanału między parachainami (lub relay-chainem-parachainem) może nastąpić rejestracja aktywów.

Ogólnie rzecz biorąc, rejestracja aktywów może odbywać się na poziomie runtime, co oznacza, że wymagana jest aktualizacja runtime, po której aktywa są już zarejestrowane i obsługiwane przez XCM. Jednak Moonbeam dołączył paletę Substrate, która umożliwia rejestrację zasobów bez konieczności aktualizacji runtime, co znacznie upraszcza proces.

Podczas rejestrowania aktywów XCM, eksternistyka musi zawierać (między innymi):

• Identyfikator parachainowy miejsca, w którym znajduje się aktyw źródłowy
• Typ aktywa. W chwili pisania tego dokumentu można zarejestrować zarówno natywny token parachainu, jak i aktyw utworzony za pomocą Palety Aktywów, podając jego indeks
• Nazwa składnika aktywu, symbol i liczba dziesiętna
• Minimalne saldo

Po zarejestrowaniu aktywu XCM można ustawić jednostki na sekundę wykonania. Jest to metryka używana do naliczania opłat za wykonanie przychodzącego komunikatu XCM w docelowym parachainie, podobna do opłat za gaz w świecie Ethereum. Opłaty mogą być jednak pobierane w innym tokenie, na przykład DOT. Jeśli ilość tokenów przesyłanych za pośrednictwem XCM nie jest wystarczająca do pokrycia kosztów wykonania XCM, transakcja XCM kończy się niepowodzeniem, a wydana opłata nie jest zwracana.

Po pomyślnym ustanowieniu kanału, zarejestrowaniu aktywów XCM w docelowym parachainie i ustawieniu jednostek na sekundę wykonania, użytkownicy powinni móc rozpocząć przesyłanie aktywów.

Wszystkie wyżej wymienione działania mogą być wykonane przez SUDO (jeśli jest dostępne) lub przez Demokrację (komitet techniczny lub referenda).

Moonbeam i XCM

Ponieważ Moonbeam jest parachainem w ekosystemie Polkadot, jedną z najbardziej bezpośrednich implementacji XCM jest umożliwienie transferu aktywów z Polkadot i innych parachainów z/do Moonbeam. Dzięki temu użytkownicy będą mogli przenieść swoje tokeny do Moonbeam i wszystkich jego dApps.

Rozszerzając unikalne funkcje kompatybilności Moonbeam z Ethereum, zewnętrzne aktywa będą reprezentowane za pomocą standardowego interfejsu ERC-20 poprzez prekompilowany kontrakt. Aktywa XCM na Moonbeam nazywane są XC-20s, aby odróżnić natywne aktywa XCM od ERC-20 generowanych za pośrednictwem EVM. Kontrakt prekompilowany uzyskuje dostęp do niezbędnych funkcji Substratu w celu wykonania wymaganych czynności. Niemniej jednak, z perspektywy dewelopera, XC-20 są tokenami ERC-20 z dodatkową korzyścią bycia aktywem XCM cross-chainu, a dApps mogą je łatwo obsługiwać poprzez znany interfejs ERC-20.

Sam prekompilat nie obsługuje przesyłania cross-chainowe, aby jak najbardziej zbliżyć się do oryginalnego interfejsu ERC-20. W związku z tym deweloperzy będą musieli polegać na API Substrate i XCM-ach, aby przenieść aktywa z powrotem do ich oryginalnego chainu, lub na innym kontrakcie prekompilacyjnym, aby uzyskać dostęp do funkcji opartych na XCM-ach z API Ethereum.

W zależności od docelowego blockchainu, przesyłanie aktywów może odbywać się poprzez teleportację lub zdalne przesyłanie, przy czym ta druga metoda jest najczęściej stosowana. Początkowo Moonbeam będzie obsługiwał wyłącznie przesyłanie zdalne.

Poniższe sekcje przedstawiają ogólny przegląd dwóch początkowych przypadków użycia XCM na Moonbeam: przesyłanie aktywów z/do Polkadot (poprzez VMP) oraz przesyłanie aktywów z/do innych parachainów (poprzez XCMP). Strona ta będzie rozbudowywana w miarę udostępniania kolejnych funkcji interoperacyjności, takich jak transfer tokenów ERC-20 z Moonbeam do innych parachainów lub przesyłanie innych aktywów do Moonbeam jako reprezentacje ERC-20.

Moonbeam i Polkadot

Ponieważ Moonbeam jest parachainem w ekosystemie Polkadot, XCM + VMP umożliwia przesyłanie DOT z/do Polkadot/Moonbeam. W tym rozdziale omówimy na wysokim poziomie wszystkie czynności wykonywane podczas realizacji takich komunikatów XCM.

Po włączeniu projektu do systemu jako parachain, automatycznie posiada on dwukierunkowy kanał komunikacyjny z relay chainem. Dlatego nie ma potrzeby rejestracji chainu. Jednak token natywny relay chainu musi być zarejestrowany na parachainie.

Alice (Polkadot) chce przelać pewną ilość DOT z Polkadot na swoje konto na Moonbeam o nazwie Alith. Dlatego inicjuje XCM, w którym wyraża swoje zamiary. W przypadku tego typu przelewów Moonbeam jest właścicielem konta suwerennego w Polkadot.

W związku z tym, w wyniku wykonania komunikatu XCM w systemie Polkadot, na suwerenne konto Moonbeam w systemie Polkadot zostanie przelana kwota DOT. Po wpłaceniu aktywów druga część komunikatu jest wysyłana do Moonbeam.

Moonbeam realizuje lokalnie działanie, do którego wiadomość XCM została zaprogramowana. W tym przypadku jest to mintowanie i przekazanie takiej samej ilości xcDOT (cross-chain DOTs) na konto określone przez Alice, którym w tym przypadku jest Alith. Opłata za wykonanie XCM w docelowym parachainie jest uiszczana w przesyłanych aktywach (w tym przykładzie są to xcDOT).

Należy zwrócić uwagę na następujące kwestie:

• Konta Alice i Alith mogą być różne. Na przykład konta Polkadota to konta SR25519 (lub ED25519), a Moonbeam to konta ECDSA (wzorowane na Ethereum). Mogą też mieć różnych właścicieli
• Istnieje pewien stopień zaufania, w którym jeden chain polega na drugim, wykonując swoją część wiadomości XCM. Jest to zaprogramowane na poziomie runtime, więc można to łatwo zweryfikować.
• W tym przykładzie DOTy cross-chainowe (xcDOTS) są wrapowaną reprezentacją oryginalnych DOTów przechowywanych na suwerennym koncie Moonbeam w Polkadot. xcDOTs mogą być w każdej chwili przesyłane w ramach Moonbeam i mogą być wymieniane na DOTy na zasadzie 1:1.

Alith umieściła swoje xcDOTs w puli liquidity. Następnie Charleth nabywa pewną ilość xcDOTs poprzez wymianę w stosunku do tej puli liquidity i chce przelać pewną ilość xcDOTs na konto Charley’a w Polkadot. Dlatego inicjuje XCM, w którym wyraża swoje zamiary.

W rezultacie wykonanie komunikatu XCM na Moonbeam spowoduje spalenie określonej liczby jednostek xcDOTs. Po spaleniu zasobów druga część komunikatu jest wysyłana do Polkadot.

Polkadot wykona lokalnie czynność, do której zaprogramowano komunikat XCM. W tym przypadku jest to przeniesienie takiej samej ilości spalonych xcDOTs z konta Moonbeam Suweren na konto zdefiniowane przez Charletha, którym w tym przypadku jest Charley.

Moonbeam i inne parachainy

Ponieważ Moonbeam jest parachainem w ekosystemie Polkadot, XCM + XCMP umożliwia przesyłanie aktywów z/do Moonbeam i innych parachainów. W tej części omówione zostaną główne różnice w porównaniu z XCM z/do Polkadot/Moonbeam.

Pierwszym wymogiem jest obecność kanału pomiędzy parachainami oraz fakt, że przesyłane aktywa muszą być zarejestrowane w docelowym parachainie. Dopiero gdy oba te warunki zostaną spełnione, można przesyłać XCM między parachainami.

Gdy Alith (Moonbeam) przeleje określoną ilość GLMR z Moonbeam na inne konto (Alice) w docelowym parachainie, tokeny są wysyłane na konto suwerenne należące do tego docelowego parachainu na Moonbeam.

Ponieważ wiadomość XCM jest realizowana w docelowym parachainie, oczekuje się, że zmintuje ona i prześle taką samą ilość xcGLMRs (cross-chain GLMRs) na konto zdefiniowane przez Alith, którym w tym przypadku jest Alice. Opłata za realizację XCM w docelowym parachainie jest uiszczana w przesyłanych aktywach (w tym przykładzie są to xcGLMRs).

Proces jest podobny w przypadku przenoszenia xcGLMRs z powrotem do Moonbeam, jak wyjaśniono w poprzednim rozdziale. Po pierwsze, realizacja komunikatu XCM powoduje spalenie liczby jednostek xcGLMRs zwróconych do Moonbeam. Po spaleniu, pozostała część komunikatu jest wysyłana do Moonbeam poprzez relay chain. Moonbeam realizuje lokalnie komunikat XCM i przesyła GLMR (taką samą liczbę spalonych xcGLMRs) z docelowego konta parachain Suweren na podany adres.

Oryginał przetłumaczonego dokumentu | Strona internetowa| Twitter | Medium