Czym jest exploit mostu cross-chain i jak powstają takie ataki?

Czym jest exploit mostu cross-chain?

Exploit cross-chain bridge polega na wykorzystaniu podatności w bridge: infrastruktury, która umożliwia komunikację między różnymi blockchainami. Taka podatność może pozwolić atakującemu na przykład uwolnić tokeny bez ważnego depozytu, mintować tokeny bez wystarczającego zabezpieczenia albo wyprowadzić rezerwy z bridge.

Cross-chain bridge umożliwia przenoszenie tokenów, wiadomości lub innych danych między oddzielnymi blockchainami. Jest to potrzebne, ponieważ blockchain nie może automatycznie sprawdzić, co wydarzyło się na innym blockchainie.

Exploit może powstać w różnych miejscach. Może to być błąd w kontroli wiadomości, zbyt szerokie uprawnienia dostępu, podatność w smart contracts albo skradzione private keys walidatorów lub administratorów. W niektórych bridge'ach validators potwierdzają na przykład, że wiadomość z jednego blockchaina jest prawdziwa i ważna, zanim na drugim blockchainie zostanie wykonane jakiekolwiek działanie.

Warto wiedzieć, że bridge dodaje dodatkową warstwę bezpieczeństwa ponad blockchainami, z którymi się łączy. W przypadku niektórych bridge'ów polegasz na zewnętrznej grupie validators lub multisig. Inne bridge'e używają light clients i dowodów kryptograficznych, takich jak dowody Merkle, aby sprawdzić, czy transakcja lub zdarzenie rzeczywiście miały miejsce na drugim blockchainie. Model bezpieczeństwa, a więc i ryzyko, mogą się więc znacząco różnić w zależności od bridge.

Strona phishingowa podczas korzystania z bridge nie oznacza automatycznie exploita bridge. Taka strona może jednak skierować Cię do złośliwego kontraktu albo skłonić do podpisania niechcianej zgody, ale sam bridge nie musi być wtedy koniecznie złamany.

Najważniejsze informacje

• Cross-chain bridge umożliwia komunikację i transfer wartości między oddzielnymi blockchainami.
• Exploit bridge wykorzystuje techniczną lub operacyjną podatność w takim bridge.
• Atakujący mogą między innymi powodować nieautoryzowane wypłaty lub mintować tokeny bez wystarczającego zabezpieczenia.
• Weryfikacja wiadomości cross-chain jest ważnym punktem bezpieczeństwa bridge.
• Model bezpieczeństwa różni się w zależności od bridge i określa, jakie dodatkowe ryzyko ponoszą użytkownicy.

Jak działa cross-chain bridge?

Cross-chain bridge obserwuje zdarzenie na blockchainie źródłowym i po jego zweryfikowaniu wykonuje odpowiadającą mu akcję na blockchainie docelowym.

Załóżmy, że chcesz wysłać token z blockchaina A na blockchain B. Blockchain B nie może automatycznie sprawdzić, czy rzeczywiście wysłałeś ten token na blockchainie A. Dlatego bridge musi zaobserwować i zweryfikować zdarzenie na blockchainie A, zanim cokolwiek wydarzy się na blockchainie B.

Powszechnie stosowany model nazywa się lock-and-mint. Twoje oryginalne tokeny są wtedy blokowane na blockchainie źródłowym. Na blockchainie docelowym mintowany jest następnie wrapped token, czyli reprezentacja oryginalnego tokena. Gdy wracasz, wrapped token jest spalany, a pierwotne tokeny mogą zostać ponownie uwolnione.

Przykład: Blokujesz 1 token na blockchainie A. Po weryfikacji otrzymujesz 1 wrapped token na blockchainie B. Twój oryginalny token nie przenosi się więc dosłownie na blockchain B, lecz pozostaje zablokowany jako zabezpieczenie dla tokena, który otrzymujesz tam.

Inne podejście opiera się na pulach płynności. Po zweryfikowanej transakcji na blockchainie źródłowym pula na blockchainie docelowym może wypłacić równoważną ilość tokenów.

Kluczowym etapem jest zawsze weryfikacja. Bridge musi na przykład sprawdzić, czy wiadomość jest prawdziwa, czy pochodzi z właściwego blockchaina, czy spełnia odpowiednie warunki i czy nie została już wcześniej przetworzona. Sposób działania zależy od konkretnego bridge.

Niektóre bridge'e obsługują również generalised message passing. Mogą wtedy nie tylko przenosić tokeny, ale też przekazywać i wykonywać inne dane lub polecenia między blockchainami. Daje to więcej możliwości, ale może też zwiększać powierzchnię ataku.

Jakie modele bezpieczeństwa stosują bridge'e?

Nie każdy bridge w ten sam sposób decyduje, czy wiadomość jest ważna. Dlatego model bezpieczeństwa może się bardzo różnić.

Bridge może na przykład polegać na:

• Zewnętrznych validators lub multisig: grupa podmiotów podpisuje wiadomości, zanim zostaną wykonane na innym blockchainie.
• Light clients: jeden blockchain sprawdza informacje kryptograficzne o stanie drugiego blockchaina.
• Dowodach kryptograficznych: bridge używa na przykład dowodów Merkle lub innych konstrukcji kryptograficznych do potwierdzania zdarzeń.
• Weryfikacji optymistycznej: wiadomości są najpierw akceptowane, ale przez pewien czas inne strony mogą zakwestionować nieprawidłową wiadomość.

Te modele wiążą się z różnymi kompromisami. Zewnętrzna grupa validators może być na przykład prostsza, ale dodaje kolejną warstwę zaufania. Bridge, który kryptograficznie sprawdza zdarzenia, ma z kolei inne ryzyka techniczne. Samo słowo „bridge” mówi więc niewiele o tym, jak bezpieczny jest dany system.

Jak można zaatakować cross-chain bridge?

Atakujący zwykle próbuje obejść weryfikację bridge albo uzyskać możliwość zatwierdzenia nieprawidłowej wiadomości cross-chain.

Logika jest prosta: jeśli blockchain docelowy błędnie uzna, że na blockchainie źródłowym tokeny zostały zdeponowane lub zablokowane, bridge może na przykład mintować nowe tokeny albo uwalniać rezerwy bez wystarczającego zabezpieczenia.

Może się to wydarzyć na kilka sposobów:

• Błąd sprawia, że wiadomość bez dowodu lub sfałszowana wiadomość zostaje mimo to zaakceptowana.
• Atakujący zdobywa wystarczającą liczbę private keys validators, podpisujących w multisig lub administratorów.
• Błąd w smart contract pomija ważną kontrolę albo daje kontu zbyt szerokie uprawnienia.
• Weryfikacja dowodu kryptograficznego, takiego jak dowód Merkle lub dowód light-client, zawiera błąd.
• Błędna konfiguracja lub aktualizacja sprawia, że nieprawidłowe wiadomości są mimo to traktowane jako ważne.

Dowód Merkle to kompaktowy sposób kryptograficzny, który pozwala wykazać, że określone dane są częścią większego zbioru danych, na przykład danych w bloku. Jeśli bridge błędnie sprawdzi taki dowód, atakujący może sprawić, że zostanie zaakceptowane zdarzenie, które nigdy nie było ważne.

Nie każdy atak przebiega więc przez skradzione klucze i nie każdy bridge działa tak samo. Aby zrozumieć ryzyko, trzeba przyjrzeć się konkretnemu modelowi weryfikacji i bezpieczeństwa danego bridge.

Jakie podatności występują najczęściej?

Wiele ataków na bridge można ogólnie podzielić na kilka kategorii: błędy w uprawnieniach dostępu, błędy logiki, problemy z weryfikacją wiadomości oraz problemy z bezpieczeństwem operacyjnym.

Permission issues dotyczą tego, kto może wykonywać określone działania. Może się zdarzyć, że konto administracyjne ma zbyt szerokie uprawnienia, konta validators są niewystarczająco zabezpieczone albo uprawnienia można błędnie zmieniać. Szczególnie przy małej grupie validators lub multisig stanowi to duże ryzyko. Jeśli wystarczająca liczba podpisujących współpracuje lub zostanie przejęta, mogą autoryzować nieprawidłowe wypłaty.

Logic issues to błędy w zasadach działania smart contracts. Kontrakt może na przykład przetworzyć wiadomość bez sprawdzenia wszystkich warunków albo błędnie skonfigurować mint i uwolnienie środków. Mogą się tu też mieścić błędy podczas aktualizacji lub inicjalizacji kontraktu.

Message verification issues pojawiają się wtedy, gdy bridge nie sprawdza wystarczająco dokładnie, czy wiadomość cross-chain rzeczywiście jest ważna. Bridge może na przykład zaakceptować niewłaściwe źródło, błędnie sprawdzić dowód kryptograficzny albo wykonać wiadomość, która nigdy nie powstała jako ważna na blockchainie źródłowym.

Key management issues pojawiają się wtedy, gdy private keys validators, administratorów lub podpisujących w multisig zostają skradzione albo są niewystarczająco chronione. Smart contracts mogą działać technicznie poprawnie, a mimo to atakujący może tworzyć ważne podpisy przy użyciu skradzionych kluczy.

Znanym ryzykiem są też replay attacks. Polegają one na ponownym użyciu wcześniej ważnej wiadomości. Bridge musi więc sprawdzać, czy każda wiadomość może zostać przetworzona tylko raz. Pomóc może unikalny message ID, nonce lub hash.

Audyt może pomóc wykryć podatności, ale nie daje gwarancji, że bridge jest wolny od błędów. Zwłaszcza po aktualizacjach, zmianach ustawień lub modyfikacjach infrastruktury off-chain mogą pojawić się nowe ryzyka.

Jaką rolę odgrywają frontendy i phishing?

Nie każda strata podczas korzystania z bridge oznacza, że sam bridge został zaatakowany. Atakujący mogą też próbować oszukać użytkowników za pomocą fałszywej strony lub interfejsu.

Fałszywy interfejs może na przykład sprawić, że wyślesz transakcję do niewłaściwego smart contract albo zgodzisz się na użycie tokenów z Twojego walleta. Techniczna infrastruktura bridge może przy tym pozostać całkowicie nienaruszona.

Różnica jest ważna: w przypadku bridge exploit wykorzystywana jest słaba strona bridge lub otaczającej go infrastruktury. W przypadku phishingu użytkownik jest zwykle wprowadzany w błąd, aby sam zatwierdził szkodliwe działanie.

Jak private keys i smart contracts mogą odgrywać rolę?

Private keys i smart contracts są ważnymi elementami wielu bridge. Problem w jednym z nich może mieć już poważne skutki.

Private key to tajny klucz, który służy do tworzenia transakcji lub podpisów kryptograficznych. Jeśli bridge wykonuje wypłatę dopiero po podpisaniu przez kilku validators, pojawia się duże ryzyko, gdy atakujący zdobędzie wystarczającą liczbę takich kluczy. Może wtedy zatwierdzać fałszywe polecenia bridge tak, jakby były legalne.

Multisig wymaga podpisu kilku stron, zanim działanie zostanie wykonane. Może to być bezpieczniejsze niż jedno konto administracyjne, ale nie oznacza automatycznie pełnego bezpieczeństwa. Próg podpisów musi być dobrze dobrany, podpisujący muszą być wystarczająco niezależni, a private keys muszą być dobrze chronione.

W przypadku ataku na Ronin Bridge w marcu 2022 roku przejęto wystarczającą liczbę kluczy validators, aby zatwierdzać nieautoryzowane wypłaty. Ostatecznie z bridge wyprowadzono 173.600 ETH i 25,5 miliona USDC. Następnie zmieniono projekt bridge i wprowadzono dodatkowe środki bezpieczeństwa.

W przypadku incydentu Harmony Horizon Bridge w czerwcu 2022 roku przejęto co najmniej dwa z czterech private keys bridge validators. Harmony poinformowało, że nie było dowodów na to, iż smart contracts bridge lub sam protokół blockchain zostały naruszone. Incydent pokazuje, że bridge można złamać bez konieczności wystąpienia błędu w on-chain contract.

Smart contracts stanowią z kolei on-chain zasady działania wielu bridge. Sprawdzają na przykład podpisy lub dowody kryptograficzne, a następnie wykonują działania, takie jak mintowanie, spalanie, blokowanie lub uwalnianie tokenów. Jeśli te kontrole są źle zaprojektowane lub zaimplementowane, atakujący może czasem stworzyć tokeny albo wypłacić rezerwy bez ważnej transakcji bazowej.

Dobra ochrona wymaga więc zarówno bezpiecznych smart contracts, jak i silnego zarządzania kluczami.

Jakie są skutki exploita cross-chain bridge?

Exploit cross-chain bridge może spowodować zniknięcie rezerw, opróżnienie pul płynności albo utratę pełnego pokrycia wrapped tokenów.

To ostatnie może mieć duże konsekwencje. W przypadku bridge typu lock-and-mint wrapped token powinien być zwykle zabezpieczony rezerwami na innym blockchainie. Jeśli to zabezpieczenie zniknie, możliwość wymiany wrapped tokena na oryginalny asset może zostać zagrożona. Może to też dotknąć protokoły, w których token jest używany jako zabezpieczenie, instrument handlowy lub płynność.

Zespoły projektowe mogą czasem tymczasowo wstrzymać bridge, aby ograniczyć dalsze szkody. Po exploicie Nomad w sierpniu 2022 roku na przykład wstrzymano dalsze przetwarzanie, gdy błąd w inicjalizacji pozwalał traktować nieprawidłowe wiadomości jako ważne. W tym incydencie wyprowadzono z bridge około 190 milionów dolarów w aktywach.

W przypadku exploita BNB Chain Token Hub w październiku 2022 roku użyto sfałszowanego dowodu kryptograficznego, co pozwoliło stworzyć około 2 miliony dodatkowych BNB. BNB Chain skoordynował działania z validators, aby tymczasowo zatrzymać blockchain i ograniczyć dalsze szkody. Dzięki temu duża część zaangażowanych BNB pozostała pod kontrolą.

Transakcji blockchain zwykle nie da się po prostu cofnąć przez centralny podmiot, jak na przykład tradycyjnego przelewu bankowego. Nie oznacza to jednak, że nigdy nie można zareagować. W zależności od sieci validators, zespoły projektowe, emitenci tokenów lub governance mogą czasem podjąć działania, aby zatrzymać dalsze transakcje, zablokować aktywa lub wdrożyć inne środki naprawcze.

Tymczasowe wstrzymanie może ograniczyć dalsze szkody, ale ma też wady. Użytkownicy mogą przez pewien czas nie móc korzystać z bridge ani odzyskać swoich tokenów. Ponadto awaryjne zatrzymanie oznacza, że określeni administratorzy, validators lub guardians mają wpływ na spowolnienie lub zatrzymanie części systemu.

To, czy użytkownicy otrzymają rekompensatę po exploicie, nie jest pewne. Zależy to między innymi od dostępnych rezerw, ubezpieczenia, decyzji projektu, governance oraz od tego, czy skradzione środki uda się odzyskać.

Duży exploit bridge może też osłabić zaufanie do projektu lub bridged asset. Może to wpłynąć na płynność i potencjalnie także na cenę rynkową, ale efekt zależy od konkretnego incydentu i warunków rynkowych.

Poza bezpośrednią stratą finansową bridge może więc przez długi czas być mniej użyteczny. Płynność może spaść, wrapped tokeny mogą być trudniejsze do wymiany, a użytkownicy mogą z większą ostrożnością podchodzić do ponownego korzystania z bridge.

Jakie znane exploity cross-chain bridge miały miejsce?

Doszło do kilku dużych exploitów bridge. Techniczna przyczyna była w każdym przypadku inna.

• Poly Network: w sierpniu 2021 roku w Poly Network przeniesiono kryptowaluty o wartości ponad 600 milionów dolarów po wykorzystaniu infrastruktury cross-chain. Duża część środków została później zwrócona.
• Wormhole: w lutym 2022 roku wykorzystano podatność w Wormhole na Solanie, aby stworzyć wrapped ETH bez wymaganego zabezpieczenia bazowego. Atakujący przeniósł następnie część aktywów na Ethereum.
• Ronin Bridge: w marcu 2022 roku przejęto klucze validators, co pozwoliło atakującemu zatwierdzać nieautoryzowane wypłaty. Łącznie z bridge wyprowadzono 173.600 ETH i 25,5 miliona USDC.
• Harmony Horizon Bridge: w czerwcu 2022 roku przejęto co najmniej dwa private keys bridge validators. W incydencie skradziono około 100 milionów dolarów w kryptowalutach.
• Nomad: w sierpniu 2022 roku błąd związany z inicjalizacją kontraktu Replica sprawił, że niezweryfikowane wiadomości mogły być traktowane jako ważne. Dzięki temu różne adresy mogły kopiować transakcje i wyprowadzać aktywa z bridge. Łączna strata wyniosła około 190 milionów dolarów.
• BNB Chain Token Hub: w październiku 2022 roku zaatakowano natywny bridge między BNB Beacon Chain a BNB Smart Chain. Dzięki sfałszowaniu low-level proof można było stworzyć około 2 miliony dodatkowych BNB.

Kwoty przy takich incydentach trzeba jednak rozpatrywać w kontekście. Podana wartość może odnosić się do wartości rynkowej zmintowanych tokenów, faktycznie wyprowadzonych rezerw, tymczasowo zablokowanych aktywów albo kwot odzyskanych później. Ponieważ ceny kryptowalut się zmieniają, raportowana wartość w dolarach może się różnić w zależności od momentu pomiaru.

Jak można zapobiegać exploitom cross-chain bridge?

Exploitów cross-chain bridge nie da się całkowicie wyeliminować, ale kilka niezależnych warstw bezpieczeństwa może zmniejszyć szansę udanego ataku i ograniczyć maksymalne szkody.

Podstawą jest ścisła weryfikacja. Bridge powinien między innymi sprawdzać, skąd pochodzi wiadomość, czy jest ważna, do jakiego działania jest przeznaczona i czy nie została już wcześniej użyta. Dopiero potem kontrakt może na przykład mintować tokeny albo uwalniać rezerwy.

Znaczenie ma też model zaufania. Bridge zależny od małej zewnętrznej grupy validators lub multisig ma inny profil ryzyka niż bridge, który weryfikuje informacje cross-chain na przykład za pomocą light clients. Żaden projekt nie jest całkowicie wolny od ryzyka.

Pomóc mogą również środki ograniczające maksymalne szkody:

• Rate limits ograniczają, ile wartości można przenieść w określonym czasie.
• Limity wypłat wyznaczają maksymalną kwotę wypłat.
• Circuit breakers mogą automatycznie spowolnić lub zatrzymać nietypową aktywność.
• Funkcje pauzy mogą tymczasowo wstrzymać określone działania bridge podczas incydentu.
• Monitoring może szybciej wykrywać wyjątkowo duże lub nietypowe wiadomości bridge.

Taki hamulec awaryjny nie usuwa samej podatności. Może jednak zapobiec temu, by atakujący w krótkim czasie wyprowadził wszystkie dostępne rezerwy.

Audyt, bug bounty, code review i szeroko zakrojone testy są również ważne. Najlepiej działają w połączeniu z ciągłym monitoringiem, bezpiecznym zarządzaniem kluczami i wcześniej przygotowanym planem reagowania na incydenty.

Jakie środki bezpieczeństwa mogą wdrożyć deweloperzy?

Deweloperzy mogą ograniczyć ryzyko, jeśli od początku rygorystycznie zaprojektują weryfikację, uprawnienia dostępu, zarządzanie kluczami i środki awaryjne.

1. Sprawdzaj każdą wiadomość w całości. Kontroluj między innymi blockchain źródłowy, nadawcę, nonce lub unikalny message ID, cel oraz dozwoloną funkcję. Dzięki temu unikniesz sytuacji, w której wiadomość pochodzi z niewłaściwego źródła albo zostaje ponownie użyta do innego działania.

2. Wbuduj ochronę przed replay. Oznacz przetworzoną wiadomość jako używaną i nie akceptuj jej ponownie. Pomaga to chronić przed replay attacks, w których to samo polecenie jest wykonywane wielokrotnie.

3. Nadaj jak najmniej uprawnień. Stosuj zasadę least privilege. Nie każde konto musi móc aktualizować kontrakty, zmieniać validators, mintować tokeny ani aktywować awaryjnego zatrzymania. Im mniej uprawnień ma jedno konto, tym mniejsze potencjalne szkody po jego przejęciu.

4. Zabezpiecz konta administracyjne za pomocą multisig. W przypadku wrażliwych działań administracyjnych używaj tam, gdzie to właściwe, kilku niezależnych podpisujących zamiast jednego externally owned account z jednym private key. Multisig jest jednak użyteczny tylko wtedy, gdy podpisujący i ich klucze są rzeczywiście wystarczająco niezależni.

5. Użyj timelock dla ryzykownych zmian. Timelock wprowadza czas oczekiwania przed wykonaniem aktualizacji lub decyzji governance. Dzięki temu zmiany można wcześniej sprawdzić, a podejrzaną aktywność łatwiej zauważyć.

6. Testuj więcej niż tylko normalną ścieżkę. Zlecaj niezależne audyty, ale testuj też aktualizacje, inicjalizację, błędne dane wejściowe, przypadki brzegowe i weryfikację dowodów. Exploit Nomad pokazuje, jak poważne mogą być skutki błędu przy aktualizacji lub inicjalizacji.

7. Przygotuj wcześniej reakcję na incydent. Używaj monitoringu, wykrywania odchyleń, rate limits i tam, gdzie to właściwe, kontrolowanego zatrzymania awaryjnego. Z góry ustal, kto może interweniować, jakie działania są możliwe i jak komunikować się podczas incydentu.

8. Starannie zarządzaj private keys. Przechowuj klucze validators i administratorów oddzielnie oraz odpowiednio je zabezpieczaj. Ustal też procedury, które pozwolą kontrolowanie dodawać, usuwać i zastępować podpisujących.

Audyt lub bug bounty nie są przy tym gwarancją bezpieczeństwa. Nowe aktualizacje, off-chain relayers, zmiany konfiguracji i codzienne bezpieczeństwo private keys pozostają osobnymi ryzykami.

Jak użytkownicy mogą ograniczyć ryzyko?

Jako użytkownik nie możesz samodzielnie ustalić bezpieczeństwa bridge, ale możesz ograniczyć ryzyko, jakie bierzesz na siebie przez korzystanie z bridge.

1. Sprawdź model zaufania. Zobacz, z jakiego bridge korzystasz i jak weryfikowane są wiadomości cross-chain. Sprawdź na przykład, czy używana jest zewnętrzna grupa validators, multisig, light client lub inny model weryfikacji.

2. Korzystaj z właściwego interfejsu. Otwieraj bridge przez zaufany i zweryfikowany kanał projektu. Zanim podpiszesz transakcję, sprawdź między innymi URL, blockchain, adres odbiorcy i token, który wysyłasz.

3. Nie podpisuj bez sprawdzenia. Sprawdź, co robi transakcja lub wiadomość, zanim ją podpiszesz. Blind signing może narazić Cię na phishing, złośliwy kontrakt lub niechciane uprawnienia.

4. Ogranicz token approvals. Jeśli to możliwe, nadaj zgodę tylko na kwotę, która jest potrzebna. Token approval może pozostać aktywny on-chain, dopóki nie zostanie zmieniony lub cofnięty.

5. Cofaj nieużywane approvals. Sprawdzaj stare spending caps i cofaj je, jeśli nie są już potrzebne. Samo odłączenie Twojego crypto wallet od dApp nie usuwa istniejących token approvals.

6. Ogranicz ekspozycję. Mała transakcja testowa może pomóc sprawdzić na przykład adres, interfejs i wybraną trasę. Taki test nie dowodzi jednak, że sam bridge jest bezpieczny.

7. Pamiętaj o ryzyku bridged tokenów. Po exploicie wrapped tokeny mogą być tymczasowo trudne do wymiany lub mniej płynne. Im dłużej i im większa wartość zależy od jednego bridge i jego rezerw bazowych, tym większa ekspozycja na to konkretne ryzyko bridge.

Przed użyciem bridge sprawdzaj też aktualne oficjalne komunikaty o incydentach i ostrzeżenia bezpieczeństwa.

Podsumowanie

Cross-chain bridge umożliwia wymianę tokenów, wiadomości i innych danych między blockchainami, ale jednocześnie dodaje dodatkową warstwę bezpieczeństwa. Podatności mogą powstawać między innymi w weryfikacji wiadomości cross-chain, uprawnieniach dostępu, private keys, konfiguracji i smart contracts.

Skutki mogą być poważne, ponieważ bridge często zarządzają znacznymi ilościami kryptowalut albo odpowiadają za pokrycie wrapped tokenów. Incydenty w takich projektach jak Poly Network, Wormhole, Ronin, Harmony, Nomad i BNB Chain pokazują też, że exploity bridge mogą powstawać na bardzo różne sposoby.

Dla deweloperów dobra ochrona oznacza więc kilka niezależnych warstw: ścisłą weryfikację, ochronę przed replay, ograniczone uprawnienia administracyjne, bezpieczne zarządzanie kluczami, monitoring i przygotowany plan reagowania na incydenty. Dla użytkowników najważniejsze jest zrozumienie, jaki model zaufania stosuje bridge, sprawdzenie właściwego interfejsu i uwzględnienie dodatkowego ryzyka związanego z bridged assets.

Bridge odgrywają ważną rolę w ekosystemie wielu blockchainów, ale nie są pozbawione ryzyka. Im lepiej rozumiesz, jak bridge sprawdza zdarzenia na innym blockchainie i od jakich stron lub systemów zależy ta weryfikacja, tym lepiej możesz ocenić jego model bezpieczeństwa.