Architektura JAM: przetwarzanie rdzeniowe i semi-spójność w Polkadot

1. Wiedza wstępna Poniżej pojawiają się następujące pojęcia, a dalsza treść zakłada ich zrozumienie.

• Funkcja przejścia stanu (State Transition Function) w roli łańcucha bloków Zrozumienie „stanu” (State). Oba pojęcia zostały wyjaśnione tutaj.
• Bezpieczeństwo ekonomiczne (Economic Security) i Dowód Stawki (Proof of Stake) Treść ta jest wyjaśniona w wykładach i materiałach wideo PBA.

2. Wstęp: Polkadot 1.0 Najpierw podsumujmy najbardziej innowacyjne cechy Polkadota 1.0:

Aspekty społeczne: Polkadot można w każdym aspekcie postrzegać jako jeden ogromny DAO. Zarządzanie siecią, w tym aktualizacje środowiska uruchomieniowego bez forka (fork-less runtime upgrades), odbywa się w całości on-chain w sposób samowykonywalny. Amerykańska Komisja Papierów Wartościowych i Giełd (SEC) traktuje DOT jako oprogramowanie, a nie papier wartościowy. Większość prac rozwojowych nad siecią jest prowadzona przez Polkadot Fellowship, a nie przez księgowo przypisane firmy (np. Parity).

Aspekty techniczne: Współdzielenie bezpieczeństwa i równoległe wykonanie (sharded execution), polegające na podziale danych sieci blockchain na „shardy”. Wykorzystanie metaprotokołu opartego na WASM. Przechowywanie kodu blockchaina w postaci bajtkodu w stanie pozwala na przeprowadzanie większości aktualizacji bez forka, co umożliwia w Polkadocie nie tylko sharding, ale także sharding heterogeniczny. Więcej szczegółów znajduje się w sekcji o heterogeniczności. Przejdźmy teraz do szczegółowego omówienia równoległego wykonania.

3. Istota równoległego wykonania: Rdzeń (Core) W tym artykule omawiamy sieci L1 hostujące inne „blockchainy” L2, takie jak Polkadot czy Ethereum. W związku z tym L2 i parachain będą traktowane jako synonimy.

Główny problem skalowalności blockchaina można podsumować w następujący sposób. Istnieje zbiór walidatorów, a kod, który wykonują, jest zabezpieczony zaufaniem wynikającym z kryptograficznej koncepcji dowodu stawki (proof of stake). Walidatory muszą zasadniczo ponownie wykonać całą pracy nawzajem. Oznacza to, że ten system nie może się skalować, dopóki zmusza wszystkich walidatorów do ciągłego (ponownego) wykonywania wszystkiego.

Należy zauważyć, że w tym modelze, o ile zachowana zostanie zasada ponownego wykonania wspomniana w poprzednim akapicie, zwiększenie liczby walidatorów nie skutkuje wzrostem przepustowości systemu. Powyższe opisuje cechy monolitycznych blockchainów, które przeciwstawiają się shardingu. Dane wejściowe (np. bloki) są przetwarzane pojedynczo przez wszystkich walidatorów sieci. Jeśli taka sieć L1 chce hostować więcej łańcuchów L2, wszyscy walidatorzy muszą ponownie wykonać pracę wszystkich L2. Oczywiście w takim systemie nie można oczekiwać skalowalności.

Jedną z metod obejścia tego problemu są optymistyczne rollupy (Optimistic Rollups), które pozwalają na ponowne wykonanie (tzw. dowody oszustwa, fraud proof) tylko wtedy, gdy ktoś zgłosi wystąpienie oszustwa. Rollupy oparte na SNARK wykorzystują fakt, że weryfikacja dowodu SNARK jest znacznie tańsza niż jego generowanie, co pozwala wszystkim walidatorom na weryfikację dowodów SNARK. Więcej szczegółów znajduje się w załączniku w sekcji Mapa przestrzeni skalowalności (Scalability Space Map).

Proste rozwiązanie polegające na shardingu polega na podziale zbioru walidatorów na mniejsze podzbiory (subset), które następnie ponownie wykonują blok L2. Jaki jest problem z tym podejściem? Polega ono na shardingu wykonania i bezpieczeństwa ekonomicznego sieci. Bezpieczeństwo L2 jest już słabsze niż L1, a im bardziej dzielimy zbiór walidatorów na więcej shardów, tym bezpieczeństwo musi być słabsze.

W przeciwieństwie do optymistycznych rollupów, które nie mogą ponownie wykonać każdej transakcji, Polkadot został zaprojektowany tak, aby shardować transakcje. Pozwala to podzbiorom walidatorów na ponowne wykonanie bloków L2, jednocześnie dostarczając wszystkim uczestnikom sieci dowód kryptograficzny, że prawdziwość bloku L2 jest tak samo bezpieczna, jak gdyby cały zbiór walidatorów ponownie wykonał blok. Jest to możliwe dzięki niedawno ogłoszonemu mechanizmowi ELVES. ELVES można postrzegać również jako mechanizm „Cynical Rollup”. Walidatorzy kilkakrotnie powtarzają proces weryfikacji ważności bloku L2 u innych walidatorów, potwierdzając wysoką prawdopodobieństwo, że blok L2 jest faktycznie ważny. W przypadku sporu cały zbiór walidatorów jest wzywany do udziału w krótkim czasie, co zostało dobrze wyjaśnione w artykule Roba Habermeiera, współzałożyciela Polkadota.

Dzięki mechanizmowi ELVES Polkadot może posiadać obie cechy, które są zazwyczaj traktowane jako wzajemnie wykluczające się: „równoległe wykonanie” i „współdzielone bezpieczeństwo”, co jest głównym osiągnięciem technicznym Polkadota 1.0 w zakresie skalowalności.

Przejdźmy teraz do metafory „rdzenia”. Blockchain z równoległym wykonywaniem można porównać do procesora CPU. Podobnie jak procesor CPU posiada wiele rdzeni mogących przetwarzać instrukcje równolegle, Polkadot może przetwarzać bloki L2 równolegle. Z tego powodu w Polkadocie L2 nazywa się parachainem [1], a środowisko, w którym podzbiór walidatorów wykonuje pojedynczy blok L2, nazywa się „rdzeniem”. Poszczególny rdzeń można podsumować jako „współpracujący zbiór walidatorów”. Jeśli monolityczny blockchain może przetworzyć tylko jeden blok w danym szczelinie czasowym, to Polkadot może przetworzyć jeden blok łańcucha przekaźnego (Relay Chain) i jeden blok parachain na rdzeń i na szczelinę czasową.

3.1. Heterogeniczność Dotychczas mówiliśmy tylko o skalowalności i równoległym wykonywaniu w Polkadocie, ale jednym z ważnych faktów jest to, że każdy shard w Polkadocie to odrębna aplikacja [2]. Zostało to zrealizowane dzięki użyciu metaprotokołu przechowywanego jako bajtkod; metaprotokół to protokół, w którym definicja blockchaina jest przechowywana w stanie blockchaina w postaci bajtkodu. W Polkadocie 1.0 jako bajtkód użyto WASM, a w JAM przyjęto PVM/RISC-V. W rezultacie Polkadot jest nazywany heterogenicznym blockchainem z shardingiem (heterogeneous sharded blockchain). Każdy L2 to odrębna, zupełnie inna aplikacja.

4. Polkadot 2.0 Polkadot 2.0 kładzie nacisk na uczynienie korzystania z rdzeni bardziej elastycznym. W dotychczasowym modelu Polkadota jeden rdzeń można było wydzierżawić na okres od 6 miesięcy do maksymalnie 2 lat. Jest to model odpowiedni dla firm z dużą ilością dostępnych zasobów, ale nie dla mniejszych zespołów. Funkcja pozwalająca na bardziej elastyczne wykorzystywanie rdzeni Polkadota nazywa się „agile coretime” (zwinny czas rdzenia). W ramach zwinnego czasu rdzeni można wypożyczyć rdzeń Polkadota na okres od jednego bloku do maksymalnie miesiąca, a w przypadku długoterminowego najmu gwarantowana jest cena maksymalna (price cap). W chwili obecnej Polkadot 2.0 jest w fazie rozwoju wraz z innymi funkcjami, więc tutaj pominę dalsze wyjaśnienia.

5. Wewnątrz rdzenia vs. On-chain Aby zrozumieć JAM (Polkadot 3.0), trzeba zrozumieć, co dzieje się w rdzeniu Polkadota, gdy trafia do niego blok L2. Poniższa treść jest mocno uproszczona.

Rdzeń składa się zasadniczo ze zbioru walidatorów. „Wysłanie danych do rdzenia” oznacza, że dane zostały dostarczone do zbioru walidatorów.

0. Do rdzenia przesyłany jest jeden blok L2 oraz podzbiór stanu tego L2. Jest to jedyna dana potrzebna do przetworzenia bloku L2 [3].
1. Podzbiór walidatorów tworzących rdzeń ponownie wykonuje blok L2 i przeprowadza zadania związane z konsensusem.
2. Walidatorzy rdzeni udostępniają dane potrzebne do ponownego wykonania (innym walidatorom spoza rdzenia). Zgodnie z zasadami ELVES więcej walidatorów może chcieć ponownie wykonać blok L2 i wtedy potrzebują tych danych.

Należy pamiętać, że wszystkie te zadania odbywają się na zewnątrz, niezależnie od głównego bloku Polkadota i funkcji przejścia stanu. Wszystkie procesy opisane do tej pory odbywają się wewnątrz rdzenia i warstwy dostępności danych.

3. Najnowszy stan wysłany przez L2 jest zapisywany w stanie łańcucha przekaźnego Polkadota (Relay Chain). To zadanie jest znacznie tańsze niż ponowne wykonanie bloku L2, wpływa na główny stan Polkadota, jest rejestrowane w bloku Polkadota i jest przetwarzane przez wszystkich walidatorów Polkadota.

Oprócz powyższego przyjrzyjmy się bliżej zadaniom wykonywanym przez Polkadot:

Z punktu 1 wynika, że w Polkadocie istnieje inna metoda przetwarzania niż typowa funkcja przejścia stanu blockchaina. Zazwyczaj, gdy wszyscy walidatorzy sieci wykonują pracę, aktualizuje to główny stan blockchaina, co nazywamy operacją on-chain (on-chain operation). Do tego odnosi się punkt 3. Jednak to, co dzieje się wewnątrz rdzenia (punkt 1), jest inne. Ten nowy sposób obliczeń blockchaina nazywamy przetwarzaniem wewnątrzrdzeniowym (in-core execution).

Z punktu 2 można wywnioskować, że Polkadot zapewnia już natywną warstwę dostępności danych (DA), a L2 automatycznie używa jej przez określony czas jako dowód przetworzenia. Ponadto dane, które mogą trafić na tę warstwę DA [4], są stałe i są zawsze dowodem wymaganym do ponownego wykonania bloku L2. Kod parachaina nie może jednak odczytywać danych z warstwy DA.

Powyższe treści są podstawą do zrozumienia funkcjonalności JAM. Podsumowując:

• Przetwarzanie wewnątrzrdzeniowe: Zachodzi wewnątrz rdzenia. Posiada obfitość zasobów (abundance) i skalowalność, a dzięki kryptografii ekonomicznej i mechanizmowi ELVES zapewnia bezpieczeństwo na poziomie „przetwarzania on-chain”.
• Przetwarzanie on-chain: To zadanie walidatorów. Jest zabezpieczone przez walidatorów zmotywowanych ekonomicznie; ponieważ każdy przetwarza wszystko, jest droższe i bardziej ograniczone.
• Dostępność danych: Polega na tym, że walidatorzy Polkadota udostępniają innym walidatorom dane, które są użyteczne przez określony czas.

6. JAM (Polkadot 3.0) Jeśli zrozumiano powyższe wyjaśnienia, koncepcja JAM będzie łatwiejsza do pojęcia. JAM jest mocno inspirowany przez Polkadot, jest w pełni kompatybilny z Polkadotem, ma zastąpić łańcuch przekaźny Polkadota i uczynić korzystanie z rdzeni fundamentalnie bezstronnym (un-opinionated [5]). JAM opiera się na Polkadocie 2.0. Celem jest zwiększenie użyteczności rdzeni Polkadota w sposób fundamentalnie bardziej elastyczny i bezstronny niż w przypadku zwinnych czasów rdzeni. W Polkadocie 2.0 przydział rdzeni dla L2 jest bardziej płynny.

Kluczem do JAM jest to, że na rdzeniu Polkadota można wdrożyć dowolną aplikację, nie ograniczając się do formatu blockchain/L2. Głównym powodem, dla których jest to możliwe, jest zapewnienie programistom trzech elementów omówionych w poprzedniej sekcji: przetwarzania wewnątrzrdzeniowego i on-chain oraz dostępności danych. Mówiąc inaczej, JAM oferuje programistom następujące funkcje:

• Możliwość programowania zadań wykonywanych wewnątrzrdzeniowo i on-chain.
• Możliwość odczytu i wprowadzania dowolnych danych z warstwy DA Polkadota.

Omówiliśmy tu podstawowe informacje o kierunku rozwoju JAM. Oczywiście wiele rzeczy zostało uproszczonych, a protokół jest nadal rozwijany. Na podstawie dotychczasowych wyjaśnień przejdźmy do bardziej szczegółowego omówienia treści JAM.

6.1. Usługi i elementy robocze W systemie JAM to, co dawniej nazywano L2/Parachain, jest teraz nazywane Usługą (Service), a bloki/transakcje to Elementy Robocze (Work-Item) lub Pakiety Robocze (Work-Package). Należy dodać, że element roboczy należy do usługi, a pakiet roboczy to grupa elementów roboczych. Oba terminy zostały wybrane jako ogólne, aby uwzględniać przypadki użycia nie ograniczone do blockchain/L2.

Usługę można opisać za pomocą trzech punktów wejścia, z których dwa to fn refine() i fn accumulate() [6]. Ten pierwszy opisuje, co robi usługa wewnątrzrdzeniowa, a drugi opisuje, co usługa robi on-chain. Ponadto nazwy obu punktów wejścia są związane z nazwą protokołu JAM (Join Accumulate Machine). Join odnosi się do fn refine(), gdzie wszystkie rdzenie Polkadota wykonują równolegle dużo pracy dla różnych usług. W Join dane są oczyszczane (refine) na mniejsze podzbiory i przekazywane do następnego etapu. Accumulate oznacza gromadzenie się wyników powyższego procesu w głównym stanie JAM, co odpowiada wykonaniu on-chain.

💡 Element roboczy może konkretnie decydować o tym, jaki kod wykonać wewnątrzrdzeniowo i on-chain, oraz decydować o sposobie, treści i czytaniu oraz pisaniu danych z Rozproszonego Jeziora Danych (Distributed Data Lake).

6.2. Semi-spojność (Eventual Consistency) Zgodnie z istniejącymi materiałami dotyczącymi XCM, który jest językiem komunikacji między parachainami Polkadota, cała komunikacja jest asynchroniczna.

Oznacza to, że po wysłaniu wiadomości system nie czeka na odpowiedź. Asynchroniczność jest cechą systemów niespójnych (incoherent) i stanowi istotny problem systemów z trwałym shardingiem, takich jak Polkadot 1.0, Polkadot 2.0 oraz istniejące warstwy L2 Ethereum. Jak jednak wyjaśniono w sekcji 2.4 Gray Paper, system zawsze synchroniczny i w pełni spójny dla wszystkich uczestników ma trudności ze skalowaniem bez poświęcania ogólności (generality), dostępności (accessibility) i odporności (resilience). ℹ️Synchroniczność (Synchronous) ~ Spójność (Coherent) || Asynchroniczność (Asynchronous) ~ Niespójność (Incoherent)To kolejny obszar, w którym uwidaczniają się zalety JAM. Wprowadzając różne właściwości (property), JAM znalazł nowy punkt równowagi zwany systemem półspójnym (semi-coherent system). Oznacza to, że często komunikujące się ze sobą podsystemy mają szansę tworzenia spójnego środowiska, nie jest to jednak wymuszane na całym systemie. Kwestia ta jest szczegółowo omówiona w wywiadzie z dr. Gavinem Woodem, autorem Gray Paper. Inna perspektywa polega na traktowaniu Polkadota, a tym samym JAM, jako systemu shardingowego, w którym granice między shardami są płynne i ustalane w każdym momencie. Polkadot był zawsze łańcuchem z shardingiem i w pełni heterogenicznym. Teraz stanie się łańcuchem, obok shardingu i heterogeniczności, z płynnie ustalanymi granicami shardingu, co @gavofyork nazwał systemem półspójnym — Kian Paimani (@kianenigma)May 15, 2024Cechy, które to umożliwiają, to: bezstanowe (state-less) i równoległe wykonanie wewnątrzrdzeniowe (parallel in-core execution), w ramach którego usługi w tym samym rdzeniu w określonym bloku mogą wchodzić w interakcje synchronicznie, oraz dostęp do wykonania on-chain, który pozwla jednej usłudze uzyskać dostęp do wyników wszystkich usług istniejących we wszystkich rdzeniach. JAM nie narzuca konkretnego harmonogramu usług. Usługi często komunikujące się mogą oferować sekwenserom ekonomiczne zachęty do tworzenia pakietów zadań (work package) zawierających elementy zadań (work item) często komunikujących się usług. Mogą one wtedy komunikować się w sposób identyczny jak w środowisku synchronicznym, znajdując się w tym samym rdzeniu. Usługi JAM mają dostęp do warstwy DA i mogą ją wykorzystywać jako tymczasową, ale bardzo tanią warstwę danych. Gdy dane zostaną przesłane do warstwy DA, są natychmiast propagowane do wszystkich rdzeni i stają się natychmiast dostępne w tym samym rdzeniu. Dzięki temu usługi JAM mogą cieszyć się wysoką dostępnością danych dzięki własnemu harmonogramowaniu w tym samym rdzeniu sekwencyjnych bloków [7]. Należy pamiętać, że powyższe funkcje są możliwe w JAM, ale nie są wymuszane na poziomie protokołu. Niektóre interfejsy mogą być teoretycznie asynchroniczne, ale w praktyce mogą działać synchronicznie dzięki wyrafinowanym abstrakcjom i zachętom. Przykładem tego jest CorePlay, omówiony w następnej sekcji. 6. 3. CorePlayW tej sekcji wyjaśniono eksperymentalną ideę JAM zwaną CorePlay. CorePlay to nowy model programowania smart kontraktów, który w momencie pisania nie został jeszcze jasno zdefiniowany [8] i nadal jest na etapie koncepcji. Aby zrozumieć CorePlay, należy najpierw przyjrzeć się maszynie wirtualnej JAM, czyli PVM. 6. 3. 1. PVMPVM jest kluczowym elementem JAM i CorePlay. Szczegółowe i techniczne wyjaśnienia PVM są dobrze opisane w Gray Paper napisanym przez ekspertów w tej dziedzinie, więc tutaj ograniczymy się do opisania kilku cech PVM: efektywne mierzenie zużycia zasobów, możliwość wstrzymywania i wznawiania wykonywania. Szczególnie ta ostatnia cecha jest ważna dla CorePlay. CorePlay to przypadek wykorzystania płynnych prymitywów JAM do stworzenia skalowalnego środowiska smart kontraktów z interfejsem programistycznym. CorePlay proponuje metodę umożliwiającą synchroniczny interfejs programistyczny poprzez bezpośrednie wdrażanie scentralizowanych na aktorach (actor-centric) smart kontraktów w rdzeniu JAM. Programuje się w standardowy sposób, używając fn main(), i komunikuje się za pomocą let _result = other_coreplay_actor(data). await?. Jeśli other_coreplay_actor znajduje się w tym samym rdzeniu danego bloku JAM, wywołanie jest synchroniczne; jeśli znajduje się w innym rdzeniu, aktor jest wstrzymywany i wznawiany w późniejszym bloku JAM. Jest to możliwe dzięki usługom JAM, elastycznemu harmonogramowaniu oraz cechom PVM. 6. 4. Usługa CoreChainNa koniec wróćmy do powodu, dla którego wspomniano, że JAM jest w pełni kompatybilny z Polkadotem. Główny produkt Polkadota, czyli parachaing w modelu Agile Coretime, zostanie zachowany w JAM. Pierwszymi usługami wdrożonymi w JAM będą tzw. CoreChain lub parachaingi. Są to usługi pozwalające na uruchamianie parachaingów w stylu Polkadot 2.0 w JAM. W JAM można wdrożyć więcej usług, a istniejące usługi CoreChain mogą z nimi komunikować się, ale funkcje previously świadczone przez Polkadot nadal będą traktowane jako ważne, a dla istniejących zespołów parachaingów pojawią się nowe możliwości. Dodatek: Sharding danychWiększość tego artykułu omawiała skalowalność z perspektywy shardingowego wykonywania, ale dyskusja jest możliwa również z perspektywy danych. Ciekawostką jest to, że spotkamy się z sytuacją podobną do tej omówionej w kontekście półspójności. W pełni spójny system może być w zasadzie lepszy, ale trudno go skalować. W pełnie niespójny system jest skalowalny, ale nie jest idealny. JAM, promujący półspójność, sugeruje nowe możliwości. W pełni spójny system: taki jak w pełni synchroniczne platformy smart kontraktów, np. Solana, czy odważne platformy wdrażające się wyłącznie w warstwie L1 Ethereum. Wszystkie dane aplikacji są przechowywane na łańcuchu i łatwo dostępne dla wszystkich innych aplikacji. Jest to idealna cecha pod względem programowalności, ale brakuje skalowalności. Niespójny system: dane aplikacji są przechowywane w osobnych shardach poza L1. Jest to bardzo skalowalne, ale niekorzystne pod względem komponowalności (composability). Dotyczy to modelu Polkadot i Ethereum rollup. JAM oferuje oba podejścia, pozwalając programistom publikować dowolne dane w warstwie JAM DA, którą można postrzegać jako strefę pośrednią między danymi on-chain a off-chain. Dzięki temu większość danych aplikacji może korzystać z warstwy DA, a w stanie JAM mogą być umieszczane tylko w pełni istotne informacje, co pozwala na budowanie całkowicie nowych typów aplikacji. Dodatek: Scalability Space MapW tej części ponownie wyjaśniono poglądy na temat skalowalności blockchain. Jest to bardziej zwięzła wersja tego, co opisano w Gray Paper. Skalowalność w blockchainach podąża w większości za podejściami stosowanymi w tradycyjnych systemach rozproszonych, czyli skalowaniem w górę (pionowe) i skalowaniem na zewnątrz (poziome). Platformy takie jak Solana to przykład skalowania w górę. Polega ono na optymalizacji kodu i sprzętu w celu osiągnięcia maksymalnej przepustowości. Ethereum i Polkadot to przykłady skalowania na zewnątrz. Oznacza to redukcję ilości pracy, którą każdy musi wykonać. W tradycyjnych systemach rozproszonych osiąga się to poprzez dodanie większej liczby zreplikowanych maszyn. W blockchainie "maszyną obliczeniową" (computation machine) jest cały zbiór walidatorów. Można podzielić ich, aby podzielić zadania (metoda ELVES) lub złagodzić ich obowiązki (metoda optymistycznego rollupa), zmniejszając obciążenie pracy całego zbioru walidatorów, co w rezultacie pozwala na poziome skalowanie systemu. 💡Skalowanie na zewnątrz w blockchainie oznacza "zmniejszenie liczby maszyn, które muszą przetwarzać wszystko". Podsumowując: Skalowanie w górę: podejście monolitycznych blockchainów polegające na optymalizacji opartej na potężnym sprzęcie. Skalowanie na zewnątrz: optymistyczne rollupy, rollupy oparte na SNARK, ELVES: syneryczne rollupy Polkadota. Dodatek: Ten sam sprzęt, aktualizacja jądraW tej części, w oparciu o prezentację Roba Habermeiera na Sub0 2023: Polkadot: Kernel/Userland | Sub0 2023 - YouTube, wyjaśniono, jak uaktualnienie JAM w stosunku do Polkadota można porównać do aktualizacji jądra na tym samym sprzęcie. W zwykłym komputerze cały stos systemowy można podzielić na trzy następujące elementy: sprzęt, jądro, przestrzeń użytkownika. Jak wspomniano wcześniej, w Polkadocie to rdzenie pełnią kluczową rolę "sprzętu", zapewniając obliczenia i dostępność danych. "Jądro" Polkadota składa się w istocie [9] z dwóch elementów: Protokół parachaingów: sztywny i wyraźny sposób korzystania z rdzeni. Zestaw funkcji niskopoziomowych, takich jak token DOT, funkcje przelewu, staking, ład (governance) itp. Oba te elementy znajdują się obecnie w łańcuchu przekaźnikowym Polkadota. Przestrzeń użytkownika: aplikacje to parachaingi, ich natywne tokeny i wszystko zbudowane na ich szczycie. Można to zwizualizować w następujący sposób. Polkadot zawsze dążył do przenoszenia funkcji kluczowych do parachaingów, czyli użytkowników pierwszej klasy. Celem RFC Minimal Relay jest to samo. Oznacza to, że przestrzeń jądra łańcucha przekaźnikowego Polkadota zostanie nieco zmniejszona, ponieważ skupi się on wyłącznie na dostarczaniu protokołu parachaingom. Gdy ta architektura zostanie wdrożona, łatwo wyobrazić sobie, jak będzie wyglądać migracja do JAM. JAM znacznie zmniejszy przestrzeń jądra Polkadota, czyniąc ją bardziej użyteczną. Ponadto protokół parachaingów przenosi się do przestrzeni użytkownika, co jest jednym z niewielu sposobów pisania aplikacji na tym samym rdzeniu (sprzęcie) i JAM (jądro). 💡To wyjaśnienie raz jeszcze podkreśla, że JAM zastępuje łańcuch przekaźnikowy Polkadotu, a nie parachaingi. Mówiąc inaczej, migracja JAM może być postrzegana jako uaktualnienie jądra. Podstawowy sprzęt pozostaje niezmieniony, a wiele części istniejącego jądra przenosi się do przestrzeni użytkownika w celu uproszczenia. Materiały źródłowe7. 9 Polkadot 2. 0: CorePlay, CoreChains, Corejam, Safrole, PolkaVM - Polkadot by Gavin @PBA4 - YouTubeGavin Wood: The Gray Paper Interview - JAM & the Future of Polkadot - Behind the Code: Web3 Thinkers - YouTubeParallel Chain. ↩︎Blockchain lub funkcja przejścia stanu. ↩︎W Polkadot 1.0 dowód stanu L2 nazywano PoV (Proof of Validity), a połączenie dowodu stanu i bloku parachaingu nazywano PVF (Parachain Validation Function). ↩︎W Gray Paper warstwa DA jest nazywana rozproszonym jeziorem danych (Distributed Data Lake, DDL). W tym artykule, dla wygody, używamy określenia DA lub warstwa DA. ↩︎Ważne jest, że JAM zastępuje tylko łańcuch przekaźnikowy Polkadotu. Wszystkie aplikacje działające na Polkadocie, w tym parachaingi, pozostają nienaruszone dzięki CoreChain. ↩︎Trzeci to on_message, wywoływany, gdy wiadomość nadejdzie z innej usługi. ↩︎Szczegółowe informacje o harmonogramowaniu usług znajdują się w sekcji "Authorization" w Gray Paper. ↩︎Najlepszym źródłem informacji o CorePlay jest ten projekt RFC. ↩︎Słowo "w istocie" jest ważne. We wspomnianym filmie Rob również nazwał protokół parachaingów aplikacją przestrzeni użytkownika Polkadota. Jest to jednak założenie teoretyczne; protokół parachaingów jest zintegrowany z podstawowym protokołem Polkadotu, czyli z samym jądrem. ↩︎O AUTORZEkian PaimaniEngineering Lead / Rust Core Developer at Parity Technologies1 postTerriTechnical Writer1 postNA TEJ STRONIEUdostępnij na TwitterzeUdostępnij na FacebookuUdostępnij na LinkedInAdres e-mailPowiadom mnieWitamy! Wkrótce otrzymasz e-mail. Kliknij łącze logowania, aby potwierdzić subskrypcję. Przykro nam, coś poszło nie tak. Spróbuj ponownie.