În acest articol, vom explora ce sunt contractele inteligente, de ce tipuri există, vom descoperi diferitele platforme de contracte inteligente, caracteristicile acestora și vom discuta despre modul în care funcționează și despre avantajele pe care le pot aduce. Acest material va fi foarte util pentru cititorii care nu sunt suficient de familiarizați cu subiectul contractelor inteligente, dar doresc să se apropie de înțelegerea acestuia.
Contract obișnuit vs. contract inteligent
Înainte de a ne aprofunda în detalii, haideți să analizăm, printr-un exemplu, diferențele dintre un contract obișnuit, care este redactat pe hârtie, și un contract inteligent, care este reprezentat în format digital.
Cum funcționa înainte de apariția contractelor inteligente? Imaginează-ți un grup de persoane care doresc să stabilească anumite reguli și condiții pentru distribuirea valorilor și să garanteze printr-un mecanism specific respectarea acestor reguli și condiții. Atunci, se adunau, redactau un document în care își consemnam datele de identificare, condițiile, valorile implicate, puneau o dată și semnau. Acest contract era de asemenea validat de o parte de încredere, cum ar fi un notar. Apoi, acești oameni plecau în direcții diferite cu copia pe hârtie a contractului și începeau să întreprindă acțiuni care puteau să nu fie conforme cu contractul în sine, adică făceau un lucru, dar pe hârtie era consemnat că ar trebui să facă complet altceva. Și cum se ieșea din această situație? Practic, unul dintre participanții grupului trebuia să ia documentul, să adune dovezi, să se prezinte în instanță și să solicite conformitatea între contract și acțiunile efective. Destul de des, obținerea unei îndepliniri corecte a acestui contract poate fi dificilă, ceea ce duce la consecințe neplăcute.
Ce se poate spune despre contractele inteligente? Ele combină atât posibilitatea redactării condițiilor contractului, cât și mecanismul de respectare strictă a acestora. Dacă condițiile au fost stabilite și a fost semnată tranzacția sau cererea corespunzătoare, atunci, după acceptarea acestei cereri sau tranzacții, nu mai este posibil să se schimbe condițiile sau să se influențeze îndeplinirea lor.
Există un validator sau o întreagă rețea, precum și o bază de date care stochează toate smart contractele ce au fost trimise spre executare într-o ordine strict cronologică. De asemenea, este important ca această bază de date să conțină toate condițiile-triggers pentru executarea smart contractului. În plus, trebuie să țină cont de valoarea care este descrisă în contract. Dacă este vorba despre o monedă digitală, atunci această bază de date trebuie să o țină cont.
Cu alte cuvinte, validatorii smart contractelor trebuie să aibă acces la toate datele cu care operează smart contractul. De exemplu, o bază de date trebuie să fie utilizată pentru a contabiliza simultan monedele digitale, soldurile utilizatorilor, tranzacțiile utilizatorilor și timpii. Atunci, în smart contract, o condiție poate fi soldul utilizatorului într-o anumită monedă, apariția unui anumit moment sau faptul efectuării unei anumite tranzacții, dar nu mai mult.
Definiția smart contractului
De fapt, termenul a fost creat de cercetătorul Nick Szabo și a fost folosit pentru prima dată în 1994, fiind documentat în 1997 într-un articol care descrie ideea de smart contracte.
Smart contractele implică o automatizare a distribuției valorii, care poate depinde doar de condițiile prestabilite. În cel mai simplu caz, aceasta apare ca un contract cu condiții strict stabilite, semnat de părți specifice.
Smart contractele sunt concepute pentru a minimiza încrederea în terți. Uneori, se exclude complet un centru de decizie de care depind toate acestea. În plus, pentru astfel de contracte este mai simplu să se realizeze un audit. Acest lucru este o consecință a unor caracteristici de proiectare a acestui sistem, dar cel mai adesea înțelegem prin smart contract o mediu descentralizat și existența unor funcții care permit oricui să analizeze baza de date și să efectueze un audit complet al executării contractelor. Astfel, se garantează protecția împotriva modificărilor retroactive ale datelor care ar putea determina modificări în execuția însuși contractului. Digitalizarea majorității proceselor în crearea și implementarea smart contractului simplifică adesea tehnologia și costul realizării acestora.
Un exemplu simplu — serviciul Escrow
Să analizăm un exemplu foarte simplu. Acesta va ajuta la înțelegerea funcționalităților contractelor smart și la o mai bună orientare în privința situațiilor în care acestea ar trebui aplicate.
Acesta poate fi realizat și folosind Bitcoin, deși în prezent Bitcoin este încă greu de considerat o platformă complet funcțională pentru contractele smart. Așadar, avem un cumpărător și un magazin online. Cumpărătorul vrea să achiziționeze un monitor de la acest magazin. În cel mai simplu caz, cumpărătorul finalizează și trimite plata, iar magazinul online o primește, confirma, după care trimite produsul. Totuși, în această situație există necesitatea unei mari încrederi — cumpărătorul trebuie să aibă încredere în magazinul online pentru întreaga valoare a monitorului. Deoarece magazinul online poate avea o reputație scăzută în ochii cumpărătorului, există riscul ca, din diverse motive, după primirea plății, magazinul să refuze să onoreze comanda și să nu trimită produsul cumpărătorului. Astfel, cumpărătorul se întreabă (iar magazinul online se întreabă și el), ce se poate aplica în acest caz pentru a minimiza aceste riscuri și a face tranzacțiile mai sigure.
În cazul Bitcoin-ului, se poate oferi posibilitatea cumpărătorului și vânzătorului de a alege independent un mediator. Există multe persoane care se ocupă cu rezolvarea disputelor. Participanții noștri pot alege dintr-o listă comună de mediatori pe cel în care vor avea încredere simultan. Împreună, ei creează un adresă multisignature 2 din 3, unde sunt trei chei și sunt necesare două semnături din oricare două chei pentru a cheltui monedele de la această adresă. O cheie va aparține cumpărătorului, a doua — magazinului online, iar a treia — mediatorului. Cumpărătorul va trimite suma necesară pentru plata monitorului pe această adresă multisignature. Acum, când vânzătorul vede că banii sunt blocați pentru o perioadă de timp pe adresa multisignature, care depinde de el, el poate trimite cu încredere monitorul prin poștă.
Apoi, cumpărătorul primește pachetul, inspectează produsul și ia o decizie cu privire la achiziția finală. El poate fi complet de acord cu serviciul oferit și poate semna tranzacția cu cheia sa, prin care transferă monedele de la adresa multisignature vânzătorului, sau poate fi nemulțumit de ceva. În al doilea caz, el se va adresa mediatorului pentru a elabora o tranzacție alternativă, care va redistribui aceste monede în mod diferit.
Să presupunem că monitorul a sosit puțin zgâriat și nu a fost inclus cablul pentru conectarea la computer, deși pe site-ul magazinului online era specificat că acel cablu ar trebui să fie în pachet. Atunci cumpărătorul adună dovezile necesare pentru a dovedi mediatorului că a fost înșelat în această situație: face capturi de ecran ale site-ului, fotografiază chitanța de la poștă, face poze cu zgârieturile de pe monitor și arată că sigiliul a fost rupt și cablul a fost scos. Magazinul online, la rândul său, adună propriile dovezi și le transmite mediatorului.
Mediatorul este interesat să satisfacă atât nemulțumirea cumpărătorului, cât și interesele magazinului online (mai încolo va fi clar de ce). El elaborează o tranzacție în care monedele de la adresa multisignature vor fi cheltuite într-o anumită proporție între cumpărător, magazinul online și mediator, deoarece ia o parte ca recompensă pentru munca sa. Să presupunem că 90% din suma totală va merge la vânzător, 5% mediatorului și 5% compensației pentru cumpărător. Mediatorul semnează această tranzacție cu cheia sa, dar aceasta nu poate fi aplicată încă, pentru că sunt necesare două semnături, iar momentan există doar una. Această tranzacție o trimite și cumpărătorului, și vânzătorului. Dacă măcar unul dintre ei va fi mulțumit de această opțiune de redistribuire a monedelor, tranzacția va fi semnată suplimentar și difuzată în rețea. Pentru a fi validată, este suficient ca unul dintre participanții la afacere să fie de acord cu opțiunea mediatorului.
Este important să alegi inițial un mediator în care ambele părți să aibă încredere. În acest fel, el va acționa independent de interesele uneia sau alteia și va evalua obiectiv situația. Dacă mediatorul nu oferă o variantă de distribuție a monedelor care să satisfacă măcar una dintre părți, atunci, ajungând la un acord, atât cumpărătorul, cât și magazinul online pot transfera monedele pe o nouă adresă multisig, adăugând cele două semnături. Noua adresă multisig va fi creată cu un alt mediator, care, poate, va fi mai competent în problemă și va oferi o variantă mai bună.
Exemplu cu o cămin și un frigider
Să luăm în considerare un exemplu mai complex, care să reflecte mai clar posibilitățile unui contract inteligent.
Să presupunem că sunt trei băieți care s-au mutat recent împreună într-o cameră la cămin. Toți trei sunt interesați să cumpere un frigider pentru camera lor, pe care să-l folosească împreună. Unul dintre ei s-a oferit să strângă suma necesară pentru achiziționarea frigiderului și să negocieze cu vânzătorul. Cu toate acestea, ei s-au cunoscut relativ recent și nu au suficientă încredere între ei. Este clar că doi dintre ei riscă, dând bani celui de-al treilea. În plus, trebuie să ajungă la un acord privind alegerea vânzătorului.
Ei pot profita de un serviciu escrow, adică să aleagă un mediator care să supravegheze executarea tranzacției și să rezolve eventualele dispute, dacă apar. Așadar, ajungând la un acord, ei întocmesc un contract inteligent și stipulează anumite condiții în el.
Prima condiție este că, până la un anumit moment, să zicem într-o săptămână, pe contul corespunzător al smart contractului trebuie să sosească trei plăți de la anumite adrese, pentru o sumă stabilită. Dacă acest lucru nu se întâmplă, smart contractul își va întrerupe execuția și va returna monedele tuturor participanților. Dacă condiția este îndeplinită, se stabilesc valorile identificatorilor vânzătorului și mediatorului, iar apoi se verifică condiția că toți participanții sunt de acord cu alegerea vânzătorului și mediatorului. Când toate condițiile sunt îndeplinite, fondurile vor fi transferate pe adresele specificate. O astfel de abordare poate proteja participanții de fraude din orice parte și elimină, în general, necesitatea de a avea încredere.
Vedem în acest exemplu principiul, că această posibilitate de a stabili pașii pentru îndeplinirea fiecărei condiții permite crearea de sisteme de orice complexitate și adâncime a nivelurilor. În plus, inițial în smart contract se poate defini prima condiție, iar abia după îndeplinirea acesteia se pot stabili parametrii pentru următoarea condiție. Cu alte cuvinte, o condiție este formulată formal, iar parametrii pentru aceasta pot fi stabiliți deja în timpul desfășurării ei.
Clasificarea smart contractelor
Pentru clasificare se pot stabili diferite grupuri de criterii. Cu toate acestea, în prezent, în contextul dezvoltării tehnologiilor, sunt relevante patru dintre acestea.
Smart contractele pot fi distinse în funcție de mediul de execuție, care poate fi fie centralizat, fie descentralizat. În cazul descentralizării, avem mult mai multă independență și reziliență în executarea smart contractelor.
De asemenea, ele pot fi distinse prin procesul de definire și executare a condițiilor: pot fi programabile arbitrar, limitate sau prestabilite, adică strict tipizate. Când pe platforma smart contractelor există doar 4 smart contracte definite, parametrii pentru acestea pot fi stabiliți arbitrar. Prin urmare, este mult mai simplu să le definim: alegem contractul din listă și transmitem parametrii.
În funcție de modul de inițiere, există contracte inteligente automatizate, adică se auto-execută atunci când se îndeplinesc anumite condiții, și există contracte în care condițiile sunt specificate, dar platforma nu verifică automat îndeplinirea acestora, astfel încât acestea trebuie inițiate separat.
În plus, contractele inteligente se diferențiază prin nivelul de confidențialitate. Ele pot fi complet deschise, parțial deschise sau complet confidențiale. Ultima variantă înseamnă că observatorii externi nu văd condițiile contractelor inteligente. Totuși, tema confidențialității este foarte vastă și este mai bine să fie discutată separat de articolul actual.
Aici ne vom concentra mai în detaliu asupra primelor trei criterii pentru a aduce mai multă claritate în înțelegerea subiectului curent.
Contracte inteligente prin mediu de execuție
Prin mediu de execuție, se disting platformele centralizate și descentralizate pentru contractele inteligente. În cazul contractelor digitale centralizate, este utilizat un singur serviciu, unde există un singur validor și poate exista un serviciu de backup și recuperare care este, de asemenea, gestionat centralizat. Există o bază de date care stochează toate informațiile necesare pentru a stabili condițiile contractului inteligent și distribuirea valorii care este consemnată în această bază de date a serviciului. Acest serviciu centralizat are un client care stabilește condițiile prin cereri specifice și folosește astfel de contracte. Deoarece platforma este centralizată, mecanismele de autentificare pot fi mai puțin fiabile decât în cazul criptomonedelor.
Ca exemplu, putem lua furnizorii de servicii de telefonie mobilă (diverse operatori mobili). Să presupunem că un anumit operator ține contabilitatea traficului pe serverele sale într-un mod centralizat, care poate fi transmis în diferite formate, de exemplu: sub formă de apeluri vocale, mesaje SMS, trafic de internet mobil și conform diferitelor standarde, și de asemenea ține evidența fondurilor din soldurile utilizatorilor. În consecință, furnizorul de servicii de telefonie mobilă poate realiza contracte pentru contabilizarea serviciilor oferite și a plăților lor cu diferite condiții. În acest caz, este ușor să stabilești condiții de tipul „trimite un mesaj SMS cu un anumit cod la un anumit număr și vei primi astfel de condiții pentru distribuția traficului.”
Se poate aduce un alt exemplu: băncile tradiționale cu funcționalitate extinsă de internet banking și astfel de contracte foarte simple, cum ar fi plățile regulate, conversia automată a plăților primite, deducerea automată a procentului într-un cont specific și așa mai departe.
Dacă vorbim despre smart contracts într-un mediu de execuție descentralizat, atunci avem un grup de validatori. Într-un scenariu ideal, un validator poate fi orice persoană. Datorită protocolului de sincronizare a bazei de date și al obținerii consensului, avem o bază de date comună care va stoca acum toate tranzacțiile cu contracte strict descrise, și nu doar solicitări condiționate, a căror formate se schimbă frecvent și nu există o specificație deschisă. Aici, tranzacțiile vor conține instrucțiuni pentru executarea contractului conform unei specificații stricte. Această specificație este deschisă, astfel încât utilizatorii platformei pot efectua auditul și valida smart contracts. Aici vedem că platformele descentralizate depășesc platformele centralizate în ceea ce privește independența și reziliența, dar proiectarea și întreținerea acestora sunt mult mai complexe.
Smart contracts în funcție de modul de formulare și executare a condițiilor
Acum să discutăm în detaliu cum smart contracts pot diferi în funcție de modul de formulare și executare a condițiilor. Aici ne vom concentra pe smart contracts care sunt programate aleatoriu și complete în sensul lui Turing. Un smart contract complet în Turing permite formularea practic oricăror algoritmi ca condiții pentru executarea contractului: scrierea de bucle, anumite funcții de calcul al probabilităților și așa mai departe — inclusiv propriile algoritmi de semnătură electronică. În acest caz, se referă la scrierea cu adevărat aleatorie a logicii.
De asemenea, sunt evidențiate smart contracts aleatorii, dar nu complete în Turing. Acestea includ Bitcoin și Litecoin cu propriul lor script. Se referă la faptul că se pot folosi doar anumite operații într-o ordine aleatorie, însă nu se pot scrie bucle și algoritmi proprii.
În plus, există platforme de smart contract care implementează smart contracturi predefinite. Acestea includ Bitshares și Steemit. Bitshares dispune de o serie de smart contracturi pentru tranzacționare, gestionarea conturilor, administrarea platformei și parametrii acesteia. Steemit este o platformă similară, dar orientată nu către emiterea de tokenuri și tranzacționare, cum este Bitshares, ci spre blogging, adică stochează și procesează conținut într-un mod descentralizat.
Printre contractele complete care pot fi descrise în termeni Turing-compleți se numără platforma Ethereum și RootStock, care este încă în dezvoltare. De aceea, în continuare ne vom concentra puțin mai mult asupra platformei de smart contracturi Ethereum.
Smart contractele prin metoda de inițiere
După metoda de inițiere, smart contractele pot fi împărțite în minimum două grupuri: automatizate și manuale (neautomatizate). Caracteristica smart contractelor automatizate este că, având toate parametrii cunoscuți și condițiile îndeplinite, acestea se execută complet automat, adică nu necesită trimiterea unor tranzacții suplimentare și nu implică costuri adiționale de comision pentru fiecare execuție ulterioară. Platforma în sine are toate datele necesare pentru a calcula modul în care se va finaliza smart contractul. Logica acestuia nu este aleatorie, ci predefinită, și totul este previzibil. Asta înseamnă că se poate evalua anticipat complexitatea execuției smart contractului, se poate utiliza un comision constant pentru acesta, iar toate procesele de execuție se desfășoară într-un mod mai eficient.
Pentru smart contractele ce sunt programate într-un mod arbitrar, execuția nu este automatizată. Pentru inițierea unui astfel de smart contract trebuie, de fapt, să se creeze o nouă tranzacție la fiecare pas, care va invoca următoarea etapă a execuției sau următoarea metodă a smart contractului, să se plătească comisionul corespunzător și să se aștepte confirmarea tranzacției. Execuția poate termina cu succes sau nu, deoarece codul smart contractului este arbitrar și pot apărea momente imprevizibile, cum ar fi bucle infinite, lipsa unor parametrii și argumente, situații necontrolate etc.
Conturi în Ethereum
Tipurile de conturi Ethereum
Să analizăm ce fel de conturi pot exista pe platforma Ethereum. Aici există doar două tipuri de conturi și nici o altă variantă. Primul tip se numește cont de utilizator, iar al doilea — cont de contract. Să vedem în ce constă diferența dintre ele.
Contul de utilizator este gestionat doar de cheia privată a semnăturii electronice. Proprietarul contului își generează propria pereche de chei pentru semnătura electronică utilizând algoritmul ECDSA (Elliptic Curve Digital Signature Algorithm). Starea acestui cont poate fi modificată doar prin tranzacții semnate cu această cheie.
Contul de smart contract are o logică separată. Acesta poate fi gestionat doar prin codul programat dinainte, care definește complet comportamentul smart contractului: cum va dispune de monedele sale în anumite circumstanțe, la inițiativa cărui utilizator și în ce condiții suplimentare aceste monede vor fi distribuite. Dacă anumite aspecte nu sunt prevăzute de dezvoltatori în codul programatic, pot apărea probleme. De exemplu, smart contractul poate ajunge într-o stare specifică în care nu acceptă inițierea ulterioară a execuției de la niciun utilizator. În acest caz, monedele vor fi, de fapt, înghețate, deoarece smart contractul nu permite ieșirea din această stare.
Cum se creează conturile în Ethereum
În cazul contului de utilizator, proprietarul își generează singur perechea de chei folosind ECDSA. Este important de menționat că Ethereum folosește același algoritm pentru semnătura electronică și aceeași curbă eliptică ca Bitcoin, dar adresa este calculată într-un mod ușor diferit. Aici nu se folosește rezultatul dublului hash, cum se întâmplă în Bitcoin, ci se realizează un hashing simplu utilizând funcția Keccak cu o lungime de 256 biți. Din valoarea obținută se elimină biții inferiori, respectiv 160 de biți inferiori din valoarea de ieșire a funcției hash. Ca rezultat, obținem adresa în Ethereum. Practic, aceasta ocupă 20 de octeți.
Să observăm că identificatorul contului în Ethereum este codificat în hex fără utilizarea unei sume de control, spre deosebire de Bitcoin și multe alte sisteme, unde adresa este codificată într-un sistem zecimal de bază 58 cu adăugarea unei sume de control. Asta înseamnă că trebuie să lucrăm cu identificatoarele conturilor în Ethereum cu precauție: chiar și o singură eroare în identificator va duce garantat la pierderea monedelor.
Există o caracteristică importantă, și anume că contul utilizatorului la nivelul bazei de date comune este creat în momentul în care acesta primește prima plată de intrare.
În ceea ce privește crearea contului pentru smart contract, se aplică o abordare complet diferită. Inițial, cineva din utilizatori scrie codul sursă al smart contractului, după care codul este trecut printr-un compilator special pentru platforma Ethereum, obținând codul byte pentru propria mașină virtuală Ethereum. Codul byte obținut este plasat într-un câmp special al tranzacției. Aceasta este semnată în numele contului inițiator. Ulterior, această tranzacție se răspândește prin rețea și publică codul smart contractului. Comisionul pentru efectuarea tranzacției și, prin urmare, pentru îndeplinirea contractului, este debitat din soldul contului inițiator.
Fiecare smart contract conține în mod obligatoriu propriul constructor (al acestui contract). Acesta poate fi gol sau poate avea conținut. După ce constructorul este executat, se creează un identificator al contului smart contractului, folosind care se pot trimite monede, invoca anumite metode ale smart contractului etc.
Structura tranzacției Ethereum
Pentru a fi mai clar, vom examina structura unei tranzacții Ethereum și un exemplu de cod pentru smart contract.
O tranzacție Ethereum constă din mai multe câmpuri. Primul dintre ele, nonce, este un anumit număr secvențial al tranzacției în raport cu contul care o răspândește și este autorul acesteia. Acest lucru este necesar pentru a distinge duplicatele tranzacțiilor, adică pentru a exclude situația în care aceeași tranzacție este acceptată de două ori. Datorită utilizării identificatorului, fiecare tranzacție are o valoare hash unică.
Apoi urmează un câmp numit prețul gazului. Aici se specifică prețul la care moneda de bază Ethereum este convertită în gas, cu care se plătește executarea unui contract smart și alocarea resurselor mașinii virtuale. Ce înseamnă asta?
În Bitcoin, comisioanele se plătesc direct în moneda de bază – bitcoinul însuși. Acest lucru este posibil datorită unui mecanism simplu de calcul: plătim strict volumul de date conținut în tranzacție. În Ethereum, situația este mai complexă, deoarece este foarte dificil să ne bazăm pe volumul de date al tranzacției. Aici, tranzacția poate conține și cod program care va fi executat pe mașina virtuală, iar fiecare operație a mașinii virtuale poate avea o complexitate diferită. Există, de asemenea, operații care alocă memorie pentru variabile. Acestea vor avea complexitatea lor, de care depinde plata pentru fiecare operație.
Costul fiecărei operații în echivalent gas va fi constant. Aceasta este introdusă special pentru a determina costul constant al fiecărei operații. În funcție de încărcătura rețelei, va varia prețul gas, adică coeficientul conform căruia moneda de bază va fi convertită în această unitate auxiliară pentru plata comisionului.
Există și o altă caracteristică a tranzacției în Ethereum: bytecode-ul pe care îl conține pentru a fi executat în mașina virtuală va continua să fie executat până când se finalizează cu un anumit rezultat (succes - eșec) sau până când se finalizează o anumită sumă de monede alocate pentru plata comisionului. Aceasta este pentru a evita situația în care toate monedele din contul expeditorului sunt consumate pentru comision în caz de eroare (de exemplu, un ciclu infinit s-a activat în mașina virtuală), există următorul câmp - start gas (adesea numit limita de gas) - acesta definește cantitatea maximă de monede pe care expeditorul este dispus să o cheltuie pentru executarea unei anumite tranzacții.
Următorul câmp se numește destination address. Aici se introduce adresa destinatarului monedelor sau adresa unui anumit contract smart, ale căror metode vor fi apelate. După aceasta urmează câmpul valoare, unde se introduce suma de monede care se trimite către destination address.
În continuare, se află un câmp interesant numit data, unde se integrează o întreagă structură. Nu este un câmp separat, ci o întreagă structură în care se definește codul pentru mașina virtuală. Aici se pot insera date arbitrare — pentru aceasta există reguli separate.
Și ultimul câmp se numește semnătură. Acesta conține atât semnătura electronică a autorului acestei tranacții, cât și cheia publică cu care va fi verificată această semnătură. Din cheia publică se poate obține identificatorul contului expeditorului acestei tranacții, adică se poate identifica univoc contul expeditorului în sistemul propriu-zis. În ceea ce privește structura tranacției, am stabilit esențialul.
Exemplu de cod al unui smart contract în Solidity
Acum să analizăm mai detaliat cel mai simplu smart contract printr-un exemplu.
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);
}
}Mai sus este prezentat un cod sursă simplificat, care poate reține monedele utilizatorilor și le poate returna la cerere.
Așadar, există un smart contract numit Bank, care îndeplinește următoarele funcții: acumulează monede pe soldul său, adică la confirmarea tranacției și plasarea unui astfel de smart contract se creează un nou cont care poate conține monede pe soldul său; își amintește utilizatorii și distribuția monedelor între aceștia; are mai multe metode de gestionare a soldurilor, adică există posibilitatea de a suplimenta, de a retrage și de a verifica soldul utilizatorului.
Să trecem acum prin fiecare linie a codului sursă. În acest contract există câmpuri constante. Unul dintre ele, de tip address, se numește owner. Aici contractul reține adresa utilizatorului care a creat acest smart contract. Apoi, există o structură dinamică care păstrează corespondențele între adresele utilizatorilor și soldurile acestora.
După aceasta, urmează metoda Bank — care se numește la fel ca și contractul. În consecință, acesta este constructorul său. Aici se face atribuirea variabilei owner adresa celui care a plasat acest smart contract în rețea. Aceasta este singura acțiune care se desfășoară în acest constructor. Adică msg în acest caz este exact acele date care au fost transmise mașinii virtuale împreună cu tranacția, conținând întregul cod al acestui contract. Prin urmare, msg.sender este autorul acestei tranacții care plasează acest cod. El va fi, de asemenea, proprietarul smart contractului.
Metoda deposit permite transferarea unui anumit număr de monede către contul contractului printr-o tranzacție. În acest caz, smart contractul, primind aceste monede, le păstrează în propriul său balans, dar în structura balances înregistrează cine a fost expeditorul acestor monede, pentru a ști cui aparțin.
Următoarea metodă se numește withdraw și acceptă un singur parametru — suma de monede pe care cineva dorește să o retragă din această bancă. Aici se verifică dacă există suficiente monede în balansul utilizatorului care apelează această metodă, pentru a le trimite. Dacă sunt suficient de multe, then smart contractul returnează apelantului această sumă de monede.
Următoarea este metoda care verifică balanța curentă a utilizatorului. Cel care apelează această metodă va fi utilizat pentru a obține această balanță în smart contract. Este demn de menționat că modificatorul acestei metode este — view. Aceasta înseamnă că metoda nu schimbă variabilele din clasa sa și este, de fapt, doar o metodă de citire. Nu se creează o tranzacție separată pentru apelarea acestei metode, nu se plătește o comision, iar toate calculele se realizează local, după care utilizatorul primește rezultatul.
Metoda kill este necesară pentru a distruge starea smart contractului. Aici este prevăzută o verificare suplimentară pentru a stabili dacă apelantul acestei metode este proprietarul contractului. Dacă este, atunci contractul se autodistruge, iar funcția de distrugere primește un parametru — identificatorul contului la care contractul va trimite toate monedele rămase în balansul său. În acest caz, monedele rămase vor fi trimise automat la adresa proprietarului contractului.
Cum funcționează un nod complet al rețelei Ethereum?
Să luăm schematic cum se desfășoară execuția acestor smart contracte pe platforma Ethereum și cum funcționează un nod complet al rețelei.
Un nod complet al rețelei Ethereum trebuie să aibă cel puțin patru module.
Primul, ca pentru orice protocol descentralizat, este modulul de rețea P2P — modulul de conectare și lucru cu alte noduri, unde se face schimbul de blocuri, tranzacții, informații despre alte noduri. Acesta este un component tradițional pentru toate criptomonedele descentralizate.
Apoi, avem un modul pentru stocarea datelor blockchain, procesare, selectarea ramurii prioritare, completarea blocurilor, deconectarea blocurilor, verificarea acestor blocuri etc.
Al treilea modul se numește EVM (Ethereum virtual machine) — acesta este mașină virtuală, care preia bytecode din tranzacțiile Ethereum. Acest modul primește starea curentă a unui anumit cont și efectuează modificări asupra stării sale pe baza bytecode-ului primit. Versiunea mașinii virtuale de la fiecare nod din rețea trebuie să fie aceeași. Calculul se desfășoară la fiecare nod Ethereum în mod identic, dar se realizează într-un mod asincron: cineva verifică și acceptă această tranzacție mai devreme, adică execută tot codul aflat în ea, iar altcineva mai târziu. Așadar, atunci când se creează o tranzacție, aceasta se propagate în rețea, nodurile o acceptă și, în momentul verificării, exact cum se execută Bitcoin Script în Bitcoin, aici se execută bytecode-ul mașinii virtuale.
O tranzacție este considerată verificată dacă tot codul conținut în ea a fost executat, a fost generat un nou stat pentru un anumit cont și a fost păstrat până când este clar dacă această tranzacție a fost aplicată sau nu. Dacă tranzacția a fost aplicată, atunci acest stat este considerat nu doar executat, ci și actual. Există o bază de date care stochează starea fiecărui cont pentru fiecare nod din rețea. Datorită faptului că toate calculările se desfășoară identic și starea blockchain-ului este aceeași, baza de date care conține stările tuturor conturilor va fi, de asemenea, aceeași pentru fiecare nod.
Mituri și limitări ale contractelor inteligente
Cât despre limitările existente pentru platformele de contracte inteligente asemănătoare cu Ethereum, putem menționa următoarele:
- executarea codului;
- alocarea de memorie;
- datele blockchain;
- trimiterea de plăți;
- crearea unui nou contract;
- apelarea altor contracte.
Să analizăm restricțiile impuse pe mașina virtuală și să demontăm unele mituri despre contractele inteligente. Pe o mașină virtuală, care poate fi nu doar în Ethereum, ci și pe platforme similare, se pot executa cu adevărat operațiuni logice arbitrare, adică se poate scrie cod și acesta va fi executat acolo, se poate aloca suplimentar memorie. Totuși, comisionul se plătește separat pentru fiecare operațiune și pentru fiecare unitate suplimentară de volum de memorie alocată.
În continuare, mașina virtuală poate citi date din baza de date a blockchain-ului, pentru a folosi aceste date ca un declanșator pentru a executa o anumită logică a contractelor inteligente. Mașina virtuală poate crea și trimite tranzacții, poate crea contracte noi și poate apela metode ale altor contracte inteligente care sunt deja publicate în rețea: există, sunt accesibile etc.
Cel mai frecvent mit este că contractele inteligente Ethereum pot utiliza informații din orice resursă online în condițiile lor. Adevărul este că mașina virtuală nu poate trimite o cerere de rețea către o resursă informațională externă pe internet, adică nu se poate scrie un astfel de contract inteligent care să distribuie valoare între utilizatori în funcție de, să spunem, vremea de afară, cine a câștigat un campionat anume sau pe baza altor incidente întâmplate în lume, deoarece informațiile despre aceste evenimente pur și simplu nu există în baza de date a platformei în sine. Astfel, în blockchain nu există nimic în legătură cu acest lucru. Dacă nu apare acolo, atunci mașina virtuală nu poate folosi aceste date ca declanșatori.
Dezavantajele Ethereum
Să enumerăm principalele dintre ele. Prima deficiență constă în faptul că există anumite dificultăți în proiectarea, dezvoltarea și testarea contractelor inteligente în Ethereum (în Ethereum, pentru scrierea contractelor inteligente se folosește limbajul Solidity). De fapt, practica arată că un procent foarte mare din toate erorile se datorează factorului uman. Acest lucru este relevant și pentru contractele inteligente Ethereum deja scrise, care au o complexitate medie sau mai mare. Dacă pentru contractele inteligente simple probabilitatea de eroare este mică, în contractele inteligente complexe foarte des apar erori care duc la furtul fondurilor, la blocarea acestora, la distrugerea contractelor inteligente într-un mod neașteptat etc. Există deja multe astfel de cazuri cunoscute.
A doua deficiență constă în faptul că în sine mașina virtuală nu este ideală, deoarece a fost tot scrisă de oameni. Aceasta poate executa comenzi arbitrare și aici se ascunde o vulnerabilitate: este posibil să se configureze în mod specific o serie de comenzi care vor duce la consecințe neașteptate. Aceasta este o sferă foarte complexă, dar există deja câteva studii care arată că aceste vulnerabilități există în versiunea actuală a rețelei Ethereum și pot duce la un eșec al funcționării multor contracte inteligente.
O altă mare dificultate, care poate fi considerată o deficiență. Aceasta constă în faptul că în mod practic sau tehnic s-ar putea ajunge la concluzia că, dacă se compune codul byte al contractului care va fi executat pe mașina virtuală, se poate determina un anumit ordin specific al operațiunilor. Când sunt executate împreună, aceste operațiuni vor suprasolicita foarte mult mașina virtuală și o vor încetini disproporționat față de comisionul care a fost plătit pentru executarea acestor operațiuni.
În trecut, a existat o perioadă similară de dezvoltare a Ethereum, când mulți tineri, care înțelegeau în detaliu funcționarea mașinii virtuale, descoperau astfel de vulnerabilități. Practic, tranzacțiile plăteau comisioane foarte mici, dar încetineau semnificativ funcționarea întregii rețele. Aceste probleme sunt foarte greu de rezolvat, deoarece trebuie, pe de o parte, să fie determinate, pe de altă parte, să fie corectată tariful pentru executarea acestor operațiuni și, în al treilea rând, trebuie realizat un hard fork, ceea ce implică actualizarea tuturor nodurilor rețelei la o nouă versiune de software și apoi activarea simultană a acestor modificări.
În ceea ce privește Ethereum, au fost efectuate foarte multe cercetări, s-a obținut o experiență practică vastă: atât pozitivă, cât și negativă, dar totuși rămân dificultăți și vulnerabilități cu care trebuie să ne confruntăm în continuare.
Așadar, partea tematică a articolului s-a încheiat, să trecem la întrebările care apar destul de frecvent.
Întrebări frecvente
— Dacă toate părțile contractului smart doresc să schimbe condițiile, pot ele anula acest contract smart cu ajutorul multiplu semnăturii, iar apoi să creeze un nou contract smart cu condițiile actualizate ale execuției sale?
Aici, răspunsul va fi ambiguu. De ce? Pentru că, pe de o parte, contractul smart este stabilit o dată și nu preconizează modificări, iar pe de altă parte, el poate avea o logică predefinită care permite schimbarea totală sau parțială a unor condiții. Deci, dacă doriți să schimbați ceva în contractul dumneavoastră smart, trebuie să precizați din timp condițiile sub care puteți actualiza aceste condiții. Așadar, numai într-un mod atât de precaut poate fi organizată actualizarea contractului. Dar aici, de asemenea, pot apărea probleme: pot apărea anumite erori și se poate crea o vulnerabilitate corespunzătoare. De aceea, astfel de lucruri trebuie proiectate și testate foarte atent și detaliat.
— Și dacă mediatorul se înțelege cu una dintre părțile participante: escrow sau contractul smart? Este obligatoriu mediatorul în contractul smart?
Mediatorul nu este obligatoriu în contractul smart. El poate lipsi. Dacă în cazul escrow mediatorul colaborează cu una dintre părți, atunci da, acest mecanism își pierde drastic toată valoarea. De aceea, mediatorii sunt aleși astfel încât să fie de încredere pentru toate părțile implicate în acest proces. Astfel, pur și simplu nu vei transfera monede pe un adresă multisignatură către mediatorul în care nu ai încredere.
— Se poate efectua o tranzacție Ethereum pentru a transfera multe tokenuri diferite de pe adresa ta către diverse adrese țintă, de exemplu, adresele de pe bursele unde sunt tranzacționate aceste tokenuri?
Aceasta este o întrebare bună și se referă la modelul tranzacțiilor Ethereum și la diferențele față de modelul Bitcoin. Iar diferența este semnificativă. Dacă în modelul de tranzacție Ethereum pur și simplu transferi monede, acestea sunt transferate doar de la o adresă la alta, fără rest, exact suma pe care ai specificat-o. Cu alte cuvinte, acesta nu este un model de ieșiri neutilizate (UTXO), ci un model bazat pe conturi și solduri corespunzătoare. Teoretic, este posibil să trimiți mai multe tokenuri diferite într-o singură tranzacție, dacă scrii un contract smart ingenios, dar tot va trebui să efectuezi multe tranzacții, să creezi contractul, apoi să-i transferi tokenurile și monedele, iar apoi să apelezi metoda corespunzătoare. Acest lucru necesită efort și timp, prin urmare, în practică, nu funcționează așa și toate plățile în Ethereum se efectuează în tranzacții separate.
— Unul dintre miturile despre platforma Ethereum este acela că nu poți descrie condiții care să depindă de datele unei surse externe de internet, așadar, ce ar trebui să facem?
Soluția constă în faptul că contractul smart în sine poate prevedea unul sau mai mulți așa-numiți oracole de încredere, care colectează date despre stare lucrurilor din lume externă și le transmit în contractele smart prin metode speciale. Contractul însuși consideră ca fiind adevărate datele pe care le primește de la părți de încredere. Pentru o mai mare fiabilitate, se aleg pur și simplu un grup mai mare de oracole, minimizând astfel riscul de conspirație. Contractul însuși poate ignora datele de la oracolele care contrazic majoritatea.
Această temă este dedicată uneia dintre lecțiile cursului online despre Blockchain — “”.
Sursa: habr.com
