Solana przeniosła swoją sieć deweloperską na Alpenglow — istotną aktualizację konsensusu zaprojektowaną tak, aby znacząco skrócić czas osiągania finalności transakcji i zmienić sposób koordynacji walidatorów w całym łańcuchu bloków. Migracja została zakończona 25 września, a aktywacja — znana jako Alpenswitch — weszła w życie w epoce 1167 po 17-minutowym odliczaniu. Przejście przeprowadzili inżynierowie z Anzy, firmy rozwijającej podstawowe oprogramowanie sieci Solana, a współzałożyciel Solany Anatoly Yakovenko odnotował to wydarzenie w krótkim wpisie w mediach społecznościowych wkrótce po migracji.

Alpenglow ma skrócić finalność transakcji w Solanie z około 12,8 sekundy do przedziału 100–150 milisekund, co może umożliwić niemal natychmiastowe potwierdzenia dla aplikacji zależnych od szybkiego rozliczania. Finalność to moment, w którym transakcja jest uznawana za trwale rozliczoną i nie może zostać cofnięta, co czyni ją jednym z kluczowych wskaźników responsywności blockchaina w praktyce; przeniesienie tej gwarancji z kilku sekund do ułamka sekundy zbliża potwierdzenia do błyskawiczności, jakiej użytkownicy oczekują od klasycznych aplikacji internetowych.

Aktualizacja jest teraz testowana na devnecie Solany, po tym jak protokół został już wdrożony na testnecie. Uruchomienie now systemu konsensusu w obu publicznych środowiskach testowych daje deweloperom i operatorom sieci możliwość zbadania jego wydajności i stabilności, zanim zapadnie decyzja o wdrożeniu w sieci mainnet-beta — środowisku produkcyjnym, w którym transakcje mają rzeczywistą wartość.

Votor zastępuje TowerBFT

Rdzeniem zmiany jest zastąpienie wieloletniego mechanizmu konsensusu TowerBFT, który zabezpieczał sieć od uruchomienia mainnetu w 2020 roku, systemem Votor — nowym mechanizmem głosowania opracowanym przez inżynierów Anzy we współpracy z badaczami z ETH Zürich. Walidatorzy zatwierdzili zmianę na podstawie dokumentu Solana Improvement Document SIMD-0326, formalnego mechanizmu sieci do ratyfikowania zmian protokołu.

Votor zmienia sposób wymiany informacji o głosowaniu między walidatorami. Zamiast zapisywać poszczególne głosy techniczne jako transakcje wewnątrz bloków, walidatorzy komunikują je bezpośrednio, a informacje mogą być następnie konsolidowane w kryptograficzne certyfikaty BLS — zagregowane podpisy, które kondensują wiele głosów w jeden zwarty dowód.

Zmiana ma na celu zmniejszenie udziału pojemności bloków zużywanej przez aktywność związaną z konsensusem. Transakcje głosowania technicznego zajmowały wcześniej znaczną część przestrzeni blokowej Solany, a według niektórych szacunków nawet 75%. Przenosząc tę aktywność poza strumień transakcji i agregując ją w kompaktowe certyfikaty, Alpenglow ma uwolnić dodatkową pojemność sieci dla transakcji użytkowników, a przy tym potencjalnie obniżyć koszty operacyjne walidatorów.

Co istotne, aktualizacja nie wymaga fundamentalnego przeprojektowania maszyny wirtualnej ani architektury inteligentnych kontraktów Solany. Aplikacje zbudowane na istniejącej Solana Virtual Machine mogą działać dalej, podczas gdy zmienia się leżący u podstaw mechanizm konsensusu.

Finalność poniżej sekundy jako cel

Głównym celem wydajnościowym Alpenglow jest znaczne skrócenie czasu potrzebnego do osiągnięcia finalności transakcji. W nowym systemie finalność ma następować w około 100 milisekund, gdy walidatorzy reprezentujący co najmniej 80% stawki sieci zareagują w wymaganym oknie czasowym. Mechanizm awaryjny ma zapewniać finalność w około 150 milisekund, gdy wyższy próg nie zostanie natychmiast osiągnięty.

Przejście na finalność poniżej sekundy może okazać się szczególnie istotne dla aplikacji płatniczych, systemów tradingowych oraz gier Web3, gdzie opóźnienia w potwierdzaniu transakcji bezpośrednio wpływają na doświadczenie użytkownika.

Protokół zawiera również model tolerancji błędów 20+20. W tej strukturze sieć ma pozostawać stabilna, jeśli 20% walidatorów stanie się niedostępnych, a jednocześnie kolejne 20% obiektem ataków lub innych zakłóceń.

Deweloperzy rozpoczynają testy w praktyce

Wdrożenie na devnecie daje twórcom aplikacji środowisko o niskim ryzyku do testowania oprogramowania względem nowych reguł konsensusu. Tokeny na devnecie nie mają rzeczywistej wartości pieniężnej, co pozwala zespołom badać zachowanie transakcji bez narażania użytkowników na ryzyko finansowe związane z aktywnością na mainnecie. Aplikacje płatnicze mogą wykorzystać to środowisko do oceny szybszych potwierdzeń, a gry blockchainowe — do sprawdzenia, czy niższe opóźnienia rozliczeń poprawiają doświadczenia interaktywne.

Nie każda aplikacja będzie wymagać zmian. Podstawowe oprogramowanie wysyłające transakcje lub odczytujące salda kont może działać dalej bez większych modyfikacji. Jednak platformy analityczne i usługi zliczające transakcje blockchainowe mogą potrzebować dostosowania swoich metod, ponieważ głosy walidatorów nie będą już występować jako pojedyncze transakcje w blokach.

Alpenglow is live on devnet >
— Solana (@solana) September 25, 2026

Usługi danych będą także musiały uwzględniać konkurujące bloki kandydujące, dopóki sieć nie osiągnie ostatecznej zgody; przedwczesne łączenie informacji z konkurencyjnych bloków mogłoby stworzyć nieprecyzyjne zapisy historyczne.

Termin wdrożenia na mainnecie pozostaje niepewny

Alpenglow działa już na devnecie i testnecie Solany, ale nie ogłoszono konkretnej daty wdrożenia na mainnecie-beta. Testy stabilności trwają, a przytoczone parametry wydajności są celami opartymi na testach protokołu i symulacjach, a nie potwierdzonymi wynikami w pełnych warunkach rynkowych. Rzeczywiste doświadczenie użytkownika może zależeć także od obsługi portfeli, procedur wpłat na giełdach i innej infrastruktury poza warstwą konsensusu.

Faza publicznych testów daje deweloperom Solany i dostawcom infrastruktury możliwość sprawdzenia, czy celowana szybkość i odporność Alpenglow przełożą się na niezawodną wydajność, zanim protokół zostanie rozważony do wdrożenia na mainnecie. Migracja stanowi więc istotny test techniczny dla Solany, a nie zakończoną aktualizację całej sieci, a wyniki z devnetu i testnetu dostarczą ważnych dowodów na to, jak nowa architektura konsensusu radzi sobie przy większych obciążeniach — i czy sieć może zbliżyć do celowanej finalności poniżej sekundy na żywej infrastrukturze. Wskaźnikami wartymi obserwacji są utrzymanie docelowych parametrów finalności na devnecie i testnecie wraz ze wzrostem obciążeń testowych oraz to, czy kolejny krok zarządczy wyznaczy konkretny harmonogram aktywacji na mainnecie-beta.