Ebben a cikkben megvizsgáljuk, hogy mik azok a okos szerződések, milyen típusai léteznek, megismerkedünk a különböző okos szerződés platformokkal, azok sajátosságaival, továbbá beszélni fogunk arról, hogyan működnek és milyen előnyöket nyújthatnak. Ez az anyag nagyon hasznos lesz azok számára, akik nem eléggé ismerik az okos szerződések témáját, de szeretnék jobban megérteni azt.
Hagyományos szerződés vs. okos szerződés
Mielőtt belemerülnénk a részletekbe, nézzük meg egy példán keresztül a különbséget a hagyományos szerződés, amely papíralapú, és az okos szerződés, amely digitális formában létezik.
Hogyan működött ez az okos szerződések megjelenése előtt? Képzeljünk el egy csoportot, amely szeretné megállapítani a javak elosztásának bizonyos szabályait és feltételeit, továbbá valamilyen módon biztosítani a szabályok és feltételek betartását. Akkor együtt ült össze, elkészítettek egy papíralapú dokumentumot, amelyen rögzítették az azonosító adataikat, a feltételeket, az érintett javakat, megadták a dátumot és aláírták. Ezt a szerződést egy megbízható fél, például közjegyző, hitelesítette. Ezután az emberek eltávoztak a saját papíralapú példányukkal, és elkezdtek olyan tevékenységeket folytatni, amelyek nem feleltek meg a szerződésnek, vagyis egyet tettek, a papíron pedig valami teljesen mást tanúsítottak. Hogyan lehet ebből a helyzetből kilépni? Valójában szükség van valamelyik csoporttagra, aki elviszi ezt a papírt, bizonyítékokat gyűjt, bíróság elé viszi az ügyet és követeli a szerződés és a tényleges cselekedetek közötti megfelelést. Gyakran nehéz elérni, hogy a szerződést tisztességesen betartsák, ami kellemetlen következményekhez vezet.
Mit mondhatunk az okos szerződésekről? Összekapcsolják a szerződés feltételeinek megírásának lehetőségét és a szigorú végrehajtásának mechanizmusát. Ha a feltételek meg lettek határozva és a megfelelő tranzakciót vagy kérést aláírták, akkor a kérés vagy tranzakció elfogadása után már nem lehet megváltoztatni a feltételeket vagy befolyásolni azok végrehajtását.
Egy érvényesítő vagy egy egész hálózat, valamint egy adatbázis létezik, amely tárolja az összes okos szerződést, amelyek végrehajtásra kerültek szigorú kronológiai sorrendben. Fontos, hogy ez az adatbázis tartalmazza az okos szerződés végrehajtásához szükséges összes feltételt, amely kiváltó tényezőként működik. Ezenkívül figyelembe kell vennie azt az értéket, amelynek elosztását a szerződés leírja. Ha ez egy digitális valuta vonatkozásában történik, akkor az adatbázisnak figyelembe kell vennie ezt.
Más szóval, az okos szerződések érvényesítőinek hozzáféréssel kell rendelkezniük minden olyan adathoz, amelyet az okos szerződés kezel. Például egy adatbázist kell használni a digitális valuták, a felhasználók egyenlegei, a felhasználói tranzakciók és az időbélyegek egyidejű nyilvántartására. Így az okos szerződésben a feltétel lehet a felhasználó egyenlege egy adott valutában, egy bizonyos időpont elérése vagy egy adott tranzakció végrehajtásának ténye, de nem több.
Az okos szerződés meghatározása
A terminológiát Nick Szabo kutató alkotta meg, és először 1994-ben alkalmazták, majd 1997-ben dokumentálták egy cikkben, amely leírja az okos szerződések ötletét.
Az okos szerződések azt feltételezik, hogy valamilyen automatizált értékmegosztás valósul meg, amely kizárólag a korábban előre meghatározott feltételektől függhet. A legegyszerűbb esetben ez úgy néz ki, mint egy szigorúan meghatározott feltételekkel rendelkező szerződés, amelyet egy adott fél ír alá.
Az okos szerződések célja a harmadik fél iránti bizalom minimalizálása. Néha teljesen kiiktatják a döntéshozatali központot, amelytől minden függ. Ezenkívül ezek a szerződések auditálása is egyszerűbb. Ez a rendszer tervezésének néhány sajátosságából fakad, de leggyakrabban az okos szerződés alatt egy decentralizált környezetet és olyan funkciók meglétét értjük, amelyek lehetővé teszik bárki számára az adatbázis elemzését és a szerződések végrehajtásának teljes auditálását. Így garantálható az adatok visszamenőleges megváltoztatásának védelme, ami változásokat eredményezne a szerződés végrehajtásában. Az okos szerződés létrehozása és indítása során a legtöbb folyamat digitalizálása gyakran egyszerűsíti a technológiát és a megvalósítás költségeit.
Egyszerű példa - Escrow szolgáltatás
Nézzük meg egy nagyon egyszerű példát. Ez segít közelebb kerülni a szmart szerződések funkcióinak megértéséhez, valamint jobban tájékozódni arról, hogy mikor érdemes őket alkalmazni.
Ez a Bitcoin használatával is megvalósítható, bár a Bitcoin-t még mindig nehéz teljes értékű szmart szerződés platformnak nevezni. Tehát van egy vásárlónk és van egy online bolt. A vásárló monitor vásárlására vágyik ebben a boltban. A legegyszerűbb esetben a vásárló leadja a megrendelést és elküldi a kifizetést, amelyet az online bolt elfogad és megerősít, majd elküldi az árut. Azonban ebben a helyzetben komoly bizalomra van szükség - a vásárlónak teljes mértékben bíznia kell az online boltban a monitor teljes költségében. Mivel az online bolt alacsony hírnévvel bírhat a vásárló szemében, fennáll a kockázata, hogy valamilyen okból a bolt a kifizetés után megtagadja a szolgáltatást, és nem küldi el a terméket a vásárlónak. Ezért a vásárló azt a kérdést teszi fel (ezzel együtt az online bolt is ezt a kérdést teszi fel), hogy mit lehet tenni ebben az esetben a kockázatok minimalizálása érdekében, és hogyan tehetők megbízhatóbbá ezek az ügyletek.
A Bitcoin esetében lehetőséget lehet adni a vásárlónak és az eladónak, hogy függetlenül válasszanak ki egy mediát. Sok olyan ember van, aki vitás kérdések megoldásával foglalkozik. A résztvevőink választhatnak egy közös mediát, akiben egyszerre bíznak. Együtt létrehoznak egy multisignature címet 2 az 3-ból, ahol három kulcs található, és két aláírásra van szükség bármelyik két kulccsal a pénz eltérítéséhez. Az egyik kulcs a vásárlóé, a másik az online bolté, a harmadik pedig a mediátoré. A vásárló ezen a multisignature címen elküldi a monitor kifizetéséhez szükséges összeget. Most, amikor az eladó látja, hogy a pénz egy ideig le van blokkolva a multisignature címen, amely tőle függ, nyugodtan elküldheti a monitort postán.
Ezután a vásárló megkapja a csomagot, megnézi a terméket, és meghozza a végső vásárlási döntést. Teljes mértékben egyetérthet a nyújtott szolgáltatással, és aláírja a tranzakciót a saját kulcsával, amelyben átadja a pénzérméket az eladónak a multisignature címről, de lehet, hogy nem teljesen elégedett. A második esetben felveszi a kapcsolatot a mediátorral, hogy alternatív tranzakciót készítsenek, amely más módon osztja el ezeket a pénzérméket.
Tegyük fel, hogy a monitor kicsit megkarcolódva érkezett, és a számítógéphez való csatlakozókábel sem volt benne, pedig az online bolt weboldalán azt írták, hogy a kábel tartozéknak számít. ekkor a vásárlónak bizonyítékokat kell gyűjtenie, hogy bebizonyítsa a mediátornak, hogy átverték ebben a helyzetben: készít képernyőképeket a weboldalról, fényképet a postai nyugtáról, fényképet a monitor karcolásairól és bemutatja, hogy a plombát felbontották, és a kábelt eltávolították. Az online bolt cserébe összegyűjti saját bizonyítékait és átadja azokat a mediátornak.
A mediátor érdeke, hogy egyszerre elégítse ki a vásárló felháborodását és az online bolt érdekeit (később kiderül, hogy miért). Olyan tranzakciót készít, amelyben a multisignature címről származó pénzérmék valamilyen arányban kerülnek felhasználásra a vásárló, az online bolt és a mediátor között, mivel ő is részesül díjazásként a munkájáért. Tegyük fel, hogy a teljes összeg 90%-a az eladónak, 5%-a a mediátornak és 5%-a a vásárlónak jár. Ezt a tranzakciót a mediátor aláírja a kulcsával, de még nem alkalmazható, mert ehhez két aláírásra van szükség, és csak egy áll rendelkezésre. Ezt a tranzakciót elküldi a vásárlónak és az eladónak is. Ha bármelyikük elégedett ezzel a pénzérmék átcsoportosításának lehetőségével, akkor a tranzakciót aláírják és elterjesztik a hálózatban. A tranzakció érvényesítéséhez elegendő, ha a megállapodás egyik résztvevője egyetértene a mediátor javaslatával.
Fontos, hogy kezdetben olyan mediátort válasszunk, akiben mindkét résztvevő megbízik. Ekkor ő függetlenül fog eljárni egyik vagy másik fél érdekeitől, és objektíven fogja értékelni a helyzetet. Ha a mediátor nem kínál olyan érmék elosztási lehetőséget, amely legalább az egyik résztvevőt kielégíti, akkor a vásárló és az online bolt közösen át tudja irányítani az érméket egy új multisignature címre, aláírva a saját két aláírásával. Az új multisignature cím már egy másik mediátorral lesz létrehozva, aki talán jobban ért a kérdéshez, és jobb lehetőséget kínál.
Példa a kollégiumra és a hűtőszekrényre
Nézzünk meg egy bonyolultabb példát, amely jobban illusztrálja a smart contract lehetőségeit.
Tegyük fel, hogy van három fiú, akik nemrég költöztek be egy kollégiumi szobába. Mindhárman érdekeltek abban, hogy vásároljanak egy hűtőszekrényt a szobájukba, amelyet közösen fognak használni. Az egyikük felajánlotta, hogy összegyűjti a szükséges pénzt a hűtőszekrény megvásárlásához és tárgyal a eladóval. Azonban viszonylag nemrég találkoztak egymással, így nem áll fenn elegendő bizalom közöttük. Nyilvánvaló, hogy ketten kockáztatnak, amikor pénzt adnak a harmadiknak. Ezen kívül egyetértésre van szükségük az eladó kiválasztásában.
Használhatják az escrow szolgáltatást, vagyis választhatnak egy mediátort, aki ellenőrzi a tranzakció végrehajtását és menet közben rendezni tudja a felmerülő vitás kérdéseket. Ezért megállapodva smart contractot készítenek, amelyben meghatározzák bizonyos feltételeket.
Az első feltétel az, hogy egy meghatározott időpontig, például egy héten belül, három kifizetésnek kell érkeznie a megfelelő okos szerződéshez meghatározott címekről, egy adott összeggel. Ha ez nem teljesül, az okos szerződés leáll, és visszautalja a pénzt minden résztvevőnek. Ha a feltétel teljesül, akkor beállítják az eladó és a közvetítő azonosítóit, valamint ellenőrzik, hogy minden résztvevő egyetértene az eladó és a közvetítő választásával. Amint az összes feltétel teljesül, a pénzeszközöket átutalják a megadott címekre. Ez a megközelítés megvédheti a résztvevőket a csalásokkal szemben, és eltávolítja a bizalom szükségességét.
Ezen a példán láthatjuk azt az elvet, hogy a lépésről lépésre való paraméterbeállítás lehetősége lehetővé teszi bármilyen összetettségű és mélységű rendszerek létrehozását. Ezen kívül először az okos szerződésben határozhatjuk meg az első feltételt, és csak annak teljesítése után állíthatjuk be a következő feltétel paramétereit. Más szóval, formálisan a feltételt rögzítjük, de a paramétereit már a működése alatt lehet meghatározni.
Okos szerződések osztályozása
Az osztályozáshoz különböző kritériumcsoportokat lehet megadni. Jelenleg azonban négy kritérium a legaktuálisabb a technológiák fejlődése szempontjából.
Az okos szerződéseket a végrehajtás környezete alapján lehet megkülönböztetni, amely lehet központosított vagy decentralizált. A decentralizáció esetén sokkal nagyobb függetlenséget és hibatűrést garantálunk az okos szerződések végrehajtásakor.
Ezeket a feltételek megadásának és végrehajtásának folyamata szerint is meg lehet különböztetni: lehetnek szabadon programozhatóak, korlátozottak vagy előre beállítottak, azaz szigorúan tipizáltak. Amikor az okos szerződések platformján csak 4 meghatározott okos szerződés létezik, a hozzájuk tartozó paramétereket szabadon lehet beállítani. Ennek megfelelően sokkal egyszerűbb őket paraméterezni: kiválasztunk egy szerződést a listából, és átadjuk a paramétereket.
Az indítási módszer szerint léteznek automatizált okos szerződések, azaz amikor bizonyos feltételek teljesülnek, automatikusan végrehajtódnak, és vannak olyan szerződések is, amelyekben a feltételek meg vannak határozva, de a platform nem ellenőrzi automatikusan a teljesülésüket, ehhez külön kell kezdeményezni őket.
Továbbá, az okos szerződések különböznek a magánélet szintje szerint. Lehetnek teljesen nyitottak, félig nyitottak vagy teljesen titkosak. Az utóbbi azt jelenti, hogy a külső megfigyelők nem látják az okos szerződések feltételeit. Azonban a magánélet témája nagyon széleskörű, és jobban meg kell vizsgálni a jelenlegi cikken kívül.
Az alábbiakban részletesebben foglalkozunk az első három kritériummal, hogy világosabbá tegyük a jelenlegi téma megértését.
Okos szerződések a végrehajtási környezet szerint
A végrehajtási környezet szerint megkülönböztetjük a központosított és decentralizált okos szerződés platformokat. A központosított digitális szerződések esetében egy szolgáltatást használnak, ahol csak egy validátor létezik, és lehet egy központosítottan kezelt biztonsági mentési és helyreállítási szolgáltatás is. Van egy adatbázis, amely tárolja az összes szükséges információt az okos szerződés feltételeinek megadásához és a szolgáltatás adatbázisában nyilvántartott értékek elosztásához. Egy ilyen központosított szolgáltatásnak van egy ügyfele, aki meghatározott kérésekkel állítja be a feltételeket és használja ezeket a szerződéseket. Mivel a platform központosított, az autentikációs mechanizmusok kevésbé megbízhatóak lehetnek, mint a kriptovaluták esetében.
Példaként említhetjük a mobil szolgáltatókat (különböző mobil operátorokat). Tegyük fel, hogy egy adott szolgáltató központosított módon nyilvántartja a forgalmat a szerverein, amely különböző formátumokban történhet, például: hanghívások, SMS küldés, mobil internet forgalom stb., és különböző szabványok szerint, valamint nyilvántartja a felhasználók egyenlegén lévő összegeket. Ennek megfelelően a mobil szolgáltató szerződéseket köthet a nyújtott szolgáltatások nyilvántartására és azok kifizetésére különböző feltételekkel. Ilyen esetben könnyen megadhatók a feltételek, mint például: 'küldj el egy SMS-t egy adott kódot egy adott számra, és ilyen-olyan forgalmi elosztási feltételeket kapsz.'
Lehet még egy példát hozni: a hagyományos bankok kiterjesztett internetbanki funkciókkal és olyan nagyon egyszerű szerződésekkel, mint a rendszeres kifizetések, a bejövő kifizetések automatikus átváltása, a kamat automatikus levonása a megadott számlára stb.
Ha a decentralizált végrehajtási környezettel rendelkező okosszerződésekről van szó, akkor egy validátor csoportunk van. Ideális esetben validátor bárki lehet. Az adatbázis szinkronizálási protokollja és a konszenzus elérése révén van egy közös adatbázisunk, amely mostantól tárolni fogja az összes tranzakciót szigorúan leírt szerződésekkel, nem pedig valamilyen önkényes kéréseket, melyek formátuma gyakran változik, és nyilvános specifikáció nincs. Itt a tranzakciók a szerződés végrehajtásának utasításait fogják tartalmazni a szigorú specifikáció szerint. Ez a specifikáció nyitott, és ezért a platform felhasználói auditálhatják és érvényesíthetik az okosszerződéseket. Itt látható, hogy a decentralizált platformok függetlenségben és hibamentességben felülmúlják a centralizáltakat, de azok tervezése és karbantartása sokkal bonyolultabb.
Az okosszerződések az előírások megadásának és végrehajtásának módja szerint
Most részletesebben megvizsgáljuk, hogyan különbözhetnek az okosszerződések az előírások megadásának és végrehajtásának módja szerint. Itt azokra az okosszerződésekre figyelünk, amelyeket tetszés szerint és Turing-komplettként programoznak. A Turing-komplett okosszerződés szinte bármilyen algoritmus megadását lehetővé teszi a szerződés végrehajtási feltételeiként: ciklusokat, valószínűségi számítási funkciókat és hasonlókat írhatunk elő - egészen a saját elektronikus aláírás algoritmusainkig. Ebben az esetben valóban tetszőleges logika írásáról van szó.
Különbséget lehet tenni mindenféle okosszerződések között, amelyek azonban nem Turing-komplettok. Ide tartozik a Bitcoin és a Litecoin saját scriptjeivel. Az azt jelenti, hogy tetszőleges sorrendben csak bizonyos műveleteket lehet használni, de már nem lehet ciklusokat és egyéni algoritmusokat írni.
Ezen kívül vannak olyan okosszerződés-platformok is, amelyek előre beállított okosszerződéseket valósítanak meg. Ilyenek például a Bitshares és a Steemit. A Bitshares egy sor okosszerződést kínál a kereskedelem, a fiókok kezelése, valamint a platform és annak paramétereinek irányítása céljából. A Steemit hasonló platform, de nem tokenkibocsátásra és kereskedelemre, mint a Bitshares, hanem blogolásra összpontosít, azaz decentralizált módon tárolja és dolgozza fel a tartalmat.
A turing-teljes okosszerződések közé tartozik az Ethereum platform és a RootStock, amely még fejlesztés alatt áll. Ezért a következőkben kicsit részletesebben foglalkozunk az Ethereum okosszerződés-platformjával.
Okosszerződések az inicializálási módszer szerint
Az inicializálási módszer szerint az okosszerződéseket minimum két csoportra oszthatjuk: automatizált és manuális (nem automatizált) szerződésekre. Az automatizáltakra jellemző, hogy az összes ismert paraméter és bekövetkezett feltétel esetén az okosszerződés teljesen automatikusan végrehajtódik, ami azt jelenti, hogy nem igényel további tranzakciók küldését és további díjak kifizetését minden egyes végrehajtás során. Maga a platform rendelkezik minden szükséges adattal ahhoz, hogy kiszámolja, hogyan fejeződik be az okosszerződés. A logika nem véletlenszerű, hanem előre meghatározott, így előre meg lehet becsülni az okosszerződés végrehajtásának bonyolultságát, és egy állandó díjat lehet használni erre, a végrehajtási folyamatok pedig hatékonyabban zajlanak.
A tetszőleges módon programozható okosszerződések esetében a végrehajtás nem automatizált. Egy ilyen okosszerződés inicializálásához gyakorlatilag minden lépésnél új tranzakciót kell létrehozni, amely már a következő végrehajtási szakaszt vagy az okosszerződés következő metódusát hívja meg, megfizetve a megfelelő díjat és várva a tranzakció megerősítésére. A végrehajtás sikeresen befejeződhet, vagy nem, mert az okosszerződés kódja tetszőleges, és felmerülhetnek olyan előre nem látott problémák, mint a végtelen ciklus, bizonyos paraméterek vagy argumentumok hiánya, nem kezelt kivételek stb.
Fiókok az Ethereumon
Ethereum-fiók típusok
Nézzük meg, milyen típusú fiókok léteznek az Ethereum platformon. Itt csak két fajtája van a fiókoknak, más lehetőség nincs. Az első típus felhasználói fiók, a második pedig szerződéses fiók. Nézzük meg, miben különböznek.
A felhasználói fiók kizárólag a digitális aláírás privát kulcsával kezelhető. A fiók tulajdonosa ECDSA (Elliptic Curve Digital Signature Algorithm) algoritmus alapján generálja a digitális aláírás kulcspárját. E fiók állapotát csak a kulccsal aláírt tranzakciók tudják megváltoztatni.
A szerződéses fiók számára külön logika van kialakítva. Ezt csak előre megadott programkód segítségével lehet irányítani, amely teljes mértékben meghatározza a szerződés viselkedését: hogyan fogja kezelni a saját érméit bizonyos körülmények között, mely felhasználó kezdeményezésére és milyen további feltételek mellett fognak az érmék eloszlani. Ha a fejlesztők nem számolnak a programkódban egyes helyzetekkel, problémák merülhetnek fel. Például a szerződés egy olyan állapotba kerülhet, amelyben nem fogad el kezdeményezést egyetlen felhasználótól sem. Ilyen esetben az érmék lényegében felfüggesztődnek, mivel a szerződés nem biztosít kiutat ebből az állapotból.
Hogyan jönnek létre a fiókok az Ethereum hálózaton
Felhasználói fiók esetén a tulajdonos önállóan generálja a kulcspárt az ECDSA alapján. Fontos megjegyezni, hogy az Ethereum ugyanazt az algoritmust és ugyanazt az elliptikus görbét használja a digitális aláírásra, mint a Bitcoin, de a cím számítása kissé eltérő módon történik. Itt már nem alkalmazzák a dupla hash-elést, mint a Bitcoinban, hanem egyetlen hash-elés történik a Keccak függvénnyel, 256 bites hosszúságra. A kapott értékből levágják a legalsó biteket, mégpedig a hash függvény kimeneti értékének 160 legalsó bitjét. Ennek eredményeként kapjuk meg az Ethereum címet. Ez gyakorlatilag 20 bájtot foglal el.
Fontos megjegyezni, hogy az Ethereum-fiók azonosítója hexadecimálisan van kódolva, anélkül hogy ellenőrző összeg lenne alkalmazva, ellentétben a Bitcoinnal és sok más rendszerrel, ahol a címek 58-alapú számsorozatként vannak kódolva, ellenőrző összeg hozzáadásával. Ez azt jelenti, hogy óvatosan kell bánni az Ethereum-fiók azonosítókkal: akár egy apró hiba az azonosítóban is garantáltan pénzveszteséghez vezet.
Van egy fontos jellemző, amely azt jelenti, hogy a felhasználói fiók az általános adatbázisban abban a pillanatban jön létre, amikor az első bejövő tranzakciót elfogadja.
A smart contract fiók létrehozása teljesen más megközelítést alkalmaz. Először is, egy felhasználó megírja a smart contract forráskódját, amelyet ezután egy az Ethereum platformhoz készült speciális fordítóval futtattak, így kapva meg a byte-kódot az Ethereum saját virtuális gépéhez. A kapott byte-kódot át kell helyezni egy speciális tranzakciós mezőbe. Ezt az indító fiók nevében írják alá. Ezután ez a tranzakció terjed a hálózaton, és elhelyezi a smart contract kódját. A tranzakció végrehajtása és így a szerződés teljesítése díját az indító fiók egyenlegéből vonják le.
Minden smart contract kötelezően tartalmazza a saját konstruktőrét (ennek a kontraktusnak). Ez lehet üres, de lehet tartalommal is. Miután a konstruktor végrehajtását betöltötték, létrejön a smart contract fiók azonosítója, amelyet felhasználva pénzt lehet küldeni, bizonyos smart contract metódusokat lehet hívni stb.
Az Ethereum tranzakció struktúrája
Hogy érthetőbb legyen, kezdjük áttekinteni az Ethereum tranzakció struktúráját és egy smart contract példakódját.
Az Ethereum tranzakció több mezőből áll. Az első mező a nonce — ez egy bizonyos sorrendben megadott tranzakciós szám a fiók szempontjából, amely terjeszti és szerzője a tranzakciónak. Erre azért van szükség, hogy megkülönböztessük a tranzakciók másolatát, azaz kizárjuk azt az esetet, amikor ugyanazt a tranzakciót kétszer fogadják el. Az azonosító alkalmazásának köszönhetően minden tranzakciónak egyedi hash értéke van.
Ezt követi egy mező, amely gas priceItt van megadva az az ár, amelyen az alap valuta, az Ethereum, átváltozik gássá, amellyel a smart contract végrehajtása és a virtuális gép erőforrásainak lefoglalása történik. Mit jelent ez?
A Bitcoin esetében a díjak közvetlenül az alap valutával — magával a bitcoinnal — történnek. Ez egy egyszerű számítási mechanizmusnak köszönhető: pontosan azt a mennyiségű adatot fizetjük ki, amely a tranzakcióban található. Az Ethereum esetében a helyzet bonyolultabb, mert nehéz az adatforgalom mennyiségét alapul venni. A tranzakciók ebben az esetben programkódot is tartalmazhatnak, amely a virtuális gépen futni fog, és minden egyes virtuális gép műveletnek eltérő összetettsége lehet. Vannak olyan műveletek is, amelyek memóriát foglalnak le a változók számára. Ezeknek meglesz a saját összetettségük, amely befolyásolja az egyes műveletek költségét.
Minden művelet költsége gázban állandó lesz. Ezt speciálisan azért vezették be, hogy meghatározzák a költségek állandó mértékét minden egyes művelethez. A hálózat terhelésétől függően változni fog a gáz ára, vagyis az a szorzó, amely alapján az alap valuta átváltozik ebbe a segédmértékbe a jutalék kifizetésére.
Van még egy jellemzője a tranzakciónak az Ethereumon: a byte-kód, amit tartalmaz a virtuális gépen végrehajtás céljából, addig fog futni, amíg sikerrel vagy hibával nem zárul, vagy amíg el nem fogy a jutalékra szánt coinok egy bizonyos mennyisége. Az ilyen helyzetek elkerülése érdekében, amikor a küldő fiók minden coinja elhasználódik a jutalékra (például ha egy végtelen ciklus indul el a virtuális gépen), van egy következő mező — start gas (gyakran gas limitnek hívják) — ez határozza meg a maximális mennyiségű coinot, amit a küldő hajlandó elkölteni egy adott tranzakció végrehajtására.
A következő mező neve destination address. Ide kerül a cím, ahova a coinokat küldik, vagy egy konkrét smart contract címe, amelynek metódusait hívni fogják. Ezt követi egy mező, érték, ahova a küldött coinok összege kerül a destination address-ra.
Ezután egy érdekes mező található, amelynek neve data, ahova egy egész struktúra illeszkedik. Ez nem egy külön mező, hanem egy teljes struktúra, amely meghatározza a virtuális géphez tartozó kódot. Ide tetszőleges adatokat lehet elhelyezni — erre külön szabályok vonatkoznak.
Az utolsó mező neve aláírás. Ez egyszerre tartalmazza az ügylet szerzőjének elektronikus aláírását és a nyilvános kulcsot, amellyel ez az aláírás ellenőrizhető. A nyilvános kulcs alapján meg lehet kapni a tranzakciót indító fiók azonosítóját, tehát egyedileg azonosítani lehet a küldő fiókot a rendszerben. A tranzakció szerkezetéről a főbb tudnivalókat tisztáztuk.
Példa egy okosszerződés kódjára Solidity nyelven
Most nézzük meg részletesebben a legegyszerűbb okosszerződést egy példa alapján.
contract Bank {
address owner;
mapping(address => uint) balances;
function Bank() {
owner = msg.sender;
}
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function withdraw(uint amount) public {
if (balances[msg.sender] >= amount) {
balances[msg.sender] -= amount;
msg.sender.transfer(amount);
}
}
function getMyBalance() public view returns(uint) {
return balances[msg.sender];
}
function kill() public {
if (msg.sender == owner)
selfdestruct(owner);
}
}Fent megtalálható az egyszerűsített forráskód, amely képes tárolni a felhasználók érméit és azokat kérésre visszaadni.
Tehát van egy Bank okosszerződés, amely a következő funkciókat látja el: összegyűjti a pénznemeket a saját egyenlegén, azaz a tranzakció megerősítésekor és az ilyen okosszerződés elhelyezésekor létrejön egy új fiók, amely tartalmazhat érméket; emlékezik a felhasználókra és a közöttük lévő érmék eloszlására; rendelkezik több módszerrel az egyenlegek kezelésére, tehát van lehetőség az egyenleg feltöltésére, kifizetésére és ellenőrzésére.
Nézzük át a forráskód minden egyes sorát. Ebben a szerződésben állandó mezők találhatók. Az egyik, melynek típusa address, owner néven fut. Itt a szerződés emlékezik arra a felhasználóra, aki létrehozta ezt az okosszerződést. Ezt követően egy dinamikus struktúra található, amely tárolja a felhasználók címei és egyenlegek közötti megfeleléseket.
Ezt követi a Bank módszer — amely ugyanazt a nevet viseli, mint a szerződés. Tehát ez a konstruktor. Itt az owner változóhoz hozzárendelődik annak a címe, aki ezt az okosszerződést elhelyezte a hálózaton. Ez az egyetlen, ami a konstruktorban történik. Ezért a msg ebben az esetben pontosan azok az adatok, amelyeket a virtuális gépnek a tranzakcióval együtt továbbítottak, amely tartalmazza ennek a szerződésnek az összes kódját. Tehát a msg.sender a tranzakció szerzője, aki ezt a kódot elhelyezi. Ő lesz az okosszerződés tulajdonosa.
A deposit method allows you to transfer a certain amount of coins to a contract account through a transaction. In this case, the smart contract, upon receiving these coins, retains them in its balance, but records in the balances structure who exactly was the sender of these coins to know to whom they belong.
The next method is called withdraw and it takes one parameter — the amount of coins that someone wants to withdraw from this bank. Here, a check is performed to see if there are enough coins in the balance of the user calling this method to send them. If there are enough, the smart contract returns that amount of coins to the caller.
Next is the method for checking the current balance of a user. The one who calls this method will be used to obtain this balance in the smart contract. It should be noted that the modifier of this method is view. This means that the method does not change its class variables in any way and is essentially a read-only method. A separate transaction is not created to call this method, no fee is paid, and all calculations are performed locally, after which the user receives the result.
The kill method is used to destroy the state of the smart contract. Here, there is an additional check to see if the caller of this method is the owner of the contract. If so, the contract self-destructs, and the destruction function takes one parameter — the account ID to which the contract will send all coins remaining in its balance. In this case, the remaining coins will automatically be sent to the owner's address.
How does a full node in the Ethereum network work?
Let's take a look schematically at how the execution of such smart contracts takes place on the Ethereum platform and how a full node in the network operates.
A full node in the Ethereum network must have at least four modules.
The first, as for any decentralized protocol, is the P2P networking module — the module for network connections and interaction with other nodes, where blocks, transactions, and information about other nodes are exchanged. This is a traditional component for all decentralized cryptocurrencies.
Továbbá van egy blokklánc adattároló modulunk, amely magában foglalja az adatfeldolgozást, a prioritás választást, blokkok hozzáadását, blokkok leválasztását, e blokkok ellenőrzését stb.
A harmadik modul neve EVM (Ethereum virtuális gép) — ez az, virtuális gép, amely a byte-kódot veszi az Ethereum tranzakcióból. Ez a modul veszi a bizonyos fiók aktuális állapotát, és végrehajtja az állapotának változásait a kapott byte-kód alapján. A virtuális gép verziójának minden hálózati csomóponton azonosnak kell lennie. A számítások minden Ethereum csomóponton abszolút azonosak, de aszinkron módon zajlanak: valaki előbb ellenőrzi és fogadja el ezt a tranzakciót, azaz végrehajtja az egész benne lévő kódot, valaki pedig később. Ennek megfelelően a tranzakció létrehozásakor az elterjed a hálózatban, a csomópontok fogadják, és az ellenőrzés pillanatában pontosan úgy, ahogyan a Bitcoinban a Bitcoin Script végrehajtása zajlik, itt a virtuális gép byte-kódját hajtják végre.
A tranzakció akkor minősül ellenőrzöttnek, ha az összes benne lévő kódot végrehajtották, új állapotot generáltak egy adott fióknál, és ezt az állapotot megőrzik, amíg nem derül ki, hogy ezt a tranzakciót alkalmazták-e vagy sem. Ha a tranzakciót alkalmazták, akkor ezt az állapotot nemcsak végrehajtottnak, hanem aktuálisnak is tekintjük. Van egy adatbázis, amely nyilvántartja minden fiók állapotát a hálózat minden csomópontja számára. Mivel minden számítás azonos módon zajlik, és a blokklánc állapota is azonos, a fiókok összes állapotát tartalmazó adatbázis is azonos lesz minden csomópontban.
A smart szerződésekkel kapcsolatos mítoszok és korlátozások
Ami a hasonló Ethereum platformok smart szerződéseinek korlátozásait illeti, az alábbiakat lehet megemlíteni:
- kód végrehajtás;
- memória allokálás;
- blokklánc adatok;
- fizetések küldése;
- új szerződés létrehozása;
- más szerződések hívása.
Nézzük meg azokat a korlátozásokat, amelyeket a virtuális gépre alkalmaznak, és ezzel együtt oszlassuk el a híreszteléseket a okos szerződésekről. A virtuális gépen, amely nemcsak az Ethereum-on, hanem hasonló platformokon is megtalálható, valóban szabad logikai műveletek végezhetők, tehát lehet kódot írni, amely ott végrehajtható, emellett további memóriát is lehet rendelni. Azonban a díjat külön kell megfizetni minden egyes műveletért és minden egyes plusz memóriáért.
Ezen kívül a virtuális gép képes adatokat olvasni a blokklánc adatbázisból, hogy ezeket az adatokat triggerekként használja az okos szerződések logikájának végrehajtására. A virtuális gép tranzakciókat hozhat létre és küldhet, új szerződéseket generálhat, és más, már a hálózaton közzétett okos szerződések metódusait hívhatja meg: amelyek léteznek, elérhetők, stb.
A legelterjedtebb mítosz az, hogy az Ethereum okos szerződései bármilyen internetes forrást felhasználhatnak a feltételeikben. Az igazság az, hogy a virtuális gép nem képes hálózati kéréseket küldeni külső információs forrásoknak az interneten, tehát nem lehet olyan okos szerződést írni, amely értéket osztana szét a felhasználók között annak függvényében, például, hogy milyen időjárás van kint, vagy ki nyert egy bizonyos bajnokságban, vagy hogy mi történt a külvilágban, mert ezeknek az eseményeknek az információja egyszerűen nem létezik a platform adatbázisában. Tehát a blokkláncon ezzel kapcsolatban semmi sincs. Ha ez ott nem jelenik meg, akkor a virtuális gép sem tudja ezeket az adatokat triggerekként használni.
Az Ethereum hátrányai
Soroljunk fel néhány alapvető problémát. Az első hátrány az, hogy nehézségek merülnek fel az Ethereumon készült okosszerződések tervezése, fejlesztése és tesztelése során (az okosszerződések írásához Solidity nyelvet használnak az Ethereumon). Valóban, a gyakorlat azt mutatja, hogy a hibák nagyon nagy százaléka az emberi tényezőhöz köthető. Ez ténylegesen vonatkozik már elkészített Ethereum okosszerződésekre is, amelyek komplexitása közepes vagy annál magasabb. Ha az egyszerű okosszerződések esetében a hiba valószínűsége alacsony, akkor a bonyolult okosszerződésekben gyakran fordulnak elő olyan hibák, amelyek pénzkivonáshoz, a pénzeszközök befagyasztásához, vagy az okosszerződések váratlan módon történő megsemmisítéséhez vezetnek, stb. Már sok ilyen esetről tudunk.
A második hátrány, hogy maga a virtuális gép sem tökéletes, mivel azt is emberek írták. Képes tetszőleges parancsokat végrehajtani, és ebben rejlik a sebezhetősége: bizonyos módon konfigurálhatók parancsok, amelyek előre nem látható következményekhez vezetnek. Ez egy nagyon bonyolult terület, de már léteznek kutatások, amelyek azt mutatják, hogy ezek a sebezhetőségek jelen vannak az Ethereum hálózat jelenlegi verziójában, és sok okosszerződés működésképtelenné válásához vezethetnek.
Még egy nagy nehézség, amit hátránynak tekinthetünk. Ez abban rejlik, hogy gyakorlatilag vagy technikailag el lehet jutni oda, hogy ha lefordítjuk a szerződés byte-kódját, amely a virtuális gépen végrehajtásra kerül, akkor meghatározható egy bizonyos specifikus műveleti sorrend. Ezeknek a műveleteknek a végrehajtása összességében nagyon megterheli a virtuális gépet, és aránytalanul lelassítja azt a díjhoz képest, amelyet az ilyen műveletek végrehajtásáért fizettek.
A múltban már volt egy olyan időszak az Ethereum fejlődésében, amikor sok olyan fiatal, aki részletesen ismerte a virtuális gép működését, olyan sebezhetőségeket fedezett fel. A tranzakciók ténylegesen nagyon kis díjat fizettek, de lényegében nagyon lelassították az egész hálózat működését. Ezeket a problémákat nagyon nehéz megoldani, mivel először is meghatározni kell őket, másodszor ki kell igazítani az ilyen műveletek végrehajtásának árát, és harmadszor végre kell hajtani egy hardforkot, ami azt jelenti, hogy az összes csomópontot frissíteni kell az új szoftververzióra, majd ezeket a változásokat egyszerre aktiválni kell.
Ami az Ethereumot illeti, nagyon sok kutatást végeztek, rendkívül nagy gyakorlati tapasztalatra tettek szert: mind pozitív, mind negatív szempontból, de ennek ellenére még mindig fennállnak nehézségek és sebezhetőségek, amelyeket még valahogyan meg kell oldani.
Tehát a cikk tematikus része befejeződött, térjünk át azokra a kérdésekre, amelyek elég gyakran felmerülnek.
Gyakran ismételt kérdések
— Ha a működő okosszerződés minden fele szeretné megváltoztatni a feltételeket, akkor törölhetik-e ezt az okosszerződést több aláírás segítségével, majd létrehozhatnak egy új okosszerződést a módosított végrehajtási feltételekkel?
Itt a válasz kettős lesz. Miért? Mert egyrészt az okosszerződés egyszeri beállítása után már nem feltételez semmilyen változást, másrészt lehet olyan előre meghatározott logikája, amely lehetővé teszi bizonyos feltételek teljes vagy részleges megváltoztatását. Tehát ha valamit változtatni szeretne az okosszerződésében, előre meg kell határoznia a feltételeket, amelyek szerint frissítheti ezeket a feltételeket. Ennek megfelelően csak ilyen körültekintő módon lehet megszervezni a szerződés frissítését. De itt is előfordulhat, hogy valamilyen hibát vét, és ennek következményeként sebezhetőséget von maga után. Ezért az ilyen dolgokat nagyon részletesen és gondosan kell megtervezni és tesztelni.
— És mi van, ha a közvetítő összeesküszik az egyik résztvevő féllel: az escrow-val vagy az okosszerződéssel? Kötelező-e a közvetítő az okosszerződésben?
A közvetítő nem kötelező a okos szerződésben. Lehet, hogy nincs jelen. Ha az escrow esetében a közvetítő együttműködik az egyik féllel, akkor igen, ez a rendszer hirtelen elveszíti az értékét. Ezért a közvetítőket úgy választják ki, hogy mindkét fél bízzon bennük, akik részt vesznek ebben a folyamatban. Ennek megfelelően egyszerűen nem fogja átutalni a kriptovalutákat a multisignature címre annak a közvetítőnek, akiben nem bízik.
— Lehetséges-e egyetlen Ethereum tranzakcióval sok különböző tokent átkonvertálni a címemről különböző célcímekre, például olyan tőzsdei címekre, ahol ezek a tokenek kereskednek?
Ez egy jó kérdés, és a tranzakciós modellek közötti különbséget érinti az Ethereum és a Bitcoin között. A különbség radikális. Az Ethereum tranzakciós modelljében egyszerűen átutal egy összeget, amely csak egyik címről a másikra megy, visszajáró nélkül, csak a megadott összeg. Más szóval, ez nem az UTXO modell, hanem a fiókmodell és a hozzá tartozó egyenlegek modellje. Egy tranzakcióval elméletileg több különböző tokenet is küldhet, ha ír egy ügyes okos szerződést, de ennek ellenére sok tranzakciót kell végrehajtani, létre kell hozni a szerződést, majd át kell adni neki a tokeneit és az érméit, végül pedig ki kell hívnia a megfelelő metódust. Ez erőfeszítést és időt igényel, így a gyakorlatban ez nem működik, és az összes Ethereum tranzakciót külön tranzakciókként hajtják végre.
— Az Ethereum platform egyik mítosza az, hogy lehetetlen olyan feltételeket megfogalmazni, amelyek külső internetes források adataitól függnek, hogyan lehet akkor ezt kezelni?
A megoldás abban rejlik, hogy maga az okos szerződés több úgynevezett megbízható oracle-t is előirányozhat, akik adatokat gyűjtenek a külvilág állapotáról, és azokat speciális metódusokon keresztül továbbítják az okos szerződésekbe. Maga a szerződés igaznak tekinti azokat az adatokat, amelyeket megbízható felektől kapott. A megbízhatóság érdekében egyszerűen nagyobb csoportot választanak az oracle-okból, és minimalizálják a megállapodás kockázatát. A szerződés figyelmen kívül hagyhatja az oracle-ok adatait, amelyek ellentmondanak a többségnek.
E témával foglalkozik a Blockchain online kurzus egyik előadása — "”.
Forrás: habr.com
