Hozzáadva: 2021. Szeptember 06.
A modern elosztott adatmenedzselés egyik központi kérdése az, hogy hogyan tudnak egymásban nem megbízó felek tranzakciókat lefolytatni egymás között. Ez már a klasszikus elosztott rendszerek tárgyalása során is felmerül. Kérdés továbbá, hogyan lehet több műveletet egy atomi lépésbe belefoglalni? Hogyan lehet hibák után helyreállni? Hogyan lehet az adatokhoz való, egymással versengő hozzáféréseket szinkronizálni? Ezeket a kérdéseket újra át kell gondolni ha a résztvevő felek autonómok és bizonyos esetekben ellenkező érdekekkel rendelkeznek.
A blokkláncok közötti ügyletek olyan adatforgalom lebonyolítását oldhatják meg, amelyeket akár ellenséges felek is indíthatnak és a vagyontárgyak kicserélése olyan felhasználók között is megtörténhet így, akik nem feltétlenül szeretnének együttműködni. Nézzük most a biztonsági kérdéseket a blokkláncok közötti ügyletek területéről. Két protokollról lesz itt szó, az egyik teljesen szinkronizált, a másik pedig félig szinkronizált és globális megosztott főkönyvet igényel.
A magyar fordítás a Cross-chain Deals and Adversarial Commerce című cikk alapján készült.
A blokkláncok közötti ügyleteket megvalósító rendszerek nagyon hasonlóak a klasszikus elosztott számításokat (distributed computing) megvalósító rendszerekhez. Vagyis sok hasonlóságot és sok eltérést is találunk. Ha például a klasszikus atomi tranzakciókat vesszük, akkor az ACID tulajdonságokról beszélhetünk (atomicity [atomi], consistency [konzisztens], isolation [izolált] és durability [tartós]). A lentiekben ki fog derülni, hogy a blokkláncok közötti tranzakciók nagyon hasonlítanak ehhez, azonban alapjában véve el is térnek. Az atomi tranzakciókat tehát teljes mértékben át kell gondolni, ha a blokkláncok közötti ügyletek megvalósítására akarjuk alkalmazni.
Klasszikus esetben az atomi fogalom azt jelenti, hogy egy tranzakció hatása vagy mindenhol létrejön, vagy sehol nem jön létre. Ez a tulajdonság nem biztos hogy teljesül ha a résztvevő felek érdekei egymással ellentétesek. A legtöbb amit el tudunk érni az az, hogy a protokollt követő felhasználókat nem verik át. Továbbá a klasszikus tranzakciók előnyben részesítik a biztonságot a túlélés tulajdonságával szemben és így például olyan commit protokollokat használhatnak, amelyek blokkolnak (Two-phase commit protocol). A blokkláncok közötti tranzakciók során viszont a túlélési tulajdonságot azzal próbálják meg biztosítani, hogy egy résztvevőnek nem engedélyezik a vagyontárgyak hosszú vagy végtelen idejű lezárását, és így az nem képes átverni a másik felet.
A klasszikus izoláció arról szól, hogy az egymással versengő tranzakciók nem tehetnek kárt egymásban. Az izolációt általában szerializálhatósággal (serializability) vagy snapshot konzisztenciával (snapshot consistency) oldják meg. Ezek a megoldások nem túl ideálisak a blokkláncok közötti tranzakciók megvalósítására, mert az egymásban nem bízó feleknek többször, megfontoltan kell egymással kapcsolatba kerülni, létrehozván így az ügyletet. Vagyis az egymással való kapcsolat gátlása a dupla költés (double-spending) problémáját oldhatja meg, hiszen így a félnek nem nyílhat lehetősége az adott vagyontárgy többszöri eladására.
Itt most olyan informatikai absztrakciót fogunk megvizsgálni, amely a klasszikus elosztott számítási világból érkezik és a modern blokkláncok közötti ügyletek megvalósításában segédkezhet. A blokkláncok közötti ügyletek megvalósítása klasszikus atomi tranzakciókon alapul és a blokkláncok közötti cserékből (cross-chain swaps) is merít ötletet, de ezektől radikálisan eltér.
A blokkláncok közötti ügyletek tehát nem atomi tranzakciók. Különböző problémák megoldására lettek kitalálva. Az atomi tranzakciók bonyolult állapotváltozásokat tesznek tisztába, azonban a blokkláncok közötti ügyletek a résztvevő felek vagyontárgyainak kicserélésére lettek kitalálva. A tranzakciók a globális tulajdonságok megőrzésének céljából “mindent-vagy-semmit” jellegűek, viszont az ügyletek autonóm résztvevői eldönthetik, hogy kielégíti-e őket az ügylet kimenetele. A tranzakciók és az ügyletek a hiba szempontjából is másképp viselkednek. A tranzakciók során feltételezzük, hogy a kliensek egy hiba során leállhatnak és ez okozhat galibát, az ügyletek során viszont feltételeznünk kell, hogy a felek tetszőleges mértékben eltérhetnek a protokolltól.
A blokkláncok közötti ügyletek továbbá nem blokkláncok közötti cserék. A lentiekből ki fog derülni, hogy a blokkláncok közötti cserék nem képesek a legkisebb mértékben sem kielégíteni azt amit a blokkláncok közötti ügyletektől elvárnánk.
A nem érdekegyeztetett kereskedelem (adversarial commerce), amelyet egymásban nem bízó felek között létrejött ügyletekként definiálunk sokáig nem fog még eltűnni a köztudatból. Továbbá, az egymásban nem autonóm bízó felek között létrejövő ügyletek során használt kommunikáció megvalósítására a legpraktikusabb megoldás a megosztott, nem módosítható adattároló. A következőekben tehát blokkláncokról és okosszerződésékről lesz szó, viszont az lenti taglalás nem szorítkozik semmilyen konkrét blokklánc technológiára, így tehát viszonylag univerzális elmélet. A megosztott adattároló technológiai megvalósításától függetlenül itt egy olyan informatikai absztrakcióról olvashatunk, amely a nem érdekegyeztetett kereskedelmet taglalja központi témaként.
Itt tehát szó lesz blokkláncok közötti ügyletekről, avagy olyan új informatikai absztrakciókról, amelyek komplex elosztott számítási rendszerekben szerveznek struktúrát amikor a résztvevő felek nem érdekegyeztetettek. Ehhez új protokollok megalkotására van szükség.
A tranzakciók atomiságát átdefiniálva új élhetőségi és biztonsági tulajdonságokat is be fogunk vezetni.
A blokkláncok közötti tranzakciók megvalósításához két protokollról lesz részletesen szó. Egy teljesen decentralizált időzár megvalósításról, amely szinkron kommunikációs modellen alapszik. És egy nem ilyen modellen alapuló hitelesített blokkláncról (certified blockchain) is szó lesz. Kiderül továbbá, hogy minden protokoll, amely valamilyen szintű aszinkronitást tolerál szükségszerűen centralizált blokkláncon kell hogy alapuljon.
A protokollok költségéről és implementációjáról is szó lesz. Mivel a blokklánc technológia még gyerekcipőben jár itt inkább az örökletes, platformfüggetlen tulajdonságokról lesz szó, mintsem valamilyen közvetlen benchmark jellegű mérésről. A fő cél a választott mód függvényében, a blokkláncok között megvalósuló tranzakciók során felmerülő költségek vizsgálata lesz.
Az olyan rendszerekben, amelyekben a felhasználók tetszőleges mértékben eltérhetnek a protokolltól a korrektség definíciójának kialakítása nagy körültekintést igényel. Meg azt sem lehet feltételezni, hogy minden résztvevő racionálisan hozza meg döntését, hiszen bizonyos felhasználók célfüggvénye nem is ismert. Lehetnek olyan hatalmak a hálózatban, akik hajlandóak a hálózat stabilitásának aláásásáért fizetni. Továbbá kiderül, hogy a klasszikus atomi fogalmak, mint például a “minden-vagy-semmi” elv a nem érdekegyeztetett felhasználók között nem is biztos hogy értelmezhető. A blokkláncok közötti cserék (cross chain swaps) irodalmában a korrektségek nem definiálják rendesen. Enélkül viszont lehetetlen a blokklánc protokollok, az okosszerződések vagy a nem érdekegyeztetett felállást lehetővé tevő alrendszerek esetében korrektségről beszélni.
A blokkláncok közötti ügyletek rugalmas definíciójába számos modell és feltételezés beleeshet. Egy extrém eset lehet mondjuk a bitcoin vagy az ethereum hálózata. Ezek a rendszerek szinkron működést feltételeznek és felső korlátja van a blokkláncban beállt változások terjedési sebességének. Egy másik extrém példa lehet az Algorand, a Libra vagy a Hot-Stuff. Ezek a kriptovaluta hálózatok fél-szinkron megoldást alkalmaznak és a kezdetekben az üzenetek terjedési idejét nem korlátozzák, viszont a hálózat végül elér egy globális stabilizációs időt (global stabilization time) és innentől kezdve az szinkronban lesz. A gyakorlatban tehát a szinkron periódusnak csak jó sokáig kell tartania és így tud a rendszer stabil állapotba kerülni. A modellek rendelkeznek előnyös és előnytelen tulajdonságokkal is és ebből következően felhasználási területeik adottak.
A szinkron protokollok védelmi mechanizmusokat kell hogy kialakítsanak a DoS támadások ellen. Az időzárakat ügyesen kell megválasztani, vagy őrtornyokat (watchtowers) kell alkalmazni. A fél-szinkron protokollok nem használnak időzárakat, azonban centralizáltabb hálózatokra van szükségük, mint a szinkronizált protokolloknak. Be lehet bizonyítani, hogy a fél-szinkron protokollok esetében szükség van egy központi főkönyvre és ebbe kell hogy írjanak a résztvevő felek. Az összetett kommunikációs megvalósításokról most nem lesz szó.
Ma a legnépszerűbb megoldás a központosított kriptovaluta tőzsdék használata. Ilyen például a Coinbase vagy a Binance. Ezek a tőzsdék általában teljesen szabályozatlanok és semmilyenemű garanciát nem vállalnak a rajtuk elhelyezett vagyontárgyakért. A kriptovaluta tőzsdék gyakran hackertámadások áldozataivá vállnak, de volt már olyan is, hogy a felhasználók pénzével eltűntek mint a kámfor.
A nem érdekegyeztetett ügyletek megvalósításának problémája jelentős mennyiségű tudományos kutatást szült. Ezekről itt olvashatunk:
https://en.bitcoin.it/wiki/Atomic_swap
https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki
https://github.com/decred/atomicswap
https://www.arwen.io/whitepaper.pdf
https://www.investopedia.com/terms/u/utxo.asp
https://bitcointalk.org/index.php?topic=1364951
https://komodoplatform.com/en/
Atomic Commitment Across Blockchains
https://www.enigma.co/enigma_catalyst.pdf
A probléma ezekkel az, hogy a bonyolultabb, például a harmadik fél közbenjárását igénylő ügyleteket képtelenek megvalósítani ezen protokollok. Nem alkalmazhatók továbbá licitálásokra sem és egyéb összetett ügyletek lebonyolítására.
Legyen Alice egy jegyüzér. Nagykerben veszi rendezvényszervezőktől a jegyeket és kiskereskedelmi áron adja azokat a végfelhasználóknak. Így keresi kenyerét. Alice a futurisztikus jövőben él a jegyek tulajdonjogát a meghamisíthatatlan főkönyvben, a blokkláncban tárolják. A jegyekért fizetett kriptovaluták tulajdonjogát pedig egy kriptovaluta blokklánc tárolja. Mind a két blokklánc támogatja az szerződés funkciót és ezzel lehet állítani a tulajdonjogokat.
A színháztulajdonos Bob egy napon 2 jegyet szeretne eladni 100 kriptovalutáért cserébe egy népszerű darabjára. Alice viszont tudja, hogy Carol akár 101 valutát is adna a jegyért cserébe, így cselekszik és lebonyolítja az ügyletet Bob és Carol között.
Alice feladata tehát abban rejlik, hogy leprogramozzon egy blokkláncok közötti protokollt. Ezen protokollnak kell biztosítani a kriptovaluták és a jegyek tulajdonjogának cseréét és közben nem szabad elfeledkeznünk Alice jutalékáról sem. Ha minden rendben van, a kriptovalutáknak és a jegyeknek gazdát kell cserélniük. Továbbá a protokollnak biztosítania kell azt is, hogy ha valaki csalni akar, akkor se tudja átverni a másikat.
Továbbá tegyük fel például azt, hogy Alice licitálásra akarja bocsátani vagyontárgyát. Bob és Carol licitálnak, megteszik ajánlataikat. Alice megnézni az ajánlatokat és akié a magasabb annak adja el vagyontárgyát, a másik licitált összegét pedig visszautasítja. Klasszikus blokkláncok közötti cserével azonban ez nem megvalósítható mert a kriptovaluta aukció kimenetele nem mondható meg előre.
Általánosabb diszkusszióval élve a blokkláncok közötti cserék nem képesek arbitrázs üzletek megvalósítására. Ezek alatt olyan üzletet értünk, amelynek során Alice olcsón vesz és azonnal drágán ad el.
Jelen pillanatban nem létezik még egy olyan blokkláncok közötti cserét megvalósító protokoll sem, amely ilyen jellegű struktúrált ügyletek megvalósítását lehetővé tenné. A blokkláncok közötti ügyletek sokkal általánosabb tárgyalásmódot igénylenek. Nézzük hát most ezt.
Minden egyes blokkláncok közötti ügylet lefolyása szemléltethető egy táblázattal. Ez a mátrix (táblázat) bemutatja a vagyontárgyak és a pénzek mozgását a blokkláncok közötti ügylet lefolyása során. Ilyen lehet a következő táblázat:
Az adott résztvevőhöz tartozó oszlop megmutatja hogy egy résztvevő mit kíván kapni az ügylettől, a sor pedig megmutatja, hogy ezért mit kell adnia az ügylet során. Egy résztvevő akkor fog részt venni az ügyletben, ha számára az ügylet kimenetele jobb helyzetbe hozza őt mint amilyenben az ügylet lefolyása előtt volt. Az előző példát a fenti táblázat szemlélteti. Ebben Alice egy 100 egységbe kerülő jeggyel kereskedett Carol és Bob között. Az aukció megvalósítása során kétirányú kommunikációt leíró mátrixot kell használnunk. Ha Bob magasabb licitet rak mint Carol, akkor Alice átadja vagyontárgyát Bobnak, Bob átadja kriptovalutáit Alicenak, Carol pedig visszakapja a pénzét. Ellenkező esetben a tranzakció fordítva fut le. A blokkláncokon megvalósított valós életből vett aukciók további díjakkal és büntető eljárásokkal kell hogy számoljanak, gátolván így a rosszindulatú felhasználók ténykedéseit.
A résztvevők prokollt kell hogy kövessenek, csak így lehet megvalósítani egy mindenki számára igazságos ügyletet. Ha ettől eltérő módon, nem alkalmazunk mondjuk mindenki által elfogadott protokollt, akkor senki sem garantálhatja, hogy az ügylet, a leírásban szereplő módon kerül lebonyolításra. Szóval akkor milyen részleges műveletekről beszélhetünk itt, amelyek elfogadhatóak?
A klasszikus modellek hibás és nem hibásan működő résztvevőket különböztetnek meg. Itt viszont csak azt tudjuk mondani, hogy lesznek olyan felhasználók akik követik a protokollt és lesznek olyanok, akik nem. A hiba-toleráns (fault-tolerant) protokollok általában megkövetelik a résztvevők bizonyos hányadának őszinteségét (protokoll követési magatartás). A bitcoin világából már jól ismert proof-of-work konszenzus a többség protokoll követő magatartását követeli meg. A legtöbb bizánci hibatolerán konszenzus pedig a résztvevők ⅔-ától követeli meg a protokollkövető magatartást a helyes működés érdekében. A blokkláncok közötti ügyletek esetében viszont jó lenne semmi ilyen jellegűt nem megkövetelni.
A protokollkövető és nem követő felosztás egyébként a BAR modellből származik. Ez a modell bizánci, altruista és racionális felosztást tárgyal. A nem érdekegyeztetett kereskedelem során a protokollkövető felek racionális felek, a többi fél eltér a prokolltól attól függetlenül, hogy racionális vagy nem. (Rationality is Self-Defeating in Permissionless Systems) Továbbá nincsenek altruista résztvevők. A jelen tárgyalás tehát eltér a BAR modelltől, mert a bizánci felek számára nem ad korlátot.
A minimálisan elvárható biztonsági jelleg abban foglaltatik, hogy egyik résztvevő fél sem jár rosszul, még akkor sem ha a többiek nem követik a protokollt. Egy résztvevő kifizetése alatt a protokoll lefolyása során vett befolyó és kifolyó vagyontárgyakból vett összesített egyenlegváltozást értjük. Bizonyos kifizetések elfogadhatók, a többi viszont nem. Bizonyos elfogadható kifizetések jobban tetszhetnek egy félnek, azonban nincs olyan elfogadható kifizetés, amely rossz helyzetbe hozná az adott felet.
Minden résztvevő fél a következő kifizetéseket elfogadhatónak tekinti: MINDET, ha a kialkudott tranzakciók mindegyike végbemegy, vagy EGYIKET SE, amikor pedig nem megy végbe tranzakció. Továbbá a felek elfogadhatnak további tranzakciókat is. Ha például van egy fél, amely három bejövő és három kimenő tranzakcióra vár, akkor elfogadhatja a tranzakciókat abban az esetben is ha csak kettőt kap és kettőt küld. Minden ilyen jellegű választás alkalmazásfüggő. Feltételezzük továbbá azt is, hogy egy fél számára ha egy tranzakciós csomag elfogadható akkor elfogadhatók az olyan tranzakciós csomagok is, amelyekben több befelé és/vagy kevesebb kifelé mutató tranzakció jönne létre. Az EGYIKET SE eset elfogadható módosításának lehet tekinteni tehát azt, amikor a fél semmit nem küld, viszont fogad valamennyi tranzakciót. Az ilyen jellegű esetek, bár a valóságban ritkán valósulnak meg, nem hagyhatók figyelmen kívül.
Egy blokkláncok közötti ügylet biztonságosnak mondható akkor ha:
1. Tulajdonság: A protokoll minden lépése során minden protokollt követő fél elfogadható kifizetésben részesül.
A biztonságosság ilyen jellegű definíciója az atomi tranzakciók mindent vagy semmit jellegű tulajdonságát cseréli le, hiszen az nem használható ha a résztvevő felek között van nem protokoll követő magatartást tanúsító fél. A blokkláncok közötti ügyletek megvalósításáért felelős protokollok általában alkalmaznak valamiféle záradékot is és ezzel biztosítják a jóhiszemű feleket.
A következő gyenge életbenmaradási tulajdonság garantálja azt, hogy a protokollt követő felek vagyontárgyai örökre nem ragadhatnak be.
2. Tulajdonság: A protokollt követő felek vagyontárgyai nem ragadhatnak bent örökre.
Végezetül pedig kívánatos, hogy az erős életbenmaradási tulajdonság is teljesüljön:
3. Tulajdonság: Ha minden résztvevő fél követi a protokollt és hajlandóak elfogadni a felajánlott kifizetéseket, akkor minden átutalás megtörténik (minden fél kifizetése MINDEN jellegű). A Impossibility of distributed consensus with one faulty process című munka eredménye alapján pedig tudjuk hogy az erős életbenmaradási tulajdonság csak azokban az időszakokban teljesülhet, amikor a hálózat szinkron állapotban van és az üzenetek terjedési idejének van felső korlátja.
A jelen tárgyalásban a blokklánc egy nyilvánosan olvasható, meghamisíthatatlan főkönyvnek tekintendő. Ez tárolja a vagyontárgyak aktuális tulajdonosaira utaló adatokat. A vagyontárgyak lehetnek átruházhatók (fungible) és nem átruházhatók is (non-fungible). Átruházható vagyontárgy például egy adag pénz, nem átruházható pedig mondjuk egy színház jegy. Résztvevő fél lehet egy magánszemély, egy szervezet vagy akár egy szerződés is. A tárgyalás során feltételezünk egymástól függetlenül működő blokkláncokat is. Ezek különböző vagyontárgyak tulajdonjogát tárolják és a blokkláncok tükrözik minden egyes vagyontárgy tranzakció eredményét. Így nincs lehetőség például papír alapú jegyek kicserélésére a felek között.
A résztvevő felek továbbá képesek bejegyzéseket létrehozni a blokkláncban és értesítéseket kapnak annak változásáról minden egyes alkalommal. A jelen modellben a bejegyzések létrehozása szerződésekkel való interakció segítségével valósul meg. A záradék megvalósítását a szerződés végzi, amikor is a fél egy bizonyos időre vagyontárgyának tulajdonjogát a szerződésnek adja át. Ha bizonyos feltételek teljesülnek, akkor a szerződés továbbküldi a tulajdonjogot a másik félnek, ha pedig nem, akkor a vagyontárgy tulajdonjoga visszaküldésre kerül.
Egy fél képes létrehozni új szerződést a blokkláncokon és hozzáfér minden egyes függvényhíváshoz, amelyeket a szerződések lehetővé tesznek számára. A szerződések állapota és a szerződéseket megvalósító forráskód publikus, ebből fakadóan a felek tisztában vannak az adott hívások eredményével. A szerződések determinisztikusan kell hogy működjenek, mert az egymásban nem megbízó felek akár többször is meghívhatják az adott kódrészleteket és így az eredményeknek mindig ugyan annak kell lenniük.
A szerződés hozzáfér adatokhoz azon a blokkláncon, amelyen publikálva van, de nem hívhat másik blokkláncon található szerződések kódját és nem fér hozzá más, külvilági adatokhoz sem. Az A blokkláncon található szerződés csak akkor tudhat a B blokkláncon bekövetkezett változásról ha valamelyik fél, egy az állapotváltozást bizonyító adattal kiegészítve értesíti a szerződést.
Összegezve tehát a szerződések passzívan működnek, publikusak, determinisztikusak és megbízhatók. A felek pedig aktívan működnek, autonómok és esetenként eltérhetnek a hivatalos protokolltól.
A kriptográfiai feltételezések pedig a következők. Minden félnek van egy privát és egy publikus kulcsa. A felek publikus kulcsát mindenki ismeri. Az üzeneteket aláírják, így nem lehet őket meghamisítani, illetve ki vannak egészítve egy egyszerhasználatos nonce értékkel, így nem lehet őket megismételni.
A blokkláncok közötti ügyleteket egy egyszerű állapotgéppel lehet szemléltetni. Ez az állapotgép nyomon követi a tulajdonjog változásokat. Az állapotváltozások záradékokat, átutalásokat, végrehajtásokat és törléseket reprezentálnak. Jelölje P a felek halmazát, A a vagyontárgyak halmazát. Egy vagyontárgyat egyszerre csak egy fél tulajdonolhat. Owns(P,a) tehát csak akkor ad vissza igaz értéket ha csak P tulajdonolja A-t.
Egy aktív ügylet ideiglenesen áthelyez egy vagyontárgy tulajdonjogát két fél között. Az ideiglenes áthelyezés végleges lesz ha a tranzakció végrehajtásra kerül és törlésre kerül ha nem valósul meg.
Az ügylet folyamán két leképzésről beszélhetünk. Az egyik C : A → P, a másik A : A → P. Kezdetben mind a kettő üres. C(a) jelöli a vagyontárgy végső tulajdonosát ha az ügylet végrehajtásra kerül az “a” blokkláncon és A(a) jelöli a vagyontárgy végső tulajdonosát ha az ügylet törlésre kerül az “a” blokkláncon. Owns(C,P,a) igaz értékkel tér vissza ha P a tulajdonosa a vagyontárgynak a végrehajtás után és Owns(A,P,a) igaz értékkel tér vissza ha P a tulajdonosa a vagyontárgynak a törlés után.
A záradékok (letét?) a klasszikus pénzügyi világban azért lettek létrehozva, hogy egy vagyontárgy tulajdonjogát ne lehessen egyszerre több félre átruházni. A következő történik ha P záradékba helyezi a-t egy D ügylet során:
Kezdet: Owns(P,a)
Vég: Owns(D, a) és Owns(C,P, a) és Owns(A,P, a)
A kezdeti feltétel megköveteli a féltől a vagyontárgy tulajdonjogát. Csak így tudja zárolni. Ha a kezdeti feltétel kielégült, akkor a vagyontárgy tulajdonjoga áthelyezésre kerül egy záradéki szerződés segítségével (escrow contract). Mivel még nem történt ideiglenes tulajdonjog áthelyezés, a vagyontárgy tulajdonjoga végrehajtás és törlés esetén is visszaszáll az eredeti tulajdonosra.
Nézzük mi történik akkor amikor az egyik fél P ideiglenesen átküldi az a vagyontárgyat Q-nak a D ügylet során:
Kezdet: Owns(D, a) és Owns(C, P, a) Vég: Owns(C,Q,a)
A kezdeti feltétel megköveteli, hogy a letétbe helyeződjön D által. D akkor tudja végrehajtani az ügyletet ha P-nél van a vagyontárgy tulajdonjoga. Ha pedig D végrehajt és az ügylet sikeres, akkor a vagyontárgy tulajdonosa Q lesz. Ha például Carol 101 darab valutát Alice-nek akar küldeni, Alice lesz C-ben a tulajdonos. Alice ezek után 100 darab valutát át tud küldeni Bob-nak, 1-et pedig megtart magának C-ben. A vagyontárgyak letétben maradnak amíg az ügylet sikeresen le nem zajlik. Ha sikerült, akkor a vagyontárgyak tulajdonjogai kicserélődnek és D megszűnésével az új állapot C lesz.
Az ügyletet a következő fázisok segítségével hajtják végre:
Hirdetési fázis. Egy piacfelderítő szolgáltató résztvevőket keres, majd azoknak a lehetséges ügyletekkel kapcsolatos információkat ad át. A piacfelderítő lehet centralizált egység is, és nem kell benne feltétlenül megbízni. Minden fél később eldöntheti, hogy hajlandó-e résztvenni az ügyletben.
Záradéki fázis. A felek záradék alá helyezik vagyontárgyaikat. Például a jegyeket és a kriptovalutákat.
Hitelesítési fázis. Miután az ideiglenes tranzakciók lezajlottak minden fél megbizonyosodik arról, hogy azok úgy történtek meg, ahogyan azt a piacfelderítő hirdette. Ezen lépés során lehetőség van a vagyontárgyak letétbe helyezésről való megbizonyosodásra, acélból hogy ne lehessen azokat kétszer elkölteni. Továbbá ellenőrizhető az is, hogy a bejövő és kimenő kifizetések egyenlege egy adott fél számára elfogadható-e. A jegyek eladása során például a felek ellenőrzik, hogy azok letétbe kerültek-e, a jegyek az előzetes feltételeknek megfelelően kerültek-e kiállításra és hogy senki sem fizet többet a kelleténél. A klasszikus kétfázisú végrehajtási protokoll (classical two-phase commit protocol) esetében a hitelesítési fázis során nincs szükség szemantikus ellenőrzésekre, ehelyett a felek elfogadják a feltételeket ha a megfelelő zárak (locks) kialakultak és azok garantáltan fenn is maradnak. A nem érdekegyeztetett ügyletek során azonban alkalmazás specifikus hitelesítési fázisra is szükség van, amelynek során a felek eldönthetik, hogy a felajánlott kifizetések elfogadhatóak-e számukra.
Végrehajtási fázis. A felek szavaznak arról, hogy az ideiglenesen átutalásokat véglegesítik-e. Ha minden egyes fél pozitívan szavaz, akkor a letétbe helyezett vagyontárgyak áthelyezésre kerülnek az új tulajdonosaikhoz, máskülönben azok visszaszállnak az eredeti tulajdonosaikhoz.
A blokkláncok közötti ügyletek két egymásba fonódott fontos mechanizmustól függenek. Elsősorban a letéti mechanizmusnak köszönhetően a vagyontárgyak tulajdonjoga először a letéti szerződésre kerül és ez meggátolja azok többszörös elkölthetőségét. Itt viszont oda kell figyelni arra, hogy a jóhiszemű felek vagyontárgyainak tulajdonjoga véletlenül se kerülhessen végtelen ideig tartó letétbe ha valaki így próbálná támadni a protokollt. Másodsorban a protokollnak az más jellegű támadásokkal szemben is ellenállónak kell lennie. Egy támadó például ellophat úgy vagyontárgyakat a rendszerből, hogy bizonyos tranzakciók sikerességéről értesíti a feleket, bizonyosakéról pedig nem. Továbbá ha egy támadó sokáig képes befolyásolni a protokoll döntéshozatalát, akkor vagyontárgyak nagyon hosszú ideig is befagyasztásra kerülhetnek. A legnehezebb feladat tehát a blokkláncok közötti ügyleteket megvalósító platformok létrehozása során a megfelelő végrehajtási protokoll és a letéti mechanizmus megtervezésében rejlik. Hasonlóan a klasszikus működésekhez itt is sok előnyről és hátrányról beszélhetünk. Nézzünk most egy szinkron és egy fél-szinkron protokollt a decentralizáció és a hibatolerancia szemszögéből. Ezeket, letéti szerződés segítségével blokkláncok közötti ügyleteket megvalósítására használhatjuk fel.
Az időzár protokoll azt a működést írja le, amelynek során a felek vagyontárgyai kikerülnek a letét alól, amennyiben minden fél pozitívan szavaz a végrehajtásról. A felek ugyanakkor nyíltan nem szavaznak a visszavonásról. Ehelyett az időzár protokoll lép működésbe és feloldja a tulajdonjogokat a letétből ha esetleg valamelyik fél leállna vagy elállna az ügylet megvalósításától. Ez a protokoll szinkron hálózati működést feltételez és ebben a blokkláncban lévő terjedési idők ismertek, illetve korlátosak. A működés során minden fél megvizsgálja hogy a várható kifizetések elfogadhatóak-e, ha igen, akkor erről az adott vagyontárgy tulajdonjogát rögzítő blokkláncon található szerződés használatával szavaznak. Minden szavazathoz hozzá kell rendelni egy időzárat. Ha a szavazatok nem érkeznek be az időzár lejártáig, a tulajdonjogok visszaszállnak az eredeti tulajdonosokhoz.
Mivel az ügylet nem érdekegyeztetett, a felek motiváltak abban, hogy a beérkező tranzakciókat befolyásoló blokkláncokon elhelyezzék szavazataikat, azonban nem motiváltak abban, hogy a kimenő tranzakciókat befolyásoló blokkláncokon elhelyezzék szavazataikat. Magyarul nem szívesen fizetnek, de örülnek ha kapnak valamit. Acélból, hogy a protokoll motiválja a résztvevőket, lehetővé teszik, hogy egy motivált résztvevő továbbítsa egy nem résztvevő végrehajtásról szóló szavazatát két letéti szerződés között. A végrehajtásokról szóló szavazatok ilyen jellegű publikálásából nem származhat kár, csak a protokolt teszik gördülékenyebbé.
A megvalósítás nehéz része az időkorlát kialakításában rejlik. Ha csak pusztán minden egyes résztvevőhöz rendelnénk egy időzárat, azzal nem lehetne biztosítani az előzőekben ismertetett helyesség tulajdonságot. Ezt a következő példával lehet szemléltetni. Vegyük az előző jegyértékesítési ügyletet. Ha a jegy tulajdonojoga és az érte fizetett kriptovaluta pontosan ugyan annyi időre van befagysztva, akkor a hálózatban található késleltetések miatt lehetetlen megvalósítani az ügyletet. Mivel a harmadik félnek véges időre van szüksége ahhoz, hogy észrevegye a blokkláncra publikált szavazatokat, majd lebonyolítsa az ügyletet, bizonyos esetben a jegy tulajdonjogához tartozó, más esetekben a kriptovalutához tartozó időzár fog feloldódni, így pedig lehetetlen lebonyolítani az ügyletet.
A probléma megoldására a javaslat a következő. Minden szavazathoz egy változó hosszúságú időzárat rendelnek hozzá, amely attól függ, hogy milyen késleltetésű úton érkezett a szavazat. Ha például az egyik fél szavaz, neki csak bizonyos időkorláton belül engedik meg a szavazat elküldését és a szavazatot alá is kell írnia. Ha a fél egy mástól érkező szavazatot továbbít, akkor annak az előzőleg definiált időkorlát kétszerese alatt be kell érkezni (a legrosszabb esettel számolva). Az ilyen jellegű szavazatokat mind a két félnek alá kell írnia. Az ilyen jellegű aláírásokat a szavazat útvonal aláírásának hívják (path signature). Ha delta az előre definiált terjedési időkorlát és p az útvonal aláírások száma, akkor a szavazatnak delta*p idő alatt be kell érkeznie.
Az időzár protokollt az alábbi lépésekben lehet futtatni:
Hirdetési fázis: Egy ügylet során egy piaci közvetítő fél a következő adatokat küldi el az összes félnek: Az ügylet azonosítója (D), a felek listája plist, a végrehajtási idő kezdete (t_0), amelyből az időzárakat lehet számolni és az időzár értéke (delta). A legtöbb blokklánc alapú rendszer pontatlanul méri a késleltetéseket. Általában az adott blokklánc magasságot szorozzák meg az átlagos blokkérkezési frekvenciával. A t_0 paramétert úgy kell megválasztani a jövőben, hogy bőven legyen idő az ideiglenes tranzakciók végrehajtására. A delta paraméternek pedig olyan nagynak kell lennie, hogy képes legyen tolerálni a blokklánc időmérési pontatlanságából adódó hibákat. t_0 és delta csak időzárak számítására van felhasználva, így értékük nem befolyásolják a normális végrehajtási időket, amikor a felek szavazatai időben beérkeznek. Ha az ügylet végrehajtásához percekre van szükség, akkor a delta paraméternek az órák nagyságrendjében kell lennie.
Zárlat fázis: A kimenő vagyontárgyakat a felek egy zárlati szerződés segítségével letétbe helyezik.
Escrow(D, Dinfo, a)
Ez az adott vagyontárgy blokkláncán történik meg. D-vel jelöljük az ügyletet, Dinfo jelöli az ügyletre vonatkozó egyéb adatokat (plist, t_0, delta). A letétbe helyezés csak akkor történik meg ha a fél ténylegesen az “a” vagyontárgy tulajdonosa és a plist listában szerepel.
Transzfer fázis: A P fél, az ideiglenesen birtokolt vagyontárgyat (a) átküldi Q-nak az adott vagyontárgy blokkláncán található letéti szerződés segítségével:
transfer(D,a,Q)
A félnek a vagyontárgy tulajdonosának kell lennie és Q-nak szerepelnie kell a listában.
Validációs fázis: Minden fél megvizsgálja hogy számára a bejövő vagyontárgyakból származó kifizetési egyenleg elfogadható-e és hogy a piaci hirdető által közzétett adatok helyesek-e. Ha igen, akkor a felek szavaznak a végrehajtásról.
Végrehajtási fázis: Minden fél, minden egyes bejövő vagyontárggyal kapcsolatban végrehajtási szavazatot ad a letéti szerződésnek. A jóindulatú felek, akár más blokkláncokra is küldhetnek szavazatokat ezzel kapcsolatban. A felek a következő eljárást használják:
commit(D,v,p)
és ezzel szavaznak, vagy szavazatokat továbbítanak a letéti szerződés felé. “v” a szavazat, “p” pedig az út aláírása a v szavazatnak. Feltételezzük továbbá, hogy az ügyletazonosítók egyediek, ezzel védeni lehet a hálózatot az újrajátszásos támadások ellen (replay attack).
Egy szerződés csak akkor fogad el egy szavazatot, ha az időben beérkezik és helyes a formátuma. Az út aláírásban minden fél egyedi és a plist lista is egyedi. Az aláírások érvényesek és tanúskodnak “v”-ről. Ha a szavazat elfogadásra került, akkor a szerződés elfogadta a fél végrehajtási akaratát.
A szerződés, miután minden fél szavazott a végrehajtásról kiereszti a zárolt vagyontárgyat az új tulajdonosnak. Ha a szerződés t_0 + N*delta időn belül nem kapott szavazatot minden egyes féltől, akkor már nem fogad el további szavazatokat és az időkorlát lejár, a vagyontárgyak pedig visszaszállnak az eredeti tulajdonosokhoz.
A magyarázat megkönnyítése érdekében az ügyletet egy digráffal lehet ábrázolni. A csomópontok a feleket jelentik, az élek pedig a tranzakciókat:
Ha az ügyletet reprezentáló digráf nem szorosan kapcsolt (strongly connected), akkor az ügylet nem jólnevelt (well-formed). Magyarul ekkor biztosan tartalmaz olyan bliccelő felet, aki szeretne valamit úgy kapni, hogy közben nem fizet érte. Ilyen esetben a többi fél nem motivált a protokollkövető magatartásra, mert biztosan jobban jönnének ki ha kizárnák a bliccelő felet az ügyletből.
A protokollkövető fél a saját bejövő vagyontárgyához tartozó blokkláncon lévő letéti szerződésnek küld szavazatokat, majd figyeli a kimenő vagyontárgyak blokkláncait és a bejövő vagyontárgyához tartozó blokklánc felé továbbít szavazatokat más felektől. Más félnek nem kell egyéb blokkláncokkal kommunikálni.
Ez a megoldás decentralizált, mert nem tartalmaz egyetlen olyan blokkláncot sem, amelyet minden egyes félnek használnia kellene. A szavazási protokoll leírja, hogy minimális szinten mit vár el a résztvevőktől. A résztvevőknek nem tiltja semmi, hogy egyéb más blokkláncokra publikálják szavazatukat, azonban feltételezhetjük, hogy mindenki a saját blokkláncát használja nagy gyakorisággal. A továbbiakban feltételezzük, hogy a tranzakciós digráf szorosan kapcsolt és az ügyletek jól viselkednek, bár az időzár protokoll képes egyéb esetek kezelésére is.
Mi történik például ha egy fél nem követi a protokollt? Például ha Bob b valutát akar Carollal c valutára cserélni. Alice bonyolítja le a cserét. 101 b valutát vesz el Bobtól (és Caroltól). Majd 100 valutát küld tovább a feleknek és közben 1-et 1-et megtart tranzakciós díjként mind a két féltől. Így, bizonyos időpontokban Alice mind a két valutával fog rendelkezni. A folyamat felgyorsítása céljából Alice átutalja a saját számlájára a beérkező valutákat és a saját számlájáról fizeti ki a feleket.
Mi van akkor, ha Alice vírussal fertőzött és irracionálisan viselkedik?
Bob beküldi neki a szavazatát, azonban többé nem kommunikál vele, Carollal viszont igen. Bob időzára le fog járni és a kriptovalutái visszatérítésre kerülnek. Számára az ügylet befejeződött. Carol viszont már elküldte a 101 darab valutáját. Ezért cserébe kap 100 valutát Alice-től, szóval az ő számára is elfogadhatóan zajlott le az ügylet.
Annak ellenére, hogy ez az ügylet nem “mindent-vagy-semmit” jellegű, elfogadható, mert minden fél számára kielégítő kifizetéssel zárult. Viszont Alice, aki eltért a protokolltól pórul jár, mert úgy kell fizetnie Carollnak, hogy közben nem kapott semmit Bobtól. A klasszikus igazságosság tehát itt nem teljesülhet, de ha igazságos szerződést szeretnénk megvalósítani, akkor az igazságosságot át kell definiálni.
Elmélet 1: Az időzár protokoll biztonságos.
Bizonyítás: A felépítésből adódóan X (protokoll követő) letétbe helyezett bejövő és kimenő vagyontárgyainak utalása kielégítő kifizetéseket eredményez. Tegyük fel a következő ellentmondást: X kimenő vagyontárgya (a) kiszabadul a letéti szerződésből és átutalásra kerül, azonban Z fél szavazatának hiánya miatt a bejövő vagyontárgy (b) nem képes kiszabadulni a letéti szerződésből és visszautalásra kerül. Tegyük fel, hogy Z végrehajtási szavazata “a” blokkláncára “p” út aláírással érkezett be. A “p”-ben található aláírók között biztosan nem szerepelhet X, mert X protokollkövető és így már biztosan továbbította volna Z szavazatát b-ről. Z szavazata “a” blokkláncára rövidebb, mint t_0 + p*delta idő alatt ér oda. Mivel X protokollkövető, ezt a szavazatot “b” blokkláncára rövidebb mint t_0 + (p+1)*delta idő alatt fogja eljuttatni, és ott ezt a szavazatot pedig el fogják fogadni. Ez pedig ellentmondás.
Elmélet 2: Az időzár protokoll teljesíti a gyenge élhetőségi tulajdonságot. A protokollkövető felek kimenő vagyontárgyai sosem ragadhatnak be örökre a szerződésbe.
Bizonyítás: Minden vagyontárgy, amelyet egy protokollkövető fél zárolt, véges időzárral rendelkezik.
Elmélet 3: Az időzár protokoll teljesíti az erős élhetőségi tulajdonságot.
Bizonyítás: Ha minden fél protokollkövető, akkor végrehajtási szavazatokat küldenek a letéti szerződés felé a beérkező vagyontárgyakról. Minden alkalommal, amikor egy bejövő vagyontárgyról érkezik szavazat egy fél azt a bejövő vagyontárgyhoz tartozó szerződés felé továbbítja. Mivel az ügyelt jól viselkedő, azaz szorosan kapcsolt digráffal jellemezhető, minden szavazatot minden szerződés felé időben továbbítanak.
Tegyük fel mégis azonban, hogy Bob időben megszerzi Alice és Carol szavazatát és azokat elküldi nekik, hogy azok utána igényelni tudják a kifizetéseket. Ekkor viszont Alice és Carol lecsatlakozik a hálózatról és nem tudják a jegy tulajdonjogát rögzítő blokklánc irányába továbbítani a szavazatokat. Tehát Alice és Carol nem protokollkövető magatartást tanúsít azzal, hogy nem jelentkeznek időben az őket megillető kifizetésekért. Ez ellen védekezvén a delta paramét jó nagyra kell választani. Így a fenntartott szolgáltatás-megtagadásos támadások (sustained denial-of-service attacks) költségét meg lehet növelni. A lightning payment network pontosan ezen okokból világítótornyoknak (watchtowers) nevezett objektumokat használ. A világítótornyok feladata a letéti szerződések monitorozása és az offline állapotban lévő felek helyett történő döntéshozatal.
Most pedig egy olyan protokollról lesz szó, amely fél-szinkron működést feltételez. Mivel nincs lehetőség időzáras letéti szerződés használatára, a felek szavazhatnak a megszakításról ha valami balul sül el vagy valamelyik időlimit lejár.
A klasszikus kétfázisú végrehajtásos protokolltól eltérően itt nincs koordináló szerv. Ehelyett egy speciális blokkláncot fogunk használni, az pedig a CBC (certified blockchain). A CBC lehet egy már használatban lévő blokklánc, de lehet egy teljesen új is.
A felek ebben a megoldásban nem a vagyontárgyak tulajdonjogait tároló blokkláncokra küldik szavazataikat, hanem a CBC blokkláncra. A CBC rögzítik és időrendi sorrendbe helyezi a szavazatokat. Egy félnek lehetősége van bizonyítékok megszerzésére, amelyek arról tanúskodnak, hogy bizonyos szavazatok bizonyos sorrendben érkeztek be. Egy fél, ha valamilyen vagyontárgyra tart igényt, vagy pénzét szeretné visszaszerezni a bizonyítékot a vagyontárgy tulajdonjogát tároló blokkláncon lévő szerződés felé továbbítja. A szerződés ellenőrzi a bizonyíték valódiságát és létrehozza a tranzakciókat ha a bizonyíték érvényes. A végrehajtás bizonyítéka arról árulkodik, hogy minden fél pozitívan szavazott a végrehajtásról, mielőtt bármelyik fél a megszakításról szavazott volna. Egy félnek lehetősége van szavazatát visszavonni, ha például valamilyen abnormalitást tapasztal (látszólag túl sokáig tart a tranzakció). Az erős túlélhetőség tulajdonság megőrzésére nagy időkorlátokat kell alkalmazni. Magyarul egy fél hosszú ideig kell hogy várakozzon mielőtt meggondolja magát, mert csak így tud a többi szavazat is beérkezni.
Egy végrehajtásos protokollt akkor hívunk decentralizáltnak, ha nincs egy olyan blokklánc, amelyet minden félnek használnia kellene egy ügylet során. A CBC protokoll tehát nem decentralizált, mert a CBC egy központi adattároló, amelyet minden félnek használnia kell az ügylet lefutása során. A decentralizáció megszünte elkerülhetetlen. Nincs egy olyan protokoll sem, amely képes lenne aszinkron periódusokat tolerálni decentralizált módon. A részletes bizonyításra nem térünk ki, de Fischer, Lynch és Paterson művéből (Impossibility of distributed consensus with one faulty process) megérthető. Ha tehát minden fél protokollkövető és ha az ügylet létrejön bármely blokkláncon, akkor annak az összes blokkláncon végre kell hajtódnia. Ugyan ez igaz a megszakításra is. Kezdetben az ügylet állapota bivalens. A kimenet lehet végrehajtás is és megszakítás is. Ennek ellenére az ügylet állapota nem lehet a végtelenségig bivalens. El kell érnie egy kritikus állapotot, amelyben minden egyes félnek döntést kell hoznia és ez a protokollt egy univalens állapotba hozni. Az univalens állapotban vagy a végrehajtás vagy a megszakítás lesz elkerülhetetlen. Az állapotváltozásért felelős végrehajtási döntés és a megszakítási döntés nem jöhet létre külön blokkláncokon, mert így nem tudnánk eldönteni melyik volt előbb és hogy melyik az elfogadható. Ebből következően tehát a kritikus állapotban a feleknek muszáj ugyanazt a szerződést használniuk, ez pedig sérti a decentralizáció elvét.
A CBC protokollt a következő módon kell futtatni:
Hirdetési fázis: Egy piaci hirdető szolgáltató egy egyedi “D” azonosító hirdetésébe kezd. Hirdeti továbbá a felek listáját (plist). Itt most nincs szükség a kezdeti időre és a delta paraméterre. Egy fél a CBC blokkláncra adatot publikál az ügylet kezdetéről:
startDeal(D, plist)
A hívó félnek szerepelnie kell a plist listában. Ha több ilyen startDeal bejegyzés jelenik meg a CBC blokkláncon, akkor a legelsőt vesszük alapul.
Letéti fázis: A kimenő vagyontárgyakat a felek letétbe helyezik:
escrow(D, plist, h, a….)
Itt a h paraméter egy olyan hash érték, amely a CBC blokkláncon azonosítja az ügyletet. Erre akkor van szükség ha esetleg több ügylet lenne a blokkláncon. Az argumentumban tetszőleges számú paraméter szerepelhet. Az időzár protokollhoz hasonlóan a küldőnek szerepelnie kell a plist-ben és az a vagyontárgy tulajdonosának kell lennie.
Transzfer fázis: A P fél az a vagyontárgyat, amelyet ideiglenesen birtokol átküldi Q-nak:
transfer(D, a, Q)
a letéti szerződés használatával. P szükségszerűen a tulajdonosa és Q-nak szerepelnie kell plistben.
Validációs fázis: Mint ahogyan az előzőekben, minden fél ellenőrzi, hogy számára megfelelőek-e a kifizetések és hogy a vagyontárgy rendesen letétbe van-e helyezve a letéti szerződésben és hogy a hash érték és a plist is valós-e.
Végrehajtási fázis: Minden X fél végrehajtási vagy megszakítási szavazatot küld D-ről a CBC blokkláncon:
commit(D,h,X) vagy abort(D,h,X)
Itt D az ügyletet azonosítja, h pedig az ügyletet indítja. És mint mindig, minden szavazónak az ügyletet indító plist-ben kell szerepelnie.
Amikor valamilyen hiba lép fel, a CBC protokoll kevesebb kimenetet engedélyez, mint az időzár protokoll, mert minden protokollkövető fél szavaz a végrehajtásról, vagy a megszakításról. Ettől függetlenül, mivel nem ismerjük teljes mértékben a nem protokollkövető felek magatartását, még ez a protokoll sem képes a klasszikus atomi tranzakcióknál megjelenő “mindent-vagy-semmit” tulajdonság teljesítésére. Ha például Carol valamilyen hiba miatt, vagy szándékosan 1001 darab valutát küld Alicenak 101 helyett és minden fél a végrehajtásról szavaz, akkor a protokollkövető Alice 901 darab bónusz valutával fog rendelkezni. Ez a kimenetel pedig se nem “mindent” vagy “semmit” jellegű még a protokollkövető feleket tekintve sem. Természetesen az ilyen jellegű kimenetelek bekövetkezési valószínűsége a valóságban alacsony, de a helyesség tárgyalása során érdemes megtenni az ilyen megkülönböztetéseket is. A CBC és az időzár protokoll is kielégíti viszont az informális biztonsági tulajdonságot, miszerint végül egyik fél sem jár rosszul.
A CBC protokoll helyessége többé kevésbé magától értetődő. A biztonság azért garantált mert minden egyes protokollkövető fél szavaz vagy a végrehajtásról vagy a megszakításról. A gyenge élhetőségi tulajdonság pedig azért van jelen, mert minden egyes protokollkövető fél, amelynek vagyontárgyai túl hosszú ideig beragadnak a protokollba a megszakításról fog szavazni. Az erős élhetőségi tulajdonság feltételei pedig a hálózat szinkron szakaszaiban teljesülnek, mert ekkor a felek szavazhatnak a végrehajtásról, még mielőtt bárki a megszakításról szavazna.
Aktív felek számára viszonylag könnyű eldönteni, hogy egy ügylet végre lett-e hajtva vagy nem. Azonban passzív szerződések számára, amelyek nem képesek más blokkláncokhoz hozzáférni ez már nem olyan egyszerű. Egy ügylet döntő szavazatának hívjuk azt a szavazatot, amely eldönti az ügylet kimenetelét. Egyszerű megoldás lehet ha a szerződés számára bemutatjuk a szóbanforgó CBC blokkot, a kezdő startDeal rekorddal és a befejező döntő szavazattal. De honnan tudhatja a szerződés, hogy ezek valóban szerepelnek-e a CBC blokkláncon? A választ a CBC blokkláncon megvalósított algoritmus részleteiben kereshetjük.
Tételezzük fel, hogy a CBC blokklánc a bizánci hibatoleráns konszenzuson (BFT) alapul. Erről a következő cikkekben lehet olvasni:
Hot-Stuff the Linear, Optimal-Resilience, One-Message BFT Devil
Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains
Practical Byzantine Fault Tolerance
A BFT protokoll a kommunikció aszinkron szakaszaiban is garantálja a biztonsági tulajdonságot. Az élhetőség pedig a szinkron szakaszokban, a globális stabilizációs idő letelése után van garantálva.
A blokkokat 3*f+1 darab ismert hitelesítő hitelesíti és ezek közül maximum f lehet nem protokollkövető. A hosszú távú hibatolerancia érdekében a blokklánc periódikusan újrakonfigurálja magát és legalább 2*f+1 hitelesítő újraválasztódik. A könnyebb tárgyalásmód végett, feltételezzük, hogy egy adott blokk tartalmazza a következő blokk hitelesítőinek kulcsait.
A BFT blokklánc minden egyes blokkja f+1 hitelesítő aláírással van ellátva és ez a blokk tanúsítványa. Bármely f+1 darab aláírás jó lehet, mert közöttük biztosan lesz legalább egy protokollkövető hitelesítő. A blokkok sorozata és az aláírások bizonyítékként használhatók. A szerződés, amely a vagyontárgy blokkláncán található le tudja ellenőrizni ezt a bizonyítékot, mindaddig, amíg ismeri az első blokk hitelesítőit. Ezt az első 3f+1 hitelesítő átadásával tudjuk megvalósítani. Az átadásra az ügylet letéti szerződésének argumentumának kibővítésével van lehetőség.
A felek protokollkövető hitelesítőket kell hogy keressenek amikor vagyontárgyaikat letétbe helyezik és a szavazás előtt le kell ellenőrizniük a hitelesítők azonosítóit. Az ilyen jellegű ellenőrzések viszonylag sok munkát igényelnek. A bizonyítékok valószínűleg több blokkban fognak szerepelni és a gyakorlati megvalósításhoz sok bejegyzésre is szükség lesz majd. Továbbá a bizonyítékok nem lehet lerövidíteni a nem releváns blokkbejegyzések kihagyásával, mert így egy kártékony félnek lehetősége nyílhat a szerződés manipulációjára. Ettől függetlenül a BFT bizonyítékok hatékonyságát sokféleképp lehet növelni.
Egy viszonylag könnyű megoldás alapulhat azon ha kihasználjuk, hogy a CBC blokkláncon vannak hitelesítők. Így a felek a CBC blokklánctól kérhetnek bizonyítványokat. Egy ilyen bizonyítvány árulkodhat az ügylet aktuális állapotáról (aktív, végrehajtott, megszakított). Ha az eredeti hitelesítők még mindig aktívak, akkor a bizonyítványt bizonyítékként lehet felhasználni. Ellenkező esetben mindig rendelkezésre kell bocsátani a hitelesítők listáját az újrakonfigurálások során.
A bitcoin és ethereum jellegű proof-of-work konszenzus algoritmust alkalmazó blokkláncok alkalmasak lehetnek a végrehajtási vagy a megszakítási állapotváltozás tárolására, azonban ekkor körültekintéssel kell eljárni, mert ezek a blokkláncok nem tárolják végleges formában az adatokat. Ebből következően bármely bizonyítást felül lehet írni egy később jövő bizonyítással. Igaz ugyan, hogy minél több blokk érkezik be annál számítási kapacitást igényel az ellentmondó blokk legyártása. Kiayias és társai (Proofs of Proofs of Work with Sublinear Complexity és Non-Interactive Proofs of Proof-of-Work) olyan PoW protokoll változtatást javasolnak, amely az ilyen jellegű proofs-of-proof-of-work jellegű bizonyítékokat még zártabb formára hoznák.
A következő felállásban Alicenak lehetősége nyílik a CBC blokkláncon egy hamis megszakítási szavazat bizonyítékát létrehozni. Amint elkezdődik az ügylet végrehajtása, Alice mondjuk egy bűntárssal együtt elkezdenek egy abort bizonyítékot tartalmazó blokkot bányászni. Ha Alice számára a tranzakció befejeződni látszik, akkor ő publikus formában küld egy végrehajtási szavazatot (commit) a CBC blokkláncra. Ha Alicenak sikerül azon idő alatt, míg a többiek szavaznak a végrehajtásról kibányászni egy abort blokkot, akkor meg tudja akadályozni hogy a vagyontárgyai kiáramoljanak tőle, de a valós szavazatokat felhasználva be tudja kebelezni az ügyletben őt (nem jogosan) megillető vagyontárgyakat.
A proof-of-work alapú rendszerekben meg lehet nehezíteni a csalók munkáját az extra blokkok beérkezésének megkövetelésével. Ha a szavazatok elfogadása előtt megköveteljük, hogy néhány blokk még érkezzen be, akkor a csalóknak több számítási kapacitást kell allokálniuk a támadás kivitelezésére. A racionális csalók elrettentésére több blokk beérkezését kell megkövetelni mielőtt elfogadnánk a szavazatokat és a blokkok száma attól függ, hogy milyen értékű az ügylet. A megoldás elviekben tehát létezik, a gyakorlati megvalósítása azonban korántsem egyértelmű. A bizonyításokat egymásra lehet pakolni és így a proof-of-proof-of-work meghamisíthat egy proof-of-work eredményt (Proofs of Proofs of Work with Sublinear Complexity). Hasonló módon, az egymásnak ellentmondó bizonyítékok létrehozásának költségét olyan magasra kell tenni, hogy ne érje meg őket létrehozni. Ezzel ellentétben a BFT commit és abort tanúsítványok véglegesek és nem függenek a kérdéses vagyontárgy értékétől.
Nezzük meg az egyes protokollok üzemeltetése során felmerülő költségeket. A következő költség analízis az ethereum protokoll költség analízisén alapul (Ethereum: a secure decentralised generalised transaction ledger). A nem PoW alapú blokkláncok is valószínűleg hasonló módon modellezhetők. A következő táblázat bemutatja a különböző felek Gas költségeit:
A szolgáltatás megtagadásos támadások (denial-of-service) jellegű támadások költségének megnövelésének érdekében a szerződéseket kezelő virtuális gépek általában minden egyes utasítás végrehajtásért díjat számolnak fel. Az ethereum esetében ezt Gas költséggel jelölik. A Gas ára a kereslet függvénye és ethereumban van kifejezve. Például egy egyszerű aritmetikai művelet elvégzése vagy a rövidéletű memóriához való hozzáférés egy számjegyes Gas költséget jelent. Az irányítási folyamatok, vagy a hosszúéletű memóriához való hozzáférés pedig kettő, de akár három számjegyes Gas költséget is jelenthet. A Gas költségeket általában a két következő művelet dominálja: hosszúéletű memóriaműveletek (5000 Gas), aláírás hitelesítés 3000 Gas.
A Gas költségek analízéshez a következő pszeudókódot fogjuk használni:
Ez a szerződés egy egyszerű ERC20 szabványú tokent valósít meg. A fő működési egységet a leképzések jelentik. Az escrow változó tárolja, hogy a felek hány vagyontárgyat helyeztek letétbe (3. sor). Az onCommit változó pedig azt adja meg, hogy a felek hány vagyontárgyat kapnak meg ha az ügylet létrejön (4. sor). A hibaellenőrzést megvalósító rész itt most nincs feltüntetve.
Letéti fázis: Minden fél meghívja az escrow függvényt azért, hogy letétbe helyezzék a vagyontárgyaikat. Ez a függvényhívás két tárolóba történő írást jelent, amíg a küldő a szerződés felé elküldi a vagyontárgyát (8. sor). 1 tárolóba történő írást jelent a frissítés (9. sor) és 1 tárolóba történő írást jelent az onCommit hívás is. Így összesen 4 írási műveletre van szükség, vagyis a letéti fázis költsége O(m) gas.
Átutalási fázis: Minden egyes fél meghívja a transfer függvényt és ezzel átutalja a letétbe helyezett tokeneket a másik félnek. A küldő onCommit ideiglenes egyenlegét ilyenkor mindig csökkenteni kell és ezért 1 tárolóba történő írást kell erre elhasználni (15. sor). A fogadó egyenlegét növelni kell ez pedig még egy írást jelent (16. sor). Így tehát az átutalási fázis gas költsége O(t) gas.
Hitelesítési fázis: Minden fél ellenőrzi a bejövő és a kimenő vagyontárgyak tulajdonjogáért felelős szerződéseket és eldönti, hogy a kifizetések kielégítik-e őt. Ez a művelet a felek rendszerében zajik, így gas költséget nem jelent.
Időzár protokoll végrehajtási fázis: Azt időzáras letéti szerződések a végrehajtási út aláírásokat ellenőrzik. Az aláírásokat nem a szerződések, hanem a felek generálják, így tehát nem merül fel többlet költség ezen lépés miatt.
A következő ábrán egy ilyen letéti szerződés pszeudókódját lehet megtekinteni. A szerződés rögzíti a résztvevő feleket (2. sor) és azt hogy ki szavazott már. A commit függvény egy szavazót, az aláírók listáját és az aláírásokat fogadja mint argumentum. A 6. sorban ellenőrzi, hogy az ügylet időzára nem járt-e még le. A 7. sorban ellenőrzi a szavazót. A 8. sorban hogy a szavazatot még nem rögzítették-e. A 9. sorban pedig, hogy nincsenek-e duplán szavazók. A nagy gas költséget okozó műveletek az aláírások hitelesítést (11. sor) jelentik és a szavazók rögzítése a hosszúéletű memóriában (13. sor) is drága.
Minden szerződés n fél aláírását hitelesíti és minden fél aláírása n-1 fél által lehet hitelesítve. Így tehát a legrosszabb esetben O(n*n) aláírást kell hitelesítenie egy szerződésnek és egyéb adatok tárolására konstans méretű tárat kell fenntartani a szerződés számára. Mivel m darab szerződés van, ez a művelet O(m*n*n) gas költséget fog magával vonzani. A legjobb esetben a megszakítás aláírások hitelesítése nélkül is megtörténhet, a legrosszabb esetben a megszakítás költsége viszont majdnem annyi lehet mint a végrehajtásé.
CBC protokoll végrehajtási fázis: A letéti szerződés a CBC blokklánctól érkező bizonyítékokat ellenőrzi. Vagyis, hogy azok elég darabszámú fél által lettek-e aláírva. A következő ábrán egy ilyen letéti szerződés pszeudokódja látható. Ez a CBC szerződés egy BFT konszenzus protokollt használ, amely f bizánci fél jelenlétét képes tolerálni. A felek a CBC felől státusz bizonyítékokat tudnak igényelni és a rekonfigurációs lépéseket most nem vesszük figyelembe.
A szerződés a 2. sorban nyomon követi az aktuális hitelesítők listáját és tudatában van a publikus kulcsaiknak is. A commit függvény argumentumában szerepelnek az aláírók és az aláírásaik is. A 6. sorban ellenőrzi, hogy nincsenek-e duplán aláírók. A 7. sorban, hogy minden aláíró hitelesítő-e, a 8. Sorban, hogy van-e elegendő szavazat. A magas gas költséget jelentő lépés a hitelesítők aláírásainak leellenőrzése jelenti (10. sor). Továbbá van még egy konstans számú műveletből álló könyvelési művelet is, amely különböző változók állapotát rögzíti.
Minden szerződés f+1 aláírást hitelesít vagy (f+1)*(k+1) darabot ha a hitelesítők listája k-szor megváltozott. A teljes gas költség tehát O(m*(f+1)) az aláírások hitelesítésére, illetve konstans darabszámú írás a letéti szerződés tároló változóinak írására.
Most nézzük a végrehajtási szerződések késleltetéseit, amikor a hálózat szinkron állapotban van és a blokklánc állapotváltozásához maximum delta idő szükséges. Erről még a feleknek értesülni is kell. Az analízis eredményeit a következő táblázat összesíti. Feltételezzük, hogy minden vagyontárgyat k-szor utalták át.
Mind a két protokoll esetében, protokollkövető magatartást feltételezvén a letéti fázis maximum delta időt vesz igénybe, hiszen minden fél párhuzamosan frissíti a kimenő vagyontárgy szerződését. Hasonló módon, az átutalási fázis maximum k*delta időt vesz igénybe. Az átutalásokat konkurens módon is elvileg létre lehet hozni, ekkor pedig ez maximum delta időt vesz igénybe. Az átutalási fázis végén a hitelesítés lokálisan, azonnal megtörténik.
Időzár protokoll végrehajtási fázis: Ha minden egyes fél a végrehajtási szavazatát csak a bejövő vagyontárgy blokkláncára küldi el, akkor a legrosszabb esetben a végrehajtási fázis időigénye arányos a leghosszabb átutalási sor hosszával, ennek felső korlátja pedig n*delta.
CBC protokoll végrehajtási fázis: Minden protokollkövető fél párhuzamos módon küldi el szavazatát a CBC blokklánc irányába és ezek a szavazatok nagyon gyorsan rendelkezésre állnak ha a CBC-t BFT protokollal valósítják meg. Ilyen lehet a PBFT családból (Hot-Stuff the Linear, Optimal-Resilience, One-Message BFT Devil vagy Practical Byzantine Fault Tolerance) egy megoldás például. A letéti szerződésnek maximum delta időre van tehát szüksége hogy átutalja vagy hogy visszaküldje a vagyontárgyakat.
A következő néhány tudományos műben részletesen olvashatunk az atomi cserékről:
https://en.bitcoin.it/wiki/Atomic_cross-chain_trading
https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki
https://github.com/decred/atomicswap
https://arxiv.org/pdf/1801.09515.pdf
https://bitcointalk.org/index.php?topic=1364951
https://supernet.org/en/technology/whitepapers/BarterDEX-Whitepaper-v0.4.pdf
https://arxiv.org/abs/1905.02847
https://www.enigma.co/enigma_catalyst.pdf
Ezen művek mindegyikében olyan atomi eljárásokról van szó, amelyek során a felek átutalják vagyontárgyaikat és utána megállnak. Ezek azért lehetnek jók, mert a segítségükkel meg lehet valósítani a decentralizált váltókat. Ezekről már néhányszor kiderült, hogy átverhetik az ügyfeleiket (https://en.wikipedia.org/wiki/Mt._Gox és https://en.wikipedia.org/wiki/Quadriga_Fintech_Solutions). Ettől függetlenül láttuk, hogy az ilyen jellegű kereskedői tranzakciókat nem képesek megvalósítani. Az aukciók létrehozására sem használhatjuk őket és más pénzügyi tranzakciók implementálására sem jók. A jelenleg használt blokkláncok közötti csereügyletek megvalósítására használt protokollok közül a hashelt időzáras szerződés a legelterjedtebb. Erről az alábbi cikkekben lehet olvasni:
https://en.bitcoin.it/wiki/Atomic_cross-chain_trading
https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki
https://github.com/decred/atomicswap
https://bitcointalk.org/index.php?topic=1364951
https://supernet.org/en/technology/whitepapers/BarterDEX-Whitepaper-v0.4.pdf
Maurice Herlihy (Atomic Cross-Chain Swaps) a két fél közötti protokollt szorosan kapcsolt irányított gráfokon tetszőleges számú fél közötti tranzakciókat megvalósító protokollá bővíti ki. Maurice Herlihy észre veszi továbbá azt is, hogy a klasszikus “mindent-vagy-semmit” jellegű helyességi tulajdonság nem alkalmazható jól a láncok közötti cserékre és egy más jellegű helyesség fogalmat vezet be. Ez leszűkíti tárgyalásmódját, hiszen közvetlen cseréket használ és nem az olyan általános struktúrákra alapoz, amelyekkel a láncok közötti ügyletek során találkoztunk. Például arról beszél, hogy a részleges kimenetelek nem elfogadhatóak a felek számára, itt viszont arról volt szó, hogy a felek eldönthetik hogy kielégíti-e őket az adott ügylet kimenetele.
Az itt bemutatott időzár protokoll struktúrája jóval egyszerűbb, mint Herlihy protokollja. Az ő megvalósítása a felhasználók egy bizonyos csoportja által birtokolt titkos kulcson alapszik. A jelen tárgyalásmód ezeket a kulcsokat szavazatokkal helyettesíti és így hasonló módon lehet kezelni minden felet. Továbbá nincs szükség alaposan kigondolt szerződés létrehozó fázisra sem. A jelen protokoll meghatározza azt is, hogy a felek mikor ellenőrzik a tranzakciók eredményeit és mind a két megvalósítás út aláírásokon alapuló időzáras mechanizmust használ.
Zakhary és társai (Atomic Commitment Across Blockchains) hashelt időzárakat nem alkalmazó blokkláncok közötti végrehajtásos protokollt javasol. Az időzárak helyett a blokkláncok az állapotváltozások bizonyítékait cserélik egymás között. Ez valamelyest hasonló a CBC protokollhoz, de mivel minden félnek regisztrálnia kell a kívánt tranzakcióját az üzlet elején, ez a protokoll csak a feltételmentes tranzakciókat támogatja.
Léteznek láncon kívüli fizetési hálózatok (off-chain payment networks) és állapot csatornák (http://l4.ventures/papers/statechannels.pdf) is. Ezek hashelt időzáras szerződéseket használnak és így képesek megemelni a már létező blokkláncok skálázódási határait.
A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels
https://eprint.iacr.org/2016/701
https://www.arwen.io/whitepaper.pdf
https://raiden.network/101.html
https://lightning.network/lightning-network-paper.pdf
Ezek a megoldások számos blokkláncot nem érintő fizetési tranzakciókat eszközölnek és a végeredményt írák végül a blokkláncba. A hashelt időzáras szerződések miatt a csalók nem tudnak meghamisított végleges állapotot beírni a blokkláncba. Joshua Lind, Oded Naor, Ittay Eyal, Florian Kelbert, Peter Pietzuch és Emin Gun Sirer (Teechain: A Secure Payment Network with Asynchronous Blockchain Access) a szinkronizációs feltételek enyhítése céljából hardveres megbízható végrehajtási környezetet javasol. Még nem teljesen világos, hogy a blokkláncokat nem érintő hálózatokat hogyan lehetne felhasználni az ügyletek megvalósítására. Az Arwen (The Arwen Trading Protocols) egy olyan megoldást jelent, amely több mint egy blokkláncokat nem érintő tranzakciókat valósít meg felhasználók és tőzsdék között. Ez a megvalósítás valutákra specializálódik és nem támogat nem felosztható (non-fungible) vagyontárgyakat. A Komodo blokkláncokat nem érintő platformok közötti fizetéseket valósít meg.
A szilánkosított blokkláncok (sharded blockchain) olyan képződmények, amelyek a bejövő adatokat több tranzakciós blokkra osztják fel és ezek az állapotváltozások párhuzamosan mennek végbe. Támogatják továbbá a többlépcsős atomi tranzakciókat, amelyek több shard-on keresztül hajtódhatnak végre. A Chainspace esetében a több shard-on átívelő tranzakciók a kliens oldalon hajtódnak végre, az Omniledger esetében pedig a szerver oldalán. Ezekben a rendszerekben egy tranzakció egy megbízható felet reprezentál és nincs lehetőség olyan tranzakciókra, amelyekben megbízhatatlan felek szerepelnének. A Chainspace a szerver oldalon hoz létre megváltoztathatatlan szerződési bizonyítékokat. Ezen bizonyítékok segítségével validálják a kliensek által végrehajtott tranzakciókat és ez a módszer hasonlít az optimista konkurens vezérlésre.
A Channels az Omniledger Atomix protokollt bővíti ki és a jelen tárgyalásban szereplő CBC megoldáshoz hasonlóan a bizonyítékokat kétfázisú protokollban használja az atomi tranzakciók megvalósítására megbízhatatlan felek között több feles UTXO transzferekre. Ez viszont nem támogatja a többlépcsős ügyleteket vagy a megbonthatatlan vagyontárgyakat.
A BAR (bizánci, önzetlen és racionális) számítási modell autonóm adminisztrációs tartományok között valósít meg együttműködő szolgáltatásokat és ezek általában kiállják a bizánci és egyéb racionális támadásokat.
A bizánci hibatoleráns rendszerek a BAR-toleráns rendszerekhez hasonlóan korlátos bizánci hiba számot feltételez és emiatt a nem érdekegyeztetett ügyleti modellek leírására nem alkalmas, hiszen ezeknél bárhány fél lehet bizánci. A CBC valamelyest egy orákulumra hasonlít. Az orákulum jelen tárgyalásban egy megbízható adatforrás, amely a szerződéseket látja el a fizikai világból jövő adatokkal.
A nem érdekegyeztetett kereskedelem előfutárai voltak a szövetségi adatbázisok (federated databases). Az ilyen irányú kutatások olyan tranzakciókat vizsgáltak, amelyek heterogén, egymásban nem bízó autonóm adatbázisok közt zajlottak. Ezen adatbázisok nem próbáltak meg védekezni semmilyen bizánci támadás ellen.
Az ügyletek segítségével motiválni lehet a felhasználókat az igazmondásra. El lehet képzelni olyan felállást, amelyben egy fél befagyaszt bizonyos mennyiségű kriptovalutát és ezt elveszik tőle ha ő miatta bukik el a tranzakció. A motivációs mechanizmusokat jelenleg is aktívan kutatják és nagyon nem mindegy hogyan implementáljuk őket. Az időzáras megoldásban ha az időzárat túl kicsire választják, akkor a rendszer szolgáltatás megtagadásos támadással gyengíthető és a felek akár el is veszthetik bejövő vagyontárgyaikat. A CBC protokoll hasonló veszélynek van kitéve, de itt kicsit más a helyzet mert a vagyontárgyak nem vesznek el, csak a támadás idejére maradnak befagyasztva. Ennél nagyobb probléma lehet a cenzúra, amelyet a CBC blokklánc résztvevői gyakorolhatnak. A CBC hitelesítők dönthetnek úgy hogy bizonyos tranzakciókat szándékosan elvetnek. További jelentős különbség a CBC és az időzár protokoll között a hitelesítendő aláírások számában rejlik. N résztvevő mellett f + 1 hitelesítőre van szükség. A legtöbb ügylet csak néhány fél között fog lezajlani. Ilyen esetekben a CBC-s megoldás drágább lehet, mint az időzáras megoldás. Ha több fél szerepel az ügyletben, akkor pedig a fordítottja igaz ennek. A CBC protokoll használata ugyan drágább, de szigorúbb késleltetéseket szab meg a felhasználók számára.
A modern elosztott adatmenedzselő rendszerek új igényeket kell hogy kielégítsenek. Autónóm felek között kell ügyleteket lebonyolítani, mégpedig úgy hogy ezek a felek közben nem bíznak meg egymásban. A régebbi megoldások, mint például az elosztott atomi tranzakciók vagy a láncok közötti cserék nem alkalmasak az ilyen jellegű bizalmi rendszerek leírására, általában nem rendelkeznek elegendő kifejező erővel. A klasszikus elosztott rendszerekben a felek megbízhatóak. A replika csoportokhoz hasonló megoldások segítségével megoldhatók a leállások és a bizánci támadásokat is ki lehet védeni és így garantálható a bizalom. Ezen esetekben a számításokat atomi tranzakciók mintájára szervezik és egyszerre csak egyet engednek futni. Így az vagy teljes mértékben lefut, vagy semmi nem történik sehol.
Ezekkel ellentétben a nem érdekegyeztetett kereskedelem során a felek eldönthetik minden alkalommal, hogy részt akarnak-e venni az ügyletben. A felek megegyeznek, hogy egy közös protokoll-t fognak követni és a szabályok betartását lehet ellenőrzni, de nem lehet kényszeríteni a feleket azok betartására. A helyesség lokálisan van értelme és bizonyos értelemben ez egy önző tulajdonság. Magyarul egyik fél sem kerül rosszabb helyzetbe az ügylet lefutása után, mint amilyenben volt. Még akkor se ha vannak rosszindulatú felhasználók. Rosszindulatú felhasználók pedig szerepelhetnek tetszőleges mértékben.
A nem érdekegyeztetett kereskedelemre jó példa lehet a részvények kereskedelme, a digitális vagyontárgyak kezelése, az IoT rendszerek, az ellátási láncok és természetesen a kriptovaluták is. A láncok közötti tranzakciókat könnyű összekeverni az atomi tranzakciókkal és a láncok közötti cserékkel, hiszen ezek mind hasonló feladatok megoldására lettek kitalálva. Remélhetőleg a fenti néhány sor sokaknak segít majd a megfelelő különbségek megértésében.
Szerző: LB
Figyelem: A bejegyzésben található információk tartalmazhatnak hibát. A szerző az abból eredő károkért nem vállal felelősséget!
