Ebben a cikkben megnézzük, mik is azok az okosszerződések, mik azok, megismerkedünk a különböző okosszerződéses platformokkal, azok jellemzőivel, valamint kitérünk arra is, hogyan működnek és milyen előnyökkel járhatnak. Ez az anyag nagyon hasznos lesz azoknak az olvasóknak, akik nem ismerik jól az intelligens szerződések témáját, de szeretnének közelebb kerülni annak megértéséhez.
Rendes szerződés vs. okos szerződés
Mielőtt belemélyednénk a részletekbe, vegyünk egy példát a normál, papíron meghatározott szerződés és a digitálisan ábrázolt intelligens szerződés közötti különbségekre.
Hogyan működött ez az intelligens szerződések megjelenése előtt? Képzeljünk el emberek egy csoportját, akik meg akarnak állítani bizonyos szabályokat és feltételeket az értékek elosztására, valamint egy bizonyos mechanizmust, amely garantálja ennek az elosztásnak az adott szabályok és feltételek szerinti megvalósítását. Majd összeálltak, papírt készítettek, amelyre felírták az azonosító adataikat, a feltételeket, az érintett értékeket, dátumozták és aláírták. Ezt a szerződést megbízható fél, például közjegyző is hitelesítette. Továbbá ezek az emberek különböző irányokba mentek egy ilyen szerződés papírpéldányával, és elkezdtek olyan műveleteket végrehajtani, amelyek esetleg nem felelnek meg magának a szerződésnek, vagyis tettek egy dolgot, de papíron tanúsították, hogy valamit tenniük kell. teljesen különböző. És hogyan lehet kikerülni ebből a helyzetből? Valójában az egyik csoporttagnak át kell vennie ezt a papírt, bizonyítékot kell vennie, bíróság elé kell vinnie, és el kell érnie a szerződés és a tényleges intézkedések közötti összhangot. Gyakran nehéz e szerződés tisztességes végrehajtását elérni, ami kellemetlen következményekkel jár.
Mit mondhatunk az intelligens szerződésekről? Egyesítik a szerződési feltételek megírásának lehetőségét és a szigorú végrehajtási mechanizmust. Ha a feltételeket meghatározták, és a megfelelő tranzakciót vagy kérést aláírták, akkor a kérelem vagy tranzakció elfogadása után a feltételek megváltoztatása, végrehajtásuk befolyásolása már nem lehetséges.
Van egy validátor vagy egy teljes hálózat, valamint egy adatbázis, amely szigorú időrendi sorrendben tárolja az összes végrehajtásra benyújtott intelligens szerződést. Az is fontos, hogy ennek az adatbázisnak tartalmaznia kell az intelligens szerződés végrehajtásához szükséges összes triggerfeltételt. Ezenkívül figyelembe kell vennie azt az értéket, amelynek felosztását a szerződés leírja. Ha ez valamilyen digitális pénznemre vonatkozik, akkor ennek az adatbázisnak ezt figyelembe kell vennie.
Más szóval, az intelligens szerződésérvényesítőknek hozzá kell férniük az összes adathoz, amelyen az intelligens szerződés működik. Például egyetlen adatbázist kell használni a digitális pénznemek, a felhasználói egyenlegek, a felhasználói tranzakciók és az időbélyegek egyidejű elszámolására. Ekkor egy intelligens szerződésben feltétel lehet a felhasználó egyenlege egy bizonyos devizában, egy bizonyos időpont megérkezése, vagy az, hogy egy bizonyos tranzakciót végrehajtottak, de semmi több.
Az intelligens szerződés meghatározása
Általában magát a terminológiát Nick Szabó kutató alkotta meg, és először 1994-ben használták, és 1997-ben dokumentálták egy cikkben, amely leírja az intelligens szerződések gondolatát.
Az intelligens szerződések magukban foglalják az értékelosztás bizonyos automatizálását, ami csak az előre meghatározott feltételeken múlhat. A legegyszerűbb formájában úgy néz ki, mint egy szigorúan meghatározott feltételekkel kötött szerződés, amelyet bizonyos felek írnak alá.
Az intelligens szerződések célja a harmadik felek iránti bizalom minimalizálása. Néha teljesen kizárják azt a döntési központot, amelyen minden múlik. Ráadásul az ilyen szerződéseket könnyebb ellenőrizni. Ez egy ilyen rendszer egyes tervezési sajátosságainak következménye, de leggyakrabban intelligens szerződésen decentralizált környezetet és olyan funkciók jelenlétét értjük, amelyek lehetővé teszik az adatbázis elemzését és a szerződések végrehajtásának teljes körű ellenőrzését. Ez biztosítja a védelmet az olyan visszamenőleges adatváltozásokkal szemben, amelyek a szerződés teljesítésében is változásokat vonnának maguk után. A legtöbb folyamat digitalizálása az intelligens szerződések létrehozásakor és elindításakor gyakran leegyszerűsíti a megvalósítás technológiáját és költségeit.
Egy egyszerű példa - Letéti szolgáltatás
Nézzünk egy nagyon egyszerű példát. Segítségével közelebb kerülhet az intelligens szerződések funkcióinak megértéséhez, valamint jobban megértheti, hogy milyen esetekben érdemes azokat használni.
Bitcoin segítségével is megvalósítható, bár a Bitcoin jelenleg még aligha nevezhető az okosszerződések teljes értékű platformjának. Tehát van néhány vásárlónk, és van egy webáruházunk. Egy vásárló monitort szeretne vásárolni ebből az üzletből. A legegyszerűbb esetben a vásárló teljesíti és elküldi a fizetést, a webáruház pedig elfogadja, visszaigazolja, majd kiszállítja az árut. Ebben a helyzetben azonban nagy bizalomra van szükség - a vásárlónak a monitor teljes költségében az online áruházban kell megbíznia. Mivel egy webáruháznak rossz hírneve lehet a vásárló szemében, fennáll annak a veszélye, hogy a fizetés elfogadása után az áruház valamilyen okból megtagadja a szolgáltatást, és nem küldi ki az árut a vevőnek. Ezért a vásárló felteszi a kérdést (és ennek megfelelően az online áruház is felteszi ezt a kérdést), hogy ebben az esetben mit lehet alkalmazni az ilyen kockázatok minimalizálása és az ilyen tranzakciók megbízhatóbbá tétele érdekében.
A Bitcoin esetében lehetőség van arra, hogy a vevő és az eladó egymástól függetlenül válasszon közvetítőt. Sokan vesznek részt a vitás kérdések megoldásában. Résztvevőink pedig a közvetítők általános listájáról választhatják ki azt, akiben megbíznak. Együtt létrehoznak egy 2/3 többaláírású címet, ahol három kulcs van, és két aláírásra van szükség tetszőleges két kulccsal ahhoz, hogy az adott címről érméket költsenek. Az egyik kulcs a vásárlóé, a második az online áruházé, a harmadik a közvetítőé lesz. És egy ilyen több aláírású címre a vevő 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 tiltva egy több aláírással rendelkező címen, amely tőle függ, nyugodtan elküldheti a monitort postán.
Ezután a vevő átveszi a csomagot, megvizsgálja az árut, és döntést hoz a végső vásárlásról. Előfordulhat, hogy teljes mértékben egyetért a nyújtott szolgáltatással, és a kulcsával aláírja a tranzakciót, ahol a többaláírású címről utal át érméket az eladónak, esetleg valamivel elégedetlen. A második esetben felveszi a kapcsolatot egy közvetítővel, hogy összeállítson egy alternatív tranzakciót, amely másként osztja el ezeket az érméket.
Mondjuk a monitor egy kicsit karcosan érkezett, és a készletben nem volt a számítógéphez való csatlakozáshoz szükséges kábel, pedig a webáruház honlapján azt írták, hogy a kábelnek a készletben kell lennie. Ezután a vevő összegyűjti a szükséges bizonyítékokat annak bizonyítására, hogy a közvetítő becsapták ebben a helyzetben: képernyőképeket készít a webhelyről, lefényképezi a postai nyugtát, lefényképezi a karcolásokat a monitoron, és megmutatja, hogy a pecsét eredeti eltört és kihúzták a kábelt. Az online áruház pedig összegyűjti a bizonyítékait, és átadja a közvetítőnek.
A közvetítő abban érdekelt, hogy egyszerre elégítse ki a vásárló felháborodását és az online áruház érdekeit (a későbbiekben kiderül, miért). Olyan tranzakcióról van szó, amelyben a többaláírású címről származó érmék bizonyos arányban elköltésre kerülnek a vásárló, az online áruház és a közvetítő között, hiszen munkájáért jutalmul egy részt vesz magának. Tegyük fel, hogy a teljes összeg 90%-a az eladót kapja, 5%-a a közvetítőt és 5%-a a vevőt kompenzálja. A közvetítő ezt a tranzakciót aláírja a kulcsával, de még nem alkalmazható, mert két aláírás kell, de csak egy éri meg. Az ilyen tranzakciót mind a vevőnek, mind az eladónak elküldi. Ha legalább egyikük elégedett ezzel a lehetőséggel az érmék újraelosztására, akkor a tranzakció előzetes aláírásra kerül és kiosztásra kerül a hálózaton. Érvényesítéséhez elegendő, ha az ügyletben részt vevő egyik fél egyetért a közvetítő lehetőségével.
Fontos, hogy kezdetben közvetítőt válasszunk, hogy mindkét résztvevő megbízzon benne. Ebben az esetben egyik vagy másik érdekeitől függetlenül jár el, és objektíven értékeli a helyzetet. Ha a közvetítő nem biztosít lehetőséget olyan érmék kiosztására, amely legalább egy résztvevőt kielégít, úgy a vevő és az online áruház közös megegyezés után két aláírásával új többaláírású címre küldheti az érméket. Az új többaláírási címet egy másik közvetítő állítja össze, aki kompetensebb lehet az ügyben, és jobb lehetőséget kínál.
Például egy kollégium és egy hűtőszekrény
Nézzünk egy összetettebb példát, amely egyértelműbben jeleníti meg az intelligens szerződés képességeit.
Tegyük fel, hogy három srác nemrég költözött ugyanabba a kollégiumi szobába. Ők hárman szeretnének egy közös használatú hűtőszekrényt vásárolni a szobájukba. Egyikük önként jelentkezett, hogy összegyűjti a szükséges összeget egy hűtőszekrény vásárlásához, és tárgyaljon az eladóval. Azonban csak nemrég találkoztak egymással, és nincs köztük kellő bizalom. Nyilvánvalóan ketten közülük kockáztatnak azzal, hogy pénzt adnak a harmadiknak. Ezenkívül megállapodásra kell jutniuk az eladó kiválasztásában.
Használhatják a letéti szolgáltatást, azaz választhatnak egy közvetítőt, aki figyelemmel kíséri a tranzakció lebonyolítását és megoldja a vitás kérdéseket, ha azok felmerülnek. Majd megegyezés után okos szerződést kötnek, és abban bizonyos feltételeket írnak elő.
Az első feltétel az, hogy egy bizonyos idő előtt, mondjuk egy héten belül, a megfelelő intelligens szerződéses számlára három kifizetést kell kapnia bizonyos címekről egy bizonyos összegért. Ha ez nem történik meg, az intelligens szerződés leáll, és visszaküldi az érméket minden résztvevőnek. Ha a feltétel teljesül, akkor az eladó és a közvetítő azonosító értékei beállnak, és a feltétel ellenőrzése, hogy minden résztvevő egyetért-e az eladó és a közvetítő választásával. Ha minden feltétel teljesül, a pénzeszközöket a megadott címekre utaljuk. Ez a megközelítés megvédheti a résztvevőket a csalástól bármely oldalról, és általában kiküszöböli a bizalom szükségességét.
Ebben a példában azt az elvet látjuk, hogy az egyes feltételek teljesítéséhez szükséges paraméterek lépésről lépésre történő beállításának lehetősége lehetővé teszi bármilyen összetettségű és beágyazott szint mélységű rendszer létrehozását. Ezenkívül először az első feltételt definiálhatja az intelligens szerződésben, és csak annak teljesülése után lehet paramétereket beállítani a következő feltételhez. Vagyis a feltétel formálisan meg van írva, és már működés közben beállíthatók a paraméterei.
Intelligens szerződések osztályozása
Az osztályozáshoz különböző kritériumcsoportokat állíthat be. A technológiai fejlesztés pillanatában azonban ezek közül négy releváns.
Az intelligens szerződéseket végrehajtási környezetük alapján lehet megkülönböztetni, amely lehet centralizált vagy decentralizált. Decentralizáció esetén sokkal nagyobb a függetlenségünk és a hibatűrésünk az intelligens szerződések végrehajtása során.
A feltételek beállításának és teljesítésének folyamata alapján is megkülönböztethetők: lehetnek szabadon programozhatók, korlátozottak vagy előre definiáltak, azaz szigorúan tipizáltak. Ha csak 4 konkrét intelligens szerződés van az intelligens szerződés platformon, akkor ezek paraméterei bármilyen módon beállíthatók. Ennek megfelelően ezek beállítása sokkal egyszerűbb: kiválasztunk egy szerződést a listából, és átadjuk a paramétereket.
A kezdeményezési mód szerint léteznek automatizált okosszerződések, azaz bizonyos feltételek fennállása esetén önmegvalósítók, és vannak olyan szerződések, amelyekben a feltételek meg vannak határozva, de a platform nem ellenőrzi automatikusan azok teljesülését, ehhez külön kell kezdeményezni.
Ezen túlmenően az intelligens szerződések adatvédelmi szintje is eltérő. Lehetnek teljesen nyíltak, részben vagy teljesen bizalmasak. Ez utóbbi azt jelenti, hogy a külső megfigyelők nem látják az intelligens szerződések feltételeit. A magánélet témája azonban nagyon tág, és jobb, ha ezt a jelenlegi cikktől külön kezeljük.
Az alábbiakban közelebbről megvizsgáljuk az első három kritériumot, hogy jobban érthetővé tegyük az aktuális téma megértését.
Intelligens szerződések futásidő szerint
A végrehajtási környezet alapján megkülönböztetünk centralizált és decentralizált intelligens szerződéses platformokat. A központosított digitális szerződések esetében egyetlen szolgáltatást alkalmaznak, ahol csak egy érvényesítő van, és lehet egy biztonsági mentési és helyreállítási szolgáltatás is, amely szintén központilag kezelt. Van egy adatbázis, amely minden szükséges információt tárol az intelligens szerződés feltételeinek meghatározásához és az érték elosztásához, amelyet ebben a szolgáltatási adatbázisban vesznek figyelembe. Egy ilyen központosított szolgáltatásnak van egy ügyfele, aki bizonyos kérésekkel feltételeket szab, és ilyen szerződéseket vesz igénybe. A platform centralizált jellege miatt a hitelesítési mechanizmusok kevésbé biztonságosak, mint a kriptovaluták esetében.
Példaként vehetjük a mobilkommunikációs szolgáltatókat (különböző mobilszolgáltatókat). Tegyük fel, hogy egy bizonyos szolgáltató központosított nyilvántartást vezet a szerverein a forgalomról, amelyet különböző formátumokban továbbíthat, például: hanghívások, SMS átvitel, mobilinternet forgalom formájában, és különböző szabványok szerint, és nyilvántartást is vezet. a felhasználói egyenlegeken lévő pénzeszközök. Ennek megfelelően a mobilkommunikációs szolgáltató eltérő feltételekkel köthet szerződést a nyújtott szolgáltatások elszámolására és azok kifizetésére. Ilyenkor könnyen beállítható olyan feltételek, hogy „küldj SMS-t ilyen és ilyen kóddal ilyen és olyan számra, és ilyen-olyan feltételeket kapsz a forgalomelosztáshoz”.
Még egy példa hozható: hagyományos bankok, kibővített internetes banki funkcionalitással és nagyon egyszerű szerződésekkel, mint például a rendszeres fizetés, a bejövő fizetések automatikus konvertálása, az automatikus kamatlevonás egy meghatározott számlára stb.
Ha decentralizált végrehajtási környezettel rendelkező intelligens szerződésekről beszélünk, akkor van egy csoport érvényesítőnk. Ideális esetben bárki válhat érvényesítővé. Az adatbázis-szinkronizációs protokollnak és a konszenzus elérésének köszönhetően van néhány közös adatbázisunk, amely mostantól az összes tranzakciót, szigorúan leírt szerződésekkel tárolja, és nem néhány feltételes lekérdezést, amelyek formátuma gyakran változik, és nincs nyitott specifikáció. Itt a tranzakciók utasításokat tartalmaznak a szerződés szigorú specifikáció szerinti végrehajtására. Ez a specifikáció nyitott, ezért a platformfelhasználók maguk is auditálhatják és érvényesíthetik az intelligens szerződéseket. Itt azt látjuk, hogy a decentralizált platformok függetlenségük és hibatűrésük szempontjából felülmúlják a centralizált platformokat, de tervezésük és karbantartásuk sokkal összetettebb.
Intelligens szerződések a feltételek meghatározásával és teljesítésével
Most pedig nézzük meg közelebbről, hogy az intelligens szerződések miben térhetnek el a feltételek meghatározásában és teljesítésében. Itt figyelmünket a véletlenszerűen programozható és Turing komplett intelligens szerződésekre irányítjuk. A Turing-komplett intelligens szerződés lehetővé teszi, hogy szinte bármilyen algoritmust beállítson a szerződés végrehajtásának feltételeként: írási ciklusokat, bizonyos valószínűségszámítási függvényeket és hasonlókat - egészen a saját elektronikus aláírási algoritmusaiig. Ebben az esetben valóban önkényes logikaírást értünk.
Vannak tetszőleges intelligens szerződések is, de nem Turing komplett szerződések. Ez magában foglalja a Bitcoint és a Litecoint is saját szkripttel. Ez azt jelenti, hogy csak bizonyos műveleteket használhat bármilyen sorrendben, de ciklusokat és saját algoritmusokat már nem írhat.
Emellett léteznek intelligens szerződéses platformok, amelyek előre meghatározott intelligens szerződéseket valósítanak meg. Ide tartozik a Bitshares és a Steemit. A Bitshares számos intelligens szerződéssel rendelkezik a kereskedéshez, számlakezeléshez, magának a platformnak és paramétereinek kezeléséhez. A Steemit egy hasonló platform, de már nem a tokenek kibocsátására és a kereskedésre koncentrál, mint a Bitshares, hanem a blogírásra, azaz decentralizáltan tárolja és dolgozza fel a tartalmat.
Az önkényes Turing-teljes szerződések közé tartozik az Ethereum platform és a RootStock, amely még fejlesztés alatt áll. Ezért az alábbiakban egy kicsit részletesebben foglalkozunk az Ethereum intelligens szerződéses platformjával.
Intelligens szerződések kezdeményezési módszerrel
Az intelligens szerződések a kezdeményezés módja alapján is legalább két csoportra oszthatók: automatizált és kézi (nem automatizált). Az automatizáltak jellemzője, hogy az összes ismert paraméter és feltétel mellett az intelligens szerződés teljes mértékben automatikusan végrehajtásra kerül, azaz nem igényel további tranzakciók küldését és további jutalék kiadását minden további végrehajtás után. Maga a platform rendelkezik minden adattal ahhoz, hogy kiszámítsa, hogyan fog teljesülni az intelligens szerződés. A logika ott nem önkényes, hanem előre meghatározott, és mindez előre megjósolható. Vagyis előre megbecsülheti egy intelligens szerződés végrehajtásának bonyolultságát, valamilyen állandó jutalékot használhat rá, és a végrehajtásához szükséges összes folyamat hatékonyabb.
A szabadon programozott intelligens szerződések végrehajtása nem automatizált. Egy ilyen intelligens szerződés kezdeményezéséhez gyakorlatilag minden lépésnél új tranzakciót kell létrehozni, amely meghívja a következő végrehajtási szakaszt vagy a következő intelligens szerződés módszerét, kifizeti a megfelelő jutalékot és megvárja a tranzakció megerősítését. A végrehajtás sikeresen befejeződhet vagy nem, mert az intelligens szerződés kódja tetszőleges, és előfordulhatnak előre nem látható pillanatok, például örök hurok, néhány paraméter és argumentum hiánya, kezeletlen kivételek stb.
Ethereum fiókok
Ethereum fióktípusok
Nézzük meg, milyen típusú fiókok lehetnek az Ethereum platformon. Itt csak kétféle fiók létezik, és nincs más lehetőség. Az első típust felhasználói fióknak, a másodikat szerződéses fióknak nevezzük. Nézzük meg, miben különböznek egymástól.
A felhasználói fiókot csak az elektronikus aláírás személyes kulcsa vezérli. A számlatulajdonos létrehozza saját kulcspárját az elektronikus aláíráshoz az ECDSA (Elliptic Curve Digital Signature Algorithm) algoritmus segítségével. Csak az ezzel a kulccsal aláírt tranzakciók módosíthatják a fiók állapotát.
Az intelligens szerződéses fiókhoz külön logika tartozik. Csak előre definiált szoftverkóddal vezérelhető, amely teljes mértékben meghatározza az intelligens szerződés viselkedését: bizonyos körülmények között hogyan kezeli az érméit, melyik felhasználó kezdeményezésére és milyen további feltételek mellett kerül kiosztásra. Ha egyes pontokat a fejlesztők nem biztosítanak a programkódban, problémák merülhetnek fel. Például egy intelligens szerződés olyan állapotot kaphat, amelyben nem fogadja el a további végrehajtás kezdeményezését egyik felhasználótól sem. Ebben az esetben az érmék ténylegesen lefagynak, mert az okosszerződés nem rendelkezik az állapotból való kilépésről.
Hogyan jönnek létre fiókok az Ethereumon
Felhasználói fiók esetén a tulajdonos önállóan generál kulcspárt az ECDSA segítségével. Fontos megjegyezni, hogy az Ethereum pontosan ugyanazt az algoritmust és pontosan ugyanazt az elliptikus görbét használja az elektronikus aláírásokhoz, mint a Bitcoin, de a cím kiszámítása kissé eltérő módon történik. Itt már nem használjuk a kettős hash eredményét, mint a Bitcoinban, hanem a Keccak függvénnyel az egyszeri hash-t 256 bit hosszúságban biztosítjuk. A legkevésbé szignifikáns biteket levágjuk a kapott értékből, vagyis a kimeneti hash érték legkisebb jelentőségű 160 bitjét. Ennek eredményeként kapunk egy címet az Ethereumban. Valójában 20 bájtot foglal el.
Felhívjuk figyelmét, hogy az Ethereum számlaazonosítója hexadecimálisan van kódolva ellenőrzőösszeg alkalmazása nélkül, ellentétben a Bitcoinnal és sok más rendszerrel, ahol a cím egy 58-as alapszámrendszerben van kódolva ellenőrző összeg hozzáadásával. Ez azt jelenti, hogy óvatosnak kell lennie az Ethereum számlaazonosítóival való munka során: az azonosító egyetlen hibája is garantáltan érmék elvesztéséhez vezet.
Van egy fontos jellemzője, hogy egy általános adatbázis szintű felhasználói fiók akkor jön létre, amikor elfogadja az első bejövő fizetést.
Az intelligens szerződéses fiók létrehozása teljesen más megközelítést igényel. Kezdetben az egyik felhasználó megírja az intelligens szerződés forráskódját, majd a kódot egy, az Ethereum platformhoz speciális fordítóprogramon keresztül továbbítják, így saját Ethereum virtuális gépéhez kapnak bájtkódot. Az eredményül kapott bájtkód a tranzakció speciális mezőjébe kerül. A kezdeményező fiókja nevében hitelesítik. Ezután ezt a tranzakciót a rendszer továbbítja a hálózaton, és elhelyezi az intelligens szerződés kódját. A tranzakció és ennek megfelelően a szerződés teljesítésének jutaléka levonásra kerül a kezdeményező számlájának egyenlegéről.
Minden intelligens szerződés szükségszerűen tartalmazza a saját kivitelezőjét (e szerződésnek). Lehet üres, vagy lehet benne tartalom. A konstruktor végrehajtása után létrejön egy intelligens szerződéses számlaazonosító, amellyel érméket küldhet, meghívhat bizonyos intelligens szerződéses módszereket stb.
Ethereum tranzakciós struktúra
A világosabbá tétel érdekében elkezdjük megvizsgálni egy Ethereum-tranzakció szerkezetét és egy példa intelligens szerződéskódot.
Egy Ethereum-tranzakció több mezőből áll. Ezek közül az első, a nonce, a tranzakció bizonyos sorszáma magához a számlához viszonyítva, amely forgalmazza és a szerzője. Erre a kettős tranzakciók megkülönböztetése érdekében van szükség, vagyis annak az esetnek a kizárásához, amikor ugyanazt a tranzakciót kétszer fogadják el. Azonosító használatával minden tranzakció egyedi hash értékkel rendelkezik.
Ezután jön egy olyan mező, mint gáz ára. Ez azt az árat jelöli, amelyen az Ethereum alapvalutát gázzá váltják, amivel az intelligens szerződés végrehajtását és a virtuális gép erőforrásának kiosztását fizetik. Mit jelent?
A Bitcoinban a díjakat közvetlenül az alapvaluta – maga a bitcoin – fizeti. Ez egy egyszerű számítási mechanizmusnak köszönhető: szigorúan a tranzakcióban szereplő adatmennyiségért fizetünk. Az Ethereumban a helyzet bonyolultabb, mert nagyon nehéz a tranzakciós adatok mennyiségére hagyatkozni. Itt a tranzakció a virtuális gépen végrehajtandó programkódot is tartalmazhat, és a virtuális gép minden egyes művelete eltérő bonyolultságú lehet. Vannak olyan műveletek is, amelyek memóriát foglalnak le a változókhoz. Megvan a saját összetettségük, amelytől függ az egyes műveletek kifizetése.
Az egyes műveletek gázegyenértékben kifejezett költsége állandó lesz. Kifejezetten az egyes műveletek állandó költségének meghatározására kerül bevezetésre. A hálózat terhelésétől függően változik a gáz ára, vagyis az az együttható, amely szerint az alapdevizát erre a segédegységre váltják át a jutalék kifizetéséhez.
A tranzakciónak van még egy jellemzője az Ethereumban: a virtuális gépben végrehajtandó bájtkódot addig hajtják végre, amíg az valamilyen eredménnyel (siker vagy kudarc) be nem fejeződik, vagy amíg el nem fogy a jutalék kifizetéséhez kiosztott érme bizonyos mennyisége. . Azért, hogy elkerüljük azt a helyzetet, amikor valamilyen hiba esetén a feladó számlájáról minden érme jutalékra került (például egy virtuális gépben elindult valamilyen örök körforgás), a következő mező létezik: indítsa el a gázt (gyakran gázlimitnek nevezik) – meghatározza az érmék maximális mennyiségét, amelyet a küldő hajlandó elkölteni egy bizonyos tranzakció végrehajtására.
A következő mező neve rendeltetési cím. Ez magában foglalja az érmék címzettjének címét vagy egy adott intelligens szerződés címét, amelynek metódusait meghívják. Utána jön a mező érték, ahol a célcímre küldött érmék mennyisége kerül megadásra.
Következő egy érdekes mező az ún dátum, ahol az egész szerkezet elfér. Ez nem egy külön mező, hanem egy teljes struktúra, amelyben a virtuális gép kódja van meghatározva. Itt tetszőleges adatokat helyezhet el - erre külön szabályok vonatkoznak.
És az utolsó mezőt hívják aláírás. Ez egyidejűleg tartalmazza a tranzakció szerzőjének elektronikus aláírását és azt a nyilvános kulcsot, amellyel az aláírást ellenőrizni fogják. A nyilvános kulcsból megkaphatja a tranzakció feladójának számlaazonosítóját, azaz egyedileg azonosíthatja magában a rendszerben a küldő számláját. Megtudtuk a lényeget a tranzakció szerkezetéről.
Példa intelligens szerződéskódra a Solidity számára
Nézzük most közelebbről a legegyszerűbb intelligens szerződést egy példa segítségével.
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 egy egyszerűsített forráskód található, amely képes tárolni a felhasználók érméit, és igény szerint visszaküldeni azokat.
Létezik tehát egy Banki okosszerződés, amely a következő funkciókat látja el: az egyenlegén érméket halmoz fel, vagyis amikor egy tranzakciót visszaigazolnak és ilyen intelligens szerződést kötnek, akkor létrejön egy új számla, amely érméket tartalmazhat az egyenlegén; megjegyzi a felhasználókat és az érmék elosztását közöttük; többféle egyenlegkezelési módszerrel rendelkezik, azaz lehetőség van a felhasználó egyenlegének feltöltésére, kivonására és ellenőrzésére.
Nézzük végig a forráskód minden sorát. Ennek a szerződésnek állandó mezői vannak. Ezek közül az egyik, címtípussal, tulajdonosnak hívják. Itt a szerződés megjegyzi az intelligens szerződést létrehozó felhasználó címét. Ezenkívül van egy dinamikus struktúra, amely fenntartja a megfelelést a felhasználói címek és az egyenlegek között.
Ezt követi a Bank metódus - ennek a szerződésnek a neve. Ennek megfelelően ez a konstruktora. Itt a tulajdonos változóhoz annak a személynek a címe van hozzárendelve, aki ezt az intelligens szerződést a hálózatra helyezte. Ebben a konstruktorban ez az egyetlen dolog, ami megtörténik. Vagyis az msg ebben az esetben pontosan az az adat, amely a jelen szerződés teljes kódját tartalmazó tranzakcióval együtt a virtuális gépre került. Ennek megfelelően az msg.sender a szerzője ennek a tranzakciónak, amely ezt a kódot tárolja. Ő lesz az okosszerződés tulajdonosa.
A befizetési mód lehetővé teszi, hogy tranzakciónként meghatározott számú érmét utaljon át a szerződéses számlára. Ebben az esetben az intelligens szerződés, fogadva ezeket az érméket, a mérlegében hagyja azokat, de a mérlegszerkezetben rögzíti, hogy pontosan ki volt az érmék feladója, hogy megtudja, kihez tartoznak.
A következő módszert visszavonásnak hívják, és egy paraméterre van szükség - az érmék mennyiségére, amelyet valaki ki akar venni ebből a bankból. Ez ellenőrzi, hogy van-e elég érme a felhasználó egyenlegében, aki ezt a módszert hívja a küldéshez. Ha van belőlük elég, akkor maga az okosszerződés adja vissza ennyi érmét a hívónak.
Ezután következik a felhasználó aktuális egyenlegének ellenőrzési módszere. Aki ezt a módszert hívja, az az intelligens szerződésben lévő egyenleget lekéri. Érdemes megjegyezni, hogy ennek a módszernek a módosítója a view. Ez azt jelenti, hogy maga a metódus semmilyen módon nem változtatja meg osztályának változóit, és valójában csak olvasási metódus. Ennek a metódusnak a meghívására külön tranzakció nem jön létre, díjat nem kell fizetni, és minden számítás helyben történik, ami után a felhasználó megkapja az eredményt.
A kill módszerre van szükség az intelligens szerződés állapotának megsemmisítéséhez. És itt van egy további ellenőrzés, hogy ennek a módszernek a hívója-e a szerződés tulajdonosa. Ha igen, akkor a szerződés önmegsemmisül, és a megsemmisítési függvény egy paramétert vesz fel - a számlaazonosítót, amelyre a szerződés elküldi az egyenlegén maradt összes érmét. Ebben az esetben a fennmaradó érmék automatikusan a szerződés tulajdonosának címére kerülnek.
Hogyan működik egy teljes csomópont az Ethereum hálózaton?
Nézzük meg sematikusan, hogyan hajtják végre az ilyen intelligens szerződéseket az Ethereum platformon, és hogyan működik a teljes hálózati csomópont.
Az Ethereum hálózat teljes csomópontjának legalább négy modullal kell rendelkeznie.
Az első, mint minden decentralizált protokoll esetében, a P2P hálózati modul – a hálózati csatlakozáshoz és más csomópontokkal való munkavégzéshez szükséges modul, ahol a blokkok, tranzakciók és más csomópontokkal kapcsolatos információk cseréje történik. Ez minden decentralizált kriptovaluta hagyományos összetevője.
Ezután van egy modulunk a blokklánc adatok tárolására, feldolgozására, prioritási ág kiválasztására, blokkok hozzáfűzésére, blokkok leválasztására, ezen blokkok érvényesítésére stb.
A harmadik modul neve EVM (Ethereum virtuális gép) - ez egy virtuális gép, amely bájtkódot kap az Ethereum tranzakciókból. Ez a modul egy adott fiók aktuális állapotát veszi, és a kapott bájtkód alapján módosítja az állapotát. A virtuális gép verziójának minden hálózati csomóponton azonosnak kell lennie. Az egyes Ethereum csomópontokon végbemenő számítások pontosan megegyeznek, de aszinkron módon: valaki korábban ellenőrzi és elfogadja ezt a tranzakciót, azaz végrehajtja az abban található összes kódot, valaki pedig később. Ennek megfelelően a tranzakció létrejöttekor az elosztásra kerül a hálózaton, a csomópontok elfogadják, és az ellenőrzéskor ugyanúgy, mint a Bitcoin Script Bitcoinban, itt is végrehajtódik a virtuális gép bájtkódja.
Egy tranzakció akkor tekinthető ellenőrzöttnek, ha a benne lévő összes kódot végrehajtották, egy bizonyos számla új állapotát generálták és elmentették mindaddig, amíg kiderül, hogy a tranzakciót alkalmazták-e vagy sem. Ha a tranzakciót alkalmazzák, akkor ez az állapot nemcsak befejezettnek, hanem aktuálisnak is tekinthető. Van egy adatbázis, amely az egyes hálózati csomópontokhoz tartozó fiókok állapotát tárolja. Tekintettel arra, hogy minden számítás azonos módon történik, és a blokklánc állapota is azonos, az összes fiók állapotát tartalmazó adatbázis is ugyanaz lesz minden csomópontnál.
Az intelligens szerződések mítoszai és korlátai
Ami az Ethereumhoz hasonló intelligens szerződéses platformokra vonatkozó korlátozásokat illeti, a következőket lehet idézni:
- kód végrehajtása;
- memória lefoglalása;
- blokklánc adatok;
- fizetések küldése;
- új szerződés létrehozása;
- hívjon más szerződéseket.
Nézzük meg a virtuális gépekre vonatkozó korlátozásokat, és ennek megfelelően oszlassunk el néhány mítoszt az intelligens szerződésekkel kapcsolatban. Egy virtuális gépen, ami nem csak Ethereumban, hanem hasonló platformokon is lehet, valóban tetszőleges logikai műveleteket hajthat végre, azaz kódot írhat és ott lefut, plusz memóriát is lefoglalhat. A díjat azonban minden egyes műveletért és minden további lefoglalt memóriaegységért külön kell fizetni.
Ezután a virtuális gép adatokat olvashat ki a blokklánc adatbázisból, hogy ezeket az adatokat triggerként használja egy vagy másik intelligens szerződési logika végrehajtásához. A virtuális gép tud tranzakciókat létrehozni és elküldeni, új szerződéseket tud létrehozni és más, a hálózaton már közzétett intelligens szerződések lehívási metódusait: meglévő, elérhető stb.
A legelterjedtebb mítosz az, hogy az Ethereum intelligens szerződései bármilyen internetes forrásból származó információkat felhasználhatnak a feltételekben. Az igazság az, hogy egy virtuális gép nem tud hálózati kérelmet küldeni valamilyen külső információs forrásnak az interneten, vagyis nem lehet olyan okos szerződést írni, amely értéket oszt el a felhasználók között attól függően, hogy mondjuk milyen az időjárás kint, vagy ki nyert valamilyen bajnokságot, vagy a külvilágban történt egyéb incidens alapján, mert ezekről az incidensekről egyszerűen nincs információ magának a platformnak az adatbázisában. Vagyis a blokkláncon nincs erről semmi. Ha nem jelenik meg ott, akkor a virtuális gép nem tudja ezeket az adatokat triggerként használni.
Az Ethereum hátrányai
Soroljuk fel a főbbeket. Az első hátrány, hogy nehézségekbe ütközik az intelligens szerződések tervezése, fejlesztése és tesztelése az Ethereumban (az Ethereum a Solidity nyelvet használja az intelligens szerződések írásához). Valójában a gyakorlat azt mutatja, hogy az összes hiba nagyon nagy százaléka az emberi tényezőhöz tartozik. Ez tulajdonképpen igaz a már megírt Ethereum intelligens szerződésekre, amelyek átlagos vagy magasabb bonyolultságúak. Ha az egyszerű intelligens szerződéseknél kicsi a hiba valószínűsége, akkor az összetett intelligens szerződéseknél nagyon gyakran előfordulnak olyan hibák, amelyek pénzeszközök ellopásához, befagyasztásához, az intelligens szerződések váratlan megsemmisüléséhez stb. ismert.
A második hátrány, hogy maga a virtuális gép nem tökéletes, hiszen azt is emberek írják. Tetszőleges parancsokat tud végrehajtani, és ebben rejlik a sebezhetőség: számos parancs konfigurálható bizonyos módon, ami előre nem látott következményekhez vezet. Ez egy nagyon összetett terület, de már több tanulmány is azt mutatja, hogy ezek a sérülékenységek az Ethereum hálózat jelenlegi verziójában léteznek, és számos intelligens szerződés meghibásodásához vezethetnek.
Egy másik nagy nehézség, ez hátránynak tekinthető. Ez abban rejlik, hogy gyakorlatilag vagy technikailag arra a következtetésre juthatunk, hogy ha összeállítjuk egy virtuális gépen végrehajtandó szerződés bájtkódját, akkor meghatározhatunk bizonyos műveleti sorrendet. Ha együtt hajtják végre, ezek a műveletek nagymértékben terhelik a virtuális gépet, és aránytalanul lelassítják a műveletek elvégzéséért fizetett díjhoz képest.
A múltban már volt egy időszak az Ethereum fejlesztésében, amikor sok srác, aki részletesen értette a virtuális gép működését, talált ilyen sérülékenységet. Valójában a tranzakciók nagyon csekély díjat fizettek, de gyakorlatilag lelassították az egész hálózatot. Ezeket a problémákat nagyon nehéz megoldani, mivel először meg kell határozni őket, másodsorban módosítani kell a műveletek elvégzésének árát, harmadszor pedig egy hard fork végrehajtását kell végrehajtani, ami azt jelenti, hogy az összes hálózati csomópontot új verzióra kell frissíteni. szoftvert, majd egyidejűleg aktiválja ezeket a változtatásokat.
Ami az Ethereumot illeti, rengeteg kutatást végeztek, sok gyakorlati tapasztalat gyűlt össze: pozitív és negatív egyaránt, de ennek ellenére továbbra is vannak nehézségek és sebezhetőségek, amelyeket még kezelni kell valahogy.
Tehát a cikk tematikus része elkészült, térjünk át a gyakran felmerülő kérdésekre.
Часто задаваемые вопросы
— Ha egy meglévő intelligens szerződés minden fele módosítani szeretné a feltételeket, felmondhatja-e ezt az intelligens szerződést a multisig használatával, majd új intelligens szerződést hozhat létre a frissített végrehajtási feltételekkel?
A válasz itt kettős lesz. Miért? Mert egyrészt az intelligens szerződés egyszer definiálva van, és már nem jelent változást, másrészt lehet előre megírt logikája, amely bizonyos feltételek teljes vagy részleges megváltoztatását biztosítja. Vagyis ha valamit módosítani szeretne az okosszerződésében, akkor elő kell írnia, hogy milyen feltételekkel frissítheti ezeket a feltételeket. Ennek megfelelően csak ilyen körültekintően szervezhető meg a szerződés megújítása. De itt is bajba kerülhet: hibázik, és kap egy megfelelő sebezhetőséget. Ezért az ilyen dolgokat nagyon részletesen, gondosan meg kell tervezni és tesztelni.
— Mi van akkor, ha a közvetítő megállapodást köt valamelyik résztvevő féllel: letéti vagy okos szerződést? Kell-e közvetítő egy okos szerződésben?
Egy okos szerződésben nincs szükség közvetítőre. Lehet, hogy nem is létezik. Ha letétbe helyezés esetén a közvetítő összeesküvésbe lép az egyik féllel, akkor igen, ez a séma élesen veszít minden értékéből. Ezért a közvetítőket úgy választják ki, hogy a folyamatban részt vevő összes fél egyidejűleg megbízzon bennük. Ennek megfelelően egyszerűen nem visz át érméket több aláírású címre olyan közvetítővel, amelyben nem bízik.
— Lehetséges egyetlen Ethereum-tranzakcióval sok különböző tokent átvinni az Ön címéről különböző célcímekre, például olyan címekre, ahol ezekkel a tokenekkel kereskednek?
Ez egy jó kérdés, és az Ethereum tranzakciós modellre vonatkozik, és arra, hogy miben különbözik a Bitcoin modelltől. És a különbség radikális. Ha az Ethereum tranzakciós modellben egyszerűen csak érméket visz át, akkor azok csak az egyik címről a másikra kerülnek átvitelre, nem változik, csak a megadott összeg. Más szóval, ez nem a fel nem használt kimenetek (UTXO) modellje, hanem a számlák és a megfelelő egyenlegek modellje. Elméletileg lehetséges egyszerre több különböző tokent küldeni egy tranzakció során, ha írsz egy ravasz okosszerződést, de akkor is sok tranzakciót kell végrehajtanod, szerződést kell kötned, majd tokeneket és érméket kell átvinned rá, majd meghívni a megfelelő metódust. . Ez erőfeszítést és időt igényel, így a gyakorlatban ez nem így működik, és az Ethereumban minden fizetés külön tranzakcióban történik.
— Az Ethereum platformmal kapcsolatos egyik mítosz, hogy nem lehet leírni azokat a feltételeket, amelyek egy külső internetes forrás adataitól függenek majd, akkor mi a teendő?
A megoldás az, hogy maga az okosszerződés egy vagy több úgynevezett megbízható orákuumot tud biztosítani, amely adatokat gyűjt a külvilág helyzetéről, és speciális módszerekkel továbbítja az okosszerződésekhez. Maga a szerződés is igaznak tekinti azokat az adatokat, amelyeket megbízható felektől kapott. A nagyobb megbízhatóság érdekében egyszerűen válassza ki az orákulumok nagy csoportját, és minimalizálja az összejátszásuk kockázatát. Maga a szerződés nem vehet figyelembe olyan orákulumokat, amelyek a többségnek ellentmondanak.
A Blockchain online kurzus egyik előadása ennek a témának szól - "".
Forrás: will.com