Co grozi walidatorom Solany, które pominą aktualizację Agave 4.4.1?

Anza dał operatorom węzłów Solana czas do epoki 1079 na zainstalowanie poprawki, która zmienia sposób, w jaki sieć liczy dane konta ładowane przez transakcję. Maszyna z starszą kompilacją mogła pozostać online i nadal wypaść z kroku z akceptowanym łańcuchem, co miało różne konsekwencje dla walidatorów zarabiających nagrody za staking oraz usług, na których portfele polegają w zakresie bieżących danych.

Anza ostrzegła walidatorów przed epoką 1079, że operatorzy uruchamiający starsze oprogramowanie ryzykują pozostanie w tyle, gdy sieć włączy nową regułę. Wymienione kompatybilne wersje to Agave 4.4.1 i Firedancer v26.10.6.

Tracker bramek funkcji Agave identyfikuje odpowiednią zmianę jako minimalny rozmiar załadowanych danych dla kont ProgramData loader-v3. Jego tabela dolnych progów wersji oddziela wydania używane przez sieci testowe od tych planowanych dla mainnetu. Odczytanie harmonogramu wymaga sprawdzenia klastra, funkcji i epoki razem.

Termin obejmował również węzły, które nie głosują. Te maszyny mogą dostarczać portfelom i giełdom salda, hashe bloków i dane potwierdzeń. Problem w jednej z nich może dotrzeć do użytkowników, którzy nigdy nie delegowali SOL ani nie wybrali walidatora.

Co robi ta zmiana

Program Solana może używać konta do przechowywania swoich danych wykonywalnych. Gdy transakcja musi załadować program, sieć uwzględnia dane związane z tą operacją. Minimum zastosowane do konta danych programu zmienia sposób, w jaki kompatybilne oprogramowanie traktuje odpowiednią transakcję w ramach nowej reguły.

Celem bramki funkcji jest koordynacja momentu, w którym uczestnicy zaczynają używać nowej reguły. Operatorzy mogą zainstalować wydanie z wyprzedzeniem, podczas gdy rzeczywista zmiana reguły wchodzi w życie w uzgodnionym punkcie. Wersja może zatem obsługiwać funkcję, zanim ta funkcja będzie aktywna w mainnecie.

Gdy bramka się aktywuje, starsze wydanie może nie zgadzać się z zaktualizowanym oprogramowaniem co do transakcji lub stanu wytworzonego przez blok. Walidator może wtedy przestać podążać za łańcuchem rozpoznawanym przez resztę sieci, mimo że sam serwer pozostaje online. To jest praktyczne znaczenie ostrzeżenia Anzy o odłączeniu od łańcucha.

Dlaczego staking stojący za węzłami ma znaczenie

Stu małych walidatorów i kilku dużych operatorów nie musi reprezentować porównywalnych ilości stakingu głosującego. Dla działania sieci istotne jest pytanie, ile stakingu podąża za kompatybilnymi regułami. Tracker mówi, że zmiany dolnego progu wersji minor w mainnecie zwykle następują po progu adopcji stakingu i okresie oczekiwania. Tę ogólną regułę należy odróżnić od konkretnego ostrzeżenia wydanego przed epoką 1079.

Sprawdzenie adopcji powinno łączyć informacje o wersji z aktywnym stakingiem, a następnie porównać te liczby z udziałem w głosowaniu po granicy. Węzeł zgłaszający właściwe wydanie może wciąż nadrabiać zaległości lub doświadczać osobnej usterki. Odwrotnie, stabilna agregacja może maskować problemy u mniejszego operatora, jeśli większość stakingu pozostaje online i głosuje normalnie.

Ta różnica ma znaczenie dla delegujących. Ich doświadczenie zależy od walidatora, któremu przydzielono ich staking, a nie od tego, czy większość maszyn zainstalowała wydanie. Jeśli walidator przestanie skutecznie głosować, utracony udział może zmniejszyć nagrody przypisywane temu stakingowi. Odpowiednim dowodem byłyby kredyty głosów i zapisy nagród dla dotkniętych epok.

Co zauważyliby użytkownicy i giełdy

Użytkownik wysyłający SOL dba o to, czy transfer zostanie zaakceptowany i osiągnie zamierzony poziom potwierdzenia. Można to sprawdzić poprzez dane transakcji i sieci. Twierdzenie, że kilku operatorów przegapiło aktualizację, samo w sobie nie dowodzi wolniejszych potwierdzeń, zatrzymania ani powszechnej awarii.

Giełda może również wstrzymać depozyty lub wypłaty podczas monitorowania aktualizacji, nawet gdy transfery są kontynuowane onchain. Salda jej klientów zależą od jej własnej infrastruktury i polityk uznawania środków. Transakcja, która pojawia się onchain, może zatem pozostać w zawieszeniu na koncie giełdowym klienta, dopóki ten podmiot nie wznowi normalnego przetwarzania.

Użyteczne porównanie po aktualizacji sprawdziłoby trzy rzeczy osobno. Po pierwsze, czy bloki były nadal produkowane i potwierdzane? Po drugie, czy ilość stawki głosującej faktycznie się zmieniła? Po trzecie, czy jakakolwiek wymieniona giełda wstrzymała lub wznowiła transfery wokół granicy? Każda odpowiedź wymaga innego zapisu.

Dlaczego termin aktualizacji dotyczył również infrastruktury

Notatki wydania Agave firmy Anza Agave release notes wskazują zmianę w rozliczaniu ProgramData jako backport. Wydanie Firedancer release obejmuje obsługę tej samej funkcji. Gdy dwa klienty przetwarzają tę samą transakcję po aktywacji, muszą uzgodnić, ile danych konta ona ładuje. Wspólna reguła ma znaczenie na granicy.

Niezastakowany węzeł RPC może obsługiwać aplikację bez wnoszenia stawki do głosów. Dzięki temu użytkownik portfela może łatwo napotkać lokalny problem, nawet jeśli walidatory głosujące nadal produkują bloki. Aplikacja czytająca z opóźnionego punktu końcowego może wyświetlać stary stan lub zwracać błąd. Porównanie jej odpowiedzi z tym samym żądaniem za pośrednictwem innego punktu końcowego pomaga zidentyfikować, gdzie wystąpiło zakłócenie.

Październikowa migracja Solany October Alpenglow migration zapewnia kontekst, w jaki sposób operatorzy przygotowują się do skoordynowanej zmiany. Ta migracja dotyczyła protokołu konsensusu. Listopadowa poprawka dotyczyła ładowania kont. Obie dają operatorom wersję do weryfikacji, ale skutki należy oceniać w odniesieniu do konkretnej reguły, która uległa zmianie.

Co odróżniało termin od daty wydania

Anza opublikowała Agave 4.4.1 5 listopada. Jej późniejsze ostrzeżenie dla operatorów mówiło, że zmiana została zaplanowana na epokę 1079, której rozpoczęcie szacowano na około 13:30 UTC 6 listopada. Wersja wskazywała oprogramowanie, którego potrzebowali operatorzy, natomiast epoka wskazywała, kiedy sieć planowała rozpocząć stosowanie reguły.

Granica epoki zależy od postępu łańcucha. Czas w ostrzeżeniu dał operatorom praktyczne oszacowanie, ale przejście łańcucha do nowej epoki było ważnym wydarzeniem. Operatorzy nie mogli traktować późniejszego czasu lokalnego ani rutynowego okna konserwacyjnego jako przedłużenia harmonogramu.

Wydanie może zawierać kod, który jeszcze nie zmienia sposobu przetwarzania transakcji przez sieć. Operatorzy najpierw instalują oprogramowanie, a następnie sieć aktywuje funkcję w zaplanowanym punkcie. Taka sekwencja pozwala operatorom przygotować się, zanim węzły natychmiast zaczną stosować różne reguły do tego samego bloku.

Okno było krótkie nawet dla operatorów, którzy przeszli już na Agave 4.4.0. Numer poprawki zmienił się o jeden, ale wcześniejsze wydanie nie miało obsługi potrzebnej dla nowej reguły. Niedawna instalacja nie była zatem substytutem sprawdzenia dokładnej kompilacji.

Wydanie Firedancer 26.10.6 release obsługiwało tę samą funkcję. Operatorzy mogli używać różnych implementacji klienta, ale obie musiały liczyć te same dane konta podczas wykonywania transakcji zgodnie z aktywnymi regułami.

Rozróżnienie między oprogramowaniem a aktywacją pojawiło się już w relacji crypto.news na temat Alpenglow’s testnet rollout. Alpenglow zmienił konsensus, podczas gdy listopadowa poprawka dotyczyła przetwarzania transakcji. W obu przypadkach dostępność kompilacji była odrębnym kamieniem milowym od wymagania przez sieć jej zachowania.

Gdzie ProgramData wchodzi w transakcję

Transakcja wymienia konta, których potrzebują jej instrukcje. Walidator ładuje dane powiązane z tymi kontami, aby wykonać instrukcje. Sieć ogranicza, ile danych konta transakcja może załadować, dając walidatorom ograniczenie na kategorię pracy, którą wykonują przed lub w trakcie wykonania.

Aktualizowalny loader Solany używa konta programu i oddzielnego konta ProgramData. To drugie przechowuje dane wykonywalnego programu oraz powiązane informacje dla loadera. Użytkownik wywołuje program bez ręcznego uwzględniania rozmiaru tych danych wykonywalnych. Ta część jest obsługiwana przez środowisko uruchomieniowe walidatora.

Poprawka ustanawia dolny limit dla ilości przypisywanej kontu ProgramData loadera-v3 podczas jego ładowania. Jeśli stare rozliczanie przypisywało mniej niż dolny limit, nowa reguła liczy co najmniej minimum przeciwko limitowi załadowanych danych transakcji. Transakcja znacznie poniżej limitu może dać ten sam wynik po zmianie.

Różnica ma znaczenie na granicy. Transakcja, która łączy kilka instrukcji lub używa kilku programów, może już ładować znaczne dane konta. Jeśli nowe minimum sprawi, że łączna ilość przekroczy limit, stare i nowe reguły mogą dać różne wyniki nawet przy tych samych instrukcjach i tym samym podpisującym.

Limit załadowanych danych jest odrębny od budżetu obliczeniowego. Obliczenia mierzą pracę wykonania. Transakcja może mieć wystarczająco dużo obliczeń, aby wykonać instrukcje, a mimo to nie spełnić limitu, który reguluje, jakie konta może załadować. Samo podniesienie limitu obliczeń nie zmienia ilości liczonej przeciwko limitowi załadowanych danych.

Reguła pozostawia również wdrożone instrukcje aplikacji na miejscu. Program może znajdować się pod tym samym adresem i mieć ten sam kod, podczas gdy walidator rozlicza jego konto ProgramData inaczej. Zespoły aplikacji mają powód, aby ponownie sprawdzić transakcje blisko limitu, nawet jeśli same nie dokonały żadnego wdrożenia.

Jak dwa węzły mogą się nie zgadzać co do tego samego bloku

Walidatory wykonują transakcje, aby sprawdzić stan wyprodukowany przez blok. Jeśli dwa węzły zaczynają od tego samego stanu i stosują różne reguły do jednej z tych transakcji, mogą osiągnąć różne wyniki. Nie mogą oba uznawać tego samego wynikowego stanu za ważny, chyba że różnica zostanie rozwiązana.

To wyjaśnia ostrzeżenie Anzy o starszych węzłach wypadających z kroku. Stary węzeł może pozostać online i nadal odpowiadać na żądania, jednocześnie nie śledząc łańcucha akceptowanego przez kompatybilne walidatory. To, że jego proces działa, jest słabszym testem niż to, czy jest aktualny i zgadza się z klastrem.

Operator może porównać slot raportowany przez węzeł z niezależnym odniesieniem. Walidator głosujący musi również sprawdzić, czy jego głosy są liczone na akceptowanym łańcuchu. Dzienniki błędów mogą zidentyfikować problem podczas odtwarzania bloków, który byłby niewidoczny w kontroli czasu działania.

Ostrzeżenie opisywało konsekwencję niekompatybilności. Ocena po terminie nadal musi pokazać, którzy operatorzy uruchamiali nieaktualne kompilacje i co stało się z ich węzłami. Migawka wersji zebrana po odzyskaniu przez operatora mogłaby pominąć krótki okres, w którym ten walidator wypadł z kroku.

Data aktywacji i moment, w którym obserwator zauważa problem, również mogą się różnić. Wąska reguła dotyczy tylko transakcji, które ją uruchamiają. Okres bez widocznej rozbieżności bezpośrednio po granicy nie pokazałby, czy węzeł mógłby obsłużyć transakcję blisko dotkniętego limitu.

Dlaczego liczba walidatorów opowiada tylko część historii

Znaczenie walidatora głosującego zależy częściowo od tego, ile stawki reprezentuje. Kilku dużych operatorów może reprezentować więcej wagi głosów niż wielu mniejszych. Liczba dotkniętych maszyn odpowiada zatem na inne pytanie niż odsetek aktywnej stawki, która kontynuowała uczestnictwo.

Węzły bez stawki mają odrębną rolę. Mogą dostarczać aplikacjom, giełdom i portfelom dane lub przekazywać podpisane transakcje. Awaria popularnej usługi może dotknąć wielu użytkowników, nawet jeśli usługa nie wnosi żadnej stawki do konsensusu.

Istotne miary mogą zmieniać się niezależnie. Produkcja bloków może być kontynuowana, podczas gdy konkretny dostawca RPC serwuje nieaktualne dane. Walidator może pomijać głosy, podczas gdy jego publiczna strona internetowa pozostaje dostępna. Giełda może wstrzymać depozyty Solany, podczas gdy łańcuch nadal potwierdza przelewy.

Wcześniejsze relacje o terminie Alpenglow Solany opisywały przekazanie wymagające skoordynowanego przygotowania przez walidatorów i aplikacje. Celem było tam szybsze finalizowanie. Brama ProgramData ma węższy efekt techniczny, ale operatorzy nadal muszą oceniać gotowość względem własnego miejsca w sieci.

Co delegatorzy mogą ustalić na podstawie zapisów głosów i nagród

Delegatorzy mają pytanie ekonomiczne, nawet gdy sieć pozostaje dostępna. Chcą wiedzieć, czy walidator zarabiający nagrody w ich imieniu nadal uczestniczył. Pominięta poprawka sama w sobie nie przenosi delegowanego SOL ze konta stakingowego, ale przerwa w głosowaniu może zmniejszyć nagrody zarobione w danym okresie.

Pierwszym miejscem, w którym należy spojrzeć, jest konto głosów walidatora. Porównanie kredytów głosów w epokach wokół granicy może ustalić, czy jego uczestnictwo się zmieniło. Zapisy nagród dają osobną kontrolę wpływu na konkretne konta stakingowe.

Niższa nagroda sama w sobie nie wskazuje aktualizacji jako przyczyny. Prowizja, wcześniejsze wyniki walidatora i status konta stakingowego mogą wpływać na zapisaną kwotę. Dowody, że głosy zatrzymały się na granicy i wznowiły po zmianie klienta, dałyby silniejsze wyjaśnienie niż pojedyncza niższa nagroda.

Token płynnego stakingu dodaje kolejną warstwę. Pula może rozłożyć swój stake na kilku walidatorów. Problem u jednego operatora może przyczynić się tylko do części zmiany nagród puli, w zależności od jego udziału w delegacji i księgowości puli.

Staking na giełdzie dodaje relację usługową. Giełda może obsługiwać własnych walidatorów lub korzystać z innego dostawcy, a następnie uznawać klientom środki zgodnie ze swoimi warunkami. Użytkownik potrzebowałby zapisów giełdy, aby powiązać zmianę głosów onchain z nagrodą uznaną na indywidualnym koncie.

Co przestarzały punkt końcowy RPC może zrobić z portfelem

Wiele portfeli pobiera salda, hashe bloków i wyniki transakcji przez punkt końcowy RPC. Węzeł, który pozostaje w tyle, może zgłosić wcześniejsze saldo lub nie zwrócić niedawnej transakcji. Użytkownicy mogą napotkać takie objawy, nawet jeśli inne węzły przetwarzają sieć normalnie.

Hash bloku może wpłynąć na transakcję, zanim sieć ją wykona. Portfel, który otrzyma nieaktualny hash bloku, może skonstruować transakcję, która nie jest już ważna, gdy dotrze do zdrowego węzła. Objawem jest nieudane przesłanie, ale przyczyną mogą być nieaktualne informacje, a nie zmiana salda lub instrukcji.

Symulacja zależy od tej samej relacji. Węzeł działający na starych regułach może zgłosić, że transakcja mieści się w załadowanym limicie danych, mimo że węzły egzekwujące nową regułę osiągają inny wynik. Symulacja na zgodnym węźle nadal może różnić się od końcowego wykonania, jeśli stan zmieni się między symulacją a włączeniem.

Aplikacje z kilkoma węzłami za jednym punktem końcowym stają przed kolejną możliwością. Żądania mogą się powieść lub nie, w zależności od tego, która maszyna je otrzyma. Dostawca musi sprawdzić, czy cała pula jest aktualna, zanim przypisze sporadyczny problem łańcuchowi.

Porównanie między niezależnymi punktami końcowymi pomaga oddzielić te problemy. Jeśli kilka aktualnych punktów końcowych się zgadza, a jeden usługa się różni, rozbieżność może być lokalna dla tej usługi. Jeśli niezależni obserwatorzy również zgłaszają zmianę w produkcji bloków lub potwierdzeniach, istnieją silniejsze dowody na problem sieciowy.

Październikowe przejście konsensusu miało własne zmiany infrastrukturalne. Crypto.news poinformował, że Alpenglow usunął poprzednie transakcje głosowania onchain. Zespoły aplikacji musiały odróżnić zmianę w tym, co obserwowały, od tego, czy walidatorzy mogli podążać za nowym systemem. Listopadowa reguła ładowania konta ponownie sprawia, że odpowiedź zależy od roli obserwatora.

Dlaczego uznanie na giełdzie może opóźniać się względem łańcucha

Giełda może uznać depozyt dopiero po tym, jak jej systemy rozpoznają przelew i zastosują swoją politykę potwierdzeń. Udana transakcja onchain nie określa zatem, kiedy zmieni się wewnętrzne saldo giełdowe klienta.

Platforma może wstrzymać depozyty lub wypłaty podczas aktualizacji infrastruktury. Może również nadal przyjmować przelewy onchain, podczas gdy jej kolejka depozytów oczekuje na potwierdzenie od sprawnego węzła. Komunikat platformy i eksplorator bloków mogą być jednocześnie prawdziwe, nawet jeśli jeden wskazuje na przerwę w usłudze, a drugi na udany przelew.

W przypadku wypłat opóźnienie może wystąpić, zanim giełda podpisze lub rozgłosi transakcję. Brak zapisu onchain w tym czasie niewiele mówi o tym, czy sieć zaakceptowałaby transakcję po jej przesłaniu. Status przetwarzania platformy odnosi się do tej części osi czasu.

Raport, że kilka giełd wstrzymało działalność, nadal wymagałby wskazania, których usług to dotyczyło i jaki powód podała każda z nich. Rutynowy komunikat o konserwacji lub kolejka spowodowana innym problemem mogą przypadać w tym samym oknie co aktualizacja. Zbieg okoliczności jest powodem do porównania zapisów, a nie miarą uczestnictwa sieci.

Co pokazałoby, czy operatorzy pominęli poprawkę

Tracker bramek funkcji Anza oddziela minimalny próg wydania od poszczególnych aktywacji. Wcześniejsze doniesienia crypto.news o wdrożeniu Alpenglow i progu mainnet opisywały to samo rozróżnienie. Kompilacja może spełniać próg w jednym momencie i nie zawierać zmiany zaplanowanej na późniejszą epokę.

Najbardziej użyteczny zapis po aktywacji porównywałby aktywną funkcję, dystrybucję oprogramowania i uczestnictwo operatorów w tym samym oknie. Zapis funkcji wskazuje, kiedy reguła zaczęła obowiązywać. Zapis oprogramowania wskazuje, które kompilacje były w użyciu. Głosy i bloki pokazują, czy sieć i poszczególni operatorzy zachowywali się inaczej.

Pominięte sloty to jedna z możliwych obserwacji. Mogą one również wzrosnąć z powodów niezwiązanych z poprawką, w tym z powodu zwykłej wydajności walidatorów wyznaczonych do prowadzenia. Porównanie kilku okien i dopasowanie pominięć do ich liderów nadaje obserwacji kontekst.

Zaległy stake zapewnia inny obraz. Kwota może się zmienić, gdy jeden duży walidator przestanie uczestniczyć, nawet jeśli całkowita liczba zaległych węzłów ledwo się zmieni. Porównanie musi uwzględniać operatorów, którzy byli już zalegli przed aktualizacją.

Efekty RPC i giełd muszą być udokumentowane osobno. Ci dostawcy mogą obsługiwać dużą liczbę użytkowników, nie pojawiając się w porównaniu stake. Ich komunikaty, metryki usług i zapisy o tym, kiedy węzły wróciły do bieżących slotów, opisywałyby zakłócenia, których dane o głosowaniu nie mogą uchwycić.

Dlaczego stopniowe wdrożenie nadal wymaga testu aktywacji

Stabilne wydanie klienta można wdrażać stopniowo, zanim nowa funkcja będzie aktywna. Pozwala to operatorom sprawdzić, czy oprogramowanie uruchamia się poprawnie, nadąża i przetwarza transakcje zgodnie z obowiązującymi regułami. Pomaga również ujawnić problemy z wdrożeniem, zanim więcej węzłów zacznie go używać.

Udane wdrożenie przed aktywacją nie może sprawdzić każdej konsekwencji aktywnej funkcji. Transakcja blisko limitu załadowanych danych konta musi zostać przetestowana w obu zestawach reguł, aby dokładnie pokazać, gdzie wynik się zmienia. To inny test niż obserwowanie, czy binarka pozostaje online.

Crypto.news wcześniej informowało, że Alpenglow obrało inne podejście do finalności. Jego kryteria sukcesu obejmowały to, co stało się z szybkością potwierdzenia. Poprawkę ProgramData lepiej oceniać po tym, czy klienci zgadzają się co do transakcji napotykających nowy limit i czy infrastruktura pozostaje dostępna po włączeniu bramki.

Wycofanie zmiany również zmienia znaczenie w momencie aktywacji. Przed granicą starsze wspierane wydanie może nadal przetwarzać reguły już obowiązujące. Po niej powrót do kompilacji, która nie zawiera funkcji, może przywrócić dokładnie tę niezgodność, którą operator próbował rozwiązać. Wersja zapasowa musi zachować wsparcie dla aktywnej bramki.

Operator z wolną mocą może uruchomić załatany węzeł i zweryfikować go przed przydzieleniem ruchu. Mniejszy operator może musieć zrestartować swój jedyny węzeł i poczekać, aż nadąży. Termin jest wspólny, ale czas, który użytkownicy spędzają na oczekiwaniu, może zależeć od nadmiarowości dostawcy.

Dlaczego cena SOL nie może mierzyć efektu aktualizacji

SOL może spaść lub wzrosnąć w tych samych godzinach, w których operatorzy instalują poprawkę. Handluje się nim względem wielu tych samych walut i pul kapitału co innymi aktywami kryptowalutowymi. Stopy, ruchy Bitcoina i zmiany w dźwigni mogą wpływać na cenę w tym samym oknie.

Problem techniczny może mieć znaczenie dla handlu, jeśli zakłóca przelewy lub powoduje niedostępność aplikacji. Dowody na takie wyjaśnienie obejmowałyby komunikaty z giełd, zmiany w depozytach lub wypłatach albo dane o wykonaniu onchain powiązane z odpowiednimi kontami. Sama cena tokena nie identyfikuje tego kanału.

Niepowodzenie pojedynczej transakcji różni się również od utraty kontroli nad kontem. Portfel mógł zbudować transakcję na podstawie starych informacji lub przesłać ją przez nieaktualny węzeł. Użytkownik nadal może kontrolować konto, podczas gdy aplikacja ma trudności z dotarciem do bieżącej sieci.

Najbardziej bezpośredni test po terminie odbywa się zatem na poziomie usługi. Węzeł głosujący powinien być aktualny i rejestrować głosy. Usługa RPC powinna odpowiadać na żądania z akceptowanego łańcucha. Giełda powinna być w stanie rozliczyć, czy i kiedy przetworzyła przelewy złożone w okolicach przełączenia.

Takie dowody mogą wesprzeć ocenę, nawet jeśli cena zmienia się z niepowiązanych przyczyn. Dają też delegatorom sposób na ocenę wyników własnego walidatora bez traktowania ogólnosieciowego wymogu wersji jako stwierdzenia o wynikach każdego operatora.

Co się dzieje, gdy operator wraca online

Zainstalowanie załatanej wersji oprogramowania to jeden z kroków przywracania węzła. Operator musi następnie sprawdzić, czy proces dogania akceptowany łańcuch i podąża za nim zgodnie z bieżącymi regułami. Serwer może pomyślnie się uruchomić, podczas gdy nadal odtwarza bloki lub zwraca dane opóźnione względem końcówki łańcucha.

Węzeł głosujący musi również wykazać, że jego udział został wznowiony. Jego operator może porównać bieżące głosy z czasem, w którym węzeł się odzyskał. Delegator czytający później dane o nagrodach może wtedy odróżnić punkt odzyskania od czasu instalacji poprawki.

Dostawca usług może wyłączyć załatany węzeł z rotacji, dopóki nie dogoni łańcucha i nie przejdzie kontroli. Operator może porównać slot, wynik niedawnej transakcji i rezultat symulacji z osobnym punktem odniesienia. Dostawca, który przywróci węzeł do ruchu przed tymi kontrolami, może sprawić, że aktualizacja oprogramowania będzie wyglądać na zakończoną, podczas gdy klienci nadal napotykają stare dane.

Harmonogram ma znaczenie przy ocenie wpływu. Węzeł, który rozjechał się i wrócił w tej samej epoce, może wyglądać na zdrowy w późniejszym katalogu. Jego utracony udział może nadal mieć znaczenie dla operatora lub delegatorów. Publiczny harmonogram incydentu wymagałby wystarczającej szczegółowości, aby pokazać, kiedy usługa ustała i kiedy wznowiono normalną aktywność.

Zespoły aplikacji mogą również zbadać transakcje, które nie powiodły się tylko przez określony backend. Jeśli ponowne przesłanie przez bieżący węzeł rozwiązuje problem bez zmiany instrukcji, wcześniejszy endpoint staje się prawdopodobnym źródłem awarii. Jeśli ta sama transakcja konsekwentnie zawodzi na bieżących węzłach w pobliżu limitu danych konta, sama transakcja może wymagać przebudowy.

Taka przebudowa może polegać na zmniejszeniu danych ładowanych przez transakcję lub rozdzieleniu instrukcji, gdy aplikacja może tolerować wiele transakcji. Podział transakcji może zmienić jej gwarancje, ponieważ instrukcje, które miały zakończyć się sukcesem lub porażką razem, mogą już tego nie robić. Zmiana należy zatem do samego projektu aplikacji, obok jej wymagań dotyczących ładowania kont.

Konsekwencje dla użytkownika zależą od tego, gdzie wystąpiła niezgodność. Operator może utracić udział, RPC może zwracać nieaktualne informacje, a aplikacja może zbudować transakcję, która już nie pasuje. Pierwsze dwa przypadki można rozwiązać, przywracając zgodną infrastrukturę, natomiast trzeci zależy od transakcji i aktywnej reguły.

Kontrola odzyskiwania Solany powinna utrzymywać te obserwacje osobno. Powinna porównywać zapisy głosów operatorów, zapisy usług dostawców i wyniki wykonania dla dotkniętych aplikacji. Dzięki temu można zidentyfikować wąski skutek, nawet jeśli sieć przez cały czas produkowała bloki.

Listopadowy termin dał operatorom nazwane wydanie i granicę epoki. Trwały zapis jego wpływu będzie wynikać z tego, co węzły robiły wokół tej granicy i jaką usługę były w stanie zapewnić po niej.

Na co uważać

• Zgodne wersje: Harmonogram Anzy i informacje o wydaniach mogą ustalić podstawę mainnetu i jej odpowiedniki w różnych klientach.
• Udział w głosowaniu: Aktywny stake i kredyty głosów mogą pokazać, czy udział w głosowaniu zmienił się wokół granicy.
• Potwierdzenia sieci: Rekordy bloków i potwierdzeń mogą pokazać, czy sieć nadal przetwarzała transakcje wokół zmiany.
• Operacje giełdowe: Komunikaty giełd mogą ustalić, czy giełda wstrzymała własne depozyty lub wypłaty Solany.

Najczęściej zadawane pytania