Biela kniha Ethereum, vysvetlená. Časť 2

Spoločnosť Ethereum bola postavená na ústrednom zameraní vytvorenia protokolu na vytváranie rôznych decentralizovaných aplikácií s mnohými prípadmi použitia.

Poskytujú Turingov kompletný programovací jazyk, kde je dôležitý vývojový čas, bezpečnosť a interakcia medzi dapps (decentralizované aplikácie). Turingova kompletná programovateľná blockchain umožňuje vývoj širokej škály inteligentných kontraktov, ktoré sú omnoho sofistikovanejšie ako zmluvy ponúkané bitcoínmi.

filozofia

Program Ethereum je navrhnutý podľa nasledujúcich piatich zásad.

jednoduchosť

Ethereum je postavený ako protokol, ktorý je jednoduchý a má víziu otvorenia pre všetkých, dokonca aj na internete

náklady na ukladanie údajov a časovú neefektívnosť. Každý priemerný programátor by mal byť schopný vybrať

workflow a implementácia projektov s ľahkosťou.To pomáha pri úplnej realizácii bezprecedentných

potenciál blockchainu a kryptomeny.

univerzálnosť

Turingova úplnosť spoločnosti Ethereum pomáha pri vytváraní akejkoľvek inteligentnej zmluvy, ktorá môže byť

matematicky definované. Mena, finančné deriváty alebo váš vlastný Skynet, všetko sa dá zostaviť. Ak však plánujete stavať Skynet, možno budete musieť mať k dispozícii celý rad kontraktov na zaistenie a dodať im dostatok plynu, aby ste udržali inteligentnú zmluvu v prevádzke.

modularita

Ethereum je navrhnuté tak, aby všetky časti protokolu mohli byť rozdelené do jednotlivých jednotiek. Aj keď niekto urobí malú modifikáciu protokolu na jednom mieste, ostatné časti aplikačného zásobníka by boli zdanlivo nedotknuté a pokračovali by v práci bez ďalších úprav.

Inovácie ako Ethash, upravené stromy Patricia a RLP (o ktorých sa bude diskutovať v budúcich príspevkoch) sa implementujú ako samostatné a vybavené kompletné knižnice. Vývoj éteru sa vykonáva tak, aby prospel celému systému kryptomeny, nielen samotnému.

obratnosť

Konštrukcie protokolu Ethereum nie sú zakorenené, hoci úpravy konštruktov vysokej úrovne sa budú robiť iba uvážlivo.

Nediskriminácia a cenzúra

Pretože sú skutočne otvorené pre všetky protokoly, je možné pomocou Ethereum vyvinúť všetky druhy aplikácií. Regulačné mechanizmy používané v programe Ethereum sa používajú skôr na obmedzenie a minimalizáciu poškodenia ekosystému, ako na obmedzenie konkrétnej kategórie aplikácií.

Napríklad môžete spustiť skript nekonečnej slučky, pokiaľ platíte potrebné a relevantné poplatky pre baníkov za spustenie kódu.

Účty Ethereum

V meste Ethereum je štát tvorený predmetmi nazývanými „účty“, kde každý účet má 20-bajtovú verejnú adresu. Prechody štátu sú prevody hodnoty a informácií medzi dvoma alebo viacerými účtami. Účet Ethereum obsahuje nasledujúce štyri polia.

  • nonce; Toto je počítadlo, ktoré zaisťuje, že každú transakciu je možné spracovať iba raz
  • Aktuálny zostatok v ére účtu
  • Kód zmluvy účtu (ak je k dispozícii, vzťahuje sa na inteligentné zmluvy)
  • Úložisko účtu (predvolene prázdne)

Éter je hlavným palivom používaným v sieti Ethereum a používa sa na transakčné poplatky známe aj ako Gwei.

Existujú dva typy účtov:

  1. Účty zvonka vlastnené; ovládané súkromnými kľúčmi: Nemajú vlastný kód. Správy sa odosielajú vytvorením a podpísaním transakcie.
  2. Účty zmlúv; riadený kódom zmluvy: Kód sa aktivuje v závislosti od obsahu prijatej správy a je možné aktivovať ďalšie procesy, ako je čítanie a zápis do interného úložiska, odosielanie ďalších správ alebo vytváranie zmlúv.

Druhý typ účtu používa burzová kryptomena: Blockchain Board of Derivatives vo svojom neväzobnom inteligentnom zmluvnom peňaženkovom systéme.

Inteligentné zmluvy sú teda autonómnymi agentmi, ktorí žijú vo vnútri prostredia Ethereum a vykonávajú kód, keď sú sprostredkovaní transakciou alebo správou. Takéto zmluvy majú priamu kontrolu nad ich éterovou rovnováhou a vlastným kľúčovým úložiskom.

transakcie

Transakcia v systéme Ethereum je v podstate podpísaný a šifrovaný dátový balík, ktorý ukladá správu, ktorá sa má odoslať z externe vlastneného účtu.

Typické transakcie obsahujú:

  • Príjemca správy (verejný kľúč príjemcu)
  • Podpis identifikujúci odosielateľa (súkromný kľúč odosielateľa)
  • Množstvo éteru, ktoré sa prevedie z odosielateľa na príjemcu
  • Voliteľné dátové pole
  • Hodnota STARTGAS predstavujúca maximálny počet výpočtových krokov, ktoré môže vykonať vykonanie transakcie
  • Hodnota GASPRICE, ktorá predstavuje poplatok, ktorý odosielateľ zaplatí za jeden výpočtový krok

Zoberme si tieto jednotlivé body. Prvé tri sú štandardné polia prítomné v každej kryptomene. Dátové pole nemá žiadnu predvolenú funkciu, ale na základe zmluvy sa môže použiť na prístup k údajom. Napríklad, ak zmluva funguje ako služba registrácie domény, potom môže chcieť interpretovať údaje, ktoré sa jej odovzdávajú, ako obsahujúce dve „polia“, pričom prvé pole je doména na registráciu a druhé pole je adresa IP zaregistrovať doménu na. Zmluva načíta tieto hodnoty z údajov správy a vhodne ich uloží do pamäte.

Polia STARTGAS a GASPRICE sú rozhodujúce pre model spoločnosti Ethereum zameraný na odmietnutie služieb. Aby sa zabránilo nekonečným slučkám alebo iným výpočtovým stratám, je pri každej transakcii potrebné stanoviť limit počtu výpočtových krokov, ktoré môže použiť. Základnou jednotkou výpočtu je „plyn“. Výpočtový krok zvyčajne stojí 1 plyn, ale niektoré operácie stoja vyššie množstvo plynu, pretože sú výpočtovo nákladnejšie alebo zvyšujú množstvo údajov, ktoré sa musia ukladať ako súčasť štátu.

V údajoch o transakcii sa účtuje poplatok 5 plynu za každý bajt. Systém poplatkov spôsobí, že útočník zaplatí pomerne za každý zdroj, ktorý spotrebuje, vrátane výpočtu, šírky pásma a úložiska. Preto každá transakcia, ktorá vedie k vysokej spotrebe siete, prirodzene vedie k vyššiemu poplatku za plyn.

Jednoducho povedané, zaplatený plyn je priamo úmerný počtu a zložitosti výpočtov vykonaných na blockchaine.

správy

Zmluvy môžu posielať správy do iných zmlúv.

Typické správy obsahujú:

  • Odosielateľ správy
  • Príjemca správy
  • Množstvo éteru, ktorý sa má pomocou správy preniesť
  • Voliteľné dátové pole
  • Hodnota STARTGAS

Správa je podobná transakcii s tým rozdielom, že správy sa vytvárajú na základe zmluvy a nie na externe vlastnené účty. Správa sa vytvorí, keď zmluva vykonávajúca kód vykoná operačný kód CALL, pričom vytvorí a vykoná správu.

Správa je prijatá účtom príjemcu, ktorý potom spustí svoj kód. Týmto spôsobom sa môžu zmluvy uzatvárať vo vzťahoch s inými zmluvami podobným spôsobom ako účty externe vlastnené.

Pridelenie plynu pridelené zmluvou sa vzťahuje na plyn spotrebovaný transakciou, ako aj na všetky čiastkové plnenia.

Pochopme to na príklade.

@A je externe vlastnený účet

@ B je zmluva

@ A odošle @ B transakciu s 1 000 plynom.

@ B spotrebuje 600 plynov a odošle správu spoločnosti @C.

Pri vnútornej realizácii @ C sa spotrebuje 300 plynu.

1000-600-300 = 100

To znamená, že zmluva @ B môže minúť ďalších 100 plynov na výpočet / správu / transakciu skôr, ako sa minie plyn.

Funkcia prechodu na etereum

Ako je uvedené v časti 1 série, môžete si pamätať funkciu prechodu štátu

APLIKUJTE (S, TX) -> S '

Ďalšie kroky vyplývajú z bielej knihy a sú do značnej miery vysvetľujúce:

  1. Transakcia musí mať správny počet hodnôt, podpis musí byť platný a kód by sa mal zhodovať s kódom v účte odosielateľa. Ak to nevyhovuje, vyhodiť chybu.
  2. Transakčný poplatok sa počíta ako STARTGAS * GASPRICE, odosielajúca adresa sa dá určiť z podpisu. Odpočítajte poplatok od zostatku odosielateľa a zvýšte jeho hodnotu. Ak nie je dostatok prostriedkov na útratu, vyhoďte chybu.
  3. Inicializujte GAS = STARTGAS a určité množstvo plynu na bajt sa odoberie na zaplatenie bajtov v transakcii.
  4. Preneste hodnotu transakcie z účtu odosielateľa na prijímajúci účet. Ak prijímajúci účet ešte neexistuje, vytvorte ho. Ak je prijímajúcim účtom zmluva, spustite kód zmluvy buď do dokončenia, alebo do vyčerpania zásob.
  5. Ak prevod hodnoty zlyhal, pretože odosielateľ nemal dostatok peňazí alebo sa pri spustení kódu vyčerpal plyn, vráťte všetky zmeny stavu okrem platenia poplatkov a pripočítajte poplatky na účet baníka. Platba poplatkov nemôže byť vrátená, pretože ťažobník vynakladá energiu na uľahčenie transakcie.
  6. V opačnom prípade vrátite poplatky za všetok zvyšný plyn odosielateľovi a poplatky za spotrebovaný plyn zašlite bani.

Predpokladajme, že kód zmluvy je nasledujúci:

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

Zmluva je v skutočnosti napísaná v nízkoúrovňovom kóde EVM, ale vyššie uvedený príklad je napísaný v Serpent.

Teraz zvážme príklad:

Ukladanie zmluvy je spočiatku prázdne a transakcia sa odosiela s 10 éterovými hodnotami, 2000 plynmi, 0,001 éterovými plynmi a 64 bajtmi údajov, pričom bajty 0–31 predstavujú číslo 2 a bajty 32–63 nesú reťazec CHARLIE.

Proces funkcie prechodu stavu v tomto scenári je nasledujúci. Tieto kroky sú podobné tým, ktoré sú uvedené vo všeobecnom príklade vyššie.

  1. Skontrolujte, či je transakcia platná a správna.
  2. Skontrolujte, či má odosielateľ transakcie najmenej 2 000 x 0,001 = 2 éter. Ak je, odčítajte odpočet 2 éteru z účtu odosielateľa. (Pretože musíme použiť vzorec STARTGAS * GASPRICE)
  3. Inicializácia plynu = 2000; za predpokladu, že transakcia je 170 bajtov dlhá a bajtový poplatok je 5, odpočítajte 850 (170 * 5) tak, aby zostalo 1150 (2000 - 850) plynu.
  4. Odečítať ďalších 10 éterov z účtu odosielateľa a pridať ho na účet zmluvy.
  5. Spustite kód. V tomto prípade je to jednoduché: skontroluje, či sa používa úložisko zmluvy v indexe 2, všimne si, že nie, a tak nastaví úložisko v indexe 2 na hodnotu CHARLIE. Predpokladajme, že to vyžaduje 187 plynu, takže zostávajúce množstvo plynu je 1150–187 = 963
  6. Pridajte 963 * 0,001 = 0,9663 éteru späť na účet odosielateľa a vráťte výsledný stav.

Týmto sa uzatvárajú kroky, ktoré sa podnikajú v celom procese.

Ak by na konci transakcie neexistovala zmluva, celkový transakčný poplatok by sa jednoducho rovnal poskytnutej GASPRICE vynásobenej dĺžkou transakcie v bajtoch a údaje odoslané spolu s transakciou by neboli relevantné.

V tomto prípade by všetok plyn využíval baník na zabezpečenie žiadneho výsledku, pretože neexistuje žiadna zmluva.

Správy a transakcie fungujú za rovnakých podmienok, pokiaľ ide o vrátenie: ak dôjde k spusteniu správy, dôjde k jej vykonaniu a všetky ostatné spustenia, ktoré sa pri tomto spustení spustia, sa vrátia, ale rodičovské vykonanie sa nemusí vrátiť.

To znamená, že pre zmluvu je „bezpečné“ uzavrieť inú zmluvu, ako keby A volala B plynom G, potom je zaručené, že vykonávanie A stratí najviac G plynu. Rodičovské popravy mimo zmlúv sa však nevracajú.

Existuje aj operačný kód CREATE, ktorý vytvára zmluvu. Jeho realizačná mechanika je vo všeobecnosti podobná CALL, s výnimkou, že výstup realizácie určuje kód novovytvorenej zmluvy.

Budeme sa ponoriť podrobnejšie do našich budúcich podrobných technických blogových príspevkov.

Vykonanie kódu

Kód v zmluvách spoločnosti Ethereum je písaný v nízkoúrovňovom jazyku bytecode založenom na stohoch, ktorý sa nazýva „kód virtuálneho počítača Ethereum“ alebo „kód EVM“. Kód EVM je v podstate rad bajtov a každý bajt je operácia.

„Vykonanie kódu je nekonečná slučka, ktorá pozostáva z opakovaného vykonávania operácie na aktuálnom programovom počítadle (ktoré začína na nule) a následnom zvyšovaní programového počítadla o jednu, až kým sa nedosiahne koniec kódu alebo sa neobjaví chyba alebo STOP alebo RETURN. je detekovaná inštrukcia. “

Operácie majú prístup k trom typom priestoru, v ktorom sa môžu ukladať údaje:

  1. Zásobník, kontajner typu last-in-first-out, do ktorého je možné hodnoty posúvať a otvárať ako typický zásobník.
  2. Pamäť, nekonečne rozšíriteľné bajtové pole.
  3. Ukladací priestor, kľúč / hodnota. Na rozdiel od zásobníka a pamäte, ktorá sa obnoví po ukončení výpočtu, ukladanie pretrváva dlhodobo.

Kód má tiež prístup k hodnote, odosielateľovi, údajom prichádzajúcej správy a hlavičke bloku. Kód môže tiež vrátiť bajtové pole údajov ako výstup.

Realizačný model kódu EVM je pomerne jednoduchý. Budeme ju ďalej skúmať v nasledujúcich krokoch.

Kým je spustený virtuálny stroj Ethereum, jeho úplný výpočtový stav možno definovať pomocou n-tice. Tuple pozostáva z block_state, transakcie, správy, kódu, pamäte, stohu, pc a plynu.

Block_state je globálny stav obsahujúci všetky účty a zahŕňa zostatky a úložisko.

Na začiatku každého kola vykonávania sa aktuálna inštrukcia nájde tak, že sa vezme pc-tý ​​bajt kódu (alebo 0, ak pc> = len (kód)), čo znamená, že pc sa považuje za nulu, ak je väčšie alebo rovnaké. na dĺžku kódu.

Každá inštrukcia má svoju vlastnú definíciu toho, ako to ovplyvní n-ticu.

ADD vyskočí dve položky zo stohu, posunie ich súčet, zníži plyn o 1 a prírastky ks o 1 (typické spracovanie stohu)

SSTORE vyskočí prvé dve položky zo zásobníka a vloží druhú položku do zmluvného úložiska podľa indexu určeného prvou položkou.

Existuje mnoho spôsobov, ako optimalizovať vykonávanie EVM pomocou kompilácie just-in-time, základnú implementáciu Ethereum možno vykonať v niekoľkých stovkách riadkov kódu.

Blockchain a ťažba

Ethereum blockchain je viac-menej podobný Bitcoin blockchainu s niekoľkými jemnými rozdielmi.

Hlavný rozdiel medzi Ethereum a bitcoinmi, pokiaľ ide o architektúru blockchainu, je ten, že na rozdiel od bitcoínov (ktoré obsahujú iba kópiu zoznamu transakcií), bloky Ethereum obsahujú kópiu zoznamu transakcií, najnovší stav, číslo bloku a obtiažnosť.

Algoritmus základného overenia bloku v Ethereum sa dá vysvetliť v nasledujúcich krokoch:

  1. Skontrolujte, či predchádzajúci blok, ktorý je predmetom odkazu, existuje a je platný.
  2. Skontrolujte, či je časová pečiatka bloku väčšia ako časová značka referenčného predchádzajúceho bloku a menej ako 15 minút do budúcnosti.
  3. Skontrolujte, či je platný počet blokov, ťažkosti, koreň transakcie, strýko root a limit plynu (rôzne koncepty špecifické pre nízkoúrovňové etéry, ktoré budú uvedené neskôr).
  4. Skontrolujte, či je doklad o práci na bloku platný.
  5. Nech S [0] je stav na konci predchádzajúceho bloku. (spomeňte si na to, čo bolo prediskutované a vysvetlené v predchádzajúcom blogovom príspevku)
  6. Nech TX je zoznam transakcií bloku s n transakciami. Pre všetky i v 0 ... n-1 nastavte S [i + 1] = APLIKOVAŤ (S [i], TX [i]). Ak niektorá aplikácia vráti chybu alebo ak celkový plyn spotrebovaný v bloku až do tohto bodu prekročí GASLIMIT, vráťte chybu.
  7. Nech S_FINAL je S [n], ale sčítanie blokovej odmeny vyplatenej bani (S_FINAL = S [n] + Bloková odmena). Odmena sa udeľuje, keď baník úspešne dokončí ťažbu bloku.
  8. Skontrolujte, či sa koreň stromu Merkle v štáte S_FINAL rovná hlavnému koreňu stavu v záhlaví bloku. Ak je, blok je platný; inak to nie je platné. (Merkle strom a validácia s hlavičkou bloku je vysvetlená pomocou relevantných obrázkov v predchádzajúcom blogovom príspevku)

Prístup ukladania celého štátu v každom bloku sa môže na prvý pohľad zdať neefektívny, ale je porovnateľný s prístupom bitcoínu.

Stav je uložený v stromovej štruktúre a po každom bloku je potrebné zmeniť iba malú časť stromu. To znamená, že medzi dvoma susednými blokmi by veľká väčšina stromu mala byť rovnaká. Dáta môžu byť uložené raz a odkazované dvakrát pomocou ukazovateľov (hash of subtrees).

Na tento účel sa používa špeciálny druh stromu známy ako „strom Patricia“ vrátane úpravy konceptu stromu Merkle, ktorý umožňuje efektívne vkladanie a mazanie uzlov.

Navyše, pretože všetky informácie o stave sú súčasťou posledného bloku, nie je potrebné ukladať celú históriu blockchainu.

Bežnou otázkou je „kde“ je zmluvný kód vykonaný z hľadiska fyzického hardvéru.

Proces vykonávania zmluvného kódu je definovaný v samotnej funkcii prechodu štátu, ktorá je súčasťou algoritmu validácie blokov. Ak je transakcia pridaná do bloku B, vykoná sa vykonanie kódu vygenerovaného touto transakciou všetkými uzlami, ktoré stiahnu a overia blok B, buď teraz alebo v budúcnosti.

Znamená to koniec časti 2 bielej knihy Ethereum. V ďalšej časti budeme diskutovať aplikácie protokolu Ethereum a ekosystému v reálnom čase.