Author: Marco Gonzàlez
Redakteur: Randall Roland
Jede Woche treffen sich die Node Operators, Antelope-Kernentwickler und Community-Mitglieder, um die spannenden Fragen des Tages zu diskutieren. Das Hauptziel jedes Node Operator Roundtables ist:
"...das Antelope-Protokoll (speziell) für Knotenbetreiber zu verbessern".
Die Treffen finden jeden Mittwoch von 14 bis 15 Uhr UTC statt.
Ab dem 1. Februar konzentrierten sich die Diskussionen am Knotenbetreiber-Rundtisch auf Konfigurationsparameter für Leap v3.2 und darüber hinaus. Special Purpose Nodes wurden am 8. Februar aufgenommen. Die Sitzungen am 15. und 22. Februar wurden für "Knoten für Spezialzwecke" genutzt. Die Gruppe arbeitete weiter an dem Dokument draft taxonomy of the roles that different antelope nodes play" (Entwurf einer Taxonomie der Rollen, die verschiedene Antilopen-Knoten spielen).
15. Februar: Knoten für besondere Zwecke (Fortsetzung) - API-Knoten
Sieh dir die Diskussionsrunde vom 15. Februar auf dem YouTube-Kanal der ENF an. Lies auch die Notizen auf EOS Nation (Leap) GitHub.
UPDATE:
Wie bereits besprochen, wird Leap v4.0.0 voraussichtlich im März mit den Tests auf dem Jungle Testnet beginnen. Ein Konsens-Upgrade wird wahrscheinlich nicht vor September stattfinden. Erwarte außerdem ein Einfrieren des Codes vor den frühen Tests in den kommenden Wochen.
ERÖRTERTE SCHLÜSSELTHEMEN
Bei der letzten Sitzung ging es um API-Knoten. In der Sitzung vom 15. Februar wurden die grundlegenden Definitionen für Knotentypen erneut erörtert. Diese Woche wurden einige Knotentypen und ein transaction estimator (Transaktionsschätzer) eingeführt. Weitere Einzelheiten findest du in der Antilope-Knotentaxonomie (Entwurf).
Über Knotentypen
Die Klassifizierung von Knotentypen wurde letzte Woche erstmals definiert. Der Schwerpunkt lag dabei auf den primären Zwecken.
Zuvor besprochene Knotentypen
Blockproduzentenknoten, primäre Ziele und Best-Practice-Konfiguration
Blocks-Only-Relay-Knoten und Best-Practice-Konfiguration
Blocks & Transaktionen Relaisknoten
Beginn der Konzentration auf API-Knoten
Es wurden zwei primäre API-Knotentypen identifiziert:
Push-API-Knoten: "Nimmt Transaktionen über HTTP-Clients an und fungiert als ausgehendes Transaktionsrelais".
"Nimmt keine eingehenden P2P-Transaktionen an, es sei denn, er fungiert auch als Blocks & Transactions Relay Node.
Chain-API-Knoten: "Bietet Zugang zum Lesen von Blockchain-primitives ... und state data..."
History Nodes haben ganz andere Anforderungen als ein Chain-API-Knoten bieten kann.
Detaillierte Anmerkungen und eine mögliche Diskussion findest du im Entwurf des Taxonomiedokuments.
Die Klassifizierung der Knotentypen wurde diese Woche abgeschlossen. Folgende Hilfsprogramme werden implementiert:
Developer Node (Entwicklerknoten): zum Testen, erfüllt alle Knotenrollen auf einem lokalen Gerät innerhalb eines einzelnen Knotennetzwerks
Weitere Einzelheiten findest du im Dokumententwurf.
Transaction Estimator (Transaktionsschätzer): Akzeptiert, validiert und wendet Transaktionen an, ohne sie an das Netzwerk weiterzuleiten.
Siehe das Entwurfsdokument für Anwendungsfälle.
Zwei weitere Knotentypen (die in der Diskussion nächste Woche als "Feeder" eingestuft werden) sind:
Snapshotting Node (Schnappschuss-Knoten): erstellt regelmäßig einen Snapshot und veröffentlicht eine Datei auf einem internen/externen Host
Eine genauere Definition finden Sie im Dokumententwurf.
Trace-API-Knoten: Zeichnet Transaktions-Trace-Informationen auf der lokalen Festplatte eines Clients auf, der über die API darauf zugreifen kann.
Layer-2-Lösungen
Ein Resource Provider Node war eine der ersten identifizierten Layer-2-Lösungen:
Resource Provider Node: Akzeptiert, interpretiert, validiert und führt Geschäftslogik auf Client-Transaktionen aus, um festzustellen, ob ein cosign (Mitzeichnung) zur Deckung der CPU/NET/RAM-Kosten warranted (gerechtfertigt, garantiert) ist.
Es wurde ein Hinweis auf den Resource Provider Node Service aufgenommen, der sich zu einer schlüsselfertigen Plugin-Lösung entwickeln kann.
AUSBLICK
Mehrere Themen decken sich mit der Diskussion über Knotentypen und potenzielle Layer-2-Lösungen. Dazu gehören die Erarbeitung von Best Practices für alle Knotentypen, die mögliche Erforschung spezieller Knotenpakete und integrierte Flags für Konfigurationsvorgaben.
22. Februar: Spezialknoten (Fortsetzung) - Feeders und Layer-2
Sieh dir die Diskussionsrunde vom 22. Februar auf der YouTube-Seite der ENF an. Lies dazu die Notizen auf EOS Nation (Leap) GitHub.
UPDATE:
Die ENF geht davon aus, dass sie einen Überblick über die Funktionen von Leap v4.0.0 noch vor dem bereits erwähnten Code-Stop geben kann. Informiere dich, wann der Roundtable stattfindet, bei dem die neuen Funktionen vorgestellt werden.
DISKUTIERTE SCHLÜSSELTHEMEN
Die Diskussion über die Spezialknoten wurde mit Rückmeldungen zum (Entwurf) des Taxonomiedokuments für Antilope-Knoten fortgesetzt. Detaillierte Sitzungsnotizen findest du hier. Vorgestellt wurden ein DeepMind Logger Knoten und ein State History Knoten, um eine Layer-2-Lösung voranzutreiben. History Services (History Dienste) sind hier von besonderem Interesse.
Es wurde auch die Idee des "Priority Loading" angesprochen. Dabei handelt es sich um die Einführung einer 3-Strikes-Regel zur Lösung eines langjährigen (Bot-)Problems. Das vorrangige Laden scheint auch bei den schwierigen Transaktionsproblemen von WAX wirksam zu sein. Eine Verlängerung der Zeiten von einer halben Sekunde auf wenige Sekunden würde einen Knoten "ausräumen". Die Lösung würde die bestehenden Vorgänge (für die meisten) nicht wesentlich verändern. Eine Ausweitung des prioritären Ladens auf eine oder zwei Minuten wäre ein Overkill. Eine einfache und effiziente Lösung, selbst wenn das Thema nicht in der Aufzeichnung vorkommt.
Konzeptualisierung von Feeder-Knoten
Im vorangegangenen Abschnitt wurde bereits auf die Knotentypen eingegangen. Beide besprochenen Feeder-Knotentypen arbeiten durch den Empfang von Blöcken von konfigurierten Peers. Beide helfen auch dabei, Layer-2-Historienlösungen zu ermöglichen:
DeepMind Logger Node: "serialisiert fortlaufend den aktuellen Block, Traces, etc. und streamt sie in stdout zur weiteren Verarbeitung..."
State History Node: "speichert Blöcke/Traces in einer State-History-Datei..."
Layer-2-Lösungen
Im Anschluss an die Überlegungen von letzter Woche zu Layer-2-Lösungen wurden einige weitere Dienste vorgestellt. Die Formatierung war der Schlüssel zu dieser Diskussion.
Event Capture Service (Ereignis-Erfassungsdienst): Übernimmt die Aufgabe, die Ausgaben von Feeder-Knoten in speziellen Formaten zu verarbeiten, um den beabsichtigten Zweck zu gewährleisten. Als Beispiel wurde ein History Provider Service genannt.
History Provider Service (History Provider Service): ein Basisdienst, der in einem beliebigen Format verfügbar ist und historische Daten auf Anfrage eines Kunden über eine API bereitstellt.
Beachte, dass der Ereigniserfassungsdienst mit forks (Gabelungen) umgehen muss.
OUTLOOK
Zusätzlich zu den für den 15. Februar aufgelisteten Ausblicken wurden mehrere andere Punkte unter "Nächste Schritte" aufgelistet - siehe den (Entwurf) der Antilope-Knoten-Taxonomie für Details. Layer-2-Lösungen werden voraussichtlich nächste Woche fortgesetzt. Außerdem muss eine Feature-Matrix für feeders definiert werden.
Quellen & Referenzen