Autor: Marco González
Redakteur: Randall Roland

Übersetzer: Markus Hinrichs

Knotenbetreiber, Entwickler des Antelope-Kerns und Mitglieder der Community treffen sich jede Woche, um die fesselnden Fragen des Tages zu diskutieren. Das Hauptziel jeder Runde der Knotenbetreiber ist:

Die Roundtables finden jeden Mittwoch statt. Besuche den Telegram-Kanal für Informationen zur Teilnahme. Die EOS Network Foundation bietet Tutorials und Dokumentationen für diejenigen an, die die Grundlagen des Betriebs eines EOS-Knotens (und mehr) erlernen möchten.

Im Folgenden findest du eine Liste der Runden innerhalb dieses halbmonatlichen Überblicks:

Weitere Besprechungsnotizen und Kommentare findest du auf GitHub. Videos sind auf dem YouTube-Kanal der ENF verfügbar.

Die Runde vom 2. August wurde nicht aufgezeichnet. Im Folgenden findest du eine offene Diskussion darüber, was in den Wochen vor dem Konsens-Upgrade auf Antelope Leap 5.0 zu erwarten ist. Angesichts der kritischen Natur und des gewünschten Zeitplans wird erwartet, dass die Runde formeller wird (ähnlich der Diskussion zu 3.0 Zeiten).

Die Planung für ein Konsens-Upgrade wurde in den letzten Wochen angesprochen. Der nächste Roundtable soll den Startplan vorstellen.

Der Zeitplan für den Leap 5.0-Start wird wesentliche und nicht wesentliche Elemente hervorheben. Einige Funktionen scheinen bereit zu sein, während bei anderen noch Fragen offen sind. Nur wenige Punkte könnten eine Verzögerung des Starts rechtfertigen. Instant Finality (IF) ist ein entscheidendes Startelement. Sie bleibt der Fokus der Diskussionen in der Runde während der frühen Phase.

Die Community-Diskussionen sollten sich auch auf folgende Punkte konzentrieren:

Während auf die Ankündigung des Zeitplans gewartet wird, hat die Community einige bemerkenswerte Punkte identifiziert. Die Rückmeldung von Michael von EOSUSA stand im Vordergrund:

Während die ENF eine hervorragende Arbeit bei der Verbesserung der Kern-Dokumentation auf docs.eosnetwork.com geleistet hat, bietet Leap 5.0 eine einzigartige Gelegenheit. Konsens-Upgrades sind herausfordernd, weil immense Anstrengungen erforderlich sind, um mit allen (aktiven) Parteien zu koordinieren. Blockproduzenten müssen innerhalb eines vereinbarten Zeitrahmens gemeinsam handeln, um eine Multisignatur abzuschließen. Die Konfiguration von Geräten betrifft sowohl Blockproduzenten als auch Knotenbetreiber.

Das Ziel ist der Erhalt eines sicheren und reibungslos funktionierenden Netzwerks. Eine weitere Initiative für v5.0 ist die Festlegung eines neuen Standards für den Konsens-Upgrade-Prozess. Neue Dokumentation ist integraler Bestandteil dieser Bemühungen. Einige Vorschläge für die neue Dokumentation umfassen Konfigurationsänderungen zwischen Versionen und die Einführung neuer Funktionen (z.B. ein Optimierender Compiler). Ebenfalls vorgeschlagen wurden Hinweise auf Konfigurationen, die spezifisch für vorherige Änderungen (für Versionen 4.0) sind und den Übergang zur Version 5.0 erleichtern.

Erwarte, dass die nächste Runde eine formellere Atmosphäre annimmt, ähnlich der Monate, die für die Entwicklung und den Start von Version 3.0 benötigt wurden, dem bahnbrechenden Produkt der ENF. Die kombinierte Geschwindigkeit und Qualität der jüngsten Produkte der Stiftung (von mehreren Versionen 4.0 bis jetzt 5.0) ist schlichtweg beeindruckend.

Die Runde vom 9. August wurde aufgezeichnet und ist verfügbar. Die ENF hat ihren Plan zur Einführung von Leap v5.0 geteilt.

Die wichtigsten Themen, die in der Runde vom 9. August diskutiert wurden, sind:

Während sich die Daten ändern können, repräsentiert der Zeitplan, der in der Runde vom 9. August vorgestellt wurde, die Reihenfolge der Operationen für den Start von Leap v5.0.

Der erste große Meilenstein ist für Mitte September mit dem Veröffentlichungskandidaten (5.0.0-rc1) geplant. Mehrere Aufgaben müssen abgeschlossen sein, bevor von den Blockproduzenten die Entscheidung zur Durchführung oder Absage getroffen wird. Dazu gehören:

Die Entscheidung zur Durchführung oder Absage hängt von der Aktivierung durch die Blockproduzenten ab. Diese Entscheidung ist vorläufig für Ende November / Anfang Dezember geplant. Der Systemvertrag muss aktualisiert werden, bevor die Sofortige Finalität aktiviert werden kann. Von der Aktivierung bis zur Implementierung der Sofortigen Finalität wird etwa eine Woche vergehen. Hoffentlich wird IF bis Anfang Dezember auf EOS aktiviert und in Betrieb genommen.

Die Community erwartet, zukünftige Terminplanungsdiskussionen zu leiten. Peer Discovery und schreibgeschützte Transaktionen werden den Start von Leap v5.0 voraussichtlich nicht verzögern. Das Team erwartet bis September ein festes, halbfestes Startdatum zu haben.

Neben der IF ist Replay Testing die andere Funktion, die den Startplan wesentlich beeinflussen könnte (siehe Runde vom 2. August).

Ein interessantes Thema wird etwa ab Minute 7 diskutiert. Die Diskussion drehte sich um die Veröffentlichung eines Veröffentlichungskandidaten und den Wiederholungstest. Ein wesentlicher Bestandteil wird der Vergleich der Integritäts-Hashes aufeinanderfolgender Schnappschüsse plus Blockwiederholungen sein. Beachte, dass ein Upgrade auf Leap v5.0 keine Neu-Synchronisierung des Blocklogs erfordert.

Es bleiben Probleme beim Durchführen eines vollständigen Genesis-Wiederholungstests. Michael von EOSUSA brachte die (inzwischen behobenen) Probleme mit Regressionen und die Zeit bis zur Fertigstellung zur Sprache. Das Entwicklungsteam konzentriert sich darauf, v5.0 mit einer Blocks-Log-Wiederholung zu starten. Die Untersuchung von Genesis-Wiederholungen ist etwas, das das Team für ein zukünftiges Upgrade im Auge behalten hat.

Eine weitere lebhafte Diskussion begann, als das Kylin-Testnet erwähnt wurde. Mathew von EOS Nation empfahl, dass Kylin nicht parallel zum Jungle-Testnet betrieben wird. Es folgte eine Änderung des Zeitplans, um die Zieltermine beizubehalten und eine Kylin-Testrunde bis Mitte Oktober einzubeziehen. Die Tests müssen vor der geplanten stabilen Veröffentlichung von Leap v5.0.0 vor November abgeschlossen sein.

Zurückgestellte Transaktionen sind nun veraltet. Idealerweise sollten sie für v5.0 entfernt werden. Wenn zurückgestellte Transaktionen in v5.0 bleiben, könnten sie noch ein weiteres Jahr bestehen bleiben. Es ist unbekannt, ob einige Verträge von ihnen abhängig sind.

Zwei Entscheidungen werden geprüft, um zurückgestellte Transaktionen zu entfernen. Die erste Lösung ermöglicht ein Zurückdrehen. Es würde jedoch viel Zeit erfordern, um sie umzusetzen. Die andere, vernünftigere Option sieht vor, dass Blockproduzenten einen Test durchführen, bei dem die Funktion kurzzeitig deaktiviert wird. Dann könnte das Feedback der Community über das Schicksal der zurückgestellten Transaktionen entscheiden. Es ist nicht bekannt, ob Projekte von zurückgestellten Transaktionen abhängen.

Für die nächste Woche erwarte erneut, dass die Diskussion um den Start von Antelope Leap v5.0 im Mittelpunkt steht.