Közösségi pénz központosítottan hitelesített blockchain alapon (és egy minta megvalósítás Amazon felhőben)

A BitCoin (és úgy eleve a blockchain) egy zseniális megoldás arra, hogy decentralizált hálózat fölé robosztus, megbízható és konzisztens adatbázisokat építsünk (a BitCoin-ról itt írtam bővebben: http://lf.estontorise.hu/archives/662). Ennek viszont ára van! A BitCoin fenntartása rendkívül számítási teljesítmény igényes. Sőt, itt nemhogy nem cél a szükséges számítási teljesítmény csökkentése, sokkal inkább annak növelése a cél, hiszen a rendszer architektúrájából következik, hogy minél nagyobb számítási teljesítmény van a rendszerben, annál nehezebb feltörni azt. Ezért van az, hogy a BitCoin hálózat számítási teljesítménye mellett eltörpül bármely bank hipermegbízható szerver infrastruktúrája. Ez egyfelől pazarló, másfelől költséges megoldás. Ha azonban hajlandóak vagyunk kicsit feláldozni a decentralizáltságból, úgy megkerülhetjük ezt a problémát. Ebben a bejegyzésben arra szeretnék majd rámutatni, hogy egy ilyen rendszer sem sokkal rosszabb, mint a meglévő megvalósítás, ugyanakkor sokkal kevésbé pazarló, és nagyságrendekkel olcsóbb.
De miért is kell ez a hatalmas számítási kapacitás a BitCoinhoz? Ez ahhoz a bányászatnak elnevezett folyamathoz kell, ami valójában a blockchain (blokklánc) egyes blokkjainak hitelesítését jelenti. Ha hajlandóak lennének ezt egy központi szerverre kiszervezni, úgy megszűnne a bányászt, a rendszer biztonságát pedig ennek a szervernek a megbízhatósága szavatolná úgy, mint más hagyományos esetben. Gigantikus szerver parkokat (BitCoin bányákat) válthatnánk ki egyetlen olcsón fenntartható szerverrel. Egy ilyen hálózat működését szeretném bemutatni egy közösségi pénz példáján keresztül.
Tegyük fel, hogy önfenntartó közösségek tagjai szeretnének egymással kereskedni, és ehhez létre kívánnak hozni egy virtuális valutát. Úgy döntenek, hogy hagyományos blockchain helyett inkább bérelnek közösen egy szervert. Ennek egy főre jutó költsége minimális (vagy épp tranzakciónként fizetnek minimális összeget). Minden pont ugyanúgy történik, mint a hagyományos blockchain (pl. BitCoin) használata esetén, csak épp a tranzakciókat egy központi szerver hitelesíti (hogy értsük a folyamatot, érdemes elolvasni az előbb linkelt bejegyzést). Ha valaki pénzt akar küldeni valakinek, elküldi a tranzakciót a szervernek, a szerver pedig mondjuk percenként összesíti ezeket, létrehozza az új blokkot, és digitálisan aláírja azt (hash bányászás helyett). A blokkláncot bármikor bárki letöltheti, és mindenki tárolja ugyanúgy, ahogy a BitCoin esetén.
Megbízható lesz egy ilyen rendszer? Annyira bizonyosan megbízható, mint a szerver, tehát olyan biztonságot ad, mint más “hagyományos” megoldás (pl. egy banki rendszer), e mellett ugye megvan az az előnye, hogy ha bármikor is kibukik, hogy a szervert feltörték, úgy a helyi blokkláncokból reprodukálható egy konzisztens állapot. Ezt még esetleg tetézni lehet azzal, hogy a kliensek broadcastolják a hálózatba az utolsó blokkokat, amik így elég hamar szétterjednek, így ha bármely kliens ütközést észlel (pl. double spending), rögtön mehet a figyelmeztetés, hogy valaki megtörte a szervert. Egy ilyen rendszerben jó eséllyel pár percen belül kibukik, hogy gond van. Ilyenkor a közösség tagjai összejönnek, beállítanak egy új szervert, amit mondjuk pár véletlenszerűen választott tag helyi blokkláncából állítanak helyre (a láncoknak ugye elvileg egyezniük kell), a régi szerver gazdáját pedig jól seggbe rúgják, mert nem vigyázott a szerverre.
Biztonságos lesz egy ilyen rendszer? Az egyenleget ugye nem lehet megpiszkálni a szerveren, mert azt a tranzakciók adják ki. Pénzt költeni más nevében megintcsak nem lehet, mert ahhoz (ahogy BitCoin esetén is) kell az illető privát kulcsa. Az anonimitás ugyanúgy biztosított, mint BitCoin esetén. Szóval elég biztonságos. (Elvileg biztonságosabb lehet, mint egy banki rendszer.)
Na és ha lelövik a szervert? Nos, valójában a BitCoin esetén is vannak fix szerverek, amikhez egy új kliens kapcsolódik. Ezek listája a kliensbe van vasalva. Ha ezeket kilőjük, azzal az új belépőket máris elvágtuk a hálózattól. Mivel a partnerek megtalálásához általában mindig kell valami központi szerver (legyen szó BitCoin-ról, torrent trackerekről, stb.) ezért mindig lesznek gyenge pontok. Ebben az esetben nyilván a központi szerver lesz a gyenge pont, ami ráadásul jóval könnyebben kiiktatható, mint más, decentralizáltabb rendszerek esetén, de mivel a szerveren nem tárolunk semmi fontosat (a blokklánc ott van minden kliensnél), ezért az közös megegyezéssel bármikor pótolható. Egy globális pénznél ez problémás lehet, egy helyi pénznél viszont kivitelezhető.
A sok elmélet után gondoltam ki is dolgozok (az architektúra szintjéig) egy hihetetlenül egyszerű megvalósítást a fentiekre, amit némi JavaScript tudással elvileg bárki össze is rakhat, aki saját közösségi pénzre vágyik. A megoldást az Amazon felhőjére találtam ki, de bármely más megoldás (Google Cloud, Azure, saját szerver, stb.) szóba jöhet. Ebben a minta megoldásban a kliensek egy HTTP végponttal rendelkező Amazon Lambda függvénynek küldik a kívánt tranzakciókat. A függvény rögtön hitelesíti is a tranzakciót a digitális aláírás alapján, és amennyiben az nem megfelelő, el is dobja. A következő körben ellenőrzi, hogy van-e elég keret a tranzakcióra a blokklánc alapján. Ha nincs, ugyancsak elbukott a tranzakció. Ha minden rendben, akkor a tranzakció bekerül egy SQS queue-ba. Egy másik lambda függvény percenként kiüríti a queue-t, és elkészíti a blokkot, amit szigorúan sorszámozva kihelyez Amazon S3-ra. S3-ról bárki letöltheti a blokklánc legújabb blokkjait, vagy akár a teljes blokkláncot. Pofon egyszerű, és elég megbízható, hiszen pl. double spending megvalósításához magát az S3 szolgáltatást kellene megtörni, és elérni, hogy bizonyos klienseknek más más tartalmat adjon. Ha ezt valaki megcsinálja, akkor egyfelől le előtte a kalappal, másfelől az Amazon úgy ahogy van, lehúzhatja magát a klotyón, mert fabatkát sem ér a szolgáltatása. Ebben viszont nem annyira hiszek. Ami inkább sebezhető, az a lambda függvény, ugyanis innen a privát kulcsot megszerezve visszamenőleg hamisítható a blokklánc, és bizonyos tranzakciók meg nem történté tehetőek (itt pénzt lopni nem nagyon lehet, inkább csak visszalopni). Egy ilyen behatolást a fentiekben leírt blokk broadcast mechanizmus valószínűleg hamar felderítene (rögtön riadót fúj az a kliens, aki a saját blokkláncától való eltérést tapasztal), de ha nem bízunk ebben (végső soron ez a mechanizmus is megtámadható), akkor megtehetjük azt, hogy több független lambda függvényt üzemelünk be, és ezek mindegyikének sorban hitelesítenie kell az adott blokkot. Így minden lambda ellen (amik célszerűen külön-külön felhasználókhoz tartoznak) sikeres támadást kell végrehajtani ahhoz, hogy hamisíthatóak legyenek a blokkok. Olyat is el tudok képzelni, hogy ha egy ilyen architektúra sikert aratna, megjelennének a piacon olyan szolgáltatók, akik semmi mást nem csinálnak, csak időbélyegezve lepecsételnek egy adatcsomagot (időbélyegző szolgáltatások már most is léteznek, ez valami hasonló), erre viszont erős garanciát vállalnak. Ez már elég garancia lehet a pénzüknek. De akár ilyen külső szolgáltató megvalósítható “hagyományos” blockchainben is pl. Ethereum segítségével. Ebben az esetben pl. naponként vagy akár óránként a saját blokkláncunk aktuális hash-ét beírhatjuk a blockchainbe, ezzel olyan biztonságba helyezve azt, amit az elosztott blockchain ad. Ha a szerverünket bárki feltöri, a kliensek egyből tudomást szereznek róla még akkor is, ha nincs náluk meg a teljes lánc. Ez esetben a blockchainben tárolt hash előtti blokkláncra olyan garanciánk van, amit az adott hagyományos blokklánc (pl. Ethereum) ad, úgy hogy azt csak részben használjuk. Akinek ezen garanciák egyke sem meggyőző, az választhatja az Ethereumot (vagy más hasonló szolgáltatást) a valutája tárolására.
A fentiekben tehát egy olyan blockchain alternatívát próbáltam felvázolni, ami nem teljesen decentralizált ugyan, de anonim, megbízható, biztonságos, olcsó, és messze nem olyan számítási igényes, mint a BitCoin vagy más AltCoin-ok. Egy ilyen rendszer üzemeltetése nem sokkal bonyolultabb, vagy költségesebb mint egy egyszerű, teljesen szerveren futtatott nyilvántartási rendszeré, ugyanakkor sokkal megbízhatóbb és biztonságosabb annál.

Hozzászólás írása