Najbardziej przełomowa aktualizacja sieciowa Ethereum od lat działa teraz bez większych incydentów od blisko dwunastu miesięcy. PeerDAS, protokół pozwalający walidatorom potwierdzać dostępność danych bez pobierania pełnych bloków, przetrwał zarówno utrzymujący się wzrost pojemności blobów, jak i dramatyczny spadek opłat transakcyjnych w warstwie 2.

Co faktycznie robi PeerDAS

Dostępność danych to właściwość, na której opiera się reszta ekosystemu: sieci warstwy 2 publikują swoje dane transakcyjne w Ethereum, aby każdy mógł zweryfikować i odtworzyć ich stan, a PeerDAS został zaprojektowany tak, aby potwierdzać, że opublikowane dane są kompletne i możliwe do odzyskania. Każdy węzeł musi sprawdzić jedynie około jedną ósmą rozszerzonych danych, aby mieć pewność, że pełny zbiór danych istnieje. Gdy wystarczająca liczba losowo wybranych próbek wróci nietknięta, sieć osiąga konsensus co do tego, że dane są dostępne, mimo że żaden pojedynczy uczestnik nie posiada ich w całości.

Mechanizm techniczny opiera się na kodowaniu kasującym podobnym do Reeda-Solomona. Rozszerzone dane blob są dzielone na 128 kolumn, które są następnie rozprowadzane po sieci za pomocą podsieci gossip. Każdy węzeł subskrybuje podzbiór około ośmiu kolumn, co sprawia, że obciążenie jest na tyle lekkie, że walidatorzy nie potrzebują ulepszonegotu, aby uczestniczyć.

Formalna nazwa protokołu to EIP-7594, a został on wdrożony jako główna funkcja hard forku Fusaka 3 grudnia 2025 roku. Przed aktywacją na mainnecie społeczność deweloperów Ethereum przeprowadziła szerokie testy na setkach węzłów na dedykowanym devnecie.

Wzrost pojemności blobów i załamanie opłat

Na starcie cel wynosił od sześciu do dziewięciu blobów na blok. Do 9 grudnia 2025 roku — sześć dni po aktualizacji Fusaka — cel wzrósł do 10 blobów. Mniej niż miesiąc później, 7 stycznia 2026 roku, osiągnął 14 blobów.

Wpływ na opłaty był uderzający. Ponieważ sieci warstwy 2 płacą za publikowanie swoich danych transakcyjnych w blobach, docelowa liczba blobów pełni rolę strony podażowej ich kosztów. W tygodniach poprzedzających aktywację PeerDAS użytkownicy warstwy 2 płacili od 0,20 do 0,50 USD za transakcję. Do pierwszego kwartału 2026 roku koszty te skompresowały się do przedziału 0,005–0,02 USD — spadek o ponad 95% w ciągu kilku miesięcy. W tym przedziale opłata za transakcję wynosi od ułamka centa do dwóch centów — na tyle mało, że stanowi zaokrąglenie przy większości transferów.

Spadek nie wynika wyłącznie z PeerDAS. Wcześniejsza aktualizacja Ethereum EIP-4844, która wprowadziła transakcje przenoszące bloby na początku 2024 roku, oddzieliła już opłaty za bloby od opłat gazowych za wykonanie. PeerDAS rozszerza ten fundament, pozwalając na przepływ znacznie większej ilości danych blob przez sieć bez proporcjonalnego zwiększania obciążenia poszczególnych walidatorów.

Dlaczego decentralizacja jest sednem sprawy

Ponieważ żaden pojedynczy węzeł nie musi pobierać ani przechowywać pełnego zbioru danych blob, protokół osiąga to, co badacze nazywają zdecentralizowanym konsensusem dostępności danych. Walidator działający na skromnym sprzęcie konsumenckim może w pełni uczestniczyć w potwierdzaniu dostępności danych, próbkując jedynie przydzielony podzbiór kolumn i polegając na żądaniach peerów w celu odtworzenia brakujących elementów. Ten niski wymóg sprzętowy to praktyczne ogniwo między projektem protokołu a jego celami decentralizacyjnymi.

Vitalik Buterin określił protokół jako znaczący postęp w skalowalności blockchainów. Badacze najbardziej związani z tą pracą, w tym Danny Ryan i Dankrad Feist, spędzili lata na przygotowaniach teoretycznych, zanim implementacja nabrała kształtu. Oryginalna propozycja danksh Failingu Feista opisuje większą architekturę, której wczesną fazą jest PeerDAS. Pełny danksharding jeszcze bardziej znacząco zwiększyłby pojem blobów, potencjalnie umożliwiając tysiące blobów na blok.

Co dalej w roadmapie skalowania Ethereum

Progresja z 6 do 14 blobów w ciągu około pięciu tygodni pod koniec 2025 roku sugeruje, że społeczność deweloperów Ethereum czuje się na siłach, by działać szybko po ustanowieniu bazy stabilności. Stanem końcowym tej roadmapy jest pełny danksharding i jego potencjał tysięcy blobów na blok, a tempo dalszych zwiększeń docelowej liczby blobów będzie konkretnym wskaźnikiem postępu w tym kierunku.