Autor: Markus Hinrichs
Redakteur: Randall Roland
Übersetzer: Markus Hinrichs
Node-Betreiber, Antelope-Kernentwickler und Community-Mitglieder treffen sich jede Woche, um über das Netzwerk und seine Entwicklung zu sprechen. Das Hauptziel jeder Node-Betreiber-Runde ist:
„...die Verbesserung des Antelope-Protokolls (speziell) für Node-Betreiber.“
Die Roundtables finden jeden Mittwoch statt. Besuche den Telegram-Kanal für Informationen zur Teilnahme. Die EOS Network Foundation bietet Tutorials und Dokumentation für diejenigen, die die Grundlagen des Betriebs eines EOS-Nodes erlernen möchten.
Hier ist eine Liste der Runden, die in dieser zweimonatlichen Zusammenfassung enthalten sind:
4. Oktober: Leap 5 Technical Highlights, Verschiebung des Konsensus-Upgrades auf Leap 6
11. Oktober: Leap 5.0 RC2, Verbesserung des Testprozesses, Herausforderungen bei der Aktualisierung
Achte auf zusätzliche Sitzungsnotizen und Kommentare auf GitHub. Videos sind auf dem YouTube-Kanal der ENF verfügbar.
4. Oktober: Technische Höhepunkte von Leap 5.0, Verschiebung des Konsensus-Upgrades auf Leap 6
Während der ersten Rundtischdiskussion im Oktober gab Brian Hazzard von der ENF einen Überblick über mehrere technische Aspekte und bevorstehende Entwicklungen im Zusammenhang mit der bevorstehenden Veröffentlichung von Leap 5.0. Anschließend führten Node-Betreiber eine Fragerunde durch, in der Themen wie Prometheus RC1, Transaktionsausführungen und mehr behandelt wurden.
Technische Höhepunkte von Leap 5.0
Speicherzustandsreduktion: Eine Reduzierung des Speicherzustands um 20 % wurde erreicht, mit der Möglichkeit einer zusätzlichen Reduzierung um 6 %. Vorteilhaft für EOS-Node-Betreiber und möglicherweise auch für andere Chains.
Vorschau der Versionshinweise: Brian Hazzard stellte Entwurfsversionshinweise vor und erwähnte die bevorstehende Veröffentlichung eines Aktualisierungshandbuchs. Weitere Details werden im Antelope Node Operator Telegram-Kanal geteilt.
Entfernung verschobener Transaktionen: Bemerkenswerte Änderungen umfassen die Entfernung verschobener Transaktionen durch Konfigurationsänderungen. Ein Protokollmerkmal für ihre Entfernung wird ebenfalls aufgenommen.
BLS-Bibliothek: Hinzugefügt zur Signaturaggregation und Implementierung von Zero-Knowledge-Proofs, insbesondere im Leap-Code-Basis.
Optimierungen: Verbesserungen in Bezug auf Speicher, CPU-Leistung und P2P-Fähigkeiten. Diese Optimierungen verbessern die Fähigkeit des EOS EVM, größere Transaktionen und kryptografische Grundlagen zu verarbeiten. Auch der EOS native Transaktionsprozess wird positiv beeinflusst.
Effizienzsteigerungen
Asynchrone Blockabfrage: Die asynchrone Blockabfrage wird eingeführt, wodurch Nodeos unabhängig den nächsten Batch von Blöcken abrufen kann. Dieser nahtlose Prozess steigert die Synchronisationseffizienz und optimiert die Latenz und Bandbreitennutzung mit neuen Standardwerten.
Peer-Auswahl: Peers wissen jetzt, welche Blöcke du besitzt, und vereinfachen die Peer-Auswahl basierend auf der Blockverfügbarkeit, um Rundreisen zu reduzieren.
Bandbreitensteuerung: Eine neue Einstellung ermöglicht es, die maximale Bandbreite für die Blockabfrage zu begrenzen, um sicherzustellen, dass die Synchronisierung nicht alle verfügbaren Bandbreitenressourcen verbraucht.
Speicherzustandsreduktion: Gemeinschaftsbeiträge führten zur Neugestaltung von Datenstrukturen für die Chain-Basis, was zu einer 20%igen Reduzierung des Speicherzustands führte. Weitere Optimierungen könnten eine zusätzliche 6%ige Reduzierung bringen.
"Ich bin wirklich auf viele Dinge in diesem Release gespannt. Die Verbesserungen beim Blockabruf sind wirklich cool; du kannst bei Leap 5.0 nicht scheitern, du erhältst immer Informationen zurück, und das 4-mal schneller..." Kevin Heifner (OCI)
11. OKTOBER: Leap 5.0 RC2, Verbesserung des Testprozesses, Herausforderungen bei der Aktualisierung
Die Sitzung begann mit einem Update zu Leap 5 RC1, das eine kurze Zugänglichkeitsphase hatte, bevor es aufgrund eines Fehlers entfernt wurde. Dies führte zur Beförderung von RC2 als offiziellen neuen Release-Kandidaten. Als die Diskussionen sich auf Testverfahren konzentrierten, stellte Eric Passmore (ENF) einen Early Access API-Knoten für verbessertes Testen vor und behandelte Themen wie die Protokollierung von Fehlern und potenzielle Leistungsprobleme. Die Verfolgung von Effizienz und einem effektiveren Testprozess fand bei den Teilnehmern Anklang, wobei Fragen zur Aktualisierung von BPs und Node-Betreibern aufkamen.
Diskussion über Tests
"...sogar einfache Tests sind auch gut. Würdet ihr bereit sein, ein bisschen zu testen, und welches Format wäre am besten?" Eric Passmore (ENF)
Frühzeitige Veröffentlichung des API-Knotens für Tests.
Schwerpunkt auf Fehlerbehebung, Protokollierung und potenzielle Leistungsprobleme.
Vorliebe für Code- oder Entwicklungs-Pakettests?
Wichtigkeit von spezifischen, wertorientierten Tests.
Herausforderungen für Node-Betreiber
Herausforderungen bei den Zustandshistorie-Knoten, der Ressourcenverwaltung und den Testumgebungen.
Notwendigkeit für eine verbesserte Koordination und Kommunikation.
Roadmap und Kommunikation
Forderung nach mehr Transparenz in der Entwicklungs-Roadmap von Antelope.
Klare Kommunikation für Entwickler zu Aktualisierungen und Änderungen.
Netzwerkaktualisierungen
Gründe für Aktualisierungen sind neue Funktionen, Leistungsverbesserungen und Vermeidung von Forks.
"...es gibt einen weiteren Hauptgrund für die Aktualisierung, nämlich dass du nicht aus der Chain geforkt werden möchtest..." Shaq
"...diese Börsen sind wahrscheinlich auf 3.1, eine schöne stabile Version, bis wir einen 5.0-Konsens-Fork pushen, bleiben sie wahrscheinlich bei 3.1, weil alles funktioniert." Michael, EOS USA
Benutzerdefinierte Builds auf verschiedenen Netzwerken.
Verwaltung benutzerdefinierter Builds und Anpassung an den Hauptcodebasis.
dApps und L2-Unterstützung
Wichtigkeit der Knotenkompatibilität und Skalierbarkeit für dApps.
Koordination mit Layer-Two-Lösungsanbietern.
Laufende Vereinbarungen für reibungslose Übergänge.
"...es gibt definitiv einige wichtige Layer-Two-Lösungen, die gut wären..." Michael, EOS USA
Unterschiede in den Aktualisierungsprozessen
Einzigartige Aktualisierungsprozesse aufgrund benutzerdefinierter Builds in verschiedenen Netzwerken.
Verwaltung unterschiedlicher Anpassungen und Zusammenarbeit mit Entwicklern.
Vielfältige Anpassungen, die auf Netzwerk-spezifische Anforderungen zugeschnitten sind.
Verwaltung unterschiedlicher Anpassungen in verschiedenen Netzwerken.
Viele benutzerdefinierte Codes auf WAX, Ultra, UX usw. → diese sind viel komplizierter zu aktualisieren.