Ethereum White Paper, Objasnio. 2. dio

Ethereum je izgrađen oko središnjeg središta stvaranja protokola za izgradnju različitih decentraliziranih aplikacija s brojnim slučajevima uporabe.

Pružaju Turingov cjelovit programski jezik u kojem su važno vrijeme razvoja, sigurnost i interakcija između dapova (decentralizirane aplikacije). Turingov cjelovit programski blok omogućuje razviti široku paletu pametnih ugovora koji su mnogo sofisticiraniji od onih koje nudi Bitcoin.

Filozofija

Ethereum je dizajniran na sljedećih pet principa.

Jednostavnost

Ethereum je izgrađen kao protokol koji je jednostavan i ima viziju biti otvoreni svima, čak i na samom

trošak pohrane podataka i vremenska neučinkovitost. Svaki prosječni programer trebao bi biti u mogućnosti odabrati taj

tijek rada i s lakoćom provodite projekte. To pomaže u punoj realizaciji neviđenog

potencijal Blockchaina i Cryptocurrency.

Univerzalnost

Turingova cjelovitost Ethereuma pomaže u stvaranju bilo kakvog pametnog ugovora koji može biti

matematički definirano. Valuta, financijski derivati ​​ili vaš vlastiti Skynet, bilo što se može izgraditi. Međutim, ako planirate graditi Skynet, možda će vam trebati imati niz ugovora koji se međusobno zaključavaju i nahraniti ih s dovoljno plina da bi se pametni ugovor i dalje održavao.

modularnost

Ethereum je dizajniran tako da se svi dijelovi protokola mogu razdvojiti u pojedinačne jedinice. Čak i ako netko napravi malu izmjenu protokola na jednom mjestu, na druge dijelove snopa aplikacija naizgled ne bi došlo do utjecaja i nastavit će raditi bez daljnjih izmjena.

Inovacije poput Ethasha, modificirana stabla Patricia i RLP (o kojima će se govoriti u budućim postovima) implementiraju se kao zasebne, sadrže kompletne knjižnice. Razvoj Ethereuma vrši se tako da koristi cijeli sustav kriptovaluta, a ne samo njega samog.

Agilnost

Konstrukcije protokola Ethereum nisu postavljene u kamenu, iako će se izmjene konstrukata visoke razine izvoditi samo promišljeno.

Nediskriminacija i necenzura

Budući da je istinski otvoren za sve protokole, bilo koje i sve vrste aplikacija mogu se razviti pomoću Ethereuma. Regulatorni mehanizmi koji se koriste u Ethereumu koriste se za ograničavanje i minimiziranje štete na ekosustavu, a ne za ograničavanje posebne kategorije primjena.

Na primjer, možete pokrenuti skriptu za beskonačnu petlju sve dok rudare plaćate potrebne i relevantne troškove za pokretanje koda.

Računi Ethereuma

U Ethereumu država se sastoji od objekata zvanih "računi", gdje svaki račun ima javnu adresu od 20 bajta. Prijelazi države su prijenosi vrijednosti i informacija između dva ili više računa. Račun Ethereuma sadrži sljedeća četiri polja.

  • Riječ ili ekspresija izmišljena za jednokratno korištenje; ovo je brojač koji osigurava da se svaka transakcija može obraditi samo jednom
  • Stanje računa na eteru na računu
  • Kôd ugovora računa (ako postoji, primjenjiv na pametne ugovore)
  • Pohrana računa (prazno je zadano)

Eter je glavno gorivo koje se koristi u Ethereumu i koristi se za naknadu za transakcije poznatu i kao Gwei.

Postoje dvije vrste računa, naime:

  1. Računi u vanjskom vlasništvu; upravlja privatnim ključevima: Nema svojstvenog koda. Poruke se šalju stvaranjem i potpisivanjem transakcije.
  2. Ugovorni računi; kontrolira Kôd ugovora: Kôd se aktivira ovisno o sadržaju primljene poruke i daljnji postupak poput čitanja i pisanja u internu pohranu, slanje drugih poruka ili stvaranje ugovora može se aktivirati.

Drugu vrstu računa koristi razmjena kriptovaluta: Blockchain Board Derivative u svom sustavu pametnih novčanika bez skrbničkog ugovaranja.

Pametni ugovori su na taj način autonomni agenti koji žive unutar Ethereum okruženja i izvršavaju kôd kad im se prenosi transakcija ili poruka. Takvi ugovori imaju izravnu kontrolu nad svojom eterskom bilansom i vlastitom prodavaonicom ključeva.

Transakcije

Transakcija u Ethereumu u osnovi je potpisani i šifrirani paket podataka koji pohranjuje poruku koja se šalje s računa izvana.

Uobičajene transakcije sadrže sljedeće:

  • Primatelj poruke (Javni ključ primatelja)
  • Potpis koji identificira pošiljatelja (privatni ključ pošiljatelja)
  • Količina etera za prijenos od pošiljatelja do primatelja
  • Neobavezno polje podataka
  • STARTGAS vrijednost, koja predstavlja maksimalni broj računskih koraka izvršenja transakcije dopušteno je poduzeti
  • Vrijednost GASPRICE, koja predstavlja naknadu koju pošiljalac plaća po računanjem

Razmotrimo te pojedine točke. Prva tri su standardna polja prisutna u svakoj kripto valuti. Polje podataka nema zadanu funkciju, ali se može koristiti ugovorom za pristup podacima. Na primjer, ako ugovor funkcionira kao usluga registracije domena, tada bi mogao da protumači podatke koji su mu proslijeđeni kao da sadrže dva "polja", prvo polje je domena za registraciju, a drugo polje IP adresa za registrirajte domenu u. Ugovor bi pročitao ove vrijednosti iz podataka poruke i na odgovarajući ih način stavio u pohranu.

Polja STARTGAS i GASPRICE presudni su za Ethereumov model zabrane uskraćivanja usluge. Kako bi se spriječilo beskonačno petlje ili drugi računski rasipanje, svaka transakcija mora postaviti ograničenje broja računajućih koraka koje može koristiti. Temeljna jedinica računanja je "plin". Obično računalni korak košta 1 plin, ali neke operacije koštaju veće količine plina jer su računski skupe ili povećavaju količinu podataka koja se mora pohraniti kao dio države.

U podacima o transakciji plaća se 5 plina za svaki bajt. Sustav naknada uzrokuje da napadač srazmjerno plaća za svaki izvor koji potroši, uključujući računanje, propusnost i pohranu. Stoga, svaka transakcija koja dovodi do velike potrošnje mreže prirodno dovodi do većih naknada za plin.

Jednostavno rečeno, plaćeni plin izravno je proporcionalan broju i složenosti izračunavanja na blockchainu.

poruke

Ugovori mogu slati poruke na druge ugovore.

Uobičajene poruke sadrže:

  • Pošiljalac poruke
  • Primatelj poruke
  • Količina etera za prijenos s porukom
  • Neobavezno polje podataka
  • STARTGAS vrijednost

Poruka je slična transakciji, osim što se poruke kreiraju ugovorom, a ne računi koji su u vanjskom vlasništvu. Poruka se proizvodi kada ugovorni izvršni kôd izvršava CALL opcode, proizvodeći i izvršavajući poruku.

Poruku prima račun primatelja koji zatim pokreće svoj kod. Na taj se način ugovori mogu provoditi u odnosima s drugim ugovorima na način sličan računima u vanjskom vlasništvu.

Raspodjela plina dodijeljena ugovorom odnosi se i na plin potrošen transakcijom, kao i na sve podizvode.

Shvatimo isto s primjerom.

@A je račun s vanjskim vlasništvom

@B je ugovor

@A šalje @B transakciju s 1000 plina.

@B troši 600 plina i šalje poruku @C-u.

Unutarnja izvedba @C troši 300 plina.

1000-600-300 = 100

To podrazumijeva da ugovor @B može potrošiti samo 100 plina na računanje / poruku / transakciju prije nego što mu je ponestalo goriva.

Funkcija prijelaza Ethereuma

Kao što je spomenuto u dijelu 1 u nizu, mogli biste se prisjetiti funkcije prijelaza stanja

PRIJAVI (S, TX) -> S '

Daljnji su koraci poduzeti iz bijelog papira i prilično su samorazumljivi:

  1. Transakcija mora imati točan broj vrijednosti, potpis mora biti valjan i ne bi trebao odgovarati onome na računu pošiljatelja. Ako se ne pridržava, baci pogrešku.
  2. Naknada za transakciju izračunava se kao STARTGAS * GASPRICE, adresa za slanje može se odrediti iz potpisa. Oduzmite naknadu od pošiljateljevog salda i povećajte pošiljateljevu neznanku. Ako nema dovoljno ravnoteže da potrošite, bacite grešku.
  3. Inicijalizirajte GAS = STARTGAS, a određena količina plina po bajtu uklanja se za plaćanje bajtova u transakciji.
  4. Prenesite vrijednost transakcije s računa pošiljatelja na račun primatelja. Ako račun primatelja još ne postoji, otvorite ga. Ako je račun za primanje ugovor, pokrenite kôd ugovora ili do okončanja ili dok se u izvršenju ne potroši benzin.
  5. Ako prijenos vrijednosti nije uspio jer pošiljatelju nije bilo dovoljno novca ili je izvršenje koda ponestalo plina, poništite sve promjene u državi osim plaćanja naknada i dodajte naknade na račun rudara. Plaćanje naknada ne može se vratiti jer rudar troši energiju kako bi olakšao transakciju.
  6. U suprotnom, vratite naknade pošiljatelju za sav preostali plin i pošaljite rudarima naknade za potrošeni plin.

Pretpostavimo da je kod ugovora sljedeći:

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

Ugovor je zapravo napisan EVM kodom niske razine, ali gornji primjer je napisan u Zmiji.

Pogledajmo sada primjer:

Spremište ugovora je u početku prazno i ​​poslana je transakcija s 10 eterskih vrijednosti, 2000 plina, 0,001 eterskom cijenom i 64 bajta podataka, pri čemu bajtovi 0–31 predstavljaju broj 2, a bajti 32–63 nose niz CHARLIE.

Proces funkcije tranzicije stanja u ovom scenariju je sljedeći. Ovi su koraci slični onima navedenim u gore navedenom generičkom primjeru.

  1. Provjerite je li transakcija valjana i dobro oblikovana.
  2. Provjerite ima li pošiljatelj transakcije najmanje 2000 * 0,001 = 2 etera. Ako jest, oduzmite 2 etera od računa pošiljatelja. (Budući da moramo formulu koristiti STARTGAS * GASPRICE)
  3. Inicijalizirajte plin = 2000; uz pretpostavku da je transakcija duga 170 bajta, a naknada za bajt je 5, oduzmite 850 (170 * 5) tako da ostaje 1150 (2000–850) plina.
  4. Oduzmite još 10 etera od računa pošiljatelja i dodajte ga računu ugovora.
  5. Pokrenite kod. U ovom je slučaju to jednostavno: provjerava je li iskorišteno spremanje ugovora u indeksu 2, primjećuje da nije, pa postavlja pohranu u indeksu 2 na vrijednost CHARLIE. Pretpostavimo da je potrebno 187 plina, a preostala količina plina je 1150–187 = 963
  6. Natrag u račun pošiljatelja dodajte 963 * 0,001 = 0,963 etera i vratite dobiveno stanje.

Ovim se zaključuju koraci koji su poduzeti u cijelom procesu.

Ako na kraju prijema transakcije ne postoji ugovor, ukupna naknada za transakciju bila bi jednostavno jednaka podnesenoj GASPRICE množeno s dužinom transakcije u bajtovima, a podaci poslani uz transakciju bili bi nebitni.

U ovom slučaju, sav bi plin rudar iskoristio da ne bi imao rezultata jer nijedan ugovor ne postoji.

Poruke i transakcije djeluju na slične uvjete kada je riječ o poništavanjima: ako izvršenje poruke ponestane goriva, tada se izvršavanje te poruke i sve ostale izvršenja pokrenute tom izvršenjem vraćaju natrag, ali roditeljske izvršbe ne moraju vratiti.

To podrazumijeva da je "sigurno" za ugovor drugi ugovor kao da A zove B s G plinom, a izvršavanje A je zajamčeno da će izgubiti najviše G plina. Međutim, izvršenja roditelja izvan ugovora ne poništavaju se.

Također, postoji šifra, CREATE, koja stvara ugovor. Mehanika njegova izvršenja općenito je slična CALL-u, s izuzetkom da ishod izvršenja određuje kod novo stvorenog ugovora.

Detaljnije ćemo detaljno proučavati opcode u našim budućim detaljnim tehničkim postovima na blogovima.

Izvođenje koda

Kôd u Ethereum ugovorima napisan je na niskom nivou, na bajtu temeljenom bajt kodu, koji se naziva "Ethereum Virtual Machine code" ili "EVM kod". EVM kod u osnovi je niz bajtova i svaki je bajt operacija.

„Izvođenje koda je beskonačna petlja koja se sastoji od opetovanog izvođenja operacije na trenutnom brojaču programa (koja počinje nulom) i zatim povećanja brojača programa za jedan, sve dok ne dođe do kraja koda ili pogreške ili STOP ili RETURN upute su otkrivene. "

Operacije imaju pristup trima vrstama prostora za pohranu podataka:

  1. Stack, spremnik zadnji u prvom na koji se vrijednosti mogu gurnuti i iskočiti poput tipičnog snopa.
  2. Memorija, beskonačno proširivi bajt.
  3. Skladište, trgovina ključeva / vrijednosti. Za razliku od skupa i memorije koja se resetira po završetku računanja, pohrana ostaje dugotrajna.

Kôd također ima mogućnost pristupa vrijednosti, pošiljatelju, podacima dolazne poruke i zaglavlju bloka. Kod također može vratiti bajt podataka kao izlaz.

Model izvršenja EVM koda prilično je jednostavan. Mi ćemo ga dalje istražiti u sljedećim koracima.

Dok radi virtualni stroj Ethereum, njegovo kompletno računsko stanje može se definirati pomoću taplea. Tuple se sastoji od block_state, transakcije, poruke, koda, memorije, snopa, računala i plina.

Ovdje je block_state globalno stanje koje sadrži sve račune i uključuje bilance i prostor za pohranu.

Na početku svakog kruga izvršenja, trenutna uputa se pronalazi uzimajući pc-ti bajt koda (ili 0 ako je pc> = len (kod)), što znači da se smatra da je pc nula kada je veća ili jednaka na duljinu koda.

Svaka uputa ima svoju definiciju kako bi utjecala na tuple.

ADD iskače dvije stavke s hrpe, gurne njihov zbroj, smanji benzin za 1 i povećava pc za 1 (tipično rad s hrpom)

SSTORE iskoči gornje dvije stavke s hrpe i umetne drugu stavku u skladište ugovora u indeksu koji je odredio prvu stavku.

Postoji mnogo načina za optimiziranje izvršenja EVM-a samo pravodobnom kompilacijom, a osnovna implementacija Ethereuma može se obaviti u nekoliko stotina redaka koda.

Blockchain i rudarstvo

Ethereum blockchain je manje-više sličan Bitcoin blockchainu s nekoliko suptilnih razlika.

Glavna razlika između Ethereuma i Bitcoina s obzirom na blockchain arhitekturu je ta što za razliku od Bitcoina (koji sadrži samo kopiju popisa transakcija), Ethereum blokovi sadrže kopiju popisa transakcija, najnovije stanje, broj bloka i poteškoća.

Algoritam osnovnog provjere bloka u Ethereumu može se objasniti u sljedećim koracima:

  1. Provjerite postoji li prethodni referentni blok i vrijedi li.
  2. Provjerite da li je vremenska oznaka bloka veća od referentnog prethodnog bloka i manje od 15 minuta u budućnosti.
  3. Provjerite jesu li broj bloka, poteškoće, korijen transakcije, korijen ujaka i ograničenje plina (različiti koncepti za nisku razinu Ethereuma koji će biti pokriveni kasnije) važeći.
  4. Provjerite je li dokaz o radu na bloku valjan.
  5. Neka je [[0] stanje na kraju prethodnog bloka. (sjetite se toga kako se raspravljalo i objasnilo u prethodnom postu na blogu)
  6. Neka TX bude popis transakcija bloka, s n transakcija. Za sve i u 0 ... n-1, postavite S [i + 1] = PRIJAVI (S [i], TX [i]). Ako bilo koja aplikacija vrati pogrešku ili ako ukupni potrošeni plin u bloku do ove točke pređe GASLIMIT, vratite pogrešku.
  7. Neka je S_FINAL S [n], ali dodajte nagradu za blok koja se isplaćuje rudaru (S_FINAL = S [n] + Nagrada za blok). Nagrada se dodjeljuje kada rudar uspješno dovrši rudarstvo bloka.
  8. Provjerite je li korijen stabla Merkle stanja S_FINAL jednak konačnom korijenu stanja navedenom u zaglavlju bloka. Ako jest, blok je valjan; u suprotnom ne vrijedi. (Stablo Merklea i potvrda zaglavlja bloka objašnjava se relevantnim slikama u prethodnom postu na blogu)

Pristup pohranjivanja čitavog stanja unutar svakog bloka u početku se može činiti neučinkovitim, ali je uporediv s pristupom Bitcoina.

Stanje je pohranjeno u strukturi stabala i nakon svakog bloka treba mijenjati samo maleni dio stabla. To podrazumijeva da bi između dva susjedna bloka velika većina stabala trebala biti ista. Podaci se mogu pohraniti jednom i dvaput upozoriti pomoću pokazivača (heševa podvrsta).

Da bi se to postiglo koristi se posebna vrsta stabla poznata kao „stablo Patricia“, uključujući izmjenu koncepta drveta Merkle koja omogućava uvođenje i brisanje čvorova na učinkovit način.

Uz to, jer su sve informacije o stanju dio posljednjeg bloka, nema potrebe za pohranjivanjem čitave povijesti blockchaina.

Često postavljeno pitanje je "gdje" se vrši ugovorni kod, u smislu fizičkog hardvera.

Proces izvršenja ugovornog koda definiran je u samoj funkciji prijelaza stanja, koja je dio algoritma provjere bloka. Ako se transakcija doda u blok B, izvršavanje koda izazvano tom transakcijom izvršavat će svi čvorovi koji preuzmu i potvrde blok B, bilo sada ili u budućnosti.

To označava kraj drugog dijela bijele knjige Ethereum. U sljedećem ćemo dijelu raspravljati o aplikacijama Ethereum protokola i ekosustavu u stvarnom vremenu.