Zmiany w przepustowości węzłów Ethereum po aktualizacji Fusaka Zespół open-source'owych budowniczych ethPandaOps, związany z operacjami infrastruktury Ethereum, ma świetny materiał dotyczący zastosowania PeerDAS w Fusaka, który został zweryfikowany w środowisku devnet. (oryginalny tekst w komentarzu) Najważniejszą aktualizacją Fusaka jest PeerDAS, a Ethereum ma osobną przestrzeń na Blob, w której L2 wykonują rollupy. Wraz ze wzrostem użycia L2 pojawia się potrzeba szybkiego rozszerzenia tej przestrzeni Blob. Jednak nieograniczone zwiększanie Blob prowadzi do wzrostu specyfikacji L1 Ethereum, co prowadzi do centralizacji. Dlatego Ethereum planuje wprowadzenie shardingu tej przestrzeni Blob, aby walidatory mogły ją dzielić, a pośrednim krokiem jest wprowadzenie PeerDAS. Dzięki PeerDAS, nawet jeśli liczba Blobów będzie stopniowo zwiększana, można zminimalizować wzrost przepustowości sieci poszczególnych węzłów. Proces i wyniki eksperymentu przeprowadzonego przez zespół ethPandaOps są opisane w oryginalnym tekście dołączonym w komentarzu. Podsumowując, wnioski z tego postu są następujące: W przypadku rozszerzenia Blobów w głównym łańcuchu Ethereum do 14 po Fusaka, zmiany w wymaganiach specyfikacji i przepustowości w zależności od typu węzła są następujące: 1⃣ Superwęzeł (węzeł stakujący z 4096ETH lub więcej) W przypadku superwęzła, należy subskrybować wszystkie 128 kolumn sub-sieci i przechowywać wszystkie dane przez 18 dni, co jest okresem przechowywania danych Bloba. Superwęzły pełnią zasadniczo rolę "kręgosłupa" sieci Ethereum, a obciążenie obliczeniowe dla przepustowości P2P i przetwarzania DA jest największe. Przepustowość sieci wynosi zazwyczaj ponad 100Mb/s, a w szczycie osiąga poziom 400Mb/s. Zazwyczaj jest obsługiwana przez profesjonalny zespół walidatorów oparty na specjalistycznym personelu i infrastrukturze. 2⃣ Domowy staker (solo staker, 32ETH) W przypadku węzła solo stakującego 32ETH, wystarczy subskrybować 8 sub-sieci przypisanych do siebie oraz sub-sieć dla losowej kolumny. Ponieważ przetwarza tylko mniej niż 1/8 danych w porównaniu do superwęzła, wymagania specyfikacji znacznie się zmniejszają. W przypadku przepustowości wystarczy około 25Mb/s. 3⃣ Węzeł pełny (bez walidatora) W przypadku prostego węzła pełnego, który nie wykonuje walidacji, wystarczy subskrybować tylko 4 kolumny sub-sieci. Przetwarza dokładnie 1/32 danych w porównaniu do superwęzła, co znacznie zmniejsza wymagania dotyczące przepustowości P2P, użycia dysku i wymagań CPU. Można uczestniczyć w sieci przy bardzo niskiej przepustowości wynoszącej 4-8Mb/s. ...