JAM ist nach 2.0, es wird gerade beschleunigt entwickelt, mit über 30 Teams, verschiedenen Programmiersprachen und unterschiedlichen Entwicklungsteams, um einen dezentralen JAM-Client (basierend auf dem JAM-Graupapierprotokoll) zu realisieren. Das früheste ETH erforderte, dass alle Transaktionen von allen Validierern einmal validiert werden (dieser Teil kann tatsächlich im Ethereum-Graupapier nachgelesen werden, es gibt auch eine bessere Interpretationsversion). L2 ermöglicht es, dass ein kleinerer Teil außerhalb der Kette Berechnungen durchführt, auf zwei Arten: Eine Art von L2 ist Betrugsnachweis (nach Entdeckung von Betrug wird der Transaktionscode erneut ausgeführt, um zu validieren), die andere Art von L2 ist zk-Nachweis, der keine Wiederholung der Berechnung erfordert, aber teure GPUs für die Generierung des Nachweises benötigt; auf der Kette wird nur der Nachweis validiert, ohne den vorherigen Transaktionsumwandlungsfunktionscode erneut auszuführen. Früher verwendete @Polkadot 1.0 einen Algorithmus namens ELVES, der im Gegensatz zum Betrugsalgorithmus von ETH passiv validiert, sondern einen probabilistischen Algorithmus zur aktiven Validierung verwendet. Bei @polkadot 2.0 wurde die Validierungsgruppe bereits zu einem Konzept namens Core verpackt, das im Wesentlichen eine Teilmenge der Validierungsgruppe ist. 2.0 unterstützt Agile Coretime, was bedeutet, dass Core dynamisch verwendet werden kann; in 1.0 konnte eine Kette nur einen Core verwenden, nach dem bevorstehenden Start von 2.0 kann eine Kette je nach Bedarf Coretime (Anzahl der Validierungsuntergruppen) dynamisch verwenden, um die Servicebelastung des Systems zu erhöhen. JAM entwickelt sich auf der Grundlage dieser Ideen weiter und es gibt so viele zk, op, Smart Contracts und sogar normale web2-artige zustandslose Anwendungen. Kann man die Dienste weiter abstrahieren, um sich besser an diese unterschiedlichen Anwendungsmodelle anzupassen und eine kombinierte Interaktion zwischen ihnen zu ermöglichen? Daher hat JAM auf dieser Grundlage eine weitere Abstraktion vorgenommen. - Verschiedene Arten von L2/Parallelketten werden jetzt als Dienste bezeichnet. - Block-/Transaktionssachen werden jetzt als Arbeitsitems oder Arbeitspakete bezeichnet. - Arbeitsitems gehören zu den Diensten, während Arbeitspakete eine Gruppe von Arbeitsitems sind. - Dienste werden durch drei Einstiegspunkte beschrieben, von denen zwei fn refine() und fn accumulated sind. - Diese beiden Einstiegspunkte sind der Grund, warum das Protokoll JAM genannt wird: Join Accumulate Machine. Join bezieht sich auf fn refine(), alle Polkadot-Kerne führen parallel eine große Menge an Arbeiten für verschiedene Dienste aus. Join bedeutet, Daten in eine kleinere Teilmenge zu verfeinern und dann an die nächste Phase weiterzugeben. - Accumulate bedeutet, die Ergebnisse aller oben genannten Operationen im Haupt-JAM-Zustand zu akkumulieren. - Verschiedene Formen von Diensten werden unterstützt (op rollups, zkrollups, Parallelketten, zustandslose Anwendungen, Smart Contracts). Die ETH-Ära war eine gemeinsame Zustandsmaschine mit einer einzigen Spalte, Die @polkadot 1.0-Ära war eine interoperable probabilistische Sharding-Maschine. Die @polkadot 2.0-Ära ist eine Agile Coretime-Maschine. Die JAM-Ära ist die Join Accumulate Machine (JAM). Es gibt viele weitere Details und Eigenschaften, hier habe ich nur die Informationen synchronisiert, die ich verstanden habe. Ein tieferes Verständnis dafür, warum JAM Programme kontinuierlich ausführen kann, ohne dass Transaktionen erforderlich sind, um Programme zu aktivieren, welche neuen Modellen und Produkten in Zukunft in Kombination mit DEFI entstehen könnten? Warum kann JAM zustandslose Anwendungen wie JAM DOOM ausführen? Weitere Informationen finden Sie im Video: Lernmaterialien: