Autor: Markus Hinrichs
Redakteur: Randall Roland
Übersetzer: Markus Hinrichs
Node-Betreiber, Antelope-Kernentwickler und Mitglieder der Community treffen sich wöchentlich, um über das Netzwerk und dessen Entwicklung zu sprechen. Das Hauptziel jeder Runde der Node-Betreiber besteht darin:
"...das Antelope-Protokoll (speziell) für Node-Betreiber zu verbessern."
Die Runden finden jeden Mittwoch statt. Besuche den Telegram-Kanal, um Informationen zur Teilnahme zu erhalten. Die EOS Network Foundation bietet Tutorials und Dokumentation für diejenigen, die die Grundlagen des Betriebs eines EOS-Knotens erlernen möchten.
Nachfolgend findest du eine Liste der Roundtables, die in diesem zweimonatlichen Überblick enthalten sind:
18. Oktober: Verbesserte CPU-Konfiguration, Diskussion über die Funktion der Initialblöcke, Vereinfachung der Konfiguration im gesamten Netzwerk und mehr
25. Oktober: Wünsche und Bestrebungen für das Format der Node-Betreiber-Anrufe, letzte Meilensteine zur RC3
Achte darauf, zusätzliche Besprechungsnotizen und Kommentare auf GitHub zu suchen. Die Videos sind auf dem YouTube-Kanal der ENF verfügbar.
Oktober: Leap 5.0 auf dem Weg: Frühe Blöcke, Leistungssteigerungen und Beiträge aus der Community
Veröffentlichung von Leap 5.0 und Tests:
Die Besprechung begann mit einer umfassenden Diskussion über die Veröffentlichung von Leap 5.0.
Die Community-Mitglieder wurden nachdrücklich ermutigt, aktiv an den Tests der Release-Kandidaten-Version RC2 teilzunehmen, um mögliche Probleme vor der offiziellen stabilen Version zu identifizieren und anzugehen.
Änderungen an der Option "CPU-Aufwandsprozent":
Es wurde eine signifikante Änderung in Bezug auf die CPU effort percentage-Option vorgestellt.
Der Vorschlag sah vor, vom Verwenden von Prozentwerten zu wechseln und die CPU-Aufwandskonfiguration in Millisekunden durchzuführen.
Bestehende Optionen wie CPU-Aufwandsprozentsatz, CPU-Aufwand des letzten Blocks, letzte Blockverschiebung und letzte Blockversionen sollten durch eine neue Option namens produce block offset ms ersetzt werden.
Einzelheiten zur neuen Option "Offset ms zum Produzieren von Blöcken":
Die kürzlich eingeführte Option "Offset ms zum Produzieren von Blöcken" ermöglicht es Node-Betreibern, die Anzahl der Millisekunden festzulegen, die sie für die gesamte Runde, bestehend aus 12 Blöcken, zuweisen möchten.
Dieser Offset spielt eine entscheidende Rolle bei der Bestimmung der für die Bewältigung der Blockproduktionslatenz zugewiesenen Zeit.
Es wurde betont, dass diese Änderung den Konsensmechanismus nicht beeinflusst und speziell entwickelt wurde, um die Effizienz der Blockproduktion zu verbessern.
Frühe Blockproduktion und Tests:
Nachfolgende Diskussionen drehten sich um die Einführung der frühen Blockproduktion in Leap 5.0.
Michael von EOSUSA stellte das Konzept vor, die Einstellungen der Systemuhr zu ändern, was Bedenken hinsichtlich möglicher Probleme und unbeabsichtigter Konsequenzen aufwarf.
Es wurden Bedenken geäußert, wie sich die frühe Blockproduktion auf das Netzwerk auswirken könnte und ob sie zu Forks oder anderen Komplikationen führen könnte.
Leistungssteigerung in Labortests:
Kevin Heifner äußerte seine Begeisterung über die potenziellen Leistungsverbesserungen, die die frühe Blockproduktion mit sich bringen würde.
Die Diskussion betonte, wie die frühe Blockproduktion mehr Zeit für die Aufnahme von Transaktionen in Blöcke ermöglicht, was letztendlich der Effizienz des Netzwerks zugutekommt.
Das EOS VM OC (Optimierter Compiler) wurde als ein wichtiger Leistungsverbesserer anerkannt, insbesondere für EOSIO DApps und Verträge.
Es wurde auf die Wahrscheinlichkeit hingewiesen, dass eine höhere Last auf historische Lösungen übertragen wird, um die Leistungssteigerung zu bewältigen.
"Es gibt eine Menge Leistungsverbesserungen seit den Tagen von 1.8 bis zu dem Punkt, an dem wir heute sind. Es ist ein viel feiner abgestimmter Motor und sollte deshalb wirklich in der Lage sein, die Last zu bewältigen" Kevin Heifner, OCI
Konfiguration von produce block offset ms und Standardeinstellungen:
Die Diskussion drehte sich um die Konfiguration von "Offset ms zum Produzieren von Blöcken" und vorgeschlagene Standardwerte.
Ein Standardwert von 450 Millisekunden wurde für "Offset ms zum Produzieren von Blöcken" vorgeschlagen, wobei die Diskussionen die Bedeutung der Standardeinstellungen betonten, um das Verhalten des Knotens zu beeinflussen.
Flexibilität wurde als ein Schlüsselfaktor hervorgehoben, der den Betreibern ermöglicht, die Einstellungen an die spezifischen Netzwerkbedingungen anzupassen.
Späte Blöcke und Zeitsynchronisation:
Die Frage der späten Blöcke und deren Verwaltung im Zusammenhang mit der frühen Blockproduktion wurde angesprochen.
Überlegungen wurden angestellt, wie die potenzielle Auswirkung der Zeitsynchronisation und der Netzwerklatenz auf späte Blöcke sein könnte.
Kevin klärte auf, dass späte Blöcke zu Mikrogabeln führen könnten, und die Rolle der Zeitsynchronisation in diesem Kontext wurde erforscht.
Festlegung von Max Transaction Time und Read Only Read Window Time:
Die Diskussion umfasste die Einstellung "Maximale Transaktionszeit" und mögliche Änderungen.
Kevin Heifner empfahl eine Standardkonfiguration von "ungefähr 500 Millisekunden".
Die Bedeutung der Konfiguration von Einstellungen für "Zeit für das Lesen von nur Lesefenstern" wurde betont, um die Netzwerkleistung zu optimieren.
Es wurde vorgeschlagen, dass einzelne Node-Betreiber diese Werte entsprechend ihren spezifischen Anwendungsfällen festlegen sollten.
Durchsetzung über On-Chain-Konsens:
Die Idee, Einstellungen über den On-Chain-Konsens zu steuern, wurde als Möglichkeit zur Vereinfachung von Netzwerkweiten Konfigurationsänderungen vorgestellt.
"...jetzt können die BPs das Netzwerk weitgehend durch eine Konsens-Einstellung steuern" Kevin Heifner
Diskussion über PR zur Kennzeichnung von Peer-to-Peer-Peers:
Ein ausstehender Pull Request bezüglich der Kennzeichnung von Peer-to-Peer-Peers wurde kurz erwähnt.
Aufgrund von Zeitbeschränkungen und der Abwesenheit des entscheidenden Teammitglieds Matthew Darwin wurde eine ausführliche Diskussion zu diesem Thema auf eine zukünftige Besprechung vertagt.
Die Besprechung endete mit dem Aufruf an die Community, Leap 5.0 rc2 aktiv zu testen und Feedback zu geben, um einen reibungslosen Übergang zur stabilen Version sicherzustellen.
Oktober: Wünsche & Bestrebungen für das Format der Node-Betreiber-Anrufe, letzte Meilensteine zur RC3
Hauptthema: Wie soll die Node-Betreiber-Runde fortgesetzt werden?
Einblicke und Engagement:
Ross von EOS Sphere schätzte die Einblicke des technischen Teams.
Shaq betonte die Notwendigkeit von Informationen und technischen Einblicken zu Leap.
Michael von EOSUSA erkannte die Auswirkungen der Zusammenarbeit auf die Softwarereife.
Kevin Heifner, OCI, betonte die Bedeutung des Feedbacks von Node-Betreibern.
Wünsche für zukünftige Besprechungen:
Diskussion über die Einbeziehung von Dokumentation in zukünftigen Besprechungen.
Arten von Dokumentation wurden hervorgehoben, einschließlich Protokoll-, Node-Betreiber- und Entwicklerdokumente.
Überlegungen zu sich entwickelnden Funktionen und potenziellen Änderungen.
Forderungen nach einer tieferen Erkundung bevorstehender Funktionen.
Besprechungsformate:
Die Idee verschiedener Besprechungen für spezifische Themen wurde diskutiert, wobei die Teilnehmer überlegten, ob ad-hoc- oder kurzlebige Besprechungen wertvoll wären.
Es wurden Bedenken geäußert, dass eine Umstellung auf breitere Formate diese Besprechungen unbeabsichtigt in Entwicklungsbesprechungen verwandeln könnte, was dazu führen könnte, dass sich Node-Betreiber abmelden.
Auswahl der Teilnehmer:
Die Teilnehmer äußerten den Wunsch, dass schwergewichtige Entwickler (z.B. Nathan James) gelegentlich an diesen Besprechungen teilnehmen. Die Idee eines beidseitigen Austauschs, bei dem Kevin Heifner an Entwicklungsbesprechungen teilnimmt und die Expertise von Nathan zur Dokumentation und Orientierung genutzt wird, wurde vorgeschlagen.
Das Dreamteam der Teilnehmer würde Kevin Heifner, Nathan James und regelmäßige Beitragende (Michael EOSUSA, Ross (EOS Sphere), Matthew Darwin) umfassen. Infrastrukturschwere Node-Betreiber wie Aaron Cox (Greymass) und L2-Spezialisten wie Stan von EOS Amsterdam könnten ebenfalls einbezogen werden.
Besprechungshäufigkeit:
Tendenz zur Beibehaltung eines wöchentlichen Zeitplans.
Besprechungsdauer:
Vorschlag, Besprechungen konstant auf eine Stunde zu beschränken.
Überlegung zur Erweiterung für tiefgreifende Diskussionen.
Alternative Besprechungszeiten:
Herausforderung durch Unterbrechung von Routinen und Fragmentierung der Teilnahme.
Vorgeschlagene zusätzliche Besprechungen zu verschiedenen Zeiten.
Verbesserungen bei der Tagesordnung:
Vorgeschlagene flexible Tagesordnung mit Statusaktualisierungen und Hauptthemen.
Bewertung von Besprechungsnotizen:
Diskussion über die Angemessenheit von Besprechungsnotizen.
Empfehlung zur Suche nach Feedback von abwesenden Personen.
Aufzeichnungen von Besprechungen:
Keine Bedenken hinsichtlich der Aufzeichnung von Besprechungen.
AI-generierte Notizen und Transkriptionen:
AI-generierte Notizen wurden begrüßt, sofern akkurat.
Steigerung der Teilnehmeranzahl:
Das letzte Thema befasste sich mit der Steigerung der Teilnahme und schlug vor, nicht anwesende Teilnehmer aktiv einzubeziehen, um die Teilnahme an diesen wertvollen Diskussionen zu erweitern.
Elemente im Zusammenhang mit Meilensteinen für das Leap-Upgrade RC2 → RC3
Ein Schwerpunkt wurde auf die CPU-Verfügbarkeit für die Transaktionsunterschrift gelegt, mit einer spezifischen Bezugnahme auf einen Konfigurationsparameter, den "Offset zum Produzieren von Blöcken", und Strategien zur Optimierung für maximale Leistung.
Meilensteine wurden skizziert, wobei der Fokus auf der Behebung von Problemen für die nächste Release-Kandidaten-Version lag.
Einige kritische Probleme, einschließlich fehlerhafter BLS-Tests in ARM-Builds, wurden diskutiert, und es wird daran gearbeitet, diese zu beheben.
Konfigurationsparameter
Die gesunde Einstellung für den "Produzier-Block-Offset"-Parameter war ein bedeutendes Thema. Die Frage wurde von Ross aufgeworfen, und Kevin erläuterte ausführlich, wie dies in der kommenden Version verbessert wird.
In RC2 betrug der Standardwert 90 % oder 600 Millisekunden, was als zu konservativ angesehen wurde.
In der neuen Version wird der neue Wert in Millisekunden ausgedrückt, was eine feinere Abstimmung ermöglicht. Die Teilnehmer diskutierten verschiedene Einstellungen und die potenziellen Vorteile, wie verbesserte Transaktionsverarbeitung und reduzierte Latenz.
"Es besteht das Potenzial für eine Zunahme der Latenz bei Transaktionen, die zufällig den 12. Block erreichen, aber nur bei denen, die diesen letzten Block erreichen würden. Das ist also eine ziemlich kleines Minus für ein sehr großes Plus", sagte Kevin Heifner.
Der bedeutendste Vorteil zeigt sich in Zeiten von Kettenüberlastung. Es hilft auch dabei, fehlgeschlagene Transaktionen effektiver zu verarbeiten, indem zusätzliche Zeit für ihre Bewertung bereitgestellt wird, ohne die Gesamtdurchsatzrate negativ zu beeinflussen. Im Wesentlichen optimiert es die CPU-Auslastung.