Ein weiterer Bericht ist erschienen - der 8/4 PeerDAS Devnet-Bericht von Sunnsyide Labs ist hier! Neugierig, wie sich Knoten unter produktionsähnlichen Bedingungen mit PeerDAS verhalten? 🧵

Dieses Mal hat Sunnyside Labs 2 Arten von Devnets basierend auf dem fusaka-devnet-2-Image von @ethPandaOps betrieben, um die Netzwerkstabilität in einer realistischeren Umgebung zu überprüfen: 1. Interop-Devnet (gemischte CL/EL-Clients mit 50% Supernode) 2. Perfect PeerDAS-Devnet (jeder Knoten verwaltet exklusiv eine einzigartige Datenkolonne)

Für jede Devnet-Konfiguration haben wir 3 neue Testszenarien durchgeführt: 1. Blobs mit großen Transaktionen Dies dient dazu, zu untersuchen, wie reguläre Transaktionen die Konkurrenz der Blockpropagation mit der Datenkolonnenpropagation über die Knoten beeinflussen. Wir haben jeden Block im Test auf 22 Mgas (2MB Blockgröße) gehalten. 2. Bandbreitenlimit + große Transaktionen Dieser Test soll das Verhalten des Netzwerks unter Bedingungen von bandbreitenlimitierten Knoten wie Heim-Stakern untersuchen. Die Bandbreite ist auf 100/50Mbps für Supernodes und 50/25Mbps für Fullnodes festgelegt, gemäß den Empfehlungen von EIP-7870. 3. Genesis-Synchronisationstest Die Genesis-Synchronisation wird über die Devnets getestet, um Blockaden oder Fehler im Synchronisationsprozess zu finden. Hier sind die Erkenntnisse, die wir aus diesen Tests gewonnen haben:

1 - Große Transaktionen haben geringe Auswirkungen auf das Netzwerk, unter unbeschränkten Netzwerkbedingungen Sowohl im Interop Devnet als auch im Perfect PeerDAS Devnet hielt das Netzwerk 60 Blobs ohne größere Probleme aus, selbst mit zusätzlichen Transaktionen neben den Blobs. Dieses Ergebnis ist dasselbe wie im Basisszenario nur mit Blobs. Dies zeigt, dass gewöhnliche Transaktionen neben Blobs minimale Auswirkungen auf die Netzwerkstabilität unter keinen Ressourcenbeschränkungen haben.

2 - Die Bandbreitenbeschränkung wirkt sich auf das Netzwerk in verschiedenen Pfaden aus Mit Uplinks, die auf 100/50Mbps für Supernodes und 50/25Mbps für Fullnodes gedrosselt sind, brach der Blob-Durchsatz auf 20 Blobs/Block im Interop-Entwicklungsnetz und 30 Blobs/Block im Perfect PeerDAS-Entwicklungsnetz ein. Unter diesen Grenzen zeigte ein starker Anstieg der IWANT-Nachrichten im beacon_block-Thema, dass die Beacon-Blöcke Schwierigkeiten hatten, sich zu verbreiten. Außerdem, sobald Knoten ihre Ausgangsobergrenzen erreichten, zeigten die EL-Mempools deutlich weniger Blobs, was durch einen steilen Rückgang der Erfolgsraten von getBlobsV2 belegt wurde. Interne Diskussionen deuten darauf hin, dass die Upload-Obergrenze von 50 Mbps für Supernodes der Hauptschuldige ist: Diese Obergrenze bei EIP-7870 ist für lokale Blockbauer ausgelegt, nicht für Supernodes, die das breitere Netzwerk bedienen. Daher waren diese Tests strenger als die Bedingungen in der realen Welt. Sunnyside Labs wird diese Woche einen Folgetest mit höherer Bandbreite für Supernodes durchführen, um die genaue Auswirkung dieser Einschränkung zu messen.

3 - Genesis-Synchronisierung funktioniert für das Interop-Entwicklungsnetz, hat jedoch im Perfect PeerDAS-Entwicklungsnetz versagt. Die Genesis-Synchronisierung wurde im Interop-Entwicklungsnetz einwandfrei abgeschlossen, blieb jedoch direkt nach der Fulu-Upgrade-Epoche im Perfect PeerDAS stehen. Wenn ein Knoten während der Genesis-Synchronisierung nicht alle Spalten abrufen kann, sollte er idealerweise zusätzliche Peers abfragen, um die Lücken zu füllen, was in keinem Client bisher implementiert ist. Ob dieses cross-peer Spaltenabrufen eine erforderliche Funktion vor dem Fusaka wird, ist noch offen; die Entscheidung wird für den nächsten Donnerstag beim ACD erwartet.

4 - Validatorenverwahrung Backfill erfolgreich bei @Teku_Consensys Die Validatorenverwahrung Backfill ermöglicht es einem Client, fehlende historische Spalten zu erkennen und automatisch von Peers abzurufen. Unser dedizierter Test hat bestätigt, dass die Implementierung von Teku einwandfrei funktioniert - sie identifizierte Lücken und füllte sie vollständig ohne Probleme unter normalen Bedingungen. Ein kleiner Fehler in einem Randfall, bei dem es eine große Lücke in der Kette ohne Blobs gab, wurde während der Tests identifiziert und schnell vom Team behoben. Andere Clients arbeiten jetzt an dieser Funktion, und sie wird in den zukünftigen Sunnyside-Entwicklungsnetzwerken getestet, sobald die Implementierung abgeschlossen ist.

Sunnyside Labs wird diese Woche weiterhin Devnets betreiben, mit Fokus auf die folgenden Themen: - Devnet-Interop mit höheren Supernode-Bandbreitenlimits und längeren Zeiträumen - Weitere Analysen zu Genesis-Sync-Tests im Perfect PeerDAS-Devnet - Weitere Devnets, die sich auf die maximale Blockgröße (im snappy-komprimierten Format), durch Blobber beschädigte Knoten und Finalität im gespaltenen Netzwerk konzentrieren.