IoTeX je nastao 2017. kao projekt fokusiran na spajanje interneta stvari (IoT) i blockchaina, s idejom da milijarde uređaja mogu sigurno komunicirati i razmjenjivati podatke te vrijednost. Riječ je o Layer 1 protokolu koji koristi vlastiti konsenzus i infrastrukturu, ali je snažno oslonjen na mostove (bridgeve) prema drugim mrežama poput Ethereum ekosustava. Upravo su ti bridge ugovori sada u središtu incidenta koji je uzdrmao povjerenje u sigurnost IoTeX-a.
Prema izjavama suosnivača projekta, napad u kojem je s nekoliko bridge ugovora odvučeno oko 2 milijuna dolara povezan je s kompromitacijom privatnog ključa. To znači da ranjivost nije bila u samom kodu pametnog ugovora, već u načinu na koji je upravljano ključevima koji imaju ovlasti nad tim ugovorima. Ovakav scenarij posebno je opasan jer napadaču daje ista prava kao legitimnim operatorima infrastrukture.
Za IoTeX, koji gradi mostove prema drugim lancima kako bi omogućio prijenos vrijednosti i interoperabilnost, ovaj incident pogađa samu srž njihove sigurnosne arhitekture. Ako ključ kojim se upravlja bridgeom bude kompromitiran, cijeli mehanizam zaključavanja i izdavanja tokena može biti zaobiđen – čak i ako je pametni ugovor formalno ispravan.
Što se dogodilo: kompromitacija privatnog ključa umjesto klasičnog hacka koda
Prema javno dostupnim informacijama i izjavama iz tima, napad nije iskoristio tipičnu grešku u pametnom ugovoru, poput reentrancy buga ili pogrešne validacije ulaznih parametara. Umjesto toga, iskorišten je privatni ključ koji je imao kontrolu nad određenim bridge ugovorima. To implicira da je napadač uspio potpisivati transakcije kao ovlašteni entitet.
Takva situacija obično znači jedno od sljedećeg: loše zaštićen ključ (npr. pohranjen na serveru bez HSM-a), kompromitirano razvojno okruženje ili interni propust (namjerni ili nenamjerni). Za razliku od uobičajenih DeFi napada, gdje je moguće zakrpati kod i vratiti sigurnost, kompromitirani ključ zahtijeva kompletno rotiranje ključeva i reviziju cijelog operativnog procesa.
Iznos koji je povučen iz bridge ugovora inicijalno je procijenjen na oko 2 milijuna dolara, iako su rane procjene u zajednici sugerirale potencijalno veći iznos. Ovaj nesrazmjer u brojkama tipičan je u prvim satima nakon incidenta: alati za praćenje lanca često zbrajaju ukupnu vrijednost ugovora, a ne stvarno povučena sredstva. Ključno je da je tim javno priznao problem s ključem, što snažno usmjerava fokus na pitanja upravljanja ovlastima.
Za korisnike koji su most koristili za prijenos vrijednosti između IoTeX lanca i drugih mreža, incident otvara pitanje: jesu li njihovi wrapped tokeni u potpunosti pokriveni kolateralom na drugoj strani mosta ili postoji manjak koji stvara refleksni rizik na cijeli ekosustav.
Kako funkcioniraju bridge ugovori i gdje nastaje single point of failure
Bridge ugovori obično funkcioniraju po principu zaključavanja i izdavanja. Kada korisnik šalje, primjerice, tokene s Layer 1 lanca A na lanac B, pametni ugovor na lancu A zaključava originalne tokene, dok bridge infrastruktura na lancu B izdaje ekvivalentne wrapped tokene. U idealnom slučaju, ovaj proces je maksimalno decentraliziran, uz korištenje multisig ili even threshold kriptografije (npr. TSS – Threshold Signature Scheme).
U praksi, međutim, mnogi bridgevi, osobito u ranim fazama razvoja projekata srednje veličine, imaju operativno središte moći u obliku jedne adrese ili malog broja validatora. Ako je jedan privatni ključ taj koji potpisuje ključne administrativne transakcije (poput promjene parametara, povlačenja sredstava ili emitiranja tokena), tada taj ključ postaje kritičan single point of failure.
Kod IoTeX bridge ugovora upravo je taj sloj upravljanja ključevima došao u fokus. Čak i ako su sam pametni ugovor i on-chain logika formalno verifikirani, činjenica da privatni ključ ima dovoljno ovlasti za pomicanje sredstava predstavlja najveći rizik. To je tipični problem operativne sigurnosti, a ne čiste on-chain logike.
Tehnički rizici: od key managementa do likvidnosti wrapped tokena
Prvi ključni rizik je centralizirani key management. Ako privatni ključ kojim se upravlja bridge ugovorima nije pohranjen u HSM-u ili sličnom rješenju (npr. MPC novčanici), već na standardnom serveru ili development računalu, svaki kompromis tog sustava izravno vodi do potpune kontrole nad sredstvima. Čak i kad se koristi multisig, konfiguracije poput 2-of-3, gdje su dva ključa pod kontrolom iste organizacije, i dalje predstavljaju koncentrirani rizik.
Drugi ozbiljan rizik vezan je za likvidnost wrapped tokena. Ako napad rezultira povlačenjem znatnog dijela kolaterala sa strane originalnih tokena, wrapped tokeni na drugoj strani postaju djelomično ili potpuno neosigurani. To može uzrokovati nagli pad njihove tržišne cijene na decentraliziranim burzama, likvidacijski val na DeFi protokolima koji ih prihvaćaju kao kolateral i lančanu reakciju gubitka povjerenja u cijeli ekosustav.
Treći sloj rizika je reputacijski i regulatorni. Incidenti povezani s kompromitacijom ključeva često se promatraju strože od “običnih” bugova u kodu, jer impliciraju propust u internim procesima i procedurama. Regulatori mogu ovakve slučajeve razmatrati u kontekstu nedovoljne zaštite korisničke imovine, što može utjecati na projekte koji ciljaju RWA integracije ili suradnju s institucionalnim ulagačima.
Širi kontekst: usporedba s drugim bridge incidentima i lekcije za industriju
IoTeX nije prvi projekt koji se suočava s kompromitacijom infrastrukture povezane s bridgevima. U posljednjih nekoliko godina više je velikih mostova između lanaca pretrpjelo napade, pri čemu je zajednički nazivnik često upravo slab key management ili prevelika ovlast administrativnih adresa. Razlika je u tome što je IoTeX već pozicioniran kao mreža koja želi biti temelj za IoT uređaje, gdje su sigurnost i integritet podataka posebno kritični.
Za razliku od nekih napada gdje je eksploatiran složen bug u verifikaciji poruka između lanaca, ovdje je, prema onome što je objavljeno, iskorišteno to što je jedan ključ imao dovoljno široke privilegije. Industrija već duže vrijeme gura prema rješenjima poput MPC novčanika i distribuiranih validatora, gdje se nikad ne formira jedna kompletna privatna kombinacija, što bi smanjilo mogućnost ovakvog incidenta.
Primjeri naprednijih bridge arhitektura, poput onih koje koriste light client verifikaciju ili zk-proofove, pokazuju da se rizik može premjestiti s povjerenja u ključeve na kriptografske dokaze. No, to dolazi s vlastitim ograničenjima – većom kompleksnošću implementacije, višim troškovima i težim auditiranjem. IoTeX incident tako ponovno otvara staru raspravu: koliko centralizacije je prihvatljivo u ranoj fazi projekta i gdje povući granicu u ovlastima administratora.
Zaključak
Incident s IoTeX bridge ugovorima, u kojem je prema izjavama tima kompromitiran privatni ključ i povučeno oko 2 milijuna dolara, još jednom potvrđuje da su upravljanje ključevima i dizajn ovlasti kritična točka svakog cross-chain sustava. S tehničke strane, pokazuje da ni savršeno napisan pametni ugovor ne znači puno ako jedna adresa ima preveliku kontrolu nad sredstvima.
Glavne prednosti ovakvih bridge rješenja – jednostavno premošćivanje likvidnosti i pristup različitim lancima – dolaze uz cijenu dodatnog sloja rizika: od centraliziranog key managementa, preko moguće nelikvidnosti wrapped tokena, do reputacijskog udara u slučaju incidenta. S druge strane, projekti koji usvoje robusnije modele (multisig s distribuiranim kontrolerima, MPC, zk-based verifikacija) mogu značajno smanjiti ovaj napadni vektor, uz cijenu veće složenosti.
Tema je posebno relevantna za korisnike koji aktivno koriste bridgeve, operatore infrastrukture, te timove koji razvijaju nove Layer 1 i interoperabilne protokole. Za njih je IoTeX slučaj konkretna studija: bez rigorozne operativne sigurnosti ključeva, sav trud uložen u on-chain logiku i performance mreže može u jednom danu biti zasjenjen kompromitacijom jedne jedine točke – privatnog ključa.
