Intelligens szerződés leszámolás: Hyperledger Fabric vs MultiChain vs Ethereum vs Corda

Egynél több módja van annak, hogy kódot helyezzünk el a blokkláncon

A legtöbb blokkláncról szóló vita során nem tart sokáig, amíg az „intelligens szerződések” fogalma megjelenik. A népszerű képzelet szerint az intelligens szerződések automatizálják a felek közötti interakciók végrehajtását anélkül, hogy megbízható közvetítőre lenne szükségük. Azzal, hogy a jogviszonyokat szavak helyett kódban fejezik ki, azt ígérik, hogy lehetővé teszik a tranzakciók közvetlen és hibamentes lebonyolítását, akár szándékosak, akár nem.

From a technical viewpoint, a smart contract is something more specific: computer code that lives on a blockchain and defines the rules for that chain’s transactions. This description sounds simple enough, but behind it lies a great deal of variation in how these rules are expressed, executed and validated. When choosing a blockchain platform for a new application, the question “Does this platform support smart contracts?” isn’t the right one to ask. Instead, we need to be asking: “What type of smart contracts does this platform support?”

Ebben a cikkben az a célom, hogy megvizsgáljak néhány fő különbséget az intelligens szerződéses megközelítések és az általuk képviselt kompromisszumok között. Ezt úgy teszem meg, hogy megvizsgálok négy népszerű vállalati blokklánc-platformot, amelyek támogatnak valamilyen testreszabott láncon belüli kódot. Először is az IBM-é Hyperledger szövet, amely szerződéseit „lánckódnak” nevezi. Másodszor, a MultiChain platformunk, amely bemutatja intelligens szűrők 2.0 verzióban. Harmadik, Ethereum (és engedélyezett kvórum és a Ás spin-off), amely népszerűsítette az „okos szerződés” nevet. És végül, R3 Corda, amely tranzakcióiban „szerződésekre” hivatkozik. Az eltérő terminológia ellenére ezek mindegyike ugyanarra a dologra vonatkozik – egy alkalmazás-specifikus kódra, amely meghatározza a lánc szabályait.

Mielőtt továbbmennék, figyelmeztetnem kell az olvasót, hogy az alábbi tartalom nagy része technikai jellegű, és feltételezi az általános programozási és adatbázis-koncepciók ismeretét. Jóban vagy rosszban ezt nem lehet elkerülni – a részletekbe való belemerülés nélkül lehetetlen megalapozott döntést hozni arról, hogy használjunk-e blokkláncot egy adott projekthez, és (ha igen) a megfelelő típusú blokkláncot.

A blokklánc alapjai

Kezdjük egy kis kontextussal. Képzeljen el egy alkalmazást, amelyet több szervezet is megoszt, és amely egy mögöttes adatbázison alapul. A hagyományos központosított architektúrában ezt az adatbázist egyetlen fél üzemelteti és kezeli, amelyben minden résztvevő megbízik, még akkor is, ha nem bíznak egymásban. Az adatbázist módosító tranzakciókat csak a központi fél rendszerein lévő alkalmazások kezdeményezik, gyakran a résztvevőktől kapott üzenetekre válaszul. Az adatbázis egyszerűen azt csinálja, amit mondanak neki, mert az alkalmazás implicit módon csak az értelmes tranzakciókat küldi neki.

A blokkláncok alternatív módszert kínálnak a megosztott adatbázisok kezelésére megbízható közvetítő nélkül. A blokkláncban minden résztvevő egy „csomópontot” futtat, amely az adatbázis másolatát tartalmazza, és függetlenül dolgozza fel az azt módosító tranzakciókat. A résztvevőket nyilvános kulcsok vagy „címek” segítségével azonosítják, amelyek mindegyike rendelkezik egy megfelelő privát kulccsal, amelyet csak az identitás tulajdonosa ismer. Bár a tranzakciókat bármely csomópont létrehozhatja, a kezdeményező privát kulcsa „digitálisan aláírja” őket, hogy igazolják származásukat.

A csomópontok peer-to-peer módon kapcsolódnak egymáshoz, gyorsan terjesztik a tranzakciókat és azokat a „blokkokat”, amelyekben azokat időbélyeggel látják el és megerősítik a hálózaton keresztül. Maga a blokklánc szó szerint ezeknek a blokkoknak a lánca, amely rendezett naplót képez minden történeti tranzakcióról. Egy „konszenzus-algoritmust” használnak annak biztosítására, hogy minden csomópont megegyezzen a blokklánc tartalmáról, anélkül, hogy központi vezérlésre lenne szükség. (Ne feledje, hogy ennek a leírásnak egy része nem vonatkozik a Cordára, ahol minden csomópontnak csak egy részleges másolata van az adatbázisból, és nincs globális blokklánc. Erről a későbbiekben többet fogunk beszélni.)

Elvileg minden megosztott adatbázis-alkalmazás megépíthető blokklánc használatával. Ez azonban számos technikai kihívást vet fel, amelyek központi forgatókönyv esetén nem léteznek:

• Tranzakciós szabályok. Ha bármelyik résztvevő közvetlenül módosíthatja az adatbázist, hogyan biztosítjuk, hogy betartsa az alkalmazás szabályait? Mi akadályozza meg a felhasználót abban, hogy öncélúan megsértse az adatbázis tartalmát?
• Determinizmus. Miután ezeket a szabályokat meghatározták, több csomópont többször alkalmazza őket az adatbázis saját példányára vonatkozó tranzakciók feldolgozásakor. Hogyan biztosíthatjuk, hogy minden csomópont pontosan ugyanazt az eredményt kapja?
• Konfliktusmegelőzés. Központi koordináció nélkül hogyan kezeljünk két olyan tranzakciót, amelyek mindegyike betartja az alkalmazás szabályait, de mégis ütközik egymással? A konfliktusok származhatnak a rendszer megjátszásának szándékos kísérletéből, vagy a balszerencse és az időzítés ártatlan következményei.

Tehát hol jönnek be az intelligens szerződések, az intelligens szűrők és a lánckód? Fő céljuk, hogy a blokklánc mögöttes infrastruktúrával dolgozzanak, hogy megoldják ezeket a kihívásokat. Az intelligens szerződések az alkalmazáskód decentralizált megfelelői – ahelyett, hogy egy központi helyen futnának, a blokklánc több csomópontján futnak, létrehozva vagy érvényesítve azokat a tranzakciókat, amelyek módosítják az adatbázis tartalmát.

Kezdjük a tranzakciós szabályokkal, az első kihívásokkal, és nézzük meg, hogyan fejeződnek ki ezek a Fabric, a MultiChain, az Ethereum és a Corda esetében.

Tranzakciós szabályok

A tranzakciós szabályok meghatározott funkciót látnak el a blokklánc alapú adatbázisokban – korlátozzák a transzformációk amely az adott adatbázis állapotán végrehajtható. Erre azért van szükség, mert a blokklánc tranzakcióit bármelyik résztvevő kezdeményezheti, és ezek a résztvevők nem bíznak eléggé egymásban ahhoz, hogy tetszés szerint módosíthassák az adatbázist.

Lássunk két példát arra, hogy miért van szükség tranzakciós szabályokra. Először is képzeljünk el egy blokkláncot, amelyet a résztvevők által közzétett PDF-dokumentumok összesítésére és időbélyegzésére terveztek. Ebben az esetben senkinek ne legyen joga dokumentumokat eltávolítani vagy megváltoztatni, mert ezzel a rendszer teljes célját – a dokumentumok fennmaradását – aláásná. Másodszor, fontolja meg a blokkláncot, amely egy megosztott pénzügyi főkönyvet képvisel, amely nyomon követi a felhasználók egyenlegét. Nem engedhetjük meg, hogy egy résztvevő önkényesen felfújja saját egyenlegét, vagy elvegye mások pénzét.

Bemenetek és kimenetek

Blokklánc-platformjaink két átfogó megközelítésre támaszkodnak a tranzakciós szabályok kifejezésére. Az elsőt, amelyet „input-output modellnek” nevezek, a MultiChain és a Corda használja. Itt a tranzakciók kifejezetten felsorolják azokat az adatbázissorokat vagy „állapotokat”, amelyeket törölnek és létrehoznak, „bemenetek” és „kimenetek” halmazát alkotva. Egy sor módosítása a sor törlésének és a helyére új létrehozásának megfelelő műveletként fejeződik ki.

Mivel az adatbázis sorai csak a bemenetekben törlődnek, és csak a kimenetekben jönnek létre, minden bemenetnek „el kell költenie” egy korábbi tranzakció kimenetét. Az adatbázis aktuális állapota a „fel nem használt tranzakciós kimenetek” vagy „UTXO-k”, azaz a korábbi tranzakciókból származó, még fel nem használt kimenetek halmaza. A tranzakciók további információkat is tartalmazhatnak, úgynevezett „metaadatokat”, „parancsokat” vagy „mellékleteket”, amelyek nem válnak az adatbázis részévé, de segítenek meghatározni jelentésüket vagy céljukat.

A bemenetek, kimenetek és metaadatok e három készletét figyelembe véve a MultiChain vagy a Corda tranzakcióinak érvényességét valamilyen kód határozza meg, amely tetszőleges számításokat végezhet ezeken a halmazokon. Ez a kód érvényesítheti a tranzakciót, vagy hibaüzenetet küldhet a megfelelő magyarázattal. Az input-output modellt úgy képzelheti el, mint egy automatizált „ellenőrt”, amely egy ellenőrzőlistát tart, amely biztosítja, hogy a tranzakciók minden egyes szabályt betartsanak. Ha a tranzakció valamelyik ellenőrzésen sikertelen, akkor azt a hálózat összes csomópontja automatikusan elutasítja.

Megjegyzendő, hogy az input-output modell megosztása ellenére a MultiChain és a Corda nagyon eltérően valósítja meg. A MultiChainben a kimenetek JSON, szöveges vagy bináris formátumú eszközöket és/vagy adatokat tartalmazhatnak. A szabályokat „tranzakciós szűrőkben” vagy „folyamszűrőkben” határozzák meg, amelyek beállíthatók úgy, hogy az összes tranzakciót ellenőrizzék, vagy csak azokat, amelyek bizonyos eszközöket vagy adatcsoportokat érintenek. Ezzel szemben a Corda kimeneti „állapotot” egy objektum reprezentálja a Java vagy a Kotlin programozási nyelvben, meghatározott adatmezőkkel. A Corda szabályait „szerződésekben” határozzák meg, amelyek meghatározott állapotokhoz kapcsolódnak, és egy állam szerződése csak azokra a tranzakciókra vonatkozik, amelyek bemenetei vagy kimenetei tartalmazzák ezt az állapotot. Ez a Cordára vonatkozik szokatlan láthatósági modell, amelyben a tranzakciókat csak a partnereik láthatják, vagy azok, akiknek a későbbi tranzakcióit érintik.

Szerződések és üzenetek

A második megközelítést, amelyet „szerződés-üzenet modellnek” nevezek, a Hyperledger Fabric és az Ethereum használja. Itt több „intelligens szerződés” vagy „lánckód” hozható létre a blokkláncon, és mindegyiknek saját adatbázisa és kapcsolódó kódja van. Egy szerződés adatbázisa csak a kódjával módosítható, nem pedig közvetlenül a blokklánc-tranzakciókkal. Ez a tervezési minta hasonló a kód és az adatok „beágyazásához” az objektumorientált programozásban.

Ezzel a modellel a blokklánc-tranzakció egy szerződésnek küldött üzenetként kezdődik, néhány opcionális paraméterrel vagy adattal. A szerződés kódja az üzenetre és a paraméterekre reagálva fut le, és ennek részeként szabadon olvashatja és írhatja saját adatbázisát. A szerződések üzeneteket is küldhetnek más szerződéseknek, de nem férhetnek hozzá közvetlenül egymás adatbázisaihoz. A relációs adatbázisok nyelvén a szerződések úgy működnek, mint érvényesíteni „tárolt eljárások”, ahol az adatbázishoz való minden hozzáférés valamilyen előre meghatározott kódon keresztül történik.

Mind a Fabric, mind a Quorum, az Ethereum egyik változata bonyolítja ezt a képet azáltal, hogy lehetővé teszi a hálózat számára több „csatorna” vagy „privát állapot” meghatározását. A cél a blokklánc titkosságának problémájának enyhítése külön környezetek létrehozásával, amelyek mindegyike csak a résztvevők egy bizonyos alcsoportja számára látható. Bár ez elméletben ígéretesnek hangzik, a valóságban az egyes csatornákban vagy magánállapotokban lévő szerződések és adatok el vannak szigetelve a többitől. Ennek eredményeként az intelligens szerződések szempontjából ezek a környezetek egyenértékűek a különálló blokkláncokkal.

Példaszabályok

Nézzük meg, hogyan valósíthatjuk meg a tranzakciós szabályokat egy egyeszközös pénzügyi főkönyvhez ezzel a két modellel. Főkönyvi adatbázisunk minden sora két oszloppal rendelkezik, amelyek a tulajdonos címét és a birtokolt eszköz mennyiségét tartalmazzák. Az input-output modellben a tranzakcióknak két feltételnek kell megfelelniük:

1. A tranzakció kimeneteiben szereplő eszközök teljes mennyiségének meg kell egyeznie a bemenetek teljes mennyiségével. Ez megakadályozza, hogy a felhasználók önkényesen pénzt hozzanak létre vagy töröljenek.
2. Minden tranzakciót minden egyes bemenet tulajdonosának alá kell írnia. Ez megakadályozza, hogy a felhasználók engedély nélkül költsék egymás pénzét.

Ez a két feltétel együttesen mindössze egy egyszerű, de életképes pénzügyi rendszer létrehozásához szükséges.

A szerződés-üzenet modellben az eszköz szerződése támogatja a „fizetés küldése” üzenetet, amely három paramétert vesz fel: a feladó címét, a címzett címét és a küldendő mennyiséget. Válaszul a szerződés a következő négy lépést hajtja végre:

1. Ellenőrizze, hogy a tranzakciót a feladó aláírta-e.
2. Ellenőrizze, hogy a feladónak van-e elegendő pénze.
3. A kért mennyiséget vonja le a feladó sorából.
4. Adja hozzá ezt a mennyiséget a címzett sorához.

Ha az első két lépésben valamelyik ellenőrzés sikertelen, a szerződés megszakad, és nem történik kifizetés.

Tehát mind a bemenet-kimenet, mind a szerződés-üzenet modell hatékony módja a tranzakciós szabályok meghatározásának és a megosztott adatbázisok biztonságának megőrzésének. Valójában elméleti szinten ezek a modellek mindegyike felhasználható a másik szimulálására. A gyakorlatban azonban a legmegfelelőbb modell a készülő alkalmazástól függ. Az egyes tranzakciók kevés vagy sok információt érintenek? Garantálni kell a tranzakciós függetlenséget? Minden adatnak egyértelmű tulajdonosa van, vagy van valamilyen globális állapot, amelyet meg kell osztani?

Nem áll rendelkezésünkre annak megvizsgálása, hogy a válaszok hogyan befolyásolják a két modell közötti választást. De általános irányelvként egy új blokklánc-alkalmazás fejlesztésekor érdemes megpróbálni mindkét formában kifejezni a tranzakciós szabályait, és megnézni, melyik passzol természetesebben. A különbség a következőkben fejeződik ki: (a) a programozás egyszerűsége, (b) a tárolási követelmények és az átviteli sebesség, valamint (c) az ütközések észlelésének sebessége. Az utolsó számról a későbbiekben többet fogunk beszélni.

Beépített szabályok

Ami a tranzakciós szabályokat illeti, van egy mód, amiben a MultiChain kifejezetten különbözik a Fabrictól, az Ethereumtól és a Cordától. Ezekkel a többi platformmal ellentétben a MultiChain számos beépített absztrakcióval rendelkezik, amelyek néhány alapvető építőelemet biztosítanak a blokklánc-vezérelt alkalmazásokhoz, anélkül igénylő a fejlesztők saját kódot írhatnak. Ezek az absztrakciók három általánosan szükséges területet fednek le: (a) dinamikus engedélyek, (b) átruházható eszközök és (c) adattárolás.

Például a MultiChain kezeli a hálózathoz való csatlakozás, a tranzakciók küldésének és fogadásának, az eszközök vagy adatfolyamok létrehozásának vagy más felhasználók engedélyeinek szabályozásának engedélyeit. Több helyettesíthető eszköz is biztonságosan és atomosan kibocsátható, átruházható, nyugdíjba vonható vagy cserélhető. Egy láncon tetszőleges számú „folyam” hozható létre a láncon belüli vagy a láncon kívüli adatok közzétételéhez, indexeléséhez és lekéréséhez JSON, szöveges vagy bináris formátumban. Ezen absztrakciókra vonatkozó összes tranzakciós szabály azonnal elérhető.

Amikor egy alkalmazást fejlesztünk a MultiChain rendszeren, figyelmen kívül hagyhatjuk ezt a beépített funkciót, és kizárólag intelligens szűrők használatával kifejezhetjük a tranzakciós szabályokat. Az intelligens szűrőket azonban úgy tervezték, hogy együttműködjenek a beépített absztrakcióival, lehetővé téve alapértelmezett viselkedésük korlátozott testreszabott módokon. Például előfordulhat, hogy bizonyos tevékenységek engedélyét meghatározott rendszergazdák szabályozzák, nem pedig az alapértelmezett viselkedést, amelyet bármelyik rendszergazda megtesz. Bizonyos eszközök átruházása idővel korlátozható, vagy egy bizonyos összeg felett további jóváhagyást igényelhet. Egy adott adatfolyamban lévő adatok ellenőrizhetők annak biztosítására, hogy csak a kötelező mezőket és értékeket tartalmazó JSON-struktúrákból álljanak.

Ezekben az esetekben az intelligens szűrők további követelményeket támasztanak a tranzakciók érvényesítéséhez, de nem eltávolítása Ez segíthet a blokklánc-alkalmazások egyik kulcsfontosságú kihívásának megoldásában: azt a tényt, hogy a láncon belüli kódok hibája katasztrofális következményekkel járhat. Ennek a problémának végtelen számú példáját láttuk a nyilvános Ethereum blokkláncban, leghíresebben a A DAO megszűnése és a Paritásos multisignature hibák. Szélesebb körű felmérések számos gyakori sebezhetőséget találtak az Ethereum intelligens szerződéseiben, amelyek lehetővé teszik a támadók számára, hogy ellopják vagy befagyasztsák mások pénzét.

Természetesen a MultiChain intelligens szűrők is tartalmazhatnak hibákat, de ezek következményei korlátozottabbak. Például a beépített eszközszabályok megakadályozzák, hogy egy felhasználó más pénzét költse el, vagy véletlenül saját pénzét tegyék el, függetlenül attól, hogy egy intelligens szűrő milyen logikát tartalmaz. Ha hibát találunk egy intelligens szűrőben, akkor az deaktiválható és kicserélhető egy javított verzióra, miközben a főkönyv alapvető integritása védett. Filozófiailag a MultiChain közelebb áll a hagyományos adatbázis-architektúrákhoz, ahol az adatbázisplatform számos beépített absztrakciót biztosít, például oszlopokat, táblákat, indexeket és megszorításokat. Hatékonyabb funkciókat, például triggereket és tárolt eljárásokat, az alkalmazásfejlesztők opcionálisan kódolhatnak, ha valóban szükség van rájuk.

Tranzakciós szabályok	Szövet	MultiChain	Ethereum	Corda
Modell	Szerződés – üzenet	Bemenet kimenet	Szerződés – üzenet	Bemenet kimenet
Beépítettek	Egyik sem	Engedélyek + eszközök + folyamok	Egyik sem	Egyik sem

Determinizmus

Térjünk át leszámolásunk következő részére. Nem számít, melyik megközelítést választjuk, a blokklánc-alkalmazások egyedi tranzakciós szabályait az alkalmazásfejlesztők által írt számítógépes kódok fejezik ki. És a központosított alkalmazásokkal ellentétben ez a kód többször és több helyen is végrehajtásra kerül minden tranzakcióhoz. Ennek az az oka, hogy a különböző résztvevőkhöz tartozó több blokklánc-csomópontnak mindegyiknek saját magának kell ellenőriznie és/vagy végrehajtania ezt a tranzakciót.

Ez az ismételt és redundáns kódvégrehajtás egy új követelményt vezet be, amely ritkán található meg a központosított alkalmazásokban: a determinizmust. A számítással összefüggésben a determinizmus azt jelenti, hogy egy kódrészlet mindig ugyanazt a választ adja ugyanazokra a paraméterekre, függetlenül attól, hogy hol és mikor futják. Ez rendkívül fontos a blokklánccal kölcsönhatásba lépő kódok esetében, mert determinizmus nélkül a lánc csomópontjai közötti konszenzus katasztrofálisan megromolhat.

Nézzük meg, hogyan néz ki ez a gyakorlatban, először az input-output modellben. Ha két csomópontnak eltérő véleménye van arról, hogy egy tranzakció érvényes-e, akkor az egyik elfogadja az adott tranzakciót tartalmazó blokkot, a másik pedig nem. Mivel minden blokk kifejezetten visszakapcsol egy előző blokkhoz, ez egy állandó „elágazást” hoz létre a hálózatban, ahol egy vagy több csomópont attól kezdve nem fogadja el a többségi véleményt a teljes blokklánc tartalmáról. A kisebbségben lévő csomópontok el lesznek vágva az adatbázis fejlődő állapotától, és többé nem fogják tudni hatékonyan használni az alkalmazást.

Most pedig nézzük meg, mi történik, ha a konszenzus megbomlik a szerződés-üzenet modellben. Ha két csomópontnak eltérő a véleménye arról, hogy egy szerződésnek hogyan kell válaszolnia egy adott üzenetre, az adatbázisaik tartalmában eltéréseket okozhat. Ez viszont befolyásolhatja a szerződés jövőbeli üzenetekre adott válaszát, beleértve a más szerződéseknek küldött üzeneteket is. A végeredmény egy növekvő eltérés a különböző csomópontok nézetei között az adatbázis állapotáról. (Az „állapotgyökér” mező az Ethereum blokkokban biztosítja, hogy a szerződésekre adott válaszok bármilyen eltérése azonnal teljesen katasztrofális blokklánc-elágazáshoz vezessen, ahelyett, hogy egy ideig rejtve maradna.)

A non-determinizmus forrásai

Tehát a blokklánc-kód nem-determinizmusa egyértelműen probléma. De ha a számítás alapvető építőkövei, mint például az aritmetika, determinisztikusak, mitől kell aggódnunk? Nos, kiderült, jó néhány dolog:

• A legnyilvánvalóbb a véletlenszám-generátorok, mivel ezek a definíció szerint minden alkalommal más eredményt produkálnak.
• Az aktuális idő ellenőrzése, mivel a csomópontok nem pontosan ugyanabban az időben dolgozzák fel a tranzakciókat, és minden esetben előfordulhat, hogy az óráik nincsenek szinkronban. (Továbbra is lehetséges időfüggő szabályokat megvalósítani, ha magán a blokkláncon belüli időbélyegekre hivatkozunk.)
• Külső erőforrások, például az internet, a lemezfájlok vagy a számítógépen futó egyéb programok lekérdezése. Nem garantálható, hogy ezek az erőforrások mindig ugyanazt a választ adják, és elérhetetlenné válhatnak.
• Több kódrészlet párhuzamos „szálak” futtatása, mivel ez egy „versenyfeltételhez” vezet, ahol nem lehet megjósolni, hogy ezek a folyamatok milyen sorrendben fejeződnek be.
• Bármilyen lebegőpontos számítás elvégzése, amely akár aprólékosan eltérő válaszokat is adhat a különböző számítógépes processzor architektúrákon.

Négy blokklánc-platformunk többféle megközelítést alkalmaz ezen buktatók elkerülésére.

Determinisztikus végrehajtás

Kezdjük az Ethereummal, mivel annak megközelítése a legtisztább. Az Ethereum-szerződések egy speciális célú „Ethereum bytecode” formátumban vannak kifejezve, amelyet az Ethereum Virtual Machine (“EVM”) hajt végre. A programozók nem írnak közvetlenül bájtkódot, hanem a Solidity nevű JavaScript-szerű programozási nyelvből generálják vagy „fordítják”. (Régebben más nyelvek is elérhetők voltak, de azóta elavult.) A determinizmust az a tény garantálja, hogy a Solidity és az Ethereum bájtkód nem képes semmilyen nem determinisztikus műveletet kódolni – ilyen egyszerű.

A MultiChain szűrők és a Corda szerződések más megközelítést választanak a meglévő programozási nyelvek és futási környezetek adaptálásával. A MultiChain a Google-ban futó JavaScriptet használja V8 motor, amely a Chrome böngésző és a Node.js platform magját is képezi, de a nem-determinizmus forrásai le vannak tiltva. Hasonlóan a Corda Java ill Kotlin, mindkettő „Java bájtkódra” van fordítva, amely egy Java virtuális gépen („JVM”) belül fut le. A Corda egyelőre az Oracle szabványos, nem determinisztikus JVM-jét használja, de folyamatban van egy determinisztikus változat. Addig is a Corda szerződéses fejlesztőinek ügyelniük kell arra, hogy kódjukban ne engedjék meg a determinizmust.

Hogyan hasonlítható össze az Ethereum purizmusa a MultiChain és a Corda evolúciós megközelítésével? Az Ethereum fő előnye a kockázat minimalizálása – egy erre a célra épített virtuális gép kevésbé valószínű, hogy nem-determinizmus véletlen forrását tartalmazná. Bár minden ilyen hiba kijavítható egy szoftverfrissítéssel, megzavarná minden olyan láncot, amelyik szerencsétlenül szembesül vele. Az Ethereum problémája azonban az, hogy a Solidity és az EVM egy apró és születőben lévő ökoszisztémát alkotnak a programozási nyelvek és futási környezetek tágabb kontextusában. Összehasonlításképpen a JavaScript és a Java a két legnépszerűbb nyelv a Githubon, több milliárd digitális eszközön fut, és évtizedek óta optimalizált futási időkkel rendelkezik. Valószínűleg ezért fontolgatja a nyilvános Ethereum blokklánc az átállást eWASM, a kialakulóban lévő WebAssembly szabvány determinisztikus villája.

Determinizmus jóváhagyással

Ami a determinizmust illeti, a Hyperledger Fabric teljesen más megközelítést alkalmaz. A Fabric alkalmazásban, amikor egy „kliens” csomópont üzenetet szeretne küldeni valamilyen lánckódnak, először elküldi ezt az üzenetet néhány „endorser” csomópontnak. Ezen csomópontok mindegyike függetlenül hajtja végre a lánckódot, véleményt alkotva az üzenetről hatás az adott lánckód adatbázisában. Ezeket a véleményeket digitális aláírással együtt küldik vissza az ügyfélnek, ami formális „jóváhagyásnak” minősül. Ha az ügyfél elegendő jóváhagyást kap a tervezett eredményről, létrehoz egy tranzakciót, amely tartalmazza ezeket a jóváhagyásokat, és továbbítja azt a láncba való felvétel céljából.

A determinizmus garantálása érdekében a lánckód minden egyes darabjához tartozik egy „jóváhagyási politika”, amely pontosan meghatározza, hogy milyen szintű jóváhagyás szükséges ahhoz, hogy tranzakciói érvényesek legyenek. Például egy lánckód házirendje kimondhatja, hogy a blokklánc csomópontjainak legalább felétől támogatásra van szükség. Egy másikhoz szükség lehet a három megbízható fél bármelyikének jóváhagyására. Akárhogy is, minden csomópont függetlenül tudja ellenőrizni, hogy megkapta-e a szükséges jóváhagyásokat.

A különbség tisztázása érdekében a legtöbb blokklánc-platformon a determinizmus a következő kérdésen alapul: „Mi az eredménye a kód futtatásának ezeken az adatokon?” – és teljesen biztosnak kell lennünk abban, hogy minden csomópont azonosan fog válaszolni erre a kérdésre. Ezzel szemben a Fabric determinizmusa egy másik kérdésen alapul: „Elegendő támogató egyetért a kód futtatásának eredményével ezeken az adatokon?” Ennek megválaszolása meglehetősen egyszerű számolás, és nincs helye a nem-determinizmusnak.

A szövet jóváhagyás általi determinizmusa számos érdekes következménnyel jár. Először is, a lánckód számos különböző programozási nyelven írható, mivel ezeket nem kell a determinizmushoz igazítani (jelenleg a Go, a Java és a JavaScript támogatott). Másodszor, a lánckód elrejthető a blokklánc egyes résztvevői elől, mivel azt csak az ügyfeleknek és a támogatóknak kell végrehajtaniuk (maga az adatbázis globálisan látható). Végül és legfőképpen a Fabric lánckód olyan dolgokat tud végrehajtani, amelyek más blokklánc-környezetekben tiltottak, például az időjárás ellenőrzése egy online webes API segítségével. A legrosszabb esetben, amikor minden jóváhagyó eltérő választ kap ettől az API-tól, az ügyfél nem szerez elegendő jóváhagyást bármely konkrét eredményhez, és nem kerül sor tranzakcióra. (Megjegyzendő, hogy a Fabric csapat tagjai még mindig ajánl determinisztikus logika használatával a lánckódon belül a meglepetések elkerülése érdekében.)

Milyen árat fizet a Fabric ezért a rugalmasságért? Ha a blokklánc célja az, hogy eltávolítsa a közvetítőket egy megosztott adatbázis-vezérelt alkalmazásból, akkor a Fabric támogatókra való támaszkodása nagy lépést tesz ettől a céltól. A lánc résztvevői számára már nem elég betartani a lánckód szabályait – bizonyos más csomópontokra is szükségük van ahhoz, hogy beleegyezzenek, hogy ezt megtették. Még ennél is rosszabb, hogy a támogatók rosszindulatú részhalmaza jóváhagyhat olyan adatbázis-módosításokat, amelyek egyáltalán nem követik a lánckódot. Ez sokkal nagyobb hatalmat biztosít a jóváhagyóknak, mint a hagyományos blokkláncok érvényesítői, akik cenzúrázhatják a tranzakciókat, de nem sérthetik meg a blokklánc szabályait. A blokklánc-alkalmazások fejlesztőinek el kell dönteniük, hogy az ő esetükben van-e értelme ennek a kompromisszumnak.

Determinizmus	Szövet	MultiChain	Ethereum	Corda
Modell	Elismerések	Adaptált futásidő	Célra épített virtuális gép	Adaptált futásidő
Nyelvek	Go + Java + JavaScript	JavaScript	szilárdság	Java + Kotlin
Kód láthatósága	Partnerek + támogatók	Blockchain	Blockchain	Partnerek + eltartottak
kényszerítve	Nem	Igen	Igen	Nem (egyelőre)

Konfliktusmegelőzés

Eddig azt tárgyaltuk, hogy a különböző blokklánc platformok hogyan fejezik ki kódban a tranzakciós szabályokat, és hogyan biztosítják determinisztikusan, hogy minden csomópont azonos módon alkalmazza ezeket a szabályokat. Itt az ideje, hogy beszéljünk leszámolásunk harmadik aspektusáról: Hogyan kezelik az egyes platformok azt a lehetőséget, hogy két, önmagában is érvényes tranzakció ütközik egymással? A legegyszerűbb példában képzeljük el, hogy Alice-nek 10 dollárja van a pénzügyi főkönyvben, és két tranzakciót sugároz – az egyik 8 dollárt küld Bobnak, a másik pedig 7 dollárt Charlie-nak. Nyilvánvaló, hogy ezen tranzakciók közül csak az egyiknek engedhető meg, hogy sikeres legyen.

Két modell

Kezdhetjük azzal, hogy csoportosítjuk a MultiChain és a Corda megközelítését a problémára. Amint azt korábban leírtuk, mindkettő bemenet-kimeneti modellt használ a tranzakciók és szabályaik ábrázolására, amelyben minden tranzakció bemenet egy korábbi tranzakció kimenetét költi el. Ez egy egyszerű elvhez vezet a konfliktusok megelőzésére: Minden kimenet csak egyszer költhető el. A MultiChain szűrők és a Corda-szerződések a megfelelő platformjukra támaszkodhatnak a korlátozás teljes érvényesítésében. Mivel Alice 10 dollárját egy korábbi tranzakció kimenete képviseli, ez az egyszeri költés szabály automatikusan leállítja, hogy elküldje Bobnak és Charlie-nak.

E hasonlóság ellenére fontos rámutatni egy alapvető különbségre a MultiChain és a Corda konfliktusok megelőzésében. A MultiChainben minden csomópont minden tranzakciót lát, így függetlenül ellenőrizheti, hogy minden kimenet csak egyszer kerül elköltésre. Minden olyan tranzakció, amely kétszeres költést hajt végre egy korábban megerősített tranzakcióval szemben, azonnal és automatikusan elutasításra kerül. Ezzel szemben a Cordában nincs globális blokklánc, ezért „közjegyzőkre” van szükség, hogy megakadályozzák ezt a dupla költést. Minden Corda kimeneti állapot egy közjegyzőhöz van hozzárendelve, akinek alá kell írnia az adott kimenetet elköltő tranzakciókat, megerősítve, hogy korábban nem költötték el. A blokklánc résztvevőinek meg kell bízniuk a közjegyzőkben, hogy őszintén betartsák ezt a szabályt, és a rosszindulatú közjegyzők tetszés szerint pusztítást okozhatnak. Akárcsak a Fabric bejegyzéseinél, ez a „egyszeri költés szolgáltatásként” tervezésnek előnyei vannak a titoktartás tekintetében, de újra bevezeti a közvetítőket, szembemenve a blokklánc-szemponttal. (Fontos tisztázni, hogy a Corda közjegyzőket konszenzusos algoritmus segítségével csoportok is működtethetik, így a főkönyv sértetlensége továbbra is védhető az egyes rossz szereplőkkel szemben).

Térjünk át az Ethereumra. Emlékeztetni kell arra, hogy az Ethereum szerződéseket és üzeneteket használ, nem pedig bemeneteket és kimeneteket. Ennek eredményeként az olyan tranzakciós ütközések, mint például Alice két fizetése, nem láthatók azonnal a blokklánc-motor számára. Ehelyett észleli és blokkolja őket a szerződés amely feldolgozza a tranzakciókat, miután megrendelésüket visszaigazolták a láncon. Alice minden egyes kifizetésének feldolgozásakor a szerződés ellenőrzi, hogy az egyenlege elegendő-e. Ha a Bobnak 8 USD-t fizetõ tranzakció kerül elõbbre, a szokásos módon kerül feldolgozásra, így Alice 2 dollárral marad a számláján. Ennek eredményeként, amikor a szerződés feldolgozza a második tranzakciót, amely 7 dollárt fizet Charlie-nak, azt látja, hogy Alice-nek nincs elegendő pénze, és a tranzakció megszakad.

Kimenetek kontra szerződések

Eddig két különböző technikát láttunk az ütköző tranzakciók megelőzésére – az egyszeri kiadású kimeneteket a MultiChain és a Corda rendszerben, valamint a szerződésalapú ellenőrzést az Ethereumban. Tehát melyik a jobb?

Ennek a kérdésnek a megválaszolása érdekében nézzünk meg egy példa „1 a 2-ből több aláírású” számlát, amely 100 dollárt tart Gavin és Helen nevében, és lehetővé teszi, hogy bármelyikük önállóan költse el ezt a pénzt. Gavin utasítja jelentkezését, hogy fizessen 80 dollárt Donnának, majd néhány másodperccel később Helen 40 dollárt akar küldeni Edwardnak. Mivel nincs elegendő forrás mindkét fizetéshez, ezek a tranzakciók elkerülhetetlenül ütköznek egymással. Abban az esetben, ha mindkét tranzakciót közvetítik, az eredményt az határozza meg, hogy melyik kerül először a láncba. Vegye figyelembe, hogy Alice példájával ellentétben ez a konfliktus az véletlen, mivel senki sem próbálja megszegni az alkalmazás szabályait – egyszerűen nem szerencsés időzítésük volt.

Ennek az ütközésnek a valószínűségét mérlegelve a kulcskérdés a következő: Miután Gavin elküldte a tranzakcióját, mennyi időbe telik Helen csomópontjának, hogy megtudja, hogy fizetése sikertelen lehet? Minél rövidebb ez az időszak, annál valószínűbb, hogy Helen nem próbálkozik ezzel a fizetéssel, megkímélve őt és kérelmét egy későbbi meglepetéstől.

Az input-output modellnél a tranzakciók közötti bármilyen konfliktus közvetlenül látható a blokklánc platform számára, mivel a két tranzakció kifejezetten ugyanazt az előző kimenetet próbálja elkölteni. A MultiChainben ez azonnal megtörténik, amint Gavin tranzakciója eljut Helen csomópontjához, általában egy másodperc alatt. Cordában a kimenet közjegyzője visszautasítja Helen tranzakciójának aláírására irányuló kérést, mivel az már aláírta Gavinét, így Helen azonnal tudni fogja, hogy fizetése sikertelen lesz. (Bár ha maga a Corda közjegyzője kerül kiosztásra, előfordulhat, hogy várnia kell néhány másodpercet a válaszra.) Akárhogy is, nem kell megvárni a tranzakció megerősítését és megrendelését a blokkláncban.

Mi a helyzet az Ethereum modelljével? Ebben az esetben a blokklánc platform nem tudja azonnal tudni, hogy konfliktus fog bekövetkezni. Bár Helen csomópontja láthatja Gavin tranzakcióját a hálózaton, nem tudhatja, hogy ez hogyan érinti Helen saját tranzakcióját, mivel szemszögéből ez egyszerűen két üzenet, amelyet ugyanahhoz a szerződéshez küldenek. Talán tíz másodperccel később, ha a blokkláncon megerősítik az ütköző tranzakciók végső sorrendjét, Helen csomópontja a várt eredmény helyett újraszámolja a ténylegeset, és az alkalmazása ennek megfelelően frissíti a megjelenítését. Addig is Gavin és Helen a homályban maradnak.

De ebből nem szabad azt a következtetést levonnunk, hogy mindig az input-output modell működik a legjobban. Tekintsünk egy változatot a példa forgatókönyvünkhöz, ahol Gavin és Helen is kisebb, 40 USD kifizetést kér az eredeti 100 USD egyenlegből, pontosan ugyanabban az időben. Az input-output modellben ezek a tranzakciók ütköznének, mivel mindketten ugyanazt az adatbázis-sort költik, amely azt a 100 dollárt tartalmazza, és csak az egyik fizetés lenne sikeres. Az Ethereumban azonban mindkét tranzakció sikeresen feldolgozásra kerül, függetlenül a végső rendeléstől, mivel a számla mindkettőhöz elegendő forrást tartalmaz. Ebben az esetben az Ethereum hűbben teljesíti Gavin és Helen szándékát.

Olvasás-írás halmazok

Végül beszéljünk a Fabric-ről, amelynek jóváhagyáson alapuló megközelítése e két technika hibridje. Amint azt korábban kifejtettük, amikor egy Fabric „ügyfél” csomópont üzenetet akar küldeni egy szerződésnek, először megkér néhány támogató csomópontot, hogy hajtsák végre az üzenetet a nevében. A jóváhagyó csomópontok ezt az Ethereumhoz hasonló módon teszik – a szerződést a helyi adatbázisukon futtatják –, de ezt a folyamatot inkább megfigyelik, mintsem azonnal alkalmazzák. Minden jóváhagyó rögzíti az olvasandó és írandó sorok halmazát, és feljegyzi a sorok pontos verzióját is az adott időpontban. A verziószámú sorok „olvasási-írási készletére” kifejezetten hivatkozik a jóváhagyás, és szerepel az ügyfél által sugárzott tranzakcióban.

A Fabric-tranzakciók közötti konfliktusok akkor oldódnak meg, amikor a láncban véglegesítik a megrendelést. Minden csomópont önállóan dolgoz fel minden tranzakciót, ellenőrzi a jóváhagyási irányelveket és alkalmazza a megadott adatbázis-módosításokat. Ha azonban egy tranzakció olyan adatbázissor-verziót olvas vagy ír, amelyet egy korábbi tranzakció már módosított, akkor a második tranzakció figyelmen kívül marad. Ha vissza akarunk térni Alice Bobnak és Charlie-nak fizetett ellentmondó kifizetéseihez, mindkét tranzakció ugyanazt a sort fogja olvasni és módosítani, amely tartalmazza azt a 10 dollárt, amellyel Alice indult. Így a második tranzakció biztonságosan és automatikusan megszakad.

A Fabric konfliktuskezelési megközelítése jól működik, de a teljesítmény és a rugalmasság tekintetében az előző két modell legrosszabb elemeit ötvözi. Mivel a jóváhagyások a tranzakciókat meghatározott olvasási-írási készletekké alakítják át, Gavin és Helen egyidejű, de kompatibilis 40 dolláros kifizetései olyan konfliktushoz vezetnének, amelyet az Ethereum elkerül. A Fabric azonban nem nyeri el az input-output modell sebességelőnyét, mivel a jóváhagyók az adatbázis blokklánc által megerősített legújabb verziójával szemben hajtanak végre szerződéseket, figyelmen kívül hagyva a meg nem erősített tranzakciókat. Tehát ha Helen néhány másodperccel Gavin után kezdeményezi a fizetést, de még azelőtt, hogy Gavinét megerősítenék a blokkláncon, a Fabric ellentmondó tranzakciókat hoz létre, amelyeket a tiszta bemenet-kimenet modell elkerül.

Konfliktusmegelőzés	Szövet	MultiChain	Ethereum	Corda
Modell	Olvasás-írás halmazok	Egyszeri költés	Szerződés ellenőrzések	Egyszeri költés
Igazolás	Független	Független	Független	Megbízható közjegyzők
Sebesség	~10s (megerősítés)	~1s (szaporodás)	~10s (megerősítés)	0-5 mp (közjegyző)

Összetett választás

Ebben a cikkben áttekintettük a Corda, az Ethereum, a Fabric és a MultiChain számos különféle módját, amellyel az „intelligens szerződések” vagy a blokkláncba ágyazott alkalmazáskód fő kihívásaival foglalkoznak. És minden platform más-más választ ad három alapvető kérdésünkre: Hogyan jelennek meg a tranzakciós szabályok? Hogyan történik a kód determinisztikus végrehajtása? És hogyan előzzük meg a konfliktusokat?

Tehát ki a nyertese az intelligens szerződéses leszámolásunknak? Mára nyilvánvalónak kell lennie, hogy nincs egyszerű válasz. Mindegyik platform egy összetett, többirányú kompromisszumot képvisel a rugalmasság, az egyszerűség, a teljesítmény, a közvetítésmentesség, a biztonság és a titoktartás között. Tehát egy adott alkalmazás platformjának kiválasztását az adott alkalmazás bizalmi modelljének, az általa érintett tranzakciótípusoknak és azok valószínű konfliktusmintájának részletes megértésével kell kezdeni. Ha úgy találja, hogy valaki egy konkrét intelligens szerződéses megoldást szorgalmaz, mielőtt megtudná a választ ezekre a kérdésekre, azt javaslom, udvariasan, de határozottan ragaszkodjon ahhoz, hogy „okosabb” megközelítést alkalmazzon.

Kérjük, tegye meg észrevételeit a LinkedIn.