Sissejuhatus nutilepingutesse

Selles artiklis arutame, mis on nutilepingud, millised need on, tutvume erinevate nutilepingute platvormidega, nende omadustega ning arutame, kuidas need toimivad ja milliseid eeliseid võivad endas peita. See materjal on väga kasulik lugejatele, kes ei ole nutilepingute teemaga piisavalt tuttavad, aga soovivad selle mõistmiseni jõuda.

Tavapärane leping vs. nutileping

Enne kui süveneme üksikasjadesse, tuletame meelde tavapärase lepingu, mis on kirjalik, ja nutilepingu, mis on esitatud digitaalses vormis, erinevusi.

Kuidas see toimis enne nutilepingute kasutuselevõttu? Kujutage ette rühma inimesi, kes soovivad kehtestada teatud reeglid ja tingimused väärtuste jaotamiseks ning kindlustada, et need reeglid ja tingimused ka tegelikult täidetakse. Nad kogunesid, koostasid dokumendi, kuhu kirja pandi nende isikuandmed, tingimused, kaasatud väärtused, kuupäev ja allkirjad. Seda lepingut kinnitas ka usaldusväärne osapool, näiteks notar. Seejärel lahkusid nad igaühega oma paberkandjal lepingust ja hakkasid tegema teatud toiminguid, mis võisid olla lepinguga mitteühtivad, st nad tegid ühte, samas kui paberil oli kinnitatud, et nad peaksid tegema midagi täiesti muud. Kuidas sellisest olukorrast välja tulla? Tegelikult pidi üks osaleja võtma selle paberi, koguma mingid tõendid, minema kohtusse ja nõudma vastavust lepingu ja tegelike toimingute vahel. Sageli on õiglase täitmise saavutamine keeruline, mis toob kaasa ebameeldivad tagajärjed.

Mida saab öelda nutilepingute kohta? Need ühendavad endas lepingutingimuste koostamise ja nende ranget täitmise mehhanismi. Kui tingimused on määratud ja vastav tehing või päring on allkirjastatud, siis ei saa pärast selle päringu või tehingu vastuvõtmist tingimusi enam muuta ega mõjutada nende täitmist.

Olgu üks valideerija või terve võrgustik, samuti andmebaas, mis salvestab kõik nutilepingud, mis on täitmiseks laekunud rangelt kronoloogilises järjekorras. Samuti on oluline, et see andmebaas sisaldaks kõiki tingimuslikke käivitajaid nutilepingute täitmiseks. Lisaks tuleb arvestada ka selle väärtusega, mille jaotust lepingus kirjeldatakse. Kui see puudutab mingit digitaalset valuutat, siis peab see andmebaas seda arvestama.

Teisisõnu peavad nutilepingute valideerijatel olema juurdepääs kõikidele andmetele, millega nutileping opereerib. Näiteks peaks olema üks andmebaas, mida kasutatakse samal ajal digitaalsete valuutade, kasutajate saldode, kasutajate tehingute ja ajatempli arvestuseks. Siis võib nutilepingus tingimuseks olla kasutaja saldo teatavas valuutas, mingi aja saabumine või mõne tehingu tegemise fakt, kuid mitte rohkem.

Nutilepingu määratlemine

Tegelikult, kogu terminoloogia loodi teadlase Nick Szabo poolt ja seda rakendati esmakordselt 1994. aastal, samas kui see dokumenteeriti 1997. aastal artiklis, mis kirjeldab nutilepingute ideed.

Nutilepingud tähendavad, et toimub mingi väärtuse jaotuse automatiseerimine, mis võib sõltuda ainult nendest tingimustest, mis on eelnevalt ette määratud. Kõige lihtsamal juhul näeb see välja nagu leping, kus on rangelt määratletud tingimused, mille on allkirjastanud teatud osalised.

Nutika lepingud on loodud vähendama usaldust kolmandate osapoolte vastu. Mõnikord välistatakse täielikult otsustusprotsess, mis kõik sõltub. Lisaks on selliste lepingute auditit lihtsam läbi viia. See tuleneb teatud süsteemide projekteerimise eripäradest, kuid enamasti mõistame nutika lepingu all detsentraliseeritud keskkonda ja funktsioone, mis võimaldavad igal soovijal andmebaasi analüüsida ja lepingute täitmise täielikku auditit teha. Nii tagatakse kaitse tagantjärgi andmete muutuste eest, mis muudaksid lepingu täitmist. Enamik protsesside digitaliseerimine nutika lepingu loomisel ja käivitamisel lihtsustab sageli tehnoloogiat ja nende elluviimise kulusid.

Lihtne näide — Escrow teenus

Vaatame väga lihtsat näidet. See aitab läheneda nutikate lepingute funktsionaalsete võimaluste mõistmisele ning paremini orienteeruda, millal neid kasutada tasub.

Seda võib ellu viia ka Bitcoiniga, kuigi praegu ei saa Bitcoini veel nimetada täisväärseks plokiahela platvormiks nutilepingute jaoks. Niisiis, meil on ostja ja veebipood. Ostja soovib osta selle poe kaudu monitori. Kõige lihtsamas olukorras esitab ostja makse ja veebipood aktsepteerib selle, kinnitab ning seejärel saadab kauba. Kuid selles olukorras on vajalik suur usaldus — ostja peab kogu monitori maksumuse osas usaldama veebipoodi. Kuna veebipood võib ostja silmis olla madala mainega, siis on oht, et mingil põhjusel, pärast makse vastuvõtmist, poe teenuseid ei osutata ja kaup ei saadeta ostjale. Seetõttu küsib ostja endalt (samuti küsib seda veebipood), mida selles olukorras rakendada, et minimeerida selliseid riske ja muuta sellised tehingud usaldusväärsemaks.

Bitcoini puhul on võimalik ostjal ja müüjal eraldi valida vahendaja. On palju inimesi, kes tegelevad vaidluste lahendamisega. Meie osalised saavad valida usaldusväärsete vahendajate üldisest nimekirjast. Koos loovad nad multisignature aadressi 2-3, kus on kolm võtit ja mõlema kahe võtmega on vaja kaht allkirja, et kulutada münte sellest aadressist. Üks võti kuulub ostjale, teine veebipoele ning kolmas vahendajale. Sellisele multisignature aadressile saadab ostja summa, mis on vajalik monitori eest tasumiseks. Nüüd, kui müüja näeb, et raha on mõneks ajaks multisignature aadressil blokeeritud, mis sõltub temast, võib ta julgelt saata monitori posti.

Seejärel vaatab ostja pakki, uurib toodet ja teeb lõpliku ostuotsuse. Ta võib olla täielikult rahul pakutava teenusega ja kinnitada tehingu oma võtmega, millega ta edastab müüjale münte multisignature aadressilt, või võib ta olla millegagi rahulolematu. Teisel juhul pöördub ta vahendaja poole, et koostada alternatiivne tehing, mis jagab neid münte teistmoodi.

Oletame, et monitor saabus veidi kriimustatud ja komplektis ei olnud arvutiga ühendamiseks vajalikku kaablit, kuigi veebipoe lehel oli kirjas, et kaabel peaks olema komplektis. Sel juhul kogub ostja tõendusmaterjali, et tõestada vahendajale, et teda on petetud: ta teeb ekraanipilte veebilehelt, teeb foto postituste tšekist, teeb foto monitori kriimudest ja näitab, et pitsat oli rikutud ning kaabel oli välja võetud. Seejärel kogub veebipood omakorda oma tõendid ja edastab need vahendajale.

Vahendaja soovib samal ajal rahuldada nii ostja rahulolematust kui ka internetipoe huve (hiljem selgub, miks). Ta koostab sellise tehingu, kus multiallkirjastatud aadressilt kulutatakse münte teatud proportsioonis ostja, internetipoe ja vahendaja vahel, kuna ta võtab osa oma töö tasuna. Oletame, et 90% kogu summast läheb müüjale, 5% vahendajale ja 5% kompensatsiooniks ostjale. Selle tehingu vahendaja allkirjastab oma võtmega, kuid sellega ei saa veel toimetada, kuna on vajalik kaks allkirja, aga hetkel on vaid üks. Sellise tehingu saadab ta nii ostjale kui müüjale. Kui vähemalt üks neist on rahul sellise müntide jaotamise variandi üle, siis tehing allkirjastatakse ja levitatakse võrku. Selle valideerimiseks piisab, kui üks tehingu osaline nõustub vahendaja pakkumisega.

Oluline on alguses valida mediátor, kellele mõlemad osalised usaldavad. Sellisel juhul tegutseb ta sõltumatult ühe või teise huvidest ja hindab olukorda objektiivselt. Kui mediátor ei paku sellist rahade jaotamise varianti, mis rahuldaks vähemalt ühte osalist, võivad ostja ja veebipood kokkuleppel saata rahad uuele multisignatuuri aadressile, lisades oma kaks allkirja. Uus multisignatuuri aadress koostatakse juba teise mediátoriga, kes võib-olla on selles küsimuses pädevam ja pakub paremat varianti.

Näide ühiselamu ja külmkapi kohta

Vaatame keerulisemat näiteks, mis näitab nutikust lepingu võimalusi selgemalt.

Oletame, et on kolm noormeest, kes on hiljuti asunud ühte ühiselamusse. Nad kõik soovivad osta oma tuppa külmkapi, mida nad saavad ühiselt kasutada. Üks neist on nõustunud koguma vajamineva summa külmiku ostmiseks ja pidama läbirääkimisi müüjaga. Kuid nad on üksteist alles hiljuti tundma õppinud ja usaldust nende vahel pole piisavalt. Ilmselgelt riskivad kaks neist, olles kolmanda raha usaldanud. Samuti peavad nad jõudma kokkuleppele müüja valimisel.

Nad võivad kasutada escrow-teenust, valides vahendaja, kes jälgib tehingu täitmist ja lahendab vaidlusi, kui need peaksid tekkima. Seejärel, kokkuleppides, koostavad nad nutikonto ja kirja pandud tingimused.

Esimene tingimus on see, et enne kindla aja saabumist, näiteks ühe nädala jooksul, peab vastavale nutilepingukontole saabuma kolm makset kindlatest aadressidest kindla summa eest. Kui seda ei juhtu, lõpetab nutileping oma täitmise ja tagastab kõik mündid osalistele. Kui tingimus täidetakse, siis määratakse müüja ja vahendaja identifikaatorid ning kontrollitakse tingimust, et kõik osalised on nõus müüja ja vahendaja valikuga. Kui kõik tingimused on täidetud, siis kantakse fondid edasi määratud aadressidele. Sarnane lähenemine võib kaitsta osalisi petmisest igalt poolt ning välistab üldiselt vajaduse usaldada.

Selle näite kaudu näeme põhimõtet, et võimalus samm-sammult määrata tingimusi iga tingimuse täitmiseks võimaldab luua süsteeme mis tahes keerukuse ja sügava sisemise tasemega. Lisaks saab nutilepingus esmalt määrata esimese tingimuse ja alles pärast selle täitmist määrata järgmise tingimuse parameetrid. Teisisõnu, tingimus on formaalselt määratletud, kuid selle parameetrid võivad olla määratud juba selle töö käigus.

Nutilepingute klassifitseerimine

Klassifitseerimiseks saab määrata erinevaid kriteeriumigruppide rühmi. Siiski on praegusel tehnoloogia arengutasemel reaalselt olulised neli neist.

Nutilepinguid saab eristada nende täitmis keskkonna järgi, mis võib olla kas tsentraliseeritud või detsentraliseeritud. Detsentraliseerimise korral omame nutilepingute täitmisel palju suuremat sõltumatust ja tõrketaluvust.

Neid saab eristada ka tingimuste määramise ja täitmise protsessi kaudu: need võivad olla vabalt programmeeritavad, piiratud või eeldefineeritud, st rangelt tüpiseeritud. Kui nutilepingute platvormil eksisteerib ainult 4 kindlat nutilepingut, saab nende parameetreid määrata vabalt. Seetõttu on nende määramine palju lihtsam: valime lepingud loetelust ja edastame parameetrid.

Algatamise viisi põhjal on olemas automatiseeritud nutilepingud, mis tähendab, et need täituvad iseenesest, kui määratud tingimused täituvad. Samuti on olemas lepingud, kus tingimused on määratud, kuid platvorm ei kontrolli nende täitmist automaatselt; neid tuleb eraldi algatada.

Lisaks erinevad nutilepingud privaatsuse taseme järgi. Need võivad olla kas täielikult avatud, osaliselt või täielikult konfidentsiaalsed. Viimane tähendab, et välised vaatlejad ei näe nutilepingute tingimusi. Siiski on privaatsuse teema äärmiselt lai ja seda oleks parem käsitleda eraldi käesolevast artiklist.

Allpool käsitleme kolme esimest kriteeriumi, et tuua rohkem selgust arutletavale teemale.

Nutilepingud täitmise keskkonna järgi

Täitmisse keskkonna järgi eristatakse nutilepingute keskseid ja detsentraliseeritud platvorme. Kesksete digitaalsete lepingute puhul kasutatakse ühte teenust, kus on ainult üks valideerija, ja võib olla varundus- ja taastusteenus, mis on samuti keskse halduse all. On olemas üks andmebaas, mis sisaldab kogu vajalikku teavet nutilepingu tingimuste seadmiseks ja selle andmebaasi teenuse kaudu arvestatava väärtuse jaotamiseks. Sellise keskses teenuses on klient, kes esitab teatud päringud, et määrata tingimused ja kasutada neid lepinguid. Kuna platvorm on keskne, võivad autentimise mehhanismid olla vähem usaldusväärsed kui krüptovaluutades.

Näiteks võib tuua mobiilside operaatorid. Oletame, et konkreetne operaator haldab oma serverites keskse süsteemi kaudu liiklusarvestust, mis võib toimuda erinevates vormingutes, nagu hääleseadmed, SMS-edastamine, mobiilse interneti liiklus ja erinevad standardid, samuti jälgib kasutajate kontode jääke. Vastavalt sellele saab mobiilside operaator koostada lepingud pakutavate teenuste ja nende tasumise kohta erinevate tingimustega. Sellisel juhul on lihtne määrata tingimusi, näiteks „saada SMS sellise koodiga sellele numbrile ja saad sellised liikluse jaotamise tingimused”.

Võib tuua veel ühe näite: traditsioonilised pangad, millel on laiaulatuslikud internetipanganduse võimalused, ja sellised lihtsad lepingud nagu regulaarnaatlused, saabumiste automaatne konverteerimine, automaatne protsent määratud kontole jne.

Kui rääkida nutilepingutest detsentraliseeritud täitmiskeskkonnas, siis meil on validaatorite rühm. Ideaalis võib validaatoriks olla tegelikult keegi. Andmebaasi sünkroniseerimise protokolli ja konsensuse saavutamise kaudu omame mingit ühist andmebaasi, mis hakkab nüüd talletama kõiki tehinguid rangelt määratletud lepingutega, mitte mingeid tingimusi, mille formaadid sageli muutuvad ja avatud spetsifikatsiooni ei ole. Siin sisaldavad tehingud juhiseid lepingute täitmiseks vastavalt rangale spetsifikatsioonile. See spetsifikatsioon on avatud ja seega saavad platvormi kasutajad teha auditi ja valideerida nutilepingud. Siin näeme, et detsentraliseeritud platvormid ületavad kesksetele platvormidele sõltumatuse ja töökindluse osas, kuid nende projekteerimine ja hooldus on seejuures palju keerulisem.

Nutilepingud tingimuste seadmiseks ja täitmiseks

Vaatame nüüd lähemalt, kuidas nutilepingud võivad erineda tingimuste määramise ja täitmise viisi poolest. Keskendume nutilepingutele, mida saab programmeerida meelevaldselt ja mis on Turingi täielikud. Turingi täielik nutileping võimaldab määrata praktiliselt igasuguseid algoritme lepingutingimustena: kirjutada tsükleid, mingeid tõenäosuse arvutamise funktsioone ja sarnast — kuni omaenda elektroonilise allkiri algoritmideni. Sellisel juhul räägime tõeliselt meelevaldse loogika kirjutamisest.

Erinevad ka meelevaldsed nutilepingud, kuid mitte Turingi täielikud. Siia alla kuuluvad Bitcoin ja Litecoin oma skriptiga. See tähendab, et saab meelevaldselt kasutada ainult teatud operatsioone, kuid tsükleid ja oma algoritme kirjutada ei saa.

Lisaks on olemas ka sellised nutilepingute platvormid, mis rakendavad eelnevalt seadistatud nutilepinguid. Nende hulka kuuluvad Bitshares ja Steemit. Bitshares'il on terve rida nutilepinguid kaubanduseks, konto haldamiseks, platvormi enda ja selle parameetrite haldamiseks. Steemit on sarnane platvorm, kuid see keskendub mitte tokenite väljastamisele ja kaubandusele, nagu Bitshares, vaid blogimisele, st see salvestab ja töötleb sisu detsentraliseeritud viisil.

Turingi täielikele lepingutele võib omistada platvormi Ethereum ja RootStock, mis on veel arendamise faasis. Seetõttu peatume järgmisena natuke põhjalikumalt nutilepingute platvormil Ethereum.

Nutilepingud algatamisviisi järgi

Selle järgi, kuidas nutilepingud algatatakse, saab neid jagada vähemalt kaheks rühmaks: automatiseeritud ja käsitsi (mitte automatiseeritud). Automatiseeritud lepingute puhul toimub kogu täitmine automaatselt, kui kõik teadaolevad parameetrid ja tingimused on täidetud, st ei nõua lisatehingute saatmist ega täiendavate tasude maksmist iga järgmise täitmise korral. Platvormil on kõik vajalikud andmed, et arvutada, kuidas nutileping lõpeb. Selle loogika ei ole juhuslik, vaid eelnevalt määratletud ning kõik see on etteaimatav. Seega on võimalik eelnevalt hinnata nutilepingute täitmise keerukust, kasutada selle jaoks mingit konstantsset tasu ning kõik protsessid tema täitmise käigus toimuvad tõhusamalt.

Ühelt poolt, et kasutada tarkvaraga programmeeritavat nutilepingut, pole täitmine automatiseeritud. Sellise nutilepingu käivitamiseks on iga sammu korral vajalik luua uus tehing, mis kutsub üles järgmise täitmise või nutilepingu järgmise meetodi, tasuda vastav tasu ja oodata tehingu kinnitamist. Täitmine võib lõppeda nii edukalt kui ka ebaõnnestunult, kuna nutilepingu kood on suvaline ja võivad tekkida ettenägematud olukorrad, nagu lõputu tsükkel, teatud parameetrite ja argumentide puudumine, töötlemata erandid jne.

Ethereum'i kontod

Ethereum'i konto tüübid

Vaatame, milliseid kontosid saab Ethereum'i platvormil luua. Siin on olemas ainult kaks tüüpi kontot, rohkem variante ei ole. Esimene tüüp on kasutajakonto ja teine – lepingu konto. Selgitame välja, millega nad erinevad.

Kasutaja kontot hallatakse ainult isikliku digitaalallkirja võtmega. Konto omanik genereerib oma digitaalallkirja võtmete paari ECDSA (Elliptic Curve Digital Signature Algorithm) algoritmi alusel. Selle konto olekut saavad muuta ainult selle võtmega allkirjastatud tehingud.

Nutilepingu konto jaoks on ette nähtud eraldi loogika. Seda saab hallata ainult eelnevalt määratud programmikoodi kaudu, mis määrab täielikult nutilepingu käitumise: kuidas see teatud tingimustes oma münte haldab, millise kasutaja algatusel ja milliste täiendavate tingimuste alusel need mündid jagatakse. Kui teatud aspektid ei ole arendajate poolt programmikoodis ette nähtud, võivad tekkida probleemid. Näiteks võib nutileping saavutada kindla oleku, kus see ei aktsepteeri edasiste toimingute algatamist üheltki kasutajalt. Sellisel juhul jäävad mündid tegelikult külmutatuks, kuna nutileping ei võimalda sellest olekust väljuda.

Kuidas luuakse kontosid Ethereumis

Kasutaja konto puhul genereerib omanik ise ECDSA võtmepaari. Oluline on märkida, et Ethereum kasutab elektroonilistes allkirjades täpselt sama algoritmi ja sama elliptilist kõverat nagu Bitcoin, kuid aadress arvutatakse veidi teistmoodi. Siin ei kasutata topelthashimist nagu Bitcoinis, vaid on ette nähtud ühekordne hashimine Keccak-funktsiooni abil, mille pikkus on 256 bitti. Saadud väärtusest lõigatakse ära madalamad bitid, täpsemalt 160 madalamat bitti hash-funktsiooni väljundist. Tulemusena saame Ethereumis aadressi, mis tegelikult võtab 20 bitti.

Märgem, et Ethereumis kodeeritakse konto ID hex-formaadis ilma kontrollsummata, erinevalt Bitcoinist ja paljusid teistest süsteemidest, kus aadress kodeeritakse 58-põhisesse arvestussüsteemi koos kontrollsummaga. See tähendab, et Ethereumis tuleb konto ID-dega olla ettevaatlik: isegi üks viga ID-s viib kindlasti müntide kadumiseni.

Oluline omadus on see, et kasutaja konto üldise andmebaasi tasandil luuakse siis, kui ta aktsepteerib esimest sissetulevat makset.

Nutilepingu konto loomise osas rakendatakse täiesti teistsugust lähenemist. Algselt kirjutab keegi kasutajatest nutilepingu lähtekoodi, seejärel läbib kood platvormi Ethereum spetsiaalset kompilaatorit, saades bytecode'i oma Ethereum'i virtuaalmasinale. Saadud bytecode lisatakse spetsiaalsesse tehingu väljale. See allkirjastatakse algataja konto nimel. Edasi levitatakse see tehing võrgus ja paigutatakse nutilepingu kood. Tehingutasu ning vastavalt ka lepingu täitmise tasu lahutatakse algataja konto saldost.

Iga nutileping sisaldab kindlasti oma konstruktorit (seda lepingut). See võib olla tühi või võib sisaldada sisu. Pärast konstruktorite täitmist luuakse nutilepingu konto identifikaator, mille abil saab saata münte, kutsuda esile kindlaid nutilepingu meetodeid jne.

Ethereum'i tehingustruktuur

Et oleks selgem, vaatame Ethereum'i tehingustruktuuri ja nutika lepingu koodinäidet.

Ethereum'i tehing koosneb mitmest väljast. Esimene neist, nonce, on tehingu järjestusnumber võrreldes konto endaga, mis selle levitab ja on selle autor. See on vajalik, et eristada tehingu koopiaid, et vältida olukorda, kus sama tehingut võetakse vastu kaks korda. Tänu identifikaatori kasutamisele on igal tehingul ainulaadne hash-väärtus.

Edasi järgneb selline väli nagu gas price. Siin näidatakse hinda, mille eest alusvaluuta Ethereum vahetatakse gas'i vastu, millega tasutakse nutika lepingu täitmise ja virtuaalmasina ressursi eraldamise eest. Mida see tähendab?

Bitcoini transaktsioonide tasud makstakse otse alusvaluutas — ise Bitcoini. See on võimalik tänu lihtsatele arvutamismehhanismidele: maksame täpselt andmemahtu, mis transaktsioonis sisaldub. Ethereumis on olukord keerulisem, kuna on väga keeruline arvestada andmemahtu transaktsiooni põhjal. Siin võib transaktsioon sisaldada ka programmeerimiskoodi, mis jooksutab virtuaalmasinas, ja iga virtuaalmasina operatsioon võib omada erinevat keerukust. Samuti on olemas operatsioonid, mis eraldavad mälu muutuja jaoks. Neil on oma keerukus, millest sõltub iga operatsiooni tasu.

Iga operatsiooni hind gas'i ekvivalentina jääb konstantseks. See on spetsiaalselt sisse toodud selleks, et määrata iga operatsiooni konstantne hind. Olenevalt võrgu koormusest gas price muutub, st koefitsient, mille alusel alusvaluuta konverteeritakse selleks abiväikeseks ühiseks tasu maksmiseks.

Ethereum'i tehingute veel üks omadus on see, et selle baidikood, mis on mõeldud täitmiseks virtuaalses masinas, täidetakse kuni selle lõpetamiseni mõne tulemusega (õnnestumine-e õnnestumine) või kuni lõppeb kindel hulk münti, mis on ette nähtud teenustasu katmiseks. Just nimelt sellepärast, et vältida olukorda, kus saatja kontolt kulutatakse kõik mündid teenustasu katteks (näiteks kui virtuaalses masinas käivitub lõputu tsükkel), on olemas järgmine väli — start gas (seda tuntakse sageli ka kui gas limit) — see määratleb maksimaalse müntide hulga, mida saatja on valmis kulutama konkreetse tehingu täitmiseks.

Järgmine väli on nimetatud destination address. Siia kantakse sisse saajate aadress või konkreetse nutilepinguga aadress, mille meetodeid kutsutakse. Pärast seda järgneb väli value, kuhu kantakse sisse mündihulk, mis saadetakse aadressile destination address.

Seejärel asub huvitav väli nimega data, kuhu mahub kogu struktuur. See ei ole eraldi väli, vaid terviklik struktuur, kus määratakse virtuaalmasina kood. Siia saab paigutada vabalt valitud andmeid — selleks on olemas eraldi reeglid.

Ja viimane väli nimetatakse signature. See sisaldab samaaegselt nii autori elektroonilist allkirja selle tehingu jaoks kui ka avalikku võtit, millega seda allkirja kontrollitakse. Avalikust võtme kaudu saab tuletada saatja konto identifitseerija selle tehingu jaoks, mis tähendab, et saab unikaalselt tuvastada saatja konto süsteemis. Tehingu struktuuri osas oleme põhiteema välja selgitanud.

Näide nutilepingust Soliditys

Vaatame nüüd lähemalt kõige lihtsamat nutilepingut näite kaudu.

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

Ülaltoodud on lihtsustatud lähtekood, mis võib säilitada kasutajate münte ja neid nõudmisel tagastada.

Seega on olemas Bank nutileping, millel on järgmised funktsioonid: see kogub oma kontole münte, st tehingu kinnitamisel ja sellise nutilepingu paigutamisel luuakse uus konto, mis võib sisaldada münte; see mäletab kasutajaid ja müntide jaotust nende vahel; sellel on mitmeid viise kontode haldamiseks, st on võimalik täiendada, välja võtta ja kontrollida kasutaja bilanssi.

Vaadakem nüüd igat rida lähtekoodis. Sellel lepingul on konstantseid välju. Üks neist on aadressi tüüpi ja seda nimetatakse owner. Siin leping mäletab kasutaja aadressi, kes selle nutilepingu lõi. Edasi on dünaamiline struktuur, mis salvestab vastavused kasutajate aadresside ja bilansside vahel.

Seejärel tuleb meetod Bank — see on nimetatud samamoodi nagu leping. Vastavalt sellele on see tema konstruktor. Siin toimub muutujale owner selle aadressi määramine, kes on paigutanud selle nutilepingu võrku. See on ainus, mis selle konstruktoris toimub. See tähendab, et msg on antud juhul just need andmed, mis on edastatud virtuaalsesse masinasse koos tehinguga, mis sisaldab kogu selle lepingu koodi. Vastavalt sellele on msg.sender selle tehingu autor, mis paigutab selle koodi. Tema saab olema nutilepingu omanik.

Meetod deposit võimaldab edastada tehinguga kindla arvu münte lepingu kontole. Antud juhul, kui nutileping saab need münte, hoiab ta neid enda saldos, kuid struktuuri balances kirjutatakse, kes täpselt oli nende müntide saatja, et teada, kellele need kuuluvad.

Järgmine meetod nimetatakse withdraw ja see võtab ühe parameetri - summa münte, mida keegi soovib sellest pangast välja võtta. Siin kontrollitakse, kas kasutaja, kes seda meetodit kutsub, omab piisavalt münte saldo peal, et neid edastada. Kui münte on piisavalt, tagastab nutileping kutse tegijale selle summa münte.

Seejärel tuleb kasutaja praeguse saldo kontrollimise meetod. Kutsuja, kes seda meetodit kutsub, kasutatakse selle saldoga smart lepingus. Oluline on märkida, et selle meetodi modifikaator on view. See tähendab, et meetod ei muuda oma klassi muutujaid ning on tegelikult ainult lugemise meetod. Eraldi tehingut ei luleta selle meetodi kutsumise jaoks, komisjonitasu ei maksta ning kõik arvutused tehakse kohalikult, pärast mida kasutaja saab tulemuse.

Kill meetod on vajalik, et hävitada nutilepingute olek. Siin on lisakontroll, kas meetodi kutsuja on selle lepinguga seotud omaniku. Kui on, siis leping hukkub automaatselt ja hävitamismeetod võtab ühe parameetri — konto identifikaatori, millele leping saadab kõik kaugendatud mündid, mis jäävad selle saldole. Sellisel juhul saadetakse allesjäänud mündid automaatselt omanikule.

Kuidas töötab Ethereum'i täielik soliit?

Vaadakem skeemist, kuidas nutilepingute täitmine toimub Ethereum'i platvormil ja kuidas töötab täielik soliit.

Ethereum'i täielik soliit peab sisaldama vähemalt nelja moodulit.
Esimene on, nagu iga detsentraliseeritud protokolli puhul, P2P võrgumoodul — moodul, mis vastutab ühenduse ja teiste soliitidega suhtlemise eest, kus toimub plokkide, tehingute ja teabe vahetus teiste soliitide kohta. See on traditsiooniline komponent kõigis detsentraliseeritud krüptovaluutades.

Järgmiseks on meil plokiahela andmete salvestamise, töötlemise, prioriteetse haru valimise, plokkide lisamise, plokkide eemaldamise, nende plokkide kontrollimise jm moodul.

Kolmas moodul kannab nime EVM (Ethereum virtuaalmasin) — see on virtuaalne masin, mis võtab vastu Ethereum'i tehingute baitkoodi. See moodul võtab etteantud konto praeguse oleku ja rakendab muudatusi selle olekus saadud baitkoodi põhjal. Iga võrgu sõlme virtuaalmasina versioon peab olema sama. Arvutused toimuvad kõigis Ethereum'i sõlmedes täiesti ühtlaselt, kuid need toimuvad asünkroonselt: keegi kontrollib ja aktsepteerib selle tehingu varem, st täidab kogu selles sisalduva koodi, ja keegi hiljem. Vastavalt sellele, kui tehing luuakse, levitab see end võrku, sõlmed võtavad selle vastu ja kontrollimise hetkel täpselt nii, nagu Bitcoini puhul täidetakse Bitcoin Script'i, täidetakse siin virtuaalmasina baitkoodi.

Tehingut loetakse kinnitatud, kui kõik selle sisu koodid on täidetud, on loodud uusi olekuid teatud kontole ning seda säilitatakse kuni selgub, kas tehing on rakendatud või mitte. Kui tehing on rakendatud, siis seda olekuid loetakse mitte ainult täidetuks, vaid ka kehtivaks. On olemas andmebaas, mis salvestab iga konto olekud iga võrgu sõlme jaoks. Kuna kõik arvutused toimuvad ühtemoodi ja plokiahela olek on identne, on ka kõikide kontode olekute andmebaas sama igas sõlmes.

Müüdid ja piirangud nutilepingute kohta

Mis puudutab piiranguid, mis kehtivad Ethereumile sarnastele nutilepingute platvormidele, siis võib tuua järgmised:

• koodi täitmine;
• mälumahutite eraldamine;
• plokiahela andmed;
• maksete saatmine;
• uue lepingu loomine;
• muude lepingute väljakutsumine.

Vaatame lähemalt, millised piirangud on määratud virtuaalmasinale, ja hajutame mõned müüdid nutilepingutest. Virtuaalmasinal, mis ei pruugi olla ainult Ethereumis, vaid ka sarnastes platvormides, on võimalik teostada tõeliselt juhuslikke loogilisi operatsioone, st kirjutada koodi, mis seal täidetakse, ning lisada mälumahtu. Kuid iga operatsiooni ja iga täiendava mälumahu eest tasutakse eraldi tasu.

Lisaks saab virtuaalmasin lugeda andmeid plokiahela andmebaasist, et kasutada neid andmeid nutilepingute teatud loogika täitmise käivitajana. Virtuaalmasin suudab luua ja saata tehinguid, luua uusi lepinguid ning kutsuda esile juba võrgus avaldatud teiste nutilepingute meetodeid: need on olemas, ligipääsetavad jne.

Kõige levinum müüt on see, et Ethereum'i nutilepingud saavad kasutada teavet mis tahes veebiallikatest oma tingimustes. Tõde on see, et virtuaalne masin ei saa saata võrgupäringut välisele teabeallikale internetis, seega ei saa kirjutada sellist nutilepingut, mis jagab väärtust kasutajate vahel sõltuvalt näiteks sellest, mis ilm on väljas, kes on mõnes meistrivõistluses võitnud või mõne muu välismaailma sündmuse põhjal, kuna teavet nende sündmuste kohta lihtsalt ei ole platvormi andmebaasis. Seega ei ole blokkhaaval selle kohta midagi. Kui seal ei ilmu midagi, ei saa virtuaalne masin neid andmeid ka triggeritena kasutada.

Ethereum'i puudused

Loetleme mõned peamised. Esiteks on Ethereumi nutilepingute projekteerimisel, arendamisel ja testimisel teatavad raskused. (Ethereumis kasutatakse nutilepingute kirjutamiseks Solidity keelt.) Tõepoolest, praktika näitab, et väga suur protsent kõigist vigadest on tingitud inimfaktori mõjust. See on tõsine probleem ka juba kirjutatud Ethereumi nutilepingute puhul, mille keerukus on keskmine või kõrgem. Kui lihtsate nutilepingute puhul on veaoht väike, siis keerukates nutilepingutes esineb sageli vigu, mis viivad raha varastamiseni, nende külmutamiseni, nutilepingute ettenägematule hävitamisele jne. Selliseid juhtumeid on juba palju teada.

Teine puudus seisneb selles, et virtuaalmasin ise pole ideaalne, kuna see on samuti inimeste kirjutatud. See võib täita juhuslikke käske ja just selles peitub haavatavus: teatud viisil on võimalik konfigureerida rida käske, mis viivad ettenägematute tagajärgedeni. See on väga keeruline valdkond, kuid on olemas juba mitmeid uuringuid, mis näitavad, et need haavatavused esinevad praeguses Ethereum'i versioonis ja need võivad viia paljude nutilepingute töökatkestuseni.

Veel üks suur keerukus, mida võib pidada puuduseks. See seisneb selles, et praktiliselt või tehniliselt on võimalik jõuda olukorrani, kus kui kompileerida nutilepingu baitkood, mis töötab virtuaalmasinas, on võimalik määratleda teatud spetsiifiline tegevuste järjekord. Kui need tegevused kokku täidetakse, koormavad need virtuaalmasinat väga tugevalt ja aeglustavad selle tööd proportsioonitamata tasu võrreldes nendest tegevustest tasutud tasuga.

Minevik, et Ethereum on kogenud arenguperioode, mil paljud inimesed, kes said hästi aru virtuaalsest masinast, avastasid erinevaid turvaprobleeme. Tegelikult maksid tehingud väga madalat tasu, kuid vähendasid märkimisväärselt kogu võrgu töövõimet. Neid probleeme on väga keeruline lahendada, kuna tuleb kõigepealt määratleda need, teiseks korrigeerida tehingute täitmise hinna ning kolmandaks läbi viia kõva haru (hardfork), mis tähendab kõikide võrgu sõlmede uuendamist uuele tarkvaraversioonile ja seejärel nende muudatuste üheaegset aktiveerimist.

Küsimus, mis puudutab Ethereum'i, on see, et on tehtud palju uuringuid ning saadud arvestatav praktikakogemus: nii positiivne kui ka negatiivne. Siiski jäävad alles keerukused ja turvavead, millega tuleb veel kuidagi tegeleda.

Nii on artikli sisuline osa lõpetatud, liikume edasi küsimuste juurde, mis esinevad üsna sageli.

Korduvad küsimused

— Kui kõik osalised kehtivast nutilepingust soovivad muuta tingimusi, kas nad saavad selle nutilepingut mitme allkirjaga tühistada ja seejärel luua uue nutilepingu uuendatud täitmise tingimustega?

Siin on vastus kahetine. Miks? Sest ühel poolt on nutileping ühekordselt defineeritud ja see ei eelda mingeid muudatusi, teisest küljest võib see sisaldada eelnevalt määratletud loogikat, mis võimaldab tingimuste täielikku või osalist muutmist. See tähendab, et kui soovite oma nutilepingus midagi muuta, peate eelnevalt määrama tingimused, mille alusel saate neid tingimusi uuendada. Seega, ainult sellise ettevaatliku lähenemisega on võimalik lepingut uuendada. Kuid ka siin võib tekkida probleeme: teha mõni viga ja saada vastava haavatavuse. Seetõttu tuleb selliseid asju väga detailselt ja hoolikalt projekteerida ning testida.

— Aga kui vahendaja puutub kokku ühe osalise osapoolega: escrow või nutilepinguga? Kas vahendaja on nutilepingus kohustuslik?

Mediatoor ei ole nutilepingus kohustuslik. Seda ei pruugi olla. Kui seoses escrow’ga satuvad mediatoor ja üks osalistest kokku leppima, siis jah, see skeem kaotab järsult oma väärtuse. Seetõttu valitakse mediatoorid nii, et neile usaldavad kõik osalised, kes antud protsessis on kaasatud. Vastavalt sellele ei edasta te lihtsalt münte multisignatuuri aadressile sellise mediatooriga, kellele te ei usalda.

— Kas on võimalik ühe tehinguga Ethereumiga saata palju erinevaid münte oma aadressilt erinevatele sihtaadressidele, näiteks börsi aadressidele, kus neid münte kaubeldakse?

See küsimus on hea ja puudutab Ethereum'i tehingumudelit ning selle erinevusi Bitcoin'i mudelist. Need erinevused on põhimõttelised. Kui Ethereum'i tehingumudelis edastate münte, siis need edastatakse lihtsalt ühelt aadressilt teisele, ilma tagasimakseta, lihtsalt konkreetne summa, mida olete määranud. Teisisõnu, see ei ole raiskamata väljundite (UTXO) mudel, vaid kontode ja vastavate saldode mudel. Ühe tehinguga on teoreetiliselt võimalik saata korraga mitmeid erinevaid tokene, kui kirjutada nutikalt sõlmitud nutileping, kuid sellegipoolest tuleb teha palju tehinguid, luua leping, edastada sellele tokene ja münte ning seejärel kutsuda vastav meetod. See nõuab pingutusi ja aega, seega praktikas nii ei toimi ning kõik maksed Ethereum'is tehakse eraldi tehingutena.

— Üks müüt Ethereum'i platvormi kohta on see, et ei saa kirjeldada tingimusi, mis sõltuvad välisest internetiressursist, kuidas siis olla?

Lahendus seisneb selles, et ise nutileping võib ette näha ühe või mitu nii nimetatud usaldusväärset oraaklit, mis koguvad andmeid välismaailma olukorra kohta ja edastavad need nutilepingutesse spetsiaalsete meetodite kaudu. Ise leping peab tõeks neid andmeid, mis ta on saanud usaldusväärsetelt allikatelt. Suurema usaldusväärsuse saavutamiseks valitakse lihtsalt suurem rühm oraakleid, et minimeerida nende kokkuleppe riski. Ise leping ei pruugi arvestada andmeid oraaklitest, mis on vastuolus enamuse arvamusega.

Selle teema kohta on juttu ühes Blockchaini veebikursuse loengus — “Sissejuhatus nutilepingutesse”.

Allikas: habr.com