Óvakodj a lehetetlen intelligens szerződéstől

A három leggyakoribb intelligens szerződéses tévhit

Egy népszerű blokklánc platform fejlesztőiként néha megkérdezik tőlünk, hogy Ethereum-szerű intelligens szerződések vannak-e MultiChain útiterv. A válasz, amit mindig adok: nem, vagy legalábbis még nem.

De a blokkláncok felhajtással teli világában az intelligens szerződések divatosak, akkor miért ne? Nos, a probléma az, hogy bár jelenleg három erős felhasználási esetet ismerünk az engedélyezett Bitcoin-stílusú blokkláncokra (eredet, vállalatközi nyilvántartások és könnyű finanszírozás), az Ethereum-stílusú intelligens szerződések megfelelőjét még nem találjuk meg.

Nem arról van szó, hogy az embereknek hiányoznak az elképzeléseik arról, hogy mit szeretnének az intelligens szerződésekkel. Inkább annyi az ilyen ötlet egyszerűen lehetetlenek. Látod, amikor az okos emberek meghallják az „okos szerződések” kifejezést, képzeletük elszabadul. Álmokat varázsolnak az autonóm intelligens szoftverekről, amelyek világgá szállnak, és adatait magukkal vigyék.

Sajnos az intelligens szerződések valósága sokkal hétköznapibb mindennél:

Az intelligens szerződés egy blokkláncon tárolt, blokklánc-tranzakciók által kiváltott kódrészlet, amely adatokat olvas és ír a blokklánc adatbázisába.

Ez az. Igazán. Az intelligens szerződés csak egy fantázianév a kódhoz, amely egy blokkláncon fut, és kölcsönhatásba lép a blokklánc állapotával. És akkor is kód? Ez Pascal, ez Python, ez PHP. Ez Java, ez Fortran, ez C++. Ha már adatbázisokról beszélünk, akkor az tárolt eljárások az SQL kiterjesztésében írva. Mindezek a nyelvek alapvetően ekvivalensek, és ugyanazokat a problémákat ugyanolyan módon oldják meg. Természetesen mindegyiknek megvannak a maga erősségei és gyengeségei – őrült lennél, ha C-ben készítenéd a webhelyet, vagy Ruby-ban tömörítenéd a HD-videót. De legalább elvileg megtehetné, ha akarná. Komoly árat kell fizetnie a kényelem, a teljesítmény és valószínűleg a haja miatt.

Az intelligens szerződésekkel nem csak az a probléma, hogy az emberek túlzott elvárásai vannak. Ez az, hogy ezek az elvárások sokakat arra késztetnek, hogy időt és pénzt költsenek olyan ötletekre, amelyeket lehetetlen megvalósítani. Úgy tűnik, a nagyvállalatok elegendő erőforrással rendelkeznek ahhoz, hogy hosszú utat járjanak be – attól a pillanattól kezdve, amikor a felső vezetés találkozik egy új technológiával, egészen addig, amíg a technológia előnyeit és korlátait valóban megértik. Talán saját tapasztalatunk segíthet lerövidíteni ezt az időt.

Az elmúlt kilenc hónap során számos intelligens szerződéses felhasználási esettel találkoztunk, és újra és újra azt a választ kaptuk, hogy ezeket egyszerűen nem lehet megtenni. Ennek eredményeként azonosítottuk a három leggyakrabban elterjedt intelligens szerződéses tévhitet. Ezek az ötletek nem rosszak, mert a technológia még kiforratlan, vagy az eszközök még nem állnak rendelkezésre. Inkább félreértik a Az adatbázisban élő és decentralizált módon futó kód alapvető tulajdonságai.

Kapcsolatfelvétel a külső szolgálatokkal

Gyakran az első javasolt használati eset egy intelligens szerződés, amely valamilyen külső esemény hatására megváltoztatja viselkedését. Például egy mezőgazdasági biztosítás, amely az adott hónapban lehullott csapadék mennyisége alapján feltételesen fizet. Az elképzelt folyamat valahogy így zajlik: az okosszerződés kivár az előre meghatározott ideig, lekéri az időjárás-jelentést egy külső szolgáltatástól, és a kapott adatok alapján megfelelően viselkedik.

Mindez elég egyszerűen hangzik, de lehetetlen is. Miért? Mert a blokklánc egy konszenzus alapú rendszer, vagyis csak akkor működik, ha minden tranzakció és blokk feldolgozása után minden csomópont azonos állapotba kerül. Mindennek, ami a blokkláncon történik, teljesen determinisztikusnak kell lennie, és nincs mód arra, hogy a különbségek bekúszhassanak. Abban a pillanatban, amikor két őszinte csomópont nem ért egyet a lánc állapotát illetően, az egész rendszer értéktelenné válik.

Most ne feledje, hogy az intelligens szerződéseket a lánc minden csomópontja függetlenül hajtja végre. Ezért, ha egy intelligens szerződés bizonyos információkat külső forrásból kér le, akkor ezt a visszakeresést minden csomópont ismételten és külön-külön hajtja végre. De mivel ez a forrás a blokkláncon kívül van, nincs garancia arra, hogy minden csomópont ugyanazt a választ kapja. Lehet, hogy a forrás megváltoztatja válaszát a különböző csomópontoktól érkező kérések között, vagy átmenetileg elérhetetlenné válik. Akárhogy is, a konszenzus megszakad, és az egész blokklánc meghal.

Tehát mi a megoldás? Valójában ez meglehetősen egyszerű. A külső adatok lekérését kezdeményező intelligens szerződés helyett egy vagy több megbízható fél („Oracles”) olyan tranzakciót hoz létre, amely beágyazza ezeket az adatokat a láncba. Minden csomópontnak azonos másolata lesz ezekről az adatokról, így biztonságosan használhatók az intelligens szerződésszámítások során. Más szóval, egy orákulum kitolja az adatokat a blokkláncba, nem pedig egy intelligens szerződésbe vontatás Bene.

A külvilág eseményeit okozó okosszerződések kapcsán hasonló probléma merül fel. Például sokaknak tetszik az intelligens szerződés ötlete, amely a bank API-ját hívja meg a pénz átutalása érdekében. De ha minden csomópont függetlenül hajtja végre a kódot a láncban, ki a felelős az API meghívásáért? Ha a válasz csak egy csomópont, mi történik, ha az adott csomópont szándékosan vagy nem? És ha a válasz minden csomópont, akkor minden csomópontra rábízhatjuk az API jelszavát? És valóban azt akarjuk, hogy az API-t több százszor hívják? Még rosszabb, ha az intelligens szerződésnek tudnia kell, hogy az API-hívás sikeres volt-e, akkor azonnal visszatérünk a külső adatoktól való függés problémájához.

Mint korábban, itt is elérhető egy egyszerű megoldás. Ahelyett, hogy az intelligens szerződés külső API-t hívna, egy megbízható szolgáltatást használunk, amely figyeli a blokklánc állapotát, és válaszul végrehajt bizonyos műveleteket. Például egy bank proaktívan figyelhet egy blokkláncot, és olyan pénzátutalásokat hajthat végre, amelyek tükrözik a láncon belüli tranzakciókat. Ez nem jelent kockázatot a blokklánc konszenzusára nézve, mivel a lánc teljesen passzív szerepet játszik.

Ha ezt a két megoldást nézzük, néhány észrevételt tehetünk. Először is, mindkettőhöz megbízható entitásra van szükség a blokklánc és a külvilág közötti interakciók kezelésére. Bár ez technikailag lehetséges, aláássa a decentralizált rendszer célját. Másodszor, az ezekben a megoldásokban használt mechanizmusok egyértelmű példái adatbázis olvasása és írása. A külső információkat szolgáltató orákulum egyszerűen beírja ezt az információt a láncba. És egy szolgáltatás, amely a valós világban tükrözi a blokklánc állapotát, nem tesz mást, mint olvas ebből a láncból. Más szavakkal, a blokklánc és a külvilág közötti bármilyen interakció a rendszeres adatbázis-műveletekre korlátozódik. Erről a tényről a későbbiekben többet fogunk beszélni.

Láncon belüli fizetések érvényesítése

Íme egy másik javaslat, amelyet gyakran hallunk: egy intelligens szerződés használata az úgynevezett „okos kötvény” kuponok kifizetésének automatizálására. Az ötlet az, hogy az intelligens szerződés kódja automatikusan kezdeményezze a kifizetéseket a megfelelő időpontokban, elkerülve a kézi folyamatokat, és garantálva, hogy a kibocsátó ne tudjon késedelmeskedni.

Természetesen ahhoz, hogy ez működjön, a befizetésekre használt forrásoknak is a blokkláncon belül kell élniük, különben egy okos szerződés nem tudná garantálni a fizetésüket. Most emlékezzünk arra, hogy a blokklánc csak egy adatbázis, jelen esetben egy pénzügyi főkönyv, amely a kibocsátott kötvényt és némi készpénzt tartalmazza. Tehát amikor a kuponkifizetésekről beszélünk, valójában adatbázis-műveletekről beszélünk, amelyek automatikusan, megbeszélt időpontban mennek végbe.

Bár ez az automatizálás technikailag megvalósítható, pénzügyi nehézségekkel küzd. Ha a kuponkifizetésekre felhasznált pénzeszközöket a kötvény intelligens szerződése szabályozza, akkor ezek a kifizetések valóban garantálhatók. De ez az alapokat is jelenti a kötvénykibocsátó másra nem használhatja fel. És ha azok az alapok nem az okosszerződés irányítása alatt, akkor a fizetés semmilyen módon nem garantálható.

Más szóval, az intelligens kötvény vagy értelmetlen a kibocsátó számára, vagy értelmetlen a befektető számára. És ha belegondolunk, ez teljesen nyilvánvaló eredmény. A befektető szemszögéből a kötvény lényege a vonzó hozam, némi nemteljesítési kockázat árán. A kibocsátó számára pedig a kötvény célja, hogy egy produktív, de némileg kockázatos tevékenységhez, például egy új gyár építéséhez forrást gyűjtsön. A kötvénykibocsátónak nincs mód arra, hogy a felvett forrásokat felhasználja, ugyanakkor garantálja a befektető visszafizetését. Ez nem érhet meglepetést a kockázat és a megtérülés közötti kapcsolat nem olyan probléma, amelyet a blokkláncok meg tudnak oldani.

Bizalmas adatok elrejtése

Ahogy én írtak róla korábban, a blokkláncok bevezetésének legnagyobb kihívása az általuk biztosított radikális átláthatóság. Például, ha tíz bank közösen hoz létre blokkláncot, és kettő kétoldalú tranzakciót bonyolít le, ez azonnal látható lesz a másik nyolc számára. Noha különféle stratégiák léteznek a probléma enyhítésére, egyik sem éri el a központosított adatbázis egyszerűségét és hatékonyságát, amelyben egy megbízható rendszergazda teljes ellenőrzése alatt áll, hogy ki mit láthat.

Vannak, akik úgy gondolják, hogy az intelligens szerződések megoldhatják ezt a problémát. Abból indulnak ki, hogy minden intelligens szerződés saját miniatűr adatbázist tartalmaz, amely felett teljes ellenőrzést gyakorol. Ezen az adatbázison az összes olvasási és írási műveletet a szerződés kódja közvetíti, ami lehetetlenné teszi, hogy az egyik szerződés közvetlenül olvassa a másik adatait. (Az adatok és a kód közötti szoros összekapcsolást beágyazásnak nevezik, és ez a népszerűség alapja objektumorientált programozás paradigma.)

Tehát ha az egyik intelligens szerződés nem tud hozzáférni egy másik adataihoz, akkor megoldottuk a blokklánc titkosságának problémáját? Van értelme az információk elrejtéséről beszélni egy intelligens szerződésben? Sajnos a válasz nem. Mert még ha az egyik intelligens szerződés nem is tudja olvasni egy másik adatait, ezek az adatok a lánc minden egyes csomópontján tárolódnak. A blokklánc minden résztvevőjének a memóriájában vagy lemezén található rendszer, amelyet a résztvevő teljes mértékben irányít. És semmi sem akadályozza meg őket abban, hogy elolvassák a saját rendszerükből származó információkat, ha és amikor úgy döntenek.

Az adatok elrejtése egy intelligens szerződésben körülbelül olyan biztonságos, mint egy weboldal HTML-kódjában. Persze a normál webfelhasználók nem fogják látni, mert nem jelenik meg a böngészőablakban. De mindössze annyi kell, hogy egy webböngésző hozzáadjon egy „Forrás megtekintése” funkciót (ahogy mindegyiknél van), és a rejtett információ általánosan láthatóvá válik. Hasonlóképpen, az intelligens szerződésekben elrejtett adatokhoz mindössze annyi kell, hogy valaki módosítsa a blokklánc-szoftverét, hogy megjelenítse a szerződés teljes állapotát, és a titoktartás minden látszata elvész. Egy félig tisztességes programozó ezt egy óra alatt meg tudná csinálni.

Mire valók az okos szerződések

Annyi olyan dolog miatt, amit az intelligens szerződések nem képesek megtenni, felmerülhet a kérdés, hogy valójában mire valók. De ahhoz, hogy megválaszoljuk ezt a kérdést, vissza kell mennünk maguknak a blokkláncoknak az alapjaihoz. Összefoglalva, a blokklánc lehetővé teszi, hogy az adatbázist közvetlenül és biztonságosan megosszák olyan entitások számára, akik nem bíznak egymásban, anélkül, hogy központi rendszergazdára lenne szükségük. A blokkláncok lehetővé teszik az adatok szétválasztását, és ez jelentős összetettség- és költségmegtakarításhoz vezethet.

Bármely adatbázist „tranzakciókkal” módosítanak, amelyek egy sor olyan változtatást tartalmaznak az adatbázisban, amelyeknek teljes egészében sikeresnek vagy sikertelennek kell lenniük. Például egy pénzügyi főkönyvben az Alice-től Bobnak történő kifizetést egy tranzakció jelenti, amely (a) ellenőrzi, hogy Alice rendelkezik-e elegendő pénzeszközzel, (b) levon egy mennyiséget Alice számlájáról, és (c) ugyanazt a mennyiséget hozzáadja Bob számlájához. .

Egy szokásos központi adatbázisban ezeket a tranzakciókat egyetlen megbízható hatóság hozza létre. Ezzel szemben egy blokklánc-vezérelt megosztott adatbázisban a tranzakciókat a blokklánc bármely felhasználója hozhatja létre. És mivel ezek a felhasználók nem bíznak teljesen egymásban, az adatbázisnak olyan szabályokat kell tartalmaznia, amelyek korlátozzák a végrehajtott tranzakciókat. Például egy peer-to-peer pénzügyi főkönyvben minden tranzakciónak meg kell őriznie a teljes forrásmennyiséget, különben a résztvevők szabadon adhatnak maguknak annyi pénzt, amennyit akarnak.

E szabályok kifejezésének többféle módja is elképzelhető, de jelenleg két domináns paradigma létezik, amelyeket a Bitcoin és az Ethereum ihletett. A Bitcoin módszer, amelyet „tranzakciós megszorításoknak” nevezhetünk, minden tranzakciót a következők szerint értékel: (a) az adott tranzakció által törölt adatbázis-bejegyzések és (b) a létrehozott bejegyzések. A pénzügyi főkönyvben a szabály kimondja, hogy a törölt bejegyzésekben szereplő pénzeszközök teljes mennyiségének meg kell egyeznie a létrehozott bejegyzések teljes mennyiségével. (Egy meglévő bejegyzés módosítását egyenértékűnek tekintjük a bejegyzés törlésével és egy új létrehozásával a helyére.)

A második paradigma, amely az Ethereumtól származik, az intelligens szerződések. Ez kimondja, hogy a szerződés adatainak minden módosítását annak kódjával kell végrehajtani. (A hagyományos adatbázisok kontextusában ezt úgy tekinthetjük, mint egy érvényesíteni tárolt eljárás.) Egy szerződés adatainak módosításához a blokklánc felhasználók küldik kéri kódjához, amely meghatározza, hogy teljesíteni kell-e ezeket a kéréseket, és ha igen, hogyan. Mint a ezt a példát, a pénzügyi főkönyvi intelligens szerződés ugyanazt a három feladatot látja el, mint egy központi adatbázis adminisztrátora: elegendő fedezet ellenőrzését, az egyik számláról történő levonást és a másikhoz való hozzáadást.

Mindkét paradigma hatékony, és mindegyiknek megvannak a maga előnyei és hátrányai, ahogy én is tettem korábban részletesen tárgyaltuk. Összefoglalva, a Bitcoin-stílusú tranzakciós korlátok kiváló egyidejűséget és teljesítményt biztosítanak, míg az Ethereum-stílusú intelligens szerződések nagyobb rugalmasságot biztosítanak. Tehát visszatérve arra a kérdésre, hogy mire valók az intelligens szerződések:

Az intelligens szerződések olyan blokklánc-használati esetekre vonatkoznak, amelyeket nem lehet tranzakciós megkötésekkel megvalósítani.

Tekintettel az intelligens szerződések használatára vonatkozó ezen kritériumra, még nem láttam olyan erős használati esetet az engedélyezett blokkláncokra, amelyek megfelelnek. Az összes általam ismert lenyűgöző blokklánc alkalmazás megvalósítható Bitcoin-stílusú tranzakciókkal, amelyek képesek kezelni az engedélyezést és az általános adattárolást, valamint az eszközök létrehozását, átvitelét, letétbe helyezését, cseréjét és megsemmisítését. Ennek ellenére még mindig jelennek meg új használati esetek, és nem lennék meglepve, ha néhány do intelligens szerződések erejét igénylik. Vagy legalábbis a Bitcoin paradigma kiterjesztése.

Bármi is lesz a válasz, a legfontosabb, hogy ne feledje, hogy az intelligens szerződések egyszerűen az egyik módszer az adatbázisban végrehajtott tranzakciók korlátozására. Ez kétségtelenül hasznos dolog, és elengedhetetlen az adatbázis biztonságos megosztásához. De az intelligens szerződések nem tehetnek mást, és biztosan nem léphetik ki annak az adatbázisnak a határait, amelyben tartózkodnak.

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