Obserwowałem Ethereum wystarczająco długo, aby wiedzieć, że prawdziwy postęp rzadko przychodzi z fajerwerkami. Zwykle przychodzi cicho, ukryty wewnątrz zmian w kodzie, które zaczynają mieć znaczenie dopiero wtedy, gdy sieć jest pod presją. Spędziłem tygodnie na czytaniu specyfikacji, śledzeniu rozmów na testnetach i obserwowaniu dyskusji walidatorów wokół aktualizacji Fusaka, a to, co mnie wyróżniało, to nie tylko skala zmian, ale także intencja, która za nimi stała.

Kiedy Fusaka zadebiutowała 3 grudnia 2025 roku, nie wydawało się to jak pojedynczy moment. To wyglądało jak koniec długiego okresu starannego przygotowania. Już widziałem, jak przeszła przez testnety Holesky, Sepolia i Hoodi, każda faza ujawniająca przypadki brzegowe, pytania o wydajność i rodzaje błędów, które pojawiają się tylko wtedy, gdy prawdziwi ludzie naciskają systemy w niespodziewany sposób. W momencie, gdy aktywacja mainnetu miała miejsce o 21:49 UTC, aktualizacja wydawała się mniej skokiem, a bardziej jak Ethereum w końcu wypuszczające powietrze po wstrzymaniu oddechu.

Na pierwszy rzut oka, Fusaka wygląda prosto. Limit gazu bloku wzrósł z 45 milionów do 150 milionów. To samo w sobie opowiada historię. Bloki Ethereum mogą teraz przenosić znacznie więcej pracy niż wcześniej, co oznacza więcej transakcji, więcej aktywności smart kontraktów i więcej miejsca na aplikacje, których ludzie rzeczywiście używają. Ale szybko się przekonałem, że Fusaka nie polega tylko na wpychaniu większych bloków na łańcuch. Chodzi o zapewnienie, że robienie tego nie cichutko wypycha zwykłych operatorów węzłów z systemu.

Ta równowaga jest miejscem, gdzie większość aktualizacji Ethereum albo odnosi sukces, albo ponosi porażkę, a Fusaka została wyraźnie zaprojektowana z myślą o tej napiętej sytuacji. Przeglądając badania i notatki implementacyjne, ciągle wracałem do dwóch pomysłów, które cicho napędzają całą aktualizację: Peer Data Availability Sampling i Verkle Trees. To nie są błyskotliwe koncepcje, ale rozwiązują problemy, które Ethereum nosiło przez lata.

Spędziłem dużo czasu próbując zrozumieć PeerDAS w prostych słowach. To, co w końcu mi się zrozumiało, to że Ethereum odchodzi od pomysłu, że każdy walidator musi osobiście przechowywać i weryfikować każdy pojedynczy kawałek danych. Zamiast zmuszać walidatorów do pobierania całych blobów danych, PeerDAS pozwala im sprawdzać małe, losowe próbki pobrane z różnych peerów. Jeśli wystarczająca liczba tych próbek jest ważna, sieć może być pewna, że pełne dane istnieją i są dostępne. To subtelna zmiana, ale potężna. Redukuje to presję na pasmo, obniża wymagania sprzętowe i sprawia, że skalowanie jest mniej wrogie dla mniejszych uczestników.

Verkle Trees zajęły mi więcej czasu. Przeszedłem przez porównania, diagramy i dyskusje, zanim naprawdę zrozumiałem, dlaczego są ważne. Stan Ethereum ciągle rośnie, a udowodnienie, że mały kawałek tego stanu jest ważny, tradycyjnie wymagało obszernej weryfikacji. Verkle Trees dramatycznie kompresują te dowody. Rezultatem jest szybsza weryfikacja i mniejszy bloat danych, co staje się krytyczne, gdy pojemność bloku wzrasta tak bardzo. Bez czegoś takiego jak Verkle Trees, podniesienie limitu gazu w tak agresywny sposób wydawałoby się lekkomyślne. Z nimi wydaje się to przemyślane.

To, co mnie zaskoczyło podczas moich badań, to jak wyraźnie Fusaka jest zgodna z długoterminowym kierunkiem Ethereum, zwłaszcza w kwestii rollupów i warstwy 2. Większe bloki i ulepszone zarządzanie blobami nie dotyczą tylko użytkowników mainnetu. Bezpośrednio pomagają rollupom w bardziej efektywnym i niezawodnym przesyłaniu danych. Dla programistów budujących na warstwie 2 oznacza to mniej dziwnych przypadków brzegowych podczas przeciążenia i bardziej przewidywalną dostępność danych. Dla użytkowników cicho przekłada się to na płynniejsze doświadczenia podczas szczytowego zapotrzebowania, nawet jeśli nigdy nie będą wiedzieć, dlaczego rzeczy wydają się lepsze.

Oczywiście, żadna aktualizacja tego typu nie przychodzi bez kompromisów. Uważnie śledziłem rozmowy walidatorów i operatorów węzłów, ponieważ zazwyczaj jako pierwsi odczuwają obciążenie. Większe bloki oznaczają więcej danych przepływających przez sieć, a niektórzy operatorzy będą musieli aktualizować konfiguracje lub sprzęt z czasem. To, co mnie uspokoiło, to widok, ile myśli włożono w minimalizowanie tego wpływu. PeerDAS i Verkle Trees nie są dodatkami; to zabezpieczenia mające na celu utrzymanie decentralizacji Ethereum, nawet gdy się rozwija.

Bezpieczeństwo było kolejnym obszarem, w którym mogłem zobaczyć powagę za Fusaka. Przed uruchomieniem Fundacja Ethereum przeprowadziła czterotygodniową nagrodę za błędy, która oferowała nagrody do dwóch milionów dolarów. To nie jest symboliczne pieniądze. To zaproszenie dla najlepszych badaczy, aby zaatakowali kod, zanim prawdziwa wartość będzie zagrożona. Obserwowanie tego procesu ujawniło, że Fusaka nie była pospieszna. Została przetestowana, wyzwana i udoskonalona publicznie.

Po spędzeniu tego czasu na obserwacji, czytaniu i składaniu wszystkiego razem, Fusaka wydaje się mniej jedną aktualizacją, a bardziej oświadczeniem. Ethereum wybiera skalowanie bez udawania, że decentralizacja jakoś sama się załatwi. Wybiera staranne inżynierowanie zamiast skrótów i stopniowe zwiększanie pojemności zamiast dramatycznych, ale kruchych skoków.

Z mojego punktu widzenia, Fusaka nie obiecuje natychmiastowych tanich opłat ani nieskończonego przepustowości. To, co oferuje, to coś bardziej realistycznego i trwalszego: miejsce do wzrostu, inteligentniejsze zarządzanie danymi i sieć, która może wspierać więcej osób bez cichutkiego podnoszenia kosztów uczestnictwa. To nie jest błyskotliwy postęp, ale to ten, który trwa.

\u003ct-43/\u003e

\u003ct-32/\u003e

\u003ct-58/\u003e