Biztonság vs. Biztosítás
Az INLOCK platform kapcsán a likviditás mellett talán a legfontosabb kérdés minden kétséget kizárólag a platform biztonsága. Ennek kapcsán született az alábbi kérdés telegramon:
Biztonság tekintetében milyen fejlesztések vannak, lesznek? Gondolok itt arra ha feltorik az inlock fiókomat. Van valamiféle biztosítás, kártalanítás ha ez mégis megtortenik? Tudom, van 2FA, de binancenél is volt, mégis feltortek tavaly.
Nézzük mit sikerült erre válaszolnom. Előbb a konkrét párhuzamot próbáltam kontextusba helyezni:
Ez a kérdés biztosan komplexebb, minthogy egy gyors válasszal elintézzük. Mindazonáltal azt had jegyezzem meg, hogy a történelem már sokszor rácáfolt arra, hogy a “nagy hatalomhoz nagy felelősség jár”, erre tökéletes példa a Binance esete. A Binance feltörése a binance-t minősíti, nem pedig bennünket, ugyanígy nem minősít bennünket az a tény sem, hogy sok más exchange sértetlensége (pl. Kraken, Liquid) éveken keresztül is kikezdhetetlen volt. Mi nem ezektől vagyunk jobbak vagy rosszabbak.
Amúgy is már régóta tervezünk megjelentetni egy jelentősebb leírást arról, hogy az INLOCK milyen módon védi az ügyfelek vagyonát, így ezt a topicot szerintem előre vesszük. Addig is röviden leírnám, hogy mi minden történik ennek kapcsán.
Az ügyfelek oldaláról jelenleg elérhető már a Google2FA támogatás, ehhez jött hozzá idén januárban egy fraud management rendszer, amibe már néhány INLOCK felhasználó sikeresen bele is ütközött. Ez a rendszer hivatott arra, hogy automatizáltan ellenőrizzen minden kimenő utalást. Nem szeretnék erről részelteket megosztani, mivel az algoritmus igen komoly érték, de röviden a lényege: a kiutalásokkor értékeli az algoritmus, hogy az aktuális kiutalás milyen szinten illik bele mind az adott ügyfél, mind a hasonló műveleteket végőz ügyfelek szokásos tranzakcióiba és ha bármilyen szokatlan dolgot tapasztal, akkor felfüggeszti az automatikus kiutalást és felkéri az ügyfelet, hogy vegye fel a kapcsolatot a compliance csapattal. Ezt követően csak MANUÁLIS jóváhagyás után történhet meg a folyósítás. Erős a gyanúm, hogyha hasonló védelemmel rendelkezett volna pl a fentebb említett Binance, akkor nem történt volna meg a támadás. Hiszen a Binance közleménye szerint nem az ő rendszerük kompromittálódott, hanem az ügyfeleink az API kulcsai, amin keresztül hajtották végre a támadást. Persze a sztori azért kicsit sántít, hiszen ha tényleg az ügyfelek hibáztak, akkor mégis miért kártalanították azokat…
Majd nyilván illő módon választ adta az INLOCKot érintő konkrét kérdésre is:
Az INLOCK oldaláról ehhez nagyon sok olyan egyéb védelem tartozik hozzá, amiket most kifejteni eléggé körülményes lenne. Ami talán a legfontosabb ezek közül: Az INLOCKon belül egy olyan UTXO modellhez hasonlító (UUB) rendszer van, ahol egy ügyfél még egy esetleges rendszerhibából vagy sérülékenységből sem tudhat elkölti/elutalni/felhasználni olyan pénzt, amivel nem rendelkezik.
Ez a gyakorlatban annyit tesz, hogy bár blockchain szinten a custody (letét) jellemzően csoportosítva van tárolva (persze szeparálva bizonyos szinteken… de erről később), viszont az alkalmazáslogikában ezek nem csak nyilvántartás szinten, de logikailag is el vannak szeparálva. Egy belső tranzakció esetén soha sem az a fontos, hogy a nyilvántartás szerint mennyi értékkel (pl. Bitcoin vagy ILK token) rendelkezik az ügyfél, hanem az, hogy mennyi érték felett RENDELKEZHET az ügyfél. Ugyan ez így leírva csak szemantikának tűnhet, de technológiai szinten a megközelítés teljesen más. Hogy mindezt kontextusba helyezzem: Ha egy esetleges szoftver hiba, vagy támadás esetén képes is lenne a támadó manipulálni a balance nyilvántartásokat, akkor is csak annyit tudna elérni, hogy a nyilvántartások érvénytelenné válnak, hiszen a módosított/manipulált egyenlegek nem lesznek konzisztensek azok előzményeivel. Így ha valaki “alapos munkát akarna végezni”, akkor lényegében visszamenőlegesen az INLOCK összesen valaha történt műveletét kéne manipulálnia ahhoz, hogy egyetlen egyenleget módosítani tudjon. Maga a védelem nyilván ismerős lehet, hiszen a blockchain technológia is pontosan ugyanazt a módszert alkalmazza. Végülis volt honnan tanulnunk.
Fontos védelmi pont, hogy az inlockon belül MINDEN erőforrás egyedileg van ügyfelekhez kötve, pénzbeli érték semmilyen esetben nem lehet shared több user között. Ennek okán van is sajnos néhány kellemetlenség a platformon, ilyen pl hogy egy ügyfélnek a withdraw addresse nem lehet azonos egy másik ügyfél deposit addressével, így egy ügyfél nem tud direktben utalni cryptot egy másik ügyfélnek a platformon belül. Ez igencsak bosszantja is néhány ügyfelünket, de nem vagyunk hajlandók feladni ezeket a védelmi pontokat.
Itt ugyan csak 2–3 dolgot emeltem ki, de további számos hasonló funkció védi az ügyfél számlák nyilvántartását.
Fontos kérdés lehet, hogy mi a helyzet a ténylegesen tárolt kriptopénzekkel. Itt szintén számos olyan szeparációs megoldást alkalmazunk, amikről nem nyilatkoznék nyilvánosan, hiszen ezzel kritikus információkat adnék ki, de azt meg kell jegyezzem, hogy etéren is nagyon komoly védelmeket alkalmazunk.
Mindazonáltal nehéz elmennem a tény mellett, hogy a legtöbb exchange feltörés általában visszavezethető egy-egy belső szereplő hibájára vagy visszaélésére. Az INLOCK platformon ezen lehetséges szereplők számát a lehető legkisebbre szűkítettük. A support csapat nem tud az ügyfelek nevében semmilyen eseményt kezdeményezni, minden esetben az ügyfélnek magyarázzák el, hogy mit kell tennie. Egyetlen alkalmazottnak sincs joga egy személyben hozzáférni a cold wallethez, a cold walletjeink egy része 3/2 (külső), másik része 5/3 (belső) multisiggel védett.
Mi történne, ha mindezen intézkedések ellenére is káreset történne ami egyértelműen visszavezethető a platform technológiai hibájára vagy a platformot fenntartók esetleges visszaélésére? Ha ilyen eset bekövetkezne, akkor természetesen az INLOCK platform törekedve az ügyfelek kártalanítására a saját céltartalékainak erejéig.
Mik is pontosan ezek a céltartalékok? A céltartalékot két forrás biztosítja: kölcsönszerződések kényszerzárásakor keletkező extra bevétel, illetve az INLOCK saját collateral reserveje.
Nézzük előbb az kényszereterminálási forrást: ahhoz, hogy ezt a kérdés kontextusba helyezzem, előbb kiemelnék egy szakaszt az INLOCK Felhasználási feltételeiből, hiszen egy céltartalék jellegénél sokkal fontosabb az, hogy mégis miből és miért is keletkezik az:
Ön kifejezetten elfogadja és egyetért azzal, hogy az INLOCK Platformon a minimum 110%-os túlbiztosítási szinttel lehet hitelkérelmet benyújtani, és a fedezeti pont egységesen 105,1%, amely elérése esetén a fedezet terminálása automatikusan megkezdődik és a vonatkozó költségek a mindenkori díjtáblázat alapján levonásra kerülnek, valamint a hitelező is automatikusan kifizetésre kerül; a kontraktus pedig
lezárásra kerül. Minden hitelkontraktus nyitásnál minimum 10 napi kamat felszámításra kerül, függetlenül a visszafizetés dátumától.
A fedezet a kontraktus időtartama alatt ún. multisig tárcában kerül elhelyezésre, ez a biztonsági eljárás garantálja, hogy egyetlen személy soha nem képes hozzáférni és visszaélni a tárolt fedezetekkel.
Tehát a céltartalék egyik alapját a fedezethiányos szerződések kényszerzárásakor keletkező USDC maradványérték biztosítja. Már az eredeti INLOCK whitepaperben is deklaráltuk, hogy az ezen tevékenységből származó maradványértéket nem kezeljük a platform saját bevételeként, hanem ez egyfajta kármentő alapként kezelendő olyan esetekre, amikor akár szoftverhibából akár külső szolgáltatói hibából fakadóan nem lenne esetleg képes az INLOCK időben (megfelelő fedezeti szinten) zárni az alulfedezett szerződéseket, illetve, ha bármilyen egyéb okból keletkezne ügyfélkár nem az ügyfél önhibájából.
A belső kármentési alap másik részét a platform saját collateral reserveje biztosítja. Ez az érték javarészt az INLOCK tokensale során befolyt és erre a célra elkülönített része. A reserve célját és annak működés még 2018 nyarán mutattuk be egy külön publikációban:
Az INLOCKot két nagyon fontos alapelvvel hoztuk létre: Soha semmilyen körülmény között NEM tárolhatunk ügyfélértéket (beleértve a kölcsönök fedezetét) tőzsdén, illetve a tőzsdén 100%-san le kell fedezve legyen minden futó kölcsön a saját collateral reservünk terhére. Ezen tartékkezelést nevezzük collateral managementnek, illetve az ehhez forrást biztosítókat neveztük a kezdeti koncepcióban Collateral Managereknek. Ez a koncepció azonban erősen változott az elmúlt bő két évben, így igazodva a jelenlegi trendekhez a folyamatot eképpen módosítottuk: Az INLOCK elsődleges collateral reservejét saját maga biztosítja a tokensaleből erre a célra allokált fedezettel. Mivel ennek véges jellege erősen korlátozná az INLOCK kölcsönnyújtási funkcióját a 100%-os lefedezési kötelem miatt, ezért 2020 év elején létrehoztuk az INLOCK Stake funkciót, amiben folyamatosan fogjuk megnyitni az opciókat a platform fedezetként elfogadott kriptopénzeire (Bitcoin, Ethereum, Litecoin, stb.). Szemben az INLOCK kölcsöadási és kölcsönvételi funkciójával, ahol explicit definiált, hogy az ügyfélpénz nem kerülhet hot walletre; az INLOCK Stake terméknél pont ez a cél. Az ügyfelek a Stakebe helyezett pénzükkel segítik azt, hogy az INLOCK szélesebb körben tudjuk szolgáltatást nyújtani, amiért cserébe természetesen piaci szintű kamat jár.
Folyamatosan törekszünk arra, hogy minél transzparensebb módon mutassuk meg ügyfeleinknek a platform működését; azonban továbbra sem feledkezünk meg a post elején már bemutatott két alapelvről: likviditás és biztonság!
