Optymalizacja opłat za gaz Ethereum: jak Proto-Danksharding zmienił koszty transakcji L2

Istotną zmianą dla użytkowników L2 nie było powszechne obniżenie opłat za gaz Ethereum. Chodziło o tańszy, tymczasowy kanał danych dla rollupów. Aktualizacja Dencun dla Ethereum aktywowała proto-danksharding poprzez EIP-4844 13 marca 2024 roku. Rollupy mogły wówczas publikować partie za pomocą blobów – tymczasowych kontenerów danych z oddzielnym rynkiem opłat – zamiast polegać wyłącznie na trwale przechowywanych danych połączeń. Ta zmiana obniżyła główny koszt wejściowy dla L2, które korzystały z blobów, ale nie sprawiła, że ​​każda transakcja L2 była tania w każdym momencie.

Obecny kontekst ma znaczenie. Późniejsza aktualizacja Fusaka Ethereum wprowadziła PeerDAS do sieci głównej w grudniu 2025 roku, realizując ten sam plan dostępności danych, umożliwiając efektywniejsze skalowanie przepustowości blobów. Dla dzisiejszych użytkowników praktyczną lekcją jest to, że opłaty za L2 zależą od więcej niż jednej „ceny gazu”: L2 musi zapłacić za własne wykonanie i za publikację danych lub dowodów w Ethereum, podczas gdy popyt na przestrzeń blobów i polityka opłat każdego L2 mogą zmienić cenę ostateczną.

Co się zmieniło wraz z proto-dankshardingiem?

Przed wprowadzeniem protokołu EIP-4844, rollup zazwyczaj przesyłał dane transakcji do Ethereum jako calldata. Calldata stanowią część danych wejściowych transakcji Ethereum i pozostają dostępne w ramach historii łańcucha. Ta trwałość jest cenna, ale sprawia, że ​​wykorzystanie tych danych w rollupach na dużą skalę jest kosztowne.

EIP-4844 dodał nowy typ transakcji, często nazywany transakcją typu blob-carrying. Blob przechowuje dane, które są udostępniane sieci przez ograniczony czas, a nie są wykonywane przez maszynę wirtualną Ethereum lub przechowywane na zawsze, tak jak calldata. Według Ethereum.org dane blobów są dostępne przez około 18 dni (4096 epok), zanim zostaną usunięte. To okno czasowe zostało zaprojektowane z myślą o potrzebach związanych z dostępnością danych w ramach agregacji, a nie jako uniwersalne, trwałe miejsce przechowywania plików.

Rezultatem jest inna ścieżka ekonomiczna dla danych zbiorczych. Dane zbiorcze nadal są rozliczane lub zakotwiczone w Ethereum, ale mogą korzystać ze specjalnie zaprojektowanych zasobów dostępności danych, zamiast konkurować jedynie o zwykłe wykonywanie L1 i pojemność danych wywołań. Zapoznaj się z sekcją FAQ Dencun dotyczącą Ethereum , aby zapoznać się z oficjalnym omówieniem aktualizacji oraz specyfikacją EIP-4844 dotyczącą struktury transakcji i opłat.

Kluczowy mechanizm: opłaty za blob są oddzielone od opłat za normalny gaz

„Gaz” jest często używany tak, jakby był jedną liczbą. Po EIP-4844 ten skrót może zaciemniać to, za co płaci się w ramach rollupu. Transakcje blobów mają standardowe pola opłaty za realizację Ethereum oraz osobną maksymalną opłatę za gaz blobów. Protokół utrzymuje niezależną opłatę bazową za blob, która reaguje na wykorzystanie blobów, zamiast wyceniać bloby wyłącznie na standardowym rynku gazu L1.

EIP-4844 celowo oddziela ceny blobów. Specyfikacja opisuje gaz blob jako niezależny od gazu normalnego, z własną wartością docelową i regułą korekty. Dlatego nagłówek o niskim koszcie gazu L1 nie wskazuje automatycznie, ile będzie kosztować transakcja L2, a gwałtowny wzrost popytu na blob może mieć znaczenie dla konsolidacji, nawet gdy normalna aktywność L1 wydaje się być niska.

Jak to zmieniło transakcje L2 w praktyce

Zbiorcze raporty umożliwiają bardziej ekonomiczne publikowanie danych

Rollupy wykonują wiele transakcji użytkowników poza siecią główną Ethereum, a następnie przesyłają do Ethereum wystarczającą ilość informacji, aby stan rollupu mógł zostać zweryfikowany lub zakwestionowany zgodnie z jego projektem. Przed pojawieniem się blobów, trwałe dane wywołań stanowiły istotną część tego rachunku. Bloby zapewniają rollupowi tańsze miejsce do publikowania danych, które muszą być dostępne wystarczająco długo dla procesu bezpieczeństwa systemu, ale nie muszą pozostawać w trwałej historii wykonywania każdego węzła.

W przypadku platformy L2 obsługującej bloby, oszczędności mogą zostać przeniesione na użytkowników, zachowane w modelu opłat lub częściowo skompensowane innymi kosztami. Czas i skala ewentualnej redukcji zależą zatem od implementacji. Ethereum.org wyraźnie zaznacza, że ​​dostawcy usług rollup dokonują wyboru pomiędzy calldata a blob, zazwyczaj w oparciu o zapotrzebowanie na przestrzeń blob, a indywidualne harmonogramy wsparcia i stawki opłat mogą się różnić.

Opłaty stały się bardziej wrażliwe na przetwarzanie wsadowe i wydajność danych

Rollup zazwyczaj grupuje wiele działań użytkownika w partia przed wysłaniem do L1. Rozłożenie kosztu danych L1 na więcej transakcji może zmniejszyć udział przypadający na użytkownika, podczas gdy działania wymagające dużej ilości danych mogą zużywać większą część. Szczegóły różnią się w zależności od architektury rollupu, metody kompresji i polityki sekwencera. Prosty transfer tokenów, wywołanie kontraktu z dużą ilością danych wywoławczych i NFT mint mogą zatem generować bardzo różne wyniki opłat w tym samym L2.

Proto-danksharding nie eliminuje tego kompromisu. Obniża koszt warstwy dostępności danych w przypadku użycia obiektów blob; nie eliminuje obliczeń L2, złożoności inteligentnych kontraktów ani kosztów ograniczonych zasobów danych w przypadku przeciążenia.

Czego proto-danksharding nie zmienił

• Nie spowodowało to bezpośrednio obniżenia ceny każdej transakcji w sieci Mainnet. W FAQ Dencun podano, że EIP-4844 dotyczy głównie opłat L2. Wpływ opłat w sieci Mainnet jest pośredni i zależy od popularności i popytu.
• Nie oznacza to, że przestrzeń blobów jest nieograniczona. Pojemność blobów jest ograniczona, a funkcje agregacji mogą korzystać z calldata, gdy przestrzeń blobów jest poszukiwana lub niedostępna przy akceptowalnym koszcie.
• Nie zmuszało to każdego L2 do korzystania z blobów w ten sam sposób. Sekwencer lub operator rollup zazwyczaj zarządza opcjami publikowania i przetwarzania wsadowego danych.
• Nie przekształciło to blobów w trwałe magazyny. Zawartość blobów jest tymczasowa; aplikacje wymagające trwałych danych muszą korzystać z odpowiedniej konstrukcji magazynu.
• Nie usunięto opłat za mosty, swapy, protokoły ani portfele. Wyświetlana suma może obejmować kilka warstw kosztów poza podstawową opłatą transakcyjną L2.

Dlaczego plan działania po Dencun nadal ma znaczenie: PeerDAS

Proto-danksharding był celowo pomostem do bardziej skalowalnej dostępności danych, a nie ostateczną formą shardingu. EIP-4844 wprowadził format transakcji blobów i oddzielny rynek opłat, zachowując jednocześnie konserwatywną początkową przepustowość. W grudniu 2025 roku Fusaka wprowadził PeerDAS (EIP-7594), projekt próbkowania dostępności danych, który pozwala węzłom weryfikować dostępność poprzez próbkowanie danych, zamiast aby każdy węzeł pobierał wszystkie dane blobów.

Ma to znaczenie, ponieważ większa przepustowość blobów może obsłużyć więcej danych zbiorczych bez konieczności obciążania każdego węzła pełnym obciążeniem. Nie zmienia to podstawowej zasady dla użytkownika: opłata za L2 jest nadal dynamiczna. Ulepszenie techniczne może zwiększyć przepustowość i zmniejszyć obciążenie, ale nie jest to obietnica stałej ceny. Zapoznaj się z ogłoszeniem Fundacji Ethereum dotyczącym sieci głównej Fusaka oraz oficjalnym przeglądem PeerDAS, aby poznać potwierdzony zakres tej aktualizacji.

Praktyczny proces optymalizacji opłat dla użytkowników L2

Nie można wybrać blobu bezpośrednio w typowej transakcji portfela; o sposobie księgowania partii decyduje proces rollupu. Można jednak obniżyć koszty, których można uniknąć, i wybrać ścieżkę dopasowaną do danej transakcji.

1. Zidentyfikuj rzeczywistą sieć. Sprawdź, czy aplikacja korzysta z sieci głównej Ethereum, konkretnego rollupu, czy innego łańcucha. „Zgodność z Ethereum” nie oznacza, że ​​korzysta z przestrzeni blobów Ethereum.
2. Przed potwierdzeniem przeczytaj zestawienie opłat. Odróżnij opłatę za sieć L2 od opłaty za aplikację, most, wymianę lub protokół.
3. Porównaj tę samą akcję w obsługiwanych L2. Korzystaj wyłącznie z oficjalnej obsługi sieciowej aplikacji i aktualnego kursu wymiany portfela. Niższa opłata jest przydatna tylko wtedy, gdy miejsce docelowe, płynność, założenia dotyczące bezpieczeństwa i ścieżka wypłaty odpowiadają Twojemu przypadkowi użycia.
4. Unikaj niepotrzebnych połączeń z dużą ilością danych. Wielokrotne zatwierdzenia, powtarzające się próby i złożone interakcje z umowami mogą kosztować więcej niż prosty transfer. Konsoliduj działania tylko wtedy, gdy nie stwarza to większego ryzyka dla bezpieczeństwa lub wykonania.
5. Nie próbuj ponownie bezmyślnie po opóźnieniu. Najpierw sprawdź status transakcji. Zastąpienie lub duplikacja transakcji może spowodować naliczenie kolejnej opłaty lub niezamierzoną drugą akcję.
6. Zachowaj niewielki bufor zasobów gazu natywnego na L2. Wyczerpanie się gazu po mostkowaniu lub wymianie może wymusić dodatkowy transfer i opóźnić transakcję.
7. Korzystaj z oficjalnych eksploratorów i dokumentacji. Przed podpisaniem umowy zweryfikuj adresy kontraktów, kroki pomostowe i ustawienia sieciowe. „Tania” transakcja wysłana do niewłaściwej sieci nie jest optymalizacją.

Kiedy niższa wyświetlana opłata nie jest lepszym wyborem

Optymalizacja opłat jest warunkowa. Niedrogi L2 może być dobrym rozwiązaniem w przypadku częstych i obsługiwanych działań, takich jak interakcja z aplikacją, która pozostaje w obrębie danego ekosystemu. Może jednak okazać się nieodpowiednim rozwiązaniem, jeśli konieczne jest natychmiastowe ponowne utworzenie mostu, aplikacja nie obsługuje sieci docelowej lub jeśli płynność i ustalenia dotyczące wypłat generują większe koszty i ryzyko niż początkowa oszczędność w opłatach.

Na przykład, przeniesienie zasobów do niskopłatnej platformy L2 w celu jednej, niewielkiej wymiany może być nieefektywne, jeśli most, zatwierdzenia i transfer zwrotny kosztują więcej niż transakcje w miejscu, w którym zasoby już się znajdują. Z drugiej strony, użytkownik realizujący wiele obsługiwanych transakcji w ramach jednego ekosystemu L2 może odnieść większe korzyści z niskich kosztów cyklicznego wykonywania transakcji i transmisji danych. Porównaj całą ścieżkę, a nie tylko pierwszą wycenę gazu.

Jak programiści powinni interpretować zmianę

W przypadku zespołów zajmujących się rollupami, bloby przesuwają cel optymalizacji z „minimalizacji stałych danych wywołań za wszelką cenę” na „efektywne wykorzystanie dostępności danych przy jednoczesnym obsłudze oddzielnego rynku opłat za blob”. Obejmuje to kompresję, tworzenie pakietów, działanie awaryjne w przypadku wzrostu opłat za blob oraz przejrzyste rozliczanie opłat dla użytkowników. Aplikacje powinny unikać ubiegania się o stałą obniżkę opłat wyłącznie na podstawie EIP-4844, ponieważ popyt, implementacja rollupów i przyszłe aktualizacje protokołu pozostają zmienne.

Dla programistów aplikacji w warstwie L2, projektowanie transakcji nadal ma znaczenie. Zmniejszenie zbędnych zapisów do pamięci, danych wywołań, wywołań kontraktów i nieudanych wykonań może obniżyć część kosztów wykonania w kosztach użytkownika. Są to wzajemnie uzupełniające się optymalizacje: proto-danksharding przede wszystkim redukuje komponent księgowania danych w warstwie L1, podczas gdy efektywne kontrakty rozwiązują problem pracy wykonywanej w samej warstwie L2.

Podsumowanie

Proto-danksharding zmienił ekonomię L2, dając rollupom tymczasowy, oddzielnie wyceniany pas danych. Właśnie dlatego wiele rollupów z obsługą blobów mogło znacząco zredukować koszty rozliczeń po wprowadzeniu Dencun. Późniejsze wprowadzenie PeerDAS wzmocniło aspekt przepustowości tego samego planu, ale żadna z aktualizacji nie powoduje statyczności opłat ani nie gwarantuje, że każdy L2 będzie tańszy niż sieć główna dla każdego zadania.

Dla użytkowników najlepszą optymalizacją jest wybór właściwej sieci dla całej ścieżki transakcji, zapoznanie się z rzeczywistą wyceną opłat, unikanie zbędnych wywołań kontraktów i zapewnienie wystarczającej ilości gazu natywnego dla używanej sieci. Dla programistów długofalową lekcją jest traktowanie dostępności blobów, opłat za blob, przetwarzania wsadowego i wykonywania L2 jako powiązanych, ale odrębnych elementów modelu kosztów.