PeerDAS
Peer Data Availability Sampling — mechanizm skalowania dostępności danych Ethereum planowany w upgrade Fusaka. Węzły próbkują losowe fragmenty danych blobów zamiast pobierać wszystko — razem zapewniają dostępność statystycznie, bez wymogu centralnego przechowywania.
Problem, który PeerDAS rozwiązuje
EIP-4844 (marzec 2024) wprowadził bloby — tańszą formę publikowania danych rollupów do Ethereum. Ale w obecnym systemie każdy pełny węzeł pobiera każdy blob. W miarę wzrostu liczby blobów rosną też wymagania przepustowości — co grozi decentralizacji, jeśli tylko serwery w data center mogą sobie na to pozwolić.
PeerDAS rozwiązuje to przez data availability sampling (DAS). Kluczowy wgląd: węzeł nie musi pobierać wszystkich danych blobów, żeby być pewnym że są dostępne — wystarczy losowo próbkować małe fragmenty i weryfikować, że wystarczająca ilość próbek daje się pobrać.
Dane blobów są kodowane erasure coding (jak RAID) — oryginał można odtworzyć z dowolnych ~50% zakodowanych fragmentów. Fragmenty są dzielone na kolumny i dystrybuowane po sieciach p2p. Każdy walidator subskrybuje małą liczbę kolumn i przechowuje je lokalnie.
Droga do pełnego dankshardingu
- EIP-4844 (Dencun, 2024)
- Wprowadził blobs i KZG commitments. Każdy węzeł pobiera wszystkie bloby. Limit: ~6 blobów/blok.
- PeerDAS (Fusaka, planowany)
- Węzły próbkują fragmenty zamiast pobierać wszystko. Docelowo setki blobów/blok.
- Pełny danksharding (przyszłość)
- Docelowy model skalowania DA Ethereum. Setki do tysięcy blobów/blok bez wzrostu wymagań węzła.
Najczęstsze błędne założenia
- PeerDAS to nie to samo co bloby. Bloby działają od EIP-4844; PeerDAS to mechanizm obsługi blobów wydajniej przy większej skali.
- Skalowanie DA nie oznacza po prostu 'kup lepszy serwer'. Ethereum celowo próbuje utrzymać węzeł dostępny na sprzęcie konsumenckim.
- PeerDAS nie jest jeszcze live — planowany jest w upgrade Fusaka.