Úvod do smart kontraktov

V tomto článku preskúmame, čo sú smart kontrakty, aké typy existujú, oboznámime sa s rôznymi platformami smart kontraktov, ich špecifikami a diskutujeme o tom, ako fungujú a aké výhody môžu ponúkať. Tento materiál bude veľmi užitočný pre čitateľov, ktorí nie sú dostatočne oboznámení s témou smart kontraktov, ale chcú sa priblížiť k jej pochopeniu.

Bežný kontrakt vs. smart kontrakt

Predtým, než sa hlbšie ponoríme do podrobností, pozrime sa na príklad rozdielu medzi bežným kontraktom, ktorý je stanovený na papieri, a smart kontraktom, ktorý je prezentovaný v digitálnej podobe.

Ako to fungovalo pred nástupom smart kontraktov? Predstavte si skupinu osôb, ktoré chcú nastaviť niektoré pravidlá a podmienky rozdeľovania hodnôt, a zabezpečiť ich dodržiavanie pomocou istého mechanizmu. Tieto osoby sa spolu zídu, vypracujú dokument, na ktorom zapíšu svoje identifikačné údaje, podmienky, zapojené hodnoty, uvedú dátum a podpíšu sa. Tento kontrakt tiež overí dôveryhodná strana, napríklad notár. Potom sa tieto osoby rozídu so svojou papierovou kópiou kontraktu a začnú vykonávať nejaké činnosti, ktoré nemusia súvisieť so samotným kontraktom, teda robia jedno, zatiaľ čo na papieri je potvrdené, že majú robiť niečo úplne iné. A ako vyviesť týchto ľudí zo situácie? V podstate musí niekto z účastníkov skupiny vziať tento papier, priniesť nejaké dôkazy, ísť na súd a usilovať sa o súlad medzi kontraktom a skutočnými činmi. Dosiahnuť spravodlivé vykonanie tohto kontraktu býva často náročné, čo môže mať nepríjemné následky.

Čo môžeme povedať o smart kontraktoch? Spájajú v sebe možnosti písania podmienok kontraktu a mechanizmus ich striktnej realizácie. Ak boli podmienky stanovené a bola podpísaná príslušná transakcia alebo dopyt, po prijatí tohto dopytu alebo transakcie už nie je možné meniť podmienky ani ovplyvniť ich vykonanie.

Existuje jeden validátor nebo celá síť a také databáze, která uchovává všechny smart kontrakty, které byly uplatněny v přísně chronologickém pořadí. Je také důležité, aby tato databáze obsahovala všechny podmínky-trigger pro provedení smart kontraktu. Kromě toho by měla zohledňovat tu hodnotu, jejíž rozdělení je popsáno ve smlouvě. Pokud se jedná o nějakou digitální měnu, musí tato databáze tuto měnu zahrnovat.

Jinými slovy, validátory smart kontraktů musí mít přístup ke všem datům, se kterými smart kontrakt pracuje. Například by měla být použita jedna databáze pro současné sledování digitálních měn, zůstatků uživatelů, transakcí uživatelů a časových razítek. Pak může být v smart kontraktu podmínkou zůstatek uživatele v určité měně, nastoupení určitého času nebo fakt provedení nějaké transakce, ale nic víc.

Definice smart kontraktu

Samotnou terminologii vymyslel badatel Nick Szabo a poprvé ji použil v roce 1994; písemně byla zdokumentována v roce 1997 v článku, který popisuje samotnou myšlenku smart kontraktů.

Smart kontrakty předpokládají automatizaci rozdělování hodnoty, která může záviset pouze na těch podmínkách, které jsou předem nastaveny. V nejjednodušším případě to vypadá jako smlouva se striktně stanovenými podmínkami, kterou podepsaly určité strany.

Smart kontrakty mají za cíl minimalizovat důvěru třetím stranám. Někdy je zcela vyloučeno centrum rozhodování, od nějž vše závisí. Kromě toho je pro takové smlouvy snazší provádět audit. To je důsledkem některých rysů navrhování takového systému, ale nejčastěji máme na mysli pod smart kontraktem decentralizované prostředí a přítomnost funkcí, které umožňují každému, kdo má zájem, provést analýzu databáze a provést úplný audit plnění smluv. Tímto způsobem je zaručena ochrana před změnami dat zpětně, které by vedly k změně v plnění samotné smlouvy. Digitalizace většiny procesů při vytváření a spuštění smart kontraktu často zjednodušuje technologii a snižuje náklady na jejich realizaci.

Jednoduchý príklad — Escrow služba

Pozrime sa na veľmi jednoduchý príklad. Pomôže nám priblížiť sa k pochopeniu funkčných možností smart kontraktov a lepšie sa orientovať, v akých prípadoch ich treba používať.

Môže sa realizovať aj s využitím Bitcoinu, hoci v súčasnosti nemožno Bitcoin ešte považovať za plnohodnotnú platformu pre smart kontrakty. Takže máme nejakého kupujúceho a internetový obchod. Kupujúci chce kúpiť monitor v tomto obchode. V najjednoduchšom prípade kupujúci vykoná a pošle platbu, a internetový obchod ju prijme, potvrdí, po čom odošle tovar. V tejto situácii však existuje potreba veľkého dôveryhodnosti — kupujúci musí dôverovať internetovému obchodu na celú hodnotu monitora. Keďže internetový obchod môže mať nízku reputáciu v očiach kupujúceho, existuje riziko, že z nejakého dôvodu po prijatí platby obchod odmietne službu a nepošle tovar kupujúcemu. Preto sa kupujúci pýta (rovnako aj internetový obchod sa týmto otáznikom zaoberá), čo sa dá v tomto prípade aplikovať na minimalizovanie takýchto rizík a urobiť podobné transakcie spoľahlivejšími.

V prípade Bitcoinu možno umožniť kupujúcemu a predajcovi nezávisle si zvoliť mediátora. Existuje mnoho ľudí, ktorí sa zaoberajú riešením sporov. A naši účastníci môžu vybrať z celkového zoznamu mediátorov toho, ktorému budú obaja dôverovať. Spoločne vytvoria multisig adresu 2 z 3, kde sú tri kľúče a potrebné sú dve podpisy akýmikoľvek dvoma kľúčmi, aby minuli mince z tejto adresy. Jeden kľúč bude patriť kupujúcemu, druhý — internetovému obchodu, a tretí — mediátorovi. A na takúto multisig adresu kupujúci zašle sumu potrebnú na zaplatenie monitora. Teraz, keď predajca vidí, že peniaze sú na nejaký čas zablokované na multisig adrese, ktorá závisí od neho, môže s istotou poslať monitor poštou.

Potom kupujúci prijme balík, skontroluje tovar a rozhodne sa o konečnej kúpe. Môže byť úplne spokojný s poskytovanou službou a podpísať transakciu svojím kľúčom, kde prenáša mince z multisignature adresy predajcovi, alebo môže byť niečím nespokojný. V druhom prípade sa spojí s mediátorom, aby vytvoril alternatívnu transakciu, ktorá inak rozdelí tieto mince.

Predpokladajme, že monitor dorazil trochu poškriabaný a v balení nebol kábel na pripojenie k počítaču, hoci na stránke internetového obchodu bolo uvedené, že kábel má byť súčasťou balenia. Potom kupujúci zhromažďuje dôkazy potrebné na to, aby dokázal mediátorovi, že ho v tejto situácii podviedli: robí snímky obrazovky stránky, fotografiu účtenky z pošty, fotografiu poškriabaní na monitore a ukazuje, že pečať bola pretrhnutá a kábel bol vybratý. Internetový obchod na druhej strane zhromažďuje svoje dôkazy a predáva ich mediátorovi.

Mediátor má záujem uspokojiť súčasne aj rozhorčenie kupujúceho, aj záujmy internetového obchodu (ďalej bude jasné prečo). Vytvára takú transakciu, v ktorej budú mince z multisignature adresy vynaložené v určitej proporcii medzi kupujúcim, internetovým obchodom a mediátorom, pretože si vezme časť ako odmenu za svoju prácu. Predpokladajme, že 90 % celej sumy pôjde predajcovi, 5 % mediátorovi a 5 % ako kompenzácia kupujúcemu. Túto transakciu mediátor podpíše svojím kľúčom, ale ešte nemôže byť použitá, pretože k tomu potrebujeme dva podpisy, a existuje len jeden. Takúto transakciu posiela ako kupujúcemu, tak predajcovi. Ak aspoň jeden z nich bude spokojný s takýmto variantom redistribúcie mincí, transakcia bude dopodpisaná a rozšírená do siete. Na jej validáciu stačí, aby sa jeden z účastníkov obchodu dohodol na variante mediátora.

Je dôležité si najprv vybrať mediátora, ktorému dôverujú obaja účastníci. V takom prípade bude pôsobiť nezávisle od záujmov jednej či druhej strany a objektívne zhodnotí situáciu. Ak mediátor nenabídne spôsob rozdelenia mincí, ktorý by uspokojil aspoň jedného účastníka, môžete sa spolu dohodnúť, a kupujúci aj internetový obchod môžu presunúť mince na nový multisignature adres, pričom poskytnú svoje dve podpisy. Nový multisignature adres bude vytvorený už s iným mediátorom, ktorý môže byť kompetentnejší v tejto záležitosti a ponúkne lepšiu alternatívu.

Príklad s internátom a chladničkou

Poďme si ukázať zložitejší príklad, ktorý jasnejšie zobrazuje možnosti smart kontraktu.

Povedzme, že sú traja chlapi, ktorí sa nedávno nasťahovali do jednej izby v internáte. Spoločne majú záujem kúpiť do svojej izby chladničku, ktorú budú zdieľať. Jeden z nich sa prihlásil, že zozbiera potrebnú sumu na kúpu chladničky a bude viesť rokovania s predajcom. Avšak sa len nedávno spoznali a medzi nimi nie je dostatočná dôvera. Je očividné, že dvaja z nich riskujú, keď dávajú peniaze tretieho. Okrem toho sa musia dohodnúť na výbere predajcu.

Môžu využiť escrow službu, teda si vybrať mediátora, ktorý skontroluje vykonanie obchodu a vyrieši sporné otázky, ak nejaké vzniknú. Potom sa dohodnú, zostavia smart kontrakt a zapíšu doň určité podmienky.

Prvým predpokladom je, že do určeného času, povedzme počas jedného týždňa, musia na príslušný účet smart kontraktu prísť tri platby z určitých adries v určitej výške. Ak sa tak nestane, smart kontrakt prestáva svoju činnosť a vracia mince všetkým účastníkom. Ak je však podmienka splnená, potom sa nastavujú hodnoty identifikátorov predajcu a sprostredkovateľa, a tiež sa kontroluje, či všetci účastníci súhlasia s výberom predajcu a sprostredkovateľa. Keď budú všetky podmienky splnené, následne sa prostriedky prevedú na určené adresy. Takýto prístup môže chrániť účastníkov pred podvodmi z ktorejkoľvek strany a úplne vylučuje potrebu dôvery.

Na tomto príklade vidíme samotný princíp, že takáto možnosť krok po kroku nastavovať parametre pre vykonanie každej podmienky umožňuje vytvárať systémy akejkoľvek zložitosti a hĺbky vnorených úrovní. Navyše, najprv v smart kontrakte môžete definovať prvú podmienku a až po jej splnení nastavovať parametre pre nasledujúcu podmienku. Inými slovami, formálne je podmienka stanovená, ale parametre pre ňu môžu byť nastavené už počas jej fungovania.

Klasifikácia smart kontraktov

Pre klasifikáciu je možné určiť rôzne skupiny kritérií. V súčasnosti sú však relevantné štyri z nich.

Smart kontrakty môžeme rozlišovať podľa prostredia vykonávania, ktoré môže byť buď centralizované, alebo decentralizované. V prípade decentralizácie máme omnoho väčšiu nezávislosť a odolnosť voči zlyhaniu pri vykonávaní smart kontraktov.

Tiež ich môžeme rozlíšiť podľa procesu stanovenia a vykonávania podmienok: môžu byť voľne programovateľné, obmedzené alebo prednastavené, t. j. prísne typizované. Keď na platforme smart kontraktov existujú iba 4 konkrétne smart kontrakty, parametre k nim možno nastavovať voľne. Zodpovedajúce tomu je ich nastavenie oveľa jednoduchšie: vyberieme zmluvu zo zoznamu a odovzdáme parametre.

Existujú automatizované smart kontrakty, ktoré sa samostatne realizujú pri splnení určitých podmienok, a sú aj také kontrakty, pri ktorých sú podmienky stanovené, ale platforma neoveruje automaticky ich splnenie; k tomu ich treba osobitne iniciovať.

Okrem toho sa smart kontrakty líšia úrovňou súkromia. Môžu byť buď úplne otvorené, čiastočne otvorené alebo úplne dôverné. Posledné znamená, že externí pozorovatelia nevidia podmienky smart kontraktov. Téma súkromia je však veľmi rozsiahla a je najlepšie ju zvážiť oddelene od aktuálneho článku.

Nižšie sa podrobnejšie zameriame na prvé tri kritériá, aby sme objasnili aktuálnu tému.

Smart kontrakty podľa prostredia vykonávania

Podľa prostredia vykonávania rozlišujeme centralizované a decentralizované platformy smart kontraktov. V prípade centralizovaných digitálnych kontraktov sa používa jedna služba, kde existuje len jeden validátor a môže byť k dispozícii služba zálohovania a obnovy, ktorá sa taktiež centralizovane spravuje. Existuje jedna databáza, ktorá uchováva všetky potrebné informácie na stanovenie podmienok smart kontraktu a distribúciu hodnoty, ktorá sa zaznamenáva v tejto databáze služby. Tento centralizovaný servis má klienta, ktorý určuje podmienky pomocou určitých požiadaviek a využíva také kontrakty. Prezentácia ako centralizovaná platforma môže mať menej spoľahlivé autentifikačné mechanizmy než kryptomeny.

Príkladom môžu byť poskytovatelia mobilných služieb (rôzne mobilné operátory). Predpokladajme, že určitý operátor vedie na svojich serveroch centralizovaným spôsobom evidenciu dátového prenosu, ktorý môže byť poskytovaný v rôznych formátoch, ako sú hlasové hovory, SMS správy, dáta mobilného internetu a podľa rôznych štandardov, a tiež vedie evidenciu prostriedkov na zostatkoch užívateľov. Podľa toho môže poskytovateľ mobilných služieb vytvárať zmluvy na evidenciu poskytovaných služieb a ich platby s rôznymi podmienkami. V takom prípade sú podmienky ako „pošli SMS s takýmto kódom na takúto číslo, a dostaneš takúto distribúciu dát“ ľahko určené.

Môžeme uviesť ešte jeden príklad: tradičné banky s rozšírenou funkčnosťou internetového bankovníctva a veľmi jednoduché zmluvy, ako sú pravidelné platby, automatická konverzia prijatých platieb, automatické pripisovanie úroku na určený účet a pod.

Ak hovoríme o smart zmluvách v decentralizovanom vykonávacom prostredí, potom máme skupinu validátorov. V ideálnom prípade sa validátorom môže stať vlastne ktokoľvek. Vďaka protokolu synchronizácie databázy a dosahovaniu konsenzu máme určitú spoločnú databázu, ktorá bude teraz uchovávať všetky transakcie so striktne opísanými zmluvami, a nie nejaké podmienené požiadavky, formáty ktorých sa často menia a neexistuje na ne otvorená špecifikácia. Tu transakcie budú obsahovať pokyny na vykonanie zmluvy podľa prísnej špecifikácie. Táto špecifikácia je otvorená a, a teda, samotní používatelia platformy môžu vykonávať audit a validovať smart zmluvy. Vidíme tu, že decentralizované platformy prevyšujú centralizované z hľadiska nezávislosti a odolnosti voči poruchám, ale ich navrhovanie a údržba sú omnoho zložitejšie.

Smart zmluvy podľa spôsobu zadávania a vykonávania podmienok

Teraz sa podrobnejšie zaoberáme tým, ako sa smart zmluvy môžu líšiť podľa spôsobu zadávania a vykonávania podmienok. Tu sa zameriavame na smart zmluvy, ktoré sú programovateľné ľubovoľne a sú úplné podľa Turinga. Úplná podľa Turinga smart zmluva umožňuje zadávať takmer akékoľvek algoritmy ako podmienky vykonávania zmluvy: písať cykly, nejaké funkcie výpočtu pravdepodobností a podobne — až po vlastné algoritmy elektronického podpisu. V tomto prípade sa hovorí o naozaj ľubovoľnom písaní logiky.

Existujú aj ľubovoľné smart zmluvy, ale nie úplné podľa Turinga. Sem môžeme zaradiť Bitcoin a Litecoin so svojím skriptom. Hovorí sa o tom, že je možné v ľubovoľnom poradí používať iba určité operácie, ale už nie je možné napísať cykly a vlastné algoritmy.

Okrem toho existujú aj platformy smart kontraktov, ktoré implementujú vopred predpísané smart kontrakty. K nim patrí Bitshares a Steemit. Bitshares má celý rad smart kontraktov na obchodovanie, správu účtov, riadenie samotnej platformy a jej parametrov. Steemit je podobná platforma, ale zameriava sa už nie na emitovanie tokenov a obchodovanie, ako Bitshares, ale na písanie blogov, t. j. uchováva a spracováva obsah decentralizovaným spôsobom.

Medzi úplné Turingove kontrakty môžeme zaradiť platformu Ethereum a RootStock, ktorá je ešte vo vývoji. Preto sa ďalej trochu podrobnejšie zameriame na platformu smart kontraktov Ethereum.

Smart kontrakty podľa spôsobu inicializácie

Podľa spôsobu inicializácie môžeme smart kontrakty rozdeliť minimálne na dve skupiny: automatizované a ručné (neautomatizované). Pre automatizované je charakteristické, že za všetkých známych parametrov a nastaní podmienok sa smart kontrakt plne vykonáva automaticky, t. j. nevyžaduje odosielanie ďalších transakcií a vynakladanie dodatočných poplatkov pri každom ďalšom vykonaní. Samotná platforma má všetky dáta na to, aby vypočítala, akým spôsobom sa smart kontrakt dokončí. Logika nie je náhodná, ale vopred určená a všetko je predvídateľné. T. j. vopred je možné zhodnotiť zložitosti vykonania smart kontraktu, použiť nejaký konštantný poplatok pre neho a všetky procesy jeho vykonania prebiehajú efektívnejším spôsobom.

Pre smart kontrakty, ktoré sú programované ľubovoľne, vykonanie nie je automatizované. Na inicializáciu takého smart kontraktu je vlastne na každom kroku potrebné vytvoriť novú transakciu, ktorá vyvolá nasledujúcu etapu vykonania alebo ďalšiu metódu smart kontraktu, zaplatiť príslušný poplatok a čakať na potvrdenie transakcie. Vykonanie môže skončiť úspešne alebo nie, pretože kód smart kontraktu je ľubovôľny a môžu sa objaviť rôzne nepredvídateľné momenty, ako nekonečný cyklus, nedostatok určitých parametrov a argumentov, nevybavené výnimky a podobne.

Účty na Ethereum

Typy účtov Ethereum

Pozrime sa na to, aké účty môžu existovať na platforme Ethereum. Existujú len dva typy účtov a žiadne iné možnosti. Prvý typ sa nazýva účet používateľa, druhý – účet kontraktu. Pochopíme, čím sa odlišujú.

Účet používateľa spravuje iba vlastný kľúč digitálneho podpisu. Majiteľ účtu si generuje svoj pár kľúčov pre digitálny podpis podľa algoritmu ECDSA (Elliptic Curve Digital Signature Algorithm). Stav tohto účtu môžu meniť iba transakcie, ktoré sú potvrdené týmto kľúčom.

Pre účet smart kontraktu je predpísaná samostatná logika. Môže sa spravovať len pomocou vopred definovaného programového kódu, ktorý úplne určuje správanie smart kontraktu: ako bude nakladať so svojimi mincami za určitých okolností, z iniciatívy ktorého používateľa a za akých dodatočných podmienok budú tieto mince distribuované. Ak niektoré aspekty neboli predpokladané vývojármi v programovom kóde, môžu nastať problémy. Napríklad, smart kontrakt môže získať určité stavy, pri ktorých neprijíma iniciovanie ďalšieho vykonávania od žiadneho používateľa. V takom prípade môžu byť mince fakticky zmrazené, pretože smart kontrakt nepredpokladá výstup z tohto stavu.

Ako sa vytvárajú účty v Ethereum

V prípade účtu používateľa si majiteľ samostatne generuje pár kľúčov podľa ECDSA. Dôležité je poznamenať, že Ethereum používa na digitálny podpis presne ten istý algoritmus a presne tú istú eliptickú krivku ako Bitcoin, ale adresa sa vypočítava trochu iným spôsobom. Tu sa už nepoužíva výsledok dvojitého hashovania, ako v Bitcoine, ale je tu predpísané jednorazové hashovanie funkciou Keccak na dĺžke 256 bitov. Od získanej hodnoty sa odrezávajú najnižšie bity, konkrétne 160 najnižších bitov výstupnej hodnoty hash-funkcie. Nakoniec dostaneme adresu v Ethereum. Fakticky zaberá 20 bajtov.

Upozorníme, že identifikátor účtu v Ethereum je kódovaný v hex bez použitia kontrolného súčtu, na rozdiel od Bitcoinu a mnohých iných systémov, kde je adresa kódovaná v sústave s základom 58 s pridaním kontrolného súčtu. To znamená, že je potrebné pracovať s identifikátormi účtov v Ethereum opatrne: aj jedna chyba v identifikátore nevyhnutne vedie k strate mincí.

Existuje dôležitá vlastnosť, a to, že účet používateľa na úrovni spoločnej databázy sa vytvára v okamihu, keď prijme prvý prichádzajúci platobný príkaz.

Pokiaľ ide o vytváranie účtu smart kontraktu, uplatňuje sa úplne iný prístup. Najprv niekto z používateľov napíše zdrojový kód smart kontraktu, po čom sa kód spracováva cez špeciálny kompilátor určený pre platformu Ethereum, čím sa získava bajtový kód pre vlastnú virtuálnu stroj Ethereum. Získaný bajtový kód je umiestnený do špeciálneho poľa tranzakcie. Tá je podpísaná v mene iniciátorovho účtu. Ďalej sa táto tranzakcia šíri po sieti a umiestňuje kód smart kontraktu. Poplatok za uskutočnenie tranzakcie a následne za vykonanie kontraktu sa odpočíta z bilancie iniciátorovho účtu.

Každý smart kontrakt nevyhnutne obsahuje svoj konštruktor (tohto kontraktu). Môže byť prázdny, alebo môže obsahovať údaje. Po vykonaní konštruktora sa vytvorí identifikátor účtu smart kontraktu, pomocou ktorého je možné posielať mince, vyvolávať určité metódy smart kontraktu atď.

Štruktúra tranzakcie Ethereum

Aby bolo jasnejšie, prejdeme si štruktúru tranzakcie Ethereum a príklad kódu smart kontraktu.

Tranzakcia Ethereum sa skladá z viacerých polí. Prvé z nich, nonce, je určitý poriadkový číslo tranzakcie vo vzťahu k samotnému účtu, ktorý ju šíri a je jej autorom. Je to potrebné na to, aby sa odlíšili duplikáty tranzakcií, teda aby sa vylúčil prípad, keď je tá istá tranzakcia prijímaná dvakrát. Vďaka aplikácii identifikátora každá tranzakcia má jedinečnú hash-hodnotu.

Ďalej nasleduje také pole, ako gas price. Tu sa uvádza cena, za ktorú sa základná mena Ethereum konvertuje na gas, ktorým sa platí za vykonanie smart kontraktu a pridelenie zdrojov virtuálnemu stroju. Čo to znamená?

V Bitcoine sa poplatky platia priamo základnou menou — samotným bitcoinom. To je možné vďaka jednoduchému mechanizmu ich výpočtu: platíme presne za objem údajov, ktorý obsahuje transakcia. V Ethereum je situácia zložitejšia, pretože z objemu údajov transakcie sa ťažko vychádza. Transakcia môže obsahovať aj programový kód, ktorý bude spustený na virtuálnom stroji, a každá operácia na virtuálnom stroji môže mať rôznu zložitosti. Existujú aj operácie, ktoré pridelujú pamäť pre premenné. Tieto operácie budú mať svoju zložitosti, od ktorej závisí platba za každú operáciu.

Cena každej operácie v ekvivalente gas bude konštantná. Zavádza sa práve pre to, aby sa určila konštantná cena každej operácie. V závislosti od zaťaženia siete sa bude meniť gas price, t.j. koeficient, podľa ktorého sa základná mena konvertuje na túto pomocnú jednotku na zaplatenie poplatku.

Existuje ešte jedna zvláštnosť transakcie v Ethereum: bajtový kód, ktorý obsahuje na vykonanie vo virtuálnom stroji, bude vykonávaný, pokiaľ sa neskončí s nejakým výsledkom (úspech-neúspech) alebo kým sa nevyčerpá určité množstvo mincí pridelených na zaplatenie poplatku. Aby sa predišlo situácii, kedy zo účtu odosielateľa pri nejakej chybe minie všetky mince na poplatok (napr. ak sa vyskytne nekonečný cyklus vo virtuálnom stroji), existuje nasledujúce pole — start gas (často ho nazývajú gas limit) — určuje maximálny objem mincí, ktoré je odosielateľ ochotný minúť na vykonanie konkrétnej transakcie.

Nasledujúce pole sa nazýva destination address. Sem sa zapisuje adresa príjemcu mincí alebo adresa konkrétneho smart kontraktu, ktorého metódy budú vyvolané. Potom nasleduje pole value, do ktorého sa zapisuje suma mincí, ktoré sa odosielajú na destination address.

Ďalej sa nachádza zaujímavé pole s názvom data, kam patrí celá štruktúra. Nie je to samostatné pole, ale celá štruktúra, v ktorej je definovaný kód pre virtuálny stroj. Sem môžeme umiestniť akékoľvek údaje — na to existujú špeciálne pravidlá.

A posledné pole sa nazýva signature. Obsahuje zároveň elektronický podpis autora tejto transakcie a verejný kľúč, ktorým bude overený tento podpis. Z verejného kľúča môžeme získať identifikátor účtu odosielateľa tejto transakcie, teda unikátne identifikovať účet odosielateľa v samotnom systéme. Z hľadiska štruktúry transakcie sme teda objasnili to hlavné.

Príklad kódu smart kontraktu na Solidity

Poďme sa teraz podrobnejšie pozrieť na najjednoduchší smart kontrakt na príklade.

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);
    }
}

Vyššie uvedený zjednodušený zdrojový kód môže uchovávať mince používateľov a vracať ich na požiadanie.

Takže existuje smart kontrakt Bank, ktorý plní nasledujúce funkcie: zhromažďuje na svojom zostatku mince, teda pri potvrdení transakcie a umiestnení takého smart kontraktu sa vytvára nový účet, ktorý môže obsahovať na svojom zostatku mince; zapamätáva si používateľov a rozdeľovanie mincí medzi nimi; má niekoľko metód na správu zostatkov, teda je možnosť doplnenia, výberu a overenia zostatku používateľa.

Prejdime si každým riadkom zdrojového kódu. V tomto kontrakte sú konštantné polia. Jedno z nich, s typom address, sa nazýva owner. Tento kontrakt si pamätá adresu používateľa, ktorý vytvoril tento smart kontrakt. Ďalej, existuje dynamická štruktúra, ktorá uchováva zodpovednosti medzi adresami používateľov a zostatkami.

Potom nasleduje metóda Bank — nazýva sa rovnako ako kontrakt. Tým pádom je to jeho konštruktor. Tu sa priraďuje premennej owner adresa toho, kto umiestnil tento smart kontrakt do siete. To je jediné, čo sa v tomto konštruktore deje. Teda msg v tomto prípade — to sú presne tie údaje, ktoré boli odoslané virtuálnemu stroju spolu s transakciou obsahujúcou celý kód tohto kontraktu. Teda msg.sender — to je autor tejto transakcie, ktorá umiestňuje tento kód. Ten bude vlastníkom smart kontraktu.

Metóda deposit umožňuje preniesť transakciou určité množstvo mincí na účet kontraktu. V tomto prípade smart kontrakt, prijímajúc tieto mince, si ich ponecháva vo svojom zostatku, ale do štruktúry balances zapisuje, kto presne bol odosielateľom týchto mincí, aby vedel, komu patria.

Ďalšia metóda sa nazýva withdraw a prijíma jeden parameter — sumu mincí, ktorú chce niekto vybrať z tohto banku. Tu sa kontroluje, či je na zostatku používateľa, ktorý volá túto metódu, dostatok mincí, aby ich mohol odoslať. Ak sú dostatočné, smart kontrakt vráti vyžadované množstvo mincí volajúcemu.

Ďalej ide metóda na kontrolu aktuálneho zostatku používateľa. Ten, kto volá túto metódu, sa použije na získanie tohto zostatku v smart kontrakte. Stojí za zmienku, že modifikátor tejto metódy je — view. To znamená, že samotná metóda nijako nemeni variabilné hodnoty svojej triedy a v skutočnosti ide len o metódu čítania. Pre volanie tejto metódy sa nevytvára samostatná transakcia, poplatok sa neplatí a všetky výpočty sa vykonávajú lokálne, po čom používateľ dostane výsledok.

Metóda kill slúži na zničenie stavu smart kontraktu. A tu je stanovená dodatočná kontrola, či je volajúci tejto metódy vlastníkom tohto kontraktu. Ak je, kontrakt sa samo-zničí a funkcia zniženia prijíma jeden parameter — identifikátor účtu, na ktorý kontrakt pošle všetky mince, ktoré zostali na jeho zostatku. V tomto prípade zostávajúce mince automaticky odídu na adresu vlastníka kontraktu.

Ako funguje plný uzol siete Ethereum?

Pozrime sa schematicky, ako prebieha vykonávanie takých smart kontraktov na platforme Ethereum a ako funguje plný uzol siete.

Plný uzol siete Ethereum musí mať aspoň štyri moduly.
Prvým, ako aj pre každý decentralizovaný protokol, je P2P networking module — modul sieťového spojenia a práce s inými uzlami, kde prebieha výmena blokov, transakcií a informácií o iných uzloch. Toto je tradičná súčasť pre všetky decentralizované kryptomeny.

Ďalej máme modul na ukladanie údajov blockchainu, spracovanie, výber prioritnej vetvy, doplňovanie blokov, odpojenie blokov, kontrolu týchto blokov atď.

Tretí modul sa nazýva EVM (Ethereum virtulná mašina) — to je virtuálna mašina, ktorá prijíma bajtový kód z Ethereum transakcie. Tento modul akceptuje aktuálny stav určitého účtu a vykonáva zmeny jeho stavu na základe prijatého bajtového kódu. Verzia virtuálnej mašiny na každom uzle siete musí byť rovnaká. Vypočítavania prebiehajú na každom uzle Ethereum presne rovnaké, no prebiehajú asynchrónne: niekto skôr overí a akceptuje túto transakciu, teda vykonáva celý kód, ktorý obsahuje, a niekto neskôr. V súlade s tým, keď sa vytvorí transakcia, rozšíri sa do siete, uzly ju prijímajú a v momente verifikácie presne tak, ako sa v Bitcoine vykonáva Bitcoin Script, tu sa vykonáva bajtový kód virtuálnej mašiny.

Transakcia sa považuje za overenú, ak bol celý kód, ktorý obsahuje, vykonaný, bolo vygenerované nové stanje určitého účtu a zachované až do momentu, kým sa nezistí, či bola táto transakcia aplikovaná alebo nie. Ak bola transakcia aplikovaná, potom sa to stanje považuje nielen za vykonané, ale už aj aktuálne. Existuje databáza, ktorá uchováva stav každého účtu pre každý uzol siete. Vďaka tomu, že sa všetky výpočty vykonávajú rovnakým spôsobom a stav blockchainu je rovnaký, bude aj databáza, ktorá obsahuje stavy všetkých účtov, rovnaká pre každý uzol.

Mýty a obmedzenia smart kontraktov

Pokiaľ ide o obmedzenia, ktoré existujú pre podobné platformy smart kontraktov ako Ethereum, môžeme uviesť nasledujúce:

• vykonávanie kódu;
• alokácia pamäte;
• údaje blockchainu;
• odosielanie platieb;
• vytvorenie nového kontraktu;
• volanie iných kontraktov.

Poďme sa pozrieť na obmedzenia, ktoré sú uvalené na virtuálnu mašinu a rozptýlime niektoré mýty o smart kontraktoch. Na virtuálnej mašine, ktorá môže existovať nielen v Ethereum, ale aj na podobných platformách, je možné vykonávať skutočne ľubovoľné logické operácie, teda napísať kód, ktorý sa tam bude spúšťať, a navyše je možné prideliť pamäť. Avšak, za každý výkon a za každú dodatočne pridelenú jednotku pamäte sa platí zvlášť.

Ďalej môže virtuálna mašina čítať údaje z databázy blockchainu, aby tieto údaje použila ako spúšťač na vykonanie konkrétnej logiky smart kontraktov. Virtuálna mašina môže vytvárať a posielať transakcie, môže vytvárať nové kontrakty a vyvolávať metódy iných smart kontraktov, ktoré už sú publikované v sieti: existujú, sú dostupné a podobne.

Najrozšírenejší mýtus tvrdí, že smart kontrakty Ethereum môžu využívať informácie z akýchkoľvek internetových zdrojov vo svojich podmienkach. Pravda je taká, že virtuálna mašina nemôže poslať sieťový požiadavok na nejaký externý informačný zdroj na internete, teda nie je možné napísať taký smart kontrakt, ktorý by rozdeľoval hodnotu medzi používateľmi na základe toho, aké je počasie vonku, kto vyhral v nejakom šampionáte alebo na základe akéhokoľvek iného incidentu, ktorý sa stal vo vonkajšom svete, pretože informácie o týchto incidentoch jednoducho nie sú v databáze samotnej platformy. Inými slovami, v blockchaine sa o tom nič nenachádza. Ak sa to tam neobjaví, virtuálna mašina nemôže tieto údaje použiť ako spúšťače.

Nevýhody Ethereum

Poďme si ich vymenovať. Prvá nevýhoda spočíva v tom, že existujú určité ťažkosti pri návrhu, vývoji a testovaní smart kontraktov na platforme Ethereum (na písanie smart kontraktov sa v Ethereu používa jazyk Solidity). Skutočne prax ukazuje, že veľmi vysoké percento všetkých chýb patrí ľudskému faktoru. Toto je fakticky aktuálne aj pre už napísané smart kontrakty Ethereum, ktoré majú priemernú alebo vyššiu zložitost'. Ak je pri jednoduchých smart kontraktoch pravdepodobnosť chyby malá, v zložitých smart kontraktoch sa veľmi často vyskytujú chyby, ktoré vedú k krádeži prostriedkov, ich zmrazeniu, k zničeniu smart kontraktov nepredvídateľným spôsobom atď. Je známych už mnoho takýchto prípadov.

Druhá nevýhoda spočíva v tom, že samotná virtuálna mašina nie je dokonalá, pretože je tiež písaná ľuďmi. Môže vykonávať ľubovoľné príkazy a v tom sa skrýva zraniteľnosť: je možné určité spôsobom nakonfigurovať radu príkazov, ktoré povedú k nepredvídaným následkom. Je to veľmi zložitá sféra, ale už existuje niekoľko štúdií, ktoré ukazujú, že tieto zraniteľnosti existujú v aktuálnej verzii siete Ethereum a môžu viesť k zlyhaniu mnohých smart kontraktov.

Ďalšia veľká zložitost', ktorú možno považovať za nevýhodu. Spočíva v tom, že sa môže praktickým alebo technickým spôsobom dospieť k tomu, že ak zkompilujeme bajtový kód kontraktu, ktorý bude vykonávaný na virtuálnej mašine, môžeme určiť určitý špecifický poriadok operácií. Pri vykonávaní v súhrne tieto operácie veľmi zaťažia virtuálnu mašinu a spomalia ju neproporcionálne k tomu poplatku, ktorý bol zaplatený za vykonanie týchto operácií.

V minulosti už bol takýto vývoj Ethereum, keď mnohí chlapci, ktorí sa podrobne zaoberali prácou virtuálnych strojov, nachádzali takéto zraniteľnosti. Fakticky transakcie platili veľmi malú províziu, ale v podstate veľmi spomaľovali prácu celej siete. Tieto problémy sa riešia veľmi ťažko, pretože je potrebné ich, po prvé, determinovať, po druhé, skorigovať cenu za vykonávanie týchto operácií a, po tretie, uskutočniť hard fork, čo znamená aktualizáciu všetkých uzlov siete na novú verziu softvéru, a potom zároveň aktivovať tieto zmeny.

Pokiaľ ide o Ethereum, bolo vykonaných veľmi veľa výskumov, získaných veľmi veľa praktických skúseností: ako pozitívnych, tak negatívnych, ale predsa zostáva množstvo komplexností a zraniteľností, s ktorými je potrebné ešte nejako bojovať.

Takže tematická časť článku sa skončila, prejdime k otázkam, ktoré vznikajú dosť často.

Často kladené otázky

— Ak všetky strany účinného smart kontraktu chcú zmeniť podmienky, môžu zrušiť tento smart kontrakt pomocou multipodpisu a potom vytvoriť nový smart kontrakt s aktualizovanými podmienkami jeho plnenia?

Tu bude odpoveď dvojaká. Prečo? Pretože z jednej strany smart kontrakt je jednorazovo nastavený a už nepripúšťa žiadne zmeny, a z druhej strany môže mať vopred napísanú logiku, ktorá predpokladá úplnú alebo čiastočnú zmenu niektorých podmienok. To znamená, že ak chcete niečo zmeniť vo svojom smart kontrakte, musíte vopred napísať podmienky, na základe ktorých môžete aktualizovať tieto podmienky. Zodpovedne, len takýmto predvídavým spôsobom je možné organizovať aktualizáciu kontraktu. Ale aj tu sa dá naraziť na nepríjemnosti: dopustiť sa nejakej chyby a získať príslušnú zraniteľnosť. Preto je potrebné takéto veci veľmi podrobne a dôkladne projektovať a testovať.

— A čo ak mediátor vstúpi do dohody s jednou zo strán účastníkov: escrow alebo smart kontrakt? Je mediátor povinný v smart kontrakte?

Mediátor nie je povinný v smart kontrakte. Môže tam chýbať. Ak by sa mediátor v prípade escrow dohodol s jednou zo strán, potom áno, tento mechanizmus stratí svoju hodnotu. Preto mediátorov vyberajú tak, aby im dôverovali všetky zúčastnené strany. Zodpovedajúcim spôsobom jednoducho neprevediete mince na multisignature adresu mediátorovi, ktorému neveríte.

— Je možné jednou transakciou Ethereum previesť mnoho rôznych tokenov zo svojho adresy na rôzne cieľové adresy, napríklad burzové adresy, kde sa tieto tokeny obchodujú?

To je dobrá otázka a týka sa modelu transakcií Ethereum a jeho odlišnosti od modelu Bitcoin. A táto odlišnosť je zásadná. V modeli transakcie Ethereum jednoducho prevádzate mince, a to len z jednej adresy na druhú, bez vrátenia, jednoducho konkrétnu sumu, ktorú ste uviedli. Inými slovami, nie je to model nepoužitých výstupov (UTXO), ale skôr model účtov a zodpovedajúcich zostatkov. Teoreticky je možné jednou transakciou poslať niekoľko rôznych tokenov, ak napíšete šikovný smart kontrakt, no aj tak bude potrebné vykonať veľa transakcií, vytvoriť kontrakt, pridať mu tokeny a mince a potom zavolať príslušnú metódu. To si vyžaduje námahu a čas, a preto to v praxi takto nefunguje a všetky platby v Ethereum sa uskutočňujú osobitnými transakciami.

— Jeden z mýtov o platforme Ethereum spočíva v tom, že nie je možné opísať také podmienky, ktoré by záviseli od údajov z externého internetového zdroja, ako to vyriešiť?

Riešením je, že samotný smart kontrakt môže predpokladať jedného alebo niekoľkých takzvaných dôveryhodných orákulov, ktorí zhromažďujú údaje o stave vecí vo vonkajšom svete a prenášajú ich do smart kontraktov prostredníctvom špeciálnych metód. Samotný kontrakt považuje za pravdivé tie údaje, ktoré prijal od dôveryhodných strán. Pre väčšiu spoľahlivosť sa jednoducho vyberá väčšia skupina orákulov a minimalizuje sa riziko ich dohody. Samotný kontrakt nemusí brať do úvahy údaje od orákulov, ktoré sú v rozpore s väčšinou.

Táto téma sa podrobne rozoberá na jednej z prednášok online kurzu o Blockchaine — “Úvod do smart kontraktov”.

Zdroj: habr.com