Deweloperzy Solany zaplanowali aktualizację konsensusu Alpenglow na 21 października, celując w finalizację transakcji w około 150 milisekund, jednocześnie prosząc walidatorów i operatorów aplikacji o przygotowanie się na zmiany podczas przejścia sieci głównej.
Podsumowanie
- Aktualizacja Alpenglow w Solanie jest zaplanowana na 21 października, celując w około 150-milisekundową finalizację transakcji.
- Quicknode ostrzega przed krótką przerwą w transakcjach i możliwymi przerwami w strumieniach danych podczas przejścia.
- Walidatorzy muszą używać kompatybilnego oprogramowania i zasilić konta głosowania na opłatę wstępu w wysokości 0,8 SOL.
- Niektóre węzły RPC mogą otrzymywać informacje o finalizacji później niż walidatorzy uczestniczący bezpośrednio w konsensusie.
Zawiadomienie o konserwacji Quicknode wskazuje środę jako planowany dzień aktywacji, ale jego najnowsza aktualizacja ostrzega, że pierwotny szacunek 14:50 UTC może przesunąć się na 13:20 UTC w miarę postępu produkcji bloków. Dostawca prosi operatorów o gotowość od 13:00 UTC, a przejście konsensusu nastąpi około 20 minut po aktywacji.
Obecna strona aktualizacji Fundacji Solana umieszcza zmianę w epoce 1064 i wymienia sieć główną jako jeszcze nieaktywowaną. Jej zaktualizowany szacunek umieszcza początek epoki około 13:20 UTC, czyniąc granicę epoki istotnym wyzwalaczem zamiast ustalonego terminu zegarowego.
Solana Alpenglow celuje w finalizację, nie szybsze wykonanie
Zgodnie z projektem Anza, Votor zastępuje logikę głosowania i finalizacji TowerBFT. Cel to około 150 milisekund w normalnych warunkach sieciowych, a nie gwarancja, że każdy portfel, giełda lub aplikacja handlowa wyświetli zakończoną transakcję w tym okresie.
Fundacja twierdzi, że wykonanie transakcji, zachowanie programów i mechanika opłat pozostają niezmienione. Zwykli użytkownicy nie muszą zmieniać sposobu podpisywania lub zatwierdzania transakcji, podczas gdy oddzielna aktualizacja dystrybucji danych Rotor jest zarezerwowana na późniejsze wydanie. Jej dokumentacja oddziela wdrożenie konsensusu od wcześniejszych redukcji czasu trwania slotu, które regulują, jak często sieć produkuje bloki.
Przegląd techniczny Quicknode opisuje dwie ścieżki głosowania działające jednocześnie. Jedna może sfinalizować blok w jednej rundzie, gdy uczestniczy 80% walidatorów, podczas gdy druga używa drugiej rundy, gdy uczestnictwo osiąga 60%.
Dostawca odróżnia ten proces od wczesnych potwierdzeń, które użytkownicy już widzą. Jego przegląd mówi, że aplikacje powszechnie wyświetlają potwierdzenia w ciągu dwóch do trzech sekund przy optymistycznych ustawieniach, zanim stary system osiągnie pełną finalizację po około 13 sekundach.
Październikowe wdrożenie następuje po wcześniejszym planie, który wiązał Alpenglow z Agave 4.3. Raport z 14 sierpnia dokumentował, że kod Alpenglow był obecny w Agave 4.2 do testów, bez autoryzacji aktywacji w sieci głównej w tym wydaniu.
Do 26 września aktualizacja dotarła do devnet po przejściu testnet poprzedniego dnia, jak wcześniej relacjonował crypto.news. Zespoły aplikacji mogły wtedy sprawdzić nowe zachowanie konsensusu przed wdrożeniem przeciwko sieci obsługującej fundusze użytkowników.
Traderzy napotkają krótką przerwę podczas przejścia
Quicknode ostrzega, że nowe transakcje na krótko przestaną wchodzić do bloków, podczas gdy sieć zmienia systemy konsensusu. Jego zawiadomienie opisuje pauzę trwającą kilka sekund, z możliwą dłuższą przerwą, jeśli przejście zajmie więcej czasu.
Zgłoszenia transakcji mogą tymczasowo zwracać błąd preflight „node unhealthy”, mówi dostawca. Strumienie danych Yellowstone mogą się raz rozłączyć, podczas gdy subskrypcje używające najwcześniejszego przetworzonego zobowiązania mogą wyświetlać sloty, które nigdy nie osiągną potwierdzenia.
Zawiadomienie o konserwacji zaleca potwierdzone lub sfinalizowane zobowiązanie dla danych, które nie mogą zostać wycofane. Quicknode mówi, że jego istniejące punkty końcowe Solana pozostaną na miejscu, a jego zespół będzie monitorował sieć przez cały czas zmiany.
W przeglądzie technicznym dostawcy szybsze nieodwracalne rozliczenie jest istotne dla aplikacji finansowych, transferów skarbowych przedsiębiorstw i usług w czasie rzeczywistym. Dokument przedstawia te zastosowania jako możliwości proponowanej architektury konsensusu, nie ustalając, że poszczególne platformy handlowe przyjmą nowe zasady rozliczeń w dniu aktywacji.
Gotowość walidatora obejmuje oprogramowanie i zasilenie konta
Obecna lista kontrolna Fundacji Solana instruuje walidatorów, aby przed epoką 1064 uruchamiali wersję 4.3.2 Agave, Jito-Solana lub Harmonic Salsa. Zgodnie z tymi samymi wytycznymi, Firedancer i Frankendancer nie są obsługiwane podczas migracji.
Operatorzy muszą utrzymywać co najmniej 0,8 SOL powyżej minimum zwolnionego z czynszu na swoich kontach głosujących, aby pokryć opłatę Validator Admission Ticket. Pierwsza opłata pokrywa udział w epoce 1065, a nieuiszczona opłata uniemożliwia walidatorowi głosowanie lub produkowanie bloków w tej następnej epoce.
Zatwierdzenie przez zarządzanie poprzedza te wymogi operacyjne. Propozycja została przyjęta we wrześniu 2025 r. przy 98,27% głosów popierających ją, zgodnie z relacją z zakończonego głosowania. Udział wyniósł 52% stawki, więc procent zatwierdzenia opisuje oddane głosy, a nie całą populację walidatorów.
To wcześniejsze głosowanie zatwierdziło SIMD-0326, propozycję stojącą za przebudową konsensusu. Współczesny raport odnotował 1,05% przeciw i 0,69% wstrzymujących się, przy czym niewielka różnica zaokrągleń została zachowana w opublikowanych liczbach.
Dostarczanie RPC może pozostawać w tyle za celem 150 ms
Dokumentacja operatora Anza wyjaśnia, że komunikaty konsensusu zwykle krążą wśród dopuszczonych walidatorów. Węzeł bez stawki korzystający z domyślnej ścieżki dostarczania dowiaduje się o finalności z certyfikatów przenoszonych w późniejszych blokach, co zazwyczaj dodaje do jednego interwału wyprodukowanego bloku.
Pominięte lub opóźnione bloki mogą wydłużyć to oczekiwanie. Węzeł współpracujący z dopuszczonym walidatorem może otrzymywać komunikaty bezpośrednio, choć opóźnienie sieci między nimi pozostaje częścią czasu dostarczania.
Wrześniowa relacja z devnetu udokumentowała odrębne zmiany dla indekserów i eksploratorów. Bloki kandydujące muszą pozostać oddzielone do potwierdzenia, a dane o udziale walidatorów odchodzą od zwykłych transakcji głosowania w kierunku certyfikatów dołączonych do danych bloku.
Zgodnie z tym raportem, usunięcie transakcji głosowania zmienia sumy na pulpitach nawigacyjnych, nawet gdy liczba płatności i transakcji użytkowników pozostaje stała. Usługi liczące obie kategorie muszą zresetować swoje porównania, podczas gdy systemy śledzące głosy walidatorów muszą odczytywać zastępcze dane certyfikatów.
