Ethereumin valkoinen kirja, selitetty. Osa 2

Ethereum rakennettiin sen keskeisen painopisteen ympärille, joka muodosti protokollan useiden hajautettujen sovellusten rakentamiseksi lukuisilla käyttötapauksilla.

Ne tarjoavat Turingin täydellisen ohjelmointikielen, missä kehitysaika, turvallisuus ja vuorovaikutus dappien (hajautettujen sovellusten) välillä ovat tärkeitä. Turingin täydellinen ohjelmoitava lohkoketju mahdollistaa laajan valikoiman älykkäiden sopimusten kehittämistä, jotka ovat paljon hienostuneempia kuin Bitcoinin tarjoamat.

Filosofia

Ethereum on suunniteltu seuraavien viiden periaatteen mukaisesti.

Yksinkertaisuus

Ethereum on rakennettu protokollaksi, joka on yksinkertainen ja jolla on visio olla avoin kaikille, jopa

tietojen tallennuskustannukset ja ajan tehottomuus. Kaikkien keskimääräisten ohjelmoijien tulisi voida valita

työnkulku ja toteuta projektit helposti. Tämä auttaa ennennäkemättömän täysin ymmärtämään

Blockchain- ja Cryptocurrency-potentiaalit.

yleisyys

Ethereumin Turingin täydellisyys auttaa luomaan mitä tahansa älykästä sopimusta, mikä voi olla

matemaattisesti määritelty. Valuutta, johdannaiset tai oma Skynet, mitä tahansa voi rakentaa. Jos kuitenkin suunnittelet Skynetin rakentamista, saatat joutua käyttämään joukko monia lukitussopimuksia ja syöttämään ne tarpeeksi kaasua pitämään älykkäät sopimukset käynnissä.

modulaarisuus

Ethereum on suunniteltu siten, että protokollan kaikki osat voidaan jakaa erillisiin yksiköihin. Vaikka joku tekisi pienen protokollamuutoksen yhdessä paikassa, sovelluspinon muut osat eivät näytä olevan muuttuneet ja jatkavat työskentelyä ilman lisämuutoksia.

Innovaatiot, kuten Ethash, modifioidut Patricia-puut ja RLP (joista keskustellaan tulevaisuuden viesteissä), toteutetaan erillisinä, ominaisuuksiltaan täydellisinä kirjastoina. Ethereum-kehitys tehdään siten, että se hyödyttää koko salausvaluuttajärjestelmää kuin vain itseään.

ketteryys

Ethereum-protokollan rakenteita ei ole asetettu kiveen, vaikka korkean tason rakenteiden muokkaukset tehdäänkin vain järkevästi.

Syrjimättömyys ja sensuuri

Ethereumilla voidaan kehittää kaikkia protokollia, ja kaikenlaisia ​​sovelluksia voidaan kehittää kaikille. Ethereumissa käytettyjä sääntelymekanismeja käytetään ekosysteemille aiheutuvien haittojen rajoittamiseen ja minimoimiseen sijasta tietyn sovellusluokan rajoittamiseksi.

Voit esimerkiksi suorittaa ääretön silmukkoodin, kunhan maksat kaivostyöläisille tarvittavat ja asiaan liittyvät maksut koodin suorittamisesta.

Ethereum-tilit

Ethereumissa tila koostuu esineistä, joita kutsutaan tileiksi, joissa jokaisella tilillä on 20 tavun julkinen osoite. Tilasiirtymät ovat arvon ja tiedon siirtämistä kahden tai useamman tilin välillä. Ethereum-tili sisältää seuraavat neljä kenttää.

  • seksuaalirikollinen; tämä on laskuri, joka varmistaa, että jokainen tapahtuma voidaan käsitellä vain kerran
  • Tilin nykyinen eetterisaldo
  • Tilin sopimuskoodi (jos olemassa, soveltuu älykkäisiin sopimuksiin)
  • Tilin tallennustila (oletuksena tyhjä)

Eetteri on tärkein polttoaine, jota käytetään Ethereumissa, ja sitä käytetään transaktiomaksuihin, jotka tunnetaan myös nimellä Gwei.

Tiliä on kahta tyyppiä:

  1. Ulkoisesti omistamat tilit; ohjattu yksityisillä avaimilla: Ei ole luontaista koodia. Viestit lähetetään luomalla ja allekirjoittamalla tapahtuma.
  2. Sopimustilit; ohjattu sopimuskoodilla: Koodi aktivoituu vastaanotetun viestin sisällöstä riippuen, ja muut prosessit, kuten lukeminen ja kirjoittaminen sisäiseen tallennustilaan, muiden viestien lähettäminen tai sopimusten luominen, voidaan aktivoida.

Toista tyyppiä olevaa tiliä käyttää kryptovaluuttakurssi: Blockchain Board of johdannaiset sen älyttömässä älykkäässä sopimus lompakkojärjestelmässä.

Älykkäät sopimukset ovat siis itsenäisiä agentteja, jotka asuvat Ethereum-ympäristössä ja suorittavat koodin, kun ne välitetään tapahtumalla tai viestillä. Tällaisilla sopimuksilla on suora vaikutus eetteritasapainoon ja omaan avainasäilöön.

liiketoimet

Ethereum-tapahtuma on pääosin allekirjoitettu ja salattu tietopaketti, joka tallentaa viestin, joka lähetetään ulkoisesti omistamalta tililtä.

Tyypillisiä liiketoimia ovat seuraavat:

  • Viestin vastaanottaja (vastaanottajan julkinen avain)
  • Lähettäjän tunnistava allekirjoitus (lähettäjän yksityinen avain)
  • Lähettäjältä vastaanottajalle siirrettävän eetterin määrä
  • Valinnainen tietokenttä
  • STARTGAS-arvo, joka edustaa laskennallisten vaiheiden enimmäismäärää, jonka tapahtuman suorittaminen saa suorittaa
  • GASPRICE-arvo, joka edustaa lähettäjän maksamaa laskelmaa kohti

Jaotelkaamme nämä yksittäiset kohdat. Ensimmäiset kolme ovat vakiokenttiä, jotka ovat läsnä jokaisessa kryptovaluutassa. Tietokentällä ei ole oletustoimintoa, mutta sopimus voi käyttää sitä tietojen käyttämiseen. Esimerkiksi, jos sopimus toimii verkkotunnuksen rekisteröintipalveluna, se voi haluta tulkita sille siirretyn datan sisältävän kaksi “kenttää”, joista ensimmäinen kenttä on rekisteröitävä toimialue ja toinen kenttä on IP-osoite rekisteröi verkkotunnus. Sopimus lukee nämä arvot viestitiedoista ja sijoittaa ne asianmukaisesti varastoon.

STARTGAS- ja GASPRICE-kentät ovat ratkaisevan tärkeitä Ethereumin palvelun kieltämisen estävälle mallille. Äärettömien silmukoiden tai muun laskennallisen hukkauksen estämiseksi jokaisella tapahtumalla on asetettava rajoitus laskennallisten vaiheiden lukumäärälle, jota se voi käyttää. Laskennan perusyksikkö on “kaasu”. Laskennallinen vaihe maksaa yleensä yhden kaasun, mutta jotkut operaatiot maksavat suurempia kaasumääriä, koska ne ovat laskennallisesti kalliimpia tai lisäävät tietomäärää, joka on tallennettava osana tilaa.

Tapahtumatiedoissa on 5 kaasun maksu jokaisesta tavusta. Maksujärjestelmä saa hyökkääjän maksamaan suhteellisesti jokaisesta kuluttamastaan ​​resurssista, mukaan lukien laskenta, kaistanleveys ja tallennustila. Siten kaikki transaktiot, jotka johtavat suureen verkonkulutukseen, johtavat luonnollisesti korkeampaan kaasumaksuun.

Yksinkertaisesti sanottuna maksettu kaasu on suoraan verrannollinen lohkoketjussa tehtyjen laskelmien määrään ja monimutkaisuuteen.

viestien

Sopimukset voivat lähettää viestejä muihin sopimuksiin.

Tyypilliset viestit sisältävät:

  • Viestin lähettäjä
  • Viestin vastaanottaja
  • Viestin kanssa siirrettävän eetterin määrä
  • Valinnainen tietokenttä
  • STARTGAS-arvo

Viesti on samanlainen kuin tapahtuma paitsi, että viestit luodaan sopimuksella eikä ulkoisesti omistamilla tileillä. Viesti tuotetaan, kun sopimusta suorittava koodi suorittaa CALL-opoodin tuottaen ja suorittamalla viestin.

Viestin vastaanottaa vastaanottajatili, joka sitten suorittaa koodinsa. Tällä tavoin sopimukset voivat solmia suhteissa muihin sopimuksiin samalla tavalla kuin ulkoisesti omistamat tilit.

Sopimuksella osoitettu kaasunjako koskee sekä kaupan kuluttamaa kaasua että kaikkia alitehtäviä.

Ymmärtäkäämme sama esimerkillä.

@A on ulkoisesti omistama tili

@B on sopimus

@A lähettää @B tapahtuman 1000 kaasulla.

@B kuluttaa 600 kaasua ja lähettää viestin @C: lle.

@C: n sisäinen suoritus kuluttaa 300 kaasua.

1000-600-300 = 100

Tämä tarkoittaa, että sopimus @B voi käyttää vain 100 muuta kaasua laskentaan / viestiin / tapahtumaan ennen kaasun loppumista.

Ethereumin tilansiirtofunktio

Kuten sarjan osassa 1 mainittiin, saatat muistuttaa tilansiirtotoimintoa

Käytä (S, TX) -> S '

Lisävaiheita otetaan valkoisesta kirjasta, ja ne ovat selvästi itsestään selviä:

  1. Tapahtumassa on oltava oikea määrä arvoja, allekirjoituksen on oltava kelvollinen ja noncen tulee vastata lähettäjän tilillä olevaa noncea. Jos se ei täytä vaatimuksia, heitä virhe.
  2. Tapahtumamaksu lasketaan muodossa STARTGAS * GASPRICE, lähetysosoite voidaan määrittää allekirjoituksesta. Vähennä maksu lähettäjän tasapainosta ja lisää lähettäjän perimätöntä. Jos saldoa ei ole tarpeeksi, heitä virhe.
  3. Alusta GAS = STARTGAS, ja tietty määrä kaasua tavua kohti otetaan pois maksaaksesi tavuista tapahtumassa.
  4. Siirrä tapahtuman arvo lähettäjän tililtä vastaanottavalle tilille. Jos vastaanottavaa tiliä ei vielä ole, luo se. Jos vastaanottava tili on sopimus, suorita sopimuksen koodi joko loppuun saakka tai kunnes toimeenpano loppuu kaasusta.
  5. Jos arvonsiirto epäonnistui, koska lähettäjällä ei ollut tarpeeksi rahaa, tai koodin suorittaminen loppui polttoainetta, peruuta kaikki tilamuutokset paitsi palkkioiden maksaminen ja lisää maksut kaivosmieskäyttäjän tilille. Palkkioiden maksamista ei voida palauttaa, koska kaivosmies kuluttaa energiaa kaupan helpottamiseksi.
  6. Muussa tapauksessa palauta kaiken jäljellä olevan kaasun maksut lähettäjälle ja lähetä kaivostyöntekijälle kulutetusta kaasusta maksetut maksut.

Oletetaan, että sopimuksen koodi on seuraava:

jos! omavarastointi [calldataload (0)]:
omavarastointi [soittolataus (0)] = soittolataus (32)

Sopimus on tosiasiallisesti kirjoitettu matalan tason EVM-koodilla, mutta yllä oleva esimerkki on kirjoitettu käärmellä.

Tarkastellaan nyt esimerkkiä:

Sopimuksen varastointi on alun perin tyhjä ja tapahtuma lähetetään 10 eetteriarvolla, 2000 kaasulla, 0,001 eetterin kaasuhinnalla ja 64 tavulla dataa. Tavut 0–31 edustavat numeroa 2 ja tavut 32–63 kantavat merkkijonoa CHARLIE.

Tilamuutosfunktioprosessi tässä skenaariossa on seuraava. Nämä vaiheet ovat samanlaisia ​​kuin yllä mainitussa yleisessä esimerkissä mainitut.

  1. Tarkista, että tapahtuma on pätevä ja hyvin muotoiltu.
  2. Tarkista, että tapahtuman lähettäjällä on vähintään 2000 * 0,001 = 2 eetteriä. Jos on, vähennä 2 eetteri lähettäjän tililtä. (Koska meidän on käytettävä kaavana STARTGAS * GASPRICE)
  3. Alusta kaasu = 2000; Jos kauppa on 170 tavua pitkä ja tavumaksu 5, vähennä 850 (170 * 5) siten, että jäljellä on 1150 (2000–850) kaasua.
  4. Vähennä vielä 10 eetteriä lähettäjän tililtä ja lisää se sopimuksen tilille.
  5. Suorita koodi. Tässä tapauksessa tämä on yksinkertainen: se tarkistaa, käytetäänkö sopimuksen tallennusta indeksissä 2, huomauttaa, että sitä ei ole, ja asettaa siten indeksissä 2 olevan tallennuksen arvoon CHARLIE. Oletetaan, että tämä vie 187 kaasua, joten jäljellä oleva kaasumäärä on 1150–187 = 963
  6. Lisää 963 * 0,001 = 0,963 eetteri takaisin lähettäjän tilille ja palauta tuloksena oleva tila.

Tämä päättää koko prosessin vaiheet.

Jos kauppaa vastaanottavassa lopussa ei olisi sopimusta, kokonaismaksuprosentti olisi yksinkertaisesti yhtä suuri kuin annettu GASPRICE kerrottuna kaupan pituudella tavuina, ja tapahtuman rinnalla lähetetyt tiedot eivät olisi merkityksellisiä.

Tässä tapauksessa kaivosmies hyödyntäisi kaiken kaasun tuottaakseen tulosta, koska sopimusta ei ole olemassa.

Viestit ja tapahtumat toimivat samoin ehdoin, kun kyse on palautuksista: jos viestin suorittaminen loppuu, niin viestin suorittaminen ja kaikki muut tämän suorittamat käynnistykset palautuvat, mutta vanhempien suorituksia ei tarvitse palauttaa.

Tämä tarkoittaa, että sopimukselle on "turvallista" soittaa toiselle sopimukselle, kuin jos A kutsuu B: tä G-kaasulla, A: n suorittamisella varmistetaan, että se menettää enintään G-kaasun. Vanhempien teloitukset sopimusten ulkopuolella eivät kuitenkaan palaudu.

Lisäksi on olemassa koodikoodi, CREATE, joka luo sopimuksen. Sen toteutusmekaniikka on yleensä samanlainen kuin CALL, paitsi että suorituksen lähtö määrittää vasta luodun sopimuksen koodin.

Harkitsemme opkoodia tarkemmin tulevaisuuden perusteellisissa teknisissä blogiviestissämme.

Koodin suorittaminen

Ethereum-sopimusten koodi on kirjoitettu matalan tason pinopohjaisessa tavukoodikielellä, johon viitataan nimellä “Ethereum Virtual Machine code” tai “EVM code”. EVM-koodi on olennaisesti sarja tavuja ja jokainen tavu on toimenpide.

”Koodin suorittaminen on ääretön silmukka, joka koostuu operaation toistuvasta suorittamisesta nykyisellä ohjelmalaskurilla (joka alkaa nollasta) ja sitten ohjelman laskurin lisäämisestä yhdellä, kunnes koodin loppu on saavutettu tai virhe tai STOP tai RETURN ohje havaitaan. ”

Operaatioilla on pääsy kolmen tyyppiseen tilaan, johon tietoja voidaan tallentaa:

  1. Pino, viimeisenä ensimmäisessä-ulos -säiliö, johon arvoja voidaan työntää ja hypätä kuten tyypillistä pinoa.
  2. Muisti, portaattomasti laajennettava tavuryhmä.
  3. Varastointi, avain / arvovarasto. Toisin kuin pino ja muisti, joka nollataan laskennan päätyttyä, tallennus säilyy pitkään.

Koodilla on myös kyky käyttää arvoa, lähettäjää, tulevan viestin tietoja ja lohkon otsikkoa. Koodi voi myös palauttaa tavujonon datatulostulona.

EVM-koodin toteutusmalli on melko yksinkertainen. Tutkimme sitä tarkemmin alla olevissa vaiheissa.

Ethereum-virtuaalikoneen ollessa käynnissä, kokonainen laskennallinen tila voidaan määrittää tuplen avulla. Kokoonpano koostuu negatiivista tilauksesta, tapahtumasta, viestistä, koodista, muistista, pinosta, tietokoneesta ja kaasusta.

Täällä pagrindstate on globaali tila, joka sisältää kaikki tilit ja saldot ja varastoinnin.

Jokaisen suorituskierroksen alussa nykyinen käsky saadaan ottamalla koodin pc-tavu (tai 0, jos pc> = len (koodi)), mikä tarkoittaa, että pc: n katsotaan olevan nolla, kun se on suurempi tai yhtä suuri koodin pituuteen.

Jokaisella ohjeella on oma määritelmänsä siitä, kuinka se vaikuttaa tuplaan.

ADD hyppää kaksi kappaletta pinosta, työntää niiden summan, vähentää kaasua yhdellä ja kasvaa pc: llä 1 (tyypillinen pinon toiminta)

SSTORE aukaisee kaksi parasta kohtaa pinosta ja lisää toisen esineen sopimuksen varastoon ensimmäisen esineen määrittelemään hakemistoon.

EVM-suoritusmuotojen optimoimiseksi on vain monia tapoja suorittaa juuri oikea-aikaisen kokoamisen avulla. Ethereumin perustoteutus voidaan suorittaa muutamalla sadalla koodirivillä.

Lohkoketju ja kaivostoiminta

Ethereum blockchain on enemmän tai vähemmän samanlainen kuin Bitcoin blockchain muutamilla hienoilla eroilla.

Suurin ero Ethereumin ja Bitcoinin välillä blockchain-arkkitehtuurissa on, että toisin kuin Bitcoin (joka sisältää vain kopion tapahtumaluettelosta), Ethereum-lohkot sisältävät kopion tapahtumaluettelosta, viimeisimmän tilan, lohkon numeron ja vaikeus.

Ethereumin peruslohkon validointialgoritmi voidaan selittää seuraavissa vaiheissa:

  1. Tarkista, onko edellinen viitattu lohko olemassa ja pätevä.
  2. Tarkista, että lohkon aikaleima on suurempi kuin viitattu edellinen lohko ja vähemmän kuin 15 minuuttia tulevaisuuteen.
  3. Tarkista, että lohkon numero, vaikeudet, tapahtuman juuri, setän juuri ja kaasuraja (useat matalatason Ethereum-kohtaiset käsitteet, jotka käsitellään myöhemmin) ovat päteviä.
  4. Tarkista, että todiste töistä lohkolla on pätevä.
  5. Olkoon S [0] tila edellisen lauseen lopussa. (muista, että tästä keskusteltiin ja selitettiin edellisessä blogiviestissä)
  6. Olkoon TX lohkon transaktiolista, jossa on n tapahtumaa. Kaikille i: n arvoille 0… n-1 asetetaan S [i + 1] = KÄYTÖSSÄ (S [i], TX [i]). Jos jokin sovellus palauttaa virheen tai jos lohkossa kulunut kokonaiskaasu tähän pisteeseen saakka ylittää GASLIMITin, palauta virhe.
  7. Olkoon S_FINAL S [n], mutta lisäämällä kaivostyöntekijälle maksettu lohkopalkkio (S_FINAL = S [n] + estä palkkio). Palkkio myönnetään, kun kaivosmies on suorittanut lohkon onnistuneesti.
  8. Tarkista, onko tilan S_FINAL Merkle-puunjuuri yhtä suuri kuin lohkon otsikossa annettu lopullinen tilajuuri. Jos se on, lohko on voimassa; muuten se ei ole pätevä. (Merkle-puu ja validointi lohkon otsikolla selitetään asiaankuuluvilla kuvilla edellisessä blogiviestissä)

Lähestymistapa tallentaa koko tila jokaisessa lohkossa voi aluksi vaikuttaa tehottomalta, mutta on verrattavissa Bitcoinin tapaan.

Tila tallennetaan puurakenteeseen ja jokaisen lohkon jälkeen vain pieni osa puusta on vaihdettava. Tämä tarkoittaa, että kahden vierekkäisen lohkon välillä suurimman osan puusta tulisi olla sama. Tiedot voidaan tallentaa kerran ja niihin voidaan viitata kahdesti osoittimilla (alajaksojen tiivisteet).

Tätä varten käytetään erityistä puuta, jota kutsutaan ”Patricia-puuksi”, mukaan lukien muutos Merkle-puukäsitteeseen, joka mahdollistaa solmujen asettamisen ja poistamisen tehokkaalla tavalla.

Koska kaikki tilatiedot ovat osa viimeistä lohkoa, koko lohkoketjuhistoriaa ei tarvitse tallentaa.

Yleisesti kysytään, missä ”sopimuskoodi” suoritetaan fyysisen laitteiston suhteen.

Sopimuskoodin suorittamisprosessi määritetään itse tilansiirtofunktiossa, joka on osa lohkon validointialgoritmia. Jos tapahtuma lisätään lohkoon B, kaikki tapahtuman suorittamat koodin suoritukset suorittavat kaikki solmut, jotka lataavat ja validoivat lohkon B, joko nyt tai tulevaisuudessa.

Tämä merkitsee Ethereum-valkoisen kirjan osan 2 loppua. Seuraavassa osassa käsittelemme Ethereum-protokollan ja ekosysteemin reaaliaikaisia ​​sovelluksia.