Sissejuhatus tarkvaralepingutesse

Selles artiklis käsitleme, mis on nutilepingud, milliseid tüüpe need on, tutvume erinevate nutilepingute platvormidega ja nende eripäradega, samuti arutame, kuidas need toimivad ja milliseid eeliseid nad endas sisaldavad. See materjal on väga kasulik lugejatele, kes ei ole veel piisavalt tuttavad nutilepingute teemaga, kuid soovivad sellega tutvuda.

Tavaleping vs. nutileping

Enne kui süveneme üksikasjadesse, vaatame näite abil erinevusi tavalepingute, mis on paberil, ja nutilepingute, mis on digitaalsetes formatides, vahel.

Kuidas see toimis enne nutilepingute tulekut? Kujutage ette rühma inimesi, kes soovivad kehtestada teatud reeglid ja tingimused väärtuste jagamiseks, samuti kindlustada nende täitmist etteantud reeglite ja tingimuste alusel teatud mehhanismi abil. Siis kogunesid nad koos, koostasid dokumendi, kuhu märkisid oma isikuandmed, tingimused, osalised väärtused, panid kuupäeva ja allkirjastasid. Selle lepingu kinnitas ka usaldusväärne pool, näiteks notar. Seejärel lahkusid need inimesed eri suundades oma paberkoopia lepingust ja hakkasid tegema teatud toiminguid, mis ei vastanud lepingule, st nad tegid üht, samas kui paberil oli kinnitatud, et nad peaksid tegema täiesti midagi muud. Kuidas sellises olukorras edasi minna? Tegelikult pidi mõni grupi liige võtma selle paberi, koguma tõendeid, minema kohut ja nõudma lepingu ja tegelike toimingute vahelise vastavuse saavutamist. Üsna tihti on õiglane lepingu täitmine keeruline, mis toob kaasa ebameeldivaid tagajärgi.

Mida saame siis nutilepingute kohta öelda? Need ühendavad endas nii lepingu tingimuste kirjutamise võimaluse kui ka nende ranget täitmise mehhanismi. Kui tingimused on kehtestatud ja vastav tehing või taotlus on allkirjastatud, siis pärast selle taotluse või tehingu aktsepteerimist ei ole enam võimalik tingimusi muuta ega mõjutada nende täitmist.

Üks või mitmeid valideerijaid ja andmebaas, mis salvestab kõik nutilepingud, mis on täitmiseks esitatud, peavad olema olemas rangelt kronoloogilises järjekorras. Samuti on oluline, et see andmebaas sisaldaks kõiki tingimusi, mis on nutilepingu täitmise käivitamiseks vajalikud. Lisaks peab see sisaldama seda väärtust, mille jaotamine on lepingus kirjas. Kui see puudutab mõnda digitaalselt valuutat, siis peab see andmebaas seda arvesse võtma.

Teisisõnu, nutilepingute valideerijatel peab olema juurdepääs kõigile andmetele, millega nutileping opereerib. Näiteks peaks üks andmebaas arvestama samaaegselt digitaalseid valuutasid, kasutajate saldo, kasutajate tehingute ja ajatempleid. Siis võib nutilepingus tingimusena olla näiteks kasutaja saldo konkreetses valuutas, mingi aja saabumine või teatud tehingu teostamine, kuid mitte rohkem.

Nutilepingu määratlemine

Tegelikult tuli terminoloogia välja uurijalt Nick Szabo ning seda rakendati esmakordselt 1994. aastal, dokumenteeriti aga 1997. aastal artiklis, mis kirjeldab nutilepingute ideed.

Nutilepingud tähendavad, et toimub teatud väärtuse jaotuse automatiseerimine, mis sõltub ainult eelnevalt seatud tingimustest. Kõige lihtsamal kujul näeb see välja nagu leping rangelt määratud tingimustega, mille on allkirjastanud konkreetsed osalised.

Nutilepingud on mõeldud kolmandate osapoolte usalduse minimeerimiseks. Mõnikord kõrvaldatakse täiesti otsustusprotsess, millest kõik sõltub. Lisaks on selliste lepingute auditimine lihtsam. See tuleneb teatavatest süsteemi disainimise eripäradest, kuid kõige sagedamini tõlgendame nutilepingut kui detsentraliseeritud keskkonda ning olemasolu funktsioonide, mis võimaldavad igal soovijal andmebaasi analüüsida ja lepingute täitmist täielikult auditeerida. Nii garanteeritakse kaitse tagasiulatuvate andmete muutmise eest, mis tooks kaasa muudatusi ise lepingus täitmisel. Enamiku protsesside digitaliseerimine nutilepingu loomise ja käivitamise ajal lihtsustab sageli nende rakendamise tehnoloogiat ja kulusid.

Lihtne näide — Escrow teenus

Vaatame väga lihtsalt näidet. See aitab paremaks mõistmiseks aru saada nutilepingute funktsionaalsust ja millal neid on mõistlik kasutada.

Seda saab rakendada ka kasutades Bitcoini, kuigi praegu on Bitcoinil raske öelda, et see on tõeline platvorm nutilepingute jaoks. Nii et meil on teatud ostja ja veebipood. Ostja soovib osta selle poest monitori. Kõige lihtsamal juhul täidab ostja makse ja saadab selle, samas kui veebipood aktsepteerib selle, kinnitab ja seejärel saadab kauba. Siiski on selle olukorra juures usaldus probleem — ostja peab usaldama veebipoodi kogu monitori maksumuses. Kuna veebipoel võib ostja silmis olla madal maine, on risk, et mingil põhjusel pärast makse saamist keeldub pood teenindamisest ja ei saada ostjale kaupa. Seetõttu peab ostja küsima (vastavalt küsib ka veebipood), mida saaks sellisel juhul rakendada, et nende riske минимизировать ja sellised tehingud usaldusväärsemaks muuta.

Bitcoiniga on võimalik anda ostjale ja müüjale võimalus iseseisvalt valida vahendaja. On palju inimesi, kes tegelevad vaidluste lahendamisega. Ja meie osalejad saavad valida üldiselt usaldusväärsest vahendajate nimekirjast. Koos loovad nad multisignature aadressi 2 3-st, kus on kolm võtit ja kaks allkirja mistahes kahest võtmes, et kulutada seda aadressilt münte. Üks võti kuulub ostjale, teine veebipoele ja kolmas vahendajale. Ja sellele multisignature aadressile saadab ostja summa, mis on vajalik monitori 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 uurib ostja pakki, vaatab kaupa ja otsustab lõppostu üle. Ta võib olla täielikult rahul pakutud teenusega ning allkirjastada tehingu oma võtmega, millega ta edastab müüjale münte multisignature aadressilt, või ta võib olla millegagi rahulolematu. Teisel juhul pöördub ta vahemehe poole, et koostada alternatiivne tehing, mis jagab münte teisiti.

Oletame, et monitor on tiba kriimuline ja komplektis ei olnud kaabli, et arvutiga ühendada, kuigi internetipoe veebilehel oli öeldud, et see kaabel peab komplektis olema. Siis kogub ostja tõendeid, mis on vajalikud, et tõestada vahemeest, et teda on selles situatsioonis petetud: ta teeb ekraanipildid veebilehelt, pildistab postitusaadressi kviitungit, pildistab monitori kriimustusi ja näitab, et pitsat on avatud ning kaabel on välja tõmmatud. Internetipood omakorda kogub oma tõendeid ja edastab need vahemeest.

Vahemik on huvitatud sellest, et rahuldada samal ajal nii ostja pahameelt kui ka internetipoe huve (hiljem selgub, miks). Ta koostab sellise tehingu, kus münte multisignature aadressilt kulutatakse teatud osas ostja, internetipoe ja vahemehe vahel, kuna ta peab enda jaoks osa oma töö tasuks. Oletame, et 90% kogu summast läheb müüjale, 5% vahemehe jaoks ja 5% ostja kompenseerimiseks. Selle tehingu allkirjastab vahemees oma võtmega, kuid see ei saa veel rakenduda, kuna selleks on vajalik kaks allkirja, praegu on vaid üks. Sellise tehingu saadab ta nii ostjale kui müüjale. Kui vähemalt üks neist on rahul selle müntide ümberjaotamise variandiga, allkirjastatakse tehing ja levitatakse võrgus. Selle valideerimiseks piisab, et üks tehingu osalistest nõustub vahemehe pakutud variandiga.

Oluline on alguses valida vahendaja, kellele mõlemad osalised usaldavad. Sel juhul tegutseb ta sõltumatult ühe või teise huvidest ning hindab olukorda objektiivselt. Kui vahendaja ei paku sellist müntide jagamise varianti, mis rahuldaks vähemalt ühte osalist, saavad nii ostja kui ka internetipood, kokkuleppel, edastada mündid uuele multisignature aadressile, andes oma kaks allkirja. Uus multisignature aadress koostatakse teise vahendajaga, kes võib-olla on küsimuses kompetentsem ja pakub parema variandi.

Näide ühiselamust ja külmk kapist

Vaatame keerukamat näidet, mis näitab nutilepingute võimalusi selgemalt.

Oletame, et kolmel poisil, kes on hiljuti ühiselamusse kolinud, on huvi osta oma tuppa külmkapp, millega nad koos kasutavad. Üks neist on vabatahtlikult nõustunud koguma vajaliku summa külmiku ostmiseks ja asjaajamiseks müüjaga. Siiski on nad üksteisega suhteliselt hiljuti tutvunud, seega usaldust ei ole. On selge, et kaks neist riskivad, andes kolmandale raha. Lisaks peavad nad müüja valimise osas kokku leppima.

Nad saavad kasutada escrow teenust, st valida vahendaja, kes kontrollib tehingu teostamist ja lahendab võimalikke vaidlusi. Siis, kokkuleppel, koostavad nad nutilepingu ja määratlevad selles kindlad tingimused.

Esimene tingimus on see, et enne kindla aja möödumist, oletame ühe nädala jooksul, peavad määratud arvelduskontole saabuma kolm makset kindlatest aadressidest teatud summas. Kui seda ei juhtu, lõpetab nutileping oma täitmise ja tagastab mündid kõigile osalejatele. Kui tingimus on täidetud, määratakse müüja ja vahendaja tunnuseid ning kontrollitakse, et kõik osalejad on nõus müüja ja vahendaja valikuga. Kui kõik tingimused on täidetud, kantakse rahalised vahendid määratud aadressidele. Selline lähenemine võib osalejaid kaitsta pettuste eest kõikidest suundadest ja välistab üldiselt usaldamise vajaduse.

Me näeme selle näite põhjal põhimõtet, et selline võimalus samm-sammult määrata parameetreid iga tingimuse täitmiseks võimaldab luua süsteeme, mille keerukus ja sügavuse tasemed on erinevad. Lisaks sellele saab nutilepingus kõigepealt määrata esimese tingimuse ja alles pärast selle täitmist määrata järgmise tingimuse parameetrid. Teisisõnu, formaalselt on tingimus kirja pandud, kuid selle parameetrid võivad olla määratud juba selle toimuval ajal.

Nutilepingute klassifitseerimine

Klassifitseerimiseks võib määrata erinevad kriteeriumide grupid. Kuid tehnoloogia arengu hetkel on asjakohased neli neist.

Nutilepinguid saab eristada täitmis keskkonna järgi, mis võib olla kas tsentraliseeritud või detsentraliseeritud. Detsentraliseerimise puhul saame palju suurema sõltumatuse ja talitluspüsivuse nutilepingute täitmisel.

Neid saab eristada ka tingimuste määramise ja täitmise protsessi järgi: need võivad olla vabalt programmeeritavad, piiratud või eelnevalt määratud ehk rangelt tüübitud. Kui nutilepingute platvormil on olemas ainult 4 kindlat nutilepingut, võib nende parameetreid määrata vabalt. Seega on neid palju lihtsam määrata: valime nimekirjast lepingu ja edastame parameetrid.

In terms of initiation, there are automated smart contracts, meaning they execute automatically when certain conditions are met, and there are those contracts with defined conditions that the platform does not check automatically for compliance; they need to be initiated separately.

Moreover, smart contracts vary by the level of privacy. They can be fully open, partially open, or completely confidential. The latter means that third-party observers do not see the conditions of the smart contracts. However, the topic of privacy is quite broad and should be considered separately from the current article.

Below we will delve deeper into the first three criteria to provide more clarity on the current topic.

Smart contracts by execution environment

Smart contracts are distinguished by centralized and decentralized platforms. In the case of centralized digital contracts, a single service is used, where there is only one validator, and there may also be a backup and recovery service that is centrally managed. There is a single database that stores all the necessary information for setting the conditions of the smart contract and distributing the value recorded in that database. Such a centralized service has a client that sets conditions through specific requests and utilizes such contracts. Due to the centralized nature of the platform, authentication mechanisms may be less reliable than in cryptocurrencies.

For example, we can take mobile service providers (various mobile operators). Suppose a certain operator centrally tracks traffic on their servers, which can be transmitted in different formats, such as voice calls, SMS transmission, mobile internet traffic, and according to different standards, while also tracking user balance funds. Accordingly, the mobile service provider can formulate contracts for accounting provided services and their payments with various conditions. In this case, conditions can easily be set, such as 'send an SMS with a specific code to a particular number and receive certain traffic distribution conditions.'

Võite tuua veel ühe näite: traditsioonilised pangad, millel on ulatuslikud internetipanganduse funktsioonid, ja väga lihtsad lepingud, nagu regulaarsed maksed, sissetulevate maksete automaatne konverteerimine, protsentide automaatne ülekandmine määratud kontole jne.

Kui rääkida nutilepingutest, millel on detsentraliseeritud täitmise keskkond, siis on meil rühm valideerijaid. Ideaalis võib valideerijaks saada keegi, kes tahab. Andmebaasi sünkroniseerimise protokolli ja konsensuse saavutamise kaudu saame mingisuguse ühise andmebaasi, mis salvestab nüüd kõiki tehinguid selgelt kirja pandud lepingute alusel, mitte mingeid tingimuslikke päringuid, mille vormingud sageli muutuvad ja millel pole avatud spetsifikatsiooni. Siin sisaldavad tehingud juhiseid lepingute täitmiseks vastavalt rangetele spetsifikatsioonidele. See spetsifikatsioon on avatud ja seega saavad platvormi kasutajad läbi viia auditeid ja valideerida nutilepinguid. Näeme, et detsentraliseeritud platvormid ületavad keskseid platvorme sõltumatuse ja tõrketaluvuse poolest, kuid nende projekteerimine ja hooldamine on sel juhul palju keerulisem.

Nutilepingud tingimuste määramise ja täitmise meetodil

Nüüd vaatame lähemalt, kuidas nutilepingud võivad erineda tingimuste määramise ja täitmise meetodi poolest. Siin pöörame tähelepanu nutilepingutele, mida saab vabalt programmeerida ja mis on Turingi täielikud. Turingi täielik nutileping võimaldab määrata praktiliselt mis tahes algoritme lepingutingimustena: kirjutada sildu, mingit tõenäosuse arvutamise funktsiooni ja nii edasi — kuni omaenda digitaalsete allkirjade algoritmideni. Sel juhul on tõeliselt vaba loogika kirjutamine mõeldud.

Erinevad ka vabalt kasutatavad nutilepingud, kuid mitte Turingi täielikud. Siia kuuluvad Bitcoin ja Litecoin oma skriptiga. See tähendab, et ühte korraldada saab ainult teatud operatsioone, kuid sildu ja oma algoritme juba kirjutada ei saa.

Lisaks on olemas ka selliseid nutilepingute platvorme, mis rakendavad ette määratud nutilepinguid. Nendeks on näiteks Bitshares ja Steemit. Bitshares'il on terve rida nutilepinguid kaubanduse, konto haldamise, platvormi enda ja selle parameetrite haldamise jaoks. Steemit on sarnane platvorm, kuid on suunatud mitte tokenite väljastamisele ja kaubandusele, nagu Bitshares, vaid blogimisele, st see salvestab ja töötleb sisu detsentraliseeritud viisil.

Tavaliste täis Turingi lepingute hulka kuuluvad platvorm Ethereum ja RootStock, mis on veel arendusjärgus. Seetõttu peatume järgmiseks natuke põhjalikumalt nutilepingute platvormil Ethereum.

Nutilepingud sissetoomise viisi järgi

Sissetoomise viisi järgi saab nutilepingud jagada vähemalt kaheks rühmaks: automatiseeritud ja käsitsi (mitte automatiseeritud). Automatiseeritud puhul on iseloomulik, et kõigi teadaolevate parameetrite ja tingimuste täitmisel täidetakse nutileping täielikult automaatselt, st ei nõua täiendavate tehingute saatmist ja iga järgnevate täitmiste puhul lisatasu kulutamist. Platvormil on kõik andmed, et arvutada, kuidas nutileping lõppeb. Loogika ei ole seal juhuslik, vaid ette määratud ja kõik see on etteennustatav. See tähendab, et on võimalik eelnevalt hinnata nutilepingu täitmise keerukust, kasutada sellele mingit konstantset tasu ja kõik protsessid tema täitmiseks toimuvad tõhusamal viisil.

Nutilepingutele, mida programmeeritakse juhuslikult, ei ole täitmine automatiseeritud. Sellise nutilepingu sissetoomiseks on iga sammu puhul vajalik luua uus tehing, mis kutsub esile järgmise täitmisetapi või järgmise nutilepingu meetodi, tasuda vastav tasu ja oodata tehingu kinnitamist. Täitmine võib lõppeda edukalt või mitte, kuna nutilepingu kood on juhuslik ning võivad ilmneda ettearvamatused, nagu lõputu tsükkel, teatud parameetrite ja argumentide puudumine, töötlemata erandid jne.

Kontod Ethereumis

Ethereum kontotüübid

Vaatame, millised võivad olla kontod Ethereum platvormil. Siin on ainult kaks tüüpi kontosid ja rohkem variante ei ole. Esimene tüüp nimetatakse kasutajakontoks, teine – lepingukontoks. Uurime, kuidas need erinevad.

Kasutajakontot juhib ainult isiklik allkirjakey. Konto omanik genereerib oma ECDSA (Elliptic Curve Digital Signature Algorithm) algoritmi abil allkirja jaoks võtmepaari. Selle konto olekut saavad muuta ainult selle võtmega allkirjastatud tehingud.

Lepingukonto jaoks on ette nähtud eraldi loogika. Sedalaadi kontot saab juhtida ainult eelnevalt määratud programmikoodi abil, mis määratleb täielikult lepingukonto käitumise: kuidas see oma münte teatud olukordades kasutab, millise kasutaja algatusel ja milliste lisatingimuste täitmisel need mündid jagatakse. Kui mõningaid aspekte ei ole arendajad programmikoodis ette näinud, võivad tekkida probleemid. Näiteks võib lepingukonto jõuda teatud olekusse, kus ta ei aktsepteeri edasisi käivitamisi üheltki kasutajalt. Sellisel juhul võivad mündid tegelikult külmuda, kuna lepingukonto ei ole selle olekust väljapääsu ette näinud.

Kuidas luuakse kontosid Ethereumis

Kasutajakonto puhul genereerib omanik iseseisvalt võtmepaari ECDSA järgi. Oluline on märkida, et Ethereum kasutab allkirjastamiseks täpselt sama algoritmi ja sama elliptilist kõverat nagu Bitcoin, kuid aadress arvutatakse pisut teistsugusel viisil. Siin ei rakendata topelthashimist, nagu Bitcoini puhul, vaid kasutatakse Kecakk-funktsiooni ühekordset hashimist 256-bitise pikkusega. Saadud väärtusest lõigatakse ära madalamad bitid, nimelt 160 kõige madalamat bitti hash-funktsiooni väljundist. Lõpuks saame Ethereum aadressi. Tegelikult hõivab see 20 baiti.

Pöörame tähelepanu sellele, et Ethereum'i konto identifikaator kodeeritakse heksadesimaalses vormis ilma kontrollsummata, erinevalt Bitcoin'ist ja paljusid teisi süsteeme, kus aadress kodeeritakse 58-põhisesse numbrilisse süsteemi koos kontrollsumma lisamisega. See tähendab, et Ethereum'i konto identifikaatoritega tuleb olla ettevaatlik: isegi üks viga identifikaatoris toob kindlasti kaasa müntide kadumise.

On oluline, et kasutaja konto luuakse üldise andmebaasi tasemel just sel hetkel, kui ta aktsepteerib esimese sisse tuleva makse.

Nutilepingute konto loomise puhul rakendatakse täiesti teistsugust lähenemist. Alustuseks kirjutab mõni kasutajatest nutilepingu lähtekoodi, seejärel käib kood spetsiaalse Ethereum'i platvormile mõeldud kompilaatori kaudu, et saada oma Ethereum'i virtuaalmasina jaoks bytecode. Saadud bytecode paigutatakse spetsiaalsesse tehingu valdkonda. Tehing kinnitatakse algataja konto nimel. Seejärel levitatakse tehing võrgu kaudu ja paigutatakse nutilepingu kood. Tehingu teostamise tasu ning seega ka lepingu täitmise tasu lahutatakse algataja konto saldost.

Iga nutileping sisaldab tingimata oma konstruktorit (selle lepingu). See võib olla tühi või sisaldada sisu. Pärast konstruktorite täitmist luuakse nutilepingu konto identifikaator, mida saab kasutada müntide saatmiseks, teatud nutilepingu meetodite kutsumiseks jne.

Ethereum'i tehingu struktuur

Selle selgemaks muutmiseks alustame Ethereum'i tehingu struktuuri ja nutilepingu koodi näite uurimist.

Ethereum'i tehing koosneb mitmest valdkonnast. Esimene neist, nonce, on mingisugune tehingu järjestusnumber, mis on seotud konto, kes seda levitab ja on selle autor. See on vajalik tehingute duplikaatide eristamiseks, et välistada olukord, kus sama tehingut aktsepteeritakse kaks korda. Tänu identifikaatori rakendamisele on igal tehingul ainulaadne hash-väärtus.

Seejärel järgneb selline väli nagu gas priceSiin näidatakse hinda, mille eest baasvaluuta Ethereum konverteeritakse gas'iks, millega tasutakse nutilepingute täitmise ja virtuaalse masina ressursi eraldamise eest. Mida see tähendab?

Bitcoini puhul makstakse teenustasusid otse baasaraha — ise Bitcoini. See on võimalik tänu lihtsale arvutuste mehhanismile: me maksame täpselt andmemahtu, mis sisaldub tehingus. Ethereumis on olukord keerulisem, kuna andmemahu põhjal tehingu hindamine on väga keeruline. Tehing võib sisaldada ka programmikoodi, mis käivitatakse virtuaalses masinas, ja iga virtuaalse masina operatsioonil võib olla erinev keerukus. Samuti on operatsioone, mis eraldavad mälu muutujatele. Nendel on oma keerukus, millest sõltub tasu iga operatsiooni eest.

Iga operatsiooni hind gas'i ekvivalentis on konstantne. See on spetsiaalselt sisse viidud selleks, et määrata iga operatsiooni konstantne hind. Vastavalt võrgu koormusele muutub gas'i hind, st korrutegur, mille alusel baasaraha konverteeritakse sellesse abielementi tasu maksmiseks.

On veel üks eripära Ethereumis toimuval tehingul: bajtikood, mis see sisaldab virtuaalses masinas täitmiseks, käivitatakse seni, kuni see ei lõpeta mingit tulemust (edu-ebaedu) või kuni lõpeb teatud kogus münte, mis on ette nähtud tasu maksmiseks. Just selleks, et vältida olukorda, kus saatja kontolt kulutatakse kõik münte tasuks mingi vea tõttu (näiteks kui mingisugune lõpmatu tsükkel käivitus virtuaalses masinas), on olemas järgmine väli — start gas (seda nimetatakse tihti gas limiidiks) — see määrab maksimaalse müntide arvu, mille saatja on valmis kulutama konkreetse tehingu täitmiseks.

Järgmine väli on nimetatud destination address. Siia kirjutatakse saadetavate müntide saaja aadress või konkreetse nutilepinguga aadress, mille meetodeid kutsutakse. Selle järel tuleb väli value, kuhu kirjutatakse saadetavate müntide summa destination address'ile.

Edasi asub huvitav väli nimega data, kuhu mahub terve struktuur. See ei ole eraldi väli, vaid terve struktuur, milles määratakse kood virtuaalse masina jaoks. Siia saab paigutada juhuslikke andmeid — selleks kehtivad erireeglid.

Ja viimast väli nimetatakse allkiri. See sisaldab samaaegselt autori elektroonilist allkirja selle tehingu kohta ning avalikku võtit, millega seda allkirja kontrollitakse. Avalikust võtme põhjal saab tuletada saatja konto identifikaatori, see tähendab, et saab unikaalselt tuvastada saatja konto süsteemis. Tehingustruktuuri osas oleme põhiasjad selgeks teinud.

Näide smartehingu koodist Soliditys

Vaadakem nüüd lähemalt kõige lihtsamat smartehingut näite põhjal.

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

Ülal on toodud lihtsustatud lähtekood, mis suudab hoida kasutajate münte ja tagastada need nõudmisel.

Nii on olemas smartehing Bank, mis täidab järgmisi funktsioone: see kogub oma kontole münte, st tehingu kinnitamisel ja sellise smartehingu paigutamisel luuakse uus konto, mis võib hoida münte oma kontol; see mäletab kasutajaid ja münte nende vahel; omab mitmeid meetodeid kontode haldamiseks, st on võimalik kontosid täiendada, välja võtta ja kontrollida kasutaja bilanssi.

Vaadakem iga rida lähtekoodis. Selles lepingus on konstantseid välju. Üks neist, tüübiga address, nimetatakse owner. Siia leping mäletab kasutaja aadressi, kes selle smartehingu lõi. Edasi on dünaamiline struktuur, mis salvestab vastavusi kasutajate aadresside ja bilansside vahel.

Pärast seda järgneb meetod Bank — see on nime poolest sama, mis leping. Vastavalt sellele on see tema konstruktor. Siin toimub muutuja owneri määramine selle isiku aadressile, kes selle smartehingu võrgus paigutas. See on ainus, mis toimub selles konstruktoris. Seega on msg antud juhul just need andmed, mis edastati virtuaalsele masinale koos tehinguga, mis sisaldas kogu selle lepingu koodi. Vastavalt sellele on msg.sender selle tehingu autor, mis paigutab selle koodi. Tema ongi smartehingu omanik.

Deposit meetod võimaldab tehingus teatud arvu münte edastada lepingu kontole. Antud juhul, kui nutileping saab need mündid, hoiab ta need oma saldos, kuid saldos on kirjas, kes täpselt olid nende müntide saatjad, et teada, kelle omad need on.

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 kutsub esile selle meetodi, saldo on piisav, et neid saata. Kui piisavalt, siis nutileping tagastab kutse teinud isikule selle arvu münte.

Edasi tuleb meetod, mis kontrollib kasutaja praegust saldo. See, kes kutsub esile selle meetodi, kasutatakse selle saldo saamiseks nutilepingus. Tasub märkida, et selle meetodi modifikaator on view. See tähendab, et meetod ei muuda oma klassi muutujaid ning on tegelikult ainult lugemismeetod. Eraldi tehingut ei loodud selle meetodi kutseks, komisjonitasu ei maksta, ja kõik arvutused teostatakse kohapeal, pärast mida kasutaja saab tulemuse.

Meetod kill on vajalik nutilepingute oleku hävitamiseks. Siin on lisaks kontroll, kas meetodi kutse tegija on selle lepingu omanik. Kui on, siis leping hävitatakse ja hävitamise funktsioon võtab ühe parameetri — konto identifitseerimise, kuhu leping saadab kõik mündid, mis jäävad tema saldosse. Antud juhul lähevad ülejäänud münnid automaatselt lepingu omaniku aadressile.

Kuidas töötab Ethereum'i võrgu täis sõlm?

Vaatame skeemiliselt, kuidas sellised nutilepingud töötavad Ethereum'i platvormil ja kuidas töötab võrgu täis sõlm.

Ethereum'i võrgu täis sõlm peab vähemalt omama nelja moodulit.
Esmane, nagu igasuguste detsentraliseeritud protokollide puhul, on P2P networking module — võrgu ühenduse moodul ja töötamine teiste sõlmede, kus toimub plokkide, tehingute ja informatsiooni vahetus teiste sõlmede kohta. See on traditsiooniline komponent kõigi detsentraliseeritud krüptovaluutade jaoks.

Edasi, meil on plokiahela andmete salvestamise, töötlemise, prioriteetselt haru valimise, plokkide täiendamise, plokkide eemaldamise, nende plokkide kontrollimise jne moodul.

Kolmas moodul kannab nime EVM (Ethereum virtuaalne masin) — see ongi virtuiaalmasin, mis aktsepteerib Ethereum'i tehingust saadud baitkoodi. See moodul võtab vastu teatud konto praeguse oleku ja teostab muudatusi selle olekus vastavalt saadud baitkoodile. Iga võrgu sõlme virtuaalse masina versioon peab olema sama. Arvutused toimuvad iga Ethereum'i sõlmes täiesti ühtlaselt, kuid need toimuvad asünkroonselt: keegi kontrollib ja aktsepteerib selle tehingu varem, see tähendab täidab kogu selles sisalduvat koodi, ja keegi hiljem. Seega, kui tehing luuakse, levitatakse see võrku, sõlmed aktsepteerivad seda ja valideerimise hetkel toimub see sama moodi nagu Bitcoinis toimub Bitcoin Script'i täitmine, siin täidetakse virtuaalse masina baitkoodi.

Tehingut loetakse kehtivaks, kui kogu selles sisalduv kood on täidetud, on genereeritud uued muudatused teatud konto olekus ja need salvestatakse seni, kuni on selge, kas see tehing on rakendatud või mitte. Kui tehing on rakendatud, siis seda olekut peetakse mitte ainult täidetuks, vaid ka aktuaalseks. On andmebaas, mis salvestab iga konto oleku iga võrgu sõlme jaoks. Kuna kõik arvutused toimuvad ühtlaselt ja plokiahela olek on sama, on ka andmebaas, mis sisaldab kõigi kontode olekuid, iga sõlme jaoks sama.

Müüdid ja piirangud nutilepingutest

Mis puutub piirangutesse, mis kehtivad Ethereum'i sarnaste nutilepingute platvormide kohta, siis võib tuua järgmised:

• koodi täitmine;
• mälu eraldamine;
• plokiahela andmed;
• maksete saatmine;
• uue lepingu loomine;
• muude lepingute kutsumine.

Vaatame üle need piirangud, mis kehtivad virtuaalmasinale, ja seega hajutame mõned müüdid nutilepingute kohta. Virtuaalmasinas, mis ei pruugi olla ainult Ethereumis, vaid ka sarnastes platvormides, on võimalik tõeliselt teostada igasuguseid loogilisi operatsioone, st kirjutada koodi ja see seal välja viia, lisaks saab eraldada täiendavat mälu. Siiski tuleb komisjonitasu maksta iga tehingu ja iga eraldatud mäluhulga eest eraldi.

Edasi, virtuaalmasin võib lugeda andmeid plokiahela andmebaasist, et kasutada neid andmeid nutilepingute teatud loogika teostamise käivitajaks. Virtuaalmasin võib luua ja saata tehinguid, luua uusi lepinguid ja kutsuda välja teiste juba võrgus avaldatud nutilepingute meetodeid: olemasolevad, kättesaadavad jne.

Levinud müüt on see, et Ethereum'i nutilepingud saavad kasutada teavet mistahes Interneti-ressurssidest oma tingimustes. Tõde on see, et virtuaalmasin ei saa saata võrgu päringut mingile välist informatsiooniallikale Internetis, st ei saa kirjutada sellist nutilepingut, mis jagaks väärtust kasutajate vahel sõltuvalt näiteks ilmast, kes võitis mõnes meistrivõistlustes, või mis tahes välismaailmas toimunud sündmuse alusel, kuna teavet nende sündmuste kohta lihtsalt ei ole platvormi enda andmebaasis. See tähendab, et plokiahelas ei ole selle kohta midagi. Kui seda seal ei ole, ei saa virtuaalmasin kasutada neid andmeid käivitajatena.

Ethereum'i puudused

Loetleme mõned peamised neist. Esimene puudus seisneb selles, et Ethereumis nutilepingute projekteerimisel, arendamisel ja testimisel esineb teatud raskusi (Ethereumis kasutatakse nutilepingute kirjutamiseks Solidity keelt). Tõepoolest, praktika näitab, et väga suur protsent kõikidest vigadest tuleneb inimfaktorist. See kehtib ka juba kirjutatud Ethereum-i nutilepingute puhul, mille keerukus on keskmine või kõrgem. Kui lihtsate nutilepingute puhul on vea tekkimise tõenäosus väike, siis keerulistes nutilepingutes esineb väga sageli vigu, mis viivad vahendite varastamiseni, nende külmutamiseni, nutilepingute ettenägematule viisil hävitamiseni jne. Võime tuua palju selliseid näiteid.

Teine puudus seisneb selles, et ise virtuaalmasin ei ole ideaalne, kuna see on samuti inimeste poolt kirjutatud. See suudab täita meelevaldseid käske ja selles peitub haavatavus: teatud viisil saab konfigureerida rida käske, mis viivad ettenägematutele tagajärgedele. See on väga keeruline valdkond, kuid juba on läbi viidud mitmeid uuringuid, mis näitavad, et need haavatavused esinevad praeguses Ethereum-i versioonis ja need võivad põhjustada paljude nutilepingute töökatkestusi.

Veel üks suur keerukus, mida võib pidada puuduseks. See seisneb selles, et praktikas või tehniliselt võib juhtuda, et kui kompileerida lepingute binaarkood, mis töötab virtuaalmasinas, saab määrata teatud spetsiifilise toimingute järjestuse. Kui neid toiminguid koos teha, koormavad need virtuaalmasinat väga tugevalt ja aeglustavad seda vastupidiselt sellele tasule, mis on makstud nende toimingute täitmise eest.

Ajal oli juba selline arenguperiood Ethereumis, mil paljud, kes said põhjalikult aru virtuaalmaja toimimisest, leidsid selliseid haavatavusi. Tegelikult maksid tehingud väga madalat tasu, kuid peaaegu tõid kogu võrgu töö väga aeglaselt. Nende probleemide lahendamine on äärmiselt keeruline, kuna tuleb neid kõigepealt määratleda, teiseks korrigeerida tehingute tegemise hinda ja kolmandaks viia läbi hard fork, mis tähendab kõigi võrgu sõlmede värskendamist uue tarkvara versiooniga ning seejärel nende muutuste samasugust aktiveerimist.

Mis puutub Ethereumisse, siis on tehtud väga palju uuringuid, saadud suur praktika: nii positiivne kui ka negatiivne, kuid vaatamata sellele jäävad probleemid ja haavatavused, millega tuleb veel kuidagi võidelda.

Nii et artikli teemaosa on lõpetatud, liigume küsimuste juurde, mis tekivad üsna tihti.

Korduma kippuvad küsimused

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

Siin on vastus kahekordne. Miks? Kuna ühelt poolt määratakse nutileping ühekordselt ja see ei tähenda juba mingeid muudatusi, kuid teisest küljest võib see omada eelnevalt määratud loogikat, mis ette näeb tingimuste täielikku või osalist muutmist. See tähendab, et kui soovite oma nutilepingus midagi muuta, peate eelnevalt määratlema tingimused, mille alusel saate need tingimused uuendada. Seega saab ainult selliselt ettevaatlikult korraldada lepingu uuendamist. Kuid ka siin on võimalik eksida: teha mõni viga ja saada vastav haavatavus. Seetõttu tuleb selliseid asju väga detailselt ja hoolikalt projekteerida ja testida.

— Ja kui vahendaja teeb koostööd ühe osalisega: escrow või nutileping? Kas vahendaja on nutilepingus kohustuslik?

Mediatoor ei ole nutika lepinguga kohustuslik. Seda ei pruugi olla. Kui escrow puhul satub mediatoor koos ühe osapoolega salasuhtesse, siis jah, see skeem kaotab järsult oma väärtuse. Seetõttu valitakse mediatoorid nii, et neile usaldavad kõik osalised, kes on seotud selle protsessiga. Seega ei hakka te lihtsalt ülekandeid multisignature aadressile tegema selle mediatooriga, kellele ei usalda.

— Kas on võimalik ühe Ethereum'i tehinguga saata oma aadressilt palju erinevaid tokeneid erinevatesse sihtaadressidesse, näiteks börsi aadressidesse, kus neid tokeneid kaubeldakse?

See on hea küsimus ja see puudutab Ethereum'i tehingute mudelit ning selle erinevust Bitcoin'i mudelist. Ja see erinevus on kardinaalne. Kui Ethereum'i tehingu mudelis edastate lihtsalt münte, siis need edastatakse ainult ühelt aadressilt teisele, vaatamata tagasimaksetele, lihtsalt konkreetne summa, mille olete määranud. Teisisõnu, see ei ole kulutamata väljundite (UTXO) mudel, vaid just kontode mudel koos vastavate saldoidega. Ühe tehinguga saata teoreetiliselt mitu erinevat tokeneid on võimalik, kui kirjutada osav nutileping, kuid siiski tuleb teha palju tehinguid, luua leping, seejärel edastada sellele tokeneid ja münte, ning seejärel kutsuda vastavat meetodit. See nõuab pingutust ja aega, seega ei toimi praktikas nii, et kõik maksed Ethereum'is tehakse eraldi tehingutena.

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

Lahendus seisneb selles, et nutileping ise võib ette näha ühe või mitu nii-öelda usaldusväärset oraaklit, mis koguvad teavet asjaolude kohta välismaailmas ja edastavad seda nutilepingutele spetsiaalsete meetodite kaudu. Ainus leping peab tõeks selliseid andmeid, mida ta on saanud usaldusväärsetelt osapooltelt. Suurema usaldusväärsuse tagamiseks valitakse lihtsalt suurem rühm oraakleid ja minimeeritakse nende süüdistamise risk. Leping võib ignoreerida oraaklite andmeid, mis on vastuolus enamus teabega.

Käesolev teema on pühendatud ühe online-kursuse loengule Blockchain — “Sissejuhatus tarkvaralepingutesse”.

Allikas: habr.com