Käesolevas artiklis vaatleme, mis on nutikad lepingud, mis need on, tutvume erinevate nutikate lepingute platvormidega, nende funktsioonidega ning arutleme ka selle üle, kuidas need toimivad ja milliseid eeliseid võivad tuua. See materjal on väga kasulik lugejatele, kes pole nutikate lepingute teemaga hästi kursis, kuid soovivad selle mõistmisele lähemale jõuda.
Tavaline leping vs. tark leping
Enne detailidesse süvenemist toome näite tavalepingu, mis on määratud paberil, ja nutilepingu, mis on digitaalselt esindatud, erinevustest.
Kuidas see toimis enne nutikate lepingute tulekut? Kujutage ette gruppi inimesi, kes soovivad kehtestada teatud reeglid ja tingimused väärtuste jaotamiseks, samuti teatud mehhanismi, mis garanteerib selle jaotuse elluviimise vastavalt etteantud reeglitele ja tingimustele. Seejärel kogunesid nad kokku, koostasid paberi, kuhu kirjutasid üles oma isikuandmed, tingimused ja väärtused, kuupäevastasid ja allkirjastasid. Selle lepingu kinnitas ka usaldusväärne isik, näiteks notar. Lisaks läksid need inimesed sellise lepingu paberkoopiaga eri suundadesse ja hakkasid tegema mingeid toiminguid, mis ei pruugi lepingule endale vastata, see tähendab, et nad tegid ühte asja, kuid paberil kinnitati, et nad peaksid midagi tegema. täiesti erinev. Ja kuidas sellest olukorrast välja tulla? Tegelikult peab üks rühmaliikmetest võtma selle paberi, võtma mõned tõendid, andma need kohtusse ja saavutama lepingu ja tegelike toimingute vastavuse. Üsna sageli on selle lepingu õiglast täitmist raske saavutada, mis toob kaasa ebameeldivaid tagajärgi.
Mida saab öelda nutikate lepingute kohta? Need ühendavad nii lepingutingimuste kirjutamise võimaluse kui ka nende range rakendamise mehhanismi. Kui tingimused on seatud ja vastav tehing või päring on allkirjastatud, siis pärast selle taotluse või tehingu aktsepteerimist ei ole enam võimalik tingimusi muuta ega nende täitmist mõjutada.
Seal on üks validaator või terve võrk, samuti andmebaas, mis salvestab kõik täitmiseks esitatud nutikad lepingud ranges kronoloogilises järjekorras. Samuti on oluline, et see andmebaas peab sisaldama kõiki nutika lepingu täitmise käivitustingimusi. Lisaks peab see võtma arvesse just seda väärtust, mille jaotust lepingus kirjeldatakse. Kui see kehtib mõne digitaalse valuuta kohta, peaks see andmebaas seda arvesse võtma.
Teisisõnu peab nutikatel lepingute valideerijatel olema juurdepääs kõikidele andmetele, millel nutikas leping töötab. Näiteks tuleks digitaalsete valuutade, kasutajate saldode, kasutajatehingute ja ajatemplite üheaegseks arvestamiseks kasutada ühte andmebaasi. Siis võib nutikas lepingus olla tingimuseks kasutaja saldo teatud valuutas, teatud aja saabumine või teatud tehingu sooritamine, aga ei midagi enamat.
Nutika lepingu definitsioon
Üldiselt lõi terminoloogia ise teadlane Nick Szabo ja seda kasutati esmakordselt 1994. aastal ning see dokumenteeriti 1997. aastal artiklis, mis kirjeldab arukate lepingute ideed.
Nutikad lepingud eeldavad teatud väärtuse jaotamise automatiseerimist, mis saab sõltuda ainult eelnevalt kindlaks määratud tingimustest. Lihtsamal kujul näeb see välja nagu rangelt määratletud tingimustega leping, millele on alla kirjutanud teatud osapooled.
Nutikad lepingud on loodud selleks, et vähendada usaldust kolmandate isikute vastu. Mõnikord on otsustuskeskus, millest kõik sõltub, täiesti välistatud. Lisaks on selliseid lepinguid lihtsam auditeerida. See on sellise süsteemi mõningate disainifunktsioonide tagajärg, kuid enamasti mõistame nutika lepingu all detsentraliseeritud keskkonda ja funktsioonide olemasolu, mis võimaldavad andmebaasi analüüsida ja lepingute täitmise täielikku auditit läbi viia. See tagab kaitse tagasiulatuvate andmete muutmise eest, mis tooks kaasa muudatusi lepingu enda täitmises. Enamike protsesside digitaliseerimine nutika lepingu loomisel ja käivitamisel lihtsustab sageli nende rakendamise tehnoloogiat ja maksumust.
Lihtne näide – tingdeponeerimisteenus
Vaatame väga lihtsat näidet. See aitab teil jõuda lähemale arukate lepingute funktsionaalsuse mõistmisele ja paremini mõista, millistel juhtudel tuleks neid kasutada.
Seda saab rakendada ka Bitcoini abil, kuigi praegu ei saa Bitcoini veel nimetada nutikate lepingute täisväärtuslikuks platvormiks. Niisiis, meil on ostjaid ja meil on veebipood. Klient soovib osta monitori sellest poest. Lihtsamal juhul täidab ja saadab ostja makse ning veebipood võtab selle vastu, kinnitab ja seejärel saadab kauba teele. Sellises olukorras on aga vaja suurt usaldust – ostja peab usaldama veebipoodi kogu monitori maksumuse. Kuna veebipoel võib ostja silmis olla madal maine, siis on oht, et mingil põhjusel keeldub pood pärast makse aktsepteerimist teenindusest ega saada kaupa ostjale. Seetõttu esitab ostja küsimuse (ja vastavalt sellele ka veebipood), mida saab antud juhul rakendada, et selliseid riske minimeerida ja tehinguid usaldusväärsemaks muuta.
Bitcoini puhul on võimalik lubada ostjal ja müüjal iseseisvalt valida vahendaja. On palju inimesi, kes on seotud vastuoluliste küsimuste lahendamisega. Ja meie osalejad saavad valida üldisest vahendajate nimekirjast selle, keda nad usaldavad. Koos loovad nad 2/3 mitme allkirjaga aadressi, kus on kolm võtit ja sellelt aadressilt müntide kulutamiseks on vaja kahte allkirja kahe võtmega. Üks võti hakkab kuuluma ostjale, teine veebipoele ja kolmas vahendajale. Ja sellisele mitme allkirjaga aadressile saadab ostja monitori eest tasumiseks vajaliku summa. Nüüd, kui müüja näeb, et temast sõltuval mitme allkirjaga aadressil on raha mõneks ajaks blokeeritud, võib ta monitori julgelt postiga saata.
Järgmisena saab ostja paki kätte, vaatab kauba üle ja teeb lõpliku ostuotsuse. Ta võib pakutava teenusega täielikult nõustuda ja allkirjastada tehingu oma võtmega, kus ta kannab mitme allkirjaga aadressilt müüjale münte või olla millegagi rahulolematu. Teisel juhul võtab ta ühendust vahendajaga, et koostada alternatiivne tehing, mis jaotab need mündid erinevalt.
Oletame, et monitor saabus veidi kriimuga ja komplektis polnud arvutiga ühendamise kaablit, kuigi netipoe kodulehel oli kirjas, et kaabel peaks komplektis olema. Seejärel kogub ostja tõendid, mis on vajalikud vahendajale tõestamaks, et ta selles olukorras pettus: ta teeb saidist ekraanipildid, pildistab postikviitungist, pildistab monitori kriimustusi ja näitab, et pitsat oli katki ja kaabel tõmmati välja. Veebipood omakorda kogub oma tõendid kokku ja edastab need vahendajale.
Vahendaja on huvitatud nii ostja nördimuse kui ka veebipoe huvide samaaegsest rahuldamisest (selgub hiljem, miks). Tegemist on tehinguga, mille käigus mitme allkirjaga aadressilt pärit mündid kulutatakse teatud proportsioonis ostja, veebipoe ja vahendaja vahel, kuna ta võtab osa omale töö eest tasu eest. Oletame, et 90% kogusummast läheb müüjale, 5% vahendajale ja 5% hüvitis ostjale. Vahendaja allkirjastab selle tehingu oma võtmega, kuid seda ei saa veel rakendada, sest selleks on vaja kahte allkirja, kuid ainult üks on seda väärt. Ta saadab sellise tehingu nii ostjale kui ka müüjale. Kui vähemalt üks neist on selle müntide ümberjagamise võimalusega rahul, allkirjastatakse tehing ja jagatakse see võrku. Selle kinnitamiseks piisab, kui üks tehingupool nõustub vahendaja valikuga.
Oluline on esialgu valida vahendaja, et mõlemad osalejad teda usaldaksid. Sel juhul tegutseb ta ühe või teise huvidest sõltumatult ja hindab olukorda objektiivselt. Kui vahendaja ei paku võimalust müntide jaotamiseks, mis rahuldavad vähemalt ühte osalejat, siis saavad nii ostja kui ka veebipood ühiselt kokku leppides saata mündid uuele mitmeallkirjalisele aadressile, pannes oma kaks allkirja. Uus mitme allkirjaga aadress koostatakse teise vahendajaga, kes võib olla selles asjas pädevam ja pakkuda paremat võimalust.
Näide ühiselamu ja külmkapiga
Vaatame keerukamat näidet, mis näitab nutika lepingu võimalusi selgemalt.
Oletame, et seal on kolm meest, kes kolisid hiljuti samasse ühiselamutuppa. Kolmekesi on huvi osta oma tuppa külmkapp, mida koos kasutada. Üks neist kogus vabatahtlikult külmkapi ostmiseks vajaliku summa ja pidas müüjaga läbirääkimisi. Kuid nad kohtusid alles hiljuti ja nende vahel pole piisavalt usaldust. Ilmselgelt võtavad kaks neist riski, andes kolmandale raha. Lisaks peavad nad jõudma kokkuleppele müüja valikus.
Nad saavad kasutada tingdeponeerimisteenust, st valida vahendaja, kes jälgib tehingu täitmist ja lahendab vaidlusi tekkivate probleemide korral. Seejärel, olles kokku leppinud, koostavad nad nutika lepingu ja näevad selles ette teatud tingimused.
Esimene tingimus on, et enne teatud aega, ütleme ühe nädala jooksul, peab vastav nutilepingu kontole laekuma kolm makset teatud aadressidelt teatud summa eest. Kui seda ei juhtu, lõpetab nutika lepingu täitmise ja tagastab mündid kõigile osalejatele. Kui tingimus on täidetud, siis määratakse müüja ja vahendaja tunnuste väärtused ning kontrollitakse tingimust, et kõik osalejad nõustuksid müüja ja vahendaja valikuga. Kui kõik tingimused on täidetud, kantakse raha määratud aadressidele. Selline lähenemine võib kaitsta osalejaid mis tahes poole pettuste eest ja üldiselt välistab vajaduse usaldada.
Selles näites näeme põhimõtet, et iga tingimuse täitmiseks parameetrite samm-sammult määramine võimaldab teil luua mis tahes keerukuse ja sügavusega pesastatud tasemete süsteeme. Lisaks saab esmalt defineerida nutilepingus esimese tingimuse ning alles pärast selle täitmist saab määrata järgmise tingimuse parameetrid. Teisisõnu, tingimus on formaalselt kirjutatud ja selle parameetrid saab määrata juba selle toimimise ajal.
Nutikate lepingute klassifikatsioon
Klassifitseerimiseks saate määrata erinevaid kriteeriumide rühmi. Tehnoloogia arendamise hetkel on neist aga aktuaalsed neli.
Nutikaid lepinguid saab eristada nende täitmiskeskkonna järgi, mis võib olla kas tsentraliseeritud või detsentraliseeritud. Detsentraliseerimise puhul on meil nutikate lepingute täitmisel palju suurem sõltumatus ja veataluvus.
Neid saab eristada ka tingimuste seadmise ja täitmise protsessi järgi: need võivad olla vabalt programmeeritavad, piiratud või ettemääratud, st rangelt trükitud. Kui nutika lepingu platvormil on ainult 4 konkreetset nutikat lepingut, saab nende jaoks parameetreid määrata mis tahes viisil. Sellest lähtuvalt on nende seadistamine palju lihtsam: valime loendist lepingu ja edastame parameetrid.
Algatamismeetodi järgi on olemas automatiseeritud nutikad lepingud ehk siis teatud tingimuste ilmnemisel on need isetäituvad ja on lepinguid, milles tingimused on täpsustatud, kuid platvorm ei kontrolli nende täitmist automaatselt, selleks nad tuleb algatada eraldi.
Lisaks on nutikate lepingute privaatsuse tase erinev. Need võivad olla kas täielikult avatud, osaliselt või täielikult konfidentsiaalsed. Viimane tähendab, et kolmandatest osapooltest vaatlejad ei näe nutikate lepingute tingimusi. Privaatsuse teema on aga väga lai ja parem on käsitleda seda käesolevast artiklist eraldi.
Allpool vaatleme lähemalt kolme esimest kriteeriumi, et tuua rohkem selgust praeguse teema mõistmisse.
Nutikad lepingud käitusaja järgi
Täitmiskeskkonnast lähtuvalt eristatakse tsentraliseeritud ja detsentraliseeritud nutikate lepingute platvorme. Tsentraliseeritud digilepingute puhul kasutatakse ühtset teenust, kus on ainult üks validaator ning võib olla ka varundus- ja taastamisteenus, mida hallatakse samuti tsentraalselt. Seal on üks andmebaas, mis salvestab kogu vajaliku teabe nutika lepingu tingimuste seadmiseks ja selles teenuseandmebaasis arvestatava väärtuse jaotamiseks. Sellisel tsentraliseeritud teenusel on klient, kes seab teatud päringutele tingimused ja kasutab selliseid lepinguid. Platvormi tsentraliseeritud olemuse tõttu võivad autentimismehhanismid olla vähem turvalised kui krüptovaluutadel.
Näitena võime võtta mobiilside pakkujad (erinevad mobiilioperaatorid). Oletame, et teatud operaator peab oma serverites tsentraliseeritud liikluse arvestust, mida saab edastada erinevates vormingutes, näiteks: kõnede, SMS-ide edastamise, mobiilse interneti liikluse ja erinevate standardite järgi, ning peab ka arvestust. kasutajate saldodel olevatest vahenditest. Sellest lähtuvalt saab mobiilsideteenuse pakkuja koostada erinevate tingimustega lepingud osutatavate teenuste ja nende tasumise arvestamiseks. Sel juhul on lihtne seada tingimusi nagu "saatke sellise ja sellise koodiga SMS sellisele ja sellisele numbrile ja saate liiklusjaotuse jaoks sellised ja sellised tingimused."
Võib tuua veel ühe näite: traditsioonilised pangad, millel on laiendatud internetipanga funktsionaalsus ja väga lihtsad lepingud nagu tavamaksed, laekuvate maksete automaatne konverteerimine, intresside automaatne mahaarvamine määratud kontole jne.
Kui me räägime nutikatest lepingutest koos detsentraliseeritud täitmiskeskkonnaga, siis meil on rühm validaatoreid. Ideaalis võib valideerijaks saada igaüks. Tänu andmebaasi sünkroonimisprotokollile ja konsensuse saavutamisele on meil mingi ühine andmebaas, mis talletab nüüd kõik rangelt kirjeldatud lepingutega tehingud, mitte aga mingid tingimuslikud päringud, mille vormingud sageli muutuvad ja avatud spetsifikatsiooni pole. Siin sisaldavad tehingud juhiseid lepingu täitmiseks vastavalt rangele spetsifikatsioonile. See spetsifikatsioon on avatud ja seetõttu saavad platvormi kasutajad ise nutikaid lepinguid auditeerida ja kinnitada. Siin näeme, et detsentraliseeritud platvormid on sõltumatuse ja tõrketaluvuse poolest tsentraliseeritud platvormidest paremad, kuid nende disain ja hooldus on palju keerukamad.
Targad lepingud tingimuste seadmise ja täitmise meetodil
Vaatame nüüd lähemalt, kuidas nutikad lepingud võivad tingimuste kehtestamise ja täitmise poolest erineda. Siin pöörame tähelepanu nutikatele lepingutele, mis on juhuslikult programmeeritavad ja Turingi valmis. Turingi täielik nutileping võimaldab teil lepingu täitmise tingimusteks seada peaaegu kõik algoritmid: kirjutustsüklid, mõned funktsioonid tõenäosuste arvutamiseks ja muu selline – kuni teie enda elektroonilise allkirja algoritmideni. Sel juhul peame silmas tõeliselt meelevaldset loogikakirjutamist.
On ka suvalisi nutikaid lepinguid, kuid mitte Turingi täielikke lepinguid. See hõlmab oma skriptiga Bitcoini ja Litecoini. See tähendab, et saate kasutada ainult teatud toiminguid mis tahes järjekorras, kuid te ei saa enam kirjutada silmuseid ja oma algoritme.
Lisaks on olemas nutika lepingu platvormid, mis rakendavad eelnevalt määratletud nutikaid lepinguid. Nende hulka kuuluvad Bitshares ja Steemit. Bitsharesil on hulk nutikaid lepinguid kauplemiseks, kontohalduseks, platvormi enda ja selle parameetrite haldamiseks. Steemit on sarnane platvorm, kuid see ei keskendu enam žetoonide väljastamisele ja kauplemisele, nagu Bitshares, vaid ajaveebi pidamisele, st salvestab ja töötleb sisu detsentraliseeritud viisil.
Turingi omavolilised lepingud hõlmavad Ethereumi platvormi ja RootStocki, mis on alles väljatöötamisel. Seetõttu peatume allpool Ethereumi nutika lepingu platvormil veidi lähemalt.
Nutikad lepingud algatamismeetodi järgi
Algatamisviisi alusel võib nutilepingud jagada ka vähemalt kahte rühma: automatiseeritud ja käsitsi (mitte automatiseeritud). Automatiseerituid iseloomustab asjaolu, et kõigi teadaolevate parameetrite ja tingimuste juures täidetakse nutikas leping täielikult automaatselt, st see ei nõua täiendavate tehingute saatmist ja iga järgneva täitmise eest täiendava vahendustasu kulutamist. Platvormil endal on kõik andmed, et arvutada, kuidas nutikas leping lõpeb. Sealne loogika ei ole meelevaldne, vaid ettemääratud ja see kõik on etteaimatav. See tähendab, et saate ette hinnata nutika lepingu täitmise keerukust, kasutada selle eest mingit pidevat vahendustasu ja kõik selle rakendamise protsessid on tõhusamad.
Vabalt programmeeritud nutikate lepingute täitmine ei ole automatiseeritud. Sellise nutika lepingu algatamiseks tuleb sisuliselt igal sammul luua uus tehing, mis kutsub välja järgmise täitmise etapi või järgmise nutika lepingu meetodi, maksab vastava vahendustasu ja jääb ootama tehingu kinnitamist. Täitmine võib lõppeda edukalt või mitte, sest nutika lepingu kood on suvaline ja võivad ilmneda ettearvamatud hetked, nagu igavene silmus, mõne parameetri ja argumentide puudumine, käsitlemata erandid jne.
Ethereumi kontod
Ethereumi konto tüübid
Vaatame, mis tüüpi kontosid Ethereumi platvormil olla saab. Siin on ainult kahte tüüpi kontosid ja muid valikuid pole. Esimest tüüpi nimetatakse kasutajakontoks, teist tüüpi lepinguliseks kontoks. Mõelgem välja, kuidas need erinevad.
Kasutajakontot juhitakse ainult elektroonilise allkirja isikliku võtmega. Konto omanik loob oma elektroonilise allkirja võtmepaari, kasutades ECDSA (Elliptic Curve Digital Signature Algorithm) algoritmi. Selle konto olekut saavad muuta ainult selle võtmega allkirjastatud tehingud.
Nutilepingu konto jaoks on ette nähtud eraldi loogika. Seda saab juhtida ainult eelnevalt määratletud tarkvarakoodiga, mis määrab täielikult nutika lepingu käitumise: kuidas ta teatud tingimustel oma münte haldab, millise kasutaja algatusel ja millistel lisatingimustel neid münte levitatakse. Kui arendajad ei ole programmi koodis mõnda punkti ette näinud, võivad tekkida probleemid. Näiteks võib nutikas leping saada teatud oleku, milles see ei aktsepteeri ühegi kasutaja edasise täitmise algatamist. Sel juhul mündid tegelikult külmutatakse, sest nutileping ei näe ette sellest olekust väljumist.
Kuidas Ethereumis kontosid luuakse
Kasutajakonto puhul genereerib omanik ECDSA abil iseseisvalt võtmepaari. Oluline on märkida, et Ethereum kasutab elektrooniliste allkirjade jaoks täpselt sama algoritmi ja täpselt sama elliptilist kõverat nagu Bitcoin, kuid aadress arvutatakse veidi teistmoodi. Siin ei kasutata enam topelträsimise tulemust nagu Bitcoinis, vaid ühekordne räsi on varustatud funktsiooniga Keccak pikkusega 256 bitti. Saadud väärtusest lõigatakse ära kõige vähem olulised bitid, nimelt väljundi räsiväärtuse kõige vähem olulised 160 bitti. Selle tulemusena saame aadressi Ethereumis. Tegelikult võtab see 20 baiti.
Pange tähele, et Ethereumi konto identifikaator on kodeeritud hex-vormingus ilma kontrollsummat rakendamata, erinevalt Bitcoinist ja paljudest teistest süsteemidest, kus aadress kodeeritakse põhinumbrisüsteemis 58, millele on lisatud kontrollsumma. See tähendab, et Ethereumis konto identifikaatoritega töötades tuleb olla ettevaatlik: isegi üks viga identifikaatoris viib garanteeritult müntide kadumiseni.
Seal on oluline funktsioon ja see on see, et kasutajakonto üldisel andmebaasi tasemel luuakse hetkel, kui ta võtab vastu esimese sissetuleva makse.
Nutika lepingukonto loomine võtab hoopis teistsuguse lähenemise. Esialgu kirjutab üks kasutajatest nutilepingu lähtekoodi, misjärel lastakse kood läbi Ethereumi platvormile spetsiaalse kompilaatori, saades baitkoodi enda Ethereumi virtuaalmasina jaoks. Saadud baitkood paigutatakse tehingu spetsiaalsele väljale. See on sertifitseeritud algataja konto nimel. Järgmisena levitatakse seda tehingut kogu võrgus ja see asetab nutika lepingu koodi. Tehingu ja vastavalt ka lepingu täitmise vahendustasu võetakse algataja konto saldolt maha.
Iga nutikas leping sisaldab tingimata oma (selle lepingu) ehitajat. See võib olla tühi või sellel võib olla sisu. Pärast konstruktori täitmist luuakse nutika lepingu konto identifikaator, mille abil saate saata münte, helistada teatud nutika lepingu meetoditele jne.
Ethereumi tehingustruktuur
Selle selgemaks muutmiseks hakkame uurima Ethereumi tehingu struktuuri ja nutika lepingu koodi näidet.
Ethereumi tehing koosneb mitmest väljast. Esimene neist, nonce, on tehingu teatud seerianumber konto enda suhtes, mis seda levitab ja on selle autor. See on vajalik topelttehingute eristamiseks, st välistamaks juhtumit, kui sama tehingut aktsepteeritakse kaks korda. Identifikaatorit kasutades on igal tehingul kordumatu räsiväärtus.
Edasi tuleb selline väli nagu gaasi hind. See näitab hinda, millega Ethereumi baasvaluuta konverteeritakse gaasiks, millega tasutakse nutika lepingu täitmise ja virtuaalmasina ressursi eraldamise eest. Mida see tähendab?
Bitcoinis makstakse tasud otse põhivaluuta – Bitcoini enda – kaudu. See on võimalik tänu lihtsale mehhanismile nende arvutamiseks: maksame rangelt tehingus sisalduva andmemahu eest. Ethereumis on olukord keerulisem, sest tehinguandmete mahule on väga raske loota. Siin võib tehing sisaldada ka programmikoodi, mis käivitatakse virtuaalmasinas ja iga virtuaalmasina toiming võib olla erineva keerukusega. On ka toiminguid, mis eraldavad muutujate jaoks mälu. Neil on oma keerukus, millest sõltub iga toimingu eest tasumine.
Iga toimingu maksumus gaasiekvivalendis on konstantne. Seda tutvustatakse spetsiaalselt selleks, et määrata kindlaks iga toimingu pidev maksumus. Olenevalt võrgu koormusest muutub gaasi hind ehk koefitsient, mille järgi vahendustasu maksmiseks konverteeritakse baasvaluuta sellesse abiühikusse.
Ethereumi tehingul on veel üks funktsioon: baitkoodi, mida see sisaldab virtuaalses masinas täitmiseks, täidetakse seni, kuni see on lõppenud mõne tulemusega (edu või ebaõnnestumine) või kuni teatud hulk eraldatud münte saab otsa vahendustasu maksmiseks. . Just selleks, et vältida olukorda, kus mingi vea korral läksid kõik saatja kontolt saadud mündid komisjonitasuks (näiteks virtuaalmasinas algas mingi igavene tsükkel), on järgmine väli - käivitage gaas (sageli nimetatakse gaasilimiidiks) – see määrab maksimaalse müntide koguse, mille saatja on nõus teatud tehingu sooritamiseks kulutama.
Järgmine väli on nn sihtkoha aadress. See hõlmab müntide saaja aadressi või konkreetse nutika lepingu aadressi, mille meetodeid kutsutakse. Pärast seda tuleb väli väärtus, kuhu sisestatakse sihtaadressile saadetavate müntide kogus.
Järgmine on huvitav valdkond nimega andmed, kuhu mahub kogu struktuur. See ei ole eraldi väli, vaid terve struktuur, milles on määratletud virtuaalmasina kood. Siin saate paigutada suvalisi andmeid - selleks on eraldi reeglid.
Ja viimane väli on nn allkiri. See sisaldab samaaegselt nii selle tehingu autori elektroonilist allkirja kui ka avalikku võtit, millega seda allkirja kontrollitakse. Avalikust võtmest saate selle tehingu saatja konto identifikaatori, st saate süsteemis endas üheselt tuvastada saatja konto. Peamise saime teada tehingu ülesehitusest.
Solidity nutika lepingu koodi näide
Vaatame nüüd näite varal kõige lihtsamat nutikat lepingut lähemalt.
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 lihtsustatud lähtekood, mis võib hoida kasutajate münte ja neid nõudmisel tagastada.
Niisiis, on olemas Panga nutileping, mis täidab järgmisi funktsioone: kogub oma saldole münte, st kui tehing kinnitatakse ja selline nutikas leping sõlmitakse, luuakse uus konto, mis võib oma saldole sisaldada münte; see jätab meelde kasutajad ja nendevahelise müntide jaotuse; omab mitmeid meetodeid saldode haldamiseks, st on võimalik täiendada, välja võtta ja kontrollida kasutaja saldot.
Vaatame läbi iga lähtekoodi rea. Sellel lepingul on püsivad väljad. Ühte neist nimetatakse aadressiga omanikuks. Siin jätab leping meelde selle nutika lepingu loonud kasutaja aadressi. Lisaks on olemas dünaamiline struktuur, mis säilitab vastavuse kasutajaaadresside ja saldode vahel.
Sellele järgneb Panga meetod – sellel on lepinguga sama nimi. Järelikult on see selle konstruktor. Siin määratakse omaniku muutujale selle nutika lepingu võrku paigutanud inimese aadress. See on ainus asi, mis selles konstruktoris juhtub. See tähendab, et msg on antud juhul täpselt need andmed, mis virtuaalmasinasse edastati koos tehinguga, mis sisaldab kogu selle lepingu koodi. Sellest lähtuvalt on msg.sender selle koodi hostiva tehingu autor. Temast saab nutika lepingu omanik.
Sissemakse meetod võimaldab tehinguga kanda lepingukontole teatud arvu münte. Sel juhul jätab nutileping need mündid vastu võttes need oma bilanssi, kuid märgib saldode struktuuri, kes täpselt oli nende müntide saatja, et teada saada, kellele need kuuluvad.
Järgmist meetodit nimetatakse väljamaksmiseks ja see võtab ühe parameetri - müntide koguse, mida keegi soovib sellest pangast välja võtta. See kontrollib, kas kasutaja saldos on piisavalt münte, kes helistab sellele meetodile nende saatmiseks. Kui neid on piisavalt, siis nutileping ise tagastab helistajale selle arvu münte.
Järgmisena tuleb kasutaja hetkeseisu kontrollimise meetod. Kes selle meetodi välja kutsub, seda kasutatakse selle saldo leidmiseks nutikas lepingus. Väärib märkimist, et selle meetodi modifikaatoriks on vaade. See tähendab, et meetod ise ei muuda oma klassi muutujaid mitte kuidagi ja see on tegelikult ainult lugemismeetod. Selle meetodi väljakutsumiseks eraldi tehingut ei tehta, tasu ei maksta ning kõik arvutused tehakse kohapeal, misjärel saab kasutaja tulemuse.
Tapmismeetodit on vaja nutika lepingu oleku hävitamiseks. Ja siin on täiendav kontroll, kas selle meetodi helistaja on selle lepingu omanik. Kui jah, siis leping hävib ise ja hävitamise funktsioon võtab ühe parameetri - konto identifikaatori, kuhu leping saadab kõik saldole jäänud mündid. Sel juhul lähevad ülejäänud mündid automaatselt lepingu omaniku aadressile.
Kuidas Ethereumi võrgu täissõlm töötab?
Vaatame skemaatiliselt, kuidas Ethereumi platvormil selliseid nutikaid lepinguid täidetakse ja kuidas töötab täisvõrgu sõlm.
Ethereumi võrgu täissõlmel peab olema vähemalt neli moodulit.
Esimene, nagu iga detsentraliseeritud protokolli puhul, on P2P võrgumoodul - võrguühenduse ja teiste sõlmedega töötamise moodul, kus vahetatakse plokke, tehinguid ja teavet teiste sõlmede kohta. See on kõigi detsentraliseeritud krüptovaluutade traditsiooniline komponent.
Järgmiseks on meil moodul plokiahela andmete salvestamiseks, töötlemiseks, prioriteetse haru valimiseks, plokkide lisamiseks, plokkide lahtiühendamiseks, nende plokkide valideerimiseks jne.
Kolmas moodul kannab nime EVM (Ethereumi virtuaalmasin) – see on virtuaalmasin, mis saab Ethereumi tehingutest baitkoodi. See moodul võtab konkreetse konto praeguse oleku ja muudab selle olekut vastuvõetud baitkoodi põhjal. Virtuaalse masina versioon peab igas võrgusõlmes olema sama. Igas Ethereumi sõlmes toimuvad arvutused on täpselt samad, kuid need toimuvad asünkroonselt: keegi kontrollib ja aktsepteerib seda tehingut varem, st täidab kogu selles sisalduva koodi ja keegi hiljem. Vastavalt sellele, kui tehing luuakse, jagatakse see võrku, sõlmed aktsepteerivad seda ja kontrollimise ajal, samamoodi nagu Bitcoin Scripti Bitcoinis, täidetakse siin virtuaalmasina baitkood.
Tehing loetakse kinnitatuks, kui kogu selles sisalduv kood on täidetud, teatud konto uus olek on genereeritud ja salvestatud seni, kuni on selge, kas seda tehingut on rakendatud või mitte. Kui tehing rakendatakse, loetakse see olek mitte ainult lõpetatuks, vaid ka praeguseks. Seal on andmebaas, mis salvestab iga võrgusõlme iga konto oleku. Kuna kõik arvutused toimuvad ühtemoodi ja plokiahela olek on sama, on ka kõigi kontode olekuid sisaldav andmebaas iga sõlme jaoks sama.
Nutikate lepingute müüdid ja piirangud
Mis puudutab piiranguid, mis kehtivad Ethereumiga sarnaste nutikate lepinguplatvormide jaoks, siis võib viidata järgmisele:
- koodi täitmine;
- eraldada mälu;
- plokiahela andmed;
- saata makseid;
- luua uus leping;
- helista teistele lepingutele.
Vaatame virtuaalmasinale kehtestatud piiranguid ja lükkame seega ümber mõned müüdid nutikate lepingute kohta. Virtuaalses masinas, mis võib olla mitte ainult Ethereumis, vaid ka sarnastel platvormidel, saate teha tõeliselt suvalisi loogilisi toiminguid, st kirjutada koodi ja see käivitatakse seal, saate täiendavalt eraldada mälu. Tasu makstakse aga iga toimingu ja iga täiendava eraldatud mäluühiku eest eraldi.
Järgmisena saab virtuaalmasin lugeda andmeid plokiahela andmebaasist, et kasutada neid andmeid ühe või teise nutika lepingu loogika käivitamiseks. Virtuaalmasin saab luua ja saata tehinguid, sellega saab luua uusi lepinguid ja teiste nutikate lepingute kõnemeetodeid, mis on juba võrgus avaldatud: olemasolevad, saadaolevad jne.
Kõige levinum müüt on see, et Ethereumi nutikad lepingud võivad oma tingimustes kasutada teavet mis tahes Interneti-ressursist. Tõde on see, et virtuaalmasin ei saa saata võrgupäringut mõnele välisele Interneti-inforessursile, see tähendab, et pole võimalik kirjutada nutikat lepingut, mis jagaks väärtust kasutajate vahel sõltuvalt näiteks sellest, milline on väljas ilm. või kes võitis mõne meistritiitli või selle põhjal, mis muu intsident välismaailmas juhtus, sest infot nende juhtumite kohta lihtsalt pole platvormi enda andmebaasis. See tähendab, et plokiahelas pole selle kohta midagi. Kui seda seal ei kuvata, ei saa virtuaalmasin neid andmeid käivitajatena kasutada.
Ethereumi puudused
Loetleme peamised. Esimene puudus on see, et nutikate lepingute kujundamisel, arendamisel ja testimisel Ethereumis on mõningaid raskusi (Ethereum kasutab nutikate lepingute kirjutamiseks keelt Solidity). Tõepoolest, praktika näitab, et väga suur protsent kõigist vigadest kuulub inimfaktorile. See kehtib tegelikult juba kirjutatud Ethereumi nutikate lepingute kohta, mis on keskmise või suurema keerukusega. Kui lihtsate nutikate lepingute puhul on vea tõenäosus väike, siis keeruliste nutikate lepingute puhul esineb väga sageli vigu, mis toovad kaasa rahaliste vahendite varguse, nende külmutamise, nutikate lepingute ootamatul viisil hävimise jne. Paljud sellised juhtumid on juba teatud.
Teine miinus on see, et virtuaalmasin ise pole täiuslik, kuna see on ka inimeste kirjutatud. See võib täita suvalisi käske ja selles peitub haavatavus: mitmeid käske saab teatud viisil konfigureerida, mis toob kaasa ettenägematud tagajärjed. See on väga keeruline valdkond, kuid juba on tehtud mitmeid uuringuid, mis näitavad, et need haavatavused on Ethereumi võrgu praeguses versioonis olemas ja need võivad viia paljude nutikate lepingute ebaõnnestumiseni.
Teine suur raskus, seda võib pidada puuduseks. See seisneb selles, et praktiliselt või tehniliselt võib jõuda järeldusele, et kui koostada virtuaalmasinas täidetava lepingu baitkood, saab määrata mingi konkreetse toimingute järjekorra. Koos tehes koormavad need toimingud virtuaalmasinat oluliselt ja aeglustavad seda ebaproportsionaalselt võrreldes nende toimingute eest makstud tasuga.
Varem oli Ethereumi arendamisel juba periood, mil paljud virtuaalmasina toimimist üksikasjalikult mõistnud tüübid leidsid sellised haavatavused. Tegelikult maksid tehingud väga väikese tasu, kuid pidurdasid praktiliselt kogu võrku. Neid probleeme on väga raske lahendada, kuna esiteks on vaja need kindlaks määrata, teiseks kohandada nende toimingute hind ja kolmandaks läbi viia kõva hark, mis tähendab kõigi võrgusõlmede värskendamist uuele versioonile. tarkvara ja seejärel nende muudatuste samaaegne aktiveerimine.
Ethereumi osas on tehtud palju uuringuid, saadud palju praktilisi kogemusi: nii positiivseid kui ka negatiivseid, kuid sellegipoolest on jäänud raskusi ja nõrkusi, millega tuleb siiski kuidagi toime tulla.
Niisiis, artikli temaatiline osa on lõpetatud, jätkame üsna sageli tekkivate küsimustega.
KKK
— Kui kõik olemasoleva nutika lepingu osapooled soovivad tingimusi muuta, kas nad saavad selle nutika lepingu multisigi abil tühistada ja seejärel luua uue nutika lepingu koos selle uuendatud täitmise tingimustega?
Siin on vastus kahetine. Miks? Sest ühest küljest on tark leping defineeritud üks kord ja see ei too enam kaasa mingeid muudatusi, teisalt võib sellel olla eelnevalt kirjutatud loogika, mis näeb ette mõne tingimuse täieliku või osalise muutmise. See tähendab, et kui soovite oma nutilepingus midagi muuta, siis peate ette kirjutama tingimused, mille alusel saate neid tingimusi uuendada. Sellest lähtuvalt saab lepingu uuendamist korraldada ainult nii heaperemehelikult. Kuid ka siin võite sattuda hätta: tehke mõni viga ja saate vastava haavatavuse. Seetõttu peavad sellised asjad olema väga üksikasjalikud ning hoolikalt kavandatud ja testitud.
— Mis saab siis, kui vahendaja sõlmib lepingu ühe osapoolega: tingdeponeerimis- või nutika lepinguga? Kas nutikas lepingus on vaja vahendajat?
Nutilepingus pole vahendajat vaja. Seda ei pruugi eksisteerida. Kui tingdeponeerimise puhul sõlmib lepitaja ühe osapoolega vandenõu, siis jah, see skeem kaotab siis järsult kogu oma väärtuse. Seetõttu valitakse vahendajad nii, et neid usaldaksid korraga kõik selles protsessis osalevad osapooled. Seetõttu ei kanna te lihtsalt münte mitme allkirjaga aadressile vahendajaga, mida te ei usalda.
— Kas ühe Ethereumi tehinguga on võimalik kanda oma aadressilt palju erinevaid žetoone erinevatele sihtaadressidele, näiteks vahetusaadressidele, kus nende žetoonidega kaubeldakse?
See on hea küsimus ja puudutab Ethereumi tehingumudelit ja selle erinevust Bitcoini mudelist. Ja erinevus on radikaalne. Kui Ethereumi tehingumudelis kannate münte lihtsalt üle, siis kantakse need ainult ühelt aadressilt teisele, ilma muudatusteta, vaid teie määratud konkreetne summa. Teisisõnu, see ei ole kulutamata väljundite mudel (UTXO), vaid kontode ja vastavate saldode mudel. Teoreetiliselt on võimalik saata ühe tehinguga mitu erinevat žetoonit korraga, kui kirjutad kavala nutika lepingu, kuid sul tuleb ikkagi teha palju tehinguid, sõlmida leping, seejärel tokenid ja mündid sinna üle kanda ning siis sobiv meetod välja kutsuda. . See nõuab pingutust ja aega, nii et praktikas see nii ei tööta ja kõik Ethereumi maksed tehakse eraldi tehingutena.
— Üks Ethereumi platvormi puudutav müüt on see, et välise Interneti-ressursi andmetest sõltuvaid tingimusi on võimatu kirjeldada, mida siis teha?
Lahenduseks on see, et nutikas leping ise suudab pakkuda ühte või mitut nn usaldusväärset oraaklit, mis koguvad andmeid välismaailma asjade seisu kohta ja edastavad need spetsiaalsete meetodite abil nutilepingutele. Leping ise loeb usaldusväärsetelt isikutelt saadud andmeid tõeseks. Suurema usaldusväärsuse huvides valige lihtsalt suur oraaklite rühm ja minimeerige nende kokkumängu oht. Leping ise ei pruugi võtta arvesse enamusega vastuolus olevaid oraaklite andmeid.
Üks Blockchaini veebikursuse loengutest on pühendatud sellele teemale - “".
Allikas: www.habr.com