Raport Devnet PeerDAS z 7/14 Sunnyside jest już dostępny! Zanurzmy się w aktualny stan PeerDAS - ile blobów możemy obsłużyć i gdzie tkwi wąskie gardło?

Wśród tych działań, rolą Sunnyside jest prowadzenie cotygodniowych devnetów w wielu różnych konfiguracjach i dostarczanie głównym deweloperom wynikających z tego spostrzeżeń: • Gdzie leżą obecne ograniczenia PeerDAS • Które komponenty dokładnie tworzą wąskie gardła • Jak dobrze w praktyce działają optymalizacje takie jak Supernodes i GetBlobV2

Naszym głównym celem jest szybkie i elastyczne testowanie w sposób, który uzupełnia to, co robią inne zespoły, takie jak @ethPandaOps w fusaka-devents, dostarczając na czas informacje zwrotne, które wspierają bieżącą implementację PeerDAS.

W tym tygodniu uruchomiliśmy 12 devnetów i przeprowadziliśmy 3 zestawy testów, używając najnowszego obrazu fusaka-devnet-2 od @ethPandaOps: 1. Przepustowość Blobów (maksymalna liczba blobów na blok) 2. Przepustowość sieci (test obciążenia ciągłego) 3. Ograniczenie przepustowości (30 / 20 / 10 Mbps)

1 – Test przepustowości Blobów Wyniki testów pokazały, że większość klientów CL mogła obsłużyć 84 bloby na blok lub więcej, i pozostawała stabilna przy co najmniej 40 blobach. Niektórzy klienci odnotowali stosunkowo niższą maksymalną liczbę blobów w porównaniu do poprzednich devnetów - ale może to być spowodowane tym, że liczba walidatorów na węzeł w tym devnecie została zmniejszona z 100 do 8, co z kolei obniżyło wskaźnik uczestnictwa subnetu każdego węzła.

2 – Test przepustowości sieci W przeciwieństwie do wcześniejszych devnetów, gdzie sieć często stawała się niestabilna przy dużej liczbie blobów, tym razem wszystkie devnety działały stabilnie przez dłuższy czas (~16 godzin) nawet przy 60 lub 72 blobach na blok. Chociaż nie gwarantuje to stabilności na poziomie produkcyjnym, pokazuje, że przynajmniej niektóre kombinacje CL-EL osiągnęły znacznie wyższy poziom odporności dzięki optymalizacji 🚀

3 – Test ograniczający przepustowość Aby sprawdzić, czy rzeczywiści stakerzy domowi mogą płynnie uczestniczyć, gdy PeerDAS jest aktywny, test ten zastosował ograniczenia sieciowe i zbadał, które czynniki stają się wąskimi gardłami w różnych ograniczonych scenariuszach. W wielu testach odkryliśmy, że zużycie przepustowości węzłów okresowo wzrasta - szczególnie na początku slotu, gdy rozgłaszane są blobsy - i że te szczyty ograniczają ogólną wydajność sieci. Ruch burstowy występował równomiernie wśród węzłów, a nie był spowodowany przez konkretnego klienta CL lub EL, a gdy tylko zaczęły się szczyty, sieć nie mogła zwiększyć przepustowości blobów dalej. Innymi słowy, ruch burstowy jest największym wąskim gardłem w środowiskach z ograniczoną przepustowością, i musimy znaleźć sposoby na jego złagodzenie.

Dodatkowo skomunikowaliśmy się z różnymi zespołami klientów i zachęciliśmy do ulepszeń dotyczących synchronizacji i problemów związanych z peerami.

Devnet Sunnyside wciąż działa 🏗️; przeprowadzamy interop-devnety z wieloma kombinacjami klientów, bardziej szczegółowe testy przepustowości, testy spamu, które obejmują normalne transakcje, oraz testy uzupełniania/synchronizacji, aby zidentyfikować wąskie gardła w środowiskach, które bardziej przypominają warunki mainnet.