Der 7/14 PeerDAS Devnet-Bericht von Sunnyside ist da! Lass uns in den aktuellen Stand von PeerDAS eintauchen - wie viel Blob können wir verarbeiten und wo liegt der Engpass?

Zu diesen Bemühungen gehört es, dass Sunnyside wöchentliche Devnets in vielen verschiedenen Konfigurationen betreibt und den Kernentwicklern die daraus gewonnenen Erkenntnisse zur Verfügung stellt: •Wo die aktuellen Grenzen von PeerDAS liegen •Welche Komponenten genau Engpässe verursachen •Wie gut Optimierungen wie Supernodes und GetBlobV2 in der Praxis funktionieren

Unser Hauptziel ist es, schnell und flexibel zu testen, um die Arbeiten anderer Teams wie @ethPandaOps bei fusaka-devents zu ergänzen und zeitnahe Rückmeldungen zu geben, die die laufende Implementierung von PeerDAS unterstützen.

In dieser Woche haben wir 12 Devnets betrieben und 3 Test-Suiten durchgeführt, indem wir das neueste fusaka-devnet-2-Image von @ethPandaOps verwendet haben: 1. Blob-Durchsatz (max. Blobs pro Block) 2. Netzwerkbandbreite (Lasttest) 3. Bandbreitenbeschränkung (30 / 20 / 10 Mbps Obergrenzen)

1 – Blob-Durchsatztest Die Testergebnisse zeigten, dass die meisten CL-Clients 84 Blobs pro Block oder mehr verarbeiten konnten und bei mindestens 40 Blobs stabil blieben. Einige Clients verzeichneten eine relativ niedrigere maximale Blob-Anzahl im Vergleich zu früheren Devnets - dies könnte jedoch daran liegen, dass die Anzahl der Validatoren pro Knoten in diesem Devnet von 100 auf 8 reduziert wurde, was wiederum die Teilnahmequote jedes Knotens im Subnetz senkte.

2 – Netzwerk-Bandbreitentest Im Gegensatz zu früheren Devnets, bei denen das Netzwerk bei hohen Blob-Zahlen oft instabil wurde, liefen diesmal alle Devnets über einen längeren Zeitraum (~16 Stunden) stabil, selbst mit 60 oder 72 Blobs pro Block. Obwohl dies keine Produktionsstabilität garantiert, zeigt es, dass zumindest einige CL-EL-Kombinationen durch Optimierung ein viel höheres Maß an Robustheit erreicht haben 🚀

3 – Bandbreitenbeschränkungstest Um zu überprüfen, ob echte Home-Staker reibungslos teilnehmen können, sobald PeerDAS aktiv ist, wurden in diesem Test Netzwerkgrenzen angewendet und untersucht, welche Faktoren unter verschiedenen eingeschränkten Szenarien zu Engpässen werden. In mehreren Tests haben wir festgestellt, dass die Bandbreitennutzung der Knoten periodisch ansteigt – insbesondere zu Beginn eines Slots, wenn Blobs verbreitet werden – und dass diese Spitzen die Gesamtleistung des Netzwerks einschränken. Der Burst-Verkehr trat gleichmäßig über die Knoten auf, anstatt durch einen bestimmten CL- oder EL-Client verursacht zu werden, und sobald die Spitzen begannen, konnte das Netzwerk die Blob-Durchsatzrate nicht weiter erhöhen. Mit anderen Worten, Burst-Verkehr ist der größte Engpass in bandbreitenbeschränkten Umgebungen, und wir müssen Wege finden, um ihn zu mildern.

Darüber hinaus haben wir mit verschiedenen Kunden-Teams kommuniziert und Verbesserungen für Synchronisations- und Peer-bezogene Probleme angeregt.

Das Sunnyside-Entwicklungsnetz läuft weiterhin 🏗️; es werden Interop-Entwicklungsnetze mit mehreren Client-Kombinationen, detaillierteren Bandbreitentests, Spam-Tests, die normale Transaktionen einschließen, und Backfill/Synchronisationstests durchgeführt, um Engpässe in Umgebungen zu identifizieren, die den Bedingungen des Hauptnetzes näher kommen.