Jak PeerDAS poprawi dostępność danych Ethereum?

Aby zapewnić wydajne zarządzanie danymi i bezpieczną weryfikację, Ethereum ewoluowało od DA do DAS, a ostatecznie wprowadziło PeerDAS.

Autor: 0XNATALIE

Podczas ostatniego spotkania deweloperów Ethereum omawiano propozycję podzielenia hard forka Pectra na dwie części. Propozycja ta została wcześniej odrzucona, ponieważ obawiano się opóźnienia aktualizacji drzew Verkle. Jednak na tym spotkaniu deweloperzy ponownie przedstawili ten pomysł, ponieważ chcieli włączyć więcej propozycji ulepszeń (EIP) do forka Pectra. Zaproponowano podział hard forka na dwie części: pierwsza część obejmie wszystkie obecne EIP na Pectra Devnet 3, a druga część forka obejmie EOF (EVM Object Format) i PeerDAS. Aby lepiej zrozumieć PeerDAS, najpierw zaczniemy od podstawowej koncepcji dostępności danych.

DA: Zapewnienie, że węzły uzyskują dane z łańcucha

Dostępność danych (Data Availability, DA) oznacza zapewnienie, że blok opublikowany przez proponującego blok oraz wszystkie dane transakcyjne zawarte w bloku są skutecznie dostępne i możliwe do pobrania przez innych uczestników sieci. Dostępność danych jest kluczowym czynnikiem bezpieczeństwa blockchaina, ponieważ jeśli dane są niedostępne, nawet jeśli blok jest legalny, inne węzły nie mogą zweryfikować jego zawartości, co może prowadzić do problemów z konsensusem i ataków na sieć. Na przykład atakujący może opublikować tylko część danych bloku, uniemożliwiając innym węzłom weryfikację.

Kiedy nowy blok jest rozgłaszany, wszystkie uczestniczące węzły pobierają i weryfikują dane bloku. Ten model jest wykonalny, gdy sieć jest niewielka, ale wraz z rozwojem blockchaina ilość danych staje się ogromna, a wymagania dotyczące przechowywania przez każdy węzeł stale rosną, co zwiększa wymagania sprzętowe. Aby umożliwić udział w weryfikacji bloków również lekkim węzłom (takim jak urządzenia mobilne czy komputery), blockchain wprowadził technologię sharding.

Sharding to technika dzielenia całej sieci blockchain na wiele małych "shardów". Każdy shard przetwarza tylko swoją część danych i nie musi obsługiwać całych danych blockchaina. W rezultacie pojedynczy węzeł musi obsługiwać tylko dane swojego shardu. Jednak każdy shard przetwarza tylko część danych, co oznacza, że węzły innych shardów nie mają bezpośredniego dostępu do pełnych danych. Jak więc zapewnić, że dane w shardach są dostępne i że inne węzły mogą zweryfikować ich poprawność? Na przykład, węzeł w jednym shardzie publikuje nowo wygenerowany blok, ale może opublikować tylko część danych. Jeśli inne węzły nie mogą uzyskać wszystkich danych bloku, nie mogą zweryfikować, czy blok jest autentyczny i legalny.

DAS: Weryfikacja dostępności danych całości poprzez częściowe dane

Aby rozwiązać problem dostępności danych w shardach, zaproponowano technikę próbkowania dostępności danych (Data Availability Sampling, DAS), której główną ideą jest weryfikacja dostępności danych bloku poprzez losowe próbkowanie, bez konieczności przechowywania lub pobierania przez każdy węzeł pełnych danych bloku.

Próbkowanie dostępności danych pozwala węzłom na losowe pobranie tylko części danych bloku w celu weryfikacji dostępności danych; jeśli węzeł może skutecznie pobrać i zweryfikować te losowe fragmenty danych, można założyć, że cały blok danych jest dostępny.

Aby umożliwić taką weryfikację próbkowania, dane bloku są zwykle kodowane za pomocą RS encoding. Ten rodzaj kodowania pozwala na odzyskanie pełnych danych nawet w przypadku utraty części danych. Dlatego nawet jeśli węzeł pobierze tylko część danych bloku, może wywnioskować i potwierdzić poprawność całych danych bloku. DAS poprzez weryfikację próbkowania zmniejsza ilość danych, które każdy węzeł musi przetworzyć, umożliwiając udział w weryfikacji bloków również lekkim węzłom.

Warstwa DA, taka jak Celestia, realizuje to właśnie za pomocą tych technologii. Główne elementy to RS encoding + validity proof + DAS.

• RS encoding (Reed-Solomon Encoding): Ten sposób kodowania pozwala węzłom, które otrzymały tylko część fragmentów danych, na odbudowanie całego bloku danych. Jest podobny do kodów korekcyjnych, ma pewną odporność na błędy i nawet przy utracie części danych, pozostałe fragmenty wystarczają do odtworzenia pełnych danych.
• Validity Proof (dowód poprawności): Wykorzystuje dowody zerowej wiedzy, aby zapewnić, że dane podczas kodowania i transmisji nie zostały uszkodzone. Jeśli weryfikacja się powiedzie, cały blok danych można poprawnie zdekodować.
• DAS (próbkowanie dostępności danych): Lekkie węzły losowo próbkują część fragmentów RS encoding z bloku, weryfikują dostępność tych fragmentów i na tej podstawie wnioskują, że cały blok danych jest dostępny.

PeerDAS: Współpraca węzłów przy weryfikacji danych

PeerDAS to konkretna implementacja DAS, która wykorzystuje sieć peer-to-peer do próbkowania dostępności danych. Sieć peer-to-peer składa się z wielu węzłów, które komunikują się bezpośrednio ze sobą. W DAS każdy węzeł niezależnie przeprowadza próbkowanie i weryfikację danych, natomiast PeerDAS optymalizuje ten proces, umożliwiając węzłom współdzielenie i wspólną weryfikację danych z bloków, co dodatkowo zwiększa efektywność weryfikacji. Węzły nie są od siebie odizolowane, mogą dzielić się zadaniami i wynikami weryfikacji danych oraz polegać na danych już zweryfikowanych przez inne węzły. Dzięki temu węzły nie muszą samodzielnie wykonywać całej pracy weryfikacyjnej, lecz współpracują, dzieląc się zadaniami, co jeszcze bardziej zmniejsza ich obciążenie. Ponadto współpraca w weryfikacji utrudnia manipulację danymi – atakujący musiałby jednocześnie wpłynąć na wiele węzłów weryfikujących, aby skutecznie zmienić dane.

Obecnie, zgodnie z najnowszymi informacjami ze spotkania Ethereum dotyczącego PeerDAS, zespół klienta Ethereum Lighthouse połączył już gałąź DAS z główną gałęzią i prowadzi testy w celu zapewnienia kompatybilności z PeerDAS. Gałąź to zwykle niezależna wersja kodu używana do opracowywania i testowania nowych funkcji lub ulepszeń; połączenie z główną gałęzią oznacza, że dana funkcja lub ulepszenie zostało już ukończone i jest wystarczająco stabilne, by zostać włączone do głównego kodu.