Solana skróciła docelowy czas slotu z 300 milisekund do 250 milisekund, zwiększając tempo, w jakim sieć produkuje sloty, o prawie 17%, nie podnosząc jednocześnie swojego ogólnego limitu przetwarzania o tę samą wartość.
Podsumowanie
- Solana zmniejszyła docelowy czas slotu z 300 ms do 250 ms, doprowadzając sieć do czterech docelowych slotów na sekundę.
- Szybszy zegar skraca czteroslotowe okno lidera każdego walidatora z 1,2 sekundy do jednej sekundy.
- Ogólna przepustowość przetwarzania pozostaje w przybliżeniu niezmieniona, ponieważ limity obliczeń i danych spadają wraz ze skracaniem czasu trwania slotu.
- Ustawienie 250 ms skraca oczekiwaną epokę Solany z około 36 godzin do 30 godzin.
- Ostateczna redukcja do 200 ms doprowadziłaby Solanę do pięciu slotów na sekundę, ale nie ustalono daty dla mainnetu.
Zgodnie z danymi blockchain, nowe ustawienie weszło w życie 18 września i doprowadza Solanę do czterech docelowych slotów na sekundę, w porównaniu z około 3,3 w poprzedniej konfiguracji 300 ms. Zmiana ta jest trzecim etapem SIMD-0525, który ma na celu stopniowe zmniejszanie czasów slotów od pierwotnego ustawienia sieci wynoszącego 400 ms do ostatecznego celu 200 ms.
Slot to okres, w którym wyznaczony walidator może wyprodukować blok. Skrócenie tego okresu daje portfelom, giełdom i aplikacjom handlowym częstsze aktualizacje stanu sieci.
Walidatorzy nadal pełnią rolę liderów przez cztery kolejne sloty. Ponieważ każdy slot jest teraz docelowo ustawiony na 250 ms, nominalne okno lidera walidatora spadło z 1,2 sekundy przy poprzednim ustawieniu do jednej sekundy.
Czas slotu Solany osiąga 250 ms
Solana rozpoczęła obecne wdrażanie w sierpniu, kiedy to skróciła czas slotu z 400 ms do 350 ms po raz pierwszy od uruchomienia sieci, jak wcześniej informował crypto.news.
SIMD-0525 podzielił proces na cztery etapy: 350 ms, 300 ms, 250 ms i 200 ms, zamiast przechodzić bezpośrednio do celu końcowego. Każda redukcja wymaga osobnej aktywacji funkcji, co pozwala deweloperom i operatorom walidatorów ocenić wydajność sieci przed kontynuowaniem.
Przy 250 ms cztery okazje na slot pojawiają się każdej sekundy. Krótsze interwały mogą dać aplikacjom bardziej aktualny obraz transakcji i stanu sieci, jednocześnie przekazując produkcję bloków od jednego walidatora do drugiego szybciej.
Rynki oparte na oracle'ach i automatyczni animatorzy rynku należą do aplikacji objętych propozycją, ponieważ ich działanie może zależeć od wieku danych onchain. Krótszy interwał zmniejsza ilość czasu między aktualizacjami sieci, a użytkownicy mogą szybciej zobaczyć zmiany statusu transakcji.
W przypadku swapów krótsze czasy mogą zawęzić okres między złożeniem transakcji a dotarciem do sieci. Bazowa propozycja wskazuje szybsze potwierdzenia i częstsze aktualizacje jako korzyści wynikające ze skrócenia czasu trwania slotu.
Zmiana ta nie zwiększa surowej przepustowości transakcyjnej Solany o prawie 17%.
W ramach SIMD-0525 limity zasobów są redukowane proporcjonalnie do czasu trwania slotu. W danym okresie produkowanych jest więcej slotów, ale każdy slot może przenosić mniej obliczeń i danych, utrzymując ilość pracy, którą sieć może przetworzyć w czasie rzeczywistym, na w przybliżeniu tym samym poziomie.
Przy bazowej wartości 60 milionów jednostek obliczeniowych stosowanej w propozycji, limit na slot spada wraz z przyspieszaniem zegara. Konfiguracja 250 ms odpowiada limitowi 37,5 miliona jednostek obliczeniowych, podczas gdy planowany etap 200 ms obniżyłby go do 30 milionów.
Szybsze bloki zmieniają wymagania infrastrukturalne Solany
Dostawcy infrastruktury mają teraz więcej pojedynczych bloków do przetworzenia i przechowywania, mimo że limit przetwarzania w czasie rzeczywistym pozostaje zasadniczo niezmieniony.
Aplikacje, które obliczają upływ czasu, mnożąc numery slotów przez stały czas trwania slotu, mogą potrzebować uwzględnienia szybszego zegara. Blockhashe wygasają szybciej w czasie rzeczywistym, ponieważ sloty postępują szybciej, pozostawiając mniej czasu na procesy transakcyjne obejmujące podpisywanie offline lub opóźnione zatwierdzenia przez ludzi.
Czas trwania epoki zmienia się z tego samego powodu. Solana utrzymuje każdą epokę na stałym poziomie 432 000 slotów, co oznacza, że epoka staje się krótsza wraz ze spadkiem czasu trwania każdego slotu.
Przy wcześniejszym celu 300 ms epoka trwała około 36 godzin. Ustawienie 250 ms skraca oczekiwany czas trwania do około 30 godzin. Przejście do ostatecznego celu 200 ms skróciłoby go do około 24 godzin.
Etapowe redukcje slotów Solany stanowią część wdrożenia Agave 4.2. Wydanie klienta rozpoczęło aktywację kilku zmian sieciowych w sierpniu, w tym niższego czynszu za przechowywanie danych onchain, większych transakcji oraz drogi do slotów 200 ms.
Etapowy projekt obejmuje zabezpieczenie powiązane ze wskaźnikami pominięć bloków. Postęp w kierunku kolejnego ustawienia slotów może zostać zatrzymany, jeśli wskaźniki pominięć wzrosną powyżej poziomu uznawanego przez deweloperów za akceptowalny, dając walidatorom czas na działanie w ramach każdej konfiguracji przed aktywacją kolejnej redukcji.
Nie ustalono daty mainnetu dla etapu 200 ms.
Ulepszenia Solany wykraczają poza szybsze sloty
Czas slotów to tylko jedna część zmian sieciowych wdrażanych przez Agave.
Solana osobno wprowadziła Transaction V1, która zwiększa maksymalny rozmiar serializowanej transakcji z 1232 bajtów do 4096 bajtów. Większy format transakcji może pomieścić operacje wymagające dużych ilości danych, takie jak dowody wiedzy zerowej i złożone instrukcje wielopodpisowe w ramach jednej transakcji.
Transaction V1 jest opcjonalna, a transakcje w formacie legacy i version zero pozostają obsługiwane. Aplikacje odczytujące bloki muszą obsługiwać nowszy format, aby prawidłowo przetwarzać transakcje V1.
Zwiększenie rozmiaru transakcji jest oddzielne od SIMD-0525. Większe pojedyncze transakcje nie determinują zatem zegara slotów, a krótsze sloty nie zwiększają automatycznie maksymalnego rozmiaru transakcji.
Solana aktywowała zmiany niezależnie poprzez bramki funkcji. Struktura ta pozwala jednemu ulepszeniu postępować bez konieczności jednoczesnej aktywacji innych funkcji zawartych w Agave 4.2.
Solana nadal celuje w sloty 200 ms
Ostatni etap w ramach SIMD-0525 zmniejszyłby docelowy czas slotu z 250 ms do 200 ms, doprowadzając sieć do pięciu docelowych slotów na sekundę.
Czteroslotowe okno lidera walidatora spadłoby w konsekwencji do około 800 ms. Czas trwania epoki zmniejszyłby się z około 30 godzin przy obecnym ustawieniu 250 ms do około 24 godzin.
Deweloperzy Solany nie podali daty aktywacji w mainnecie dla ostatecznej redukcji. Postęp zależy od zachowania sieci przy obecnym ustawieniu, w tym od tego, czy walidatorzy mogą utrzymać akceptowalne wskaźniki pominięć bloków.
Redukcje slotów są oddzielne od Alpenglow, planowanego przeprojektowania konsensusu Solany. Alpenglow ma zastąpić TowerBFT systemem głosowania o nazwie Votor i usunąć transakcje głosowania onchain z podstawowego procesu konsensusu sieci.
Ulepszenie konsensusu Alpenglow celuje w finalność około 150 ms. Jego kod został dołączony do testów, a wdrożenie w mainnecie zostało powiązane z Agave 4.3, a nie z bramkami funkcji czasu slotów używanymi dla SIMD-0525.
Alpenglow wszedł do testów społeczności walidatorów wcześniej w 2026 roku, umożliwiając operatorom uruchomienie projektu konsensusu w klastrze testowym przed wdrożeniem w mainnecie. Anza opisała ten system jako największą zmianę konsensusu w historii Solany.
W przypadku SIMD-0525 sieć pozostaje na etapie 250 ms, dopóki deweloperzy nie aktywują ostatecznej bramki funkcji. Konfiguracja 200 ms zakończyłaby wdrożenie, które rozpoczęło się od 400 ms i przechodziło przez 350 ms, 300 ms i 250 ms, zmniejszając limity zasobów na każdym etapie.
