Ezért nem támaszkodhat a kriptoipar tovább a központosított felhőszolgáltatókra
Az október 20-i, több órás Amazon Web Services (AWS)-leállás újra megmutatta, mennyire sérülékeny a digitális gazdaság – és vele együtt a kriptoipar. A hiba az AWS egyik belső, DNS-t érintő alrendszeréből indult, és elérhetetlenné tett szolgáltatásokat a kritikus US-East-1 régióban. Rövid időre olyan nagy szereplők is akadoztak, mint a Coinbase, a Robinhood vagy a CoinMarketCap. Tíz nappal később újabb, kisebb fennakadás következett, miközben az év korábbi részében más régiókban is voltak zavarok – sőt, Microsoft Azure és Google Cloud kiesésekre is láttunk példát.
A történtek nem (csak) az AWS-ről szólnak: a tanulság az, hogy egy ponton túl minden központosított infrastruktúra egyetlen hibaponttá válhat. A kriptoipar pedig, amely büszkén hirdeti a decentralizáció előnyeit, túl sokat bízott ezekre a rendszerekre.
Az áramszünet ára: likviditás, csúszó megbízások, kihagyott lehetőségek
Egy kriptotőzsdén minden másodperc pénz. Ha egy központi felhőkomponens – legyen az DNS, adatbázis-kapcsolat vagy üzenetsor – megáll, a megbízások késnek, a kivonások és befizetések befagynak, a piaci ár pedig közben mozog tovább. A végfelhasználó ebből annyit érzékel, hogy „nem megy az app” – a professzionális kereskedő pedig azt, hogy elvesztett egy belépőt vagy egy fedezeti zárást. A tényleges veszteséget ritkán lehet pontosan összeszámolni, de a hatás valós: likviditáskiesés, bizalomvesztés, reputációs kár.
Kapcsolódó tartalom: Az Amazon miatt fagytak le a legnagyobb kriptoplatformok
A központosított felhők korlátai
A nagy felhők (AWS, Azure, Google Cloud) elképesztő méretet, teljesítményt és vállalati szintű biztonságot nyújtanak – de nem tudják kinullázni a központosításból fakadó kockázatot. Egy hibás frissítés, egy túlterhelt útvonal, egy szűk keresztmetszetű vezérlő komponens dominóhatást indíthat. Ha az egész rendszer egy régióra, egy szolgáltatóra vagy egy hálózati rétegre épül, akkor a kiesés kikerülhetetlenül rendszerszintű.
Mire váltson a kriptoipar? Decentralizált és hibrid architektúra
Nem az a megoldás, hogy holnaptól mindent blokkláncra költöztetünk. A reális irány egy hibrid felépítés: a nagy felhők erősségeit megtartjuk, de a valóban kritikus részeket szétosztjuk több, egymástól független helyre és szolgáltatóra. Ilyen kritikus elem például a kereskedési motor (amely párosítja a vételi–eladási megbízásokat és kezeli a kockázatot), az elszámolási folyam, a kulcsok biztonságos tárolása, az állapotjelző („él-e a rendszer?”) végpontok és a bejelentkezés/azonosítás.
A gyakorlatban ez úgy néz ki, hogy a rendszer egyszerre két különböző földrajzi helyen fut, ideális esetben két külön felhőszolgáltatónál. A névfeloldást (DNS) nem bízzuk egyetlen szolgáltatóra: több, egymástól független DNS-útvonalat használunk, hogy egy hiba ne vágjon el minden forgalmat. Az adatok és üzenetek továbbítását nem egyetlen központi „cső” végzi, hanem két, egymástól független üzenetközvetítő rendszer, így ha az egyik megáll, a másik át tudja venni a feladatot. A feldolgozók úgy vannak megírva, hogy egy üzenetet hiba esetén is biztonságosan újra tudjanak dolgozni, és a rendszer a kiesés után magától „össze tudja rakni” a helyes állapotot.
Az adatbázisnál a fő példány mellé másik szolgáltatónál tartott, folyamatosan frissülő másolatot építünk. Ha gond van, a naplókból vissza lehet játszani a tranzakciókat, így nem vész el adat. A pénzügyi kulcsokat több szereplő között megosztva (többszereplős kulcsmegosztás), több hardveres kulcstárolóval és földrajzi szétszórással védjük; vészhelyzetre előre jóváhagyott, szigorú eljárásrend van. A kiszolgáló rétegben több tartalomszolgáltató hálózat és webes tűzfal működik párhuzamosan, a legfontosabb szolgáltatások pedig csökkentett funkcióval is képesek üzemelni, hogy teljes leállás helyett legalább az alapok menjenek.
Mindehhez rendszeres leállás-szimuláció kell: időnként szándékosan „lekapcsolunk” egy egész régiót próbaból, mérjük, hogyan tartjuk a vállalt szolgáltatási szinteket, és frissítjük a részletes vészforgatókönyveket.
Ez a felépítés valóban többe kerül, és hozhat némi plusz késleltetést és szervezési bonyolultságot. De ezek a költségek bőven összevethetők azzal, amit egy csúcsidőben bekövetkező, több órás leállás okoz pénzben és hírnévben. A lényeg: ne legyen egyetlen olyan pont a rendszerben, amelynek a hibája mindent magával ránt.