Was ist die von Gavin Wood offiziell angekündigte Polkadot-Technologievision „JAM“ der nächsten Generation?

Am 19. April kündigte Gavin Wood auf der Token 2049-Konferenz in Dubai eine mutige Vision für die nächste Generation der Polkadot-Technologie an. Wie andere bahnbrechende Neuheiten, die Polkadot auf den Markt gebracht hat, wird diese neue Vision die Zukunft von Web3 revolutionieren. Es bietet die Geschwindigkeit, Skalierbarkeit, vollständige Dezentralisierung und Benutzerfreundlichkeit, die Web3 benötigt, um tiefgreifende Innovationen in Web3 und im gesamten Technologiebereich voranzutreiben.

Im Mittelpunkt dieser Vision steht JAM, eine neue Version der Polkadot-Kette, die die Fähigkeiten von Polkadot über die aktuellen Grenzen von Web3 hinaus erweitern und gleichzeitig den Einsatz einer breiten Palette von Technologien auf Polkadot ermöglichen wird. Mit JAM wird die bahnbrechende Skalierbarkeit, die derzeit nur durch Rollups möglich ist, auf die Konsensebene gebracht.

Nach Abschluss der Entwicklung wird JAM ein verteilter Computer sein, der nahezu jede Art von Aufgabe ausführen kann, die als Dienst ausgedrückt werden kann. JAM drängt Polkadot in die Welt der synchronen Zusammensetzbarkeit, was dazu beitragen wird, die Fragmentierung zu reduzieren und Aktivitäten zu konsolidieren, sodass Anwendungen auf Polkadot das Netzwerk im gesamten Ökosystem besser nutzen können. Dies wird neue Möglichkeiten für tiefgreifende Innovationen eröffnen und Entwicklern eine leistungsstarke Umgebung bieten, in der sie auf eine noch nie dagewesene Weise kreativ sein können.

JAM befindet sich derzeit in der Forschungs- und Entwicklungsphase. Derzeit liegt in der Polkadot-Community ein Vorschlag zur Abstimmung vor (Referendum 682 https://polkadot.polkassembly.io/referenda/682), um diese neue Richtung zu bestätigen und die Technical Fellowship zur Genehmigung von JAM zu ermächtigen.

Um die Entwicklung von JAM zu unterstützen und sicherzustellen, dass es im Sinne einer echten Dezentralisierung aufgebaut wird, kündigte Gavin in seiner Rede gemeinsam die Einrichtung des JAM-Bonus mit insgesamt 10 Millionen DOT an verwendet werden, um andere Implementierungen der JAM-Entwicklung anzuregen.

Während seiner Rede veröffentlichte Gavin auch ein technisches Grey Paper. Wenn Sie tiefer in die Vision und die technischen Details des Projekts eintauchen möchten, finden Sie das Papier auf der neuen JAM Graypaper-Website: https://graypaper.com/.

Gemeinsam sind Gavin und Polkadot führend bei der Entwicklung innovativer Technologien, die darauf abzielen, die Vision eines freien und offenen Netzwerks zu verwirklichen. JAM ist das nächste Kapitel in der sich entwickelnden Polkadot-Geschichte.

Das Folgende ist die neueste Einführung in JAM aus dem Polkadot-Wiki, geschrieben von Gavin Wood. Der vollständige Name von

JAM lautet Join-Accumulate Machine, ein neues Design, das die bestehende Relaiskette ersetzen soll. Der Name JAM leitet sich von CoreJAM ab, das für Collect Refine Join Accumulate steht und das von der Maschine verkörperte Rechenmodell beschreibt, das ursprünglich in einem RFC von Gavin Wood beschrieben wurde. Allerdings werden in der tatsächlichen Kette nur Join und Accumulate ausgeführt, während die Prozesse Collect und Refine außerhalb der Kette stattfinden.

Im Gegensatz zum aktuellen iterativen Ansatz wird JAM als umfassendes Einzel-Upgrade eingeführt. Dafür gibt es unter anderem folgende Gründe:

• Einheitliche Upgrades können die Vorgänge nach dem Upgrade präzise einschränken, was bei einem iterativen Ansatz schwierig zu bewerkstelligen ist.
• Es reduziert die kleinen Upgrades und großen Änderungen, die oft regelmäßig über Wochen oder Monate erfolgen.

Während dieser Übergang große bahnbrechende Veränderungen erfordert, werden wir hart daran arbeiten, seine Auswirkungen auf ein überschaubares Maß zu reduzieren. Es ist besser, mehrere kleinere Breaking Changes in einem einzigen Übergang zu kombinieren, der ein neues Blockchain-Konzept einführt und verschiedene bestehende Ideen integriert.

Eine Rollup-Kette

JAM ist eine domänenspezifische Kette, die zur Behandlung von Problemen in einer bestimmten Domäne verwendet wird. In diesem Fall handelt es sich um einen Rollup, den die Ethereum-Community als optimistischen Rollup bezeichnet. Das Rollup von JAM ist hinsichtlich der Sicherheit sehr eingeschränkt. Das ist es, was Polkadot in den letzten fünf Jahren getan hat, und es hat sich zu einer hochgradig domänenspezifischen Rollup-Kette entwickelt. JAM macht es im Wesentlichen vielseitiger und erfordert weniger voreingestellte Einstellungen.

Die JAM-Kette übernimmt die Ausgabe des Rollups und allgemeiner die an anderer Stelle durchgeführten Berechnungen und integriert die Ausgabe in einen gemeinsamen Zustand, ähnlich der Funktionalität der Polkadot-Relay-Kette.

Die Aufgabe der JAM-Kette besteht darin, die notwendige Ausrüstung bereitzustellen, um sicherzustellen, dass die Ausgabe die Eingabe nach der Transformation korrekt widerspiegelt.

Ähnlichkeiten zu Smart-Contract-Ketten

JAM weist mehrere Ähnlichkeiten zu Smart-Contract-Ketten auf:

• Die JAM-Kette selbst führt erlaubnislosen Code direkt aus.
• Der Zustand der JAM-Kette ist in verschiedene Pakete unterteilt.
• Neben der Kapselung des Status umfasst es auch die Kapselung von Code und Balance.

Die Kapselung dieser Zustände wird als Dienst bezeichnet. Daher ist der Status von JAM in Dienste unterteilt. Das Erstellen neuer Dienste ist erlaubnisfrei, ähnlich wie die Bereitstellung intelligenter Verträge in einer intelligenten Vertragskette. Daher erfordert das Hinzufügen neuer Dienste zu einer JAM-Kette keine maßgebliche Genehmigung oder Einhaltung von Governance-Mechanismen, im Gegensatz zu Substrat-basierten Ketten, die für das Hinzufügen neuer Paletten eine Governance-Genehmigung erfordern. Zu den Diensten gehören Code, Guthaben und bestimmte Zustandskomponenten, ähnlich den Strukturen, die üblicherweise in Smart-Contract-Ketten zu finden sind.

Service-Einstiegspunkte

Der Code des JAM-Dienstes ist in drei verschiedene Einstiegspunkte unterteilt:

• Refine ist die Funktion, die die meisten zustandslosen Berechnungen durchführt. Es definiert Transformationen für Rollups bestimmter Dienste.
• Die Accumulate-Funktion nimmt die Ausgabe und fügt sie dem Gesamtstatus des Dienstes hinzu.
• OnTransfer verarbeitet Informationen von anderen Diensten.

Arbeitspakete sind der Input für den Service. Ein Arbeitspaket kann viele Arbeitselemente enthalten. Jedes Arbeitselement ist einem Dienst zugeordnet und spiegelt die tatsächliche Eingabe für diesen Dienst wider. Bei Parachain-Diensten kommen hier Transaktionen und alle Blockchain-Eingaben ins Spiel. Die Sicherheitsvorrichtung von

JAM besteht aus einer zweistufigen Verarbeitung, bei der die Refine-Funktion Arbeitselemente als Eingabe akzeptiert und die Ergebnisse der Arbeit als Ausgabe erzeugt und dann in die Accumulate-Funktion übergeht (zuerst Refine, dann Accumulate). Arbeitselemente werden zu Arbeitsergebnissen verfeinert. Daher wird ein Arbeitspaket, das viele Arbeitselemente enthält, zu einem Arbeitsbericht verfeinert. Einem Arbeitspaket kann die Nutzung eines Kerns für einen bestimmten Zeitraum (in der Regel 6 Sekunden) zugewiesen werden.

JAM ist transaktionslos

JAM unterscheidet sich von intelligenten Vertragsketten durch transaktionslose Operationen. Es gibt keine Transaktionen innerhalb von JAM; alle Aktionen sind erlaubnislos und durchlaufen zunächst die Verfeinerungsphase. In dieser Phase verfeinert der Dienst die Eingabedaten vor und wandelt sie in einen Arbeitsbericht mit den Arbeitsergebnissen um. Die Ergebnisse dieser Bemühungen werden dann in die Kette übertragen.

Obwohl keine Transaktionen stattfinden, akzeptiert JAM weiterhin externe Informationen in bestimmten Formaten. Es gibt fünf Arten von externen Informationen:

2. Zusicherungen

4. Vorbilder

Die ersten drei Arten sind Teil des JAM-Kettensicherheitsrahmens. „Garantien“ und „Zusicherungen“ umfassen Validatoren, die gemeinsam nachweisen, dass ein Arbeitsergebnis das Ergebnis des entsprechenden Arbeitselements genau widerspiegelt, wenn es durch die Funktion „Verfeinern“ des Dienstes transformiert wird.

Eine Beurteilung liegt vor, wenn die Integrität eines Arbeitsergebnisses in Frage gestellt wird, wenn eine große Anzahl von Validatoren dessen Gültigkeit oder Ungültigkeit bescheinigen. In diesem Fall wurden möglicherweise ungültige Arbeitselemente in den Status des Dienstes integriert und müssen möglicherweise zurückgesetzt werden. Das Urteil muss innerhalb einer Stunde nach Übermittlung des Arbeitsberichts an die Kette gefällt werden. Während dieser Zeit wird die Sperre vorübergehend ausgesetzt.

Das Vorbild ist eine Funktion, die von der JAM-Kette für die Refine-Funktion bereitgestellt wird. Obwohl die Refine-Funktion normalerweise zustandslos ist, kann sie eine zustandsbehaftete Operation ausführen: das Nachschlagen eines gehashten Vorbilds. Diese Funktion ist der einzige Aspekt der Funktion „Verfeinern“, für den es eine Standardeinstellung gibt.

Tickets gelangen als anonyme Einträge in den Blockproduktionsmechanismus. Es handelt sich dabei nicht um direkte Voraussetzungen für die Blockproduktion; das System arbeitet vielmehr zwei Epochen im Voraus. Dieser Mechanismus ist Teil des SAFROL-Algorithmus, einer verfeinerten Version des ursprünglichen SASSAFRAS-Algorithmus.

Refine-Funktion

In JAM kann die Refine-Verarbeitungsstufe bis zu 15 MB Daten pro Zeitraum akzeptieren, wobei jeder Zeitraum 6 Sekunden dauert. Die von Refine erzeugten Daten sind jedoch bis zu 90 kB groß und erfordern aufgrund der verteilten Natur des Verfügbarkeitssystems eine umfangreiche Datenkomprimierung. Im Kontext von Parachains stellen beispielsweise 15 MB Daten einen Proof of Validity (PoV) dar, während 90 kB Daten einem Kandidatenbeleg entsprechen.

Refine kann bis zu 6 Sekunden PVM-Gas verbrauchen, was der gesamten Blockierungsperiode der Relaiskette entspricht. Diese verlängerte Ausführungszeit im Vergleich zur aktuellen Zwei-Sekunden-Grenze von PVF wird durch Sicherheitsmessung und andere Optimierungen erreicht.

Refine kann auch eine Originalbildsuche durchführen. Wenn davon ausgegangen wird, dass ein Hash und das zugehörige Vorbild in der JAM-Kette verfügbar sind, kann das Vorbild durch Bereitstellung des Hashs angefordert werden. Diese Fähigkeit ermöglicht ein effizientes Speichern und Abrufen von Code, indem beispielsweise Parachain-Code in der JAM-Kette gespeichert und auf seinen Hash im Arbeitspaket verwiesen wird.

Refine ist die Hauptverarbeitungsleistung und erledigt die meisten Aufgaben, bei denen es sich um zustandslose Vorgänge handelt.

Accumulate-Funktion

Die Accumulate-Funktion ist für die Integration der von der Refine-Funktion generierten Ausgabe in den Kettenzustand verantwortlich. Accumulate kann mehrere Ausgaben von Refine akzeptieren, die alle vom selben Dienst stammen. Refine und Accumulate dienen beide als Einstiegspunkte aus einem bestimmten Servicecodeblock.

Die Ausführungszeit von Accumulate pro Ausgabe ist viel kürzer als die von Refine, normalerweise nur höchstens 10 Millisekunden. Die Dauer hängt jedoch von der Anzahl der Workitems im Arbeitspaket ab. Enthält ein Arbeitspaket mehrere Elemente, wird die verfügbare Zeit auf diese aufgeteilt.

Im Gegensatz zu Refine ist Accumulate zustandsbehaftet und kann auf den Zustand der JAM-Kette zugreifen. Es kann Speicher von jedem Dienst lesen, in seinen Schlüsselwertspeicher schreiben, Gelder überweisen und Memos hinzufügen, wenn Gelder übertragen werden. Darüber hinaus kann Accumulate neue Dienste erstellen, ihren Code aktualisieren, die Verfügbarkeit von Vorbildern anfordern und vieles mehr.

Darüber hinaus kann Refine Unterinstanzen von PVM aufrufen. Dies ermöglicht die Erstellung von Unterinstanzen oder virtuellen Maschinen, in denen Code und Daten bereitgestellt, Speicher- und Stack-Konfigurationen angepasst und Berechnungen innerhalb eines flexiblen Rahmens durchgeführt werden können.

onTransfer-Funktion

Die onTransfer-Funktion im JAM-System ist ebenfalls zustandsbehaftet und ermöglicht es ihr, den Status des Dienstes zu ändern. Es hat die Möglichkeit, den Status anderer Dienste zu überprüfen und seinen eigenen Status zu ändern. Diese Funktion erleichtert die Kommunikation zwischen Diensten, wenn auch auf asynchrone Weise.

Im Gegensatz zu vielen Smart-Contract-Plattformen, bei denen Interaktionen synchron erfolgen, erfolgen in JAM Interaktionen zwischen gekapselten Komponenten (wie in diesem Fall Smart Contracts oder Services) asynchron. Nachrichten und Token werden zusammen gesendet und irgendwann innerhalb desselben sechs Sekunden dauernden Ausführungszyklus vom empfangenden Dienst verarbeitet. Es gibt keinen unmittelbaren Rückpfad. Wenn ein Rückpfad erforderlich ist, muss der sendende Dienst eine weitere Übertragung initiieren oder seinen Status so ändern, dass der empfangende Dienst ihn später interpretieren kann.

Accumulate und onTransfer sind beide für die parallele Ausführung konzipiert, sodass Accumulate und die Übertragung verschiedener Dienste gleichzeitig erfolgen können. Dieses Design eröffnet die Möglichkeit für zukünftige Verbesserungen, wie z. B. die Zuteilung der Gaszufuhr über die aktuellen 10 Millisekunden hinaus. Theoretisch könnte ein sekundärer Kern verwendet werden, um bestimmte Akkumulationen durchzuführen, wodurch mehr Gas ausgebeutet werden könnte.

Verallgemeinerung von JAM-Ketten

Wie im ursprünglichen Polkadot-Whitepaper angegeben, ist Polkadot in erster Linie auf ein bestimmtes Serviceprofil zugeschnitten: die Bereitstellung von Parachains. Um diesen Dienst zu implementieren, hat Polkadot zwei wichtige Unterkomponenten entwickelt:

• Verteiltes Datenverfügbarkeitssystem
• Ein System, das Prüfung und Sicherheit für Berechnungen bietet (d. h. ein optimistisches Rollup-System mit starken Sicherheitsgarantien)

Mit Polkadot Im Vergleich dazu JAM hat weniger voreingestellte Präferenzen und bietet ein höheres Maß an Abstraktion und Generalisierung. Dies macht es einfacher, die zugrunde liegenden Komponenten entsprechend den persönlichen Vorlieben zu nutzen.

JAM arbeitet erlaubnislos, ähnlich einer Smart-Contract-Kette, und ermöglicht individuelle Uploads und die Ausführung des beabsichtigten Codes. Darüber hinaus hostet es Daten, ermöglicht die Suche nach Vorbildern und verwaltet den Status, ähnlich einem Schlüsselwertsystem. Da JAM über keinen Mechanismus zur direkten Annahme von Transaktionen verfügt, enthält der Genesis-Block von JAM einen Dienst, der die Erstellung neuer Dienste erleichtert.

Für Dienste innerhalb von JAM gibt es keine vordefinierten Beschränkungen hinsichtlich der Menge an Code, Daten oder Status. Ihre Fähigkeiten werden durch kryptoökonomische Faktoren bestimmt; je mehr DOT-Tokens hinterlegt sind, desto größer ist die Kapazität für Daten und Status. Beispielsweise konsolidiert der Parachain-Dienst auf JAM alle Funktionen von Polkadot 1.1 in einem einzigen Dienst, und andere Dienste können auch das verteilte Verfügbarkeitssystem von Polkadot sowie Prüf- und Sicherungssysteme für die Berechnung nutzen.

Polkadot Virtual Machine (PVM)

PVM basiert auf der RISC-V-Befehlssatzarchitektur (ISA), die für ihre Einfachheit und Vielseitigkeit bekannt ist. RISC-V ISA bietet mehrere Vorteile:

1. Einfache Übersetzung in gängige Hardwareformate wie x86, x64 und ARM.

2. Gut unterstützt durch Tools wie LLVM.

PVM selbst verkörpert Einfachheit und Sicherheit, ist sandboxfähig und bietet verschiedene Ausführungsgarantien. Es ist deterministisch, konsenssensitiv und leicht zu messen. Im Vergleich zu anderen virtuellen Maschinen mangelt es PVM an Komplexität und übermäßigen Voreinstellungen.

WASM ist zwar für Web-Anwendungsfälle optimiert, bringt aber auch Herausforderungen beim Stack-Management mit sich, insbesondere wenn es um die Handhabung der Kontinuität geht. RISC-V löst dieses Problem, indem es den Stapel im Speicher platziert und so die sequentielle Verarbeitung auf natürliche Weise ohne zusätzliche Komplexität erleichtert.

Darüber hinaus zeigt PVM eine überlegene Ausführungsgeschwindigkeit bei der Ausführung auf Legacy-Hardware, insbesondere auf X64 und ARM, und bietet Vorteile wie die kostenlose Messung, die im Vergleich zu WASM günstig ist.

Durch die Unterstützung der RISC-V-Kontinuität wird ein neuer Standard für skalierbare Codierung auf Multicore-Plattformen wie JAM etabliert. Asynchrone parallele Architekturen werden für die Skalierbarkeit von Hardware- und Softwareplattformen immer wichtiger, ein Trend, der sich voraussichtlich auch auf Blockchains und Konsensalgorithmen ausweiten wird.

SAFROLE

SAFROLE ist ein Blockproduktionsalgorithmus, der SASSAFRAS vereinfacht. Einige Komponenten, die für Parachains nützlich sein könnten, sind ausgeschlossen. Daher bleiben Parachains möglicherweise bei SASSAFRAS statt bei SAFROLE. SAFROLE ist so einfach wie möglich:

• Stellen Sie sicher, dass es so wenige voreingestellte Präferenzen wie möglich gibt, um potenzielle zukünftige Anwendungsfälle zu maximieren.
• Treten Sie in die Fußstapfen des Ethereum Yellow Paper und versuchen Sie wirklich, so viele Implementierungen wie möglich zu erreichen, um das Fachwissen zu verbreiten.

Es ist eine Herausforderung zu verstehen, wie Polkadot 1.0 durchgängig funktioniert. Mit JAM sollte jemand, der das Yellow Paper lesen und verstehen kann, sehr schnell lesen und verstehen können, wie JAM funktioniert. Einfachheit ist also entscheidend.

SAFROLE ist ein auf SNARK basierender Blockproduktionsalgorithmus. Es verwendet SNARKs aufgrund ihrer anonymisierenden Eigenschaften. Und es ermöglicht eine nahezu völlig gabelfreie Blockproduktion in konstanter Zeit. Die wenigen Fälle, in denen es zu einer Abzweigung kommen kann, passieren grundsätzlich nur, wenn es zu einer Netzwerkspaltung kommt oder jemand vorsätzlich böswillig handelt. Der große Wert der Anonymität besteht nicht darin, die Identität der Validatoren geheim zu halten; tatsächlich geben sie ihre Identität preis, wenn sie einen Block erzeugen, und dies geschieht, um die Sicherheit des Blockproduktionsmechanismus selbst zu gewährleisten, im Wesentlichen um Spam zu vermeiden Anschläge.

Netzwerk

JAMs Netzwerk verwendet das QUIC-Protokoll. Dies ermöglicht direkte Peer-to-Peer-Verbindungen zwischen einer großen Anzahl von Validatoren. Dadurch können die über 1000 Validatoren auf Polkadot dauerhafte Verbindungen untereinander aufrechterhalten, ohne sich um mögliche Socket-Probleme kümmern zu müssen. Da JAM keine Transaktionen abwickelt, besteht im Grunde kein Grund für Gerüchte. In Situationen, in denen eine Verteilung erforderlich ist, die nicht Punkt-zu-Punkt oder innerhalb einer sehr kleinen Teilmenge von Validatoren erfolgt, wird die Rasterdiffusion verwendet, bei der die Validatoren in einem Raster angeordnet werden, Pakete in Reihen gesendet werden und diese dann von jedem Knoten an gesendet werden Alle seine Spalten sind Mitglied.

Pipeline für effiziente Blockverarbeitung

In zustandsbasierten Blockchains wie Ethereum enthält der Header des Blocks normalerweise die Post-State-Wurzel, die den berechneten Zustand aller Blöcke zusammenfasst. Daher kann der Blockheader erst gesendet werden, wenn alle Berechnungen abgeschlossen sind. Einige Berechnungen können jedoch vor dem Senden des Blockheaders durchgeführt werden, da deren Ergebnisse die Gültigkeit des Blocks bestimmen.

JAM verfolgt jedoch einen anderen Ansatz und fügt den Pre-State-Root anstelle des Post-State-Roots in den Blockheader ein. Dies bedeutet, dass der im Header angezeigte Zustand um einen Block verzögert wird. Dadurch können einfache Berechnungen durchgeführt werden, die etwa 5 % der Blockarbeitslast oder Ausführungszeit ausmachen, und Blöcke können sofort verteilt werden. Die restlichen 95 % der Blockberechnungen, hauptsächlich Akkumulationsaufgaben, können später abgeschlossen werden. Dadurch kann der nächste Block gestartet werden, bevor der aktuelle Block ausgeführt wird.

Dieser Ansatz ermöglicht eine effizientere Nutzung der Zeit zwischen den Blöcken. In einem herkömmlichen Setup, wie etwa der sechssekündigen Blockzeit von Polkadot, muss die Post-State-Wurzel bereitgestellt werden und kann nur zeitweise berechnet werden. Durch die Pipeline in JAM kann jedoch die gesamte Blockzeit effektiv für Berechnungen genutzt werden, wodurch die Effizienz maximiert wird.

Während die Verwendung der gesamten Blockzeit für Berechnungen möglicherweise nicht ideal ist, da dies zu permanentem Nachholbedarf und verzögerten Blockimporten führen kann, kann der Ansatz von JAM die Berechnungszeiten im Vergleich zu herkömmlichen Setups erheblich verlängern. Dadurch können effektive Blockberechnungszeiten von etwa drei bis dreieinhalb Sekunden erreicht werden, was eine enorme Verbesserung gegenüber aktuellen Setups darstellt.

Architektonischer Unterschied: JAM vs. Relay Chain

Ein architektonischer Unterschied zwischen JAM und Relay Chain ist der Grad der festen Funktionalität. Während die Relay Chain einige Elemente festlegt, beispielsweise die zur Definition des Protokolls verwendete Sprache (WASM), geht JAM in dieser Hinsicht noch weiter. Es schreibt beispielsweise die Typen vor, die zum Codieren von Blockheadern und Hashing-Schemata verwendet werden, was es schwierig macht, diese Aspekte zu ändern.

Allerdings behält JAM durch sein Servicemodell eine Flexibilität, die mit der durch das WebAssembly-Metaprotokoll in der Relay-Kette erreichten vergleichbar ist. In diesem Modell wird die Verantwortung für die Upgradefähigkeit auf den Service verlagert, wodurch die Kette selbst von der Last der Upgrades befreit wird. Drei Hauptgründe für diese Entscheidung sind:

1. Einfachheit priorisieren. Durch die Aufrechterhaltung nicht aktualisierbarer Ketten wird die Komplexität erheblich reduziert.
2. Relaisketten neigen dazu, komplexe Funktionen einzuführen, ohne alte Funktionen zu entfernen, was die Sache komplizierter macht. Da Upgrades einfach zu implementieren sind, besteht kaum ein Anreiz, das Substrate SDK zu vereinfachen. Daher wird die Replikation von Polkadot unpraktisch. Die festen Parameter von
3. JAM bieten Optimierungspotenzial. Durch ein klares Verständnis der spezifischen Aufgaben, die die JAM-Kette ausführen muss, und die Möglichkeit, feste Parameter festzulegen, wird eine Optimierung in Bereichen wie Netzwerktopologie und Timing möglich. Dies steht im Gegensatz zur hochaktualisierbaren Natur der Relay-Kette, bei der diese Optimierungen aufgrund der häufigen Änderungen, die wahrscheinlich bei jedem Upgrade vorgenommen werden, komplexer sind.

Trotz dieser Unterschiede behält JAM die Flexibilität bei Funktionen auf Anwendungsebene wie Kernzeitverkäufen, Einsätzen und Governance bei, die alle innerhalb des Dienstes verwaltet werden. Darüber hinaus führt JAM ein neues Konzept ein, indem es Token-Guthaben mit Diensten verknüpft und so Möglichkeiten für Anpassungen des Wirtschaftsmodells bietet, die in rein aktualisierbaren Ketten wie Relay-Ketten nicht einfach zu erreichen sind.

JAM Toaster

Um sicherzustellen, dass JAM seinen ursprünglichen Erwartungen gerecht wird, gehört zu den laufenden Bemühungen der Aufbau einer umfassenden Testumgebung für die JAM-Kette. Anstatt ein kleines Testnetzwerk auf unzuverlässiger Hardware zu betreiben, um die Cloud-Computing-Kosten zu verwalten, erfordert diese Initiative eine erhebliche Investition.

JAM Toaster wird hier vorgestellt, bei dem es sich im Wesentlichen um eine Testplattform für groß angelegte Experimente und Leistungsbewertungen handelt. Dies geht auf frühere Herausforderungen ein, die bei der Entwicklung der Polkadot-Relay-Chain aufgetreten sind, als wir erfuhren, dass es sich als schwierig erwies, die entstehenden Effekte und Dynamiken des Netzwerks in einem solchen Ausmaß zu betreiben. Frühere Versuche waren auf einige Dutzend Knoten im Testnetzwerk und im Kusama-Netzwerk beschränkt, denen aufgrund des fehlenden Zugriffs auf validierende Knoten keine umfassenden Überwachungsmöglichkeiten zur Verfügung standen. Im Gegensatz dazu können kleine Testnetzwerke die Netzwerkdynamik groß angelegter Bereitstellungen nicht genau simulieren.

JAM Toaster möchte diese Lücke schließen, indem es einen detaillierten Einblick in das gesamte JAM-Netzwerk, einschließlich 1023 Knoten, bietet. Die Plattform erleichtert die Untersuchung des Netzwerkverhaltens und der Leistungsmerkmale und bietet Entwicklern wertvolle Einblicke in die erwartete Leistung von Parachains.

JAM und Substrate

Benchmarking vs. Metering

In JAM können Benchmarking oder Leistungstests optional sein. Während in einigen Fällen immer noch ein Benchmarking erforderlich sein kann, macht das Messsystem von JAM im Allgemeinen die Notwendigkeit eines häufigen Benchmarkings überflüssig. JAM läuft auf einem Messsystem, das es Benutzern ermöglicht, die Rechenlast nach Abschluss zu bewerten. Darüber hinaus gibt es einen theoretischen Mechanismus zur Steuerung der Berechnung beim Aufbau von Blöcken.

In einigen Fällen ist jedoch immer noch ein Benchmarking erforderlich. Wenn die Messung beispielsweise für bestimmte Anwendungsfälle zu konservativ ist, ist möglicherweise ein Benchmarking erforderlich, um die Leistung zu verbessern. Darüber hinaus sind Benchmarks für Aufgaben nützlich, die längere Ausführungszeiten erfordern, um sicherzustellen, dass sie nicht zu lange dauern.

XCMP

Als nächstes kommt Cross-Chain Messaging (XCMP), und JAM erfordert volle XCMP-Unterstützung. Dies liegt daran, dass in einer Relay-Kette, wenn alle Fallschirme ständig alle Daten übertragen, mehr Daten über Kandidatenempfangsstellen weitergeleitet werden können. JAM befolgt strenge Regeln, auch für Parachain-Dienste, einschließlich Einschränkungen bei der Datenübertragung zwischen den Phasen „Refine“ und „Accumulate“. Bei der Verwendung von Horizontal Relay Chain Messaging (HRMP) durchlaufen derzeit alle Nachrichten die Relay-Kette, wodurch die Datennutzlast auf 4 kB oder weniger begrenzt wird, was möglicherweise nicht praktikabel ist. Infolgedessen leitet XCMP nur Nachrichtenheader durch die Kette weiter, während die eigentlichen Nachrichtendaten außerhalb der Kette übertragen werden, eine notwendige und längst überfällige Verbesserung.

Accords

Accords kapseln im Wesentlichen Zustand und Logik, ähnlich wie Smart Contracts, mit mehreren Instanzen jeder Parachain. Sie erleichtern den Austausch von Nachrichten zwischen Instanzen und ermöglichen die synchrone Interaktion mit Parachains. Das Protokoll ist in Szenarien nützlich, in denen es an Vertrauen zwischen Parachains mangelt, beispielsweise bei Token-Transfers. Im Gegensatz zu bestehenden Ansätzen mit Reservevermittlern vereinfacht Accords den direkten Token-Transfer zwischen Parachains und macht vertrauenswürdige Vermittler überflüssig. Darüber hinaus kann Accords als XCM-Weiterleitungsmechanismus fungieren und die Nachrichtenintegrität auch bei der Weiterleitung über Drittvermittler sicherstellen, wodurch die Notwendigkeit einer expliziten Herkunftskennzeichnung entfällt.

Verbesserung der Effizienz

Schließlich verfolgt JAM einen breiteren, weniger bevorzugten Ansatz, um den zugrunde liegenden Konsensmechanismus zu nutzen und so bei der Umsetzung innovativerer Lösungen zu helfen. Beispielsweise wird die verteilte Verfügbarkeit für komplexe Aufgaben wie Zero-Knowledge-Beweise praktischer und effizienter. Darüber hinaus unterstützt JAM ein gemischtes Ressourcenverbrauchsmodell, bei dem Arbeitspakete sowohl rechenintensive Aufgaben als auch datenintensive Vorgänge enthalten können. Durch die Kombination rechenintensiver Dienste mit Diensten, die eine hohe Datenverfügbarkeit erfordern, optimiert JAM die Nutzung der Validatorressourcen und senkt so die Kosten. Dieser flexible Ansatz macht die Kombination von Parachain-Workloads wie verteilter Verfügbarkeit und SNARK-Verifizierung kostengünstiger und steigert gleichzeitig die Effizienz.

JAM-Verbesserungen und Kompatibilität

JAM wurde entwickelt, um der Kompatibilität mit bestehenden Polkadot 1-Fallschirmen Priorität einzuräumen. Während die Kompatibilität mit dem Polkadot SDK gewahrt bleibt, wurde die Polkadot Validator Function (PVF) verschoben. Es zielt auf die Polkadot Virtual Machine (PVM) ab, nicht auf WebAssembly. Dieser Übergang wird durch die Tatsache erleichtert, dass PVM eine geringfügige Modifikation von RISC-V ist, das offiziell als Ziel von LLVM identifiziert wurde. Daher kann PVM ein offizielles LLVM-Ziel werden, bevor JAM bereitgestellt wird.

JAM ist nicht nur ein Host für Parachains, sondern führt auch bedeutende Verbesserungen ein. Es bietet das Potenzial, Benchmarking-Bemühungen zu vereinfachen und zukünftige Benchmarking-Anforderungen zu lindern. Darüber hinaus führt JAM das Konzept von Protokollen, Multi-Instanz- und Multi-Shard-Smart-Verträgen ein, um spezifische Interaktionsprotokolle zwischen Parachains zu verwalten und auszuführen. Darüber hinaus ist eine umfassende Unterstützung von Cross-Chain Messaging (XCMP) von entscheidender Bedeutung, die es ermöglicht, Einschränkungen bei der Informationsübertragung zwischen Parachains aufzuheben, was typischerweise durch Cross-Chain Messaging (XCM) erleichtert wird.

In Bezug auf Agile Coretime behält JAM die Kompatibilität mit bestehenden Einstellungen bei. Es bietet jedoch die Möglichkeit, Kernzeiten nicht nur auf Parachains, sondern auf jeder Gruppe von Arbeitspaketen zu lokalisieren. Diese Flexibilität erhöht die Vielseitigkeit und Effizienz der Ressourcenzuweisung innerhalb des JAM-Ökosystems.

Das obige ist der detaillierte Inhalt vonWas ist die von Gavin Wood offiziell angekündigte Polkadot-Technologievision „JAM“ der nächsten Generation?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!