Solana obiecywał szybszą finalność. Teraz walidatorzy muszą to udowodnić

Alpenglow działa w sieciach testowych Solany, podczas gdy mainnet nadal opiera się na istniejącym konsensusie. Proponowana zmiana zmieniłaby sposób, w jaki walidatorzy zgadzają się, że blok jest ostateczny. Cel 150 milisekund to twierdzenie o wydajności w określonych warunkach, a nie obietnica, że każda płatność użytkownika zostanie rozliczona w tym czasie.

Najważniejsza zmiana konsensusu Solany przechodzi przez sekwencję testów walidatorów. Tracker bram funkcji Anza wymienia SIMD-0326, Alpenglow, wśród oczekujących aktywacji w mainnecie. Rejestruje pozycje aktywacji w testnecie i devnecie oraz wskazuje Agave 4.3.0 jako wersję oprogramowania powiązaną z tą funkcją. Minimalna wersja mainnetu pokazana w tym samym zrzucie wynosiła 4.2.2, a 4.3.0 wymieniono jako następną oczekiwaną wersję minimalną. Planowana wersja minimalna i aktywna funkcja konsensusu to różne kamienie milowe.

Wcześniejszy raport z testnetu opisywał przejście do szerszych testów walidatorów. Późniejsza relacja z devnetu odnotowała obie sieci testowe, podczas gdy mainnet kontynuował działanie z obecnym konsensusem. To jest status, względem którego należy oceniać wszelkie obiecywane przyspieszenie.

28 września był pułapką kalendarzową

Jeden wpis w harmonogramie mówił, że aktywacje funkcji w mainnecie zostaną wznowione 28 września. Nie mówił, że sam Alpenglow zostanie włączony tego dnia. Tracker osobno wymienia Alpenglow jako oczekujący. Potraktowanie daty wznowienia kolejki bram funkcji jako zaplanowanego przełączenia protokołu zamieniło znacznik procesu w fałszywy termin. Korekta z 29 września prześledziła to zamieszanie i stwierdziła, że Anza odrzuciła rzekomą datę uruchomienia.

Rozróżnienie to jest istotne. Walidatorzy mogą przyjąć wydanie oprogramowania zawierające uśpiony kod bez aktywowania funkcji. Minimalna wersja może wzrosnąć po przekroczeniu progu stawki i upływie epok. Oddzielna brama funkcji może włączyć nowe zachowanie. Użytkownicy, którzy widzą zmianę numeru wersji na pulpicie, nie widzą przez to, że szybszy protokół finalności został uruchomiony.

Właściwym punktem zaczepienia wiadomości jest to, że proces testowania i aktywacji jest nadal otwarty po szeroko rozpowszechnionej dacie. Ostateczne okno mainnetu wymaga wyraźnego harmonogramu, przygotowania operatorów i dowodów z publicznych testów. Żaden z tych kroków nie jest zastępowany przez post w mediach społecznościowych opisujący aktualizację jako nieuchronną.

Votor zmienia głosy, podczas gdy Rotor czeka

Propozycja SIMD-0326 definiuje początkowy ruch głównie wokół Votor, nowego mechanizmu konsensusu. Wyraźnie pozostawia Rotor, proponowany zamiennik rozpowszechniania danych, na osobną zmianę i początkowo zachowuje istniejącą propagację Turbine. Opisy marketingowe kompletnego stosu Alpenglow mogą zacierać ten zakres.

Konsensus odpowiada, kiedy wystarczająca liczba walidatorów zgodziła się co do bloku, że należy go traktować jako ostateczny w ramach protokołu. Propagacja danych odpowiada, jak blok dociera do tych walidatorów. Wykonanie odpowiada, czy transakcja została pomyślnie przeprowadzona. Aplikacja czeka również, aż jej dostawca RPC zgłosi wynik. Szybsze głosowanie nie może wyeliminować wszystkich innych opóźnień na tej ścieżce.

Wartość 150 milisekund najlepiej odczytywać jako cel finalności w sprzyjających warunkach sieciowych, mierzony na warstwie konsensusu. Nie jest to czas realizacji transakcji od początku do końca dla użytkownika, którego portfel musi podpisać, przesłać, dotrzeć do lidera, zostać uwzględniony w bloku, wykonać i zwrócić przez usługę RPC. Użyteczny publiczny benchmark powinien określać swoje punkty początkowy i końcowy. Stoper uruchomiony przy propozycji bloku nie jest porównywalny z tym uruchomionym, gdy klient naciska Wyślij.

Propozycja zastępuje układ głosowania innym kompromisem między bezpieczeństwem a żywotnością. Opisuje model 20 plus 20, który może tolerować wrogi udział i oddzielny nieodpowiadający udział przy określonych założeniach. Autorzy wyraźnie zauważają, że jednorundowe głosowanie nie zapewnia tego samego progu bizantyjskiego 33%, osiągalnego dzięki projektom dwurundowym. To przyznanie należy umieścić obok twierdzenia o szybkości, a nie w przypisie.

Test dwukolumnowy zapobiega mylącemu benchmarkowi

Jedna kolumna powinna mierzyć finalność protokołu z punktu widzenia walidatora: czas, jaki upływa od zaproponowanego bloku do certyfikatu finalizacji, wraz z rozkładem wolnych wyników. Druga powinna mierzyć potwierdzoną transakcję użytkownika: przesłanie przez wykonanie, włączenie, finalność i odpowiedź RPC. Różnica między tymi kolumnami to praca, której nagłówek konsensusu nie mierzy.

Załóżmy, że test zgłasza 150 milisekund na finalizację po propozycji, ale włączenie transakcji czeka jeden slot 350 milisekund, a dostarczenie przez RPC zajmuje kolejne 100 milisekund. Klient widzi co najmniej 600 milisekund przy tych ilustracyjnych założeniach, przed dodaniem podpisywania lub ponownych prób. Obliczenie to 350 plus 150 plus 100. Są to hipotetyczne czasy, a nie pomiary Alpenglow w środowisku produkcyjnym. Pokazują, dlaczego liczba konsensusu poniżej sekundy nie musi być tym samym co doświadczenie płatności poniżej sekundy.

Mediana opóźnienia może ukryć przypadki, na których operatorom zależy najbardziej. Walidator utknięty za słabą trasą sieciową, tymczasową partycją, brakującym głosem lub ciężką pracą odtwarzania może doświadczyć długiego ogona. Giełdy i dostawcy płatności zazwyczaj budują polityki finalności dla rzadkich złych warunków, a nie tylko dla mediany benchmarku. Wiarygodne wdrożenie publikowałoby wyniki percentylowe, zachowanie przy odzyskiwaniu i konsekwencje nieudanych liderów.

Propozycja czasu slotu to kolejna zmienna. Dąży do etapowych redukcji z celu 400 milisekund w kierunku 200 milisekund. Interwał slotu i finalność są powiązane, ale odrębne; twierdzenie, że każdy krótszy slot dowodzi działania Votor, myli dwie aktualizacje. Wcześniejsze konto testowe walidatora śledziło testowanie protokołu przed tym szerszym wdrożeniem.

Walidatorzy muszą testować przypadki awarii

Ścieżka szczęśliwa sieci to najłatwiejsze środowisko do wygenerowania szybkiej liczby. Kandydat do mainnetu musi przetrwać walidatorów dołączających późno, opóźnione wiadomości między regionami, restarty oprogramowania, awarie liderów i sprzeczne widoki łańcucha. Propozycja migracji Alpenglow dotyczy przekazania ze starego stanu głosowania do nowego. Poprawny protokół w stanie ustalonym może jednak zostać ujawniony przez słabe przejście.

Testy powinny pokazać, czy klaster osiąga jedną spójną ostateczną decyzję po zagojeniu się partycji, jak szybko wznawia działanie, jeśli znaczący udział stawki przejdzie offline, oraz czy węzły z różnymi zgodnymi wersjami zgłaszają ten sam wynik. Testnet jest cenny, ponieważ walidatorzy z różną infrastrukturą napotykają warunki, które kontrolowane laboratorium może przeoczyć. Nie może dokładnie odtworzyć zachęt ekonomicznych i ruchu sieci na żywo.

Miks klientów ma znaczenie. Tracker Anzy oznaczył Firedancer i Frankendancer jako nieobsługiwane dla wiersza Alpenglow w zaobserwowanym zrzucie. To status zgodności w konkretnym harmonogramie, a nie trwałe twierdzenie o którymkolwiek z klientów. Migracja produkcyjna musi uwzględniać stawkę uruchamiającą każdą implementację lub określić, co ci operatorzy muszą zmienić.

Zachęty walidatorów są również częścią testu. Uruchomienie nowego protokołu głosowania może zmienić przepustowość, wymagania sprzętowe i koszty uczestnictwa. Jeśli mniejsi operatorzy wypadną, ponieważ nie mogą spełnić wymagań, szybsza sieć może skończyć z mniejszą liczbą niezależnych uczestników. Rzeczywiste liczby operatorów i rozkład stawki po aktywacji testowałyby ten kompromis.

Szybki certyfikat i wolny certyfikat obsługują różne warunki

Protokół nie zależy od tego, że jedna ścieżka zawsze kończy się w 150 milisekund. SIMD-0326 definiuje szybką finalizację, gdy walidatorzy reprezentujący 80% stawki notaryzują blok w jednej rundzie. Jego wolniejsza ścieżka opiera się na dwóch rundach obejmujących 60% stawki oraz certyfikatach notaryzacji i finalizacji. Lider może nie dostarczyć ważnego bloku na czas, w którym to przypadku walidatorzy mogą zagłosować za pominięciem tego slotu. Projekt obejmuje certyfikaty dla pominiętych slotów oraz ścieżkę awaryjną. Nagłówkowy benchmark, który mierzy tylko szybką ścieżkę 80%, pominąłby dokładnie te sytuacje, które czynią finalizację wartościową.

Tę różnicę można poddać praktycznemu testowi. Dla każdego proponowanego slotu w ciągu dnia należy policzyć udział sfinalizowany szybkim certyfikatem, udział wykorzystujący wolniejszą ścieżkę oraz udział pominięty. Podaj medianę oraz 95. i 99. percentyl osobno dla każdej klasy. Szybka mediana jest użyteczna, ale operator musi wiedzieć, jak często sieć opuszcza szybką ścieżkę i jak długo trwa potem powrót do niej. Usługa płatnicza obsługująca tysiące paragonów dziennie może doświadczyć zdarzenia z długiego ogona, nawet jeśli takie zdarzenie jest rzadkie dla pojedynczego przelewu.

Certyfikat to zwięzły, weryfikowalny zapis porozumienia ważonego stawką. Nie jest to głosowanie przez stałą liczbę maszyn. Dziesięciu małych walidatorów nie może zastąpić jednego walidatora reprezentującego dużą ilość stawki jedynie poprzez przewagę liczebną. Raportowanie liczby walidatorów bez rozkładu stawki zafałszowałoby zatem test bezpieczeństwa. Prawidłowe liczby to stawka uczestnicząca w każdej rundzie, stawka offline oraz stawka, która się nie zgadza. Te liczby wymagają znaczników czasu, ponieważ przypisania stawki i dostępność operatorów zmieniają się.

Propozycja mówi, że bezpośrednio sfinalizowany blok rozstrzyga także o swoich przodkach: wcześniejsze bloki w jego łańcuchu stają się sfinalizowane, a pominięte sloty są traktowane jako pominięte. Oznacza to, że pulpit nawigacyjny może pokazywać finalizację przychodzącą w grupach po wolnym okresie. Pomiar, który uśredniałby pozorne czasy ukończenia tych przodków w jedną atrakcyjną liczbę, byłby trudny do porównania z użytkownikiem, który czekał przez pauzę. Test powinien zachować pierwotny czas propozycji każdego bloku oraz czas obserwacji certyfikatu.

Autorzy protokołu nie twierdzą, że mają ten sam próg przeciwnika co każdy konkurencyjny projekt. Ich ramy 20 plus 20 akceptują inną równowagę między wadami bizantyjskimi a niereagującą stawką w zamian za krótszą normalną ścieżkę. To, czy ten kompromis jest akceptowalny, jest osądem governance opartym na modelowaniu zagrożeń i dowodach wydajności, a nie kwestią rozstrzygniętą przez pojedynczą demonstrację najszybszego przypadku. Niezwykle szczera sekcja bezpieczeństwa w SIMD-0326 umożliwia raportowanie tego kompromisu bez przypisywania motywów którejkolwiek ze stron.

Przełączanie konsensusu wymaga wspólnego bloku początkowego

Dokument migracyjny porusza problem, którego wykres szybkości nie może pokazać. Stary i nowy konsensus nie mogą bezpiecznie działać jako niezależne historie po przełączeniu. Walidatorzy muszą uzgodnić ostatni stary blok, który staje się rodzicem pierwszego bloku Alpenglow. Dokument nazywa ten wspólny punkt blokiem genezy Alpenglow. Jeśli operatorzy nie zgadzają się co do niego, ich późniejsze certyfikaty finalizacji odnosiłyby się do niekompatybilnych historii.

Proponowane przekazanie rozpoczyna się po slocie aktywacji funkcji, ale granica używana do migracji znajduje się 5000 slotów później. Dodatkowy interwał ma na celu uniknięcie początku epoki. Proces następnie czeka na blok spełniający silny warunek optymistycznego potwierdzenia, z głosami reprezentującymi co najmniej 82% stawki w wzorcu określonym w propozycji. Walidatorzy podpisują głos genezy dla wspólnego bloku przodka. Certyfikat genezy 82% daje im dowód do przełączenia. Arytmetyka tych progów jest częścią projektu migracji, oddzieloną od szybkiej ścieżki finalizacji Votora na poziomie 80% po przełączeniu.

Walidator otrzymujący certyfikat genezy weryfikuje jego podpisy względem kluczy BLS odpowiedniej epoki i rozgłasza go. Plan następnie inicjalizuje Votora z wybranego bloku i zatrzymuje TowerBFT dla późniejszych slotów. Wycofuje bloki po wybranym punkcie genezy i resetuje powiązany stan przed przetwarzaniem nowych bloków. Dokument argumentuje, że to wycofanie jest bezpieczne, ponieważ transakcje użytkowników nie są pakowane do tych tymczasowych bloków. To twierdzenie zasługuje na test na rzeczywistym klastrze; nie jest to coś, co operator aplikacji może zweryfikować wyłącznie na podstawie nagłówka o finalizacji.

Węzeł może być offline podczas przekazania. Dokument opisuje, jak powracający walidator może poznać certyfikat genezy ze snapshotu lub nadrobić zaległości po zaobserwowaniu ważnego certyfikatu finalizacji Alpenglow. To tutaj inżynieria wydania spotyka teorię konsensusu. Jeśli spóźniony węzeł zinterpretuje przejście nieprawidłowo, może prezentować nieaktualne lub niespójne dane, nawet gdy klaster większościowy kontynuuje pracę. Giełdy i dostawcy RPC powinni przećwiczyć scenariusze restartu i przywracania snapshotów, a nie tylko obserwować, czy początkowe przełączenie się powiedzie.

Istnieje wyraźny koszt żywotności. Propozycja migracji mówi, że przekazanie może przerwać postęp, optymistycznie na jeden slot poza granicą. Oczekiwanie jednego slotu nie jest maksymalną gwarancją poziomu usług. Publiczny postmortem po aktywacji powinien stwierdzić, ile slotów zostało pominiętych, czy pakowanie transakcji użytkowników zostało wstrzymane i jak długo zewnętrzne usługi potrzebowały na wznowienie normalnego raportowania potwierdzeń. Szybki stan ustalony nie może sprawić, że interwał przejściowy zniknie z doświadczenia użytkowników.

Dlatego daty mainnetu nie można wywnioskować z ogólnego kalendarza oprogramowania. Bezpieczne przełączenie wymaga kompatybilnej rejestracji kluczy BLS, przyjętej bramki funkcji, wspólnego bloku początkowego, dystrybucji certyfikatów, zachowania rollbacku i odzyskiwania dla opóźnionych węzłów. To są obserwowalne zadania dla operatorów. Specyfikacja migracji daje im listę kontrolną, podczas gdy rzeczywiste ćwiczenie sieciowe pokaże, czy lista kontrolna jest wystarczająca.

Koszty walidatorów mogą zmienić, kto uczestniczy

Ulepszenie ma projekt ekonomiczny, a także cel opóźnienia. W obecnym głosowaniu operatorzy wysyłają transakcje głosowania i płacą związane z nimi opłaty. SIMD-0326 proponuje bilet wstępu walidatora, czyli VAT, pobierany zamiast tego wzorca opłat. Dokument podaje wstępny szacunek około 0,8 SOL dziennie, czyli 1,6 SOL na epokę, i mówi, że cała płatność zostałaby spalona. Liczba ta jest początkowym parametrem w propozycji, a nie aktywnym wyciągiem rozliczeniowym dla każdego walidatora.

Stały koszt wstępu może uprościć jeden wydatek, jednocześnie ciążyć bardziej na małym operatorze z niewielkim delegowanym stake. Duży walidator i mały nie zarabiają tych samych nagród. Pytanie brzmi, czy ich ekonomia netto poprawia się po uwzględnieniu zaoszczędzonych opłat za głosowanie, kosztów sprzętu, przepustowości i VAT. Propozycja mówi, że operatorzy powinni zauważyć niższe zużycie zasobów po migracji. To oczekiwany efekt, a nie zmierzony wynik w całym aktywnym zestawie walidatorów.

Przydatne porównanie przed i po śledziłoby tych samych operatorów przez ulepszenie. Dla każdego przedziału stake porównaj dzienne opłaty za głosowanie przed zmianą z VAT i kosztami operacyjnymi po niej. Policz udział niezależnych operatorów, którzy przestają produkować głosy lub opuszczają aktywny zestaw. Spadek liczby maszyn sam w sobie nie dowodziłby utraty decentralizacji, gdyby odchodzący walidatorzy mieli znikomy stake, ale byłby ostrzeżeniem do zbadania. Koncentracja stake i różnorodność geograficzna dodałyby niezbędnego kontekstu.

Propozycja mówi, że niewystarczająco finansowany walidator zostałby usunięty z aktywnego zestawu. To czyni zarządzanie saldem biletów kwestią czasu działania. Operatorzy potrzebują alertów, zanim skończą się środki, a delegujący muszą zrozumieć, co się stanie, jeśli ich wybrany walidator stanie się nieaktywny. Różnica między protokołem konsensusu, który działa w laboratorium, a siecią, która działa dzień po dniu, obejmuje przyziemne finansowanie kont. wcześniejszy raport o zarządzaniu walidatorami Solany opisuje formalną ścieżkę decyzyjną; dalszy udział po wdrożeniu jest osobnym testem.

Pytanie produkcyjne nie brzmi po prostu, czy 150 milisekund jest osiągalne. Brzmi, czy wystarczająco szeroki zestaw walidatorów może dostarczyć tę wydajność bez niezgłoszonego wzrostu kosztów lub kruchości operacyjnej. Szybsza finalność z węższą bazą operatorów byłaby innym wynikiem niż pełna obietnica propozycji. Zarówno opóźnienie, jak i uczestnictwo potrzebują punktu odniesienia pobranego przed zmianą.

Transakcja może być finalna, podczas gdy usługa wciąż pozostaje w tyle

Depozyt na giełdzie ilustruje lukę między finalnością łańcucha a użytecznym saldem użytkownika. Najpierw klient składa podpisaną transakcję. Transfer dociera do lidera i zostaje włączony do bloku. Walidatorzy głosują i tworzy się certyfikat finalizacji. Usługa RPC obserwuje certyfikat i raportuje go. Monitor depozytów giełdy identyfikuje adres i aktywo, przeprowadza kontrole polityki i uznaje konto. Zmiana konsensusu zasadniczo skraca jeden interwał w tej sekwencji.

Giełda może czekać dłużej z własnego wyboru. Może wymagać dodatkowych kontroli dla dużych depozytów, porównywać wyniki u wielu dostawców RPC lub opóźniać uznanie podczas incydentu. To nie oznacza, że łańcuch nie spełnił celu finalności. Oznacza, że benchmark łańcucha nie może być reklamowany jako gwarantowany czas uznania dla klienta. Uczciwe twierdzenie o produkcie powinno rozróżniać finalność bloku, widoczność RPC i własną decyzję instytucji o uznaniu.

Możliwy jest również odwrotny błąd. Aplikacja może wyświetlić oczekujący sukces, gdy tylko jej węzeł RPC zobaczy blok, zanim nadejdzie certyfikat finalizacji. Użytkownik może doświadczyć szybkiego zielonego znacznika, mimo że najsilniejsze zapewnienie protokołu pojawia się później. Podczas migracji aplikacja, która nadal oznacza status swojego zobowiązania sprzed aktualizacji w ten sam sposób, powinna zostać przetestowana pod kątem nowej semantyki. Wizualnie niezmieniony interfejs portfela może ukrywać zmieniony model ryzyka.

W przypadku aplikacji zdecentralizowanych finalny blok nie gwarantuje korzystnej transakcji. Transakcja może zostać wykonana i zakończyć się niepowodzeniem zgodnie z regułą aplikacji, uiścić opłaty lub rozliczyć się po cenie, której użytkownik nie oczekiwał w ramach przesłanych parametrów. Konsensusowa finalność oznacza, że księga główna zdecydowała o tym wyniku. Nie poświadcza, że inteligentny kontrakt jest bezpieczny ani że dane wejściowe oracle były poprawne. Aktualizacja powinna być doceniona za węższą właściwość, którą ma poprawić.

Aby uczynić to twierdzenie falsyfikowalnym, dostawcy infrastruktury mogliby publikować sparowane znaczniki czasu dla próbki transakcji: przybycie do ich usługi, pierwsze włączenie, obserwację certyfikatu, odpowiedź RPC i widoczne dla klienta uznanie. Powinni ujawniać brakujące obserwacje i ponowne próby. Porównanie tych przedziałów przed i po aktywacji, przy podobnych obciążeniach i warunkach opłat, pokazałoby, jak bardzo Alpenglow faktycznie skrócił całą podróż. Byłby to silniejszy dowód niż powtarzanie celu z białej księgi.

Najsilniejszym argumentem jest rzeczywista poprawa rozliczenia

Zwolennicy mogą przedstawić istotny argument. Obecna ścieżka potwierdzenia Solany od dawna pozostawia lukę między szybką produkcją bloków a silniejszą finalnością. Jeśli Votor niezawodnie zmniejszy tę lukę, giełda może szybciej uznawać depozyty, trader może zmniejszyć niepewność po wykonaniu, a dostawca płatności może rozliczać się z mniejszym oczekiwaniem. Propozycja protokołu jest poważnym projektem inżynieryjnym, a walidatorzy już poświęcili czas na testowanie go poza mainnetem.

Wcześniejsze relacje o zarządzaniu odnotowują decyzję walidatorów stojącą za propozycją. Ścieżka zarządzania walidatorami oznacza również, że zmiana nie jest jedynie obietnicą firmy. Operatorzy muszą przyjąć oprogramowanie i uczestniczyć w aktywacji. Etapowa bramka funkcji daje sieci możliwość ujawnienia problemów przed produkcją. Te mocne strony nie dowodzą ostatecznego poziomu usługi, ale czynią fazę testowania istotną.

Argument przeciwny to kompromis, który sami autorzy ujawniają: szybszy projekt głosowania wiąże się z odmiennymi założeniami dotyczącymi awarii. Operatorzy muszą również zarządzać migracją i kompatybilnością klientów. Mediana 150 milisekund uzyskana na spokojnym klastrze testowym nie odpowie na pytanie, jak protokół zachowuje się, gdy znaczący stake jest offline lub łącza sieciowe są niestabilne. Dlatego dowody należą do raportu o przypadkach awarii, a nie tylko do demonstracji szybkości.

Gotowość mainnetu ma kilka oddzielnych bramek

Pierwsza to adopcja oprogramowania: wystarczająca ilość stake uruchamia kompatybilne wydanie. Druga to weryfikacja protokołu na testnecie i devnecie: głosy i certyfikaty pozostają poprawne w normalnych i niekorzystnych warunkach. Trzecia to przygotowanie operacyjne: giełdy, dostawcy RPC, eksploratory bloków i portfele wiedzą, jak obserwować nowy sygnał finalności. Czwarta to sama zaplanowana aktywacja funkcji.

Tracker Anzy wskazuje, że minimalna wersja mainnetu może wzrosnąć, gdy 95% stake przyjmie nową wersję minor i miną dwie pełne epoki. Ta reguła reguluje minimalną obsługiwaną wersję; nie należy jej parafrazować jako automatycznej aktywacji Alpenglow przy 95%. Niezależny wiersz funkcji pozostaje miejscem do sprawdzenia rzeczywistej oczekującej zmiany.

Żaden zgłoszony test nie dowodzi, że cena SOL musi reagować w określony sposób. Ceny tokenów uwzględniają warunki makroekonomiczne, finansowanie, podaż, popyt na aplikacje i oczekiwania dotyczące aktualizacji przed wdrożeniem. Wcześniejszy przegląd aktywacji wyjaśnia, dlaczego kamień milowy konsensusu jest istotny, nie czyniąc go z definicji katalizatorem cenowym.

Czego wciąż brakuje w publicznych dowodach

Opublikowany, ostateczny plan aktywacji z datą oraz porównywalna publiczna seria pomiarów finalności przy różnych obciążeniach pozwoliłyby czytelnikom ocenić, jak blisko sieć jest do obiecywanego celu. Wyniki testów powinny określać wersje oprogramowania, uczestniczący stake, typy klientów, warunki przesyłania wiadomości, włączenie transakcji oraz opóźnienia percentylowe. Pojedynczy najlepszy czas finalizacji byłby niepełny.

Najbardziej rozstrzygający raport pojawi się po przełączeniu: powtarzane obserwacje finalności i widocznego dla aplikacji rozliczenia w mainnecie, a także ujawnienie wszelkich zdarzeń odzyskiwania. Do tego czasu testy walidatorów pokazują, że proponowany system jest ćwiczeniowy. Nie dowodzą one, że każdy użytkownik doświadczy rozliczenia w 150 milisekund.

Na co uważać

• Bramka funkcji: Wyraźny status Alpenglow w mainnecie według Anza oraz slot aktywacji, odrębny od ogólnej daty minimalnej wersji.
• Adopcja stake: Udział stake walidatorów uruchamiających wydanie obsługujące tę funkcję.
• Zgodność klientów: Aktualizacje dla implementacji walidatorów wymienionych jako nieobsługiwane w bieżącym wierszu trackera.
• Testy awarii: Opublikowane czasy odzyskiwania i opóźnienia długiego ogona przy podziałach, restartach i brakujących głosach.
• Czas użytkownika: Pomiary w mainnecie od złożenia przez finalność i powiadomienie RPC, nie tylko czas certyfikatu.

FAQ