A februári Moonwell incidens jól megmutatta, hogy AI-val támogatott fejlesztésnél a kockázat többnyire nem az eszköz hibája, hanem a folyamatoké: milyen változtatás kerülhet be, milyen ellenőrzéseken megy át, ki és hogyan hagyja jóvá. Az esetet többek között egy auditor X posztja hozta nyilvánosságra , majd több forrás is összefoglalta, hogy a hibás árazás láncreakciót indított, és a protokollban nagyjából 1,8 millió dollárnyi veszteség keletkezett.
Ebben a hírlevélben két doogról lesz szó:
- Mi a technikai háttér,
- Milyen governance és kontrollpontokkal lehet az AI-val gyorsított fejlesztést biztonságosan működtetni, hogy a minőségbiztosítás ne maradjon le a szállítási tempótól
Fogalmi háttér a pontos értelmezéshez
cbETH
A cbETH a Coinbase által kibocsátott olyan token, amely az ETH lekötéséhez kapcsolódik. A lekötésért jutalom jár, ezért az átváltási arány idővel változhat, vagyis ugyanannyi cbETH mögött idővel több ETH-értékű fedezet állhat. Ebből következik, hogy a cbETH értéke nem egyszerűen egy darab ETH árfolyama, hanem egy összetettebb kapcsolat az átváltási arány és az ETH piaci ára között .
Miért fontos ez? Mert amikor egy rendszer cbETH-t fogad fedezetként, hitelkeretet számol, vagy likvidálási küszöböket néz, akkor a cbETH árának meghatározása tipikusan több információ összekapcsolására épül. Ha ebből a láncból egy elem hiányzik, vagy a rendszer rossz adatforrásra támaszkodik, akkor hibás árat fog látni, és a kockázati logika is hibásan fog működni.
Solidity és okosszerződés
A Solidity az egyik leggyakrabban használt programozási nyelv az Ethereumhoz hasonló blokkláncokon futó okosszerződésekhez. Ezeknél a rendszereknél a kód nem egy háttérben futó alkalmazáslogika, hanem maga a pénzügyi működés: fedezetet tart nyilván, kamatot számít, hiteleket kezel, pozíciókat zár, és szükség esetén automatikusan likvidál.
Ezért az árazáshoz vagy az árfolyamadatokhoz kapcsolódó hibák nem úgy jelentkeznek, mint egy hagyományos szoftvernél, ahol legfeljebb lassan romlik a felhasználói élmény. Itt egy rossz beállítás vagy hibás számítás rövid időre olyan helyzetet hozhat létre, amelyet automatizált szereplők azonnal ki tudnak használni.
PR, commit és kódellenőrzés
A pull request, röviden PR egy olyan javasolt kódváltoztatás, amelyet a csapat általában csak ellenőrzés után enged be a fő kódbázisba. A review, vagyis a kódellenőrzés célja, hogy még az élesítés előtt kiderüljenek a logikai hibák, a kockázatos mellékhatások, illetve az olyan változtatások, amelyek egy későbbi incidens alapját jelenthetik.
A commitok a fejlesztés apróbb lépéseit rögzítik, a commit történet pedig visszakövethetővé teszi, hogy pontosan mikor és mi változott. Ebből sokszor az is látszik, milyen eszközökkel és milyen munkafolyamatban készült a módosítás. Ennél az esetnél az auditor arra hívta fel a figyelmet, hogy a fejlesztési nyomok között AI-közreműködésre utaló jelölések is megjelentek.
Ettől még a felelősség nem az eszközé, hanem a folyamaté. A döntő kérdés az, hogy a kritikus változtatásokat milyen jóváhagyási szabályok és ellenőrzési pontok védik, és ezek a kontrollok képesek-e lépést tartani azzal, hogy AI-val gyorsabban készülnek a módosítások.
Mi történt a Moonwell esetében?
A beszámolók szerint egy governance által jóváhagyott változtatás végrehajtásakor a cbETH oracle konfigurációja hibásan lett beállítva. A rendszer a cbETH árát lényegében csak a cbETH per ETH arányból vezette le, miközben a helyes USD árképzéshez az ETH USD árát is be kellett volna vonni, vagyis egy összetett, több lépcsős árazást kellett volna használni .
Ennek következménye az lett, hogy a cbETH ára rövid időre extrém módon félreárazódott. A botok a protokoll szabályai szerint azonnal reagáltak a rossz árra, és tömeges likvidálási események indultak, amelyek végül körülbelül 1,78 millió dollárnyi rossz adósságot hagytak a rendszerben .
Fontos részlet, hogy ez miért történik ennyire gyorsan. DeFi környezetben a likvidáció nem kézi folyamat, hanem automatizált verseny: a botok folyamatosan figyelik a feltételek teljesülését, és millisekundumok alatt lépnek, ha a rendszer szerint egy pozíció likvidálható. Ha az oracle rossz árat ad, a botok a protokoll logikáját követik, és ez üzletileg azonnali veszteséget okozhat.
Hol jön be ebbe az AI, és miért lett belőle vita?
A vita lényege nem az, hogy az AI elrontotta. A vita arról szól, hogy AI-val támogatott fejlesztésnél a változtatások száma és tempója nő, a konfigurációk és integrációk komplexitása is nő, és ha a review, a tesztelés, valamint az ellenőrzési pontok nem erősödnek vele együtt, akkor nagyobb eséllyel csúszik át hiba.
A kommentekben is megjelent egy józan megállapítás: a döntést és a jóváhagyást végül mindig ember hozza meg, adott esetben auditor is részt vesz benne, mégis megtörténhet az incidens. Ez a gondolat különösen aktuális akkor, amikor a fejlesztés egy része már nagyban támaszkodik generatív AI-ra, és a csapat elkezd ráállni arra a ritmusra, hogy gyorsabban lehet haladni, mint amennyire a kontrollrendszer fel van készítve.
A másik fontos adalék, hogy a nyilvános összefoglalók szerint voltak tesztek, és audit is felmerült, mégsem fogták meg ezt a hibamódot. Ez azért lényeges, mert azt mutatja: nem elég a tesztek léte. Kritikus rendszereknél az a kérdés, hogy a tesztek és ellenőrzések célzottan lefedik-e azokat a hibamódokat, amelyeknél a kár azonnal realizálódik, például árképzés, oracle összekapcsolások, feed kiválasztás, szélsőértékek kezelése.
Governance tanulság: AI-val gyorsított fejlesztéshez külön kontrollréteg kell
Ha AI segít kódot írni, konfigurációt módosítani vagy integrációt összerakni, akkor a governance szerepe felértékelődik. Itt a governance nem dokumentumgyártást jelent, hanem működési biztonságot, azaz olyan döntési pontok és ellenőrzések rendszerét, amelyek csökkentik annak esélyét, hogy kritikus hiba átcsússzon.
Néhány kérdés, amit érdemes intézményesen tisztázni:
- Mely komponensekben megengedett AI-javaslatok közvetlen átvétele, és hol kötelező a szigorított felülvizsgálat, például árazás, jogosultságkezelés, pénzügyi logika, oracle réteg
- Mi számít kötelező, kétlépcsős review-nak, és milyen ellenőrzőlista alapján történik
- Hogyan igazoljuk, hogy a változtatás a kritikus hibamódokra is tesztelt, ideértve a negatív teszteket és a reális tartományellenőrzést
- Hogyan kezeljük az auditok korlátait, például audit scope, audit utáni módosítások, konfigurációs változások
- Milyen traceability szükséges, vagyis mi változott, ki hagyta jóvá, milyen automatikus ellenőrzések futottak le
Ehhez kapcsolódóan letölthető a Cubix AI Governance Checklist, amely kifejezetten azt foglalja össze, milyen területeken érdemes döntést hozni, mielőtt nagy nyelvi modelleket vagy GenAI megoldásokat integráltan használtok a szervezeti működésben .
A checklist itt érhető el: https://landing.cubixedu.com/ai-governance-checklist/?utm_source=blog&utm_medium=cikk
Miért foglalkozunk ezzel a Cubixnál?
Mert a fejlesztési sebesség és a biztonság közötti feszültség most új szintre került. Ezért készül nálunk hamarosan AI security fókuszú képzés is, amely az AI-assisted fejlesztés kockázatait, tipikus hibamódjait és a szükséges kontrollpontokat rendszerezetten tárgyalja — nem elméleti, hanem vállalati működésben alkalmazható megközelítéssel.
Addig is nézz szét AI képzéseink között: https://cubixedu.com/kepzesek/kategoria/mesterseges-intelligencia?direction=asc&utm_source=blog&utm_medium=cikk
