Pagina a fost actualizată pe: August 9, 2021

Ethereum Whitepaper

Această lucrare introductivă a fost publicată inițial în 2013 de Vitalik Buterin, fondatorul Ethereum, înainte de lansarea proiectului în 2015. Este demn de remarcat faptul că Ethereum, ca multe proiecte software open-source bazate pe comunitate, a evoluat de la începuturile sale inițiale.

Deși are câțiva ani de când a fost creat, menținem această lucrare, deoarece continuă să servească drept referință utilă și o reprezentare exactă a Ethereum și a viziunii sale. Pentru a afla despre cele mai recente evoluții ale Ethereum și despre modul în care se fac modificări ale protocolului, recomandăm acest ghid.

O nouă generație de contracte inteligente și o platformă de aplicații descentralizată

Dezvoltarea Bitcoin de către Satoshi Nakamoto în 2009 a fost adesea apreciată ca o dezvoltare radicală în bani și monedă, fiind primul exemplu a unui activ digital care simultan nu are niciun suport sau valoare intrinsecă și niciun emitent sau controlor centralizat". Cu toate acestea, o altă parte - probabil mai importantă - a experimentului Bitcoin este tehnologia blockchain care stă la bază ca instrument de consens distribuit, iar atenția începe rapid să se deplaseze către acest alt aspect al Bitcoin. În mod obișnuit aplicațiile alternative citate ale tehnologiei blockchain includ utilizarea activelor digitale în-blockchain pentru a reprezenta monede personalizate și instrumente financiare (monede colorate), proprietatea unui dispozitiv fizic subiacent (proprietate inteligentă), active non-fungibile precum nume de domenii (Namecoin), precum și aplicații mai complexe care implică existența de active digitale controlate direct de o bucată de cod care implementează reguli arbitrare (contracte inteligente) sau chiar organizații autonome descentralizate bazate pe blockchain (DAO). Ce intenționează să ofere Ethereum este un blockchain cu un limbaj de programare Turing-complet încorporat, care poate fi folosit pentru a crea „contracte” care pot fi utilizate pentru a codifica funcții de tranziția de stare arbitrară, permițând utilizatorilor să creeze oricare dintre sistemele descrise mai sus, precum și multe altele pe care nu le-am imaginat încă, pur și simplu scriind logica în câteva linii de cod.

Introducere în Bitcoin și concepte existente

Istoric

Conceptul de monedă digitală descentralizată, precum și aplicațiile alternative, precum registrele de proprietate, există de zeci de ani. Protocoalele anonime de numerar electronic din anii 1980 și 1990, bazate în cea mai mare parte pe o primitivă criptografică, cunoscută sub numele de Chaumian Blinding, au furnizat o monedă cu un grad ridicat de confidențialitate, dar nu au reușit să câștige tracțiune din cauza dependenței lor de un sistem centralizat intermediar. În 1998, b-money ai lui Wei Dai au devenit prima propunere de a introduce ideea de a crea bani prin rezolvarea puzzle-urilor computaționale, precum și a consensului descentralizat, dar propunerea a avut puține detalii cu privire la modul în care consensul descentralizat ar putea fi implementat. În 2005, Hal Finney a introdus un concept al dovezilor de muncă reutilizabile (rpow), un sistem care folosește ideile de b-money și cele de puzzle-uri Hashcash dificile din punct de vedere al calculului ale lui Adam Back, pentru a crea un concept pentru o criptomonedă, dar din nou, nu a reușit să-și atingă idealul, bazându-se pe computerul de încredere ca back-end. În 2009, o monedă descentralizată a fost implementată pentru prima dată în practică de Satoshi Nakamoto, combinând primitive stabilite pentru gestionarea proprietății prin criptografie cu cheie publică cu un algoritm de consens pentru a urmări cine deține monede, cunoscut sub numele de „dovada muncii”.

Mecanismul din spatele dovezii muncii a fost un progres astronomic, deoarece a rezolvat simultan două probleme. În primul rând, a furnizat un algoritm de consens simplu și moderat eficient, permițând nodurilor din rețea să convină în mod colectiv asupra unui set de actualizări canonice ale statului registrului Bitcoin. În al doilea rând, a oferit un mecanism pentru a permite intrarea liberă în procesul de consens, rezolvând problema politică de a decide cine ajunge să influențeze consensul, prevenind simultan atacurile de tip „sybil”. Face acest lucru prin substituirea unei bariere formale în calea participării, cum ar fi cerința de a fi înregistrată ca entitate unică pe o anumită listă, cu o barieră economică - greutatea unui singur nod în procesul de votare consens este direct proporțională cu puterea de calcul pe care o aduce nodul. De atunci, a fost propusă o abordare alternativă numită dovada mizei (PoS), calculând greutatea unui nod ca fiind proporțională cu deținerile sale valutare și nu cu resursele de calcul; discutarea meritelor relative ale celor două abordări depășește scopul lucrării acesteia, dar trebuie remarcat faptul că ambele abordări pot fi utilizate pentru a servi drept coloana vertebrală a unei criptomonede.

Iată o postare de pe blogul lui Vitalik Buterin, fondatorul Ethereum, despre Preistoria Ethereum. Aici este o altă postare de pe blog cu mai multă istorie.

Bitcoin ca un sistem de tranziție de stare

Din punct de vedere tehnic, registrul unei criptomonede precum Bitcoin poate fi considerat un sistem de tranziție de stare, acolo unde există o „stare” constând din starea de proprietate a tuturor bitcoin-urilor existente și o „funcție de tranziție de stare” care ia o stare și o tranzacție și generează o nouă stare care este rezultatul. Într-un sistem bancar standard, de exemplu, starea este un bilanț, o tranzacție este o cerere să muți $X de la A la B, iar funcția de tranziție a stării reduce valoarea valoarea contului lui A cu $X și crește valoarea contului lui B cu $X. Când contul lui A are mai puțin de $X, în primul rând, starea funcției de tranziție returnează o eroare. Prin urmare, se pot defini formal:

APPLY(S,TX) -> S' sau ERROR

În sistemul bancar definit mai sus:

APPLY({ Alice: $50, Bob: $50 },"trimite $20 de la Alice la Bob") = { Alice: $30, Bob: $70 }

Dar:

APPLY({ Alice: $50, Bob: $50 },"trimite $70 de la Alice la Bob") = ERROR

„Starea” din Bitcoin este colecția tuturor monedelor (din punct de vedere tehnic, „ieșiri de tranzacție necheltuite” sau UTXO) care au fost exploatate dau nu au fost încă cheltuite, fiecare UTXO având o denumire și un proprietar (definit de o adresă de 20 de byți, care este în esență o cheie publică criptografică^{fn. 1}). A tranzacția conține una sau mai multe intrări, fiecare intrare conținând o referință la un UTXO existent și la o semnătură criptografică produsă de cheia privată asociată cu adresa proprietarului și una sau mai multe ieșiri, fiecare ieșire conținând un nou UTXO care va fi adăugat la stare.

Funcția de tranziție de stare APPLY(S,TX) -> S'se poate defini aproximativ după cum urmează:

Pentru fiecare intrare în TX:
- Dacă UTXO la care se face referire nu este în S, returnează o eroare.
- În cazul în care semnătura furnizată nu se potrivește cu proprietarul UTXO, returnează o eroare.
În cazul în care suma valorilor tuturor intrărilor UTXO este mai mică decât suma nominală a tuturor ieșirilor UTXO, returnează o eroare.
Returnează S' cu toate intrările UTXO eliminate și toate ieșirile UTXO adăugate.

Prima jumătate a primului pas împiedică tranzacțiile să cheltuiască monede care nu există, a doua jumătate a primului pas împiedică tranzacțiile să nu cheltuiască monedele altor persoane, iar a doua etapă impune conservarea valorii. Pentru a utiliza acest lucru pentru plată, protocolul este după urmează. Să presupunem că Alice vrea să trimită 11,7 BTC lui Bob. În primul rând, Alice va căuta un set de UTXO disponibile pe care le deține, care totalizează până la cel puțin 11,7 BTC. În mod realist, Alice nu va va putea obține exact 11,7 BTC; să spunem că minimul pe care îl poate obține este 6+4+2=12. Ea creează apoi o tranzacție cu aceste trei intrări și două ieșiri. Prima ieșire va fi 11,7 BTC cu adresa lui Bob ca proprietar, iar a doua ieșire va fi restul de 0,3 BTC „rest”, proprietarul fiind Alice însăși.

Minarea

Dacă am avea acces la un serviciu centralizat de încredere, implementarea acestui sistem ar fi banală; ar putea fi pur și simplu codificat exact cum am descris, utilizând discul dur al unui server centralizat pentru a ține evidența stării. Cu toate acestea, cu Bitcoin încercăm să construim un sistem valutar descentralizat, așa că va trebui să combinăm sistemul de tranziție de stare cu unul de consens, pentru a ne asigura că toată lumea este de acord cu ordinea tranzacțiilor. Procesul de consens descentralizat al Bitcoin necesită noduri în rețea pentru a încerca în mod continuu să producă pachete de tranzacții numite „blocuri”. Rețeaua este destinată să producă aproximativ un bloc la fiecare zece minute, fiecare bloc conținând un marcaj temporal, un nonce, o referință (adică hash) a blocului anterior și o listă a tuturor tranzacțiilor care au avut loc de la blocul anterior. În timp, acest lucru creează un „blockchain” persistent, în continuă creștere, care se actualizează constant pentru a reprezenta cea mai recentă stare a registrului Bitcoin.

Algoritmul de verificare a validării unui bloc, exprimat în acest model, este după urmează:

Verifică dacă blocul anterior la care face referire blocul există și este valid.
Verifică dacă marcajul temporal al blocului este mai mare decât cel al blocul anterior^{fn. 2} și mai puțin de 2 ore în viitor
Verifică dacă dovada muncii pe bloc este valabilă.
Să spunem că S[0] este starea de la sfârșitul blocului anterior.
Să presupunem că TX este lista de tranzacții a blocului cu n tranzacții. Pentru orice i din 0...n-1, alege S[i+1] = APPLY(S[i],TX[i]) Dacă vreo aplicație returnează o eroare, ieși și returnează fals.
Returnează true și înregistrează S[n] ca stare la sfârșitul acestui bloc.

În esență, fiecare tranzacție în bloc trebuie să furnizeze o stare validă de trecere de la ceea ce a fost starea canonică înainte ca tranzacția să fie executată la noua stare. Reține că starea nu este codificată în bloc în niciun fel; este pur și simplu o abstractizare care să fie ținută minte de nodul de validare și poate fi calculată (în siguranță) pentru orice bloc numai pornind de la starea de geneză și aplicând secvențial fiecare tranzacție în fiecare bloc. În plus, reține că ordinea în care minerul include tranzacțiile în bloc contează; dacă sunt două tranzacții A și B într-un bloc, astfel încât B să cheltuiască UTXO creat de A, atunci blocul va fi valabil dacă A vine înainte de B, dar nu altfel.

Singura condiție de valabilitate prezentă în lista de mai sus care nu se găsește în alte sisteme este cerința pentru „dovada muncii”. Condiția precisă este ca hash-ul dublu-SHA256 al fiecărui bloc, tratat ca un număr de 256 de biți, trebuie să fie mai mic decât o țintă ajustată dinamic, care din momentul acestei scrieri este de aproximativ 2¹⁸⁷. Scopul acestui lucru este de a face crearea blocului „dificilă” din punct de vedere computațional, împiedicând astfel atacatorii „sybil” să refacă întregul blockchain în favoarea lor. Deoarece SHA256 este conceput pentru a fi o funcție de pseudorandom complet imprevizibilă, singura modalitate de a crea un bloc valid este pur și simplu prin încercare și eroare, crescând în mod repetat nonce-ul și verificând dacă noul hash se potrivește.

La ținta curentă de ~2¹⁸⁷, rețeaua trebuie să facă în medie ~2⁶⁹ încercări înainte de a găsi un bloc valid; în general, ținta este recalibrată de rețea la fiecare 2016 blocuri, astfel încât, în medie, un bloc nou este produs de unele noduri din rețea la fiecare zece minute. Pentru a compensa minerii pentru această lucrare de calcul, minerul fiecărui bloc are dreptul de a include o tranzacție oferindu-și 12,5 BTC de nicăieri. În plus, dacă orice tranzacție are o valoare nominală totală mai mare în intrări decât în ieșiri ca rezultat, diferența, de asemenea, merge la miner ca o „taxă de tranzacție”. De altfel, acesta este singurul mecanism prin care este emis BTC; starea genezei nu conținea nicio monedă.

Pentru a înțelege mai bine scopul mineritului, să examinăm ce se întâmplă în cazul unui atacator rău intenționat. Deoarece criptografia care stă la baza Bitcoin este cunoscută ca fiind sigură, atacatorul va viza o parte a sistemului Bitcoin care nu este protejată de criptografie direct: ordinea tranzacțiilor. Strategia atacatorului este simplă:

Trimite 100 BTC unui comerciant în schimbul unui anumit produs (de preferință un bun digital cu livrare rapidă)
Așteaptă livrarea produsului
Produce o altă tranzacție trimițând aceleași 100 BTC lui însuși
Încercă să convingă rețeaua că tranzacția sa pentru el însuși a fost cea care a venit prima.

Odată ce pasul (1) a avut loc, după câteva minute un miner va include tranzacția într-un bloc, să zicem blocul numărul 270. După aproximativ o oră, alte cinci blocuri vor fi adăugate lanțului după acel bloc, cu fiecare dintre aceste blocuri indicând indirect tranzacția și astfel, „confirmând-o". În acest moment, comerciantul va accepta plata ca fiind finalizată și va livra produsul; din moment ce presupunem că acesta este un bun digital, livrarea este instantanee. Acum, atacatorul creează o altă tranzacție, trimițând 100 de BTC către el însuși. În cazul în care atacatorul pur și simplu eliberează tranzacția la întâmplare, aceasta nu va fi procesată; minerii vor încerca să ruleze APPLY(S,TX) și să observe că TX consumă un UTXO care nu mai este în stare. Deci, în schimb, atacatorul creează o „furculiță” a blockchain-ului, începând prin exploatarea unei alte versiuni de bloc 270 indicând spre același bloc 269 ca fiind părinte, dar cu noua tranzacție în locul celei vechi. Pentru că datele blocului sunt diferite, acest lucru necesită refacerea dovezii de muncă. Mai mult decât atât, noua versiune a blocului 270 a atacatorului are un hash diferit, astfel încât blocurile originale de la 271 la 275 nu „indică” spre el; astfel, lanțul original și noul lanț al atacatorului sunt complet separate. Regula este că într-o furculiță cel mai lung blockchain este considerat a fi adevărat, astfel încât minerii legitimi vor lucra pe lanțul 275 în timp ce atacatorul singur lucrează pe lanțul 270. Pentru ca atacatorul să-și facă blockchain-ul lui ca cel mai lung, el ar trebui să aibă mai multă putere de calcul decât restul rețelei combinate pentru a ajunge din urmă (prin urmare, „51% atac”).

Arbori Merkle

Stânga: este suficient să se prezinte doar un număr mic de noduri într-un arbore Merkle pentru a da o dovadă a valabilității unei ramuri.

Dreapta: orice încercare de a schimba orice parte a arborelui Merkle va duce în cele din urmă la o inconsistență undeva în lanț.

O caracteristică importantă de scalabilitate a Bitcoin este că blocul este stocat într-o structură de date pe mai multe niveluri. „Hash”-ul unui bloc este de fapt numai hash-ul antetului blocului, o bucată de aproximativ 200 de byți de date care conține marcajul temporal, nonce, hash-ul blocului anterior și hash-ul rădăcină al unei structuri de date numită arborele Merkle care stochează toate tranzacțiile în bloc. Un arbore Merkle este un tip de arbore binar, compus dintr-un set de noduri cu un număr mare de noduri de frunze în partea de jos a arborelui care conțin datele subiacente (plasate dedesubt), un set de noduri intermediare în care fiecare nod este hash-ul celor doi copii ai săi, și în cele din urmă un singur nod rădăcină, format, de asemenea, din hash-ul celor doi copii ai săi, reprezentând „partea de sus” a arborelui. Scopului arborelui Merkle este să permită ca datele dintr-un bloc să fie livrate bucată cu bucată: un nod poate descărca numai antetul unui bloc dintr-o singură sursă, partea mică a arborelui relevantă pentru el de la o altă sursă, și încă să fie siguri că toate datele sunt corecte. Motivul pentru care funcționează este că hash-urile se propagă în sus: dacă un utilizator rău intenționat încearcă să schimbe o tranzacție cu una falsă în partea de jos a unui arbore Merkle, această modificare va provoca o modificare a nodului de mai sus și apoi o modificare a nodului de deasupra aceluia, schimbând în cele din urmă rădăcina arborelui și, prin urmare, hash-ul blocului, determinând protocolul să îl înregistreze ca un bloc complet diferit (aproape sigur cu o dovadă nevalidă de lucru).

Protocolul arborelui Merkle este, fără îndoială, esențial pentru durabilitatea pe termen lung. Un „nod complet” în rețeaua Bitcoin, unul care stochează și procesează toate elementele fiecărui bloc, ocupă aproximativ 15 GB de spațiu pe disc în rețeaua Bitcoin începând cu aprilie 2014 și crește cu peste un gigabyte pe lună. În prezent, acest lucru este viabil pentru unele calculatoare desktop și nu pentru telefoane, și mai târziu, în viitor, numai întreprinderile și pasionații vor putea participa. Un protocol cunoscut sub numele de „verificare simplificată a plăților” (SPV) permite existența unei alte clase de noduri, numite „noduri ușoare”, care descarcă anteturile de bloc, verifică dovada muncii pe anteturile de bloc și apoi descarcă numai „ramurile” asociate cu tranzacțiile care sunt relevante pentru acestea. Acest lucru permite nodurilor ușoare să determine cu o garanție puternică a securității care este starea oricărei tranzacții Bitcoin, și echilibrul lor actual, doar descărcând o parte foarte mică a întregului blockchain.

Aplicații Alternative Blockchain

Ideea de a lua ideea blockchain de bază și de a o aplica altor concepte are, de asemenea, o istorie lungă. În 1998, Nick Szabo a venit cu conceptul de titluri de proprietate sigure cu autoritatea proprietarului, un document care descrie modul în care „noi progrese în tehnologia de baze de date replicate” va permite un sistem bazat pe blockchain pentru stocarea unui registru al celor care dețin un anumit teren, creând un cadru elaborat, care să includă concepte precum exploatarea fermieră, posesia adversă și impozitul pe teren georgian. Cu toate acestea, la momentul respectiv nu a existat, din păcate, niciun sistem eficient de baze de date replicate disponibil, și astfel protocolul nu a fost niciodată pus în aplicare în practică. După 2009 însă, odată ce consensul descentralizat al Bitcoin a fost dezvoltat, o serie de aplicații alternative au început să apară rapid.

Namecoin - creat în 2010, Namecoin este cel mai bine descris ca o bază de date descentralizată de înregistrare a numelui. În protocoalele descentralizate, cum ar fi Tor, Bitcoin și BitMessage, trebuie să existe o modalitate de identificare a conturilor, astfel încât alte persoane să poată interacționa cu ele, dar în toate soluțiile existente, singurul tip de identificator disponibil este un hash pseudo-aleatoriu ca 1LW79wp5ZBqaHW1jL5TCiBCQYtHagUWy. În mod ideal, cineva ar dori să poată avea un cont cu un nume ca „george”. Cu toate acestea, problema este că, dacă o persoană poate crea un cont numit „george”, atunci altcineva poate folosi același proces pentru a înregistra „george” pentru ei înșiși, precum și să le impersonalizeze. Singura soluție este modelul „first-to-file”, unde primul care înregistrează reușește și al doilea eșuează - o problemă perfect potrivită pentru protocolul de consens Bitcoin. Namecoin este cea mai veche și cea mai de succes implementare a unui sistem de înregistrare a numelui folosind o astfel de idee.
Monede colorate - scopul monedelor colorate este de a servi ca protocol pentru a permite oamenilor să-și creeze propriile monede digitale - sau, în cazul banal important al unei monede cu o unitate, tokenuri digitale, pe blockchain-ul Bitcoin. În protocolul de monede colorate, cineva „emite” o nouă monedă prin atribuirea publică a unei culori la un anumit Bitcoin UTXO, iar protocolul definește în mod recursiv (repetitiv), culoarea altor UTXO pentru a fi aceeași cu culoarea intrării pe care tranzacția care le-a creat o folosește (se aplică unele reguli speciale în cazul intrărilor de culori mixte). Acest lucru permite utilizatorilor să mențină portofele care conțin numai UTXO de o anumită culoare și le folosesc în operațiunile lor ca bitcoin-uri obișnuite, urmărind înapoi prin blockchain pentru a determina culoarea oricărui UTXO pe care îl primesc.
Metacoins - ideea din spatele unei metacoin este de a avea un protocol bazat pe Bitcoin, folosind tranzacții Bitcoin pentru a stoca tranzacții cu metacoin, dar având o funcție de tranziție de stare diferită, APLPPLY'. Deoarece protocolul metacoin nu poate împiedica apariția tranzacțiilor metacoin nevalide în blockchain-ul Bitcoin, se adaugă o regulă conform căreia dacă APPLY'(S,TX) returnează o eroare, protocolul implicit este APPLY'(S,TX) = S. Aceasta oferă un mecanism ușor pentru crearea unui protocol arbitrar de criptomonedă, potențial cu funcții avansate care nu pot fi implementate în interiorul Bitcoin în sine, dar cu un cost de dezvoltare foarte scăzut, odată ce complexitatea mineritului și a rețelelor este deja gestionată de protocolul Bitcoin. Cripomonedele metacoin au fost utilizate pentru implementarea unor clase de contracte financiare, înregistrarea numelor și schimbul descentralizat.

Astfel, în general, există două abordări către construirea unui protocol de consens: construirea unei rețele independente și construirea unui protocol bazat pe Bitcoin. Fosta abordare, deși are un succes rezonabil în cazul aplicațiilor precum Namecoin, este dificil de implementat; fiecare implementare individuală trebuie să acroșeze (bootstrap) un blockchain independent, precum și construirea și testarea tuturor tranzițiilor de stare necesară și codurilor de rețea. În plus, anticipăm că setul de aplicații pentru tehnologia consensului descentralizat va urma o distribuție a legii puterii în care marea majoritate a aplicațiilor ar fi prea mici pentru a-și justifica propriul blockchain și observăm că există clase mari de aplicații descentralizate, în special organizații autonome descentralizate, care trebuie să interacționeze între ele.

Abordarea bazată pe Bitcoin, pe de altă parte, are defectul că nu moștenește caracteristicile simplificate ale Bitcoin de verificare a plăților. SPV funcționează pentru Bitcoin, deoarece poate utiliza adâncimea blockchain-ului ca un proxy pentru valabilitate; la un moment dat, odată ce strămoșii unei tranzacții merg destul de departe înapoi, este sigur să spunem că au fost în mod legitim parte a stării. Pe de altă parte, metaprotocoalele bazate pe blockchain nu pot forța blockchain-ul să nu includă tranzacții care nu sunt valabile în contextul propriilor protocoale. Prin urmare, o implementare pe deplin securizată de metaprotocol SPV, ar trebui să scaneze înapoi tot drumul până la începutul blockchain-ului Bitcoin pentru a determina dacă anumite tranzacții sunt sau nu valabile. În prezent, toate implementările „ușoare” de Bitcoin pe bază de metaprotocoale se bazează pe un server de încredere pentru a furniza date, fără îndoială, un rezultat extrem de suboptim mai ales atunci când unul dintre scopurile primare ale unei criptomonede este de a elimina nevoia de încredere.

Scripturi

Chiar și fără extensii, protocolul Bitcoin facilitează de fapt o versiune slabă a unui concept de „contracte inteligente”. UTXO în Bitcoin poate fi deținut nu doar de o cheie publică, ci și de un script mai complicat exprimat într-un limbaj de programare simplu bazat pe stivă. În această paradigmă, o tranzacție care cheltuiește acest UTXO trebuie să furnizeze date care satisfac scriptul. Într-adevăr, chiar și mecanismul de bază de proprietate a unei chei publice este implementat printr-un script: scriptul ia ca intrare o semnătură curbă eliptică, o verifică în raport cu tranzacția și adresa care deține UTXO și returnează 1 dacă verificarea are succes sau 0 în caz contrar. Alte, scripturi mai complicate, există pentru diferite cazuri de utilizare suplimentare. De exemplu, se poate construi un script care necesită semnături din două dintre trei anumite chei private pentru a valida („multisig”), o configurare utilă pentru conturile corporative, conturile de economii sigure și unele situații de comerț fiduciar. Scripturile pot fi, de asemenea, folosite pentru plata de recompense pentru soluționarea de probleme de calcul, și se poate construi chiar și un script care spune ceva de genul „acest Bitcoin UTXO este al tău, dacă poți oferi o dovadă SPV că mi-ai trimis o tranzacție Dogecoin de această denumire”, permițând, în esență, schimbul încrucișat descentralizat de criptomonede.

Cu toate acestea, limbajul de scripturi implementat în Bitcoin are mai multe limitări importante:

Lipsa exhaustivității Turing - adică, în timp ce există un subset mare de calcule pe care limbajul de script Bitcoin le acceptă, acesta nu suportă totul. Principala categorie care lipsește este funcția de bucle. Acest lucru se face pentru a evita bucle infinite în timpul verificării tranzacției; teoretic este un obstacol de depășit pentru programatorii de scripturi, deoarece orice buclă poate fi simulată prin simpla repetare a codului de bază de multe ori cu o instrucțiune if, dar conduce la scripturi care sunt foarte ineficiente în spațiu. De exemplu, implementarea unui algoritm alternativ de semnare a curbei eliptice ar necesita probabil 256 de runde de multiplicare repetate, toate incluse individual în cod.
Orbire-Valorică - nu există nicio modalitate pentru ca un script UTXO să ofere un control fin asupra cantității care poate fi retrasă. De exemplu, un caz puternic de utilizare al unui contract oracol ar fi un contract de asigurare hedge, în care A și B introduc BTC în valoare de $1.000 USD, iar după 30 de zile scriptul trimite BTC în valoare de 1.000 USD către A, iar restul către B. Acest lucru ar necesita un oracol pentru a determina valoarea unui BTC în USD, dar chiar și atunci este o îmbunătățire masivă în ceea ce privește încrederea și cerințele de infrastructură față de soluțiile complet centralizate care sunt disponibile acum. Cu toate acestea, deoarece UTXO sunt totul-sau-nimic, singura modalitate de a realiza acest lucru este prin hack-ul foarte ineficient de a avea mai multe UTXO de diferite denominații (de exemplu, un UTXO de 2^k pentru fiecare k până la 30) și de a alege O care UTXO îl trimite la A și care la B.
Lipsa stării - UTXO poate fi cheltuit sau necheltuit; nu există nicio oportunitate pentru contracte în mai multe etape sau scripturi care să mențină orice altă stare internă dincolo de aceasta. Acest lucru face dificilă încheierea de contracte de opțiuni în mai multe etape, oferte de schimb descentralizate sau protocoale de angajament criptografice în două etape (necesare pentru recompense de calcul sigure). De asemenea, înseamnă că UTXO poate fi utilizat doar pentru a construi contracte simple, unice și nu contracte mai complexe „fără stare”, cum ar fi organizațiile descentralizate și face dificilă implementarea metaprotocoalelor. Starea binară combinată cu orbirea valorică înseamnă, de asemenea, că o altă aplicație importantă, limitele de retragere, este imposibilă.
Orbire-Blockchain - UTXO sunt oarbe la date blockchain, cum ar fi nonce, marca temporală și hash-ul blocului anterior. Acest lucru limitează sever aplicații cum ar fi jocurile de noroc și alte câteva categorii, privând limbajul de script de o sursă potențială de elemente aleatorii.

Astfel, vedem trei abordări pentru construirea de aplicații avansate pe bază de criptomonedă: construirea unui nou blockchain, utilizarea scripturilor bazate pe Bitcoin și construirea unui metaprotocol bazat pe Bitcoin. Construirea unui nou blockchain permite libertatea nelimitată în construirea unui set de caracteristici, dar cu prețul timpului de dezvoltare, a efortului de bootstrap și a securității. Utilizarea scripturilor este ușor de implementat și standardizat, dar este foarte limitată în ceea ce privește capacitățile sale, iar metaprotocoalele, deși sunt ușoare, suferă de defecte în scalabilitate. Cu Ethereum, intenționăm să construim un cadru alternativ care să ofere câștiguri și mai mari în ceea ce privește ușurința dezvoltării, precum și proprietăți și mai puternice ale clientului ușor, permițând în același timp aplicațiilor să partajeze un mediu economic și de securitate blockchain.

Ethereum

Intenția Ethereum este de a crea un protocol alternativ pentru construirea de aplicații descentralizate, oferind un set diferit de compromisuri care credem că va fi foarte util pentru o mare clasă de aplicații descentralizate, cu un accent deosebit pe situații în care timpul de dezvoltare rapidă, securitatea pentru aplicațiile mici și rar utilizate, precum și capacitatea diferitelor aplicații de a interacționa foarte eficient sunt importante. Ethereum face acest lucru prin construirea a ceea ce este, în esență, nivelul fundamental abstract final: un blockchain cu un limbaj de programare built-in Turing-complet, care permite oricui să scrie contracte inteligente și aplicații descentralizate în care ei pot crea propriile reguli arbitrare pentru proprietate, formatele de tranzacție și funcțiile de tranziție de stare. O versiune de bază a Namecoin poate fi scrisă în două linii de cod, iar alte protocoale, cum ar fi monedele și sistemele de reputație pot fi construite în mai puțin de douăzeci de minute. Contracte inteligente, „cutii” criptografice care conțin valoare și o deblochează numai dacă sunt îndeplinite anumite condiții, pot fi, de asemenea, construite pe această platformă, cu mult mai multă putere decât cea oferită de scriptul Bitcoin din cauza puterilor adăugate de exhaustivitatea-Turing, valoarea-conștientizată, blockchain-conștientizat și starea.

Filozofie

Designul din spatele Ethereum este destinat să urmeze următoarele principii:

Simplitate: protocolul Ethereum ar trebui să fie cât mai simplu posibil, chiar și cu prețul unor stocări de date sau ineficiență de timp.^{fn. 3} În mod ideal, un programator mediu ar trebui să poată urmări și implementa întreaga specificație, ^{fn. 4} astfel încât să realizăm pe deplin potențialul de democratizare fără precedent pe care îl aduce criptomoneda și să promoveze viziunea Ethereum ca protocol deschis tuturor. Orice optimizare care adaugă complexitate nu ar trebui inclusă decât dacă oferă beneficii foarte substanțiale.
Universalitatea: o parte fundamentală a filozofiei de proiectare a Ethereum este că Ethereum nu are „caracteristici”.^{fn. 5} În schimb, Ethereum oferă un limbaj de script intern Turing-complet, pe care un programator îl poate folosi pentru a construi orice tip de contract inteligent sau tranzacție care poate fi definit matematic. Dorești să inventezi propriul tău instrument financiar derivat? Cu Ethereum, poți. Vrei să-ți faci propria monedă? Configureaz-o ca un contract Ethereum. Dorești să configurezi un Daemon sau Skynet la scară largă? Este posibil să trebuiască să ai câteva mii de contracte și să te asiguri că le hrănești cu generozitate, pentru a face acest lucru, dar nimic nu te oprește cu Ethereum la îndemână.
Modularitate: părțile protocolului Ethereum ar trebui să fie proiectate astfel încât să fie cât mai modulare și separabile. Pe parcursul dezvoltării, obiectivul nostru este să creăm un program în care, dacă se va face o mică modificare de protocol într-un singur loc, stiva de aplicații ar continua să funcționeze fără alte modificări. Inovații precum Ethash (vezi Anexa la Yellow Paper sau articolul wiki), arborii Patricia modificați (Yellow Paper, wiki) și RLP (YP, wiki) ar trebui să fie și sunt implementate ca biblioteci separate, complete cu caracteristici. Acest lucru se întâmplă astfel încât, deși sunt utilizate în Ethereum, chiar dacă Ethereum nu necesită anumite caracteristici, astfel de caracteristici sunt încă utilizabile și în alte protocoale. Dezvoltarea Ethereum ar trebui realizată la maximum, astfel încât să beneficieze întregul ecosistem al criptomonedelor, nu doar tu însuți.
Agilitate: detaliile protocolului Ethereum nu sunt bătute în piatră. Deși vom fi extrem de prudenți în ceea ce privește modificările la construcțiile de nivel înalt, de exemplu, cu foaia de parcurs a fragmentelor, abstractizarea executării, cu disponibilitatea datelor doar consacrată în consens. Testele de calcul ulterioare în procesul de dezvoltare ne pot determina să descoperim că anumite modificări, de exemplu, la arhitectura protocolului sau la Mașina Virtuală Ethereum (EVM), vor îmbunătăți în mod substanțial scalabilitatea sau securitatea. Dacă se găsesc astfel de oportunități, le vom exploata.
Fără discriminare și fără cenzură: protocolul nu ar trebui să încerce să restricționeze în mod activ sau să prevină anumite categorii de utilizare. Toate mecanismele de reglementare din protocol ar trebui să fie concepute pentru a reglementa direct prejudiciul și să nu încerce să se opună unor aplicații nedorite specifice. Un programator poate rula chiar și un script cu buclă infinită în Ethereum atâta timp cât este dispus să plătească în continuare taxa de tranzacție per pas de calcul.

Conturile Ethereum

În Ethereum, starea este alcătuită din obiecte numite „conturi”, fiecare cont având o adresă de 20 de byți, iar tranzițiile de stare sunt transferuri directe de valoare și informații între conturi. Un cont Ethereum conține patru câmpuri:

Nonce, un contor utilizat pentru a asigura că fiecare tranzacție poate fi procesată o singură dată
Soldul de eter actual al contului curent
Codul contractului contului, dacă este prezent
Stocarea contului (gol implicit)

Eter este principalul cripto-combustibil intern al Ethereum și este utilizat pentru plata taxelor de tranzacție. În general, există două tipuri de conturi: conturi deținute extern, controlate de chei private și conturi de contract, controlate de codul lor de contract. Un cont deținut extern nu are cod și cineva poate trimite mesaje dintr-un cont deținut extern prin crearea și semnarea unei tranzacții; într-un cont de contract, de fiecare dată când contul de contract primește un mesaj, codul său se activează, permițându-i să citească și să scrie în stocarea internă și să trimită alte mesaje sau să creeze contracte la rândul său.

Reține că aceste „contracte” din Ethereum nu trebuie văzute ca ceva care ar trebui „îndeplinit” sau „respectat”; mai degrabă seamănă cu „agenți autonomi” care trăiesc în interiorul mediului de execuție Ethereum, executând întotdeauna o anumită bucată de cod atunci când sunt „împinși” de un mesaj sau tranzacție și având controlul direct asupra propriului echilibru de eter și propriul depozit de chei/valori pentru a urmări variabilele persistente.

Mesaje și tranzacții

Termenul „tranzacție” este utilizat în Ethereum pentru a se referi la pachetul de date semnat care stochează un mesaj care trebuie trimis dintr-un cont deținut extern. Tranzacțiile conțin:

Destinatarul mesajului
Semnătura care identifică expeditorul
Cantitatea de eter de transferat de la expeditor la destinatar
Un câmp de date opțional
Valoarea STARTGAS, reprezentând numărul maxim de pași de calcul pe care tranzacția este permisă să-i execute
Valoare GASPRICE, reprezentând comisionul pe care expeditorul îl plătește pe fiecare pas de calcul

Primele trei sunt câmpuri standard așteptate în orice criptomonedă. Câmpul de date nu are nicio funcție în mod implicit, dar mașina virtuală are un cod de operare pe care un contract îl poate utiliza pentru a accesa datele; un exemplu de utilizare este când un contract funcționează ca un serviciu de înregistrare a domeniului pe blockchain, atunci poate dori să interpreteze datele care i-au fost transmise ca și cum ar conține două „câmpuri”, primul câmp fiind un domeniu de înregistrat și al doilea câmpul fiind adresa IP la care să-l înregistreze. Contractul ar citi aceste valori din datele mesajului și le va pune în mod corespunzător în stocare.

Câmpurile STARTGAS și GASPRICE sunt cruciale pentru modelul antinegare a serviciului Ethereum. Pentru a preveni buclele infinite accidentale sau ostile sau alte pierderi de calcul din cod, fiecare tranzacție trebuie să stabilească o limită a numărului de pași de calcul de execuție a codului pe care îi poate folosi. Unitatea fundamentală de calcul este „gazul”; de obicei, un pas de calcul costă 1 gaz, dar unele operațiuni costă cantități mai mari de gaz, deoarece sunt mai scumpe din punct de vedere al calculului sau măresc cantitatea de date care trebuie stocate ca parte a stării. Există, de asemenea, o taxă de 5 gaz pentru fiecare byte în datele tranzacției. Intenția sistemului de taxare este de a cere unui atacator să plătească proporțional pentru fiecare resursă pe care o consumă, inclusiv calculul, lățimea de bandă și stocarea; prin urmare, orice tranzacție care face ca rețeaua să consume o cantitate mai mare din oricare dintre aceste resurse trebuie să aibă o taxă de gaz aproximativ proporțională cu creșterea.

Mesaje

Contractele au capacitatea de a trimite „mesaje” către alte contracte. Mesajele sunt obiecte virtuale care nu sunt niciodată serializate și există doar în mediul de execuție Ethereum. Un mesaj conține:

Expeditorul mesajului (implicit)
Destinatarul mesajului
Cantitatea de eter de transferată cu mesajul
Un câmp de date opțional
O valoare STARTGAS

În esență, un mesaj este ca o tranzacție, cu excepția faptului că este produs de un contract și nu de un actor extern. Un mesaj este produs atunci când un contract care execută codul execută opcodul CALL, care produce și execută un mesaj. Asemenea unei tranzacții, un mesaj duce la contul destinatarului care își execută codul. Astfel, contractele pot avea relații cu alte contracte exact în același mod în care pot avea actorii externi.

A se reține că alocația de gaz atribuită unei tranzacții sau contract se aplică gazului total consumat de acea tranzacție și tuturor sub-execuțiilor. De exemplu, dacă un actor extern A trimite o tranzacție către B cu 1.000 de gaz, iar B consumă 600 de gaz înainte de a trimite un mesaj către C, iar executarea internă a lui C consumă 300 de gaz înainte de întoarcere, atunci B poate cheltui încă 100 de gaz înainte de a rula fără combustibil.

Funcția de tranziție a stării Ethereum

Funcția de tranziție a stării Ethereum, APPLY(S,TX) -> S' poate fi definită după urmează:

Verifică dacă tranzacția este bine formată (de exemplu, are numărul corect de valori), semnătura este valabilă, iar nonce-ul se potrivește cu nonce-ul din contul expeditorului. Dacă nu, întoarce o eroare.
Calculează taxa de tranzacție ca STARTGAS * GASPRICE și determină adresa de trimitere din semnătură. Scade taxa din soldul contului expeditorului și incrementează nonce-ul expeditorului. Dacă nu există un sold suficient pentru a cheltui, întoarce o eroare.
Inițializează GAS = STARTGAS și scoate o anumită cantitate de gaz pe byte pentru a plăti pentru byți din tranzacție.
Transferă valoarea tranzacției din contul expeditorului în contul de primire. În cazul în care contul de primire nu există încă, îl creează. În cazul în care contul de primire este un contract, execută codul contractului, fie până la finalizarea contractului, fie până când execuția rămâne fără gaz.
Dacă transferul de valori nu a reușit, deoarece expeditorul nu a avut suficienți bani sau executarea codului a rămas fără gaz, anulează toate schimbările de stare, cu excepția plății taxelor, și adaugă taxele în contul minerului.
În caz contrar, rambursează expeditorului taxele pentru toate gazele rămase și trimite taxele plătite pentru gazul consumat minerului.

Să presupunem că avem un contract cu acest cod:

if !self.storage[calldataload(0)]:
    self.storage[calldataload(0)] = calldataload(32)

Reține că, în realitate, codul contractului este scris în cod EVM de nivel scăzut; acest exemplu este scris în Serpent, unul dintre limbajele noastre de nivel înalt, pentru claritate, și poate fi compilat în codul EVM. Să presupunem că stocarea contractului începe goală și că o tranzacție este trimisă cu o valoare de 10 eter, 2.000 gaz, 0,001 gasprice de eter și 64 de byți de date, cu byți 0-31 reprezentând numărul 2 și byți 32-63 care reprezintă șirul CHARLIE. ^{fn. 6} Procesul pentru funcția de tranziție de stare în acest caz este după urmează:

Verifică dacă tranzacția este validă și bine formată.
Verifică dacă expeditorul tranzacției are cel puțin 2.000 * 0,001 = 2 eter. Dacă este, atunci scade 2 eter din contul expeditorului.
Gazul inițial = 2.000; dacă presupunem că tranzacția are o lungime de 170 byți și taxa pe byte este de 5, scade 850, astfel încât să rămână 1.150 de gaz.
Scade încă 10 eter din contul expeditorului și îi adaugă în contul contractului.
Rulează codul. În acest caz, acest lucru este simplu: se verifică dacă se utilizează stocarea contractului la indexul 2, observă că nu este, și astfel se setează stocarea la indexul 2 la valoarea CHARLIE. Să presupunem că acest lucru ia 187 de gaz, astfel încât cantitatea rămasă de gaz este de 1.150 - 187 = 963
Adăugă 963 * 0,001 = 0,963 eter înapoi în contul expeditorului și returnează starea rezultată.

Dacă nu a existat niciun contract la finalul tranzacției, atunci taxa totală de tranzacție ar fi pur și simplu egală cu valoarea GASPRICE înmulțită cu durata tranzacției în byți, iar datele trimise împreună cu tranzacția ar fi irelevante.

Reține că mesajele funcționează similar cu tranzacțiile în ceea ce privește revenirile: dacă o execuție de mesaj rămâne fără gaz, atunci execuția acelui mesaj și toate celelalte execuții declanșate de acea execuție revin, dar execuțiile părinte nu trebuie să revină. Aceasta înseamnă că este „sigur” ca un contract să solicite un alt contract, ca și cum A ar apela B cu gaz G, atunci execuția lui A este garantată că va pierde cel mult G gaz. În cele din urmă, reține că există un opcod, CREATE, care creează un contract; mecanica sa de execuție este în general similară cu CALL, cu excepția că rezultatul execuției determină codul unui contract nou creat.

Executarea codului

Codul din contractele Ethereum este scris într-un limbaj bytecode, de nivel scăzut, bazat pe stivă, denumit „codul mașinii virtuale Ethereum” sau „codul EVM”. Codul constă dintr-o serie de byți, în care fiecare byte reprezintă o operație. În general, execuția codului este o buclă infinită care constă din efectuarea în mod repetat a operației la contorul programului curent (care începe la zero) și apoi creșterea incrementală a contorului programului cu unul, până când se ajunge la sfârșitul codului sau se detectează o instrucțiune de eroare sau STOP sau RETURN. Operațiunile au acces la trei tipuri de spații în care să stocheze date:

Stiva, un container „last-in-first-out” (LIFO) către care valorile pot fi împinse și introduse
Memorie, o matrice de byți extensibilă infinit
Stocarea pe termen lung a contractului, un depozit de chei/valori. Spre deosebire de stivă și memorie, care se resetează după terminarea calculului, stocarea persistă pe termen lung.

De asemenea, codul poate accesa valoarea, expeditorul și datele mesajului primit, precum și datele antetului blocului, iar codul poate returna, de asemenea, o matrice de byți de date ca ieșire.

Modelul formal de execuție al codului EVM este surprinzător de simplu. În timp ce mașina virtuală Ethereum rulează, starea sa completă de calcul poate fi definită de secvența de variabile (block_state, transaction, message, code, memory, stack, pc, gas), unde block_state este starea globală care conține toate conturile și include solduri și stocarea. La începutul fiecărei runde de execuție, instrucțiunea curentă se găsește luând byte-ul pc al codului (sau 0 dacă pc >= len (cod)) și fiecare instrucțiune are propria definiție în ceea ce privește modul în care afectează secvența de variabile. De exemplu, ADD scoate două articole din stivă și împinge suma lor, reduce gas cu 1 și crește pc cu 1, iar SSTORE scoate primele două articole din stivă și introduce al doilea articol în stocarea contractului la indexul specificat de primul articol. Deși există multe modalități de a optimiza execuția mașinii virtuale Ethereum prin compilare-din-mers, o implementare de bază a Ethereum se poate face în câteva sute de linii de cod.

Blockchain și minerit

Blockchain-ul Ethereum este în multe feluri similar cu blockchain-ul Bitcoin, deși are unele diferențe. Principala diferență dintre Ethereum și Bitcoin în ceea ce privește arhitectura blockchain este că, spre deosebire de Bitcoin (care conține doar o copie a listei de tranzacții), blocurile Ethereum conțin o copie a listei de tranzacții și cea mai recentă stare. În afară de aceasta, alte două valori, numărul blocului și dificultatea, sunt, de asemenea, stocate în bloc. Algoritmul de validare a blocului de bază în Ethereum este după cum urmează:

Verifică dacă blocul anterior la care se face referire există și este valid.
Verifică dacă marcajul temporal al blocului este mai mare decât cel al blocului anterior de referință și mai mic de 15 minute în viitor
Verifică dacă numărul blocului, dificultatea, rădăcina tranzacției, rădăcina unchiului și limita de gaz (diverse concepte specifice Ethereum de nivel scăzut) sunt valide.
Verifică dacă dovada muncii pe bloc este validă.
Stabilește S[0] ca stare la sfârșitul blocului anterior.
Stabilește TX să fie lista de tranzacții a blocului, cu n tranzacții. Pentru toate i în 0...n-1, setează S[i+1] = APPLY(S[i],TX[i]). Dacă orice aplicație returnează o eroare sau dacă gazul total consumat în bloc până la acest punct depășește GASLIMIT, returnează o eroare.
Lasă S_FINAL să fie S[n], dar adăugând recompensa bloc plătită minerului.
Verifică dacă rădăcina arborelui Merkle a stării S_FINAL este egală cu rădăcina de stare finală furnizată în antetul blocului. Dacă este egală, blocul este valid; în caz contrar, nu este valid.

Abordarea poate părea extrem de ineficientă la prima vedere, deoarece trebuie să stocheze întreaga stare cu fiecare bloc, dar în realitate eficiența ar trebui să fie comparabilă cu cea a Bitcoin. Motivul este că starea este stocată în structura arborelui, iar după fiecare bloc trebuie schimbată doar o mică parte a arborelui. Astfel, în general, între două blocuri adiacente marea majoritate a arborilor ar trebui să fie aceeași, și, prin urmare, datele pot fi stocate o dată și menționate de două ori folosind indicii (adică hash-uri de sub-arbori). Un tip special de arbore cunoscut sub numele de „arborele Patricia” este folosit pentru a realiza acest lucru, inclusiv o modificare a conceptului de arbore Merkle, care permite ca nodurile să fie inserate și șterse, și nu doar schimbate, eficient. În plus, deoarece toate informațiile de stare fac parte din ultimul bloc, nu este nevoie să fie stocată întreaga istorie a blockchain-ului - o strategie care, dacă ar putea fi aplicată la Bitcoin, se poate calcula că ar oferi o economie de 5-20 de ori în spațiu.

O întrebare frecventă este „unde” este executat codul contractului, în ceea ce privește hardware-ul fizic. Acest lucru are un răspuns simplu: procesul de executare a codului de contract face parte din definiția funcției de tranziție de stare, care face parte din algoritmul de validare al blocului, astfel încât, dacă o tranzacție este adăugată în blocul B, executarea codului generat de acea tranzacție va fi executată de toate nodurile, acum și în viitor, care descarcă și validează blocul B.

Aplicații

În general, există trei categorii de aplicații care funcționează pe Ethereum. În prima categorie sunt aplicațiile financiare, oferind utilizatorilor modalități mai puternice de gestionare și încheiere a contractelor folosind banii lor. Ele includ sub-monedele, instrumentele financiare derivate, contractele de acoperire a riscurilor, portofelele de economii, testamentele și, în final, chiar unele categorii de contracte de muncă pe scară largă. În a doua categorie sunt aplicațiile semi-financiare, în care sunt implicați bani, dar există, de asemenea, o latură grea nemonetară a ceea ce se face; un exemplu perfect este de auto-aplicarea de recompense pentru soluții la problemele de calcul. În cele din urmă, există aplicații precum votul on-line și guvernanța descentralizată care nu sunt deloc financiare.

Sisteme token

Sistemele token pe-blockchain au multe aplicații, de la sub-monede reprezentând active cum ar fi USD sau aur, la acțiunile companiei, tokenuri individuale reprezentând proprietăți inteligente, cupoane sigure nefalsificabile și chiar sisteme token fără legături la valori convenționale, utilizate ca sisteme de puncte pentru stimulare. Sistemele token sunt surprinzător de ușor de implementat în Ethereum. Ce trebuie să înțelegi este că o monedă, sau sistem de tokenuri, este o bază de date cu o singură operațiune: scade X unități de la A și adaugă X unități lui B, cu condiția ca (1) A să fi avut cel puțin X unități înainte de tranzacție și (2) tranzacția să fie aprobată de A. Tot ce este nevoie pentru a pune în aplicare un sistem de tokenuri este de a pune în aplicare această logică într-un contract.

Codul de bază pentru implementarea unui sistem de tokenuri în Serpent arată după urmează:

def send(to, value):
    if self.storage[msg.sender] >= value:
        self.storage[msg.sender] = self.storage[msg.sender] - value
        self.storage[to] = self.storage[to] + value

Aceasta este, în esență, implementare literală a „sistemului bancar” funcția de tranziție de stare descrisă mai sus în acest document. Câteva linii suplimentare de cod trebuie să fie adăugate pentru a asigura etapa inițială de distribuire a unităților monetare în primul rând și alte câteva cazuri de margine și, în mod ideal, ar trebui adăugată o funcție care să permită altor contracte să interogheze pentru soldul unei adrese. Dar asta e tot. Teoretic, sistemele token bazate pe Ethereum care acționează ca sub-monede pot include o altă caracteristică importantă pe care metamonedele bazate pe Bitcoin în-lanț nu o au: capacitatea de a plăti taxe de tranzacție direct în moneda respectivă. Modalitatea de implementare a acestui lucru este următoarea: contract menține soldul de eter cu cu care să ramburseze expeditorului eter utilizat pentru plata de taxe și reface soldul prin colectarea unităților valutare interne pe care le ia în taxe și revânzarea lor într-o licitație permanentă. Utilizatorii ar trebui, prin urmare, să „activeze” conturile lor cu eter, dar odată ce eterul este acolo ar fi reutilizabil, deoarece contractul ar rambursa de fiecare dată.

Instrumente financiare derivate și Monede cu Valoare Stabilă

Instrumentele financiare derivate sunt cea mai comună aplicație a unui „contract inteligent”, și una dintre cele mai simple de implementat în cod. Principala provocare în punerea în aplicare a contractelor financiare este că majoritatea acestora necesită trimiterea la un instrument bursier de prețuri extern; de exemplu, o aplicație foarte dezirabilă este un contract inteligent care să asigure volatilitatea eterului (sau a altei criptomonede) în raport cu dolarul SUA, dar acest lucru cere contractului să știe care este valoarea ETH/USD. Cel mai simplu mod de a face acest lucru este printr-un contract de „flux de date” menținut de o anumită parte (de exemplu. NASDAQ) conceput astfel încât acea parte are capacitatea de a actualiza contractul după cum este necesar, și oferind o interfață care permite altor contracte să trimită un mesaj la acel contract și a obține înapoi un răspuns care oferă prețul.

Având în vedere acest ingredient critic, contractul de acoperire împotriva riscurilor ar arăta după urmează:

Așteptă ca partea A să introducă 1.000 eter.
Așteptă ca partea B să introducă 1.000 eter.
Înregistrează valoarea în USD a 1.000 eter, calculată prin interogarea contractului de alimentare cu date, în stocare, să spunem că acest lucru este $x.
După 30 de zile, permite lui A sau B să „reactiveze” contractul pentru a trimite eter în valoare de $x (calculat la noul preț după interogarea contractului de alimentare cu date) la A, iar restul la B.

Un astfel de contract ar avea un potențial semnificativ în cripto-comerț. Una dintre principalele probleme citate despre criptomonedă este faptul că este volatilă; deși mulți utilizatori și comercianți ar dori securitatea și comoditatea de a utiliza active criptografice, ei nu ar dori să se confrunte cu perspectiva de a pierde 23% din valoarea fondurilor lor într-o singură zi. Până în prezent, soluția cea mai frecvent propusă a fost activele garantate de emitent; ideea este că un emitent creează o sub-monedă în care are dreptul de a emite și revoca unități și furnizează o unitate de monedă oricui le furnizează (off-line) cu o unitate a unui activ suport specificat (de exemplu, aur, USD). Emitentul promite apoi să furnizeze o unitate a activului suport oricui trimite înapoi o unitate a cripto-activului. Acest mecanism permite oricărui element non-criptografic să fie „elevat” la un activ criptografic, cu condiția ca emitentul să poată fi de încredere.

Cu toate acestea, în practică, emitenții nu sunt întotdeauna de încredere, iar în unele cazuri infrastructura bancară este prea slabă sau prea ostilă pentru ca astfel de servicii să existe. Instrumentele financiare derivate oferă o alternativă. Aici, în loc de un emitent unic care oferă fonduri pentru a susține un activ, o piață descentralizată de speculatori, pariind că prețul unui activ criptografic de referință (de exemplu ETH) va crește, va juca acest rol. Contrar emitenților, speculatorii nu au nicio opțiune să eșueze partea lor de negociere, deoarece contractul de asigurare le ține fondurile în garanție. Reține faptul că această abordare nu este pe deplin descentralizată, deoarece o sursă de încredere este în continuare necesară pentru un ticker de prețuri, deși discutabil, chiar și acest lucru este o îmbunătățire masivă în ceea ce privește reducerea cerințelor de infrastructură (spre deosebire de a fi un emitent, emiterea unui flux de informații privind prețurile nu necesită licențe și poate fi probabil clasificată drept libertatea cuvântului) și reducând potențialul de fraudă.

Sisteme de identitate și de reputație

Cea mai veche criptomonedă alternativă dintre toate, Namecoin, a încercat să utilizeze un blockchain ca Bitcoin pentru a oferi un sistem de înregistrare a numelui, unde utilizatorii își pot înregistra numele într-o bază de date publică alături de alte date. Cazul de utilizare citat major este pentru un sistem DNS, de mapare de nume de domenii, cum ar fi „bitcoin.org” (sau, în cazul Namecoin, „bitcoin.bit”) la o adresă IP. Alte cazuri de utilizare includ autentificarea prin e-mail și potențial, sisteme mai avansate de reputație. Iată contractul de bază de furnizare a unui sistem de înregistrare de nume asemănător cu Namecoin pe Ethereum:

def register(name, value):
    if !self.storage[name]:
        self.storage[name] = value

Contractul este foarte simplu; tot ce este o bază de date în interiorul rețelei Ethereum care poate fi adăugată, dar nu modificată sau eliminată. Oricine poate înregistra un nume cu o anumită valoare, iar acea înregistrare va rămâne pentru totdeauna. Un contract mai sofisticat de înregistrare a numelui va avea, de asemenea, o „clauză funcțională” care permite altor contracte să-l interogheze, precum și un mecanism pentru „proprietarul” (adică primul înregistrator) unui nume pentru a schimba datele sau a transfera proprietatea. Se poate adăuga chiar și reputație și funcționalitate web-of-trust.

Stocare descentralizată de fișiere

În ultimii ani, au apărut o serie de companii start-up noi populare de stocare online a fișierelor, cea mai proeminentă fiind Dropbox, care urmărește să permită utilizatorilor să încarce o copie de rezervă a discului lor dur pentru a fi stocat și accesat de pe orice dispozitiv dintr-un dosar special sincronizat, în schimbul unei taxe lunare. Cu toate acestea, în acest moment piața stocării fișierelor este uneori relativ ineficientă; o privire superficială la diverse soluții existente arată că, în special la bariera de netrecut a nivelului de 20-200 GB pe care nici cotele gratuite, nici reducerile la nivel de întreprindere nu pot să o treacă, prețurile lunare pentru costurile de stocare a fișierelor mainstream sunt de așa natură că plătești mai mult decât costul întregului disc dur într-o singură lună. Contractele Ethereum pot permite dezvoltarea unui ecosistem descentralizat de stocare a fișierelor, în care utilizatorii individuali pot câștiga cantități mici de bani prin închirierea propriilor discuri dure, iar spațiul neutilizat poate fi utilizat pentru a reduce în continuare costurile stocării fișierelor.

Elementul cheie care stă la baza unui astfel de dispozitiv ar fi ceea ce am numit „contractul Dropbox descentralizat”. Acest contract funcționează după cum urmează. În primul rând, se împart datele dorite în blocuri, criptând fiecare bloc pentru confidențialitate și se construiește un arbore Merkle din acestea. Se face apoi un contract cu regula că, la fiecare N blocuri, contractul ar alege un index aleatoriu în arborele Merkle (folosind hash-ul blocului anterior, accesibil din codul contractului, ca sursă aleatorie), și să dea X eter primei entități care furnizează o tranzacție simplificată de verificare a plății, ca o dovadă a dreptului de proprietate asupra blocului la acel index specific în arbore. Atunci când un utilizator dorește să-și descarce din nou fișierul, poate folosi un protocol de canal de microplată (de exemplu, plătește 1 szabo pe 32 kilobyți) pentru a recupera fișierul; cea mai eficientă abordare este ca plătitorul să nu publice tranzacția până la final, înlocuind în schimb tranzacția cu una ușor mai profitabilă cu același nonce după fiecare 32 de kilobyți.

O caracteristică importantă a protocolului este că, deși ar părea că cineva se încrede în mai multe noduri aleatorii care să nu decidă să uite fișierul, se poate reduce riscul aproape la zero, împărțind fișierul în mai multe bucăți prin partajare secretă și urmărind contractele pentru a vedea dacă fiecare bucată este încă în posesia unui nod. Dacă un contract plătește în continuare bani, acesta oferă criptografic o dovadă că cineva de acolo încă stochează fișierul.

Organizații autonome descentralizate

Conceptul general al unei „organizații autonome descentralizate” este cel al unei entități virtuale care are un anumit set de membri sau acționari care, probabil cu o majoritate de 67%, au dreptul să cheltuiască fondurile entității și să-i modifice codul. Membrii vor decide în mod colectiv modul în care organizația ar trebui să-și aloce fondurile. Metodele de alocare a fondurilor unui DAO ar putea varia de la recompense, salarii la mecanisme și mai exotice, cum ar fi o monedă internă pentru recompensarea muncii. Aceasta replică în esență capcanele legale ale unei companii tradiționale sau nonprofit, dar folosind doar tehnologia blockchain criptografică pentru punerea în aplicare. Până în prezent, cele mai multe discuții despre DAO s-au bazat pe modelul „capitalist” al unei „societăți autonome descentralizate” (DAC) cu acționari care primesc dividende și acțiuni tranzacționale; o alternativă, probabil descrisă ca fiind o „comunitate autonomă descentralizată”, ar avea un procentaj egal în procesul decizional și ar necesita ca 67% dintre membrii existenți să fie de acord să adauge sau să elimine un membru. Cerința ca o persoană să poată avea o singură calitate de membru ar trebui apoi să fie pusă în aplicare în mod colectiv de către grup.

O schemă generală pentru cum să codezi un DAO este următoarea. Cel mai simplu design este pur și simplu o bucată de cod auto-modificat care se schimbă dacă două treimi dintre membri sunt de acord asupra unei modificări. Deși codul este teoretic imuabil, aceasta se poate ocoli ușor și poate avea o mutabilitate de facto, având bucăți de cod în contracte separate și având adresa contractelor de apelat stocate în stocarea modificabilă. Într-o simplă implementare a unui astfel de contract DAO, ar exista trei tipuri de tranzacții, care se disting prin datele furnizate în tranzacție:

[0, i, K, V] pentru a înregistra o propunere cu indexul i pentru a schimba adresa la indexul de stocare K la valoarea V
[1, i] pentru a înregistra un vot în favoarea propunerii i
[2, i] pentru a finaliza propunerea i dacă s-au obținut suficiente voturi

Contractul va avea apoi clauze pentru fiecare dintre acestea. Acesta va menține o evidență a tuturor modificărilor de stocare deschise, împreună cu o listă a celor care le-au votat. De asemenea, ar avea o listă cu toți membrii. Atunci când orice modificare de stocare ajunge la două treimi din membrii care votează pentru aceasta, o tranzacție finală ar putea executa modificarea. Un schelet mai sofisticat ar avea, de asemenea, capacitatea de vot încorporată pentru funcții precum trimiterea unei tranzacții, adăugarea de membri și eliminarea membrilor și poate prevedea chiar delegarea de vot în stilul Democrației lichide (adică oricine poate desemna pe cineva să voteze pentru ei și atribuirea este tranzitivă, deci dacă A atribuie lui B și B atribuie lui C atunci C determină votul lui A). Această concepție ar permite DAO să crească organic ca o comunitate descentralizată, permițând oamenilor să delege în cele din urmă sarcina de a filtra cine este membru al specialiștilor, deși, spre deosebire de „sistemul actual”, specialiștii pot să apară și să iasă din existență de-a lungul timpului, deoarece membrii individuali ai comunității își modifică poziția.

Un model alternativ este pentru o corporație descentralizată, în care orice cont poate avea zero sau mai multe acțiuni, iar două treimi din acțiuni sunt necesare pentru a lua o decizie. Un schelet complet ar implica funcționalitatea de gestionare a activelor, capacitatea de a face o ofertă de cumpărare sau vânzare de acțiuni și capacitatea de a accepta oferte (de preferință cu un mecanism de ordonare a comenzilor în cadrul contractului). Delegația ar exista, de asemenea, în stilul Democrației Lichide, generalizând conceptul de „consiliu de administrație”.

Alte aplicații

1. Portofele de economii. Să presupunem că Alice vrea să-și păstreze fondurile în siguranță, dar este îngrijorată că va pierde sau că cineva îi va pirata cheia privată. Ea pune eter într-un contract cu Bob, o bancă, după cum urmează:

Alice singură poate retrage maxim 1% din fonduri pe zi.
Bob singur poate retrage maxim 1% din fonduri pe zi, dar Alice are capacitatea de a efectua o tranzacție cu cheia ei închizând această abilitate.
Alice și Bob împreună pot retrage orice.

În mod normal, 1% pe zi este suficient pentru Alice și, dacă Alice dorește să retragă mai mult, îl poate contacta pe Bob pentru ajutor. În cazul în care cheia lui Alice este piratată, ea aleargă la Bob pentru a muta fondurile într-un nou contract. Dacă ea își pierde cheia, Bob va scoate fondurile în cele din urmă. Dacă Bob se dovedește a fi rău intenționat, atunci ea îl poate bloca în capacitatea sa de a retrage.

2. Asigurarea culturilor. Se poate face cu ușurință un contract de instrumente financiare derivate utilizând un flux de date al vremii în locul oricărui index de preț. Dacă un fermier din Iowa cumpără un instrument financiar derivat care plătește invers în funcție de precipitațiile din Iowa, atunci dacă este secetă, fermierul va fi plătit automat, iar dacă plouă suficient, fermierul va fi fericit, deoarece îi merge bine culturii lui. Aceasta se poate extinde la asigurarea împotriva dezastrelor naturale în general.

3. Un flux de date descentralizat. Pentru contractele financiare pentru diferență, de fapt este posibilă descentralizarea fluxului de date printr-un protocol numit SchellingCoin. SchellingCoin funcționează în principiu după cum urmează: N părți, pun toate în sistem valoarea unei date de referință (de exemplu, prețul ETH/USD), valorile sunt sortate și toți cei între procentajul de 25 și 75 la sută primesc un token ca recompensă. Toată lumea are stimulentul de a oferi răspunsul pe care îl vor oferi toți ceilalți, iar singura valoare pe care un număr mare de jucători pot să cadă de acord în mod realist este implicit evident: adevărul. Acest lucru creează un protocol descentralizat care poate oferi teoretic orice număr de valori, inclusiv prețul ETH/USD, temperatura din Berlin sau chiar rezultatul unui anumit calcul dur.

4. Garanția Escrow inteligentă cu multiple semnături. Bitcoin permite contracte de tranzacții cu mai multe semnături în care, de exemplu, trei din cinci chei date pot cheltui fondurile. Ethereum permite mai multă granularitate; de exemplu, patru din cinci pot cheltui totul, trei din cinci pot cheltui până la 10% pe zi, iar doi din cinci pot cheltui până la 0,5% pe zi. În plus, Ethereum multisig este asincron - două părți își pot înregistra semnăturile pe blockchain în momente diferite, iar ultima semnătură va trimite automat tranzacția.

5. Cloud computing. Tehnologia EVM poate fi utilizată și pentru a crea un mediu de calcul verificabil, permițând utilizatorilor să solicite altora să efectueze calcule și apoi, opțional, să solicite dovezile corectitudinii calculelor la anumite puncte de control selectate aleatoriu. Acest lucru permite crearea unei piețe de cloud computing în care orice utilizator poate participa cu desktopul, laptopul sau serverul specializat, iar verificarea prin sondaj împreună cu depozitele de securitate pot fi utilizate ca să asigure că sistemul este de încredere (și anume, nodurile nu pot trișa profitabil). Totuși, un astfel de sistem poate să nu fie potrivit pentru toate sarcinile; sarcinile care necesită un nivel ridicat de comunicare între procese, de exemplu, nu pot fi realizate cu ușurință pe un nor mare de noduri. Cu toate acestea, alte sarcini sunt mult mai ușor de paralelizat; proiecte precum SETI@home, folding@home și algoritmi genetici pot fi ușor implementate pe o astfel de platformă.

6. Jocuri de noroc peer-to-peer. Orice număr de protocoale de jocuri de noroc peer-to-peer, cum ar fi Frank Stajano și Cyberdice a lui Richard Clayton, pot fi implementate pe blockchain-ul Ethereum. Cel mai simplu protocol de jocuri de noroc este de fapt pur și simplu un contract pentru diferențierea pe următorul hash de bloc, iar protocoale mai avansate pot fi construite de acolo, creând servicii de jocuri de noroc cu taxe aproape zero care nu au capacitatea de a trișa.

7. Piețe de predicție. Odată furnizat un oracol sau un SchellingCoin, piețele de predicție sunt, de asemenea, ușor de implementat, iar piețele de predicție împreună cu SchellingCoin se pot dovedi a fi prima aplicație principală a futarchy-ei ca protocol de guvernanță pentru organizațiile descentralizate.

8. Piețe descentralizate în lanț, folosind sistemul de identitate și reputație ca bază.

Diverse și preocupări

Implementare GHOST modificată

Protocolul „Greedy Heaviest Observed Subtree” (GHOST) este o inovație introdusă pentru prima dată de Yonatan Sompolinsky și Aviv Zohar în decembrie 2013. Motivația din spatele GHOST este că blockchain-urile cu timp de confirmare rapidă suferă în prezent de o securitate redusă din cauza unei rate vechi ridicate - deoarece blocurile iau un anumit timp pentru a se propaga prin rețea, dacă minerul A extrage un bloc și apoi minerul B se întâmplă să exploateze un alt bloc înainte ca blocul minerului A să se propage către B, blocul minerului B va ajunge să fie risipit și nu va contribui la securitatea rețelei. Mai mult, există o problemă de centralizare: dacă minerul A este o piscină minieră cu 30% hashpower și B are 10% hashpower, A va risca să producă un bloc vechi 70% din timp (în timp ce în restul de 30% din timp A produce ultimul bloc și astfel va obține date miniere imediat), în timp ce B va risca să producă un bloc vechi 90% din timp. Astfel, dacă intervalul de blocare este suficient de scurt pentru ca rata de învechire să fie mare, A va fi substanțial mai eficient pur și simplu în virtutea mărimii sale. Cu aceste două efecte combinate, blockchain-urile care produc blocuri rapid sunt foarte susceptibile de a conduce la o singură piscină minieră cu un procent suficient de mare din puterea hash a rețelei pentru a avea un control de facto asupra procesului minier.

Așa cum este descris de Sompolinsky și Zohar, GHOST rezolvă prima problemă a pierderii securității rețelei prin includerea blocurilor vechi în calcularea cărui lanț este „cel mai lung”; adică nu doar părintele și strămoșii strămoșilor unui bloc, ci și descendenții învechiți ai strămoșului blocului (în jargonul Ethereum, „unchii”) se adaugă la calcularea cărui bloc are cea mai mare dovadă totală a muncii care îl suportă. Pentru a rezolva a doua problemă a prejudecății centralizării, mergem dincolo de protocolul descris de Sompolinsky și Zohar și oferim, de asemenea, recompense pentru blocurile vechi: un bloc vechi primește 87,5% din recompensa sa de bază, iar nepotul care include blocul vechi primește restul de 12,5%. Cu toate acestea, taxele de tranzacție nu sunt acordate unchilor.

Ethereum implementează o versiune simplificată a GHOST care coboară doar șapte niveluri. Mai precis, este definit după cum urmează:

Un bloc trebuie să specifice un părinte și trebuie să specifice 0 sau mai mulți unchi
Un unchi inclus în blocul B trebuie să aibă următoarele proprietăți:
Acesta trebuie să fie un copil direct al strămoșului de generație k al B, unde 2 <= k <= 7.
Nu poate fi un strămoș al B
Un unchi trebuie să fie un antet de bloc valid, dar nu trebuie să fie un bloc verificat anterior sau chiar valid
Un unchi trebuie să fie diferit de toți unchii incluși în blocurile anterioare și de toți ceilalți unchi incluși în același bloc (neincludere-dublă)
Pentru fiecare unchi U din blocul B, minerul lui B primește un plus de 3,125% adăugat la recompensa sa de coinbase, iar minerul lui U primește 93,75% dintr-o recompensă standard de coinbase.

Această versiune limitată de GHOST, cu unchi incluși doar până la a șaptea generație, a fost folosită din două motive. În primul rând, un GHOST nelimitat ar include prea multe complicații în calcularea cărui unchi este valid pentru un anumit bloc. În al doilea rând, un GHOST nelimitat cu compensare așa cum se utilizează în Ethereum elimină stimulentul unui miner de a mina pe lanțul principal și nu pe lanțul unui atacator public.

Taxe

Deoarece fiecare tranzacție publicată în blockchain impune rețelei costul necesității descărcării și verificării acesteia, este nevoie de un anumit mecanism de reglementare, care implică de obicei taxe de tranzacție, pentru a preveni abuzul. Abordarea implicită, utilizată în Bitcoin, este de a avea taxe pur voluntare, bazându-se pe mineri să acționeze ca gardieni și a stabili minime dinamice. Această abordare a fost primită foarte favorabil în comunitatea Bitcoin, în special pentru că este „bazată pe piață”, permițând cererii și ofertei - între minerii și expeditorii tranzacțiilor - să stabilească prețul. Cu toate acestea, problema acestei rațiuni este că procesarea tranzacțiilor nu este o piață; deși este intuitiv atractiv să interpretăm procesarea tranzacției ca un serviciu pe care minerul îl oferă expeditorului, în realitate, fiecare tranzacție pe care un miner o include va trebui procesată de fiecare nod din rețea, deci marea majoritate a costului tranzacției prelucrarea este suportată de terți și nu de minerul care ia decizia de a o include sau nu. Prin urmare, este foarte probabil să apară probleme ale tragediei-bunurilor-comune.

Totuși, așa după cum se dovedește acest defect al mecanismului bazat pe piață, atunci când i se oferă o ipoteză simplificatoare inexactă, magic se anulează singur. Argumentul este următorul. Să presupunem că:

O tranzacție duce la k operațiuni, oferind recompensa kR oricărui miner care o include acolo unde R este setat de expeditor și k și R sunt (aproximativ) vizibile în prealabil minerului.
O operațiune are un cost de procesare C pentru orice nod (adică toate nodurile au o eficiență egală)
Există N noduri miniere, fiecare cu o putere de procesare exact egală (adică 1/N din total)
Nu există noduri complete care nu sunt miniere.

Un miner ar fi dispus să proceseze o tranzacție dacă recompensa așteptată este mai mare decât costul. Astfel, recompensa așteptată este kR/N, deoarece minerul are o șansă de 1/N de a procesa următorul bloc, iar costul de procesare pentru miner este pur și simplu kC. Prin urmare, minerii vor include tranzacții în cazul în care kR/N > kC sau R > NC. Reține că R este taxa pe operațiunea furnizată de expeditor și, prin urmare, este o limită inferioară a beneficiului pe care expeditorul îl obține din tranzacție, iar NC este costul întregii rețele de procesare a unei operațiuni. Prin urmare, minerii sunt stimulați să includă doar acele tranzacții pentru care beneficiul utilitar total depășește costul.

Cu toate acestea, există mai multe abateri importante de la aceste ipoteze în realitate:

Minerul plătește un cost mai mare pentru procesarea tranzacției decât celelalte noduri de verificare, deoarece timpul de verificare suplimentar întârzie propagarea blocului și astfel crește șansa ca blocul să devină învechit.
Există noduri complete care nu sunt miniere.
Distribuția energiei miniere poate ajunge radical inegalizată în practică.
Speculatorii, dușmanii politici și nebunii ale căror funcții de utilitate includ provocarea de daune rețelei există și pot stabili în mod inteligent contracte în care costul lor este mult mai mic decât costul plătit de alte noduri de verificare.

(1) oferă unui miner tendința de a include mai puține tranzacții și (2) crește NC; prin urmare, aceste două efecte, cel puțin parțial, se anulează reciproc. ^Cum? (3) și (4) sunt problemele majore; pentru a le rezolva, instituim pur și simplu un plafon variabil limitat: niciun bloc nu poate face mai multe operații decât BLK_LIMIT_FACTOR înmulțit cu media mișcării exponențiale pe termen lung. Mai precis:

blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) +
floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR)

BLK_LIMIT_FACTOR și EMA_FACTOR sunt constante care vor fi setate pentru moment la 65536 și 1,5, dar probabil vor fi modificate după o analiză ulterioară.

Există un alt factor care descurajează supradimensionarea blocurilor în Bitcoin: blocurile care sunt mari vor dura mai mult timp pentru a se propaga și, prin urmare, au o probabilitate mai mare de a deveni vechi. În Ethereum, propagarea blocurilor care consumă foarte mult gaz poate dura, de asemenea, mai mult, pentru sunt mai mari din punct de vedere fizic și pentru că au nevoie de mai mult timp pentru a procesa tranzițiile stării tranzacției pentru a le valida. Această descurajare a întârzierii este o considerație semnificativă în Bitcoin, dar mai puțin în Ethereum din cauza protocolului GHOST; prin urmare, bazarea pe limite de blocuri reglementate, oferă o linie de bază mai stabilă.

Calcul și completitudine-Turing

O notă importantă este că mașina virtuală Ethereum este Turing-completă; aceasta înseamnă că orice calcul care se poate realiza, poate fi codificat de codul mașinii virtuale Ethereum, inclusiv buclele infinite. Codul EVM permite bucle infinite în două moduri. În primul rând, există o instrucțiune JUMP care permite programului să se întoarcă la un loc anterior din cod și o instrucțiune JUMPI pentru a face un salt condițional, permițând instrucțiuni precum while x < 27: x = x * 2. În al doilea rând, contractele pot apela alte contracte, permițând potențial buclarea prin recursivitate. Acest lucru duce în mod natural la o problemă: pot utilizatorii rău intenționați să blocheze minerii și nodurile complete, forțându-i să intre într-o buclă infinită? Problema apare din cauza unei probleme în informatică cunoscută sub numele de „problema opririi”: nu există nicio modalitate de a spune, în cazul general, dacă un anumit program se va opri vreodată.

Așa cum este descris în secțiunea de tranziție de stare, soluția noastră funcționează solicitând unei tranzacții să stabilească un număr maxim de pași de calcul pe care este permis să-i facă, iar dacă execuția durează mai mult, calculul este anulat, dar taxele trebuie plătite. Mesajele funcționează în același mod. Pentru a arăta motivația din spatele soluției noastre, ia în considerare următoarele exemple:

Un atacator creează un contract care execută o buclă infinită, apoi trimite o tranzacție activând acea buclă către miner. Minerul va procesa tranzacția, rulând bucla infinită și va aștepta ca aceasta să rămână fără gaz. Chiar dacă execuția rămâne fără gaz și se oprește la jumătatea parcursului, tranzacția este încă valabilă, iar minerul cere totuși taxa de la atacator pentru fiecare etapă de calcul.
Un atacator creează o buclă infinită foarte lungă cu intenția de a-l forța pe miner să continue să calculeze atât de mult timp, încât atunci când calculul se termină, vor mai apărea câteva blocuri și nu va fi posibil ca minerul să includă tranzacția pentru solicitarea taxei. Cu toate acestea, atacatorului i se va cere să trimită o valoare pentru STARTGAS, limitând numărul de pași de calcul pe care îi poate face execuția, astfel încât minerul va ști din timp că acest calcul va lua un număr excesiv de mare de pași.
Un atacator vede un contract cu un cod cu o formă cum ar fi send(A,contract.storage[A]); contract.storage[A] = 0 și trimite o tranzacție cu suficient gaz pentru a executa primul pas, dar nu și al doilea (adică efectuarea unei retrageri fără a permite scăderea soldului). Autorul contractului nu trebuie să-și facă griji cu privire la protecția împotriva unor astfel de atacuri, deoarece dacă execuția se oprește la jumătatea modificărilor, acestea vor fi anulate.
Un contract financiar funcționează luând mediana a nouă fluxuri de date proprietare pentru a minimiza riscul. Un atacator preia unul dintre fluxurile de date, care este conceput pentru a fi modificabil prin intermediul mecanismului de apelare a adresei variabile descris în secțiunea despre DAO-uri și îl convertește pentru a rula o buclă infinită, încercând astfel să forțeze orice încercări de a solicita fonduri de la contractul financiar să ducă la o lipsă de gaz. Cu toate acestea, contractul financiar poate stabili o limită de gaz pentru mesaj pentru a preveni această problemă.

Alternativa la completitudinea-Turing este incompletitudinea-Turing, în care JUMP și JUMPI nu există și este permis să existe numai o singură copie a fiecărui contract în stiva de apeluri la un moment dat. Cu acest sistem, sistemul de taxe descris și incertitudinile legate de eficacitatea soluției noastre ar putea să nu fie necesare, deoarece costul executării unui contract ar depăși sau fi egal cu contractul însuși datorită mărimii sale. În plus, incompletitudinea-Turing nu este o limitare chiar atât de mare; dintre toate exemplele de contracte pe care le-am conceput intern până acum, doar unul a necesitat o buclă și chiar și acea buclă ar putea fi eliminată făcând 26 de repetări ale unei bucăți de cod dintr-o linie. Având în vedere implicațiile serioase ale completitudinii-Turing și beneficiul limitat, de ce să nu avem pur și simplu un limbaj Turing incomplet? În realitate, totuși, incompletitudinea-Turing este departe de a fi o soluție elegantă la problemă. Pentru a vedea de ce, ia în considerare următoarele contracte:

C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (rulează un pas al unui program și înregistrează modificarea stocării)

Acum, trimite o tranzacție la A. Așadar, în 51 de tranzacții, avem un contract care durează 2⁵⁰ de pași de calcul. Minerii ar putea încerca să detecteze astfel de bombe logice din timp, menținând o valoare alături de fiecare contract, specificând numărul maxim de pași de calcul pe care îi poate face și calculând acest lucru pentru contractele care solicită alte contracte recursiv, dar asta ar necesita interzicerea de către mineri a contractelor care creează alte contracte (din moment ce crearea și executarea tuturor celor 26 de contracte de mai sus ar putea fi ușor transformate într-un singur contract). Un alt punct problematic este proprietatea de variabilitate a câmpului de adresă al unui mesaj, deci, în general, nici măcar nu este posibil să se spună din timp ce alt contract va apela un anumit contract. Prin urmare, una peste alta, avem o concluzie surprinzătoare: completitudinea-Turing este surprinzător de ușor de gestionat, iar lipsa completitudinii-Turing este la fel de surprinzător de dificil de gestionat dacă nu există exact aceleași controale - dar în acest caz de ce să nu lăsăm protocolul să fie doar Turing-complet?

Moneda și emiterea

Rețeaua Ethereum include propria sa monedă încorporată, eterul, care servește scopului dublu de a furniza un strat de lichiditate primar pentru a permite schimbul eficient între diferite tipuri de active digitale și, mai important, de a oferi un mecanism de plată a taxelor de tranzacție. Pentru comoditate și pentru a evita argumentele viitoare (a se vedea dezbaterea actuală mBTC/uBTC/satoshi în Bitcoin), denominațiile vor fi pre-etichetate:

1: wei
10¹²: szabo
10¹⁵: finney
10¹⁸: eter

Aceasta ar trebui luată ca o versiune extinsă a conceptului de „dolari” și „cenți” sau „BTC” și „satoshi”. În viitorul apropiat, ne așteptăm ca „eter” să fie utilizat pentru tranzacții obișnuite, „finney” pentru microtranzacții și „szabo" și „wei” pentru discuții tehnice despre taxe și implementarea protocolului; valorile rămase pot deveni utile ulterior și nu ar trebui incluse în clienți în acest moment.

Modelul de emisiune va fi după cum urmează:

Eterul va fi lansat într-o vânzare valutară la prețul de 1.000-2.000 eter per BTC, un mecanism destinat finanțării organizației Ethereum și ca plată pentru dezvoltare care a fost utilizat cu succes de alte platforme, cum ar fi Mastercoin și NXT. Cumpărătorii timpurii vor beneficia de reduceri mai mari. BTC-ul primit din vânzare va fi utilizat în întregime pentru a plăti salarii și recompense programatorilor și va fi investit în diverse proiecte cu scop lucrativ și non-profit din ecosistemul Ethereum și criptomonedă.
0,099x suma totală vândută (60.102.216 ETH) va fi alocată organizației pentru a compensa contribuabilii timpurii și pentru a plăti cheltuielile exprimate în ETH înainte de blocul genezei.
0,099x suma totală vândută va fi menținută pe termen lung ca rezervă.
0,26x suma totală vândută va fi alocată minerilor pe an pentru totdeauna după acel moment.

Grup	La lansare	După 1 an	După 5 ani
Unități valutare	1,198X	1,458X	2,498X
Cumpărători	83,5%	68,6%	40,0%
Rezervă cheltuită pre-vânzare	8,26%	6,79%	3,96%
Rezervă folosite post-vânzare	8,26%	6,79%	3,96%
Mineri	0%	17,8%	52,0%

Rata de creștere a aprovizionării pe termen lung (procente)

În ciuda emiterii liniare a monedei, la fel ca în cazul Bitcoin în timp, rata de creștere a ofertei tinde totuși la zero

Cele două alternative principale din modelul de mai sus sunt (1) existența și dimensiunea unui fond de dotare și (2) existența unei oferte liniare în continuă creștere, spre deosebire de o aprovizionare plafonată ca în Bitcoin. Justificarea fondului de dotare este următoarea. Dacă fondul de dotare nu ar exista și emisia liniară s-ar reduce la 0,217x pentru a furniza aceeași rată a inflației, atunci cantitatea totală de eter ar fi cu 16,5% mai mică și astfel fiecare unitate ar fi cu 19,8% mai valoroasă. Prin urmare, în echilibrul 19,8% mai mult eter ar fi cumpărat în vânzare, astfel încât fiecare unitate ar fi din nou la fel de valoroasă ca înainte. Organizația ar avea atunci 1,198x de BTC, care poate fi considerat a fi împărțit în două tranșe: BTC-ul original și 0,198x suplimentar. Prin urmare, această situație este exact echivalentă cu dotarea, dar cu o diferență importantă: organizația deține pur BTC și, prin urmare, nu este stimulată să susțină valoarea unității de eter.

Modelul permanent de creștere a ofertei liniare reduce riscul a ceea ce unii consideră a fi o concentrare excesivă a bogăției în Bitcoin și oferă persoanelor care trăiesc în epocile prezente și viitoare șansa justă de a achiziționa unități valutare, păstrând în același timp un puternic stimulent pentru a obține și deține eter pentru că „rata de creștere a ofertei” ca procent încă tinde la zero în timp. Teoretizăm, de asemenea, că, deoarece monedele se pierd întotdeauna în timp din cauza neglijenței, decesului etc., iar pierderea monedelor poate fi modelată ca procent din oferta totală pe an, că oferta totală de monedă în circulație se va stabiliza, de fapt, la o valoare egală cu emisiunea anuală împărțită la rata de pierdere (de exemplu, la o rată de pierdere de 1%, odată ce aprovizionarea atinge 26X, atunci se va extrage 0,26X și se va pierde 0,26X în fiecare an, creând un echilibru).

De reținut că, în viitor, este probabil ca Ethereum să treacă la un model de dovadă a mizei pentru securitate, reducând cerința de emitere la undeva între zero și 0,05X pe an. În cazul în care organizația Ethereum pierde finanțarea sau din orice alt motiv dispare, lăsăm deschis un „contract social”: oricine are dreptul să creeze o viitoare versiune candidat a Ethereum, cu o singură condiție și anume cantitatea de eter să fie cel mult egală cu 60.102.216 * (1,198 + 0,26 * n) unde n este numărul de ani după blocul de geneză. Creatorii sunt liberi să vândă în grup, sau să atribuie o parte sau toată diferența dintre expansiunea alimentării datorată PoS și extinderea maximă admisibilă a ofertei, pentru a plăti pentru dezvoltare. Upgrade-urile candidaților care nu respectă contractul social pot fi în mod justificat încorporați în versiuni conforme.

Centralizarea mineritului

Algoritmul de extragere Bitcoin funcționează pe faptul că minerii calculează SHA256 pe versiuni ușor modificate ale antetului blocului de milioane de ori din nou și din nou, până când în cele din urmă un nod vine cu o versiune al cărei hash este mai mic decât ținta (în prezent în jur de 2¹⁹²). Cu toate acestea, acest algoritm de minerit este vulnerabil la două forme de centralizare. În primul rând, ecosistemul minier a ajuns să fie dominat de ASIC-uri (circuite integrate specifice aplicației), cipuri de calculator concepute pentru, și, prin urmare, de mii de ori mai eficiente la sarcina specifică mineritului de Bitcoin. Aceasta înseamnă că mineritul de Bitcoin și-a pierdut scopul primordial al descentralizării și egalității, necesitând milioane de dolari de capital pentru a participa efectiv. În al doilea rând, majoritatea minerilor Bitcoin nu efectuează de fapt validarea blocurilor la nivel local; în schimb, se bazează pe un bazin centralizat și temporar de date de minerit pentru a furniza anteturile blocului. Această problemă este, cu siguranță, mai gravă: în momentul scrierii acestui articol, primele trei grupuri miniere controlează indirect aproximativ 50% din puterea de procesare din rețeaua Bitcoin, deși acest lucru este atenuat de faptul că minerii pot trece la alte bazine miniere dacă un grup sau coaliția încearcă un atac de 51%.

Intenția actuală la Ethereum este de a utiliza un algoritm de minerit în care minerii sunt obligați să aducă date aleatorii din stare, să calculeze unele tranzacții selectate aleatoriu din ultimele N blocuri din blockchain și să returneze hash-ul rezultatului. Aceasta are două beneficii importante. În primul rând, contractele Ethereum pot include orice tip de calcul, deci un ASIC Ethereum ar fi în esență un ASIC pentru calcul general - adică un procesor mai bun. În al doilea rând, mineritul necesită acces la întregul blockchain, forțând minerii să stocheze întregul blockchain și cel puțin să fie capabili să verifice fiecare tranzacție. Aceasta elimină necesitatea unor bazine miniere centralizate; deși bazinele miniere pot îndeplini în continuare rolul legitim de distribuire a recompenselor, această funcție poate fi servită la fel de bine de grupurile peer-to-peer fără control central.

Acest model nu este testat și ar putea exista dificultăți pe parcurs pentru a evita anumite optimizări inteligente atunci când se utilizează executarea contractului ca algoritm minier. Cu toate acestea, o caracteristică deosebit de interesantă a acestui algoritm este aceea că permite oricui să „otrăvească fântâna”, prin introducerea unui număr mare de contracte în blockchain-ul special conceput pentru a bloca anumite ASIC-uri. Există stimulente economice pentru producătorii ASIC de a folosi un astfel de truc pentru a se ataca reciproc. Astfel, soluția pe care o dezvoltăm este, în cele din urmă, o soluție economică adaptativă umană, mai degrabă decât una pur tehnică.

Scalabilitatea

O preocupare comună cu privire la Ethereum este problema scalabilității. Asemenea cu Bitcoin, Ethereum suferă de defectul că fiecare tranzacție trebuie procesată de fiecare nod din rețea. Cu Bitcoin, dimensiunea blockchain-ului actual se situează la aproximativ 15 GB, crescând cu aproximativ 1 MB pe oră. Dacă rețeaua Bitcoin ar procesa cele 2.000 de tranzacții Visa pe secundă, ar crește cu 1 MB pe trei secunde (1 GB pe oră, 8 TB pe an). Este posibil ca Ethereum să sufere un tipar similar de creștere, înrăutățit de faptul că vor exista multe aplicații bazate pe blockchain-ul Ethereum în loc de doar o monedă, așa cum este cazul cu Bitcoin, dar ameliorat de faptul că nodurile complete Ethereum trebuie să stocheze doar starea în locul întregului istoric blockchain.

Problema cu o dimensiune atât de mare a blockchain-ului este riscul de centralizare. Dacă dimensiunea blockchain-ului crește la, să zicem, 100 TB, atunci scenariul probabil ar fi că doar un număr foarte mic de companii mari ar rula noduri complete, toți utilizatorii obișnuiți folosind noduri SPV ușoare. Într-o astfel de situație, apare potențialul îngrijorător că nodurile complete ar putea să se unească și să cadă cu toții de acord să trișeze într-un mod profitabil (de exemplu, să schimbe recompensa pe bloc, să-și acorde singuri BTC). Nodurile ușoare nu ar avea nicio modalitate de a detecta acest lucru imediat. Desigur, probabil ar exista cel puțin un nod cinstit complet și, după câteva ore, informațiile despre fraudă se vor scurge prin canale precum Reddit, dar în acel moment ar fi prea târziu: ar depinde de utilizatorii obișnuiți să se organizeze într-un efort de a pune pe lista neagră blocurile date, o problemă de coordonare masivă și probabil imposibil de realizat la o scară similară cu cea a lansării unui atac de succes de 51%. În cazul Bitcoin-ului, aceasta este în prezent o problemă, dar există o modificare blockchain sugerată de Peter Todd care va atenua această problemă.

În viitorul apropiat, Ethereum va folosi două strategii suplimentare pentru a face față acestei probleme. În primul rând, datorită algoritmilor de exploatare bazate pe blockchain, cel puțin fiecare miner va fi forțat să fie un nod complet, încât să fie în numărul egal sau mai mic cu cel al nodurilor complete. În al doilea rând și mai important totodată, vom include o rădăcină intermediară de arbore de stare în blockchain, după procesarea fiecărei tranzacții. Chiar dacă validarea blocurilor este centralizată, atâta timp cât există un nod de verificare onest, problema centralizării poate fi ocolită printr-un protocol de verificare. Dacă un miner publică un bloc nevalid, acel bloc trebuie să fie formatat greșit sau să aibă o stare S[n] incorectă. Deoarece S[0] este cunoscut ca fiind corect, trebuie să existe o primă stare S [i] care este incorectă unde S[i-1] este corect. Nodul de verificare ar furniza indexul i, împreună cu o „dovadă de invaliditate” constând din subsetul de noduri de arbori Patricia care trebuie să proceseze APPLY(S[i-1], TX [i]) -> S[i]. Nodurile ar putea folosi acele noduri Patricia pentru a rula acea parte de calcul, și a vedea dacă S[i] generat nu corespunde cu S[i] furnizat.

Un alt atac, mai sofisticat, ar implica minerii rău intenționați care publică blocuri incomplete, astfel încât informațiile complete nici măcar să nu existe pentru a determina dacă blocurile sunt valabile sau nu. Soluția la acest lucru este un protocol provocare-răspuns: nodurile de verificare emit „provocări” sub formă de indicii de tranzacție țintă, iar la primirea unui nod, un nod ușor tratează blocul ca fiind nesigur până când un alt nod, fie un miner fie un alt verificator, oferă un subset de noduri Patricia ca dovadă a validității.

Concluzie

Protocolul Ethereum a fost conceput inițial ca o versiune îmbunătățită a unei criptomonede, oferind caracteristici avansate, cum ar fi escrow pe-blockchain, limitele de retragere, contracte financiare, piețele de jocuri și altele asemenea, printr-un limbaj de programare extrem de generalizat. Protocolul Ethereum nu ar „sprijini” nicio aplicație în mod direct, dar existența unui limbaj de programare complet Turing înseamnă că, teoretic, pot fi create contracte arbitrare pentru orice tip de tranzacție sau aplicație. Totuși, ceea ce este mai interesant la Ethereum este că protocolul Ethereum se deplasează mult dincolo de simpla monedă. Protocoalele legate de stocarea descentralizată a fișierelor, calculul descentralizat și piețele de predicție descentralizate, printre alte zeci de astfel de concepte, au potențialul de a spori substanțial eficiența industriei de calcul și de a oferi un impuls masiv altor protocoale peer-to-peer prin adăugarea pentru prima dată a unui nivel economic. În cele din urmă, există, de asemenea, o gamă substanțială de aplicații care nu au nimic de-a face cu banii, absolut deloc.

Conceptul unei funcții de tranziție de stare arbitrară așa cum este implementat de protocolul Ethereum furnizează o platformă cu potențial unic; mai degrabă decât să fie un protocol închis, cu un singur scop, destinat unei game specifice de aplicații în stocarea datelor, jocuri de noroc sau finanțe, Ethereum este deschis prin design și credem că este extrem de bine potrivit pentru a servi ca nivel fundamental pentru un număr foarte mare de protocoale atât financiare, cât și non-financiare în anii următori.

Note și referințe suplimentare

Note

Un cititor sofisticat poate observa că, de fapt, o adresă Bitcoin este hash-ul cheii publice a curbei eliptice și nu cheia publică în sine. Cu toate acestea, este de fapt o terminologie criptografică perfect legitimă să se refere la hash-ul cheii publice ca la cheia publică în sine. Acest lucru se întâmplă deoarece criptografia Bitcoin poate fi considerată a fi un algoritm personalizat de semnătură digitală, în care cheia publică se compune din hash-ul cheii publice ECC, semnătura constă din cheia publică ECC concatenată cu semnătura ECC, iar algoritmul de verificare implică verificarea cheii publice ECC în semnătură împotriva hash-ului cheii publice ECC furnizat ca o cheie publică și apoi verificarea semnăturii ECC împotriva cheii publice ECC.
Din punct de vedere tehnic, mediana celor 11 blocuri anterioare.
Protocolul Ethereum ar trebui să fie la fel de simplu pe cât de practic, dar poate fi necesar să ai un nivel destul de ridicat de complexitate, de exemplu, la scalare, pentru a absorbi costurile de stocare, lățimea de bandă și I/O, pentru securitate, confidențialitate, transparență etc. Acolo unde este necesară complexitatea, documentația ar trebui să fie cât mai clară, concisă și actualizată posibil, astfel încât cineva fără nici o cunoștință în Ethereum să-l poată învăța și să devină un expert.
Consultă Yellow Paper pentru Mașina Virtuală Ethereum (care este utilă ca specificație și ca referință pentru construirea unui client Ethereum de la zero), în timp ce există multe subiecte în wiki Ethereum, cum ar fi dezvoltarea de fragmente, dezvoltarea de bază, dezvoltarea de aplicații dapp, cercetare, cercetare și dezvoltare Casper R&D și protocoale de rețea. Pentru cercetare și posibila implementare viitoare există ethresear.ch.
Un alt mod de a exprima acest lucru este abstractizarea. Cea mai recentă foaie de parcurs este planificarea abstractizării execuției, permițând motoarelor de execuție să nu trebuiască neapărat să respecte o specificație canonică, dar, de exemplu, ar putea fi adaptate pentru o aplicație specifică, precum și pentru un fragment. (Această eterogenitate a motoarelor de execuție nu este menționată în mod explicit în foaia de parcurs. Există, de asemenea, fragmentarea eterogenă, pe care Vlad Zamfir a conceput-o.)
Pe plan intern, 2 și „CHARLIE” sunt ambele numere, acesta din urmă fiind în reprezentare de bază big-endian 256. Numerele pot fi cel puțin 0 și cel mult 2²⁵⁶-1.

Referințe suplimentare

Pentru istoricul White Paper, vezi https://github.com/ethereum/wiki/blob/old-before-deleting-all-files-go-to-wiki-wiki-instead/old-whitepaper-for-historical-reference.md

Ethereum, ca multe proiecte software open-source bazate pe comunitate, a evoluat de la începuturile sale. Pentru a afla despre cele mai recente evoluții ale Ethereum și despre modul în care se fac modificările protocolului, îți recomandăm acest ghid.

Ajută la actualizarea acestei pagini

PAGINĂ DE PORNIRE/

WHITEPAPER