JAM und die Evolution von Polkadot: Skalierung durch Sharding und Semi-Coherence

1. Hintergrundwissen

Im Folgenden werden die folgenden Konzepte verwendet. Das Verständnis dieser Konzepte wird vorausgesetzt.

• Blockchain als Zustandsübergangsfunktion (State Transition Function): Verständnis von „Zustand“ (State). Beide Konzepte werden hier erläutert.
• Wirtschaftliche Sicherheit (Economic Security) und Proof of Stake: Dies wird in den PBA-Vorlesungen und Videos erklärt.

2. Einführung: Polkadot 1.0

Fassen wir zunächst die innovativsten Merkmale von Polkadot 1.0 zusammen:

Soziale Aspekte:

• Polkadot kann in jeder Hinsicht als ein riesiges DAO betrachtet werden.
• Die Netzwerk-Governance, einschließlich fork-less Runtime-Upgrades, erfolgt vollständig on-chain und selbstbestimmt.
• Die US-Börsenaufsicht (SEC) betrachtet DOT als Software und nicht als Wertpapier.
• Die meisten Netzwerkentwicklungen werden vom Polkadot Fellowship und nicht von buchhalterischen Firmen (z. B. Parity) betreut.

Technische Aspekte:

• Gemeinsam genutzte Sicherheit und shardierte Ausführung (Technik zur Aufteilung von Daten eines Blockchain-Netzwerks in „Shards“).
• Verwendung eines WASM-basierten Meta-Protokolls.
• Durch das Speichern von Blockchain-Code im Zustand als Bytecode können die meisten Upgrades fork-less durchgeführt werden. Dies ermöglicht es Polkadot, nicht nur Sharding, sondern heterogenes Sharding zu nutzen. Weitere Details finden Sie unter Heterogenität.

Lassen Sie uns nun die shardierte Ausführung genauer betrachten.

3. Der Kern der shardierten Ausführung: Cores

In diesem Artikel befassen wir uns mit L1-Netzwerken, die andere L2-„Blockchains“ hosten, wie Polkadot oder Ethereum. Dementsprechend werden L2 und Parachain als Synonyme behandelt.

Das Kernproblem der Blockchain-Skalierbarkeit lässt sich wie folgt zusammenfassen:

• Es gibt eine Gruppe von Validatoren.
• Der Code, den sie ausführen, ist durch das kryptographische Konzept des Proof of Stake vertrauenswürdig gesichert.
• Validatoren müssen im Grunde die gesamte Arbeit der anderen neu ausführen.

Das heißt, dieses System kann nicht skaliert werden, solange es alle Validatoren zwingt, immer alles (neu) auszuführen. Es ist zu beachten, dass in diesem Modell die Erhöhung der Anzahl der Validatoren nicht zu einer Erhöhung des Durchsatzes des Systems führt, solange das oben genannte Prinzip der Neu-Ausführung beibehalten wird. Die obige Beschreibung betrifft monolithische Blockchains im Gegensatz zu Sharding. Eingaben (z. B. Blöcke) werden nacheinander von allen Netzwerk-Validatoren verarbeitet. Wenn ein solches System mehr L2s hosten möchte, müssen alle Validatoren die Arbeit aller L2s neu ausführen. Eine Skalierbarkeit ist in einem solchen System natürlich nicht zu erwarten.

Eine Möglichkeit, dieses Problem zu umgehen, sind Optimistic Rollups. Hierbei wird die Neu-Ausführung (auch als Fraud Proof bezeichnet) nur dann durchgeführt, wenn jemand behauptet, dass ein Betrug vorliegt. SNARK-basierte Rollups basieren auf der Tatsache, dass die Überprüfung von SNARK-Beweisen deutlich kostengünstiger ist als deren Erstellung, sodass alle Validatoren SNARK-Beweise überprüfen können. Weitere Informationen finden Sie in der Scalability Space Map im Anhang.

Die einfache Lösung für Sharding besteht darin, die Gruppe der Validatoren in kleinere Teilmengen (Subsets) zu unterteilen und diese kleine Teilmenge den L2-Block neu ausführen zu lassen. Welches Problem hat dieser Ansatz? Wir sharding hier die Ausführung und die wirtschaftliche Sicherheit des Netzwerks. Die Sicherheit von L2 ist bereits schwächer als die von L1, und je mehr man die Validator-Gruppe in mehr Shards zerteilt, desto schwächer wird die Sicherheit zwangsläufig.

Im Gegensatz zu Optimistic Rollups, bei denen Transaktionen nicht jedes Mal neu ausgeführt werden können, ist Polkadot so konzipiert, dass Transaktionen gesharded werden. Dies ermöglicht es, dass Teilmengen von Validatoren L2-Blöcke neu ausführen, und bietet allen Netzwerkteilnehmern einen kryptowirtschaftlichen Beweis, dass die Gültigkeit des L2-Blocks genauso sicher ist, als hätte die gesamte Validator-Gruppe den Block neu ausgeführt. Dies wird durch den kürzlich offiziell angekündigten ELVES-Mechanismus ermöglicht. ELVES kann auch als „Cynical Rollup“-Mechanismus betrachtet werden. Validatoren wiederholen den Prozess, bei dem sie die Gültigkeit eines L2-Blocks von anderen Validatoren bestätigen lassen, mehrfach und können so bestätigen, dass der L2-Block mit hoher Wahrscheinlichkeit tatsächlich gültig ist. Im Falle eines Streits wird die gesamte Validator-Gruppe kurzfristig zur Teilnahme aufgefordert. Dies ist in einem Beitrag von Rob Habermeier, einem Mitbegründer von Polkadot, gut erklärt.

Dass Polkadot sowohl „shardierte Ausführung“ als auch „gemeinsam genutzte Sicherheit“ besitzen kann – Eigenschaften, die normalerweise als gegenseitig ausschließend betrachtet werden – ist dem ELVES-Mechanismus zu verdanken. Dies ist auch der wichtigste technische Erfolg von Polkadot 1.0 in Bezug auf Skalierbarkeit.

Lassen Sie uns nun zur „Core“-Metapher übergehen. Eine Ausführungs-Shard-Blockchain lässt sich mit einer CPU vergleichen. Genau wie eine CPU über mehrere Kerne verfügt, die Befehle parallel verarbeiten können, kann Polkadot L2-Blöcke parallel verarbeiten. Aus diesem Grund werden L2s in Polkadot als Parachains[1] bezeichnet und die Umgebung, in der eine Teilmenge von Validatoren einen einzelnen L2-Block ausführt, als „Core“. Ein einzelner Core lässt sich als „zusammenarbeitende Validator-Gruppe“ zusammenfassen. Während eine monolithische Blockchain zu jedem Zeitpunkt nur einen einzelnen Block verarbeiten kann, kann Polkadot pro Core und Zeitslot jeweils einen Relay-Chain-Block und einen Parachain-Block verarbeiten.

3.1. Heterogenität

Bisher haben wir nur über Skalierbarkeit und die shardierte Ausführung von Polkadot gesprochen. Eine wichtige Tatsache ist jedoch, dass jeder Shard in Polkadot eine völlig eigenständige Anwendung ist[2]. Dies wurde durch die Verwendung eines Meta-Protokolls实现, das als Bytecode gespeichert wird. Ein Meta-Protokoll ist ein Protokoll, bei dem die Definition der Blockchain in Form von Bytecode im Zustand der Blockchain gespeichert wird. In Polkadot 1.0 wurde WASM als Bytecode verwendet, in JAM wird PVM/RISC-V übernommen. Zusammenfassend ist dies der Grund, warum Polkadot als heterogenes Sharding-Blockchain (heterogeneous sharded blockchain) bezeichnet wird. Jedes L2 kann als eine völlig unterschiedliche, eigenständige Anwendung betrachtet werden.

4. Polkadot 2.0

Der Schwerpunkt von Polkadot 2.0 liegt darauf, die Nutzung von Cores flexibler zu gestalten. Im ursprünglichen Polkadot-Modell konnte ein Core für mindestens 6 Monate bis zu 2 Jahre gemietet werden. Dies ist ein geeignetes Modell für Unternehmen mit vielen verfügbaren Ressourcen, aber nicht für kleine Teams. Die Funktion, die die Nutzung von Polkadot-Cores flexibler macht, wird „Agile Coretime“ genannt. Bei der Agile Coretime können Polkadot-Cores für einen Block bis zu einem Monat gemietet werden, und bei langfristiger Miete ist ein Preis上限 (price cap) garantiert. Da Polkadot 2.0 zum jetzigen Zeitpunkt zusammen mit anderen Funktionen in Arbeit ist, werden wir hier auf weitere Erläuterungen verzichten.

5. Innerhalb des Cores vs. On-Chain

Um JAM (Polkadot 3.0) zu verstehen, muss man verstehen, was im Polkadot-Core passiert, wenn ein L2-Block eingeht. Das Folgende enthält starke Vereinfachungen.

Ein Core besteht im Grunde aus einer Gruppe von Validatoren. „Daten an den Core senden“ bedeutet, dass die Daten an die Validator-Gruppe übermittelt wurden.

0. Ein L2-Block und eine Teilmenge des entsprechenden L2-Zustands werden an den Core gesendet. Dies sind die einzigen Daten, die zur Verarbeitung des L2-Blocks erforderlich sind[3].
1. Die Teilmenge der Validatoren, die den Core bilden, führt den L2-Block neu aus und führt konsensusbezogene Aufgaben durch.
2. Die Core-Validatoren stellen sicher, dass andere Validatoren (außerhalb des Cores) die für die Neu-Ausführung erforderlichen Daten nutzen können. Gemäß den ELVES-Regeln möchten möglicherweise mehr Validatoren den L2-Block neu ausführen, und dazu werden diese Daten benötigt. Man muss sich daran erinnern, dass all diese Aufgaben außerhalb des Hauptblocks von Polkadot und der Zustandsänderungsfunktion stattfinden. Alle bisher beschriebenen Prozesse finden innerhalb des Cores und der Datenverfügbarkeitsschicht statt.
3. Der neueste Zustand, der von L2 gesendet wurde, wird im Zustand der Polkadot Relay Chain gespeichert. Diese Aufgabe ist viel kostengünstiger als die Neu-Ausführung des L2-Blocks, beeinflusst den Hauptzustand von Polkadot, wird im Polkadot-Block aufgezeichnet und von allen Polkadot-Validatoren verarbeitet.

Zusätzlich zu den oben genannten Punkten sehen wir uns die Aufgaben an, die Polkadot ausführt:

Aus Punkt 1 wissen wir, dass es in Polkadot eine andere Verarbeitungsweise gibt als die übliche Zustandsübergangsfunktion von Blockchains. Wenn im Allgemeinen alle Validatoren eines Netzwerks Aufgaben ausführen, wird der Zustand der Hauptblockchain als Ergebnis aktualisiert. Dies nennt man On-Chain-Operation. Dies entspricht Punkt 3. Was aber innerhalb des Cores (Punkt 1) geschieht, ist anders. Diese neue Art der Blockchain-Berechnung nennt man „In-Core Execution“.

Aus Punkt 2 lässt sich ableiten, dass Polkadot bereits eine native Datenverfügbarkeitsschicht (DA) bereitstellt und L2 diese DA automatisch für eine bestimmte Zeit als Nachweis der Ausführung verwendet. Darüber hinaus ist die Datenmenge, die auf diese DA[4]-Schicht geladen werden kann, festgelegt. Diese Daten sind der Nachweis, der immer für die Neu-Ausführung des L2-Blocks erforderlich ist. Außerdem kann der Code eines Parachains keine Daten aus der DA-Schicht lesen. Diese Inhalte bilden die Grundlage für das Verständnis der Funktionen von JAM. Zusammenfassend lässt sich sagen:

• In-Core Execution: Findet innerhalb des Cores statt. Sie verfügt über Fülle (abundance) und Skalierbarkeit und basiert auf Kryptowirtschaft und ELVES, bietet aber dieselbe Sicherheit wie „On-Chain Execution“.
• On-Chain Execution: Dies ist die Aufgabe der Validatoren. Die Sicherheit wird durch wirtschaftlich motivierte Validatoren aufrechterhalten. Da jeder alles verarbeitet, ist es teurer und eingeschränkter.
• Datenverfügbarkeit: Dies bedeutet, dass Polkadot-Validatoren anderen Validatoren für einen bestimmten Zeitraum verfügbare Daten bereitstellen.

6. JAM (Polkadot 3.0)

Wenn Sie die bisherigen Erklärungen verstanden haben, wird das Konzept von JAM leichter verständlich. JAM wurde stark von Polkadot beeinflusst, ist vollständig kompatibel mit Polkadot und ist ein neues Protokoll, das die Polkadot Relay Chain ersetzen und die Core-Nutzung grundlegend unparteiisch (un-opinionated[5]) gestalten soll. JAM basiert auf Polkadot 2.0. Es zielt darauf ab, die Nutzbarkeit von Polkadot-Cores grundlegend flexibler und unparteiischer zu gestalten als bei Agile Coretime. In Polkadot 2.0 ist die Zuweisung von Cores an L2s flüssiger. Der Kern von JAM besteht darin, dass jede Anwendung, die nicht auf das Format von Blockchain/L2 beschränkt ist, auf einem Polkadot-Core bereitgestellt werden kann. Der Hauptgrund, warum dies möglich ist, liegt darin, dass Entwicklern die drei im vorherigen Abschnitt beschriebenen Elemente bereitgestellt werden: In-Core- und On-Chain-Verarbeitung sowie Datenverfügbarkeit. Mit anderen Worten, JAM bietet Entwicklern folgende Funktionen:

• Programmierung der Aufgaben, die in Core und On-Chain ausgeführt werden.
• Lesen und Schreiben beliebiger Daten aus der Polkadot-DA-Schicht.

Dies sind die Grundlagen der Richtung, die JAM verfolgt. Natürlich wurden viele Aspekte vereinfacht und das Protokoll befindet sich weiterhin in der Entwicklung. Auf der Grundlage der bisherigen Erläuterungen werden wir die Inhalte von JAM nun detaillierter betrachten.

6.1. Dienste und Work-Items

Im JAM-System werden die sogenannten L2/Parachains als Service (Dienst) bezeichnet, und Blöcke/Transaktionen werden als Work-Item oder Work-Package bezeichnet. Ergänzend lässt sich sagen, dass ein Work-Item zu einem Service gehört und ein Work-Package eine Gruppe von Work-Items bezeichnet. Beide Begriffe wurden als allgemeine Begriffe gewählt, um Anwendungsfälle zu ermöglichen, die nicht auf Blockchain/L2 beschränkt sind.

Ein Service kann durch drei Einsprungspunkte beschrieben werden, von denen zwei fn refine() und fn accumulate()[6] sind. Ersteres beschreibt, was ein In-Core-Service tut, und letzteres beschreibt, was ein Service On-Chain tut. Schließlich stehen die Bezeichnungen dieser beiden Einsprungspunkte in Verbindung mit dem Namen des Protokolls, JAM (Join Accumulate Machine). Join bezieht sich auf fn refine(), bei dem alle Polkadot-Cores parallel viele Aufgaben für verschiedene Dienste ausführen. Im Join werden Daten in kleinere Teilmengen verfeinert und an die nächste Stufe weitergegeben. Accumulate ist der Prozess, bei dem die Ergebnisse der zuvor genannten Schritte im Haupt-JAM-Zustand zusammengeführt werden, was dem On-Chain-Ausführungsteil entspricht.

💡 Work-Items können spezifisch entscheiden, welcher Code in Core und On-Chain ausgeführt wird, und sie können bestimmen, wie sie Daten aus dem verteilten Data Lake (Distributed Data Lake) lesen und schreiben, sowie Inhalt und Ob/Wie.

6.2. Quasi-Konsistenz

Nach den verfügbaren Materialien zu XCM, der Sprache für die Kommunikation zwischen Polkadot-Parachains, ist alle Kommunikation asynchron.

Das bedeutet, dass nach dem Senden einer Nachricht nicht auf eine Antwort gewartet wird. Asynchronität ist eine Eigenschaft inkohärenter Systeme und ein typisches Problem für Systeme mit dauerhaft implementiertem Sharding, wie Polkadot 1.0, Polkadot 2.0 und die bestehende Gruppe von Ethereum-L2-Lösungen. Wie jedoch in Abschnitt 2.4 des Gray Paper erläutert, ist es für ein System, das gegenüber allen Mitgliedern stets synchron und vollständig kohärent ist, schwierig zu wachsen, ohne die Allgemeinheit (Generality), Zugänglichkeit (Accessibility) und Widerstandsfähigkeit (Resilience) zu opfern.

ℹ️ Synchron (Synchronous) ~ Kohärent (Coherent) || Asynchron (Asynchronous) ~ Inkohärent (Incoherent)

Hier zeigt sich eine weitere Stärke von JAM. Durch die Einführung verschiedener Eigenschaften (Properties) hat JAM einen neuartigen Gleichgewichtspunkt gefunden: das halbkohärente System (semi-coherent system). Das bedeutet, dass häufig kommunizierende Subsysteme die Chance erhalten, ein konsistentes Umfeld zu schaffen, ohne dass dies jedoch für das gesamte System erzwungen wird. Dieser Aspekt wird in einem Interview mit Dr. Gavin Wood, dem Autor des Gray Paper, ausführlich beleuchtet.

Eine weitere Sichtweise ist es, Polkadot und JAM als Sharding-Systeme zu betrachten, bei denen die Grenzen zwischen Shards flüssig sind und in jedem Moment entschieden werden.

Polkadot war bereits immer ein shardetes und vollständig heterogenes Blockchain-System. Jetzt wird es, zusätzlich zu Sharding und Heterogenität, eine Blockchain sein, bei der die Sharding-Grenzen flüssig bestimmt werden – was @gavofyork in als halbkohärentes System bezeichnete.

— Kian Paimani (@kianenigma) May 15, 2024

Die Merkmale, die dies ermöglichen, sind folgende:

Zustandslose (state-less) und parallele In-Core-Ausführung (parallel in-core execution), bei der in einem bestimmten Block nur Dienste auf demselben Core synchron interagieren können, sowie der Zugang zur On-Chain-Ausführung, bei der ein Dienst auf die Ergebnisse aller Dienste über alle Cores hinweg zugreifen kann.

JAM erzwingt keine spezifische Dienstplanung. Dienste, die häufig kommunizieren, können Sequenzer einen wirtschaftlichen Anreiz bieten, Arbeitspakete zu erstellen, die Arbeitselemente dieser häufig kommunizierenden Dienste enthalten. Sie können so kommunizieren, als befänden sie sich auf demselben Core in einer synchronen Umgebung. JAM-Dienste haben Zugang zur DA-Schicht (Data Availability) und können diese als temporäre, aber extrem kostengünstige Datenschicht nutzen.

Sobald Daten an die DA gesendet sind, werden sie sofort an alle Cores propagiert und stehen sofort auf demselben Core zur Verfügung. Dadurch können JAM-Dienste durch eigene Planung auf demselben Core aufeinanderfolgender Blöcke [7] eine hohe Datenzugänglichkeit erreichen. Es ist zu beachten, dass dies zwar in JAM möglich ist, aber nicht auf der Protokollebene erzwungen wird. Einige Schnittstellen sind theoretisch asynchron, können aber durch ausgeklügelte Abstraktionen und Anreize in der Praxis synchron funktionieren. Ein Beispiel dafür ist CorePlay, das im nächsten Abschnitt erläutert wird.

6. 3. CorePlay

In diesem Abschnitt wird CorePlay erläutert, eine experimentelle Idee von JAM. CorePlay ist ein neues Modell für die Programmierung von Smart Contracts. Zum Zeitpunkt dieses Textes ist es noch nicht klar definiert [8] und befindet sich noch im Ideenstadium. Um CorePlay zu verstehen, müssen wir uns zunächst die virtuelle Maschine von JAM ansehen, die PVM.

6. 3. 1. PVM

Die PVM ist ein wichtiges Element für JAM und CorePlay. Eine detaillierte technische Beschreibung der PVM ist im Gray Paper gut dargelegt, das von Experten auf diesem Gebiet verfasst wurde. Hier erkläre ich nur einige Merkmale der PVM:

• Effiziente Messung des Ressourcenverbrauchs
• Unterbrechung und Wiederaufnahme der Ausführung

Letzteres ist besonders wichtig für CorePlay. CorePlay ist ein Beispiel für die Schaffung einer skalierbaren Smart-Contract-Umgebung mit Programmierschnittstellen unter Verwendung der flüssigen Primitive von JAM. CorePlay schlägt vor, aktorenbasierte Smart Contracts direkt auf einem JAM-Core bereitzustellen, um eine synchrone Programmierschnittstelle zu ermöglichen. Man codiert wie gewohnt mit fn main() und kommuniziert mittels let _result = other_coreplay_actor(data).await?.

Wenn sich other_coreplay_actor auf demselben Core desselben JAM-Blocks befindet, ist der Aufruf synchron. Befindet er sich auf einem anderen Core, wird der Aktor unterbrochen und in einem späteren JAM-Block fortgesetzt. Dies ist dank der Dienste von JAM, der flexiblen Planung und den Eigenschaften der PVM möglich.

6. 4. CoreChain Service

Abschließend möchte ich noch einmal den Grund aufgreifen, warum JAM vollständig mit Polkadot kompatibel ist. Das Hauptprodukt von Polkadot, Parachains im Agile Coretime-Modell, wird in JAM beibehalten. Die ersten Dienste, die in JAM bereitgestellt werden, werden CoreChain oder Parachains genannt. Es handelt sich um einen Dienst, der Polkadot-2.0-Parachains die Ausführung auf JAM ermöglicht.

Weitere Dienste können in JAM bereitgestellt werden, und vorhandene CoreChain-Dienste können mit diesen kommunizieren. Die Funktionen, die Polkadot bisher bereitgestellt hat, werden weiterhin wichtig behandelt werden, und bestehenden Parachain-Teams werden sich neue Möglichkeiten eröffnen.

Anhang: Data Sharding

Während ein großer Teil dieses Artikels die Skalierbarkeit aus der Perspektive des Sharding von Berechnungen diskutierte, ist eine Diskussion auch aus Datensicht möglich. Interessanterweise werden wir einer ähnlichen Situation gegenüberstehen wie bei der Halb-Kohärenz. Ein vollständig kohärentes System ist im Prinzip besser, aber schwer zu skalieren. Ein vollständig inkohärentes System ist skalierbar, aber nicht ideal. JAM, das für Halb-Kohärenz steht, bietet neue Möglichkeiten.

Vollständig kohärente Systeme: Zu finden auf vollständig synchronen Smart-Contract-Plattformen wie Solana oder auf mutigen Plattformen, die nur auf Ethereum L1 bereitstellen. Alle Anwendungsdaten werden auf der Chain gespeichert und sind einfach für alle anderen Anwendungen zugänglich. Dies ist in Bezug auf Programmierbarkeit eine perfekte Eigenschaft, bietet aber keine Skalierbarkeit.

Inkohärente Systeme: Anwendungsdaten werden auf verschiedenen Shards außerhalb von L1 gespeichert. Dies ist sehr skalierbar, aber schlecht in Bezug auf Komponierbarkeit (Composability). Das Polkadot- und das Ethereum-Rollup-Modell fallen darunter.

JAM bietet beides und ermöglicht es Programmierern, beliebige Daten auf der JAM-DA-Schicht zu veröffentlichen, die als Zwischenzone zwischen On-Chain- und Off-Chain-Daten betrachtet werden kann. Dadurch können die meisten Anwendungsdaten die DA-Schicht nutzen, während der JAM-Zustand nur absolut kritische Informationen enthält, was völlig neue Arten von Anwendungen ermöglicht.

Anhang: Scalability Space Map

In diesem Teil werden wir die Ansicht über Blockchain-Skalierbarkeit erneut erläutern. Dies ist eine prägnantere Version dessen, was auch im Gray Paper beschrieben steht. Skalierbarkeit bei Blockchains folgt meistens den Ansätzen, die in traditionellen verteilten Systemen verwendet werden: Skalierung nach oben (vertikal) und Skalierung nach außen (horizontal).

Plattformen wie Solana entsprechen der Skalierung nach oben. Sie optimieren Code und Hardware, um den maximalen Durchsatz zu erreichen. Ethereum und Polkadot entsprechen der Skalierung nach außen. Das bedeutet, die Arbeitslast zu reduzieren, die jeder erledigen muss. In traditionellen verteilten Systemen erreicht man dies, indem man mehr replizierte Maschinen hinzufügt. Bei Blockchains ist die "Berechnungsmaschine" (computation machine) die Gesamtheit aller Validatoren.

Man kann die Arbeit aufteilen (Ansatz ELVES) oder ihre Pflichten erleichtern (Ansatz Optimistic Rollups), um die Arbeitslast der gesamten Validatorengemeinschaft zu verringern und so das System horizontal zu skalieren.

💡 Skalierung nach außen bei Blockchains bedeutet: "Die Anzahl der Maschinen zu reduzieren, die alles verarbeiten müssen."

Zusammenfassend lässt sich sagen:

• Skalierung nach oben: Der Ansatz monolithischer Blockchains, basierend auf Optimierung mithilfe leistungsstarker Hardware.
• Skalierung nach außen:
• Optimistic Rollups
• SNARK-basierte Rollups
• ELVES: Das sarkastische Rollup von Polkadot.

Anhang: Gleiche Hardware, Kernel-Update

In diesem Teil wird auf der Grundlage eines Vortrags von Rob Habermeier auf der Sub0 2023 (Polkadot: Kernel/Userland | Sub0 2023 - YouTube) erläutert, wie JAM als Upgrade von Polkadot als Kernel-Update auf derselben Hardware verstanden werden kann.

In einem gewöhnlichen Computer kann der gesamte System-Stack in drei Teile gegliedert werden:

1. Hardware
2. Kernel
3. User Space (Benutzerraum)

Wie bereits erläutert, übernimmt in Polkadot der Core die Rolle der Hardware, also das zentrale Subjekt, das Berechnung und Datenverfügbarkeit bereitstellt. Der Kernel von Polkadot besteht im Wesentlichen [9] aus den folgenden beiden Teilen:

• Parachain-Protokoll: Eine starre und meinungsstarke Art der Nutzung des Cores. Eine Reihe von Low-Level-Funktionen wie DOT-Token, Transfer-Funktionen, Staking, Governance usw.
• Diese beiden Teile befinden sich derzeit in der Polkadot Relay Chain.

Der Benutzerraum umfasst die Anwendungen: die Parachains, ihre nativen Token und alles, was darauf aufgebaut ist. Dies kann man sich wie folgt vorstellen:

Polkadot wollte immer die Kernfunktionen in den Benutzerraum zu den Parachains, den erstklassigen Benutzern, verlagern. Auch das Ziel des "Minimal Relay RFC" ist dies. Dies bedeutet, dass der Kernelraum von Polkadot etwas verkleinert wird, da sich die Polkadot Relay Chain nur darauf konzentriert, das Protokoll für die Parachains bereitzustellen.

Sobald diese Architektur umgesetzt ist, lässt sich leicht vorstellen, wie eine Migration zu JAM aussehen würde. JAM wird den Kernelraum von Polkadot drastisch verkleinern und ihn breiter nutzbar machen. Außerdem wird das Parachain-Protokoll in den Benutzerraum verschoben. Dies ist einer der wenigen Wege, Anwendungen auf demselben Core (Hardware) und JAM (Kernel) zu schreiben.

💡 Diese Erklärung betont noch einmal, dass JAM die Polkadot Relay Chain ersetzt, nicht die Parachains. Mit anderen Worten, die JAM-Migration kann als Kernel-Upgrade betrachtet werden. Die Basis-Hardware bleibt bestehen, und große Teile des bestehenden Kernels werden der Vereinfachung halber in den Benutzerraum verschoben.

Referenzen

1. 7. 9 Polkadot 2. 0: CorePlay, CoreChains, Corejam, Safrole, PolkaVM - Polkadot by Gavin @PBA4 - YouTube
2. Gavin Wood: The Gray Paper Interview - JAM & the Future of Polkadot - Behind the Code: Web3 Thinkers - YouTube
3. Parallel Chain. ↩︎
4. Blockchain oder Zustandsübergangsfunktion. ↩︎
5. In Polkadot 1.0 wurde der Zustandsbeweis von L2 als PoV (Proof of Validity) und die Kombination aus Zustandsbeweis und Parachain-Block als PVF (Parachain Validation Function) bezeichnet. ↩︎
6. Im Gray Paper wird die DA-Schicht als Distributed Data Lake (DDL) bezeichnet. In diesem Artikel wird der Einfachheit halber von DA oder DA-Schicht gesprochen. ↩︎
7. Es ist wichtig, dass JAM nur die Polkadot Relay Chain ersetzt. Alle Anwendungen, die auf Polkadot laufen, einschließlich der Parachains, bleiben dank CoreChain erhalten. ↩︎
8. Die dritte ist on_message, die aufgerufen wird, wenn eine Nachricht von einem anderen Dienst kommt. ↩︎
9. Für Details zur Dienstplanung siehe den Abschnitt "Authorization" im Gray Paper. ↩︎
10. Die beste Ressource zu CorePlay ist dieser RFC-Entwurf. ↩︎
11. Das Wort "im Wesentlichen" ist wichtig. In dem erwähnten Video bezeichnete Rob auch das Parachain-Protokoll als eine Benutzer- raumanwendung von Polkadot. Dies ist jedoch eine theoretische Annahme; das Parachain-Protokoll ist in das Core-Polkadot-Protokoll, also den Kernel selbst, integriert. ↩︎