Solana Agave 4.2: 90% obniżka czynszu i droga do slotów 200 ms

Trzy aktualizacje z bramkowaniem funkcji zaczęły się aktywować w sieci głównej Solany w tygodniu 17 sierpnia. 90% redukcja czynszu za przechowywanie w łańcuchu, 3,3-krotny wzrost maksymalnego rozmiaru transakcji oraz etapowe skracanie czasu slotu z 400 ms do 200 ms to najważniejsza zmiana infrastrukturalna Solany od czasu, gdy Firedancer osiągnął sieć główną.

Mapa drogowa infrastruktury Solany na 2026 rok to sekwencja zakładów ułożonych jeden na drugim. Firedancer osiągnął sieć główną w grudniu 2025 roku i obecnie przenosi około 14% udziału w sieci głównej na ponad 20% aktywnych walidatorów. Agave 4.2 zmienia ekonomikę i charakterystykę wydajności sieci, którą ci walidatorzy obsługują. Alpenglow, wydany w następnej wersji, całkowicie zastępuje mechanizm konsensusu. Każda warstwa zależy od poprzedniej, a każda zmienia to, co programiści mogą budować na Solanie.

Ten artykuł rozbija trzy aktualizacje Agave 4.2, mierzy, co każda z nich zmienia w praktyce, i analizuje, jak pozycjonują Solanę względem mapy drogowej Hegota Ethereum i szerszej konkurencji o uwagę programistów i użytkowników.

Redukcja czynszu: co konta za 0,016 USD oznaczają dla budowniczych

Czynsz na Solanie to minimalne saldo, które użytkownik musi zdeponować, aby konto pozostało otwarte. Depozyt skaluje się z ilością przechowywanych danych. Przy poprzedniej stawce standardowe konto tokena SPL wymagało około 0,16 USD w SOL jako depozytu zwolnionego z czynszu. Ta kwota nie jest opłatą. Jest zablokowana na koncie tak długo, jak długo konto istnieje, i zwracana po zamknięciu konta.

SIMD-0437 obniża stałą lamportów na bajt o współczynnik 10, z 6 960 do 696. Depozyt zwolniony z czynszu dla tego samego konta tokena spada do około 0,016 USD. Dla pojedynczego konta różnica jest trywialna. Dla aplikacji, które tworzą tysiące lub miliony kont, różnica jest strukturalna.

Zdecentralizowana giełda, która utrzymuje księgę zamówień w łańcuchu, tworzy konta dla każdego otwartego zlecenia. Protokół gier, który śledzi stan graczy, tworzy konta dla każdego aktywnego gracza. Platforma tokenizacji, która emituje ułamkowe udziały, tworzy konta dla każdego posiadacza. W każdym przypadku koszt uruchomienia aplikacji skaluje się liniowo z liczbą kont, a SIMD-0437 zmniejsza ten koszt o 90%.

Praktyczny efekt jest taki, że kategorie aplikacji, które były nieekonomiczne na Solanie przy poprzedniej stawce czynszu, stają się opłacalne przy nowej. Księgi zamówień w łańcuchu z granularnymi poziomami cen, w pełni w łańcuchu gry z trwałym stanem dla milionów graczy oraz platformy tokenizacji z dziesiątkami tysięcy posiadaczy stają się znacznie tańsze w obsłudze.

Kontrargumentem jest to, że tańsze przechowywanie zwiększa rozdęcie stanu. Każde konto istniejące na Solanie zajmuje miejsce, które walidatorzy muszą przechowywać i przetwarzać. Zmniejszenie kosztu tworzenia kont o 90% może spowodować odpowiedni wzrost liczby kont, obciążając wymagania sprzętowe walidatorów. Anza, zespół programistów stojący za Agave, argumentował, że kompresja stanu i funkcje zarządzania cyklem życia kont w przyszłych wydaniach rozwiążą problem rozdęcia niezależnie od stawki czynszu.

Większe transakcje: od obejść do atomowego wykonania

Limit 1232 bajtów na transakcję był jednym z najbardziej uporczywych problemów dla programistów Solany. Ograniczenie wynika z limitu rozmiaru pakietów UDP w sieci, który został ustalony przy starcie i nigdy nie został zaktualizowany. Programiści pracujący ze złożonymi operacjami, dowodami ZK, dużymi konfiguracjami multisig i transakcjami DeFi z wieloma instrukcjami musieli dzielić pracę na wiele transakcji lub używać tabel odnośników adresów, aby skompresować odwołania.

SIMD-0296 podnosi limit do 4096 bajtów dzięki nowemu formatowi transakcji v1. Format zastępuje instrukcje ComputeBudgetProgram maską konfiguracyjną przenoszoną bezpośrednio w nagłówku transakcji, uwalniając miejsce na rzeczywiste dane instrukcji. Transakcje v1 są identyfikowane przez wiodący bajt wersji 129 i nie obsługują tabel odnośników adresów, ale przy 4096 bajtach pełna lista adresów może być w większości przypadków zawarta bezpośrednio.

Wpływ najbardziej odczuwają trzy kategorie programistów. Weryfikacja dowodów ZK, która wymaga przekazania danych dowodu jako danych wejściowych transakcji, może teraz zostać wykonana jako pojedyncza atomowa transakcja zamiast dzielenia na wiele wywołań. Duże portfele multisig z wieloma podpisującymi mogą zawierać wszystkie podpisy w jednej transakcji. A schematy podpisów na łańcuchu, takie jak BLS, które wymagają większego materiału klucza, mogą działać bez obejść.

Istniejące aplikacje nie muszą się zmieniać. Formaty transakcji v0 i legacy działają dokładnie tak samo jak wcześniej. Tylko aplikacje, które chcą większego rozmiaru, muszą przyjąć v1. Indeksery i eksploratory bloków, które dekodują surowe bajty transakcji, będą musiały rozpoznać nowy układ, ale ścieżka migracji jest opcjonalna, a nie wymuszona.

3,3-krotny wzrost może wydawać się skromny w porównaniu z praktycznie nieograniczonym calldata Ethereum. Różnica polega na tym, że transakcje Solany wykonują się w pojedynczym slocie z deterministycznym porządkowaniem, podczas gdy transakcje Ethereum konkurują o włączenie do bloku ze zmiennymi kosztami gazu. Podejście Solany wymienia elastyczność na szybkość: transakcja o rozmiarze 4096 bajtów na Solanie potwierdza się w mniej niż sekundę, podczas gdy porównywalna transakcja Ethereum może czekać minuty w zależności od cen gazu i zatorów w bloku.

Droga do slotów 200 ms

SIMD-0525 jest najbardziej ambitną z trzech aktualizacji i tą, która ma najbardziej widoczny wpływ na użytkowników. Obecny czas slotu Solany wynosi 400 ms, co oznacza, że nowy blok jest produkowany mniej więcej co 0,4 sekundy. SIMD-0525 ma na celu zmniejszenie do 200 ms, co praktycznie podwaja tempo produkcji bloków w sieci.

Redukcja nie jest natychmiastowa. Przebiega w czterech kolejnych krokach po 50 ms: z 400 ms do 350 ms, następnie do 300 ms, potem do 250 ms i wreszcie do 200 ms. Każdy krok jest blokowany przez aktywację funkcji, którą muszą przyjąć walidatorzy. Protokół zawiera kluczowe zabezpieczenie: jeśli wskaźnik pomijania bloków przekroczy określony próg na dowolnym etapie, sieć nie przejdzie do następnego kroku, dopóki stabilność nie zostanie przywrócona.

Testnet już zademonstrował sloty 300 ms, potwierdzając pierwsze dwa kroki. Pozostałe kroki do 250 ms i 200 ms będą zależeć od wydajności walidatorów mainnetu w warunkach rzeczywistego obciążenia, które różnią się od warunków testnetu pod względem wolumenu ruchu, rozmieszczenia geograficznego i różnorodności sprzętu.

Dla użytkowników szybsze sloty oznaczają szybsze potwierdzenia. Swap na DEX Solany obecnie potwierdza się w około 400 ms. Przy slotach 200 ms ten sam swap potwierdza się w połowie tego czasu. Dla animatorów rynku ciaśniejsze sloty oznaczają ciaśniejsze spready, ponieważ okno, w którym oferowana cena może się zdezaktualizować, zmniejsza się z każdym krokiem. Dla walidatorów szybsze sloty oznaczają wyższe wymagania sprzętowe: budżet obliczeniowy na slot pozostaje taki sam, ale czas dostępny na jego przetworzenie zmniejsza się o połowę.

Obawa dotycząca sprzętu walidatorów nie jest teoretyczna. ETHNews poinformowało, że aktualizacja Agave 4.2 „sprawia, że jest taniej w użyciu, trudniej w prowadzeniu”. Obniżenie czynszu obniża koszty dla programistów. Skrócenie czasu slotu zwiększa koszty dla walidatorów. To, czy kompromis jest netto pozytywny, zależy od tego, czy tańsze koszty rozwoju przyciągną wystarczająco dużo nowej aktywności, aby uzasadnić wyższe koszty infrastruktury, które muszą ponieść walidatorzy.

Rola Firedancer w aktualizacji

Wymagania wydajnościowe Agave 4.2 byłyby trudniejsze do spełnienia bez obecności Firedancer na mainnecie. Klient walidatora Jump Crypto napisany w C i C++, który trafił do mainnetu w grudniu 2025 roku, zapewnia bazę wydajnościową, której sam oryginalny klient Agave nie mógł zagwarantować.

Dane operatorów z okresu wdrożenia 2025–2026 pokazują, że walidatory Firedancer osiągnęły poprawę wskaźnika pomijania o 18 do 28 punktów bazowych, o 15% mniej utraconych kredytów głosowania, opóźnienie głosowania wynoszące około 1,002 slotów oraz pełniejsze bloki średnio 47 milionów w porównaniu z 44,8 milionami jednostek obliczeniowych w Agave. Te różnice mają znaczenie, gdy czasy slotów są skracane o połowę, ponieważ tolerancja na opóźnienia przetwarzania maleje z każdym zmniejszeniem.

Firedancer posiada obecnie około 14% udziału w mainnecie, rozproszonego na ponad 20% aktywnych walidatorów. Różnorodność klientów jest również cechą odporności: błąd, który powoduje awarię Agave, niekoniecznie wpłynie na Firedancer i odwrotnie. Dla sieci przygotowującej się do skrócenia czasu slotu o połowę, a następnie całkowitej wymiany mechanizmu konsensusu, posiadanie dwóch niezależnych klientów nie jest luksusem, ale wymogiem bezpieczeństwa.

Alpenglow: przepisanie konsensusu czekające w następnej wersji

Agave 4.2 zawiera kompletny kod Alpenglow, ale nie aktywuje go na mainnecie. Ta aktywacja jest zarezerwowana dla Agave 4.3, planowanej na październik 2026 roku. Gdy zostanie wydana, Alpenglow zastąpi zarówno Proof of History, jak i TowerBFT, dwa systemy, na których Solana działa od momentu uruchomienia w 2020 roku.

Zastąpieniem jest Votor, algorytm głosowania, który celuje w finalność około 150 ms w porównaniu z obecną finalnością TowerBFT wynoszącą 12,8 sekundy. Votor całkowicie eliminuje transakcje głosowania w łańcuchu. W TowerBFT walidatory przesyłają głosy jako zwykłe transakcje, które zużywają przestrzeń blokową i jednostki obliczeniowe. W Votor walidatory wymieniają głosy bezpośrednio przez oddzielny kanał, uwalniając pojemność bloków dla transakcji użytkowników.

Model bezpieczeństwa toleruje jednocześnie 20% udziału offline i 20% udziału działającego wrogo. Anza opublikowała program bug bounty o wartości 50 000 SOL dla Alpenglow, z przyjmowaniem zgłoszeń od 5 sierpnia, co wskazuje na zaufanie do kodu, jednocześnie przyznając, że wymiana konsensusu tej skali wymaga zewnętrznego przeglądu bezpieczeństwa.

Kolejność ma znaczenie. Agave 4.2 zmniejsza czynsz, zwiększa rozmiar transakcji i zaczyna skracać czasy slotów. Agave 4.3 zastępuje mechanizm konsensusu. Każda aktualizacja jest zaprojektowana tak, aby była niezależnie użyteczna, ale pełna wizja – sloty 200 ms z finalnością 150 ms w protokole konsensusu, który nie zużywa przestrzeni blokowej na głosowanie – wymaga pomyślnego wdrożenia wszystkich.

Jak to się ma do mapy drogowej Hegota Ethereum

Solana i Ethereum podążają różnymi ścieżkami do tego samego celu: niższych kosztów, wyższej przepustowości i szybszej finalności. Kontrast między Agave 4.2 a planem aktualizacji Hegota Ethereum ilustruje różnice architektoniczne.

Harmonogram Hegota Ethereum przewiduje termin preferencji we wrześniu, a sama aktualizacja jest planowana na 2027 rok. Zakres jest nadal definiowany: zgłoszono 66 propozycji, a społeczność musi odrzucić większość z nich przed sfinalizowaniem aktualizacji. Kluczowe kandydatury obejmują EIP-8182 dotyczący natywnej prywatności, FOCIL w celu odporności na cenzurę oraz zwiększenie przepustowości blobów dla skalowalności rollupów. Devnet Glamsterdam opóźnił się, przesuwając harmonogram dalej.

Podejście Solany jest szybsze i bardziej scentralizowane w podejmowaniu decyzji. Anza ustala harmonogram aktywacji funkcji, walidatory go przyjmują, a aktualizacja przebiega. Nie ma odpowiednika wieloletniego procesu EIP Ethereum z zarządzaniem społecznościowym nad tym, które propozycje zostaną wybrane. Kompromis polega na tym, że Solana może dostarczyć trzy główne aktualizacje w jednym wydaniu, podczas gdy Ethereum potrzebuje 12–18 miesięcy na sfinalizowanie porównywalnego zakresu zmian.

Różnica wydajności po Agave 4.2 jest wyraźna. Solana przy slotach 200 ms z finalnością Alpenglow 150 ms potwierdzałaby transakcje w czasie poniżej 400 ms. Obecna finalność Ethereum wynosi około 13 minut, a ulepszenia Hegota, jeśli zostaną wdrożone, mają na celu finalność pojedynczego slotu, która nadal byłaby mierzona w sekundach, a nie milisekundach.

Różnica kosztów również się powiększa. Obniżenie opłat za przechowywanie w Solanie sprawia, że przechowywanie w łańcuchu jest o rząd wielkości tańsze. L1 Ethereum pozostaje drogie w przechowywaniu, a rollupy absorbują większość redukcji kosztów poprzez dane blob. Dla deweloperów wybierających miejsce do budowy nowych aplikacji, ekonomika infrastruktury coraz bardziej sprzyja Solanie w przypadkach użycia wymagających wysokiej przepustowości, niskich kosztów i szybkiej finalizacji.

Kontrargumentem jest to, że wolniejszy proces Ethereum produkuje bardziej solidne, sprawdzone w boju aktualizacje z szerszym konsensusem społeczności. Przewaga szybkości Solany odbywa się kosztem presji na centralizację walidatorów i cieńszego marginesu bezpieczeństwa podczas większych przejść infrastrukturalnych. Rynek ostatecznie oceni oba podejścia na podstawie adopcji przez deweloperów i aktywności użytkowników, a nie tylko specyfikacji technicznych.

Sygnał migracji deweloperów

Aktualizacje infrastruktury mają znaczenie tylko wtedy, gdy deweloperzy zareagują budując aplikacje, które z nich korzystają. Wiodącym wskaźnikiem nie jest cena SOL ani TVL, ale tempo wdrażania nowych programów i wolumen adopcji transakcji v1 w tygodniach po aktywacji.

Ekosystem deweloperski Solany stale rósł przez 2026 rok, a Fundacja Solana raportuje ponad 2500 aktywnych miesięcznie deweloperów w swoim najnowszym raporcie ekosystemowym. Oczekuje się, że obniżenie opłat przyspieszy rozwój gier w łańcuchu, zdecentralizowanych protokołów społecznościowych i platform tokenizacji, które wcześniej były ograniczane kosztami tworzenia kont.

Dynamika konkurencyjna jest również istotna. Deweloperzy, którzy czekali na tańszą infrastrukturę Solany, teraz ją mają. Deweloperzy rozważający rollupy Ethereum ze względów kosztowych muszą porównać dodatkową złożoność mostkowania L2 i rozdrobnioną płynność z zintegrowanym doświadczeniem L1 Solany przy podobnych lub niższych kosztach.

Przeciwny argument: dlaczego te aktualizacje niosą ryzyko

Optymistyczny scenariusz dla Agave 4.2 zakłada, że Solana stanie się tańsza, szybsza i bardziej wydajna. Pesymistyczny scenariusz to taki, że Solana stanie się trudniejsza w prowadzeniu, zwiększając presję na centralizację walidatorów, jednocześnie wprowadzając trzy równoczesne zmiany w sieci przetwarzającej miliardy dolarów dziennie.

Obniżenie opłat stwarza ryzyko wzrostu stanu. Jeśli liczba kont na Solanie wzrośnie proporcjonalnie do redukcji kosztów, walidatory będą musiały przechowywać i przetwarzać 10 razy więcej danych stanu. Fundacja Solana nie opublikowała prognozy wzrostu stanu dla środowiska po SIMD-0437.

Skrócenie czasu slotu zwiększa wymagania sprzętowe w czasie, gdy koszty walidatorów Solany są już wyższe niż w większości konkurencyjnych sieci. Walidator działający na Solanie wymaga wysokiej klasy sprzętu z szybkim dyskiem NVMe, szybkim łączem sieciowym i dużą ilością pamięci RAM. Skrócenie czasu slotu o połowę nie podwaja kosztów sprzętu, ale zawęża margines błędu i może wypchnąć mniejszych walidatorów poniżej progu wydajności potrzebnego do uniknięcia kar za pomijanie.

Zwiększenie rozmiaru transakcji wprowadza nowy format, który indeksatory, portfele i SDK muszą obsługiwać. Chociaż migracja jest opcjonalna, fragmentacja ekosystemu między formatami transakcji v0, legacy i v1 tworzy dodatkową złożoność dla deweloperów i dostawców infrastruktury.

Czas również wprowadza ryzyko wykonania. Aktywowanie trzech głównych funkcji jednocześnie w sieci przetwarzającej miliardy dolarów dziennie oznacza, że jakiekolwiek efekty interakcji między aktualizacjami, scenariusz, którego testnet może nie w pełni odwzorować, mogą ujawnić się pod obciążeniem produkcyjnym. Stopniowe skracanie czasu slotu łagodzi największe pojedyncze ryzyko, ale obniżenie opłat i zwiększenie rozmiaru transakcji aktywują się bez równoważnych zabezpieczeń.

Istnieje również ryzyko konkurencyjne, o którym mówi się mniej. Jeśli Agave 4.2 odniesie sukces, potwierdzi tezę, że pojedynczy zespół może wdrażać duże zmiany infrastrukturalne szybciej niż zdecentralizowany proces zarządzania Ethereum. Ta teza przyciąga deweloperów w krótkim okresie. W długim okresie tworzy zależność od ciągłej kompetencji Anzy i zgodności z ekosystemem. Wolniejszy proces Ethereum rozkłada to ryzyko na szerszy zestaw uczestników. To, czy szybkość czy odporność ma większe znaczenie, zależy od horyzontu czasowego.

Co udowodniłoby błędność pesymistycznego scenariusza: pomyślna aktywacja wszystkich trzech funkcji bez wzrostu wskaźników pomijania, bez odejść walidatorów oraz mierzalny wzrost aktywności deweloperów i kont w sieci w ciągu 90 dni. Okno 90 dni ma znaczenie, ponieważ zmiany w infrastrukturze często pokazują swoje efekty stopniowo, a nie natychmiast.

Co oglądać

• Współczynnik pomijania po każdym zmniejszeniu czasu slotu. Zabezpieczenie w SIMD-0525 zatrzymuje postęp, jeśli współczynniki pomijania przekroczą próg. To, czy sieć przejdzie przez wszystkie cztery zmniejszenia, czy zatrzyma się na etapie pośrednim, wskaże rzeczywiste ograniczenia infrastruktury walidatorów Solany.
• Tempo tworzenia kont po obniżce czynszu. Gwałtowny wzrost liczby nowych kont potwierdzi tezę, że czynsz był znaczącą barierą dla rozwoju. Płaskie tworzenie kont sugerowałoby, że ograniczenie leżało gdzie indziej.
• Adopcja transakcji v1. To, jak szybko dostawcy portfeli, DEX-y i protokoły DeFi przyjmą większy format transakcji, zdecyduje, czy zwiększenie rozmiaru przełoży się na nowe możliwości, czy pozostanie niewykorzystane.
• Wyniki bug bounty Alpenglow. Program bug bounty o wartości 50 000 SOL zakończony przed wydaniem Agave 4.3 dostarczy publicznych ustaleń dotyczących bezpieczeństwa, które wskażą, czy październikowe przejście na nowy mechanizm konsensusu odbędzie się zgodnie z planem.
• Trajektoria udziału Firedancer. Różnorodność klientów jest warunkiem wstępnym dla profilu ryzyka tych aktualizacji. To, czy udział Firedancer wynoszący 14% wzrośnie do 33%, progu powszechnie uważanego za niezbędny dla znaczącej odporności, ma znaczenie dla bezpieczeństwa sieci podczas przejścia.

Często zadawane pytania