Ryzyko mostów: walidatorzy, multisig i ataki powtórzeniowe

2026-08-12

Most niczego nie przenosi. Stawia twierdzenie na jednym łańcuchu i przekonuje drugi łańcuch, żeby na nim zadziałał, a każde włamanie na most to ten drugi łańcuch, który uwierzył twierdzeniu, choć powinien był je odrzucić. Dlatego ryzyko mostów warto porządkować po założeniu o zaufaniu, a nie po nazwie produktu: w co wierzy łańcuch docelowy i co trzeba zrobić, żeby uwierzył w nieprawdę. Ten artykuł przechodzi przez pięć strukturalnych źródeł, od zewnętrznych zbiorów walidatorów po klucze aktualizacji.

Pytanie, które porządkuje każdy most

Oficjalna dokumentacja dla deweloperów Ethereum sprowadza bezpieczeństwo mostu do jednego pytania: kto weryfikuje ten system? Prowizje, szybkość i liczba podłączonych łańcuchów leżą już poniżej tego pytania.

Mechanika prawie się nie zmienia. Na łańcuchu źródłowym coś się dzieje. Jakaś strona poświadcza, że to się stało. Kontrakt na łańcuchu docelowym sprawdza to poświadczenie wobec reguły i, jeśli przechodzi, odblokowuje albo emituje. Wszystko, czego chce atakujący, leży po drugiej stronie tej reguły.

Dokumentacja dzieli konstrukcje na dwie rodziny. Mosty zaufane są weryfikowane z zewnątrz: przez federację z multisigiem, system obliczeń wielostronnych albo sieć wyroczni. Mosty bez zaufania opierają się na łączonych łańcuchach i ich własnych walidatorach, nie dodając nowego założenia. Pierwsza rodzina kupuje łączność i szybkość, a płaci bezpieczeństwem: most chroniony przez zewnętrznych walidatorów jest zwykle słabszy niż most chroniony natywnie przez same łańcuchy.

Skala pieniędzy czyni tę wymianę bezlitosną. Do sierpnia 2022 roku Chainalysis naliczyła 13 osobnych włamań na mosty cross-chain na około 2 miliardy dolarów, czyli mniej więcej 69% wszystkiego, co skradziono w krypto w tamtym roku do tego momentu. Mosty przyciągają ataki, bo gromadzą zabezpieczenie dokładnie w punkcie, w którym sprawdzana jest jedna reguła.

Dlatego kolejne sekcje są ułożone według założeń, a nie według incydentów. Dwa mosty o różnych nazwach i tym samym modelu weryfikacji psują się tak samo, a znajomość nazw nic nie mówi o tym, z którego właśnie zamierzasz skorzystać.

Zewnętrzny zbiór walidatorów to system, którego nie audytowałeś

Najczęstsza konstrukcja zaufana ustawia między łańcuchami zbiór N stron. Obserwują one łańcuch źródłowy, podpisują poświadczenie, że zdarzenie zaszło, a kontrakt docelowy przyjmuje je, jeśli weryfikuje się co najmniej M podpisów. Poza tym kontrakt nie ma o rzeczywistości żadnego zdania.

Wniosek jest bezlitośnie prosty: kto kontroluje M kluczy, ten może emitować. Weź zbiór 9 stron z progiem 5. Atakujący z 5 kluczami nie potrzebuje błędu w kontrakcie, słabości któregokolwiek z łańcuchów ani żadnej dodatkowej kontroli. Przez cały czas, gdy opróżnia most, most robi dokładnie to, do czego został zbudowany.

Zauważ, jakie bezpieczeństwo naprawdę kupujesz. Zbiór walidatorów to własny system, z własnymi operatorami, maszynami i bodźcami, i nie dziedziczy nic po łączonych łańcuchach. Most weryfikowany przez zewnętrzny zbiór jest tak mocny jak ten zbiór i ani trochę mocniejszy, choćby sieci po obu jego stronach były ogromne.

Warto więc pytać o skład. Kim jest tych N i czy w ogóle są ujawnieni? To odrębne organizacje czy jedna organizacja z dziewięcioma maszynami? Ile wynosi M? Czy członkowie mają cokolwiek w stawce, co można im zabrać, jeśli podpiszą fałszywą wiadomość? I kto może zmienić skład, bo zbiór, który przepisuje jeden klucz, jest mostem jednopodpisowym w przebraniu komitetu.

Próg liczy się tylko wtedy, gdy klucze zawodzą niezależnie

M-of-N to twierdzenie o niezależności, a nie arytmetyka. Pięć z dziewięciu jest sensownie trudniejsze niż jeden z jednego tylko wtedy, gdy tych dziewięć kluczy może zawieść na dziewięć niepowiązanych sposobów.

Często nie może. Klucze wewnątrz jednej firmy dzielą jeden proces rekrutacji, jeden obraz laptopa, jeden VPN, jedną chmurową usługę kluczy i jeden interfejs podpisu. Jeśli jedna wiadomość phishingowa dosięga wszystkich dziewięciu posiadaczy albo pięć kluczy leży na jednym koncie chmurowym, to N jest liczbą na pulpicie, a prawdziwe N jest bliższe 1.

Podniesienie progu tego nie naprawia i coś kosztuje. Przy wysokim M utrata kilku kluczy zostawia most bez możliwości podpisania czegokolwiek: nic nie zostaje skradzione, ale nic też się nie rusza, a kto ma aktywa po złej stronie, ten czeka. Każdy próg to wybór między zbyt łatwo ukraść a zbyt łatwo zamrozić.

Powierzchnia podpisu zasługuje na tyle samo uwagi co przechowywanie kluczy. Podpisujący zatwierdzają dane, których w większości nie potrafią przeczytać, więc jeśli interfejs pokazuje przyjazne podsumowanie, a bajty pod spodem mówią co innego, uczciwi podpisujący wytwarzają ważny złośliwy podpis. Ślepe podpisywanie zamienia komitet M-of-N w pieczątkę M-of-N i żaden próg przed tym nie chroni.

Lekkie klienty i weryfikacja optymistyczna obstawiają co innego

Konstrukcje z minimalnym zaufaniem usuwają zewnętrzny zbiór, ale nie usuwają zaufania, tylko je przenoszą. Główną robotę robią dwie rodziny.

Weryfikacja lekkim klientem umieszcza klient łańcucha źródłowego wewnątrz łańcucha docelowego. Docelowy przechowuje stan konsensusu źródłowego i sprawdza, czy deklarowane zdarzenie zostało wobec niego udowodnione. W IBC każda strona połączenia używa lekkiego klienta drugiego łańcucha do weryfikacji przychodzących wiadomości, więc założenie sprowadza się do konsensusu łańcucha źródłowego plus poprawności kodu klienta. Nowsza wersja IBC mówi wprost: klient to po prostu model weryfikacji i równie dobrze może być lekkim klientem, multisigiem albo weryfikatorem dowodów. Założenia nie wyznacza etykieta, tylko typ klienta.

Weryfikacja optymistyczna idzie w drugą stronę: przyjmij wiadomość warunkowo i daj każdemu okno, w którym można udowodnić, że jest fałszywa. Założeniem jest, że przynajmniej jeden obserwator działa, ma z czego płacić i zdąży wprowadzić transakcję kwestionującą przed zamknięciem okna. Obserwator, który przez czas trwania okna jest wyłączony, bez środków albo cenzurowany, to tyle samo co brak obserwatora.

Żadna z rodzin nie jest darmowa, a koszty są strukturalne, nie przypadkowe. Lekkie klienty kosztują gaz i pracę inżynierską dla każdej pary łańcuchów, a błąd w kliencie jest błędem w samej regule. Konstrukcje optymistyczne łączą się tanio, ale każą każdemu uczciwemu użytkownikowi odsiedzieć opóźnienie wybrane przez projektanta. Dokumentacja Ethereum nazywa oba koszty wprost: ograniczenia łączności przy mostach na lekkich klientach i szybkości przy optymistycznych.

Powtórzenie to jedna ważna wiadomość policzona dwa razy

Wiadomość mostu to autoryzacja. Atak powtórzeniowy polega na tym, że autoryzacja rzeczywiście wydana zostaje przedstawiona ponownie: drugi raz w tym samym miejscu albo pierwszy raz tam, gdzie nigdy nie miała obowiązywać. Nic nie jest podrabiane. Te same ważne bajty są po prostu użyte jeszcze raz.

Kanoniczna odpowiedź leży w historii samego Ethereum. EIP-155 wkłada chain ID do danych, które są haszowane i podpisywane, więc podpis zrobiony dla jednego łańcucha nie weryfikuje się na innym. Zwróć uwagę, jak to wprowadzono: starszy sześcioelementowy format pozostał ważny, czyli ta ochrona jest czymś, co podpisujący włącza sam, a nie czymś, co gwarantuje format.

Dla wiadomości strukturalnych, które mosty faktycznie przenoszą, EIP-712 definiuje separator domeny. Może on nieść nazwę, wersję, chain ID i adres kontraktu weryfikującego, a także salt jako separator ostatniej szansy, i mówi, że portfel powinien odmówić podpisu, gdy chain ID nie zgadza się z łańcuchem, na którym użytkownik faktycznie jest. Inny łańcuch, inny kontrakt, inna wersja, inna wiadomość. To właśnie znaczy w praktyce rozdzielenie domen: adresat trafia do środka tego, co podpisano.

Rozdzielenie domen nadal nie powstrzymuje dostarczenia tej samej wiadomości dwa razy pod ten sam adres. EIP-712 mówi to sam: standard obejmuje podpisywanie i nie zawiera ochrony przed powtórzeniem, więc aplikacje muszą odrzucić duplikat albo uczynić autoryzowane działanie idempotentnym. Ta robota należy do nonce, numeru sekwencyjnego albo zapisu wiadomości już zużytych.

IBC pokazuje wzór złożony do końca. Dostarczenie dokładnie raz jest deklarowaną własnością protokołu: każdy pakiet niesie numer sekwencyjny, łańcuch odbierający zapisuje pod tym numerem potwierdzenie, a pakiet, którego potwierdzenie już istnieje, jest odrzucany. Specyfikacja zauważa, że to ten sam problem numerów sekwencyjnych co przy podpisanych wiadomościach, tyle że w roli podpisującego występuje lekki klient. Weryfikacja bez odsiewania duplikatów to pół mostu.

Ryzyko mostów według założeń o zaufaniu: zewnętrzne zbiory walidatorów, progi multisig, lekkie klienty i weryfikacja optymistyczna, powtórzenia wiadomości i klucze aktualizacji

Klucze aktualizacji stoją nad każdym innym założeniem

Wszystko powyżej opisuje regułę, którą most egzekwuje dzisiaj. Klucz aktualizacji rozstrzyga, kto może tę regułę wymienić jutro.

Większość kontraktów mostowych to proxy, a ERC-1967 standaryzuje, gdzie proxy trzyma swoje okablowanie: jeden slot pamięci na adres implementacji, do której deleguje, drugi na adres admina uprawnionego do zmiany tej implementacji. Jedna transakcja od admina kieruje proxy na nowy kod, a nowy kod może definiować ważność, jak mu się podoba.

To czyni klucz aktualizacji nadzbiorem każdego innego ryzyka na tej stronie. Dziewięciokluczowy zbiór walidatorów, lekki klient, okno kwestionowania: wszystko to może wymienić ten, kto kontroluje slot admina. Uczciwy sufit bezpieczeństwa mostu to słabsze z dwojga: model weryfikacji albo ścieżka aktualizacji.

Pociechą jest to, że akurat to da się sprawdzić. Standard mówi, gdzie patrzeć, i wymaga, by zmiany tych slotów emitowały zdarzenia: Upgraded przy zmianie implementacji i AdminChanged przy zmianie admina. Odczytaj slot admina. Zobacz, czy trzyma pojedyncze konto zewnętrzne, multisig czy timelock, a jeśli timelock, to jak długie jest opóźnienie i kto może je anulować.

Pauzy i zmiany parametrów zasługują na tę samą lekturę. Prawo zatrzymania mostu albo podniesienia limitu przelewu jest mniejsze niż prawo przepisania reguł, ale to wciąż klucz w czyichś rękach, a most, który da się zatrzymać, da się zatrzymać w połowie twojego przelewu.

Podsumowanie

Ryzyko mostu układa się czysto, gdy zapytasz, kto weryfikuje. Zewnętrzny zbiór walidatorów to osobny system, którego próg jest jego budżetem bezpieczeństwa, a ten próg trzyma się tylko wtedy, gdy stojące za nim klucze mogą zawieść niezależnie. Lekkie klienty przenoszą założenie na konsensus łańcucha źródłowego i poprawność kodu klienta; konstrukcje optymistyczne na to, że przynajmniej jeden obserwator pozostanie żywy i nieskrępowany przez całe okno. Ochrona przed powtórzeniem to wymóg osobny: adresat musi być częścią tego, co podpisano, a każda wiadomość potrzebuje numeru sekwencyjnego albo potwierdzenia. Nad tym wszystkim stoi klucz aktualizacji, który jedną transakcją wymienia resztę. To tych pięć odpowiedzi, a nie marka w interfejsie, bierzesz na wiarę.

Zastrzeżenie: ten artykuł to treść edukacyjna Bitbase Academy, wyłącznie w celach informacyjnych. Nie stanowi porady inwestycyjnej, handlowej, podatkowej ani finansowej. Kryptoaktywa są zmienne — samodzielnie oceń ryzyko. Napisano w sierpniu 2026 r.; sprawdzaj aktualne oficjalne informacje.