Ten sam błąd, dwa finały: Telestai, Ravencoin i to, co dziedziczy fork

Wczoraj pisaliśmy o błędzie konsensusu Ravencoina — niesprawdzanym polu nHeight w nagłówku bloku, które pozwalało podrabiać dowód pracy, i o trzydniowej reorganizacji łańcucha, jakiej wymagało cofnięcie tego.

Ta historia ma drugą połowę i to ona jest bardziej użyteczna. Inny łańcuch miał dokładnie ten sam błąd dokładnie w tym samym miejscu. Nigdy go nie wykorzystano.

Różnicę między tymi dwoma finałami warto zrozumieć, bo nie jest to różnica w kodzie.

Telestai odziedziczył wadę, bo tak właśnie działają forki

Telestai to fork Ravencoina. Jego baza kodu pochodzi od Ravencoina, przez Meowcoina — noty wydania Telestai Core 3.0.1 wciąż wymieniają wśród porządków „czystkę źródeł Meowcoina", co pokazuje, jak niedawno ta linia była jeszcze widoczna w drzewie źródeł.

Walidacja nagłówków w Ravencoinie nie sprawdzała deklarowanego nHeight względem rzeczywistego położenia bloku w łańcuchu. W Meowcoinie też nie. W Telestai też nie. Nikt nie wprowadził tego błędu do Telestai; przyszedł razem z całą resztą, tak jak fork dziedziczy te fragmenty kodu, na które nikt nie patrzy, razem z tymi, na które ktoś patrzy.

To ta mało efektowna mechanika, przez którą jedna wada staje się problemem kilku łańcuchów. Forki nie są kopiami dryfującymi ku niezależności. Są kopiami niosącymi całą historię założeń rodzica — w tym, w tym przypadku, założenie, że ktoś już to pole waliduje.

Co Telestai zrobił, mając dwa dni uprzedzenia

Exploit Ravencoina ujawniono publicznie 11 sierpnia 2026 roku. Telestai Core 2.1.8 ukazał się 13 sierpnia, zatytułowany wprost: „Security: KAWPOW nHeight bind".

Noty wydania nie owijają w bawełnę:

To wydanie naprawia problem konsensusu/DoS w KAWPOW, w którym pole nagłówka nHeight (wybierające epokę ethash) nie było powiązane z łańcuchem. Ta sama klasa błędu została wykorzystana na mainnecie Ravencoina. Węzły Telestai działające na starszych wersjach pozostają narażone, dopóki nie zaktualizują.

Sama poprawka jest warstwowa, a warstwy są tu najciekawsze:

• Bezwzględne ograniczenie epoki jest egzekwowane natychmiast, zanim w ogóle dojdzie do liczenia skrótu dowodu pracy.
• Ścisłe powiązanie height == prev + 1 włącza się przy bloku 1 100 000 — w stylu miękkiego forka, bez przepisywania historii.
• Dowód pracy jest liczony dopiero po znalezieniu bloku rodzica i zweryfikowaniu wysokości, co zamyka ścieżkę wyczerpania pamięci, na której węzeł można było zmusić do kosztownej pracy nad nagłówkiem, który powinien był odrzucić od razu.
• Te same kontrole obowiązują w ConnectBlock i VerifyDB, żeby węzeł reindeksujący bazę nie przyjął po cichu z powrotem tego, czego nowe reguły zabraniają.

Mainnet był na wysokości około 1 057 000, gdy pojawiła się wersja 2.1.8. Egzekwowanie ustawiono na 1 100 000. Ten odstęp — jakieś 43 000 bloków — był celowy: dość rozbiegu, by giełdy, pule, eksploratory i operatorzy węzłów zaktualizowali się, zanim reguła się włączy, i nie na tyle dużo, by okno stało otworem w nieskończoność.

Telestai wskazał też źródło. Noty odsyłają do 2miners/Ravencoin, gałąź rvn-nheight-fix — tej samej łatki, która wyszła z incydentu Ravencoina — i dziękują badaczom, którzy udokumentowali pełniejszą poprawkę przyjmowania nagłówków. Lekarstwo pojechało tą samą drogą, którą wcześniej przebył błąd.

Dwa finały obok siebie

Dwa łańcuchy. Jedno dziedzictwo kodu. Jedna identyczna uśpiona wada.

Tę w Ravencoinie pierwszy znalazł atakujący. Efektem były cztery dni podrabianych bloków przed publicznym ujawnieniem, giełdy wstrzymujące wpłaty i wypłaty, spadek kursu o mniej więcej 20% i trzydniowa reorganizacja usuwająca zatrutą gałąź.

Tę w Telestai znaleziono, czytając cudzy raport z incydentu. Efektem była łatka dwa dni później, wysokość aktywacji ustawiona z zapasem i — ponieważ nie było nieprawidłowej historii do usunięcia — żadna reorganizacja. Nic nie zostało cofnięte, bo nic nie musiało.

I to cała różnica. Nie lepszy kod. Nie inny błąd. Tylko to, kto zauważył pierwszy i jak szybko ludzie utrzymujący łańcuch zareagowali na czyjś zły tydzień.

Potem Telestai zmienił algorytm w całości

Sześć dni po łatce bezpieczeństwa Telestai wydał Core 3.0.0, z forkiem przy bloku 1 150 000 — około 16 października 2026 roku — na Meraki, własny algorytm dowodu pracy. Meraki wciąż jest krewnym KAWPOW (pochodną Ethasha o zabarwieniu ProgPoW, a koparka zaczęła jako fork kawpowminer), reklamowaną jako mniej prądożerna i osiągalna na skromnych kartach graficznych.

Z przyczynowością trzeba tu uważać, bo kusi, żeby narysować prostą linię, a linia prosta nie jest. Meraki było w toku już przed sierpniem: kompilacje wygrzewające 3.0.0 na testnecie publikowano 13 i 14 sierpnia, w tych samych dniach co wydanie bezpieczeństwa, a takiego harmonogramu nikt nie składa w czterdzieści osiem godzin. Zmiana algorytmu była planowaną pracą, która przypadkiem wylądowała obok incydentu, a nie reakcją na niego.

W liście wydań kryje się też mała lekcja o nieefektownych stronach utrzymywania łańcucha. Między poprawką bezpieczeństwa a forkiem Telestai wydał 2.1.9 z powodu, który z konsensusem nie ma nic wspólnego: 2.1.8 zbudowano względem nowszej Berkeley DB, a otwarcie nią starego wallet.dat mogło przepisać dzienniki portfela tak, że starsze klienty nie potrafiły już odczytać pliku. Więc zbudowano ponownie względem Berkeley DB 4.8 i wydano jeszcze raz. Wydanie bezpieczeństwa niewiele daje, jeśli aktualizacja do niego naraża pliki portfeli twoich użytkowników.

Dlaczego to ważne poza dwoma małymi łańcuchami

Większość czytających nie ma ani RVN, ani TLS. Uogólnia się wzorzec.

Rozwidlone łańcuchy dzielą powierzchnię błędów i prawie nikt jej nie śledzi. Litecoin, Dogecoin, Bitcoin Cash, Ravencoin, Zcash i dziesiątki innych pochodzą od Bitcoin Core, a każdy niesie punkt rozejścia, po którym poprawki z góry strumienia przestają docierać same. Podatność ujawniona w jednym łańcuchu jest otwartym pytaniem dla każdego łańcucha położonego poniżej tego samego kodu — a im dalej fork odpłynął, tym więcej pracy kosztuje samo ustalenie, czy poprawka w ogóle się stosuje. Telestai odpowiedział na to pytanie w dwa dni. Nie każdy fork ma kogoś, kto ma to w zakresie obowiązków.

„Nikt tego nie wykorzystał" to nie to samo co „tego tam nie było". Oprogramowanie węzła Telestai było podatne przez całe swoje istnienie. Błąd był realny przez cały czas; nowa była tylko uwaga. Łańcuchy, które nigdy nie dostają raportu z incydentu od rodzeństwa, tą drogą się nie dowiadują.

Poprawka, która wyprzedzi exploit, kosztuje prawie nic. Ta sama poprawka po nim kosztuje reorganizację. Praca techniczna w Telestai 2.1.8 i w twardym forku Ravencoina to z grubsza ta sama łatka. Różniło się wszystko dookoła: czy była nieprawidłowa historia do odrzucenia, czy giełdy musiały się zatrzymać, czy potwierdzenia użytkowników przez trzy dni cokolwiek znaczyły.

To to samo rozumowanie, które stoi za powtarzalnymi kompilacjami i badaniem zależności: większość tego, co cię chroni, leży powyżej wszystkiego, co widać z wnętrza portfela, i utrzymują to ludzie uważający w twoim imieniu.

Co to znaczy w SSP

Praktycznie: dla ciebie nic się nie zmienia.

SSP obsługuje Ravencoina, a nasz węzeł działa na 4.8.0 w odzyskanym łańcuchu — we wczorajszym tekście sprawdziliśmy skróty bloków po obu stronach reorganizacji względem łańcucha referencyjnego. SSP nie obsługuje Telestai, więc w twoim portfelu nie ma żadnego salda Telestai, o które trzeba by się martwić.

Piszemy o łańcuchu, którego nie obsługujemy, bo ta historia czysto ilustruje coś, co traktujemy poważnie. Prowadzenie infrastruktury węzłów oznacza śledzenie prac nad bezpieczeństwem w górę strumienia dla każdego łańcucha, który nosimy, w tym tych, których bazy kodu mają wspólnych przodków. Wartość tego jest zupełnie niewidoczna, kiedy działa: załatany węzeł wygląda dokładnie tak samo jak niezałatany, dokładnie do dnia, w którym przestaje.

Sierpień Telestai to właśnie to, jak wygląda od środka: opiekun projektu czyta o cudzym exploicie, rozpoznaje jego kształt we własnym drzewie kodu i wydaje wersję. Żadnego incydentu, żadnej reorganizacji, żadnego ogłoszenia, które ktokolwiek z zewnątrz by zapamiętał. Tylko numer wersji idący w górę.