Ievads viedajos līgumos

Šajā rakstā mēs aplūkosim, kas ir viedie līgumi, kādi tie var būt, iepazīsimies ar dažādām viedo līgumu platformām, to īpatnībām, kā arī apspriedīsim, kā tie darbojas un kādas priekšrocības tie var piedāvāt. Šis materiāls būs ļoti noderīgs lasītājiem, kuri nav pietiekami labi iepazinušies ar viedo līgumu tēmu, bet vēlas tuvoties tās izpratnei.

Parastais līgums vs. viedais līgums

Pirms mēs iedziļināmies detaļās, aplūkosim piemēru, lai saprastu atšķirību starp parasto līgumu, kas ir rakstīts uz papīra, un viedo līgumu, kas tiek attēlots digitālā formātā.

Kā tas darbojās pirms viedo līgumu parādīšanās? Iedomājieties grupu cilvēku, kuri vēlas noteikt noteiktus noteikumus un apstākļus vērtību sadalei, kā arī nodrošināt to izpildi saskaņā ar noteiktiem noteikumiem un apstākļiem. Viņi sapulcējās kopā, sastādīja dokumentu, kurā ierakstīja savus identifikācijas datus, apstākļus, iesaistītās vērtības, uzlika datumu un parakstījās. Šo līgumu arī apstiprināja uzticama puse, piemēram, notārs. Pēc tam šie cilvēki devās katrs savu ceļu ar papīra kopiju šī līguma un sāka veikt kādas darbības, kas varēja neatbilst pašam līgumam, t.i., viņi rīkojās vienā veidā, kamēr uz papīra bija apstiprināts, ka viņiem jādara pilnīgi pretēji. Un kā izkļūt no šīs situācijas? Faktiski kādam no grupas dalībniekiem bija jāņem šī papīra kopija, jāiegūst kaut kādi pierādījumi, jānes tie uz tiesu un jādara viss, lai panāktu atbilstību starp līgumu un reālajām darbībām. Samērā bieži būt taisnīgi izpildīt šo līgumu ir grūti, kas noved pie nepatīkamām sekām.

Ko var teikt par viedajiem līgumiem? Tie apvieno sevī gan iespēju uzrakstīt līguma noteikumus, gan mehānismu to stingrai izpildei. Ja noteikumi ir noteikti un attiecīgais darījums vai pieprasījums ir parakstīts, tad pēc šī pieprasījuma vai darījuma pieņemšanas vairs nav iespējams mainīt noteikumus vai ietekmēt to izpildi.

Pastāv viens validētājs vai visa tīkla, kā arī datu bāze, kas glabā visus viedo līgumu izpildes datus stingrā hronoloģiskā secībā. Vēl svarīgi, ka šai datu bāzei jāietver visi nosacījumi-trigeri viedo līgumu izpildei. Turklāt tai jāņem vērā tā vērtība, kuras sadalījums aprakstīts līgumā. Ja tas attiecas uz kādu digitālo valūtu, tad šai datu bāzei jāņem vērā tās vienības.

Citiem vārdiem sakot, viedo līgumu validētājiem jābūt piekļuvei visiem datiem, ar kuriem darbojas viedais līgums. Piemēram, vienai datu bāzei jāizmanto, lai vienlaikus uzskaitītu digitālās valūtas, lietotāju bilances, lietotāju darījumus un laika zīmogus. Tādējādi viedajā līgumā nosacījums var būt lietotāja bilance noteiktā valūtā, noteikta laika iestāšanās vai faktisks konkrēta darījuma veikšana, bet ne vairāk.

Viedā līguma definīcija

Pati terminoloģija tika izdomāta pētniekam Nick Szabo un pirmo reizi tika pielietota 1994. gadā, un dokumentēta tika 1997. gadā rakstā, kas apraksta pati ideju par viedajiem līgumiem.

Viedie līgumi pieņem, ka notiek kādas automātiskas vērtības sadalīšanas izpilde, kas var būt atkarīga tikai no iepriekš noteiktiem nosacījumiem. Visvienkāršākajā variantā tas izskatās kā līgums ar stingri noteiktiem nosacījumiem, ko paraksta konkrētas puses.

Viedie līgumi ir paredzēti, lai minimizētu uzticību trešajām pusēm. Dažreiz pilnībā tiek izslēgts lēmumu pieņemšanas centrs, no kura viss ir atkarīgs. Turklāt tādiem līgumiem ir vieglāk veikt revīziju. Tas ir dažu šādas sistēmas projektēšanas iezīmju rezultāts, bet visbiežāk mēs saprotam zem viedā līguma decentralizētu vidi un funkcijas, kas ļauj ikvienam analizēt datu bāzi un veikt pilnu līgumu izpildes revīziju. Tādējādi tiek garantēta aizsardzība pret datu izmaiņām retrospektīvi, kas radītu izmaiņas paša līguma izpildē. Lielākās daļas procesu digitalizācija viedo līgumu izveidē un palaišanā bieži vien atvieglo tehnoloģiju un to realizācijas izmaksas.

Vienkāršs piemērs — Escrow pakalpojums

Apskatīsim ļoti vienkāršu piemēru. Tas palīdzēs tuvoties izpratnei par viedlīgumu funkcionalitāti, kā arī labāk orientēties, kad tos ir lietderīgi piemērot.

To var īstenot arī, izmantojot Bitcoin, lai gan pašlaik Bitcoin vēl grūti saukt par pilnvērtīgu platformu viedlīgumiem. Tātad, mums ir pircējs un ir interneta veikals. Pircējs vēlas iegādāties monitoru šajā veikalā. Visvienkāršākajā gadījumā pircējs noformē un nosūta maksājumu, bet interneta veikals to pieņem, apstiprina, pēc tam nosūta preci. Tomēr šajā situācijā nepieciešams liels uzticības līmenis — pircējs visai monitoru vērtībai uzticas interneta veikaliem. Ņemot vērā, ka interneta veikalai var būt zema reputācija pircēja acīs, pastāv risks, ka kādu iemeslu dēļ, pēc maksājuma pieņemšanas, veikals atsakās no apkalpošanas un nesūta preci pircējam. Tāpēc pircējs uzdod jautājumu (tādā pašā veidā to dara arī interneta veikals), ko varētu piemērot, lai minimizētu šādus riskus un padarītu šīs darījumus drošākus.

Attiecībā uz Bitcoin var nodrošināt iespēju pircējam un pārdevējam neatkarīgi viens no otra izvēlēties mediātoru. Ir daudz cilvēku, kas nodarbojas ar strīdu risināšanu. Un mūsu dalībnieki var izvēlēties kādu no kopējā mediātoru saraksta, kam viņi vienlaikus uzticas. Kopā viņi izveido 2 no 3 multisig adresi, kurai ir trīs atslēgas, un ir nepieciešamas divas paraksti, izmantojot jebkuras divas atslēgas, lai tērētu monētas no šīs adreses. Viena atslēga piederēs pircējam, otra — interneta veikalam, bet trešā — mediātoram. Un uz šādu multisig adresi pircējs nosūtīs summu, kas nepieciešama monitora apmaksai. Tagad, kad pārdevējs redz, ka nauda uz kādu laiku ir bloķēta multisig adresē, kas atkarīga no viņa, viņš var droši nosūtīt monitoru pa Pastu.

Pēc tam pircējs saņem sūtījumu, apskata preces un pieņem lēmumu par galīgo pirkumu. Viņš var būt pilnībā apmierināts ar sniegtajiem pakalpojumiem un parakstīt darījumu ar savu atslēgu, kurā viņš pārsūta monētas no multisignature adreses pārdevējam, vai arī viņš var būt neapmierināts. Otrajā gadījumā viņš sazinās ar mediatoru, lai izveidotu alternatīvu darījumu, kas citādi sadalīs šīs monētas.

Pieņemsim, ka monitors ieradās nedaudz skrāpēts, un komplektā nebija kabelis datora pieslēgšanai, lai gan interneta veikala mājas lapā bija teikts, ka kabelis vajadzēja būt iekļauts komplektā. Tad pircējs apkopo pierādījumus, kas nepieciešami, lai pierādītu mediatoram, ka viņu šajā situācijā apmānījusi: viņš uzņem ekrānuzņēmumus no tīmekļa vietnes, uzņem fotografiju no čekiem no pasta, uzņem fotografiju par skrāpējumiem uz monitora un parāda, ka zīmogs bija pārgriezts un kabelis izņemts. Interneta veikals savukārt apkopo savus pierādījumus un nosūta tos mediatoram.

Mediators ir ieinteresēts apmierināt gan pircēja neapmierinātību, gan interneta veikala intereses (vēlāk tiks skaidrots, kāpēc). Viņš izveido tādu darījumu, kurā monētas no multisignature adreses tiks tērētas noteiktā proporcijā starp pircēju, interneta veikalu un mediatoru, jo viņš ņem sev daļu kā atlīdzību par savu darbu. Pieņemsim, 90% no kopējās summas dosies pārdevējam, 5% mediatoram un 5% kompensācijai pircējam. Šo darījumu mediators paraksta ar savu atslēgu, taču tas vēl nevar tikt piemērots, jo tam nepieciešamas divas paraksti, bet ir tikai viens. Šādu darījumu viņš nosūta gan pircējam, gan pārdevējam. Ja vismaz viens no viņiem būs apmierināts ar šo monētu pārdali, darījums tiks parakstīts un izplatīts tīklā. Lai to validētu, pietiek, lai viens no darījuma dalībniekiem piekristu mediatora piedāvātajam variantam.

Svarīgi ir sākotnēji izvēlēties mediatoru, kuram abi dalībnieki uzticas. Šādā gadījumā viņš darbosies neatkarīgi no viena vai otra interesēm un objektīvi novērtēs situāciju. Ja mediators nesniedz tādu monētu sadales variantu, kas apmierina vismaz vienu dalībnieku, tad, vienojoties kopā, gan pircējs, gan interneta veikals var pārsūtīt monētas uz jaunu multisignature adresi, pieliekot savas divas parakstus. Jaunā multisignature adrese tiks izveidota ar citu mediatoru, kurš, iespējams, būs zinošāks šajā jautājumā un piedāvās labāku variantu.

Piemērs ar kopmītnēm un ledusskapi

Apskatīsim sarežģītāku piemēru, kas skaidrāk parāda viedoklīgo līgumu iespējas.

Pieņemsim, ka ir trīs puikas, kuri nesen apmetās vienā istabā kopmītnē. Viņi visi trīs vēlas iegādāties ledusskapi savā istabā, ko tie izmantos kopīgi. Viens no viņiem piedāvājās savākt nepieciešamo summu ledusskapja iegādei un sarunāties ar pārdevēju. Tomēr viņi attiecīgi nesen iepazinās un starp viņiem nav pietiekama uzticības. Acīmredzami divi no viņiem riskē, nododot naudu trešajam. Turklāt viņiem ir jāvienojas par pārdevēja izvēli.

Viņi var izmantot escrow pakalpojumu, tas ir, izvēlēties mediatoru, kurš uzraudzīs darījuma izpildi un risinās strīdīgos jautājumus, ja tādi rastos. Tad, vienojoties, viņi sastāda viedoklīgo līgumu un uzraksta tajā noteiktus nosacījumus.

Pirmais nosacījums ir tāds, ka līdz noteiktam laikam, teiksim, nedēļas laikā, attiecīgajā viedajā līgumā ir jāsaņem trīs maksājumi no noteiktiem adresēm par noteiktu summu. Ja tas nenotiek, vieds līgums pārtrauc izpildi un atgriež monētas visiem dalībniekiem. Ja nosacījums tiek izpildīts, tad tiek norādītas pārdevēja un starpnieka identifikācijas vērtības, kā arī tiek pārbaudīts nosacījums, ka visi dalībnieki piekrīt pārdevēja un starpnieka izvēlei. Kad visi nosacījumi tiks izpildīti, līdzekļi tiks pārsūtīti uz norādītajām adresēm. Šāda pieeja var aizsargāt dalībniekus no krāpniecības no jebkuras puses un pilnībā izslēdz nepieciešamību uzticēties.

Mēs redzam šajā piemērā pašu principu, ka šāda iespēja pakāpeniski definēt parametrus katra nosacījuma izpildei ļauj radīt sistēmas jebkādā sarežģītībā un dziļuma līmeņos. Turklāt vispirms viedajā līgumā var noteikt pirmo nosacījumu, un tikai pēc tā izpildes var noteikt parametrus nākamajam nosacījumam. Citiem vārdiem sakot, formāli nosacījums tiek definēts, bet tā parametri var tikt noteikti jau tās izpildes laikā.

Viedo līgumu klasifikācija

Klasifikācijai var noteikt dažādas kriteriju grupas. Tomēr šobrīd tehnoloģiju attīstības posmā aktuālas ir četras no tām.

Viedos līgumus var atšķirt pēc izpildes vides, kas var būt vai nu centralizēta, vai decentralizēta. Decentralizācijas gadījumā mums ir daudz lielāka neatkarība un avārijas noturība viedo līgumu izpildē.

Tie arī var tikt atšķirti pēc nosacījumu definēšanas un izpildes procesa: tie var būt brīvi programmēti, ierobežoti vai iepriekš noteikti, t.i., stingri tipizēti. Kad viedo līgumu platformā pastāv tikai 4 noteikti viedie līgumi, parametrus tiem var definēt brīvi. Attiecīgi, tos ir daudz vieglāk definēt: mēs izvēlamies līgumu no saraksta un nododam parametrus.

Ir automatizēti viedie līgumi, t.i., tie izpildās paši par sevi, kad iestājas noteikti nosacījumi, kā arī pastāv līgumi, kuros nosacījumi ir noteikti, bet platforma automātiski nesoca to izpildi; tādā gadījumā tie ir jāuzsāk atsevišķi.

Turklāt viedie līgumi atšķiras pēc privātuma līmeņa. Tie var būt pilnībā atklāti, daļēji atklāti vai pilnībā konfidenciāli. Pēdējais nozīmē to, ka trešās puses novērotāji neredz viedo līgumu nosacījumus. Tomēr privātuma tēma ir ļoti plaša un to labāk izskatīt atsevišķi no šā raksta.

Zemāk mēs sīkāk apskatīsim pirmos trīs kritērijus, lai pievienotu lielāku skaidrību pašreizējai tēmai.

Viedie līgumi pēc izpildes vides

Pēc izpildes vides pastāv centralizētas un decentralizētas viedo līgumu platformas. Centralizētu digitālo līgumu gadījumā tiek izmantota viena pakalpojuma, kurā ir tikai viens validētājs, un var būt centralizēti pārvaldīta rezerves un atjaunošanas pakalpojums. Ir viena datu bāze, kas glabā visu nepieciešamo informāciju viedo līgumu nosacījumu noteikšanai un vērtības sadalei, kas tiek ņemta vērā šajā pakalpojuma datu bāzē. Šādam centralizētam pakalpojumam ir klients, kurš ar noteiktiem pieprasījumiem nosaka nosacījumus un izmanto šādus līgumus. Tā kā platforma ir centralizēta, autentifikācijas mehānismi var būt mazāk droši nekā kriptovalūtās.

Kā piemēru var minēt mobilo sakaru pakalpojumu sniedzējus (dažādus mobilo operatorus). Pieņemot, ka noteikts operators centralizētā veidā uz saviem serveriem uzskaita trafiku, kas var tikt pārsūtīts dažādos formātos, piemēram: balss zvanu formā, SMS pārsūtīšanas veidā, mobilā interneta trafika veidā, un atbilstoši dažādiem standartiem, un uzskaita līdzekļus lietotāju bilancēs. Tādējādi mobilo sakaru operators var izstrādāt līgumus par sniegtajām pakalpojumu uzskaiti un to apmaksu ar dažādiem nosacījumiem. Šādā gadījumā viegli tiek noteikti nosacījumi, piemēram, “nosūti SMS ar tādu kodu uz tādu numuru un saņem šādus trafika sadales nosacījumus.”

Var arī cits piemērs: tradicionālās bankas ar paplašinātām interneta banku funkcijām un ļoti vienkāršas līgumus, piemēram, regulāros maksājumus, automātisko ienākošo maksājumu konvertēšanu, automātisko procentu pārskaitīšanu uz norādīto kontu utt.

Ja runājam par viedo līgumiem decentralizētā izpildes vidē, tad mums ir validaatori. Ideālā gadījumā validaatoram var kļūt ikviens. Protokola dēļ, kas sinhronizē datu bāzi un sasniedz konsensu, mums ir viena kopīga datu bāze, kas tagad uzglabās visas transakcijas ar stingri aprakstītiem līgumiem, nevis kādiem noteiktiem pieprasījumiem, kuru formāti bieži mainās un nav atklātu specifikāciju. Šeit transakcijām būs instrukcijas līguma izpildei saskaņā ar stingro specifikāciju. Šī specifikācija ir atklāta un, līdz ar to, pati platformas lietotāji var veikt auditu un validēt viedos līgumus. Šeit redzam, ka decentralizētās platformas pārsniedz centralizētās neatkarības un atteices izturības ziņā, bet to projektēšana un uzturēšana ir daudz sarežģītāka.

Viedie līgumi pēc nosacījumu noteikšanas un izpildes veida

Tagad aplūkosim detalizētāk, kā viedie līgumi var atšķirties pēc nosacījumu noteikšanas un izpildes veida. Šeit pievērsīsim uzmanību viedajiem līgumiem, kas programmējami brīvi un ir Tjūringa pilnībā. Tjūringa pilns viedais līgums ļauj noteikt praktiski visus algoritmus kā līguma izpildes nosacījumu: rakstīt ciklus, kādas funkcijas varbūtību aprēķināšanai un tamlīdzīgi — līdz pat saviem elektroniskās paraksta algoritmiem. Šajā gadījumā ir runa par tiešām brīvām loģikas rakstīšanu.

Tiek izdalīti arī brīvi viedie līgumi, bet ne Tjūringa pilnībā. Šeit var iekļaut Bitcoin un Litecoin ar savu skriptu. Tas nozīmē, ka var izmantot tikai noteiktas operācijas, bet jau nevar rakstīt ciklus un savus algoritmus.

Turklāt ir tādas viedo līgumu platformas, kas īsteno iepriekš noteiktus viedos līgumus. Tām pieder Bitshares un Steemit. Bitshares ir plašs viedo līgumu klāsts tirdzniecībai, kontu pārvaldībai, paša platformas un tās parametrus pārvaldībai. Steemit ir līdzīga platforma, taču tā ir orientēta nevis uz tokenu izdošanu un tirdzniecību, kā Bitshares, bet gan uz emuāru veidošanu, proti, tā uzglabā un apstrādā saturu decentralizētā veidā.

Uz universāliem Tjūringas pilnajiem līgumiem attiecas Ethereum platforma un RootStock, kas vēl ir izstrādes stadijā. Tādēļ mēs turpināsim ar detalizētāku skatījumu uz Ethereum viedo līgumu platformu.

Viedie līgumi pēc iniciācijas veida

Viedos līgumus pēc iniciācijas veida var iedalīt vismaz divās grupās: automatizētajos un manuālajos (ne automatizētajos). Automatizētajiem ir raksturīgi, ka, zinot visus parametrus un iestājušos apstākļus, vieds līgums pilnībā izpildās automātiski, tas ir, neprasa papildu darījumus vai papildus komisijas maksājumus katram nākamajam izpildes ciklam. Pašai platformai ir visi dati, lai aprēķinātu, kādā veidā vieds līgums tiks pabeigts. Loģika tur nav nejauša, bet iepriekš noteikta, un viss tas ir paredzams. Tas nozīmē, ka iepriekš var novērtēt viedo līgumu izpildes sarežģītību, izmantot kādu konstantu komisiju tam, un visi procesi tā izpildē tiek veikti efektīvāk.

Viedajiem līgumiem, kurus programmē brīvi, izpilde nav automatizēta. Lai iniciētu tādu viedo līgumu, faktiski katrā posmā ir jāizveido jauns darījums, kas izsauks nākamo izpildes posmu vai nākamo viedā līguma metodi, jāmaksā attiecīgā komisija un jāgaida darījuma apstiprinājums. Izpilde var noslēgties ar panākumiem vai ne, jo viedā līguma kods ir brīvs un var parādīties dažādi neparedzēti faktori, piemēram, mūžīgs cikls, trūkstošu parametru un argumentu problēmas, neapstrādāti izņēmumi utt.

Konta Ethereum

Ethereum kontu tipi

Apskatīsim, kādi var būt konti Ethereum platformā. Šeit pastāv tikai divi kontu veidi, un nav nekādu citu variantu. Pirmais veids saucās lietotāja konts, otrais - līguma konts. Apskatīsim, kādas ir to atšķirības.

Lietotāja konts tiek pārvaldīts tikai ar personisko elektroniskās paraksta atslēgu. Konta īpašnieks ģenerē savu atslēgu pāri elektroniskai parakstīšanai, izmantojot ECDSA (Elliptic Curve Digital Signature Algorithm) algoritmu. Šī konta stāvokli var mainīt tikai transakcijas, kuras ir parakstījušas šīs atslēgas.

Līguma kontam ir paredzēta atsevišķa loģika. To var pārvaldīt tikai ar iepriekš noteikto programmēšanas kodu, kas pilnībā nosaka līguma uzvedību: kā tas rīkosies ar savām monētām noteiktos apstākļos, kura lietotāja iniciatīvas dēļ šīs monētas tiks izplatītas un pēc kādiem papildu nosacījumiem. Ja daži aspekti nav paredzēti izstrādātāju programmēšanas kodā, var rasties problēmas. Piemēram, līgums var sasniegt noteiktu stāvokli, kurā tas nepieņem tālākas izpildes iniciatīvu no neviena lietotāja. Šādā gadījumā monētas faktiski paliks iesaldētas, jo līgums neparedz izeju no šī stāvokļa.

Kā tiek izveidoti konti Ethereum

Attiecībā uz lietotāja kontu, īpašnieks patstāvīgi ģenerē atslēgu pāri, izmantojot ECDSA.Svarīgi atzīmēt, ka Ethereum izmanto tieši tādu pašu algoritmu elektroniskai parakstīšanai un to pašu elipsveida līkni kā Bitcoin, taču adrese tiek aprēķināta nedaudz citādi. Šeit vairs netiek izmantota dubultā vērtēšana, kā Bitcoin gadījumā, bet ir paredzēta vienkāršā vērtēšana ar Keccak funkciju 256 bitu garumā. No iegūtās vērtības tiek atgriezti pēdējie biti, proti, 160 pēdējie biti no izejas hēša funkcijas. Rezultātā mēs iegūstam adresi Ethereum. Faktiski tā aizņem 20 baitus.

Ievērosim, ka Ethereum konta identifikators tiek kodēts hex formātā bez kontroles summas izmantošanas, atšķirībā no Bitcoin un daudzām citām sistēmām, kur adreses tiek kodētas 58 pamata sistēmā, pievienojot kontroles summu. Tas nozīmē, ka ar Ethereum kontu identifikatoriem ir jārīkojas uzmanīgi: pat viena kļūda identifikatorā garantēti novedīs pie monētu zaudēšanas.

Ir svarīga iezīme, un tā ir tāda, ka lietotāja konts kopējā datubāzē tiek izveidots brīdī, kad viņš pieņem pirmo ienākošo maksājumu.

Attiecībā uz viedpirkuma veidošanu tiek izmantots pavisam cits pieejas veids. Sākotnēji kāds no lietotājiem uzraksta viedpirkuma avota kodu, pēc tam kods tiek izlaists caur specializētu Ethereum platformai paredzētu kompilētāju, iegūstot bajt-kodu, kas paredzēts Ethereum virtuālajai mašīnai. Iegūtais bajt-kods tiek ievietots īpašā transakcijas laukā. To apstiprina iniciatora konta vārdā. Pēc tam šī transakcija tiek izplatīta tīklā un izveido viedpirkuma kodu. Maksājums par transakciju un, attiecīgi, par līguma izpildi tiek ņemts no iniciatora konta bilances.

Katram viedpirkumam noteikti ir sava konstruktora funkcija (šī līguma). Tā var būt tukša vai saturēt kādu saturu. Pēc tam, kad konstrukcija tiek izpildīta, tiek izveidots viedpirkuma konta identifikators, izmantojot kuru var nosūtīt monētas, izsaukt noteiktas viedpirkuma metodes utt.

Ethereum transakcijas struktūra

Lai būtu skaidrāk, mēs sāksim aplūkot Ethereum transakcijas struktūru un viedpirkuma koda piemēru.

Ethereum transakcija sastāv no vairākiem laukiem. Pirmais no tiem 'nonce' — tas ir kāds secības numurs transakcijai attiecībā uz pašu kontu, kas to izplata un ir tās autors. Tas ir nepieciešams, lai atšķirtu transakciju dublikātus, proti, lai izslēgtu gadījumu, kad viena un tā pati transakcija tiek apstiprināta divreiz. Pateicoties identifikatora izmantošanai, katrai transakcijai ir unikāls haša vērtējums.

Tālāk ir tāds lauks kā gāzes cena. Šeit norādīta cena, par kuru pamatvalūta Ethereum tiek konvertēta gāzē, kas tiek izmantota, lai samaksātu par viedo līgumu izpildi un virtuālās mašīnas resursu piešķiršanu. Ko tas nozīmē?

Bitcoin gadījumā komisijas maksas tiek maksātas tieši ar pamatvalūtu — pašu bitkoinu. To nodrošina vienkāršs aprēķinu mehānisms: mēs maksājam precīzi par datu apjomu, kas atrodas darījumā. Ethereum situācija ir sarežģītāka, jo ir grūti balstīties tikai uz darījuma datu apjomu. Šeit darījums var saturēt arī programmēšanas kodu, kas tiks izpildīts virtuālajā mašīnā, un katra virtuālās mašīnas operācija var būt ar atšķirīgu sarežģītību. Ir arī operācijas, kas piešķir atmiņu mainīgajiem, un tām būs sava sarežģītība, no kuras būs atkarīga samaksa par katru operāciju.

Katras operācijas izmaksas gāzē būs konstantes. Tas tiek ieviests speciāli, lai noteiktu katras operācijas nemainīgas izmaksas. Atkarībā no tīkla slodzes mainīsies gāzes cena, tas ir, koeficients, saskaņā ar kuru pamatvalūta tiks konvertēta šajā palīgvienībā komisijas maksas samaksai.

Ir vēl viena iezīme darījumam Ethereum: байт-код, kas tajā ir iekļauts, tiks izpildīts līdz tam brīdim, kad tiks saņemts kāds rezultāts (veiksmīgi-naveiksmīgi) vai līdz beigsies noteikts monētu skaits, kas ir paredzēts komisijas maksai. Tieši, lai novērstu situāciju, kad sūtītāja kontā sakarā ar kādu kļūdu tiek iztērētas visas monētas komisijai (piemēram, ja virtuālajā mašīnā uzsākas bezgalīgs cikls), pastāv nākamais lauks — start gas (to bieži sauc par gāzes limitu) — tas nosaka maksimālo monētu apjomu, ko sūtītājs ir gatavs tērēt, lai veiktu noteiktu darījumu.

Nākamais lauks tiek saukts par destination address. Šeit tiek ievadīts saņēmēja monētu adrese vai konkrētā viedā līguma adrese, kuru metodes tiks izsauktas. Pēc tam seko lauks value, kurā tiek norādīta monētu summa, kas tiek nosūtīta uz destination address.

Tālāk ir interesants lauks ar nosaukumu data, kur ievēro visa struktūra. Tas nav atsevišķs lauks, bet visa struktūra, kurā tiek definēts kods virtuālajai mašīnai. Šeit var ievietot dažādus datus — tam ir noteikti noteikumi.

Un pēdējais lauks saucas signature. Tas vienlaikus satur gan darījuma autora elektronisko parakstu, gan publisko atslēgu, ar kuru tiks verificēts šis paraksts. No publiskās atslēgas var iegūt nosūtītāja konta identifikatoru šajā darījumā, proti, unikāli identificēt nosūtītāja kontu pašā sistēmā. Attiecībā uz darījuma struktūru mēs esam noskaidrojuši galveno.

Piemērs smartrakta koda uz Solidity

Tagad aplūkosim tuvāk vienkāršāko smartrakta piemēru.

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

Augstāk ir sniegts vienkāršots avota kods, kas var uzglabāt lietotāju monētas un atgriezt tās pēc pieprasījuma.

Tātad, ir smartrakts Bank, kas izpilda šādas funkcijas: tas uzkrāj uz sava bilances monētas, proti, apstiprinot darījumu un izvietojot šādu smartrakstu, tiek izveidots jauns konts, kuram var būt monētas uz bilances; tas atceras lietotājus un monētu sadalījumu starp viņiem; tam ir vairāki bilances pārvaldības metodes, t.i., ir iespēja papildināt, izņemt un pārbaudīt lietotāja bilanci.

Apskatīsim katru rindu avota kodā. Šajā kontraktā ir konstantes lauki. Viens no tiem, ar adreses tipu, saucas owner. Šeit kontrakts atceras lietotāja adresi, kurš izveidojis šo smartrakstu. Tālāk ir dinamiska struktūra, kas saglabā atbilstības starp lietotāju adresēm un bilancēm.

Pēc tam seko metode Bank — tā saucas tāpat kā kontrakts. Līdz ar to tas ir tā konstruktors. Šeit notiek mainīgā owner piešķiršana tam, kurš izvietojis šo smartrakstu tīklā. Tas ir vienīgais, kas notiek šajā konstruktorā. Proti, msg šajā izpratnē ir tie dati, kas tika nodoti virtuālajai mašīnai kopā ar darījumu, kas saturēja visu šo kontrakta kodu. Attiecīgi, msg.sender ir šī darījuma autors, kurš izvieto šo kodu. Viņš kļūs par smartrakta īpašnieku.

Deposit metode ļauj pārskaitīt noteiktu monētu skaitu uz līguma kontu. Šajā gadījumā viedais līgums, saņemot šīs monētas, atstāj tās savā bilancē, bet struktūrā balances ieraksta, kurš tieši bija šo monētu sūtītājs, lai zinātu, kam tās pieder.

Nākamais metode ir withdraw, un tam ir viens parametrs – summa monētu, ko kāds vēlas izņemt no šī bankas. Šeit tiek pārbaudīts, vai lietotāja bilancē, kas izsauc šo metodi, ir pietiekami daudz monētu, lai tās nosūtītu. Ja monētu ir pietiekami, tad pats viedais līgums atgriež izsaucējam šo monētu daudzumu.

Tālāk ir metode, kas pārbauda lietotāja pašreizējo bilanci. Tas, kurš izsauc šo metodi, tiks izmantots, lai iegūtu šo bilanci viedajā līgumā. Vērts pieminēt, ka šīs metodes modifikators ir view. Tas nozīmē, ka pati metode nemaina nekādus sava klases mainīgos un ir faktiski tikai lasīšanas metode. Atsevišķa transakcija netiek izveidota, lai izsauktu šo metodi, maksa netiek maksāta, un visi aprēķini tiek veikti lokāli, pēc tam lietotājs saņem rezultātu.

Kill metode ir nepieciešama, lai iznīcinātu viedā līguma stāvokli. Šeit ir ietverta papildu pārbaude, vai metodes izsaucējs ir šī līguma īpašnieks. Ja ir, tad līgums pašiznīcina, un iznīcināšanas funkcija pieņem vienu parametrs — konta identifikators, uz kuru līgums nosūtīs visas monētas, kas palikušas uz tā bilances. Šajā gadījumā atlikušās monētas automātiski aizies uz līguma īpašnieka adresi.

Kā darbojas pilnais Ethereum tīkla mezgls?

Apskatīsim grafiski, kā notiek šādu viedo līgumu izpilde uz Ethereum platformas un kā darbojas pilnais tīkla mezgls.

Pilnajam Ethereum tīkla mezglam vismaz jābūt četriem moduļiem.
Pirmais, kā jebkuram decentralizētam protokolam, ir P2P networking module — modulis tīkla savienojumam un darbam ar citiem mezgliem, kur notiek bloku, transakciju, informācijas apmaiņa par citiem mezgliem. Tas ir tradicionāls komponents visām decentralizētām kriptovalūtām.

Tālāk mums ir blokķēdes datu glabāšanas modulis, apstrādes, prioritārās atzara izvēles, bloku papildināšanas, bloku atsaistes, šo bloku pārbaudes utt.

Trešais modulis saucas EVM (Ethereum virtuālā mašīna) — tas ir virtuālā mašīna, kas pieņem byte kodu no Ethereum darījuma. Šis modulis pieņem konkrēta konta pašreizējo stāvokli un veic izmaiņas tā stāvoklī, pamatojoties uz saņemto byte kodu. Katram tīkla mezglam jābūt identiskai virtuālās mašīnas versijai. Aprēķini notiek katrā Ethereum mezglā absolūti vienādi, taču tie notiek asimetriski: kāds agrāk pārbauda un pieņem šo darījumu, t.i., izpilda visu tajā iekļauto kodu, bet kāds vēlāk. Atbilstoši, kad tiek izveidots darījums, tas izplatās tīklā, mezgli to pieņem un, verificējot, tieši tāpat kā Bitcoin gadījumā Bitcoin Script tiek izpildīts, šeit tiek izpildīts virtuālās mašīnas byte kods.

Darījums tiek uzskatīts par pārbaudītu, ja viss tajā iekļautais kods ir izpildīts, ir ģenerēts jauns konkrētā konta stāvoklis un saglabāts, līdz ir skaidrs, vai šis darījums ir piemērots vai nē. Ja darījums ir piemērots, tad šis stāvoklis tiek uzskatīts ne tikai par izpildītu, bet jau arī par aktuālu. Ir datubāze, kas glabā katra konta stāvokli katram tīkla mezglam. Tā kā visi aprēķini notiek vienādi un blokķēdes stāvoklis ir identisks, tad arī datubāze, kas satur visu kontu stāvokļus, būs identiska katram mezglam.

Mīti un ierobežojumi viedajiem līgumiem

Attiecībā uz ierobežojumiem, kas pastāv līdzīgām Ethereum platformām viedajiem līgumiem, var minēt sekojošos:

• koda izpilde;
• atmiņas piešķiršana;
• blokķēdes dati;
• maksājumu sūtīšana;
• jauna līguma izveide;
• citu līgumu izsaukšana.

Apskatīsim ierobežojumus, kas tiek piemēroti virtuālajai mašīnai, un attiecīgi atraisīsim dažus mītus par viedajiem līgumiem. Virtuālajā mašīnā, kas var būt ne tikai Ethereum, bet arī līdzīgās platformās, var veikt patiesi izsmeļošas loģiskās operācijas, t.i., rakstīt kodu un tas tiks izpildīts tur, var papildus piešķirt atmiņu. Tomēr maksa tiek maksāta atsevišķi par katru operāciju un par katru papildus piešķirto atmiņas apjomu.

Tālāk, virtuālā mašīna var nolasīt datus no blokķēdes datu bāzes, lai izmantotu šos datus kā trigeri konkrētas loģikas izpildei viedo līgumu ietvaros. Virtuālā mašīna var izveidot un sūtīt darījumus, tā var izveidot jaunus līgumus un izsaukt citu jau publicētu viedo līgumu metodes: tās pastāv, ir pieejamas utt.

Visbiežākais mīts ir tas, ka Ethereum viedie līgumi var izmantot informāciju no jebkuriem interneta resursiem savos noteikumos. Patiesība ir tāda, ka virtuālā mašīna nevar nosūtīt tīkla pieprasījumu kādam ārējam informācijas resursam internetā, t.i., nav iespējams uzrakstīt tādu viedo līgumu, kas sadalītu vērtību starp lietotājiem, atkarībā no tā, piemēram, kāda ir laika situācija ārā, vai kurš uzvarējis kādā čempionātā, vai pamatojoties uz to, kāds cits notikums noticis ārējā pasaulē, jo informācija par šiem notikumiem vienkārši nav blokķēdes platformas datu bāzē. Tas nozīmē, ka nekas par to blokķēnā nav. Ja tas tur neparādīsies, tad arī virtuālā mašīna nevarēs izmantot šos datus kā trigerus.

Ethereum trūkumi

Apskatīsim galvenos trūkumus. Pirmais trūkums ir saistīts ar grūtībām, projektējot, izstrādājot un testējot viedos līgumus Ethereum (Ethereum viedo līgumu rakstīšanai tiek izmantota Solidity valoda). Patiesībā prakse rāda, ka ļoti liels procents no visām kļūdām ir cilvēka faktora dēļ. Tas attiecas arī uz jau uzrakstītajiem Ethereum viedajiem līgumiem, kuriem ir vidēja vai augstāka sarežģītība. Ja vienkāršu viedo līgumu kļūdu iespējamība ir maza, tad sarežģītos viedajos līgumos ļoti bieži ir kļūdas, kas noved pie līdzekļu zādzības, to iesaldēšanas, viedo līgumu neparedzētas iznīcināšanas utt. Ir zināmi daudzi šādi gadījumi.

Otrais trūkums ir tāds, ka pati virtuālā mašīna nav ideāla, jo to arī ir rakstījuši cilvēki. Tā var izpildīt patvaļīgas komandas, un šajā slēpjas ievainojamība: ir iespējams noteikt komandu konfigurāciju, kas novedīs pie neparedzētiem rezultātiem. Tā ir ļoti sarežģīta joma, bet jau ir vairāki pētījumi, kas parāda, ka šīs ievainojamības pastāv esošajā Ethereum tīkla versijā un tās var izraisīt daudzu viedo līgumu darbības pārtraukšanu.

Vēl viena liela grūtība, ko var uzskatīt par trūkumu. Tā sastāv no tā, ka var praktiski vai tehniski nonākt pie secinājuma, ka, ja kompili sāks līguma bytecode, kas tiks izpildīts uz virtuālās mašīnas, var noteikt specifisku operāciju secību. Izpildes procesā šīs operācijas ļoti noslogos virtuālo mašīnu un ievērojami palēninās tās darbību, salīdzinot ar maksu, kas tika samaksāta par šo operāciju izpildi.

Pagātnē bija periods, kad Ethereum attīstībā daudzi speciālisti, kuri detalizēti izprata virtuālās mašīnas darbību, atklāja dažādas ievainojamības. Faktiski darījumi maksāja ļoti mazu nodevu, taču tie ievērojami palēnināja visas tīkla darbību. Šo problēmu risināšana ir ļoti sarežģīta, jo ir nepieciešams, pirmkārt, noteikt tās, otrkārt, koriģēt cenu par šo operāciju izpildi, un, treškārt, veikt hardfork, kas nozīmē visus tīkla mezglus atjaunināt uz jaunu programmatūras versiju un pēc tam vienlaicīgi aktīvi ieviest šīs izmaiņas.

Attiecībā uz Ethereum ir veikts ļoti daudz pētījumu, gūts liels praktisks pieredze: gan pozitīva, gan negatīva, tomēr joprojām paliek sarežģījumi un ievainojamības, ar kurām vēl jārīkojas.

Tātad, tēmas daļa ir pabeigta, pāriesim pie jautājumiem, kas rodas diezgan bieži.

Biežāk uzdotie jautājumi

— Ja visi aktīvā viedlīguma dalībnieki vēlas mainīt nosacījumus, vai viņi var atcelt šo viedlīgumu ar daudzparakstu un pēc tam izveidot jaunu viedlīgumu ar atjauninātajiem izpildes nosacījumiem?

Atbilde būs divējāda. Kāpēc? Tāpēc, ka no vienas puses viedlīgums tiek noteikts vienreiz un tam nav paredzētas nekādas izmaiņas, bet no otras puses tam var būt iepriekš noteikta loģika, kas paredz pilnīgas vai daļējas noteiktu nosacījumu izmaiņas. Tātad, ja jūs vēlaties kaut ko mainīt savā viedlīgumā, jums iepriekš jānosaka nosacījumi, saskaņā ar kuriem jūs varat atjaunināt šos nosacījumus. Līdz ar to tikai šādā apdomīgā veidā var organizēt līguma atjaunināšanu. Bet arī šeit var gadīties nepatikšanas: pieļaut kādu kļūdu un iegūt attiecīgu ievainojamību. Tāpēc šādas lietas ir jāprojekti ļoti detalizēti un rūpīgi jātestē.

— Un, ja mediators ir ieinteresēts ar vienu no dalībniekiem: escrow vai viedlīgumu? Vai mediators ir obligāts viedlīgumā?

Starpnieks nav obligāts viedlīguma sastāvdaļa. To var arī nepietikt. Ja gadījumā, ja escrow starpnieks noslēgs vienošanos ar vienu no pusēm, tad, jā, šis shēma tad strauji zaudē visu savu vērtību. Tāpēc starpnieki tiek izvēlēti tā, lai visām iesaistītajām pusēm tajā procesā būtu uzticama. Tātad jūs vienkārši nepārskaitīsiet monētas uz multisignature adresi pie tā starpnieka, kuram neuzticaties.

— Vai ir iespējams ar vienu Ethereum darījumu pārsūtīt daudz dažādu tokenu no sava aderes uz dažādām mērķa adresēm, piemēram, biržu adresēm, kur šie tokeni tiek tirgoti?

Tas ir labs jautājums un attiecas uz Ethereum darījumu modeli un tā atšķirību no Bitcoin modeļa. Un atšķirība ir radikāla. Ja Ethereum darījumu modelī jūs vienkārši pārskaitāt monētas, tad tās tiek pārskaitītas tikai no vienas adreses uz otru, bez atlikuma, vienkārši konkrēta summa, kuru esat norādījis. Citiem vārdiem sakot, tas nav neiztērēto izeju (UTXO) modelis, bet gan kontu modelis ar attiecīgajām bilancēm. Ar vienu darījumu nosūtīt vairākus dažādus tokenus teorētiski ir iespējams, ja uzrakstāt viltīgu viedlīgumu, taču tomēr būs jāveic daudz darījumu, jāsagatavo līgums, tad jānodod tam tokeni un monētas, pēc tam jāizsauc attiecīgā metode. Tas prasa pūles un laiku, tādēļ praksē tas tā nedarbojas, un visi maksājumi Ethereum tiek veikti atsevišķos darījumos.

— Viens no mītiem par Ethereum platformu ir tas, ka nav iespējams aprakstīt tādus nosacījumus, kas atkarīgi no datiem no ārējiem interneta resursiem, tad kā rīkoties?

Risinājums ir tāds, ka pats viedlīgums var paredzēt vienu vai vairākus tā sauktos uzticamus orakulus, kuri apkopo informāciju par ārējo pasauli un nodod to viedlīgumiem caur speciālām metodēm. Pats līgums uzskata par patiesību tos datus, kurus tas saņēmis no uzticamiem avotiem. Lielākas uzticamības nodrošināšanai vienkārši izvēlas lielāku orakulu grupu un samazina risku, ka tie varētu vienoties. Pats līgums var ignorēt orakulus, kuru dati neatbilst vairumam.

Šai tēmai ir veltīta viena no lekcijām tiešsaistes kursā par Blockchain — “Ievads viedajos līgumos”.

Avots: habr.com