JAM wird in 12-20 Monaten ausgeliefert? Drei Hauptentwickler enthüllen das M1-, PoP-Wirtschaftsmodell und die Zukunft von ZK!

JAM, dieser Name wurde in der Polkadot-Community schon lange diskutiert. Nachdem Gavin Wood auf dem Web3 Summit eine Reihe von bahnbrechenden Informationen präsentiert hat, sind die Erwartungen und Fragen rund um JAM auf ein neues Hoch gestiegen – Was genau ist JAM? Welche Veränderungen wird es für Polkadot bringen? Wie weit ist es noch von der offiziellen Einführung entfernt?

Um der Community ein umfassenderes Verständnis zu ermöglichen, hat PolkaWorld drei Gäste eingeladen, die direkt an der Kernentwicklung von JAM beteiligt sind – Bryan vom Acala-Team, Junha, Entwickler der JAM Rust-Implementierung „FastRoll“, sowie Boy Maas, Entwickler der JAM Zig-Implementierung „JAMZig“ und Mitbegründer des Polona-Projekts.

Die drei Gäste sind nicht nur tief in die technische Umsetzung von JAM involviert, sondern erforschen auch in unterschiedlichen Richtungen das Potenzial von JAM: von der Implementierung mehrsprachiger Clients über die Migration von Cross-Chain-Toolchains bis hin zu zukünftigen Anwendungen des PVM – sie repräsentieren den aktuellen Stand der Entwicklung von JAM am besten.

In diesem Interview nehmen sie uns aus erster Hand mit in die Welt von JAM:

• Was bedeuten die von Gavin angekündigten wichtigen JAM-Updates wirklich?
• Wie werden das Token-Limit von JAM (π × 1 Milliarde) und der PoP-Mechanismus (Proof of Personhood) das Wirtschaftsmodell von Polkadot verändern?
• Wie ist der technische Fortschritt und das Ziel von Milestone 1? Wann wird das Testnet starten?
• Wie wird ZK (Zero-Knowledge Proofs) in Zukunft mit JAM kombiniert?
• Wie werden das Governance-Modell von JAM und das Gray Paper Editorial Committee die langfristige Entwicklung des Protokolls beeinflussen?

Wenn du mehr über die Zukunft von JAM erfahren möchtest und darüber, wie es die Infrastruktur des Polkadot-Ökosystems neu gestalten wird – diese Ausgabe solltest du nicht verpassen.

Lerne die drei JAM-Entwicklungsteams kennen

Kristen: Hallo zusammen, ich bin Kristen. Heute haben wir drei Kernentwickler von JAM eingeladen, die direkt an der Entwicklung von JAM beteiligt sind. Wenn ihr PolkaWorld oder die neuesten Entwicklungen von Polkadot verfolgt habt, wisst ihr wahrscheinlich, dass derzeit der Web3 Summit stattfindet und Gavin dort einige wichtige Neuigkeiten zu JAM verkündet hat. Auch aus der Community erreichen uns bereits viele Fragen, daher haben wir kurzfristig dieses Live-Interview organisiert, um mit Hilfe unserer drei Gäste der Community einen umfassenden Einblick in die von Gavin auf dem Web3 Summit angekündigten JAM-Inhalte zu geben.

Im ersten Teil möchte ich die drei Gäste bitten, sich kurz vorzustellen, ihren Verantwortungsbereich im JAM-Projekt zu erläutern und den aktuellen Entwicklungsstand zu schildern. Einige Gäste sind bereits alte Bekannte unserer Sendung, aber da immer neue Zuschauer dazukommen, bitte ich euch, euch noch einmal vorzustellen. Fangen wir mit Junha an.

Junha: Danke für die Einladung, Kristen. Hallo zusammen, ich bin Junha und zum ersten Mal in dieser Sendung dabei.

Ich entwickle derzeit die Rust-Implementierung des JAM-Protokolls, das Projekt heißt „FastRoll“. Im Moment besteht mein Team nur aus mir selbst, ich bin also ein unabhängiger Entwickler.

Ich arbeite seit etwa einem Jahr an diesem Projekt und bereite mich gerade auf die Evaluierung des ersten Meilensteins vor, während ich parallel bereits mit einigen Aufgaben für die zweite Phase begonnen habe.

Kristen: Willkommen, Junha! Jetzt bitte ich Bryan, sich vorzustellen.

Bryan: Hallo zusammen, ich bin Bryan vom Acala-Team. Ich leite derzeit ein kleines Team, das eine weitere Implementierung des JAM-Protokolls entwickelt, das Projekt heißt „Boka“.

• Wir arbeiten ebenfalls an der finalen Ausarbeitung der ersten Phase und aktualisieren parallel einige Off-Chain-Komponenten zur Vorbereitung auf die zweite Phase.
• Außerdem haben wir gerade mit der Entwicklung eines PVM-Recompilers begonnen, befinden uns aber noch in einer sehr frühen Phase, bis zur Fertigstellung ist es noch ein weiter Weg.

Kristen: Danke, Bryan, dass du wieder bei uns bist. Bryan war tatsächlich unser erster Gast, der das JAM-Projekt vorgestellt hat, schön, dass du wieder da bist. Zum Schluss begrüßen wir Boy Maas, mit dem wir auch schon ein Interview geführt haben.

Boy Maas: Ja, genau, hallo zusammen, ich bin Boy Maas. Ich bin unabhängiger Entwickler der Zig-Implementierung des JAM-Protokolls, unser Client heißt „JAMZig“.

Außerdem bin ich Mitbegründer eines Projekts im JAM-Ökosystem, dessen Ziel es ist, die Toolchain und die virtuelle Maschine (SVM) von Solana vollständig auf JAM zu migrieren. Wir haben bereits die erste Proof-of-Concept-Phase abgeschlossen, das heißt, einige Grundfunktionen laufen bereits.

Wird JAM in 12 bis 20 Monaten offiziell ausgeliefert?

Kristen: Willkommen, Boy Maas! Polona ist wirklich ein Vorreiterprojekt, das darauf abzielt, Solana-Entwickler ins Polkadot-Ökosystem zu holen – eine großartige Idee! Willkommen an alle drei Gäste.

Meine erste Frage geht an Boy Maas. Du hast am Web3 Summit teilgenommen. Auf Twitter gab es schon viele Nachrichten über Gavins Vortrag, aber ich möchte dich bitten, uns aus deiner Perspektive zu berichten, was du mitgenommen hast. Hast du Gavins Vortrag gesehen? Kannst du uns die wichtigsten Informationen schildern?

Boy Maas: Natürlich, es war wirklich großartig, vor Ort zu sein. Man trifft viele Mitglieder der Polkadot-Community, viele interessante Vorträge vermitteln einem das Gefühl, die Dynamik der gesamten Community zu spüren. Die Atmosphäre ist sehr positiv und voller Energie, das macht Lust auf die Zukunft. Heute ist der letzte Tag, und ich freue mich darauf, diese Erfahrungen mit in unsere Entwicklung zu nehmen.

Kristen: Du hast Gavins Vortrag gesehen, oder?

Boy Maas: Ja, habe ich.

Kristen: Gibt es Inhalte, die dir besonders im Gedächtnis geblieben sind? Auf Twitter haben wir einige Textausschnitte gesehen, aber wir hoffen, dass ihr Entwickler das für alle verständlich erklären könnt.

Boy Maas: Natürlich. Gavin hat in seinem Vortrag viele Themen angesprochen. Er ist ein sehr visionärer Mensch mit viel Erfahrung, daher haben seine Entscheidungen und neuen Ideen großen Einfluss auf die zukünftige Ausrichtung der Community.

Das Wichtigste war, dass er angekündigt hat, dass das Gesamtangebot an JAM-Token auf „π mal 1 Milliarde“ (π × 1.000.000.000) festgelegt wird. Das ist eine sehr bedeutende Entscheidung mit vielen Folgen.

Ein weiterer Schwerpunkt war, dass er der Polkadot-Community klarer vermitteln wollte, was JAM eigentlich ist. JAM ist im Wesentlichen dazu da, das Polkadot-Ökosystem zu stärken und zu unterstützen, es ist als Infrastruktur-Booster für das gesamte Ökosystem positioniert. Tatsächlich haben viele derzeit das Gefühl, JAM noch zu erkunden und sich daran anzupassen: Was ist JAM? Was kann es? Wie arbeitet es mit dem Polkadot-Mainnet zusammen? Wie wird es umgesetzt?

Als Entwickler kennen wir die technischen Details von JAM, aber ich verstehe auch, dass die meisten Leute noch nicht genau wissen, welche Veränderungen JAM bringen wird. Alle versuchen, sich vorzustellen, wie die von JAM angetriebene Zukunft aussehen könnte.

Kristen: Klingt sehr spannend. Mir ist auch aufgefallen, dass Gavin erwähnt hat, JAM werde in 12 bis 20 Monaten offiziell ausgeliefert. Euer Projekt Polona ist vermutlich auch auf diesen Zeitplan angewiesen, oder? Wird euer Entwicklungsfortschritt mit dem Zeitplan von JAM synchronisiert?

Boy Maas: Ja, Kristen, das stimmt genau. Wir haben eigentlich nicht gezielt darauf hingearbeitet, zum Start des Testnets schon alles fertig zu haben, aber nach dem jetzt veröffentlichten Zeitplan passt unser Plan perfekt. Sobald das JAM-Testnet online geht, können wir es sofort nutzen. Und wenn das Netzwerk offiziell läuft, sind wir auch sofort dabei.

Was ist JAMs M1?

Kristen: Sehr schön, das freut mich zu hören. Jetzt möchte ich die nächste Frage an Junha richten.

JAM hat kürzlich ein großes technisches Update veröffentlicht und die Ziele für den ersten Meilenstein (milestone 1) klar definiert. Einige Zuhörer wissen aber noch nicht genau, was milestone 1 eigentlich ist und wie weit die Entwicklung fortgeschritten ist. Kannst du uns erklären, was milestone 1 konkret beinhaltet? Wie ist der Stand beim Testnet? Wann erwartest du den Start?

Junha: Natürlich. Wie du erwähnt hast, wurde das JAM „Gray Paper“ kürzlich auf Version 0.7.0 aktualisiert. Gavin hat in seinem Vortrag auch gesagt, dass ab dieser Version das Polkadot Fellowship mit der Evaluierung von milestone 1 beginnen kann. Die meisten Teams, die an JAM-Node-Clients arbeiten, bereiten sich derzeit auf diese Evaluierung vor.

Das Ziel von milestone 1 ist es, einen Node-Client zu liefern, der „Blöcke korrekt importieren“ kann, also die grundlegendste Runtime-Logik von JAM validiert.

Konkret heißt das: Gegeben eine Reihe von Blöcken (darunter gültige und ungültige), muss der Client erkennen, welche Blöcke das richtige Format haben. Für gültige Blöcke muss der Client die darin enthaltenen externen Daten lesen, die Status-Transformationslogik ausführen (also die Kernlogik der Blockchain-Runtime) und schließlich einen neuen On-Chain-Status erzeugen. Denn eine Blockchain ist im Wesentlichen eine State Machine: Ausgehend von einem Anfangszustand kann durch das Importieren von Blöcken und Ausführen der entsprechenden Logik ein Folgezustand erzeugt werden.

Die Evaluierung von milestone 1 prüft, ob die Node-Implementierung nach dem Import dieser Blöcke einen korrekten Folgezustand erzeugt.

Die Evaluierungsmethode ist ebenfalls sehr direkt: Wir bereiten eine Reihe von Testblöcken vor und vergleichen dann, ob die verschiedenen Implementierungen denselben Folgezustand erzeugen. Dieses Status-Ergebnis kann durch eine „vertical root“ zusammengefasst werden, was den Vergleich sehr einfach macht. Es gibt bereits ein Test-Tool namens JAM Conformance Fuzzer, das automatisch viele Blöcke mit Zufallsdaten generieren und testen kann, ob alle Implementierungen denselben Status-Root liefern.

Ich denke, das ist eine gute Gelegenheit, kritische Bugs zu finden und rechtzeitig zu beheben, um die Grundlage für die nächsten, komplexeren Phasen zu legen.

Kristen: Verstanden. Wann wird das Testnet voraussichtlich starten?

Junha: Du meinst das JAM-Testnet? Einige Teams haben bereits versucht, mit selbst kompilierten Binaries Interoperabilitätstests zwischen Implementierungen durchzuführen, aber meiner Meinung nach wird ein wirklich lauffähiges Testnet erst nach milestone 2 ausgereift sein.

Denn milestone 1 prüft hauptsächlich die Status-Transformationslogik der Nodes, das reicht noch nicht für einen vollständigen Testnet-Betrieb. Erst milestone 2 wird evaluieren, ob die Implementierungen das gesamte Netzwerkprotokoll (networking spec) umgesetzt haben. Dieses Protokoll ist aber noch nicht stabil und steht noch nicht im Gray Paper. Sobald die Netzwerkspezifikation stabil ist und die Implementierungen fertig sind, können Interoperabilitätstests zwischen den Nodes durchgeführt werden.

Dann ist es sinnvoll, das Testnet offiziell vorzubereiten. Natürlich könnten einige Teams schon vorher experimentieren, aber mein persönlicher Plan ist, erst nach milestone 2 am Testnet teilzunehmen.

Kristen: Okay. Glaubst du, dass die neuen Inhalte, die Gavin auf dem Summit vorgestellt hat, deine Entwicklungsfortschritte beeinflussen werden?

Junha: Ich denke, die meisten seiner Ankündigungen sind eher auf die langfristige Vision ausgerichtet, daher wird sich kurzfristig an meinem Entwicklungsplan nicht viel ändern. Mein Fokus liegt weiterhin darauf, milestone 1 abzuschließen, ich rechne damit, dass ich noch einige Wochen oder sogar einen Monat brauche, um eine vollständig konforme Client-Implementierung zu liefern. Daher wird sich meine Strategie vorerst nicht wesentlich ändern.

Natürlich könnten sich diese neuen Richtungen auf längere Sicht (ein bis drei Jahre) auswirken, aber im Moment konzentriere ich mich darauf, milestone 1 gut zu machen.

Welche Auswirkungen hätte PoP als Ersatz für NPoS?

Kristen: Verstanden, danke für deine Einblicke! Jetzt eine „harte“ Frage an Bryan, es geht um die Token-Ökonomie. Wir wissen, dass Entwickler ungern die Effektivität von Wirtschaftsmodellen bewerten, aber das ist eines der Themen, die die Community am meisten interessieren. Gavin hat auf dem Summit angekündigt, dass PoP (Proof of Personhood) NPoS ersetzen wird, dass die Belohnungen für Validatoren fixiert werden und dass ein jährlicher Halving-Mechanismus die Gesamtmenge an DOT begrenzen wird. Wie siehst du als Entwickler diese Veränderungen? Was ist deiner Meinung nach die größte Auswirkung? Unterstützt du das persönlich? Gibt es Bedenken oder Vorschläge?

Bryan: Das ist in der Tat eine große Veränderung.

Lass mich kurz den Hintergrund zusammenfassen: Egal ob Proof of Work (PoW), Proof of Stake (PoS) oder jetzt das vorgeschlagene Proof of Personhood (PoP) – all diese Mechanismen dienen letztlich dazu, die Netzwerksicherheit zu gewährleisten und Angriffe wie Double-Spending oder Chain-Forks zu verhindern.

Jeder Mechanismus hat seine Betriebskosten: Bei PoW sind das die Blockbelohnungen, dazu kommen Strom- und Rechenleistungskosten, bei PoS müssen die Staker belohnt werden.

Das neue Proof of Personhood unterscheidet sich stark im Belohnungssystem. Polkadot hat bisher NPoS (Nominated Proof of Stake) verwendet, das zwar nicht so teuer wie PoW ist, aber dennoch ein Problem hat: Um die Netzwerksicherheit zu gewährleisten, müssen ständig neue Tokens ausgegeben werden, um Validatoren und Nominatoren zu belohnen, was zu Inflation führt.

Mit POP soll das Ziel sein, die Betriebskosten für die Netzwerksicherheit zu senken, nicht mehr auf wirtschaftliche Anreize oder Strafen zu setzen, sondern einen neuen Ansatz zu verfolgen – wie das genau umgesetzt wird, ist noch unklar, aber die Kernidee ist „eine Person, eine Stimme“. Wenn das funktioniert, wird Betrug viel schwieriger, das Netzwerk leichter abzusichern, und es müssen nicht mehr so viele Tokens als Belohnung ausgegeben werden.

Aus Netzwerksicht ist das eine deutliche Kostensenkung, was gut ist. Es gibt aber auch Nebenwirkungen: Viele haben bisher durch Nominierungs-Staking zusätzliche Tokens verdient, dieses Ertragsmodell fällt nun weitgehend weg. Es gibt zwar neue Möglichkeiten, Tokens zu verdienen, aber die Menge wird deutlich geringer. Andererseits: Wenn die Ausgaben des Netzwerks sinken, steigt der Wert der Tokens für die Inhaber, daher sehe ich das insgesamt positiv.

Das könnte auch einen positiven Nebeneffekt haben: Es könnte DeFi fördern. Wenn die Staking-Erträge sinken, könnten Nutzer ihr Kapital in andere DeFi-Protokolle wie Lending oder Liquiditätsbereitstellung umschichten und so das DeFi-Ökosystem beleben.

Natürlich muss man die vollständigen Details abwarten, und selbst dann ist es schwer, alle Auswirkungen genau vorherzusagen. Aber persönlich sehe ich diese Veränderungen eher positiv.

Kristen: Kurzfristig könnte das für Validatoren tatsächlich ein harter Schlag sein, schließlich sinken ihre Einnahmen deutlich. Glaubst du, das wird anfangs zu Problemen führen?

Bryan: Das hängt davon ab, wie der Übergang gestaltet wird. Es wird nicht von einem Tag auf den anderen alles geändert, sondern schrittweise, ähnlich wie beim jährlichen Halving der Token-Versorgung. Die Inflation wird nicht sofort auf null gesenkt, sondern jedes Jahr ein bisschen weniger, sodass alle Zeit haben, sich anzupassen und ihre Strategien zu ändern.

Wir müssen weiterhin die Netzwerksicherheit gewährleisten, die Validatoren müssen zumindest ihre Kosten decken und einen gewissen Gewinn erzielen, und es muss Anreize geben, Validatoren zu nominieren und gute Validatoren auszuwählen. Diese Voraussetzungen bleiben, wir wollen nur nicht mehr so hohe Belohnungen zahlen. Es wird also Veränderungen geben, aber hoffentlich kann das neue Wirtschaftsmodell die Auswirkungen minimieren.

Was ist zkJAM?

Kristen: Stimmt, die Meinungen in der Community sind gespalten. Anfangs forderten alle „weniger Inflation“, jetzt, wo es in Richtung Deflation geht, gibt es wieder Beschwerden. Ich denke, die Richtung ist gut, danke für deine tiefgehenden Einblicke.

Kommen wir zu einem technischen Thema – ZKJAM. Dieses Wort habe ich in Gavins PPT gesehen, es wirkt noch recht konzeptionell. Aber „Zero-Knowledge Proofs“ (ZK) sind in den letzten Jahren im Web3-Bereich sehr angesagt, viele sagen, ZK sei die ultimative Lösung für Rollups und Skalierbarkeit. Wie könnte die Kombination von ZK und JAM in Zukunft aussehen? Ich würde gerne eure Meinungen hören. Junha, fang du an.

Junha: Gerne. Gavin hat JAM in seinem Vortrag als einen dezentralisierten „Super-Bare-Metal-Computer“ beschrieben, und die darauf laufenden Services sind wie Betriebssysteme auf Hardware, etwa Windows oder macOS.

Wenn in Zukunft ZK in JAM integriert wird, wird das aus Sicht von Service- oder App-Entwicklern keine besonders „disruptiven“ Veränderungen bringen, das gesamte Entwicklungs- und Nutzererlebnis sollte weitgehend gleich bleiben.

Selbst wenn das Sicherheitsmodell von JAM von einem „auditbasierten Re-Execution-Modell“ auf ein „ZK-Proof-basiertes Modell“ umgestellt wird, ist das völlig sinnvoll, solange das Upgrade gründlich geprüft und effektiver ist.

Ich denke also, wenn klar ist, dass ZK und JAM gut zusammenpassen und besser sind als die aktuelle Methode, ist das Upgrade sinnvoll und das Gesamterlebnis wird sich kaum ändern.

Kristen: Danke für deine Einschätzung. Ich glaube, einige Zuhörer sind bei den technischen Begriffen schon ausgestiegen, aber keine Sorge, wir werden einen Rückblick auf Chinesisch veröffentlichen, den ihr mehrfach lesen könnt. Jetzt bitte ich Bryan um seine Meinung.

Bryan: Ich denke, man muss zwei Konzepte unterscheiden: Zum einen JAM als Infrastruktur, die ZK-sichere Rollups trägt, zum anderen JAM selbst, das durch ZK abgesichert wird. Das sind zwei völlig verschiedene Dinge.

Über das PVM in JAM kann jeder ZK-bezogene Algorithmus oder jede Architektur, etwa neue ZK-Rollup-Protokolle, als Service auf JAM bereitgestellt werden. Das ist relativ einfach umzusetzen.

Aber wenn JAM selbst durch ZK abgesichert werden soll, erfordert das viel Spitzenforschung und Optimierung bestehender Algorithmen. Im Moment ist das noch sehr „cutting edge“. Es hängt von der aktuellen Lage ab – die Algorithmen sind vielleicht noch nicht schnell oder günstig genug, aber vielleicht erfindet morgen jemand einen Algorithmus, der 100-mal effizienter ist, und alles ändert sich.

Wenn es also in Zukunft wirklich nützliche ZK-Integrationen gibt, die JAM sicherer machen, unterstütze ich das natürlich.

Kristen: Verstanden, hoffentlich gibt es in diesem Bereich echte Durchbrüche. Boy Maas, wie siehst du als erfahrener Entwickler dieses Thema?

Boy Maas: Ich finde, Bryan und Junha haben das schon sehr umfassend erklärt. Einer der Gründe, warum ich JAM mag, ist, dass es ein sehr pragmatisches System ist. Die Designentscheidungen zielen darauf ab, das System wirklich zum Laufen zu bringen und Berechnungen auszuführen. Wie Bryan sagte, ist es derzeit einfach zu teuer und unrealistisch, alles mit ZK zu machen. Ich kann mir vorstellen, dass in Zukunft ein „Hybridmodell“ eingesetzt wird, bei dem traditionelle Audit-Methoden und ZK parallel genutzt werden.

Im Moment sind die Kosten für ZK zu hoch und es ist zu unpraktisch, aber in den nächsten 12 Monaten bis 5 Jahren wird sich im ZK-Bereich sicher viel tun. Wenn ZK wirklich effizient wird, ist das eine sehr attraktive Technologie, die unser gesamtes Sicherheitsmodell und die Architektur neu definieren könnte.

Aber aktuell ist ein Hybridmodell wohl realistischer: Es bleibt praktisch, und Anwendungen, die wirklich ZK-Sicherheit brauchen, können diese Technologie nutzen.

JAM wird ein Gray Paper Editorial Committee gründen

Kristen: Danke für eure Einschätzungen. Kommen wir zum nächsten Thema: das Governance-Modell von JAM.

Gavin wird weiterhin Chefredakteur des Gray Paper bleiben und hat angekündigt, ein „Gray Paper Editorial Committee“ zu gründen, das aus technisch versierten Beitragenden besteht, die tief in die JAM-Entwicklung involviert sind. Dieses Komitee wird künftig gemeinsam über Updates, Prioritäten und wichtige Entscheidungen des JAM-Protokolls bestimmen. Was haltet ihr als Entwickler von dieser Form der Protokoll-Governance? Besteht die Gefahr, dass man vom ursprünglichen Ziel abweicht? Wie sollte man damit umgehen? Boy Maas, fang du an.

Boy Maas: Ich finde, das ist eine sehr sinnvolle Frage. In einem so hochspezialisierten Bereich ist es absolut vernünftig und notwendig, ein Komitee für die Aktualisierung des Gray Paper zu haben. Diejenigen, die diese Entscheidungen treffen, müssen die JAM-Grundlagen sehr gut verstehen und langjährige Praxiserfahrung haben, um kluge Entscheidungen zu treffen. Dass Gründer Gavin dieses Komitee leitet, ist sehr sinnvoll, daher unterstütze ich diese Governance-Form voll und ganz.

Kristen: Du findest also, dass es gut ist, wenn ein professionelles Team kollektiv über das Protokoll entscheidet?

Boy Maas: Ja, absolut.

Kristen: Okay, Bryan, wie siehst du das?

Bryan: Im Grunde werden alle Projekte von irgendeiner Art „Komitee“ gesteuert, nur Größe und Mitglieder unterscheiden sich. Der Unterschied ist, ob der Governance-Prozess klar definiert ist.

Ich finde, allein schon den Governance-Prozess klar aufzuschreiben, ist ein Fortschritt. So weiß jeder, wie Updates entschieden werden, das erhöht die Transparenz und erleichtert die spätere Optimierung des Prozesses. Wenn es keine Regeln gibt, kann man auch nichts verbessern.

Der Inhalt des Gray Paper ist sehr komplex, fast alle Entwickler der JAM-Implementierungen haben verschiedene Versionen mehrfach gelesen. Aber ehrlich gesagt, versteht wahrscheinlich niemand außer Gavin alles zu 100 %, vielleicht nicht einmal Gavin selbst. Viele Leute beteiligen sich an der Überarbeitung der Dokumente, etwa durch Korrekturen, Formeländerungen oder Logikoptimierungen – das ist ein kollaborativer Prozess.

Ich denke, nur Leute mit jahrelanger Erfahrung in diesem Bereich sollten das Gray Paper ändern. Eine kleine Änderung kann große Auswirkungen haben. Es geht um die Zukunft von Web3, sogar des Internets, und um die Sicherheit vieler Assets – da muss man sehr vorsichtig sein. Transparenz und Offenheit sind wichtig. Jeder kann Vorschläge machen, aber man muss beweisen, dass man den Vorschlag wirklich verstanden hat, sonst gehen sinnvolle Beiträge im Lärm unter.

Kristen: Das heißt, das Komitee braucht auch einen Mechanismus, etwa wer Mitglied werden kann, wie die Mitglieder organisiert werden usw. Jeder hat seine Meinung, ohne Regeln entstehen leicht Meinungsverschiedenheiten oder man weicht vom Ziel ab.

Bryan: Deshalb brauchen wir Smart Contracts und klare Prozesse, alles muss schriftlich festgehalten werden. Wenn die Regeln schwarz auf weiß stehen, kann jeder die Einhaltung überwachen, alles ist transparent, dann ist die Gefahr des Abweichens viel geringer. Wenn alles hinter verschlossenen Türen passiert, weiß niemand, was passiert, dann ist die Gefahr groß. Transparenz ist entscheidend, besonders wenn Prozesse durch Smart Contracts durchgesetzt werden können, dann kann dieses System langfristig bestehen.

Kristen: Verstanden, ich erinnere mich, dass auch die Bitcoin-Community ein Entwicklerkomitee zur Weiterentwicklung hat.

Bryan: Ja, die Bitcoin-Community hat einen Kernentwicklerkreis, aber die endgültige Entscheidung wird durch Forks getroffen – die Kette mit der meisten Hashpower gewinnt.

Kristen: Verstanden, danke für die Erklärung. Zum Schluss hören wir noch Junhas Meinung zu diesem Thema.

Junha: Ich finde, die Gründung eines Editorial Committee ist ein sehr natürlicher und sinnvoller Schritt. JAM ist ein besonderes Projekt: Noch bevor eine lauffähige Software entwickelt wurde, wurde ein vollständiges technisches Spezifikationsdokument (Gray Paper) veröffentlicht. Dieses Dokument enthält viele mathematische Formeln zur Definition des Systemverhaltens. Die Dokumentation vor der Entwicklung dient dem Ziel höherer Dezentralisierung und Systemresilienz.

Deshalb wurde das Gray Paper seit seiner Veröffentlichung mehrfach überarbeitet und wird auch nach Version 1.0 weiter angepasst werden.

Mit mehr Teams, die das JAM-Protokoll implementieren und Testnets aufbauen, werden wir sicher Bereiche finden, die weiter optimiert werden können, um die Protokollausführung effizienter oder praktikabler zu machen. Aufgrund der Natur des JAM-Projekts wird das Gray Paper auch nach dem Mainnet-Start noch Monate lang weiterentwickelt, vielleicht gibt es sogar Hard Forks.

In so einem Fall ist es offensichtlich besser, wenn mehrere Leute gemeinsam für die Entwicklung der Protokoll-Spezifikation verantwortlich sind, als wenn nur der Autor allein entscheidet.

Wie Bryan sagte, ist Transparenz sehr wichtig, der Entscheidungsprozess des Komitees muss öffentlich sein. Ich hoffe auch, dass mehr Teams, die das JAM-Protokoll nutzen, sich aktiv an der Dokumentenprüfung, Korrektur und am Feedback beteiligen, statt einfach „zu glauben, dass Gavin immer Recht hat“. Durch diese aktive Beteiligung können Verbesserungen gefunden werden. Das ist ein guter Anfang und vielversprechend. Angesichts der Besonderheiten des JAM-Projekts ist diese fortlaufende Verbesserung der Spezifikation sehr natürlich und sinnvoll.

Wir unterschätzen vielleicht, was JAM für die Blockchain bringen wird

Kristen: Okay, das ist wirklich ein guter Anfang. Wenn der gesamte Prozess transparent ist, wäre das großartig. Danke für eure Beiträge, ich denke, wir haben alle heutigen Themen besprochen.

Zum Abschluss: Gibt es noch etwas, das ihr ergänzen möchtet? Zu JAM, zum Web3 Summit – irgendetwas, das ihr noch sagen wolltet, aber bisher nicht konntet? Fangen wir mit Bryan an.

Bryan: Ich habe nichts Besonderes mehr hinzuzufügen. JAM ist eine grundlegende Infrastruktur, sie ist zwar wichtig, aber nicht alles. Wirklich wichtig sind die Services und Anwendungen, die auf JAM aufbauen – die Nutzer werden JAM nicht direkt verwenden, sondern die darauf basierenden Services.

Die Einführung von JAM ist also nur der erste Schritt zum eigentlichen Ziel. Wir sollten uns mehr auf die Services und Anwendungen konzentrieren, die auf JAM laufen, denn sie beeinflussen die Nutzer wirklich. Es gibt also noch viel zu tun, und unser Fokus sollte nicht nur auf dem JAM-Kernprotokoll liegen, sondern auch auf allem, was darauf aufgebaut wird.

Kristen: Danke dir. Boy Maas, möchtest du noch etwas zu Polona oder JAM ergänzen?

Boy Maas: Natürlich. Zuerst möchte ich noch etwas zu JAM sagen. Ich erinnere mich, dass Gavin in Lissabon einmal über JAM gesprochen hat. Damals hatte ich das starke Gefühl, dass wir vielleicht unterschätzen, was diese Plattform für die Blockchain-Community bringen wird.

Die „Bandbreite“ und Flexibilität, die JAM bietet, hat bisher keine andere Blockchain erreicht. Ich denke, es ist bereits ein wichtiger Meilenstein in der Entwicklung der Blockchain, besonders was die neuen Anwendungen betrifft, die darauf möglich sind – das ist wirklich einzigartig.

Außerdem ein Update zu unserem Polona-Projekt: Wir machen große Fortschritte, wir haben bereits eine Proof-of-Concept-Version auf JAM laufen. Wir haben die Solana SVM auf das PVM portiert, das heißt, du kannst jetzt direkt Solana-Bytecode auf JAM ausführen, inklusive Cross-Contract-Calls – alles funktioniert, das ist wirklich cool. Das zeigt auch die Leistungsfähigkeit der JAM-Services.

Kristen: Großartig, danke! Zum Schluss noch Junha, möchtest du etwas ergänzen?

Junha: Ich hoffe, dass mehr Leute anfangen, sich für JAM, Polkadot und das Gray Paper zu interessieren. Ich würde wirklich gerne mit mehr Menschen in Kontakt treten und Ideen austauschen.

Die JAM-Clients sind noch in der Entwicklung, daher gibt es noch nicht viele „fertige“ Anwendungsbeispiele. Das Team von Gavin hat einige Demos gezeigt, aber es gibt noch nicht viele echte Praxisbeispiele, die wirklich „überzeugen“, was das System leisten kann.

Aber ich denke, wenn du dich für die Ideen hinter Web3 interessierst und die Branche wirklich voranbringen willst, dann ist JAM ein sehr lohnenswertes Projekt für eine tiefere Beschäftigung. Ich arbeite derzeit allein an diesem Projekt, daher würde ich mich sehr freuen, mehr Gleichgesinnte kennenzulernen – selbst wenn wir nur gemeinsam das Gray Paper lesen und diskutieren. Ich hoffe, wir können Ideen austauschen und vielleicht gemeinsam etwas Neues aufbauen, besonders nach der Fertigstellung der Node-Auslieferung.

Kristen: Danke für deinen Beitrag und vielen Dank an alle Gäste für die spannenden Ansichten und Einsichten heute! Danke an alle Zuhörer für eure Teilnahme, folgt gerne den Twitter-Accounts unserer Gäste, die ihr in der PolkaWorld-Ankündigung findet. Egal ob ihr normale Nutzer oder Entwickler seid, es lohnt sich, die neuesten Entwicklungen rund um JAM zu verfolgen. Danke fürs Zuhören, bis zum nächsten Mal! Auf Wiedersehen!