Autor: Marco González
Redakteur: Randall Roland
Übersetzung: Markus Hinrichs
Jede Woche treffen sich Node Operators, Antelope Kernentwickler und Community-Mitglieder, um die spannenden Fragen des Tages zu diskutieren. Das Hauptziel jedes Node Operator Roundtable ist:
„… die Verbesserung des Antelope-Protokolls (speziell) für Knotenbetreiber“.
Die Treffen finden jeden Mittwoch von 14 UTC bis 15 UTC (13 UTC bis 14 UTC während der Sommerzeit) statt. Die EOS Network Foundation bietet Anleitungen und Dokumentationen für diejenigen, die die Grundlagen des Betriebs eines EOS-Knotens (und mehr) erlernen möchten.
Im Folgenden eine Übersicht über die beiden Rundtischgespräche, die in dieser halbmonatlichen Zusammenfassung enthalten sind:
21. Juni: P2P-Verbesserungen – Dokument mit Auflistung des Problems und der Lösungen
28. Juni: Block Trimming, Planung für Leap 5.0, IF, OC
Weitere Sitzungsnotizen und Kommentare befinden sich auf GitHub. Videoaufzeichnungen befinden sich auf dem YT der ENF.
21. Juni: P2P-Verbesserungen Dokument mit Auflistung des Problems, Lösungen
In der Sitzung am 21. Juni wurde die P2P-Diskussion fortgesetzt. Ein GitHub-Dokument, das einige der Rückmeldungen der letzten Wochen aufgreift, diente als Diskussionsgrundlage.
Übersicht
Im Leitdokument wird das Problem klar definiert. Die Definition einer akzeptablen Lösung deckt sich eng mit dem bisherigen Feedback.
Updates
Der Leap 4.0.3 Patch wurde während des Treffens veröffentlicht
Aufgliederung des Leitfadens zu P2P-Verbesserungen
Die Seite des Leitfadens gliedert sich in mehrere Abschnitte: das Problem, die Lösung, die Issues, die Ressourcen und die Kommentare.
Problem: Möglichkeiten, Zielgruppe und Strategie
Es gibt unterschiedliche Bedürfnisse für bestimmte Benutzergruppen. Die Prioritäten werden nun besser verstanden.
Die identifizierte Zielgruppe ist Antelope-basiert und:
„Technisch versierte Personen“ (Knotenbetreiber), die an „zuverlässigen, kostengünstigen und vereinfachten Lösungen“ interessiert sind.
Um das Problem mit der Kernentwicklung in Einklang zu bringen, muss der Schwerpunkt auf der „Verbesserung der Benutzererfahrung und der Effizienz der Infrastruktur“ liegen. Von einer erfolgreichen Umsetzung verspricht man sich eine „breitere Akzeptanz und den Erfolg des Antelope-Protokolls“.
Bei der Rückkehr zu den Möglichkeiten der Zielbenutzer stehen folgende Prioritäten im Vordergrund:
Ganz oben auf der Liste steht die „Verbesserung der Peer-Auswahl im Catch-Up-Modus für verfügbare Blöcke“.
Die Bandbreite war in den letzten Wochen ein häufig diskutiertes Thema. Eine bessere Kontrolle des „Peer-Bandbreitenverbrauchs“ ist die nächste Priorität. Die Vermeidung von Missbräuchen und die automatische Rotation der Peers sind Schwerpunkte.
Die dritte große Priorität ist die „Möglichkeit, Peer-Verbindungen als intern oder extern zu kennzeichnen“. Hier wird erwartet, dass das Problem des „Vertrauens (Ebenen) innerhalb der internen Infrastruktur“ gelöst wird.
Im Dokument und/oder im Video werden weitere Themen wie eine terminalbasierte Benutzeroberfläche, schwarze Listen von Peers und Synchronisierung beschrieben.
Lösungssuche und Identifizierung von Risiken
Der Name der oben beschriebenen Produktmöglichkeit lautet „P2P-Verbesserungen“. Die vier primären Erfolgskriterien, die im GitHub-Dokument aufgeführt sind:
Verbesserung der Synchronisierungszeit für einen neuen oder neu gestarteten Knoten
Verringerung der Anzahl der Schritte, um einen neuen Knoten zu konfigurieren
Verbesserung der Zuverlässigkeit von Transaktionen, die das P2P-Netzwerk durchlaufen
Verbesserung der Geschwindigkeit der Transaktionen, die das P2P-Netzwerk durchlaufen
Der Prozess der Identifizierung von Risiken orientiert sich an einem Artikel („Die vier großen Risiken“), der von der Silicon Valley Project Group verfasst wurde. Die darin gestellte Frage bezieht sich auf P2P Peer Discovery RFP in Bezug auf parallele Zeitpläne:
„Besteht das Risiko von Konflikten oder Überschneidungen?“
Auf der Dokumentationsseite stehen weitere Ressourcen und Fragen zur Verfügung.
Kommentare und Feedback zum Treffen
Die Antworten der Teilnehmer umfassen:
interne Knotenpunkte und Engpässe
Speichergeschwindigkeit ist entscheidend
bloks-log wurde als Problem in Bezug auf das Lesen und lokale Peers erwähnt (z. B. Anzahl der Operationen und Synchronisierung)
begrenzte Synchronisierungsoptionen
Bandbreite vs. Reichweite des Status (bei ausreichender Bandbreite und rotierenden Peers möglicherweise kein Problem)
Abschließender Dialog
Die Sitzung endete mit klärenden Fragen. Es wurde eine Anfrage zur Drosselung (Verlangsamung) als Bandbreitenmanagementstrategie gestellt. Aus den Rückmeldungen geht hervor, dass die Drosselung eine Option im Gegensatz zur Abschaltung von Peers ist.
Das Entwicklungsteam bittet die Betreiber der Knotenpunkte, die nächsten Schritte mitzubestimmen. Die Aufmerksamkeit wurde auf die Aufschlüsselung der Aufgaben („Features/Epics“) auf der Dokumentenseite gelenkt. Hier wurden Bandbreite und Kontrollmechanismen erwähnt.
28. Juni: Block Trimming, Planung für Leap 5.0, IF, OC
In der Sitzung vom 28. Juni wurde das Block Trimming als verbesserungswürdiger Bereich identifiziert. Die Planung für Leap 5.0 umfasst Vorbereitungszeit, neue Standards, IF, OC und mehr.
Überblick
Knotenbetreiber tauschten ihre Erfahrungen mit dem derzeitigen Blocktrimmverfahren aus. Diagnostik, Automatisierung und weitere Lösungstypen wurden diskutiert. Im letzten Drittel der Sitzung wurden Planung und Vorbereitungen für Leap 5.0 erörtert.
Updates
es gibt keine neuen Updates zu Leap 4.0
das Entwicklungsteam arbeitet weiter an einem vorläufigen Zeitplan für einen Veröffentlichungskandidaten für 5.0
Mehr über Leap 5.0 in einem späteren Abschnitt.
Anliegen der Community
Das Wort wurde ergriffen, um die Anliegen zu hören, die der Community auf den Nägeln brennen. Die Diskussion begann mit dem Trimmen von Blöcken und den unterschiedlichen Problemen zwischen der aktuellen Version 4.0.3 und der erwarteten Version 5.0. Das Trimmen von Blöcken stieß sofort auf Interesse. Die Verwendung des leap-util zum Trimmen einer Lösung für eine bloks-log-Ausnahme zog mehrere Kommentare nach sich. Die Notwendigkeit, das Trimmen auf mehrere hundert Blöcke auszuweiten, scheint verbesserungswürdig zu sein. Kleinere Trims, die die Fehler (Ausnahmen) identifizieren können, sind eine attraktive Funktion, die man hinzufügen könnte.
Tiefergehend diskutierte Themen
Zwei Themen schienen aus dem Eröffnungsdiskurs hervorzugehen:
Formatierung und Inhalt von leap-util (z. B. Smoke-Test)
Notwendigkeit eines Rollbacks von bloks-log
Im Folgenden ist eine Liste der angesprochenen Themen aufgeführt. Die Listenpunkte folgen einer allgemeinen chronologischen und logischen Reihenfolge, wie sie in der Sitzung aufgezeichnet wurde:
Anzeige vs. Funktionalität
Mögliche Verbesserungen für minimales Trimmen
Gewährleistung einer sicheren Lösung
Vorschlag, sukzessives (einzelnes) Beschneiden hinzuzufügen
ein Werkzeug zur Trimm-Diagnose könnte beschädigte Blöcke ermitteln
eine automatische Reparaturlösung, die darauf achtet, dass keine Blöcke automatisch entfernt werden
Lösungen für öffentliche vs. private Knoten
Vollständige Behebung per Snapshot verweist auf Vorsichtsmaßnahmen bezüglich öffentlicher vs. privater Knoten
Die Community scheint sich einfachere Diagnose- und Wiederherstellungswerkzeuge zu wünschen. Für weitere Details besuche leap-util is unable to successfully run a detailed smoke test and trim the blocklog. #1348.
PLANUNG FÜR LEAP 5.0
Wie bereits erwähnt, hat die Planung für einen Leap 5.0 Veröffentlichungskandidaten begonnen. Das Entwicklungsteam arbeitet daran, den langen, komplizierten Prozess eines Konsens-Upgrades zu entschärfen. Leap 5.0 wird ein Standardverfahren einführen. Es werden einige Monate benötigt, um die Community vorzubereiten. Geplant ist eine Veröffentlichung vor den Feiertagen, d. h. die Einführung beginnt im September.
Es wird davon ausgegangen, dass Leap zwei größere Releases pro Jahr erfahren wird. Eine davon wird wahrscheinlich ein Konsens-Upgrade erfordern. Eines der Hauptanliegen ist die Senkung der Betriebskosten der Knotenpunkte. Dazu gehören auch Kostensenkungen für Knotenbetreiber beim Hinzufügen neuer Ketten. Es wurden Kommentare zu den Vorteilen von Erfahrung und Optimierung (RAM, CPU und Festplattenplatz) abgegeben. Es wurde betont, wie wichtig es ist, dass mehr Anwender ein Upgrade auf 4.0 durchführen.
Zwei primäre Protokoll-Upgrade-Funktionen für 5.0 sind:
Instant Finality (IF)
Optimizing Compiler (OC)-Funktionen
IF scheint der entscheidende Punkt von beiden zu sein. IF bleibt eine Schlüsselinitiative des ursprünglichen ENF-Plans für das neue EOS. OC-Funktionen sind Leistungsvorteile, die in erster Linie die EVM verbessern sollen. Es gibt jedoch auch allgemeine OC-Vorteile, die die Hersteller einschließen. Siehe Add eos-vm-oc-enable auto mode #1322 für weitere Informationen.
Andere Punkte werden parallel entwickelt und in zukünftigen Versionen erwartet, um 5.0 nicht zu verzögern.
Abschließender Dialog
Das Treffen schließt mit einer Untersuchung der OC-Funktionen für 5.0. Die aktuelle Entwicklung befasst sich mit grundlegenden Verbesserungen. OC soll zunächst auf eosio-Systemverträgen (z. B. für Token und EOS EVM) laufen, bevor die anderen erwähnten Funktionen folgen. Neue Funktionen und die Vorbereitung auf Leap 5.0 werden wahrscheinlich im Mittelpunkt zukünftiger Treffen stehen.