Ethereum fehér könyv, magyarázat. 2. rész

Az Ethereum a középpontjában az volt, hogy protokollt készítsen számos decentralizált alkalmazás számára, számos felhasználási esettel.

Turing teljes programozási nyelvet biztosítanak, ahol a fejlesztési idő, a biztonság és az interakciók a dappok (decentralizált alkalmazások) között fontosak. A Turing teljes programozható blokklánc lehetővé teszi az intelligens szerződések széles skálájának kidolgozását, amelyek sokkal kifinomultabbak, mint a Bitcoin.

Filozófia

Az Ethereum a következő öt alapelvre épül.

Egyszerűség

Az Ethereum egyszerű protokollként épül fel, amelynek elképzelése, hogy mindenki számára nyitva áll, még a

az adattárolás költsége és az időhiányosság. Bármely átlagos programozónak képesnek kell lennie arra, hogy kiválassza a

munkafolyamat és a projektek könnyű végrehajtása. Ez elősegíti a példa nélküli megvalósítását

a Blockchain és a Cryptocurrency lehetőségei.

egyetemesség

Az Ethereum Turing teljessége segít bármilyen intelligens szerződés létrehozásában

matematikailag meghatározva. Deviza, származékos termékek vagy a saját Skynet, bármi megépíthető. Ha azonban tervezi a Skynet kiépítését, akkor lehet, hogy sok blokkoló szerződésre van szüksége, és elegendő gázzal kell táplálnia őket az intelligens szerződés futtatásához.

A modularitás

Az Ethereum úgy van megtervezve, hogy a protokoll minden részét külön-külön is fel lehessen osztani. Még akkor is, ha valaki kicsivel módosítja a protokollt egy helyen, az alkalmazásköteg többi részét látszólag nem érinti, és további módosítások nélkül működik tovább.

Az olyan innovációk, mint az Ethash, a módosított Patricia fák és az RLP (amelyekről a jövőbeli beszámolók tárgyalnak), külön, teljes könyvtárakként kerülnek megvalósításra. Az Ethereum fejlesztése azért történik, hogy az egész kriptovaluta rendszer számára hasznot húzzon, és ne csak magát.

Agilitás

Az Ethereum protokoll konstrukciói nem kerülnek kőbe, bár a magas szintű konstrukciók módosítása csak mérlegelés szerint történik.

Megkülönböztetésmentesség és cenzúramentesség

Mivel valóban nyitott minden protokoll számára, az Ethereum segítségével bármilyen és bármilyen alkalmazás fejleszthető. Az Ethereumban alkalmazott szabályozási mechanizmusokat az ökoszisztéma káros hatásainak korlátozására és minimalizálására használják, nem pedig az alkalmazások egy meghatározott kategóriájára.

Például futtathat egy végtelen hurok szkriptet, mindaddig, amíg megfizeti a bányászoknak a kód futtatásáért szükséges és releváns díjakat.

Ethereum számlák

Az Ethereumban az állam „számlák” elnevezésű objektumokból áll, ahol minden egyes fiók 20 bájtos nyilvános címmel rendelkezik. Az államátmenetek érték- és információátvitel két vagy több számla között. Az Ethereum-fiók a következő négy mezőt tartalmazza.

  • nonce; ez egy számláló, amely biztosítja, hogy minden tranzakció csak egyszer feldolgozható legyen
  • A számla jelenlegi éter-egyenlege
  • A fiók szerződés kódja (ha van, az intelligens szerződésekre alkalmazható)
  • A fiók tárolója (alapértelmezés szerint üres)

Az éter az Ethereumban használt fő üzemanyag, amelyet tranzakciós díjakhoz használnak, más néven Gwei néven.

Kétféle számla létezik:

  1. Külső tulajdonú számlák; privát kulcsok által vezérelt: Nincs benne rejlő kód. Az üzeneteket tranzakció létrehozásával és aláírásával küldik el.
  2. Szerződéses számlák; szerződéses kóddal vezérelt: A kód a fogadott üzenet tartalmától függően aktiválódik, és aktiválhatóak a további folyamatok, például az olvasás és írás a belső tárolóba, más üzenetek küldése vagy szerződések létrehozása.

A második típusú számlát egy kriptovaluta-kivezetés használja: a Blockchain Board of derivatívák az őrizetlen intelligens szerződéses pénztárca rendszerében.

Az intelligens szerződések önálló ügynökök, amelyek az Ethereum környezetben élnek és kódot hajtanak végre, amikor tranzakció vagy üzenet útján továbbítják azokat. Az ilyen szerződések közvetlenül ellenőrizhetik éter-egyenlegüket és saját kulcstárolójukat.

tranzakciók

Az Ethereumban végzett tranzakció lényegében aláírt és titkosított adatcsomag, amely egy külső tulajdonban lévő számláról küldött üzenetet tárol.

A tipikus tranzakciók a következőket tartalmazzák:

  • Az üzenet címzettje (a címzett nyilvános kulcsa)
  • A feladót azonosító aláírás (a feladó privát kulcsa)
  • A feladó és a címzett között átadandó éter mennyisége
  • Opcionális adatmező
  • A STARTGAS érték, amely a számítási lépések maximális számát képviseli, amelyet a tranzakció végrehajtása megengedett
  • GASPRICE érték, amely a feladó által a számítási lépésben fizetett díjat képviseli

Bontjuk le ezeket az egyes pontokat. Az első három olyan standard mező, amely minden kriptovalutában jelen van. Az adatmezőnek nincs alapértelmezett funkciója, hanem egy szerződés felhasználhatja az adatok elérésére. Például, ha egy szerződés domain regisztrációs szolgáltatásként működik, akkor esetleg azt szeretné értelmezni, hogy az átadott adatok két „mezőt” tartalmaznak, az első mező egy regisztrálandó tartomány, a második mező pedig az IP cím regisztrálja a domaint a. A szerződés elolvassa ezeket az értékeket az üzenet adataiból, és megfelelően tárolja őket.

A STARTGAS és a GASPRICE mezők döntő jelentőségűek az Ethereum szolgáltatásmegtagadás elleni modelljében. A végtelen hurkok vagy más számítási veszteségek elkerülése érdekében minden tranzakcióhoz meg kell határozni a felhasználható számítási lépések számának korlátját. A számítás alapvető egysége a „gáz”. Általában egy számítási lépés 1 gázt fizet, de egyes műveletek magasabb gázmennyiséget igényelnek, mivel számítási szempontból drágábbak vagy megnövelik az állam részeként tárolandó adatok mennyiségét.

A tranzakcióadatokban minden bájtért 5 gáz fizet. A díjrendszer arra készteti a támadót, hogy arányosan fizesse az összes felhasznált erőforrást, beleértve a számítást, a sávszélességet és a tárolást. Ezért minden olyan tranzakció, amely nagy hálózati fogyasztáshoz vezet, magasabb gázdíjat eredményez.

Egyszerűen fogalmazva: a fizetett gáz közvetlenül arányos a blokkláncon elvégzett számítások számával és összetettségével.

üzenetek

A szerződések üzeneteket küldhetnek más szerződésekhez.

A tipikus üzenetek a következőket tartalmazzák:

  • Az üzenet feladója
  • Az üzenet címzettje
  • Az üzenettel átvitt étermennyiség
  • Opcionális adatmező
  • STARTGAS érték

Az üzenet hasonló a tranzakcióhoz, azzal az eltéréssel, hogy az üzeneteket egy szerződés hozza létre, és nem egy külső tulajdonban lévő fiókkal. Az üzenet akkor kerül előállításra, amikor egy szerződés végrehajtó kód végrehajtja a CALL opódot, előállítva és végrehajtva egy üzenetet.

Az üzenetet a fogadó fiók veszi, amely ezt követően futtatja a kódját. Ilyen módon a szerződések más szerződésekkel kapcsolatosan érvényesíthetők, hasonlóan a külső tulajdonban lévő számlákhoz.

A szerződés által kiosztott gázelosztás vonatkozik mind a tranzakció során felhasznált gázra, mind az összes végrehajtásra.

Megértjük ugyanezt egy példával.

A @A egy külső tulajdonú számla

A @B szerződés

Az @A @B tranzakciót küld 1000 gázzal.

A @B 600 gázt fogyaszt, és üzenetet küld a @C-nek.

A @C belső végrehajtása 300 gázt fogyaszt.

1000-600-300 = 100

Ez azt jelenti, hogy a @B szerződés csak további 100 gázt költehet számításra / üzenetre / tranzakcióra, mielőtt elfogy a gáz.

Ethereum állapotátmeneti funkció

A sorozat 1. részében említettek szerint emlékeztethet az állapotátmeneti funkcióra

ALKALMAZÁS (S, TX) -> S ”

További lépések történnek a fehér könyvből, és nagyjából önmagukban állnak:

  1. A tranzakciónak megfelelő számú értékkel kell rendelkeznie, az aláírásnak érvényesnek kell lennie, és a nonce-nek meg kell egyeznie a feladó fiókjában található nonce-vel. Ha nem felel meg, dobjon el hibát.
  2. A tranzakciós díjat STARTGAS * GASPRICE formában kell kiszámítani, a küldési cím az aláírás alapján meghatározható. Vonja le a díjat a feladó egyenlegéből, és növelje meg a feladó nonce értékét. Ha nincs elég egyensúly költeni, dobjon el hibát.
  3. Inicializálja a GAS = STARTGAS-t, és bájtonként egy bizonyos mennyiségű gázt levetnek a tranzakcióban a byte-k megfizetésére.
  4. Vigye át a tranzakció értékét a küldő fiókjából a fogadó fiókba. Ha a fogadó fiók még nem létezik, hozza létre. Ha a fogadó számla szerződés, futtassa a szerződés kódját akár a teljesítésig, akár addig, amíg a végrehajtás el nem fogy.
  5. Ha az értékátutalás sikertelen azért, mert a küldőnek nem volt elegendő pénz, vagy a kód végrehajtása kifogyt a benne, akkor térítse vissza az összes állapotváltozást, kivéve a díjak megfizetését, és adja hozzá a díjakat a bányász számlájához. A díjak megfizetése nem téríthető vissza, mivel a bányász energiát költ az ügylet megkönnyítése érdekében.
  6. Ellenkező esetben térítse meg a feladónak az összes fennmaradó gáz díját, és küldje el a bányásznak az elfogyasztott díjat.

Tegyük fel, hogy a szerződés kódja a következő:

önálló tárolás [híváslista (0)]:
saját tárolás [híváslista (0)] = híváslista (32)

A szerződés valójában alacsony szintű EVM kóddal van írva, de a fenti példa kígyó.

Nézzük meg például egy példát:

A szerződés tárolója kezdetben üres, és egy tranzakciót 10 éterértékkel, 2000 gázzal, 0,001 étergázárral és 64 bájt adattal küldik el, 0–31 bájtot jelölve a 2. számot, és 32–63 bájtot hordozva a CHARLIE karakterláncot.

Az állapotátmeneti funkció folyamata ebben a forgatókönyvben a következő. Ezek a lépések hasonlóak a fenti általános példában említettekhez.

  1. Ellenőrizze, hogy a tranzakció érvényes és megfelelő-e.
  2. Ellenőrizze, hogy a tranzakció feladójának legalább 2000 * 0,001 = 2 étere van-e. Ha igen, akkor vonj le 2 étert a feladó fiókjából. (Mivel a képletet a STARTGAS * GASPRICE-nak kell használni)
  3. Inicializálja a gázt = 2000; Feltételezve, hogy a tranzakció 170 bájt hosszú, és a bájtdíj 5, vonja le a 850-et (170 * 5), így marad 1150 (2000–850) gáz.
  4. Levonj további 10 étert a feladó fiókjából, és add hozzá a szerződés fiókjához.
  5. Futtassa a kódot. Ebben az esetben ez egyszerű: ellenőrzi, hogy a szerződés tárolása a 2. indexben történik-e, észreveszi, hogy nem, és ezért a 2. indexben a tárolást CHARLIE értékre állítja. Tegyük fel, hogy ez 187 gázt igényel, tehát a fennmaradó gázmennyiség 1150–187 = 963
  6. Adjon vissza 963 * 0,001 = 0,963 étert a feladó fiókjához, és adja vissza az eredményül kapott állapotot.

Ez befejezi a teljes folyamatban elvégzett lépéseket.

Ha a tranzakció fogadó végén nem lenne szerződés, akkor a teljes tranzakciós díj egyszerűen megegyezik a megadott GASPRICE-vel, szorozva a tranzakció hosszával byte-ban, és a tranzakcióval együtt küldött adatok nem relevánsak.

Ebben az esetben az összes bázist egy bányász felhasználná eredménytelen eredmény elérésére, mivel nem létezik szerződés.

Az üzenetek és a tranzakciók hasonló feltételekkel működnek a visszatéréseknél: ha az üzenet végrehajtása elfogy, akkor az üzenet végrehajtása és az összes többi végrehajtás, amelyet ez a végrehajtás váltott ki, visszaáll, de a szülői végrehajtást nem kell visszaállítani.

Ez azt jelenti, hogy „biztonságos” egy másik szerződés meghívása, mintha A hívja B-t G-gázzal, akkor az A végrehajtása garantáltan elveszíti legfeljebb G-gázt. A szülők szerződésen kívüli végrehajtása azonban nem tér vissza.

Ezenkívül van egy CREATE opciókód is, amely szerződést hoz létre. Végrehajtási mechanizmusa általában hasonló a CALL-hoz, azzal a kivétellel, hogy a végrehajtás kimenete határozza meg az újonnan létrehozott szerződés kódját.

A továbbiakban alapos műszaki blogbejegyzéseinkben részletesebben foglalkozunk az opóddal.

Kódfuttatás

Az Ethereum szerződésekben szereplő kód alacsony szintű, verem-alapú bájtkód nyelven íródik, amelyet „Ethereum virtuális gép kódjának” vagy „EVM kódnak” neveznek. Az EVM kód alapvetően bájt sorozat, és minden bájt egy művelet.

„A kódfuttatás egy végtelen hurok, amely abból áll, hogy a műveletet az aktuális programszámlálón (amely nullával kezdődik) ismételten elvégezzük, majd a programszámlálót egyvel megnöveljük, amíg el nem éri a kód végét, vagy meg nem jelenik a hiba, vagy STOP vagy RETURN utasítás észlelve. ”

A műveletek háromféle helyhez férnek hozzá, ahol adatok tárolhatók:

  1. Verem, egy utolsó-az-első-kimeneti tároló, amelybe az értékeket át lehet tolni és felbukkanni, mint egy tipikus verem.
  2. Memória, egy végtelenül bővíthető byte-tömb.
  3. Tárolás, kulcs / érték tároló. Ellentétben a veremmel és a memóriával, amely a számítás befejezése után áll vissza, a tárolás hosszú távon fennmarad.

A kód hozzáférhet az értékhez, a feladóhoz, a bejövő üzenet adataihoz és a blokk fejlécéhez is. A kód visszaadhat egy bájt adatsort is kimenetként.

Az EVM kód végrehajtási modellje meglehetősen egyszerű. Az alábbiakban részletesebben megvizsgáljuk.

Amíg az Ethereum virtuális gép fut, annak teljes számítási állapotát a rendszer határozhatja meg. A tupla áll államállapotból, tranzakcióból, üzenetből, kódból, memóriából, veremből, számítógépből és gázból.

A „alapállapot” itt a globális állam, amely az összes számlát tartalmazza, egyenlegeket és tárolókat is magában foglal.

A végrehajtás minden fordulójának kezdetén az aktuális utasítás megtalálható a pc pc-bájtjának (vagy 0, ha pc> = len (kód)) levételével, ami azt jelenti, hogy a pc nullának tekinthető, ha nagyobb vagy egyenlő a kód hosszához.

Minden utasításnak megvan a saját meghatározása, hogyan befolyásolja a párosítást.

Az ADD kiiktat két elemet a veremről, kiszorítja azok összegét, 1-rel csökkenti a gázszintet és 1-rel növeli a pc-t (a verem tipikus működése)

Az SSTORE felpattan a legfelső két elemre a veremről, és a második elemet a szerződés tárolójába helyezi az első elem által megadott index alatt.

Az EVM végrehajtásának optimalizálására számos módszer van a just-in-time összeállítással, az Ethereum alapvető megvalósítása néhány száz sor sorban végezhető el.

Blokklánc és bányászat

Az Ethereum blokklánc néhány apró különbséggel többé-kevésbé hasonlít a Bitcoin blokkláncához.

Az Ethereum és a Bitcoin közötti fő különbség a blokklánc architektúrája szempontjából az, hogy ellentétben a Bitcoin-tal (amely csak a tranzakciók listáját tartalmazza), az Ethereum blokkok tartalmazzák a tranzakciók listájának másolatát, a legfrissebb állapotot, a blokk számát és a nehézség.

Az alapvető blokk-érvényesítési algoritmus az Ethereum-ban a következő lépésekben magyarázható:

  1. Ellenőrizze, hogy létezik-e a korábban hivatkozott blokk és érvényes-e.
  2. Ellenőrizze, hogy a blokk időbélyege nagyobb-e, mint a hivatkozott előző mondaté, és kevesebb, mint 15 perc a jövőben.
  3. Ellenőrizze, hogy a blokk száma, a nehézség, a tranzakció gyökere, a nagybátyja gyökér és a gázkorlát (különböző alacsony szintű Ethereum-specifikus fogalmak, amelyeket később fedezünk be) érvényesek.
  4. Ellenőrizze, hogy a blokkon végzett munka igazolása érvényes-e.
  5. Legyen S [0] az előző mondat végén levő állapot. (Emlékezzünk erre az előző blogbejegyzésben tárgyalt és magyarázott kérdésekre)
  6. Legyen TX a blokk tranzakciólistája, n tranzakcióval. Az összes i esetén 0… n-1-ben állítsa be az S [i + 1] = ALKALMAZÁS (S [i], TX [i]) beállítást. Ha bármely alkalmazás hibát ad vissza, vagy ha a blokkban felhasznált teljes gáz mennyisége, amíg ez a pont meg nem haladja a GASLIMIT-et, adja meg a hibát.
  7. Legyen S_FINAL S [n], de hozzáadva a bányásznak fizetett blokk jutalmat (S_FINAL = S [n] + Blokk jutalom). A jutalmat akkor kapják, amikor egy bányász sikeresen elvégezte a blokk bányászatát.
  8. Ellenőrizze, hogy az S_FINAL állapot Merkle fa gyökere megegyezik-e a blokk fejlécében megadott végső állapot gyökérrel. Ha igen, akkor a blokk érvényes; egyébként nem érvényes. (A Merkle fa és az érvényesítés a blokk fejlécével az előző blogbejegyzés releváns képeivel magyarázható)

A teljes állapot tárolása minden blokkban eleinte hatékonynak tűnhet, de összehasonlítható a Bitcoinéval.

Az állapotot a fa szerkezete tárolja, és minden blokk után csak a fa egy apró részét kell megváltoztatni. Ez azt jelenti, hogy két szomszédos blokk között a fa nagy többségének azonosnak kell lennie. Az adatok egyszer tárolhatók és kétszer hivatkozhatók mutatók segítségével (az alsófák hash -jai).

Ennek végrehajtására egy speciális fa, „Patricia fa” néven kerül sor, beleértve a Merkle fa koncepciójának olyan módosítását, amely lehetővé teszi a csomópontok hatékony beillesztését és törlését.

Ezenkívül, mivel az összes állapotinformáció az utolsó blokk része, nincs szükség a teljes blokklánc-előzmények tárolására.

Gyakran feltett kérdés a „hol” a szerződés kódjának végrehajtása a fizikai hardver szempontjából.

A szerződés kód végrehajtásának folyamatát az állapotátmeneti függvény határozza meg, amely a blokk érvényesítési algoritmus része. Ha egy tranzakciót hozzáadnak a B blokkhoz, akkor az adott tranzakció által kiváltott kódfuttatást minden olyan csomópont végrehajtja, amelyek letöltik és érvényesítik a B blokkot, akár most, akár a jövőben.

Ez jelzi az Ethereum fehér könyv 2. részének végét. A következő részben az Ethereum protokoll és az ökoszisztéma valós idejű alkalmazásairól beszélünk.