Oldal legutoljára frissítve: 2023. március 23.

Ethereum fehérkönyv

Ezt a bemutató kiadványt eredetileg 2013-ban adta ki Vitalik Buterin, az Ethereum alapítója, a projekt 2015-ös indulása előtt. Fontos megjegyezni, hogy az Ethereum sok másik közösség által vezetett, nyílt forráskódú szoftver projekthez hasonlóan, a kezdeti elindulás óta fejlődött.

Noha több éve íródott, fenntartjuk ezt a kiadványt, mert továbbra is hasznos referenciaként szolgál és pontos ábrázolást mutat az Ethereumról és annak jövőképéről. Ha többet szeretnél megtudni az Ethereum legutóbbi fejlesztéseiről és az általunk elvégzett protokoll változtatásokról, akkor ezt az útmutatót ajánljuk.

Az okosszerződések és decentralizált alkalmazás platformok következő generációja

Satoshi Nakamoto 2009-ben történő Bitcoin fejlesztését gyakran a pénz és a pénznem radikális fejleményének nevezték, ez az első példa egy olyan digitális eszközre, amelynek egyszerre nincs háttér vagy belső értéke(opens in a new tab)↗, valamint nincs központi kibocsájtója vagy irányítója. A Bitcoin kísérlet másik - vitathatatlanul fontosabb - része azonban az alapjául szolgáló blokklánc technológia, mint az elosztott konszenzus eszköze, és a figyelem gyorsan kezd áttérni a Bitcoin ezen másik aspektusára. A blokklánc technológia gyakran idézett alternatív alkalmazásai közé tartozik az blokkláncon lévő digitális eszközök használata az egyedi valuták és pénzügyi eszközök reprezentálására (colored coins(opens in a new tab)↗), a mögöttes fizikai eszköz tulajdonjoga (smart property(opens in a new tab)↗), nem felcserélhető eszközök, mint a domén nevek (Namecoin(opens in a new tab)↗), vagy a komplexebb alkalmazások, melyek digitális javak közvetlen irányítását vonják magukkal egy tetszőleges szabályrendszert követő kód alapján (smart contracts(opens in a new tab)↗) vagy akár blokklánc alapú decentralizált autonóm szervezetek(opens in a new tab)↗ (DAO-k). Az Ethereum egy olyan beépített, teljesen kidolgozott Turing-teljes programozási nyelvvel rendelkező blokkláncot szeretne nyújtani, amely használható olyan "szerződések" létrehozására, amelyek tetszőleges állapotátmeneti funkciók kódolására használhatóak, lehetővé téve a felhasználók számára a fent leírt rendszerek bármelyikének létrehozását, valamint sok olyan más dolgot is, melyre még nem gondoltunk, egyszerűen a logika pár sornyi kódként való leírásával.

Bevezetés a Bitcoinba és a létező fogalmakba

Előzmények

A decentralizált digitális valuta, valamint az alternatív alkalmazások, például az ingatlan-nyilvántartások fogalma évtizedek óta létezik. Az 1980-as és 1990-es évek anonim e-cash protokolljai, melyek főleg a Chaum féle vakításként ismert kriptográfiai primitívre támaszkodtak, egy magas fokú adatvédelemmel rendelkező valutát kínáltak, de a protokolloknak többnyire nem sikerült elterjedniük, mivel egy centralizált közvetítőre támaszkodtak. 1998-ban Wei Dai b-money-je(opens in a new tab)↗ vált az első javaslattá, mely bemutatta a pénz létrehozásának számítási kirakósok megoldásával történő ötletét, valamint a decentralizált konszenzust, de a javaslat kevés részletet tartalmazott arról, hogy hogyan lehetne megvalósítani a decentralizált konszenzust a gyakorlatban. 2005-ben Hal Finney bemutatta az újrafelhasználható munkabizonyítékokat(opens in a new tab)↗, egy olyan rendszert, amely a b-pénzből származó ötleteket és Adam Back számítási szempontból nehéz Hashcash rejtvényeit használta fel a kriptovaluta koncepciójának megalkotására, de az ideálistól ez is elmaradt azáltal, hogy egy megbízható számítási backendre támaszkodott. Először 2009-ben került bevezetésre a gyakorlatban egy decentralizált valuta Satoshi Nakamoto által, amely egyesítette az alapként szolgáló már létező primitíveket amik a tulajdonjog publikus kulcs kriptográfiával történő kezelésére szolgáltak, egy konszenzus algoritmussal, mely az érmék tulajdonosainak számontartására szolgál és amit "munkabizonyítéknak" nevezünk.

A proof-of-work mögötti mechanizmus egy áttörés volt, mivel egyszerre két problémára is megoldást nyújtott. Egyrészt egy olyan egyszerű és mérsékelten hatékony konszenzus algoritmust biztosított, amely lehetővé teszi a hálózat csomópontjainak, vagyis a résztvevő számítógépeknek (node-ok), hogy kollektíven egyetértsenek a Bitcoin főkönyvi állapotának kanonikus frissítéseiről. Másrészt egy olyan mechanizmust biztosított, amely szabad belépést tesz lehetővé abba a konszenzus folyamatba, mely megoldja annak a politikai problémának az eldöntését, hogy ki befolyásolja a konszenzust, emellett a Sybil-támadásokat is megelőzi. Ezt úgy teszi meg, hogy a részvétel formális akadályát - mint például egy adott listán egyedi entitásként való nyilvántartásba vétel követelményét - gazdasági akadályokkal helyettesíti: egy résztvevő csomópont súlya a konszenzusos szavazási folyamatban közvetlenül arányos azzal a számítási erővel, amivel a csomópont rendelkezik. Azóta javaslattétel született egy alternatív megközelítésre, amit letétbizonyítéknak hívnak, mivel a hálózaton résztvevő számítógép, vagy csomópont (node) súlyozását a valuta letétbe helyezésének arányában számítja ki, nem pedig annak számítási kapacitása alapján; a két megközelítés relatív előnyeinek megvitatása meghaladja ennek a cikknek a kereteit, de meg kell jegyezni, hogy mindkét megközelítés felhasználható egy kriptovaluta alapjaként.

Itt egy blog bejegyzés Vitalik Buterintől, az Ethereum alapítójától az Ethereum előtörténetéről(opens in a new tab)↗. Itt(opens in a new tab)↗ egy másik blog bejegyzés további történetekkel.

Bitcoin, mint egy állapot átmeneti rendszer

Technikai szempontból egy kriptovaluta, például a Bitcoin főkönyve egy állapot átmeneti rendszernek tekinthető, ahol van egy "állapot", amely számon tartja az összes létező bitcoin tulajdonosi státuszát, és egy "állapot átmeneti függvény", ami az állapothoz egy tranzakció hozzáadásával egy új állapotot eredményez. Például egy szabályos banki rendszerben az állapot a vagyonmérlegnek felel meg, a tranzakció egy kérvény $X összeg átmozgatására A-ból B-be, az állapot átmeneti függvény pedig csökkenti A számlájának értékét $X összeggel, valamint növeli B számlájának értékét $X összeggel. Ha az A számla kevesebb összeggel rendelkezik mint $X, akkor az állapot átmeneti függvény egy hiba jelzést ad vissza. Tehát így definiálható formálisan:

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

A fentiekben leírt banki rendszerben:

APPLY({ Alice: $50, Bob: $50 },"küld $20 Alice-tól Bob-nak") = { Alice: $30, Bob: $70 }

De:

APPLY({ Alice: $50, Bob: $50 },"küld $70 Alice-tól Bob-nak") = ERROR

A Bitcoin "állapota" az összes érme együttvéve (műszaki nyelven "elköltetlen tranzakciós kimenetek" vagy UTXO), amelyek ki lettek bányászva és még nem lettek elköltve. Minden UTXO-nak van egy névértéke és egy tulajdonosa (melyet egy 20 bájtos cím határoz meg, mely lényegében egy kriptográfiai publikus kulcs^{fn. 1}). Egy tranzakció egy vagy több bemenetet tartalmaz, és mindegyik bemenet tartalmaz egy hivatkozást egy meglévő UTXO-ra és egy kriptográfiai aláírást, amelyet a tulajdonos címéhez társított privát kulcs hoz létre, és egy vagy több kimenetet, ahol minden egyes kimenet egy új UTXO-t tartalmaz, amik aztán hozzáadódnak az állapothoz.

Az állapot átmeneti függvény APPLY(S,TX) -> S' nagyjából a következő módon definiálható:

1. Minden egyes bemenetre a TX-ben:

   • Ha a hivatkozott UTXO nincs benne az S-ben, hiba visszaadása.
   • Ha a szolgáltatott aláírás nem egyezik az UTXO tulajdonosának aláírásával, hiba visszaadása.

2. Ha az összes bemeneti UTXO egység összege kisebb, mint az összes kimeneti UTXO egység összege, hiba visszaadása.

3. S' visszaadása az összes bemeneti UTXO elvételével és az összes UTXO hozzáadásával.

Az első lépés első fele megakadályozza, hogy a tranzakciók feladói nem létező érméket költsenek el, az első lépés második fele pedig megakadályozza, hogy a tranzakciók feladói mások érméit költsék el, a második lépés pedig az érték megőrzését hajtja végre. Ahhoz, hogy ezt fizetésnél használjuk, a protokoll a következő. Tegyük fel, hogy Alice 11,7 BTC-t szeretne Bob-nak átutalni. Először Alice megkeresi az általa birtokolt elérhető UTXO-k egy olyan halmazát, melynek összege legalább 11.7 BTC. A valóságban Alice nem fog pont 11.7 BTC-t találni; mondjuk, hogy a legkisebb, amit megtalált 6+4+2=12. Ezután elkészít egy tranzakciót ezzel a három bemenettel és két kimenettel. Az első kimenet 11.7 BTC lesz, aminek Bob címe lesz a tulajdonosa, a második kimenet pedig a maradék 0.3 BTC "visszajáró", melynek maga Alice a tulajdonosa.

Bányászat

Ha hozzáférnénk egy megbízható, központosított szolgáltatáshoz, ezt a rendszert jelentéktelen lenne megvalósítani; mivel ugyanezt pontosan a leírtak szerint lehetne kódolni, egy központosított, azaz centralizált szerver merevlemezén tárolva az állapotot. Azonban a Bitcoinnal egy decentralizált pénz rendszert próbálunk építeni, így az állapot átmeneti rendszert egy konszenzus rendszerrel kell kombinálnunk, hogy biztosítsuk, hogy mindenki egyetért a tranzakciók sorrendje felett. A Bitcoin decentralizált konszenzus folyamata elvárja a hálózat résztvevőitől, hogy folyamatosan tranzakciókból álló csomagokat próbáljanak készíteni, melyeket '"blokkoknak" hívunk. A hálózat nagyjából egy blokkot szándékozik gyártani minden tizedik percben, ahol minden egyes blokk tartalmaz egy időbélyeget, egy nonce-t, egy hivatkozást az előző blokkra (vagyis hash-t), és az összes olyan tranzakciót tartalmazó listát, melyek az előző blokk után következtek. Idővel egy tartós, folyamatosan növekvő "blokklánc" jön létre, mely folyamatosan frissül, hogy a Bitcoin főkönyv legutóbbi állapotát reprezentálja.

A blokkok érvényességét ellenőrző algoritmust az alábbi paradigma szerint lehet kifejezni:

1. Ellenőrizni, hogy a blokk által hivatkozott előző blokk létezik és érvényes.
2. Ellenőrizni, hogy a blokk időbélyege nagyobb-e, mint az előző blokké^{fn. 2} és kevesebb mint 2 óra telt el azóta
3. Ellenőrizni, hogy a blokk munkabizonyítéka érvényes-e.
4. Legyen S[0] az előző blokk után lévő állapot.
5. Legyen TX a blokk tranzakciós listája n tranzakcióval. Minden i-re 0...n-1-ig, S[i+1] = APPLY(S[i],TX[i]) Ha bármely lépés hibát ad vissza, kilépni és false értéket visszaadni.
6. True visszaadása, és S[n] regisztrálása az állapotként a blokk végén.

Lényegében a blokkban szereplő minden tranzakciónak érvényes állapot átmenetet kell biztosítania a tranzakció lefutása előtti kanonikus állapotból egy új állapotba. Fontos megjegyezni, hogy az állapot semmilyen módon nincs belekódolva a blokkba; pusztán absztrakció, amelyre a hálózat érvényesítő résztvevőjének emlékeznie kell, és bármely blokkra (biztonságosan) csak akkor számítható ki, ha a kezdeti állapotból indulunk ki, és minden tranzakciót egymás után lefuttatunk minden blokkban. Továbbá meg kell jegyezni, hogy az is számít, hogy a bányász a tranzakciókat milyen sorrendben helyezte el a blokkban; ha van két olyan A és B tranzakció a blokkban, ahol B az A által létrehozott UTXO-t költi el, a blokk akkor lesz érvényes, ha A előbb van mint B, fordítva nem.

A fenti listában szereplő érvényességi feltételek közül egyedül a "munkabizonyíték" szükségessége nem található meg más rendszereknél. A pontos feltétel pedig az, hogy minden blokk dupla-SHA256 hashének, melyet egy 256 bites számként kezelünk, kisebbnek kell lennie, mint egy dinamikusan beállított célérték, mely ennek az anyagnak a megírása közben 2¹⁸⁷. Ennek a célja, hogy a blokk létrehozása számítási szempontból "nehéz" legyen, és hogy ezáltal megakadályozza a sybil-támadókat, hogy átalakítsák a teljes blokkláncot a saját érdekükben. Mivel az SHA256-ot úgy tervezték, hogy egy teljesen megjósolhatatlan álvéletlen (pszeudo-random) függvény legyen, így a blokk létrehozásának egyetlen módja a próbaszerencse (trial and error), vagyis ismételten növelni kell a nonce-t és figyelni, hogy az új hash megfelelő-e.

A jelenlegi 2¹⁸⁷-es cél esetében, a hálózatnak átlagosan ~2⁶⁹ próbálkozást kell tennie, mielőtt valaki egy érvényes blokkot találna; általánosságban a hálózat minden 2016 blokk után újrakalibrálja a célt azért, hogy a hálózat egy résztvevője átlagosan minden tizedik percben egy új blokkot hozzon létre. Azért, hogy a bányászok kompenzálva legyenek ezért a számítási munkáért, minden blokk bányászát megilleti, hogy egy olyan tranzakciót tegyen a blokkba, amiben jóváír magának 12.5 BTC-t a semmiből. Továbbá ha bármely tranzakciónak nagyobb bemeneti egysége van, mint kimeneti, akkor a különbség a bányászokhoz került, mint egy "tranzakciós díj". Tulajdonképpen ez a BTC kibocsátásának egyetlen módja; a kezdeti állapot egyáltalán nem tartalmazott érméket.

Hogy jobban megértsük a bányászat célját, nézzük meg, hogy mi történik egy rosszindulatú támadás esetében. Mivel a Bitcoin mögötti kriptográfia közismerten biztonságos, a támadó a rendszer azon részét fogja célba venni, melyet nem véd közvetlenül kriptográfia: a tranzakciók sorrendjét. A támadó stratégiája egyszerű:

1. 100 BTC elküldése egy kereskedőnek valamilyen termékért cserébe (ideálisan egy digitális termék, gyors "kiszállítással")
2. Megvárni amíg megérkezik a termék
3. Egy másik tranzakció létrehozása, amiben ugyanazt a 100 BTC-t küldi el magának
4. Meggyőzni a hálózatot, hogy a saját magának intézett tranzakció volt előbb.

Amint az (1) lépés befejeződött, pár perc múlva valamelyik bányász beteszi a tranzakciót egy blokkba, mondjuk a 270-es számúba. Nagyjából egy órával később, ezután a blokk után öt új blokk kerül hozzáadásra a lánchoz, és minden egyes blokk közvetetten hivatkozik a tranzakcióra, így "megerősítve" azt. Ezen a ponton a kereskedő elfogadja a kifizetést véglegesítettként és kiszállítja a terméket; mivel feltételezzük, hogy ez egy digitális termék, a szállítás azonnali. Ekkor a támadó egy új tranzakciót hoz létre, amiben 100 BTC-t küld magának. Ha a támadó egyszerűen elküldené a tranzakciót a világba, nem kerülne feldolgozásra; mert a bányászok megpróbálják a futtatni az APPLY(S,TX) függvényt és észreveszik, hogy a TX egy olyan UTXO-t akar felhasználni, ami már nem létezik az "állapot" szerint. Ehelyett a támadó csinál egy blokklánc "elágazást" (fork) úgy, hogy a 270-es blokknak egy új verzióját kezdi el bányászni, ami ugyanarra a 269-es "szülő" blokkra épül, de a régi helyett egy új tranzakcióval. Mivel a blokk adata különböző, így újra kell csinálni a "prrof-of-work"-öt. Továbbá a támadó 270-es számú új blokk verziója egy különböző hash-sel rendelkezik, így az eredeti blokkok 271-től 275-ig nem "hivatkoznak" rá; így az eredeti lánc és a támadó új lánca teljesen különböző. Az a szabály, hogy az elágazásban a hosszabb blokkláncot kell igaznak tekinteni, így a törvényesen bányászók a 275-ös láncon fognak tovább dolgozni, míg a támadó egyedül dolgozik a 270-es láncon. Ahhoz, hogy a támadó saját blokkláncát tehesse a leghosszabbá, több számítási kapacitással kell rendelkeznie, mint a hálózat többi résztvevőjének együttvéve, hogy utolérhesse őket (innen ered az "51%-os támadás").

Merkle fák

Bal: elegendő a csomópontok egy kis számát prezentálni a Merkle fában, hogy bizonyítsuk egy ág érvényességét.

Jobb: bármely kísérlet, mely a Merkle fa egy részének megváltoztatására irányul, végül következetlenséghez fog vezetni valahol a láncon.

A Bitcoin egyik fontos skálázhatósági tulajdonsága, hogy a blokk egy több szintes adatstruktúrában van tárolva. A blokk hash valójában csak a blokk fejléc hashe, ez megközelítőleg 200 bájt adatot jelent, mely tartalmazza az időbélyeget, a nonce-t, az előző blokk hashét és a Merkle fának nevezett adat struktúra gyökér hashét, mely a blokkban lévő összes tranzakciót tárolja. A Merkle fa egyfajta bináris fa, ami csomópontokból áll; jelentős számú levél csomópontból a fa alján, amik az alapul szolgáló adatokat tartalmazzák, egy sor középső csomópontból, ahol minden csomópont két gyerekének a hashe, és végül egy gyökér csomópontból, amely szintén két gyerekének a hashéből keletkezett, és a fa "tetejét" reprezentálja. A Merkle fa célja, hogy lehetővé tegye a blokkban lévő adatok feldarabolását: egy csomópont letöltheti csak a blokk fejlécet egy forrásból; a fának számára releváns kis részét pedig egy másik forrásból, és mégis biztos lehet az adat helyességében. Az ok amiért ez működik az a hashek felfelé terjedése: ha egy rosszindulatú felhasználó megpróbál betenni egy hamis tranzakciót a Merkle fa aljára, az változást indít el az eggyel feljebb lévő csomópontban, mely megváltoztatja az afelett lévő csomópontot, végül a gyökér csomópont is megváltozik, így ezzel a blokk hash is, ebből kifolyólag a protokoll egy teljesen másik blokként regisztrálja azt (szinte biztosan érvénytelen munkabizonyítékkal).

A Merkle fa protokoll vitathatatlanul elengedhetetlen a hosszú távú fenntarthatósághoz. Egy "teljes csomópontnak" a Bitcoin hálózatban, az amelyik az összes blokk egészét tárolja és feldolgozza, körülbelül 15 Gb lemezterülettel kell rendelkeznie a Bitcoin hálózatban 2014 áprilisában, és ez havonta 1 Gb-tal nő. Jelenleg ezt csak bizonyos asztali számítógépek tudják megvalósítani, telefonok nem, és a jövőben csak vállalkozások és hobbisták lesznek képesek részt venni. Egy "egyszerűsített fizetési hitelesítésnek (SPV)" nevezett protokoll lehetővé teszi egy másik csomópont típus létezését, melyeket "könnyű csomópontoknak" hívunk, ezek a hálózati résztvevők csak a blokk fejléceket töltik le, hitelesítik a munkabizonyítékot a blokk fejléceken és csak a számukra releváns tranzakciókhoz tartozó "ágakat" töltik le. Ez lehetővé teszi a könnyű csomópontoknak, hogy erős biztonsági garanciával meghatározhassák bármelyik Bitcoin tranzakció állapotát és aktuális egyenlegét, miközben a teljes blokklánc csak nagyon kis részét töltik le.

Alternatív blokklánc alkalmazások

A mögöttes blokklánc másfajta koncepciókra történő alkalmazásának ötlete szintén hosszú történelemmel bír. 1998-ban Nick Szabo kiadta a tulajdonosi jogokkal rendelkező biztonságos tulajdonok(opens in a new tab)↗ koncepciójával foglalkozó kiadványt. Ez a dokumentum leírja, hogy az "újdonságok a replikált adatbázis-technológiában" miként tesznek lehetővé egy blokklánc-alapú rendszert, mely nyilvántartja, hogy ki milyen földterülettel rendelkezik, létrehozva ezzel egy kidolgozott keretrendszert, amely magában foglalja az olyan fogalmakat, mint a homesteading, a hátrányos birtoklás és a George féle föld adó. Abban az időben sajnos nem állt rendelkezésre hatékony replikált adatbázis-rendszer, ezért a protokollt a gyakorlatban soha nem valósították meg. 2009-től azonban a Bitcoin decentralizált konszenzusának kialakulása után számos alternatív alkalmazás kezdett gyorsan megjelenni.

• Namecoin - a 2010-ben létrehozott Namecoint(opens in a new tab)↗ legjobban egy decentralizált név regisztrációs adatbázisként lehet leírni. Az olyan decentralizált protokollokban, mint a Tor, a Bitcoin és a BitMessage azért, hogy más emberek kölcsönhatásba léphessenek velük a fiókok azonosítására van szükség valamilyen módon, de az összes létező megoldásban az egyetlen elérhető azonosítótípus egy pszeudorandom hash, például 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Ideális esetben olyan számlanevet szeretnénk használni, mint a "george". A probléma azonban az, hogy ha egy személy létrehozhat egy "george" nevű fiókot, akkor valaki más is végig mehet ugyanezen a folyamaton a "george" regisztrálásához, és annak adhatja ki magát. Az egyetlen megoldás a first-to-file paradigma, ahol az első regisztrálónak sikerül, a másodiknak pedig meghiúsul - ez a probléma tökéletesen megfelel a Bitcoin konszenzusprotokoll számára. A Namecoin a legrégebbi és a legsikeresebb név regisztrációs rendszer implementáció, mely ezen ötleten alapszik.
• Colored coins - a colored coinok(opens in a new tab)↗ célja egy olyan protokoll megtestesítése, mely lehetővé teszi az emberek számára, hogy saját digitális valutát készítsenek - vagy az egy egységgel rendelkező valuták triviális és fontos esetében, digitális tokeneket a Bitcoin blokkláncon. A colored coins protokollban egy új pénznemet "bocsát ki" valaki azáltal, hogy nyilvánosan hozzárendel egy színt egy adott Bitcoin UTXO-hoz, és a protokoll rekurzív módon meghatározza a többi UTXO színét annak az inputnak a színével, amelyet az őket létrehozó tranzakció költött (néhány speciális szabály vonatkozik a vegyes színű bemenetekre). Ez lehetővé teszi a felhasználók számára, hogy csak bizonyos színű UTXO-t tartalmazó pénztárcákat tartsanak fenn, és a szokásos bitcoinokhoz hasonlóan küldjék el őket, visszakeresve a blokkláncon, hogy meghatározzák a kapott UTXO-k színét.
• Metacoins - a metacoin mögött az az ötlet áll, hogy legyen egy olyan protokoll, amely a Bitcoinra épült, és a Bitcoin tranzakciókat használja metacoin tranzakciók tárolására, de más állapotátmeneti függvénnyel rendelkezik, ami az APPLY'. Mivel a metacoin protokoll nem tudja megakadályozni, hogy érvénytelen metacoin tranzakciók jelenjenek meg a Bitcoin blokkláncon, bekerült az a szabály, hogy ha az APPLY'(S,TX) hibaüzenetet ad vissza, a protokoll az APPLY'(S,TX) = S alapértelmezett értékre áll be. Ez egy egyszerű mechanizmust biztosít egy tetszőleges kriptovaluta protokoll létrehozására, potenciálisan fejlett funkciókkal, amelyek nem valósíthatók meg a Bitcoin belsejében, de a fejlesztési költségek alacsonyak, mivel a bányászat és a hálózatépítés bonyolultságait már a Bitcoin protokoll kezeli. A metacoinokat használták már néhány pénzügyi szerződés fajtánál, név regisztrációnál és decentralizált tőzsdék esetében.

Így általánosságban két megközelítés van egy konszenzus protokoll fejlesztésére: egy független hálózat építése és egy protokoll fejlesztése a Bitcoinra. Az előbbi megközelítést, ami bár meglehetősen sikeres a Namecoinhoz hasonló alkalmazások esetében, nehéz implementálni; minden egyedi implementációnak bootstrapelni kell egy független blokkláncot, illetve kifejleszteni és letesztelni a szükséges állapot átmenetet és a hálózati kódot. Továbbá arra számítunk, hogy a decentralizált konszenzus technológiát használó alkalmazások a hatványtörvény szerinti eloszlást fogják követni, ahol az alkalmazások túlnyomó többsége túl kicsi lesz ahhoz, hogy indokolt legyen egy saját blokkláncot fenntartaniuk, és megjegyezzük, hogy a decentralizált alkalmazásoknak nagy osztályai léteznek, különösen a decentralizált autonóm szervezetek, melyeknek interakcióba kell lépniük egymással.

Másfelől a Bitcoin alapú megközelítésnek az a hátulütője, hogy nem örökli a a Bitcoin egyszerűsített fizetési hitelesítési tulajdonságait. Az SPV működik a Bitcoin esetében, mivel felhasználja a blokklánc mélységet, mint érvényességi proxy; egy ponton, amint a tranzakció ősei eleget mennek vissza, biztonsággal állítható, hogy érvényes részei az állapotnak. Másfelől a blokklánc alapú meta protokollok nem kényszeríthetik a blokkláncot, hogy ne tartalmazza azokat a tranzakciókat, melyek nem érvényesek a saját protokolljuk kontextusában. Ezért egy teljesen biztonságos SPV meta-protokoll megvalósításnak vissza kell hivatkoznia a Bitcoin blokklánc elejéig annak megállapítására, hogy biztos-e a tranzakciók érvényessége. Jelenleg a Bitcoin alapú meta-protokollok összes "könnyű" implementációja egy megbízott szerverre támaszkodik az adatszolgáltatásra, mely vitathatóan egy meglehetősen szuboptimális eredmény különösen akkor, amikor a kriptovaluták elsődleges célja a bizalom szükségletének megszüntetése.

Szkriptelés

Még valamilyen kiterjesztés nélkül is a Bitcoin protokoll valóban meg tudja könnyíteni az "okosszerződések" egy gyenge változatának koncepcióját. A Bitcoinban lévő UTXO-kat nem csak publikus kulcsok birtokolhatják, hanem bonyolultabb szkriptek is, melyeket egy egyszerű stack alapú programozási nyelvvel lehet kifejezni. Ebben a paradigmában az UTXO-t elköltő tranzakcióknak adatokat kell szolgáltatni a szkriptek kielégítésére. Valójában még az alapvető publikus kulcs tulajdonjog mechanizmus is egy szkripten keresztül valósul meg: a szkript egy elliptikus görbe aláírást használ bemenetként, megerősíti a tranzakció és az UTXO-t birtokló cím szerint és 1-et ad vissza, ha az érvényesítés sikeres ellenkező esetben 0-át. Más bonyolultabb szkriptek is léteznek további különböző felhasználási esetekre. Például létre lehet hozni egy olyan szkriptet, mely három privát kulcsból kettő aláírását igényli az érvényesítéshez ("multisig"), a vállalati számlák, biztonságos megtakarítási számlák és néhány kereskedői letét számára hasznos beállítás. A szkriptek felhasználhatók a számítási problémák megoldásáért járó jutalmak kifizetésére is, sőt össze lehet állítani egy olyan szkriptet, amely valami olyasmit mond, hogy "ez a Bitcoin UTXO a tiéd, ha tudsz egy SPV bizonyítékot nyújtani arra, hogy nekem küldtél egy ilyen címletű Dogecoin tranzakciót", mely lényegében lehetővé teszi a decentralizált kereszt-kriptovaluta váltást.

Azonban a Bitcoinban implementált szkript nyelvnek számos fontos megkötése van:

• Turing-teljesség hiánya - vagyis, bár van egy nagy számítási részhalmaz, amelyet a Bitcoin szkriptnyelv támogat, közel sem támogat mindent. A fő kategória a hiányzó ciklusok. Ennek az az oka, hogy elkerüljük a végtelen ciklusokat a tranzakció ellenőrzések során; elméletileg ez egy leküzdhetetlen akadály a szkript programozók számára, mivel bármely ciklus szimulálható úgy, hogy egyszerűen megismételjük több alkalommal a mögöttes kódot egy if utasítással, de ez nagyon kis hatékonyságú szkriptekhez vezet. Például egy alternatív elliptikus görbe aláírás algoritmus implementálása valószínűleg 256 ismételt szorzási kört igényelne, mely mindegyike egyenként szerepelne a kódban.
• Értékvakság - nincs olyan UTXO szkript, mely képes lenne szofisztikáltan irányítani a kiutalható mennyiséget. Például egy orákulum szerződés hatékony felhasználási esete egy hedging szerződés lehetne, ahova A és B $1000 értékű BTC-t tesz be és 30 nappal később a szkript elküld $1000 értékű BTC-t A részére a maradékot pedig B részére. Ez egy orákulumot igényelne, mely meghatározná 1 BTC értékét USD-ben, de még így is hatalmas előrelépés a bizalom és infrastrukturális követelmények szempontjából a teljesen központosított megoldásokhoz képest, melyek elérhetőek jelenleg. Azonban mivel az UTXO mindent vagy semmit elven működik, ennek az egyedüli módja, ha sok UTXO-t használunk különböző egységekkel (pl.: egy 2^k UTXO minden k-ra egészen 30-ig) és az O eldönti, hogy melyik UTXO-t küldi A-nak és melyiket B-nek.
• Az állapot hiánya - a Egy UTXO lehet elköltött vagy elköltetlen(opens in a new tab)↗; nincs lehetőség többlépcsős szerződésekre vagy szkriptekre, amelyek minden más belső állapotot ezen túl tartana. Ez megnehezíti a többlépcsős opciós szerződések, decentralizált csereajánlatok vagy kétlépcsős kriptográfiai elköteleződési protokollok létrehozását (ami szükséges a biztonságos számítási kompenzációhoz). Ez azt is jelenti, hogy az UTXO csak egyszerű, egyszeri szerződések és nem bonyolultabb "állapottal rendelkező" szerződések, például decentralizált szervezetek létrehozására használható, és a metaprotokollok megvalósítását megnehezíti. A bináris állapot az értékvaksággal kombinálva azt is jelenti, hogy egy másik fontos alkalmazás, a kiutalási limitek beállítása, sem lehetséges.
• Blockchain-vakság - Az UTXO nem tud az olyan blokklánc adatokról, mint a nonce, az időbélyeg vagy az előző blokk hash. Ez súlyosan korlátozza a szerencsejátékokban és számos más kategóriában történő alkalmazásokat azáltal, hogy megfosztja a szkript nyelvet a véletlenszerűség potenciálisan értékes forrásától.

Így meglátásunk szerint háromféleképpen lehet fejlett alkalmazásokat fejleszteni egy kriptovalutára: új blokklánc indítása, a Bitcoin szkripting használata és egy meta protokoll fejlesztése Bitcoinra. Egy új blokklánc indítása lehetővé teszi a korlátlan szabadságot a funkciókészlet építésében, de a fejlesztési idő, a bootstrapping és a biztonság árán. A szkriptek használata egyszerűen megvalósítható és szabványosítható, de nagyon korlátozott a képességeiben, és a meta protokollok, míg egyszerűek, nehezen skálázhatóak. Az Ethereummal egy olyan alternatív keretrendszert szeretnénk létrehozni, mely még jobban megkönnyíti a fejlesztést, valamint erősebb könnyű kliens tulajdonságokkal rendelkezik, egyúttal az alkalmazásoknak egy közös gazdasági környezetet és blokklánc biztonságot biztosít.

Ethereum

Az Ethereum célja egy alternatív protokoll létrehozása decentralizált alkalmazások fejlesztésére, különböző kompromisszumokkal, amelyről úgy hisszük, hogy nagyon hasznos lesz a decentralizált alkalmazások nagy részének, különös tekintettel az olyan esetekre, ahol fontos a gyors fejlesztési idő, a biztonság a kisméretű és ritkán használt alkalmazások számára, és a különböző alkalmazások közötti nagyon hatékony együttműködés. Az Ethereum ezt úgy éri el, hogy felépíti azt, ami lényegében a végső absztrakt alapréteg: egy blokkláncot beépített Turing-teljes programozási nyelvvel, mely lehetővé teszi bárki számára az okosszerződés írást és a decentralizált alkalmazás fejlesztést, ahol létrehozhatják a saját tetszőleges tulajdonjogi szabályaikat, tranzakció formátumukat és az állapot átmeneti függvényeket. A Namecoin lecsupaszított verziója két sornyi kódból megírható, a többi protokoll, mint például a valuták és az identitás rendszerek pedig kevesebb, mint húsz sorból. Okosszerződések, olyan kriptográfiai "dobozok", melyek értéket tartalmaznak és csak akkor nyílnak ki amikor bizonyos feltételek teljesülnek, szintén építhetőek a platformra sokkal nagyobb erővel, mint amit a Bitcoin szkriptelés kínál, a Turing-teljesség, érték-tudatosság, blokklánc-tudatosság és az "állapot" hozzáadott ereje miatt.

Filozófia

Az Ethereum mögötti elgondolás az alábbi elveket szándékozik követni:

1. Egyszerűség: az Ethereum protokollnak a lehető legegyszerűbbnek kell lennie, még az adattárolás vagy az időhatékonyság rovására is.^{fn. 3} Egy átlagos programozó ideális esetben képes a teljes részletes leírást követni és implementálni,^{fn. 4} annak érdekében, hogy teljes mértékben kiaknázhassuk a kriptovaluta példátlan demokratizálási potenciálját, és tovább terjesszük az Ethereum mint mindenki számára nyitott protokoll elképzelését. Az olyan optimalizálásokat, melyek a komplexitás növelésével járnak, nem szabad használni, kivéve ha az optimalizálás jelentős előnnyel jár.
2. Univerzalitás: az Ethereum design filozófia egyik alapvetése, hogy az Ethereumnak nincsenek "jellemző vonásai".^{fn. 5} Ehelyett az Ethereum egy olyan Turing-teljes szkript nyelvet szolgáltat, mellyel a programozó bármilyen okosszerződést vagy tranzakció típust felépíthet, melyek matematikailag definiálhatóak. Szeretnéd feltalálni a saját pénzügyi származékos termékedet? Az Ethereummal megteheted. Szeretnéd létrehozni a saját valutádat? Hozd létre egy Ethereum szerződéssel. Szeretnél egy teljeskörű Daemont vagy Skynetet felállítani? Lehet, hogy szükséged lesz pár ezer összekapcsolódó szerződésre és számíts rá, hogy bőkezűen kell majd őket táplálnod, de semmi nem állíthat meg a karnyújtásnyira lévő Ethereummal.
3. Modularitás: az Ethereum protokoll részeit annyira modulárissá és szétválaszthatóvá kell tervezni, amennyire csak lehetséges. A fejlesztés során az a célunk, hogy egy olyan programot hozzunk létre, amiben ha valahol egy kisebb protokoll módosítást viszünk végbe, az alkalmazási verem (stack) továbbra is működni fog további módosítás nélkül. Az olyan innovációkat, mint az Ethash (lásd Sárga Könyv Függelék(opens in a new tab)↗ vagy wiki szócikk(opens in a new tab)↗), a módosított Patricia fák (Sárga Könyv(opens in a new tab)↗, wiki(opens in a new tab)↗) és az RLP (YP(opens in a new tab)↗, wiki(opens in a new tab)↗) különálló, funkció-teljes könyvtárként kell alkalmazni, és így is vannak alkalmazva. Ennek az az oka, hogy annak ellenére, hogy az Ethereumban használjuk őket, még ha az Ethereum nem is igényli bizonyos funkcióit, ezek a funkciók más protokollok számára is hasznosak lehetnek. Az Ethereum fejlesztést úgy kell maximálisan elvégezni, hogy a teljes kriptovaluta ökoszisztéma javát szolgálja, ne csak a sajátját.
4. Agilitás: az Ethereum protokoll részletei nincsenek kőbe vésve. Azonban rendkívül megfontoltak leszünk a magas szintű konstrukciók megváltoztatását illetően, mint például a sharding ütemterv(opens in a new tab)↗ esetében a végrehajtás absztrahálása csak az adatok konszenzusos elérhetőségével fog történni. A fejlesztési folyamat során történő későbbi számítási tesztek arra a felfedezésre vezethetnek, hogy bizonyos módosítások például a protokoll felépítésében vagy az Ethereum Virtuális Gépben (EVM) jelentős mértékben növelhetik a skálázhatóságot vagy a biztonságot. Ha találunk ilyen lehetőségeket, akkor ki fogjuk használni őket.
5. Megkülönböztetés-mentesség és cenzúra-mentesség: a protokoll nem kísérelheti meg bizonyos használati kategóriák aktív betiltását vagy megelőzését. A protokoll összes szabályozási mechanizmusát arra kell tervezni, hogy közvetlenül a károkozást szabályozza nem pedig a bizonyos nemkívánatos alkalmazásokat. Egy programozó akár egy végtelen ciklusos szkriptet is futtathat az Ethereumon, amíg hajlandó fizetni a számítási lépések tranzakciós díját.

Ethereum számlák

Az Ethereumban az állapotot "számláknak" nevezett objektumok alkotják, ahol minden egyes számla egy 20-bájtos címmel rendelkezik és az állapot átmenetet a számlák közötti közvetlen érték és információ átutalás végzi. Az Ethereum számlák négy mezőt tartalmaznak:

• A nonce, egy számláló, mely biztosítja, hogy minden tranzakció csak egyszer kerül feldolgozásra
• A számla jelenlegi ether egyenlege
• A számla szerződés kódja, ha van
• A számla tárhelye (alapértelmezetten üres)

Az "Ether" az Ethereum elsődleges belső kripto-üzemanyaga és a tranzakciós díj kifizetésére lehet használni. Általánosságban kétfajta számlatípus létezik: külső tulajdonú számlák, melyeket privát kulcsok irányítanak és szerződéses számlák, melyeket a szerződés kódjuk irányít. Az külső tulajdonú számlának nincsen kódja, és az adott személy üzenetet küldhet egy külső tulajdonú számláról egy tranzakció létrehozásával és aláírásával; a szerződéses számla esetében minden esetben, amikor a szerződéses számla egy üzenetet kap aktiválódik a kódja, ennek hatására lehetővé teszi a belső tárhely írását és olvasását, új üzenetek küldését vagy szerződés létrehozást.

Fontos megjegyezni, hogy az Ethereumban a "szerződésekre" nem úgy kell tekinteni, mint amit „teljesíteni” vagy „betartani” kell; inkább "autonóm ügynökök", akik az Ethereum végrehajtási környezetében élnek, és mindig végrehajtanak egy adott kóddarabot, amikor "megböki" őket egy a üzenet vagy tranzakció, és közvetlen ellenőrzésük alatt tartják saját Ether egyenlegüket és saját kulcsérték-adatbázisukat, a tartós változók nyomon követésére.

Üzenetek és tranzakciók

A "tranzakció" kifejezést az Ethereumban egy aláírt adat csomagra használjuk, ami egy külső tulajdonú számláról érkező üzenetet tartalmaz. A tranzakció a következőket tartalmazza:

• Az üzenet címzettje
• A küldőt azonosító aláírás
• Az Ether összeg, amit a küldő át akar utalni a címzettnek
• Egy opcionális adat mező
• A STARTGAS érték, ami a tranzakció végrehajtás számítási lépéseinek maximális számát jelenti
• A GASPRICE érték, ami a számítási lépésenkénti díjat jelenti, amit a feladó fizet

Az első három olyan alap mező, ami minden kripto valutánál megtalálható. Az adatmezőnek alapértelmezés szerint nincs funkciója, de a virtuális gép rendelkezik egy opkóddal, amelyet a szerződés használhat az adatok elérésére; mint például, amikor egy szerződés domain regisztrációs szolgáltatásként működik a blokkláncon, akkor úgy értelmezheti a hozzá érkező adatot, hogy az két "mezőt" tartalmaz, az első mező a regisztrálandó domain, a második mező pedig az IP-cím, amelyre regisztrálni kell. A szerződés elolvassa ezeket az adatokat az üzenetből, és a megfelelő helyükre helyezi el őket az adattárban.

The STARTGAS és GASPRICE mezők kritikusak az Ethereum szolgáltatás megtagadása elleni modelljében. A véletlen vagy rosszindulatú végtelen ciklusok vagy más számítási kódveszteség megelőzésének érdekében minden tranzakciónak korlátot kell szabnia arra vonatkozóan, hogy a kódfuttatás hány számítási lépést használhat. A számítás alapvető egysége a "gas"; általában egy számítási lépés 1 gas-ba kerül, de egyes műveletek magasabb gas mennyiségbe kerülnek, mert számítási szempontból drágábbak, vagy növelik az állapot részeként tárolandó adatok mennyiségét. Továbbá minden egyes tranzakciós adatban található byte után 5 gas díj is felszámításra kerül. A díjrendszer célja, hogy megkövetelje a támadótól, hogy minden általa felhasznált erőforrásért arányosan fizessen, beleértve a számítást, a sávszélességet és a tárhelyet is; ennélfogva minden olyan tranzakció esetében, amelynek eredményeként a hálózat ezeknek az erőforrásoknak bármelyikét nagyobb mennyiségben fogyasztja, az erőforrások növekedésével nagyjából arányos gas költséggel kell számolni.

Üzenetek

A szerződéseknek meg van a lehetőségük, hogy "üzeneteket" küldjenek más szerződéseknek. Az üzenetek olyan virtuális objektumok, amik soha nincsenek szerializálva és csak az Ethereum futtatási környezetben léteznek. Az üzenet a következőket tartalmazza:

• Az üzenet küldője (magától értetődő)
• Az üzenet címzettje
• Az üzenettel küldendő Ether összege
• Egy opcionális adat mező
• A STARTGAS érték

Lényegében az üzenet olyan mint a tranzakció, kivéve, hogy nem a külső szereplő által lett létre hozva, hanem a szerződés által. Üzenet akkor jön létre, amikor a kódot jelenleg végrehajtó szerződés végrehajtja a CALL opkódot, amely előállítja és vére hajtja az üzenetet. Úgy mint a tranzakció, az üzenet is a kódja futtatására vezeti a címzett számlát. Ezáltal a szerződéseknek is ugyanúgy lehet kapcsolatuk másik szerződésekkel, mint a külső szereplőknek.

Megjegyzendő, hogy a tranzakciók vagy szerződések által kiszabott gas díj vonatkozik a teljes gas összegre, amit az a tranzakció és az összes alvégrehajtási folyamat felhasznált. Például, ha egy külső szereplő A küld egy tranzakciót B-nek 1000 gas-al, és B 600 gas-t fogyaszt, mielőtt üzenetet küldene C-nek, és C belső végrehajtása 300 gas-t fogyaszt, mielőtt visszatérne, akkor B további 100 gas-t költhet, mielőtt kifogyna a gas-ból.

Ethereum állapotátmenet függvény

Az Ethereum állapotátmenet függvény, APPLY(S,TX) -> S' a következőképpen írható le:

1. Ellenőrizni, hogy a tranzakció jól formált-e (azaz megfelelő-e az értékek száma), az aláírás érvényes-e, és a nonce megegyezik-e a feladó számláján szereplő nonce-al. Ha nem, hiba vissza adása.
2. Kiszámítani a tranzakciós díjat a következőképpen STARTGAS * GASPRICE, és meghatározni a küldő címet az aláírásból. Levonni a díjat a küldő fél számla egyenlegéről és növelni a küldő fél nonce-át. Ha nincs elegendő egyenleg, hiba vissza adása.
3. Beállítani a GAS = STARTGAS kezdőértéket és bizonyos mennyiségű, bájtonkénti gas-t elvenni a tranzakció bájtjainak kifizetéséhez.
4. Átutalni a tranzakció értékét a küldő számlájáról a fogadó számlájára. Ha a fogadó számla még nem létezik, létrehozni azt. Ha a fogadó számla egy szerződés, futtatni a szerződés kódját, addig amíg a tranzakció teljesül, vagy ameddig a végrehajtás során elfogy a gas.
5. Ha az érték átutalás azért nem sikerült, mert a feladónak nem volt elegendő pénze, vagy a kódfuttatás során elfogyott a gas, akkor minden állapotváltozást visszavonni, kivéve a díjak kifizetését, és a díjakat a bányász számlájához hozzáadni.
6. Máskülönben az összes fennmaradó gas díjat visszatéríteni a feladónak, az elfogyasztott gas-ért fizetett díjakat pedig elküldeni a bányásznak.

Például tegyük fel, hogy a szerződés kódja:

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

Megjegyzendő, hogy a valóságban a szerződés alacsony szintű EVM programozási nyelven van írva; ez a példa az érthetőség kedvéért az egyik magas szintű programozási nyelven, a Serpent-en íródott, és le lehet fordítani EVM kódra. Tegyük fel, hogy a szerződés tárhelye az elején üres, és egy 10 Ether értékű tranzakciót elküldenek 2000 gas-al, 0,001 Ether gas árral, és 64 bájtnyi adattal, ahol 0-31 bájtok a 2 számot ábrázolják, és 32-63 bájtok pedig a karakterláncot ábrázolják CHARLIE.^{fn. 6} Az állapot átmeneti függvény folyamata ebben az esetben a következőképpen alakul:

1. Ellenőrizni, hogy a tranzakció érvényes és jól formált.
2. Ellenőrizni, hogy a tranzakció küldőjének van legalább 2000 * 0,001 = 2 Ethere. Ha igen, levonni 2 Ethert a küldő számlájáról.
3. A gas = 2000 kezdőérték beállítása; feltételezve, hogy a tranzakció 170 bájt hosszú és a bájtdíj 5, levonni 850-et úgy, hogy 1150 gas maradjon.
4. További 10 Ether levonása a küldő számlájáról, és annak hozzáadása a szerződés számlájához.
5. A kód futtatása. Ebben az esetben ez egyszerű: a kód ellenőrzi, hogy a szerződés tárhelye a 2 indexen van használva, ha észreveszi, hogy nem, akkor a tárhely indexet beállítja 2 az értéket pedig CHARLIE. Tegyük fel, hogy ez 187 gas-ba kerül, így a fennmaradó gas összeg 1150 - 187 = 963
6. 963 \ * 0,001 = 0,963 Ether visszaadása a feladó fiókjába, és visszatérés az eredményül kapott állapothoz.

Ha a tranzakció fogadó oldalán nem lenne szerződés, akkor a teljes tranzakciós díj egyszerűen megegyezne a megadott GASPRICE szorozva a tranzakció hosszával bájtokban, és a tranzakcióval együtt elküldött adatok lényegtelenek lennének.

Megjegyzendő, hogy az üzenetek és a tranzakciók visszafordítása ugyanúgy működik: ha az üzenet végrehajtása során elfogy a gas, akkor az üzenet végrehajtása és az összes többi végrehajtás, amelyet az a végrehajtás váltott ki, visszaáll, de a szülő végrehajtásokat nem kell visszaállítani. Ez azt jelenti, hogy egy szerződés "biztonságosan" hívhat egy másik szerződést, mivel ha A G-gas-al hívja B-t, akkor A végrehajtása garantáltan legfeljebb G-gas veszteséget okoz. Végül megjegyzendő, hogy van egy műveleti kód (opcode) CREATE, ami létrehozza a szerződést; aminek a végrehajtási mechanikája általában hasonló a CALL-hoz, azaz híváshoz, azzal a kivétellel, hogy a végrehajtás kimenete határozza meg az újonnan létrehozott szerződés kódját.

Kód futtatás

Az Ethereum szerződésekben szereplő kód alacsony szintű, verem-alapú bájtkód nyelven íródott, amelyet "Ethereum virtuális gép kódnak" vagy "EVM kódnak" neveznek. A kód bájtok sorozatából áll, ahol mindegyik bájt egy műveletet képvisel. A kódfuttatás általában egy végtelen ciklus, ami a művelet ismételt végrehajtásából áll az aktuális programszámlálón (amely nullától kezdődik), majd eggyel növeli a programszámlálót addig, amíg el nem éri a kód végét, vagy egy hibát, illetve STOP vagy RETURN utasítást észlel. A műveletek háromféle helyhez férnek hozzá, ahol adatokat tárolhatnak:

• A verem egy utolsóként be, elsőként ki (LIFO) tárolóhely, ahol az értékek rárakhatóak (push) és levehetőek (pop) a verem tetejéről
• Memória , egy végtelenül bővíthető bájt tömb
• A szerződés hosszú távú tárhelye , egy kulcs- és értéktároló. A veremtől és a memóriától eltérően, amelyek a számítás befejezése után nullázódnak, ez a tároló hosszú ideig fennmarad.

A kód hozzáférhet a bejövő üzenet értékéhez, feladójához és adataihoz, valamint a blokk fejlécének adataihoz, és a kód egy bájt adattömböt is visszaadhat kimenetként.

Az EVM kód formális végrehajtási modellje meglepően egyszerű. Amíg az Ethereum virtuális gép fut, teljes számítási állapota meghatározható a következő értéksorral: (blokk_állapot, tranzakció, üzenet, kód, memória, verem, programszámláló(pc), gas), ahol a blokk_állapot az összes számlafiókot tartalmazó globális állapot, amely magában foglalja az egyenlegeket és a tárolóhelyeket. Minden egyes végrehajtási kör elején, az aktuális utasítás megtalálható a kód-nak (vagy 0 ha pc >= len(code)) a programszámláló -n meghatározott bájtja által, és minden utasításnak megvan a maga meghatározása abból a szempontból, hogy milyen hatással van az értéksorra. Például, ADD elvesz két elemet a veremből és visszarakja az összegüket, csökkenti a gas -t 1-el, és növeli a programszámláló-t 1-el, és a SSTORE leveszi a verem két legfelső elemét és behelyezi a második elemet a szerződés tárhelyébe az első elem által meghatározott indexen. Bár számos módja van az Ethereum virtuális gép végrehajtás optimalizálásának, futásidejű fordítással vagy másnéven röpfordítással, az Ethereum alapvető megvalósítása néhány száz kódsorban elvégezhető.

Blokklánc és bányászat

Az Ethereum blokklánc sok szempontból hasonló a Bitcoin blokklánchoz, bár vannak közöttük különbségek. A fő különbség az Ethereum és a Bitcoin között a blokklánc felépítésének tekintetében az, hogy a Bitcointól eltérően (amely csak a tranzakciós lista másolatát tartalmazza) az Ethereum blokkok tartalmazzák a tranzakciós lista és a legutóbbi állapot másolatát is. Emellett két másik érték, a blokk száma és a nehézsége is tárolva van a blokkban. Az Ethereum blokk érvényesítési algoritmusa a következő:

1. Ellenőrizni, hogy az előző blokk, amire a blokk hivatkozik létezik és érvényes.
2. Ellenőrizni, hogy a blokk időbélyege nagyobb-e, mint az előző blokké és kevesebb mint 15 perc telt el azóta
3. Ellenőrizni, hogy a blokk száma, a nehézség, a tranzakció gyökér, a nagybácsi gyökér és a gas korlát (különféle alacsony szintű Ethereum-specifikus fogalmak) érvényesek-e.
4. Ellenőrizni, hogy a blokk proof-of-work-je érvényes-e.
5. Legyen S[0] az előző blokk után lévő állapot.
6. Legyen TX a blokk tranzakciós listája n tranzakcióval. Minden i-t a 0...n-1, -ban beállítani S[i+1] = APPLY(S[i],TX[i]). Ha valamelyik alkalmazás hibát ad vissza, vagy a blokkban az eddig a pontig fogyasztott gáz összmennyisége túllépi a GASLIMIT értéket, hibát ad vissza.
7. Legyen az S_FINAL S[n], de hozzáadva a bányásznak fizetett blokkjutalmat.
8. Ellenőrizd, hogy az S_FINAL állapot Merkle-fája azonos-e a blokk fejlécben megadott végleges állapottal. Ha igen, a blokk érvényes; ellenkező esetben nem az.

A megközelítés első pillantásra nagyon hatékonytalannak tűnhet, mert minden blokkal a teljes állapotot kell tárolni, de a valóságban a hatékonyság a Bitcoinéhoz hasonló. Ennek az oka, hogy az állapot a fa struktúrájában tárolódik, és minden blokk után a fa csak egy kis részét kell megváltoztatni. Így általában két szomszédos blokk között a fa túlnyomó részének azonosnak kell lennie, ezért az adatokat egyszer kell tárolni és kétszer lehet rájuk hivatkozni mutatók (azaz részfák hash-jeinek) használatával. Ennek megvalósításához egy speciális "Patricia-fának" nevezett fát használnak, beleértve a Merkle-fa koncepciójának módosítását, amely lehetővé teszi a csomópontok hatékony beillesztését és törlését, nem csak megváltoztatását. Ezen túlmenően, mivel az összes állapotinformáció része az utolsó blokknak, nincs szükség a teljes blokklánc előzmények tárolására - egy stratégia, amely, ha alkalmazható lenne a Bitcoin-ra, 5-20-szoros megtakarítást eredményezne a térben.

Gyakran feltett kérdés, hogy "hol" történik a szerződés kódjának végrehajtása, a fizikai hardver szempontjából. Erre egyszerű a válasz: a szerződés kódjának végrehajtási folyamata az állapotátmeneti függvény definíciójának része, amely a blokk érvényesítési algoritmus része, tehát ha egy tranzakciót hozzáadunk a B blokkhoz, akkor a tranzakció által létrehozott kód végrehajtását minden csomópont végrehajtja, most és a jövőben is, amelyek letöltik és érvényesítik a B blokkot.

Alkalmazások

Az Ethereumon általánosságban háromféle alkalmazás létezik. Az első kategória a pénzügyi alkalmazások, amelyek hatékonyabb módszereket kínálnak a felhasználóknak a pénzük kezelésére és szerződéskötésre. Ebbe beletartoznak a devizák, a derivatív pénzügyi eszközök, a fedezeti ügyletek, a takarék pénztárcák, végrendeletek, és végül akár teljes körű munkaszerződések egyes kategóriái. A második kategória a félig pénzügyi alkalmazások, amik kapcsolatosak a pénzzel, de a tevékenységeiknek van egy súlyos, nem pénzügyi oldala is; erre tökéletes példa az önérvényesítő jutalmak, a számítási problémák megoldásért. Végül vannak olyan alkalmazások, mint az online szavazás és a decentralizált irányítás, amelyek egyáltalán nem pénzügyi vonatkozásúak.

Token rendszerek

A blokkláncon való token vagyis zseton rendszereknek számos alkalmazása van, kezdve az olyan alvalutáktól, amik olyan eszközöket képviselnek, mint az USA Dollár vagy az arany, egészen a vállalati részvények, az okos tulajdont képviselő egyedi zsetonok, a biztonságos, hamisíthatatlan kuponok, és még olyan zseton rendszerekig is, amik semmilyen kapcsolatban nem állnak a hagyományos értékhez, csak a jutalmazás pontrendszereiként használják őket. A zseton rendszereket meglepően egyszerű módon létre lehet hozni az Ethereumon. Kulcsfontosságú megérteni azt, hogy a pénznem vagy a zseton rendszer alapvetően egy egy műveletből álló adatbázis: vonjon le X egységet A-ból, és adjon X egységet B-nek, azzal a feltétellel, hogy (1) A-nak a tranzakció előtt legalább X egysége volt és (2) a tranzakciót A jóváhagyta. A zseton rendszer megvalósításához mindössze annyi kell, hogy ezt a logikát beépítsék egy szerződésbe.

Az alapkód a zsetonrendszer megvalósítására Serpent programnyelven a következőképpen néz ki:

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

Ez lényegében a "bankrendszer" állapotátmeneti függvényének szó szerinti megvalósítását jelenti, amely ebben a dokumentumban fentebb már le lett írva. Néhány extra kódsort hozzá kell adni, hogy biztosítsuk a pénzegységek elosztásának kezdeti lépését, néhány másik szélsőséges esetben is, és ideális esetben egy függvényt is hozzáadunk, ami lehetővé teszi másik szerződéseknek, hogy lekérdezzék egy cím számlaegyenlegét. De ennyi az egész. Elméletileg a pénznemként működő Ethereum-alapú zsetonrendszerek tartalmazhatnak egy másik fontos jellemzőt, ami a Bitcoin-alapú blokkláncon található pénzeszközöknél hiányzik: a tranzakciós díjak közvetlen fizetése ugyanabban a pénznemben. Ez úgy lehetne megvalósítható, hogy a szerződés fenntartana egy Ether egyenleget, amelyből visszatérítené a feladónak a díjakra használt Ethert, és ezt az egyenleget úgy töltené fel, hogy összegyűjti a díjakra beszedett belső valutaegységeket, és egy folyamatosan futó aukción továbbértékesíti azokat. A felhasználóknak tehát Etherrel kellene "aktiválniuk" a számláikat, de onnantól, hogy az Ether ott van, újrafelhasználható, mert a szerződés minden alkalommal visszatérítené.

Pénzügyi derivatívák és stabil értékű valuták

A pénzügyi derivatívák az "intelligens szerződés" leggyakoribb alkalmazásai, és az egyik legegyszerűbben megvalósítható kóddal. A pénzügyi szerződések végrehajtása során az a fő kihívás, hogy többségük külső árfolyamra való hivatkozást igényel; például nagyon kívánatos alkalmazás egy olyan okos szerződés, amely fedezetet ad az Ether (vagy más kriptovaluta) árfolyamingadozására az amerikai dollárral szemben, de ehhez a szerződésnek tudnia kell az ETH / USD értékét. Ennek legegyszerűbb módja egy adott fél (pl. NASDAQ) által fenntartott "adatcsatorna" szerződés, amelynek célja, hogy az adott fél képes legyen a szerződés szükség szerinti frissítésére, és egy olyan felület biztosítása, amely lehetővé teszi más szerződések számára, hogy üzenetet küldjenek a szerződésnek, és választ kapjanak, ami tratalmazza az árat.

Tekintettel erre a kritikus összetevőre, a fedezeti szerződés a következőképpen nézne ki:

1. Megvárni, amíg az A fél berak 1000 Ethert.
2. Megvárni, amíg a B fél berak 1000 Ethert.
3. Az adatcsatorna szerződés lekérdezésén keresztül kiszámított 1000 Ether USD értékének rögzítése a tárolóhelyen, mondjuk, hogy ez $x.
4. 30 nap elteltével hagyni, hogy A vagy B "újraaktiválja" a szerződést úgy, hogy $x értékű Ethert küld (amelyet úgy számol ki, hogy újból lekérdezi az adatcsatorna szerződést az új árról) A-nak, a többit pedig B-nek.

Egy ilyen szerződés jelentős potenciállal bírna a kriptokereskedelemben. Az egyik fő probléma, amire gyakran hivatkoznak a kriptovalutával kapcsolatban, hogy ingatag az árfolyama; bár sok felhasználó és kereskedő vágyik a kriptográfiai eszközök biztonságára és kényelmére, nem biztos, hogy szembe akar nézni azzal a lehetőséggel, hogy egyetlen nap alatt elveszítheti pénzeszközei értékének 23% -át. Eddig a leggyakrabban a kibocsátó által biztosított eszközöket javasolták; annak az elképzelésnek az alapján, hogy a kibocsátó létrehoz egy pénzeszközt, ahol joga van kibocsátani és visszavonni egységeket, és mindenkinek egy egységnyi pénzeszközt ad, aki (offline) cserébe ad neki egy meghatározott, egy egységnyi alapul szolgáló eszközt (pl. arany, USA Dollár). A kibocsátó ezután megígéri, hogy az alapul szolgáló eszköz egy egységét adja annak, aki visszaküldi a kripto eszköz egy egységét. Ez a mechanizmus lehetővé teszi minden nem kriptográfiai eszköz kriptográfiai eszközzé történő emelését, feltéve, hogy a kibocsátó megbízható.

A gyakorlatban azonban a kibocsátók nem mindig megbízhatóak, és egyes esetekben a banki infrastruktúra túl gyenge vagy túl ellenséges ahhoz, hogy ilyen szolgáltatások létezzenek. A pénzügyi derivatívák alternatívát kínálnak. Itt ahelyett, hogy egyetlen kibocsátó biztosítaná az eszközök fedezetére szolgáló alaptőkét, a spekulánsok decentralizált piacon való fogadásai arról, hogy egy kriptográfiai referencia eszköz (pl. ETH) ára emelkedni fog-e játsszák azt a szerepet. A kibocsátóktól eltérően a spekulánsoknak nincs lehetőségük az ügylettel kapcsolatos kötelezettségük elmulasztására, mert a fedezeti szerződés letétben tartja pénzeszközeiket. Fontos megjegyezni, hogy ez a megközelítés nincs teljesen decentralizálva, mert még mindig megbízható forrásra van szükség az árjegyző szerepének betöltésére, bár már ez is vitathatatlanul hatalmas előrelépés az infrastruktúra-követelmények csökkentése szempontjából (ellentétben a kibocsátóval, az árfolyam-kiadáshoz nem szükséges licenc és valószínűleg a szólásszabadság kategóriájába sorolhatók), és a csalás lehetőségét is csökkenti.

Identitás és Hírnév Rendszerek

A legkorábbi alternatív kriptovaluta, a, Namecoin(opens in a new tab)↗, egy Bitcoinhoz hasonló blokkláncot próbált meg használni egy névregisztrációs rendszer biztosításához, ahol a felhasználók a nevüket egy nyilvános adatbázisba regisztrálhatták több más adat mellett. A leggyakrabban idézett alkalmazási eset DNS(opens in a new tab)↗ rendszerre, a domain nevek, például "bitcoin.org" (vagy a Namecoin esetében "bitcoin.bit") leképezése egy IP címre. Egyéb alkalmazási esetek például az e-mail autentikációk és a potenciálisan haladóbb reputációs rendszerek. Nézzünk egy alap szerződést, amely Namecoin-féle név regisztrációt biztosít az Ethereumon:

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

A szerződés nagyon egyszerű; gyakorlatilag egy adatbázis az Ethereum hálózatban, amelyhez hozzá lehet adni, de nem lehet módosítani vagy törölni belőle. Bárki regisztrálhat nevet valamilyen értékkel, majd a regisztráció örökre megmarad. Egy kifonomultabb névregisztrációs szerződésben szerepelne egy "függvény kaluzula", amely engedné a többi szerződésnek a lekérdezést, valamint a név "tulajdonosának" (azaz az első regisztrálónak) egy mechanizmust, az adat módosítására vagy a tulajdonjog átadására. Bárki hozzáadhat reputációt és web-of-trust funkcionalitást a legfelső réteghez.

Decentralized fájltárhely

Az elmúlt években számos népszerű online fájltárhely startup tűnt fel, amelyek közül az egyik legkiemelkedőbb a Dropbox, akik lehetővé teszik ügyfeleiknek, hogy a merevlemezük biztonsági mentését feltöltsék, majd a szolgáltatással tároltassák azt, majd a fehasználó havidíj ellenében férhet hozzá az adataihoz. Azonban ezen a ponton a fájltárhely piac relatív nem hatékony; ha megvizsgáljuk a különböző meglévő megoldásokat(opens in a new tab)↗, láthatjuk, hogy különösen a "borzongások völgye", azaz a 20-200 GB szinten, ahol sem az ingyenes kvóták, sem a vállalati szintű kedvezmények nem jelennek meg, a mainstream fájltárolási költségek havi árszintje ott tart, hogy egy hónapért többet fizet az átlag felhasználó, mint egy teljes merevlemezért. Az Ethereum szerződések lehetővé teszik egy decentralizált fájl tárolási ökoszisztéma fejlesztését, ahol az egyes felhasználók kis mennyiségű pénzt kereshetnek azzal, hogy bérbeadják saját merevlemezüket és a használaton kívüli tárhelyüket, ezzel is lefelé hajtva a tárolás költségeit.

Az ilyen eszközök kulcsfontosságú megerősítő eleme az általunk "decentralizált Dropbox szerződésnek" elnevezett megoldás. A szerződés a következő módon működik. Először a kívánt adatokat blokkokra bontjuk, adatvédelmi okokból ezeket titkosítjuk, majd egy Merkle-fát építünk belőle. Ezután létrehozunk egy szerződést azzal a szabállyal, hogy minden N blokkban a szerződés egy véletlen indexet választ ki a Merkle-fában (az előző blokk-hash segítségével a szerződés kódjából, véletlenszerűen), majd X ethert adunk az első entitásnak, hogy egy egyszerűsített fizetés hitelesítéssel lássa el a tranzakciót, például a blokk tulajdonjogát bizonyító elemmel az adott indexen a fában. Amikor egy felhasználó újra le szeretné tölteni a fájlt, egy mikrofizetési csatorna protokollt használhat (például 1 szabo 32 kilobyte adatért) a fájl lekérésére; a leginkább költséghatékony megközelítés az, amikor a fizető félnek csak a legvégén kell publikálnia a tranzakciót, ahelyett, hogy a tranzakciót egy kissé jövedelmezőbbre cserélné le ugyanazzal a nounce-al 32 kilobytonként.

A protokoll egyik fontos jellemzője, hogy bár úgy tűnik, hogy valaki több véletlen csomópontot bíz meg azzal, hogy ne felejtse el a fájlt, a saját kockázatát a nullához közelire csökkentheti azzal, hogy a fájlt több részre bontja titkos megosztással, majd figyeli a szerződést, hogy lássa az egyes darabok továbbra is valamelyik csomópont birtokában vannak. Ha egy szerződés továbbra is fizet, akkor kriptográfiai bizonyíték van arra, hogy valaki továbbra is tárolja a fájlt.

Decentralizált Autonóm Szervezetek

A "decentralizált autonóm szervezetek" általános koncepciója, hogy egy virtuális entitásnak, amely adott számú taggal vagy "részvényessel" rendelkezik, akár esetleg 67%-os többséggel, felhatalmazása lehet arra, hogy elköltse az entitás pénzeszközeit és módosítsa a kódját. A tagok együttesen dönthetik el, hogy a szervezet hogyan allokálja a pénzeszközöket. Egy DAO pénzeszközeinek allokálásának módszerei a pénzadománytól, fizetéseken át akár még egzotikusabb mechanizmusokig terjedhet, mint például egy belső valuta a munka elismerésére. Ez gyakorlatilag replikálja a hagyományos vállalatok vagy non-profit entitások jogi csapdáit, de a végrehajtásra kizárólag kriptográfiai blokklánc technológiát használ. Eddig a DAO-kkal kapcsolatban leginkább a kapitalista "decentralizált autonóm vállalat" (DAC) modelljéről beszéltünk, ahol a részvényesek osztalékot vagy kereskedhető részvényeket kapnak; azonban van egy alternatív, talán a "decentralizált autonóm közösség" fogalommal leírható értelmezés is, ahol a tagok egyenlő mértékben vesznek részt a döntéshozatalban, és a tagok 67%-ának beleegyezése szükséges ahhoz, hogy felvegyenek egy új tagot, vagy eltávolítsanak egy tagot. Azt a követelményt, hogy egy személy csak egy tagsággal rendelkezhet a csoportnak kollektíven kell érvényre juttatnia.

A DAO-k kódolásának általános leírása a következő. A legegyszerűbb megoldás egy önmagát módosító kódelem alkalmazása, amely változik, ha a tagok kétharmada egyetért egy módosítással. Bár a kód elméletileg állandó, bárki megkerülheti, és de-facto megváltoztathatja, ha a kód darabjait külön szerződésekbe foglalja, majd a módosítható tárhelyen menti el azt a címet, amit a szerződéseknek meg kell hívni. Egy ilyen DAO szerződés egyszerű implementációjában három tranzakció típus lenne, amelyeket a tranzakcióban megadott adatok különböztetnek meg:

• [0,i,K,V] ahol a javaslatot az i indexxel regisztrálják, hogy módosítsa a címet a K tárolási indexen V értékre
• [1,i] amely egy szavazatot regisztrál az i javaslat előnyben részesítésére
• [2,i] az i javaslat véglegesítésére, ha elég szavazat érkezett be

A szerződésben ezután mindegyikre szerepel egy klauzula. Ezután rögzíti az összes nyitott tárolási módosítást, és azt a listát is, hogy ki szavazott rájuk. Tartalmazza a tagok listáját is. Amikor valamelyik tárolási módosításra a tagok kétharmada szavazott, a véglegesítési tranzakció hajtja végre a módosítást. Egy kifinomultabb vázban lehet beépített szavazási lehetőség is olyan funkciókra, mint például tranzakció küldése, tagok hozzáadása vagy eltávolítása, valamint lehetővé kell tenni egy Liquid Democracy(opens in a new tab)↗-stílusú szavazási delegálást is (azaz egyvalaki kijelölheti, hogy ki szavazzon helyette, majd a kijelölés átadható, tehát, ha A B-t bízza meg a szavazással, majd B C-t bízza meg, C határozza meg A szavazatát). A tervezés lehetővé teszi, hogy a DAO organikusan nőjjön decentralizált közösségként, és a tagok végül delegálhassák azt a feladatot egy specialistának, hogy kiszűrjék a tagokat, szemben a specialisták "jelenlegi rendszerével" akik a közösség egyes tagjait érintő változások függvényében könnyen ki- vagy beugorhatnak.

Alternatív mód a decentralizált vállalat modell, amikor valamelyik számlán nulla vagy több részvény van, és a döntéshozatalhoz a részvények kétharmadára van szükség. Egy teljes vázban ideális esetben van egy eszközkezelő funkció, lehetőség részvények vásárlására vagy eladására szóló ajánlattételre, valamint lehetőség az ajánlatok elfogadására (lehetőség szerint a szerződésen belül egy ajánlat-egyeztető mechanizmussal). A delegálás szintén Liquid Democracy-stílusban létezik, általánosítva az "igazgatótanács" koncepciót.

További alkalmazások

1. Tárcák mentése. Tegyük fel, hogy Alice biztonságban szeretné tudni pénzeszközeit, azonban aggódik amiatt, hogy veszteség éri, vagy valaki feltöri a privát-kulcsát. Ethert helyez el egy szerződésben Bobbal, egy bankkal a következőképpen:

• Alice egyedül naponta legfeljebb a pénzeszközök 1%-át tudja felvenni.
• Bob egyedül naponta a pénzeszközök legfeljebb 1%-át tudja felvenni, de Alicenak lehetősége van arra, hogy tranzakciót végezzen a kulcsával és zárolja ezt a lehetőséget.
• Alice és Bob együtt bármennyit fel tud venni.

Alicenek általában elég naponta 1%, azonban, ha Alice-nak többre van szüksége, értesítheti Bobot, és segítséget kérhet. Ha Alicet támadás éri, Bobhoz siethet, és a pénzeszközöket egy új szerződésbe tudja átmozgatni. Ha elveszíti a kulcsát, Bob tudja végül kivenni az eszközöket. Ha Bob rosszindulatúan kezd viselkedni, Alice ki tudja kapcsolni, hogy Bob pénzt vehessen fel.

2. Termény-biztosítás. Bárki készíthet könnyedén származtatott szerződést, ha az ár indexek helyett az időjárási adatokról érkező adat-feedet használja. Ha egy iowai farmer olyan származtatott ügyletet vásárol, ami fordítottan fizet az Iowában esett csapadék alapján, majd, ha szárazság van, a farmer automatikusan pénzhez jut, ha pedig elég eső esik, a farmer szintén jól jár, mert jó termése lesz. Ez általánosságban kiterjeszthető természeti csapásra vonatkozó biztosítással.

3. Egy decentralizált adat-feed. A pénzügyi CFD-k (nyitó és záróérték közti különbség lekereskedése) esetében gyakorlatilag lehetőség van decentralizálni az adat-feed-et a következő protokollal SchellingCoin(opens in a new tab)↗. A SchellingCoin gyakorlatilag a következőképpen működik: N fél beteszi a rendszerbe egy adott bázis értékét (pl. ETH/USD árfolyam), az értékeket rendezik, és mindenki, aki 25% - 75% között van egy tokent kap jutalmul. Ez a rendszer mindenkit arra ösztönöz, hogy olyan választ adjon, mint a többiek, és az egyetlen érték, amiben a játékosok nagy száma realisztikusan egyet tud érteni a nyilvánvaló alap: azaz az igazság. Ez egy decentralizált protokollt hoz létre, amely elméletileg bármilyen számú értéket adhat, ideértve az ETH/USD árát, vagy a berlini hőmérsékletet vagy egy nehéz számítási feladat eredményét.

4. Okos, több aláírásos escrow. A Bitcoin többaláírásos tranzakciós szerződéseket is enged, ahol például adott öt kulcsból három tudja elkölteni a pénzeszközöket. Az Ethereum ennél részletesebb lehetőségeket is kínál; például ötből négy mindent el tud költeni, ötből három naponta 10%-ot, ötből kettő pedig csak napi 0,5%-t. Továbbá az Ethereum több aláírásos megoldás aszinkron - két fél különböző időben tudja regisztrálni az aláírását a blokkláncon, az utolsó aláírás küldi el automatikusan a tranzakciót.

5. Felhőben történő számítás. Az EVM technológia szintén használható hitelesíthető számítási környezet létrehozására, ahol a felhasználók megkérhetnek másokat számítások végzésére, majd opcionálisan kérhetnek bizonyítékot arra, hogy a számítások adott, véletlenszerűen kiválasztott ellenőrzési pontokon pontosan lettek elvégezve. Így létre lehet hozni egy felhő alapú számítási piacot, amelyen bármelyik felhasználó részt vehet az asztali gépével, laptopjával, vagy speciális szerverével, és együtt ellenőrizhetik szúrópróbaszerűen, hogy mely biztonsági letétek használhatók annak biztosítására, hogy a rendszer megbízható (azaz a csomópontok nem tudnak nyereségesen csalni). Bár egy ilyen rendszer nem feltétlenül felel meg minden feladatra; például nehézkes olyan feladatokat elvégezni nagyméretű felhőalapú csomópontokon, amelyek magasszintű, folyamat közbeni kommunikációt igényelnek. Más feladatokat azonban sokkal könnyebb párhuzamosan végezni; például a SETI@home, folding@home és általános algoritmusokat könnyebben meg lehet valósítani ilyen platformokon.

6. Peer-to-peer szerencsejáték. Tetszőleges számú peer-to-peer szerencsejáték protokollt, például Frank Stajano és Richard Clayton Cyberdice(opens in a new tab)↗ protokollját, lehet megvalósítani Ethereum blokkláncon. A legegyszerűbb szerencsejáték protokoll egyszerűen egy CFD a következő blokk-hashre, ennél bonyolultabb protokollokat is lehet építeni, például szerencsejáték szolgáltatásokat nullához közeli díjakkal, ahol ki lehet zárni a csalás lehetőségét.

7. Kimenetelre fogadó piacok. Az Oracle vagy SchellingCoin környezetben futó kimenetelre fogadó piacokat könnyen meg lehet valósítani; ezek a piacok a SchellingCoin-nal együtt az első futarchy(opens in a new tab)↗ mainstream alkalmazássá nőhetik ki magukat a decentralizált szervezetek irányítási protokolljaként.

8. On-chain decentralizált piacterek, amelyek az azonosítás és elismerés rendszert használják alapként.

Egyebek és aggályok

Módosított GHOST implementáció

A "Greedy Heaviest Observed Subtree" (GHOST) innovatív protokollt Yonatan Sompolinsky és Aviv Zohar vezette be 2013 decemberében(opens in a new tab)↗. A GHOST mögötti motiváció az volt, hogy azokon a blokkláncokon, ahol a megerősítési idő gyors, a magas elavulási aránynak köszönhetően csökken a biztonság - mivel a blokknak bizonyos időre van szüksége a hálózaton való terjedéshez, ha A bányász kibányász egy blokkot, majd B bányász még azelőtt kibányász egy blokkot, hogy A bányász blokkja eljutna B bányászhoz, ez utóbbi blokkja feleslegessé válik, és nem járul hozzá a hálózat biztonságához. Továbbá van egy centralizációs probléma is: ha A bányász egy 30% hash-erejű bányász-pool, és B bányásznak 10% hash-ereje van, A bányásznak megvan az a kockázata, hogy az esetek 70%-ában elavult blokkot hozzon létre (mivel a fennmaradó 30% esetben A bányász hozta létre az utolsó blokkot, így azonnal bányászati adathoz jut), míg B bányász kockázata, hogy az esetek 90%-ában fog létrehozni elavult blokkot. Ezért ha a blokk intervallum elég rövid ahhoz, hogy a lejárati arány magas legyen, A jelentősen hatékonyabb lesz pusztán a mérete miatt. A két hatás kombinálásával az a blokklánc, amely gyorsan gyárt blokkokat valószínűleg vezetni fog egy bányász poolt, és elég nagy százalékot fog elfoglalni a hálózat hash-teljesítményéből, hogy de facto átvegye az irányítást a bányászási folyamat fölött.

Ahogy Sompolinsky és Zohar is leírta, a GHOST megoldja a hálózat biztonságának elvesztését érintő első problémát azzal, hogy lejárt blokkokat is belevesz annak kiszámításába, hogy melyik lánc a "leghosszabb"; azaz nem csak a blokk szülőit és elődeit veszi figyelembe, hanem a blokk elődeinek nem élő leszármazottait is (Ethereum kifejezéssel élve "nagybácsikat") hozzáadja ahhoz a számításhoz, hogy melyik blokkon van a legtöbb proof-of-work. A centralizációval kapcsolatos második probléma megoldására túlhaladunk a Sompolinsky és Zohar által ismertetett protokollon, és blokk jutalmakat adunk az elavult blokkokra is: egy elavult blokk az alapjutalom 87,5%-át éri, míg az elavult blokkot tartalmazó unokaöccs megkapja a fennmaradó 12,5%-ot. A tranzakciós díjakat azonban nem kapják meg a nagybácsik.

Az Ethereum a GHOST egy egyszerűsített verzióját implementálja, amely hét szintre megy le. A részletes meghatározást lásd itt:

• Egy blokknak meg kell határoznia egy szülőt, és 0 vagy több nagybácsit
• Egy B blokkban lévő nagybácsinak a következő tulajdonságokkal kell rendelkeznie:
• Közvetlen leszármazottnak kell lennie a k-adik generációs B ősnek, ahol 2 <= k <= 7.
• Nem lehet a B őse
• Egy nagybácsinak érvényes blokk fejlécnek kell lennie, de nem kell korábban hitelesített vagy érvényes blokknak lennie
• A nagybácsinak különböznie kell a korábbi blokkokban szereplő nagybácsiktól, illetve az ugyanabban a blokkban lévő más nagybácsiktól (nincs-dupla-szerepeltetés)
• MindenU nagybácsihoz a B blokkban, a B bányász további 3,125%-ot kap a coinbase jutalmához, és az U bánász 93,75% standard coinbase jutalomban részesül.

A GHOST limitált verzióját, ahol legfeljebb 7 generációig szerepelhet nagybácsi, két ok miatt használtuk. Először is a korlátlan GHOST túl sok komplikációval járna annak kiszámításában, hogy egy adott blokkban mely nagybácsik érvényesek. Másodsorban a korlátlan GHOST, ahogy az Ethereumban használják, nem ösztönzi a bányászt, hogy a fő láncon bányásszon a nyilvános támadó által használt lánc helyett.

Díjak

Mivel minden blokkláncban közzétett tranzakció költséget ró a hálózatra a letöltés és a hitelesítés miatt, szükség van valamilyen szabályozó mechanizmusra, általában tranzakciós díjak beiktatását, hogy meg lehessen akadályozni a rosszindulatú viselkedést. A Bitcoinban is alkalmazott alapértelmezett megközelítés szerint tisztán önkéntes díjakra van szükség, ami a bányászokra támaszkodik abban, hogy őrizzék a biztonságot és dinamikus minimumokat állítsanak be. Ezt a megközelítést nagyon kedvezően fogadták a Bitcoin közösségben, különösen azért, mert "piaci-alapú", meghagyja a keresletet és a kínálatot a bányászok és a tranzakciók küldői között, és így meghatározza az árat. A probléma ezzel az érveléssel az, hogy a tranzakciók feldolgozása nem piac; bár intuitívan vonzó a tranzakció feldolgozását olyan szolgáltatásként értelmezni, amelyet a bányász kínál küldőnek, a valóságban minden olyan tranzakció, amelyhez bányász kell a hálózat minden csomópontján fel kell dolgozni, így a tranzakció feldolgozási költségének jelentős részét külső felek fizetik, és nem a bányász hozza meg azt a döntést, hogy foglalkozik-e vele vagy sem. Így nagyon valószínű a "közlegelő tragédiája" típusú problémák előfordulása.

Azonban úgy tűnik, hogy a piaci alapú mechanizmus ezen hibája, amikor pontatlan egyszerűsítő feltételezéssel élnek, mágikusan megszünteti saját magát. Az érvelés a következő. Tegyük fel, hogy:

1. Egy tranzakció k művelethez vezet, kR jutalmat kínál minden olyan bányásznak, aki szerepel benne, ahol az R értéket a küldő állítja be, és az k és R (durván) már előre látható a bányász oldalán.
2. Egy művelet feldolgozásához szükséges költség C bármely csomóponton (azaz az összes csomópont hatékonysága azonos)
3. N bányász csomópont van, mindegyik pontosan ugyanannyi feldolgozási teljesítménnyel (azaz 1/N az összesből)
4. Nincs nem-bányászó teljes csomópont.

Egy bányász akkor hajlandó feldolgozni a tranzakciót, ha a várható jutalom nagyobb, mint a költség. Így a várható jutalom kR/N mivel a bányásznak 1/N esélye van feldolgozni a következő blokkot, és a bányász feldolgozási költsége kC. Következésképpen a bányászok olyan tranzakciókban fognak részt venni, ahol kR/N > kC, vagy R > NC. Ne feledjük, hogy R a küldő által műveletenként biztosított díj, amely alulról korlátozza azt az előnyt, amit a küldő a tranzakcióból nyer, és az NC pedig a műveletet feldolgozó teljes hálózat költsége. Következésképpen a bányászok csak olyan tranzakcióban érdekeltek, amelyen a teljes haszonelvű előny nagyobb, mint a költség.

Azonban a valóságban számos fontos eltérés mutatkozik a feltételezésektől:

1. A bányász nagyobb költséget fizet a tranzakció feldolgozásáért mint a többi, hitelesítést végző csomópont, mivel az extra hitelesítéshez szükséges idő késlelteti a blokk terjedését, és növeli annak az esélyét, hogy a blokk elavulttá válik.
2. Így létezik nem-bányászó teljes csomópont.
3. A bányászati teljesítmény eloszlás a gyakorlatban radikálisan egyenlőtlenné válhat.
4. A spekulánsok, politikai ellenségek és őrültek, akiknek a használati függvényei a hálózatra nézve káros elemeket tartalmaznak okosan olyan szerződéseket készíthetnek, amelyekben a költségeik sokkal alacsonyabbak, mint a többi hitelesítő csomópont által fizetett költségek.

(1) olyan tendenciát biztosít a bányásznak, hogy kevesebb tranzakcióba vonódjon bele, és (2) növeli az NC értékét; következésképpen ez a két hatás legalább részben kiírtja egymást.^{Hogyan?(opens in a new tab)↗} (3) és (4) a fő probléma; megoldásukra egy egyszerű lebegő sapkát alkalmazunk: egyetlen blokkon sem lehet több művelet mint a hosszú távú exponenciális mozgóátlag BLK_LIMIT_FACTOR -szorosa. Különösképpen:

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

A BLK_LIMIT_FACTOR és EMA_FACTOR állandó, beállításuk jelenleg 65536 és 1,5, amely további elemzés után változhat.

Van még egy faktor, ami megszünteti a nagy blokkméretek iránti elköteleződést a Bitcoinban: a nagy blokkok terjedési ideje hosszabb, és így nagyobb eséllyel válnak elavulttá. Az Ethereumban a sok gázt fogyasztó blokkoknak is több időre van szüksége a terjedéshez, mivel egyrészt fizikailag hosszabbak, másrészt több időbe telik az állapot átmenet tranzakciók feldolgozásának validálása. Ez a késleltetési negatív ösztönző jelentős a Bitcoin esetében, de kevésbé az az Ethereum világában a GHOST protokoll miatt; következésképpen a szabályozott blokk limitekre való támaszkodás stabilabb alapkonfigurációt tesz lehetővé.

Számítási és Turing-teljesség

Fontos megjegyezni, hogy az Ethereum virtuális gép Turing-teljes; azaz az EVM kód minden olyan számítást képes titkosítani, amelyet rejtve lehet elvégezni, ideértve a végtelen hurkokat is. Az EVm kód a hurkokat kétféleképpen teszi lehetővé. Egyfelől a JUMP utasítás lehetővé teszi a programnak, hogy visszaugorjon egy korábbi pontra a kódban, míg a JUMPI utasítás feltételhez kötött ugrást hajt végre, lehetővé téve a while x < 27: x = x * 2 típusú állításokat. Másodsorban a szerződések más szerződéseket is meghívhatnak, ami potenciálisan lehetővé teszi a rekurzión keresztül történő hurkok alkalmazását. Ez természetesen egy problémát eredményez: a kártékony felhasználók lényegében le tudják állítani a bányászokat és a teljes csomópontokat azzal, hogy végtelen hurokba lépésre kényszerítik őket? A probléma a számítástechnikában megakadás problémaként ismert jelenség miatt jelentkezik: általánosságban nem lehet megmondani, hogy egy adott program mikor akad meg.

Mint azt az állapot átmenet részben is leírtuk, a megoldásunk úgy működik, hogy egy tranzakcióban be kell állítani a maximálisan engedélyezett számítási lépések számát, és ha a futtatás tovább tart, a számítást visszatérítik, azonban díjat is kell fizetni. Az üzenetek hasonlóképpen működnek. A megoldás mögött húzódó motiváció bemutatására nézzük az alábbi példákat:

• Egy támadó létrehoz egy szerződést, amely végtelen hurkot futtat, majd egy tranzakciót küld a bányásznak, amely aktiválja a hurkot. A bányász feldolgozza a tranzakciót, futtatja a végtelen hurkot, majd megvárja, amíg elfogy a gáz. Bár a futtatás kifogy a gázból és félúton megáll, a tranzakció továbbra is érvényes, és a bányász bekéri a díjat a támadótól minden számítási lépésért.
• Egy támadó egy nagyon hosszú végtelen hurkot hoz létre azzal a szándékkal, hogy a bányász olyan sokáig végezze a számítást, hogy a számítás végére pár új blokk is kikerüljön, és így lehetetlenné váljon a bányásznak a tranzakció belefoglalása, hogy díjat számíthasson fel. Azonban a támadónak be kell küldenie egy STARTGAS értéket, amely korlátozza a futtatásban használható számítások számát, így a bányász már előre tudni fogja, hogy a számítás jelentősen több lépésből fog állni.
• Egy támadó valami ilyesmit kódot lát a szerződésben send(A,contract.storage[A]); contract.storage[A] = 0, és pont annyi gázzal küldi el a tranzakciót, hogy futtatni lehessen az első lépést, de a másodikat már ne (azaz meglegyen a levétel, de az egyenleg ne csökkenjen le). A szerződés létrehozójának nem kell azon aggódnia, hogy védekezzen az ilyen támadások ellen, mivel, ha a futtatás félúton megáll, azok vissza lesznek térítve.
• Egy pénzügyi szerződés úgy működik, hogy kilenc tulajdonost illető adat -feed középértékét veszi a kockáztok minimalizálása érdekében. Amikor egy támadó átvesz egy adat-feed-et, amelyet úgy tervetek, hogy módosítható legyen a DAO részben ismertetett változó-cím-meghívás mechanizmuson keresztül, és átkonvertálja úgy, hogy végtelen hurokban fusson, és így megpróbál kikényszeríteni olyan próbálkozásokat amelyek pénzeszközöket kérnek a pénzügyi szerződéstől amíg ki nem fogy a gáz. Azonban a pénzügyi szerződésekben be lehet állítani gázkorlátot az üzeneten, és így meg lehet előzni a problémát.

A Turing-teljesség alternatívája a Turing-nem-teljesség, ahol a JUMP és JUMPI nem létezik, és egyszerre csak egy szerződéspéldány létezhet a hívás-stackben. Ezzel a rendszerrel a korábban ismertetett díjrendszer és a megoldásunk hatékonyságával kapcsolatos bizonytalanságok nem feltétlenül szükségesek, mivel a szerződés futtatásának költségét annak mérete korlátozza be. Továbbá a Turing-nem-teljesség nem túl nagy limitáció; az általunk kitalált összes szerződés példa közül csupán egyhez volt szükség hurokra, és még ez az egy hurok is eltávolítható egy egysoros kódrészlet 26 ismétlésével. A Turing-teljesség súlyos implikációi, valamint a korlátozott haszon alapján, miért nincs egyszerűen egy Turing-nem-teljesség nyelv? A valóságban azonban a Turing-nem-teljesség messze van a probléma elegáns megoldásától. Hogy megértsük miért, nézzük meg a következő szerződéseket:

C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (futtasson egy lépést a programból, majd rögzítse a változtatást a tárhelyen)

Most, küldjön egy tranzakciót A-nak. Így 51 tranzakcióban van egy olyan szerződésünk, amely akár 2⁵⁰ számítási lépést is magában foglalhat. A bányászok megpróbálhatják már jóelőre kiszűrni ezeket a logikai bombákat, ha értéket tartanak minden szerződés mellett, amely meghatározza, hogy legfeljebb mennyi számítási lépést vehet fel, és kiszámítják ezt azokhoz a szerződésekhez, amelyek rekurzívan hívnak más szerződéseket, azonban ez arra kényszerítené a bányászokat, hogy letiltsák azokat a szerződéseket, amelyek más szerződéseket hoznak létre (mivel a fenti 26 szerződés létrehozása és futtatása könnyedén egy szerződésbe gyúrható). Másik problematikus pont, hogy az üzenet címmezője egy változó, tehát általánosságban idő előtt nem lehet megmondani, hogy milyen más szerződést fog meghívni egy adott szerződés. Ezért összességében meglepő következtetésre jutottunk: A Turing-teljességet meglepően könnyű kezelni, valamint a Turing-teljesség hiányát hasonlóképpen meglepően nehéz kezelni, kivéve, ha ugyanezeket a vezérlőket alkalmazzuk - de ebben az esetben miért ne legyen a protokoll Turing-teljes?

Valuta és kiadás

Az Ethereum rendszerben saját beépített valuta, az ether szolgál kettős célt, egyfelől egy elsődleges likviditási réteget biztosít a különböző digitális eszközök közötti hatékony váltáshoz, másfelől pedig fontos mechanizmust biztosít a tranzakciós költségek fizetésére. Kényelmi szempontból, valamint elkerülve a későbbi vitákat (lásd a jelenlegi mBTC/uBTC/satoshi vitát a Bitcoin-ban), a névértékeket előre felcímkézzük:

• 1: wei
• 10¹²: szabo
• 10¹⁵: finney
• 10¹⁸: ether

Ez a "dollár" és "cent", illetve a "BTC" és "satoshi" koncepció kibővített változataként értelmezhető. A közeljövőben az "ether" lesz használatos a hagyományos tranzakciókra, a "finney" a mikrotranzakciókra, a "szabo" és "wei" pedig a díjak és protokoll implementációkkal kapcsolatos technikai értekezésekben; a fennmaradó címletek pedig később lehetnek hasznosak, és jelenleg nem szerepelnek a kliensekben.

A kiadási modell a következő:

• Az Ether mint valuta egy BTC-hez viszonyítva 1000-2000 ether árfolyamon fog forogni; ez a mechanizmus az Ethereum szervezet forrásait biztosítja, valamint ezzel lehet fizetni a fejlesztésekért, amelyet más platformon, például a Mastercoin-on és az NXT-n már sikerrel használtak. A korai vásárlók nagyobb kedvezményekben részesülnek. Az eladásból kapott BTC-ket teljes mértékben a fejlesztők fizetésére és javadalmazására fordítják, valamint különböző for-profit és non-profit projektekbe fektetik az Ethereum és kriptovaluta ökoszisztémában.
• A teljes értékesített összeg (60102216 ETH) 0.099x-át a szervezet kapja a korai hozzájárulók kompenzálására, valamint ETH-ban denominált költségekre fordítják a genesis blokk előtt.
• A teljes értékesített összeg 0,099x részét hosszú távú tartalékba helyezik.
• A teljes értékesített összeg 0,26x része a bányászokhoz kerül évente, örökre ezután a pont után.

Hosszú távú kínálati növekedési ütem (százalék)

A lineáris valuta kibocsátások ellenére, hasonlóan a Bitcoin-hoz időről időre a kínálati növekedési ütem nulla felé tart

A fenti modellben két választási lehetőség van (1) egy felnagyítási-pool megléte és mérete, és (2) egy állandóan növekvő lineáris kereslet, szemben a Bitcoin esetében látható felső korlátos kínálattal. A felnagyítási-pool indoklása a következő. Ha nincs felnagyítási-pool, és a lineáris kibocsátás 0,217x-re csökken az infláció biztosítására, akkor az ether teljes mennyisége 16,5%-al lesz kevesebb, és minden egység 19,8%-al értékesebb lenne. Következésképpen a 19,8%-os egyensúlyban több ethert vásárolnak az értékesítés folyamán, így minden egység megőrzi korábbi értékét. A szervezet ezután 1,198x BTC-vel rendelkezik, amit két szeletre lehet bontani: az eredeti BTC és a további 0,198x rész. Következésképpen a helyzet pontosan megegyezik a nagyítással, van azonban egy fontos különbség: a szervezetnél csupán BTC van, és így nincs ösztönözve arra, hogy támogassa az ether mértékegység értékét.

Az állandó lineáris keresletnövekedés modell csökkenti a jelentő vagyonkoncentráció kockázatát a Bitcoinban, és lehetőséget biztosít a jelen és jövő vásárlóinak, hogy reális esélyük legyen valuta egységeket venni, ugyanakkor erősen ösztönöznek arra, hogy még több ethert vegyenek és tartsanak, mivel a "kereslet növekedési üteme" százalékosan idővel a nulla felé közelít. Azt is feltételezzük, hogy mivel óvatlanság, haláleset stb. miatt mindig van, aki elveszti a coinjait, és ez százalékosan is modellezhető az éves kínálat függvényében, a teljes forgalomban lévő valutakészlet végül a veszteség arányával elosztott éves kiadás értékével azonos értéken stabilizálódik (például ha a veszteség aránya 1%, amint a kínálat 26X, 0,26X lesz bányászva és 0,26x veszik el évente, és létrejön az egyensúly).

Ne feledjük, hogy a jövőben valószínű, hogy az Ethereum proof-of-stake modellre vált a biztonság érdekében, és évi nulla és 0,05X közé csökken a kiadásra vonatkozó követelmény. Abban az esetben, ha az Ethereum szervezet elveszíti pénzeszközeit, vagy valamilyen más okból kifolyólag eltűnik, nyitva hagyunk egy "társadalmi szerződést": mindenkinek joga van létrehozni egy jövőbeli Ethereum verziót, azzal a feltétellel, hogy az ether mennyiségének 60102216 * (1.198 + 0.26 * n) kell lennie, ahol az n a z évek számát jelöli a genesis blokk után. A létrehozók szabadon értékesíthetik crowd-sell formájában, illetve meghatározhatják a PoS-által hajtott kínálat növekedés és a maximálisan engedélyezett kínálat bővülés különbségét részben vagy egészben a fejlesztés költségeinek lefedésére. Azok a frissítések, amelyek nem felelnek meg a társadalmi szerződés követelményeinek forkolhatók a követelményeknek megfelelő verziókba.

A bányászat centralizálása

A Bitcoin bányászati algoritmusa úgy működik, hogy a bányászok SHA256 számításokat végeznek a blokk fejléc kissé módosított verzióin egymás után több milliószor, amíg végül egy csomópont egy olyan verzióhoz ér, amelynek hash értéke kevesebb mint a cél (jelenleg körülbelül 2¹⁹²). Azonban ez a bányászati algoritmus a centralizáció két formájára sérülékeny. Először is a bányászati ökoszisztémát az ASIC-ok (alkalmazásspecifikus integrált körök), az erre a célra tervezett számítógép chipek dominálják, és ezért ezek többezerszer hatékonyabbak a Bitcoin bányászat során. Ez azt jelenti, hogy a Bitcoin bányászat már egyáltalán nem decentralizált és az egyenlőségen alapuló tér, és több millió dolláros tőkére van szükség ahhoz, hogy hatékonyan részt lehessen venni benne. Másodsorban a legtöbb Bitcoin bányász gyakorlatilag nem lokálisan validálja a blokkokat; hanem helyette egy centralizált bányász-poolra támaszkodnak a blokk fejlécek megadásakor. Ez a probléma azonban még rosszabb: a tartalom írásakor a legjobb három bányász-pool indirekt módon a feldolgozási teljesítmény körülbelül 50%-át irányítja, bár ezt némiképp enyhíti az a tény, hogy a bányászok átválthatnak egy másik pool-ra, ha a pool vagy a koalíció 51%-os támadással próbálkozik.

Az Ethereumban jelenleg az a szándék, hogy olyan bányászati algoritmust használjanak, ahol a bányászoknak véletlenszerűen kell adatot lekérniük az állapotról, ki kell számítaniuk néhány random kiválasztott tranzakciót a blokklánc utolsó N blokkjáról, és vissza kell adniuk az eredmény hashjét. Ennek két fontos előnye van. Először is az Ethereum szerződésekben bármilyen számítás lehet, így egy Ethereum ASIC lényegében egy általános számításra használt ASIC - azaz egy jobb CPU. Másodszor a bányászatnak hozzá kell férnie a teljes blokklánchoz, ami arra kényszeríti a bányászokat, hogy a teljes blokkláncot tárolják, és legalább képesnek kell lenniük minden tranzakció hitelesítésére. Emiatt nincs szükség centralizált bányászati-poolokra; bár a bányászati-poolok továbbra is betöltik azt a legitim szerepet, hogy kizárják a jutalom elosztás véletlenszerűségét, ezt a funkciót egyenlően el tudják látni a peer-to-peer poolok, központi irányítás nélkül.

Ez a modell még nincs tesztelve, és szembejöhetnek még nehézségek bizonyos okos optimalizálások elkerülése terén, amikor a szerződés futtatást bányászati algoritmusként használják. Azonban ennek az algoritmusnak egyik érdekes funkciója, hogy bárki "megmérgezheti a kutat", ha nagyszámú szerződést vezet be a blokkláncra, azért, hogy megakasszon bizonyos ASIC-okat. Az ASIC gyártók számára léteznek gazdasági ösztönzők arra, hogy ezzel a trükkel megtámadják egymást. Ezért az általunk fejlesztett megoldás végeredményben egy adaptív humán gazdasági megoldás, és nem pusztán technikai.

Méretezhetőség

Az Ethereummal kapcsolatos gyakori aggály a méretezhetőség kérdése. A Bitcoinhoz hasonlóan az Ethereumnak megvan az a hibája, hogy a hálózatban minden csomópontnak fel kell dolgoznia a tranzakciókat. A Bitcoin esetében a jelenlegi blokklánc mérete körülbelül 15 GB, ami óránként mintegy 1 MB-vel nő. Ha a Bitcoin hálózatnak másodpercenként 2000 Visa tranzakciót kellene feldolgoznia, akkor három másodpercenként nőne 1 MB-val (1 GB óránként, 8 TB évente). Az Ethereumon is hasonló növekedési tempó figyelhető meg, amelyet még rosszabbá tesz az a tény, hogy számos alkalmazást futtatnak az Ethereum blokkláncán, szemben azzal, hogy a Bitcoin csak egy valuta, azonban javít rajta az, hogy az Ethereum teljes csomópontjainak csak az állapotot és nem a teljes blokklánc előzményt kell tárolniuk.

A nagyméretű blokklánccal a centralizáció kockázata a fő probléma. Ha a blokklánc mérete mérete mondjuk 100 TB-ra nő, a legvalószínűbb forgatókönyv szerint csak nagyon kevés nagyvállalat tud majd teljes csomópontot futtatni, az összes hagyományos felhasználó pedig könnyű SPV-csomópontokat fog használni. Egy ilyen helyzetben felmerülhet a lehetséges aggály, hogy a teljes csomópontok összefoghatnak, és megállapodnak abban, hogy profitábilis módon csaljanak (például módosítsák a blokkok után járó jutalmat, vagy BTC-t adjanak maguknak). A könnyű csomópontok nem tudják ezt azonnal felismerni. Természetesen legalább egy becsületes teljes csomópont valószínűleg létezne, és a csalás kiderülése után néhány órával már a Reddit is tele lenne a hírrel, azonban ezen a ponton ez már túl késő lenne: a normál felhasználókon múlna, hogy szervezetten tiltólistára tegyék az adott blokkokat, azonban ez a koordinációs probléma jelentős és eléggé megoldhatatlan helyzetet teremtene, hasonlóan egy sikeres 50%-os támadás indításához. A Bitcoin esetében ez jelenleg probléma, de létezik rá blokklánc módosítási javaslat Peter Todd-tól(opens in a new tab)↗ amely enyhítene a problémán.

A közeljövőben az Ethereum két további stratégiát fog használni a probléma megoldására. Először a blokklánc alapú bányászati algoritmusok miatt legalább minden bányász rá lesz kényszerítve, hogy teljes csomópont legyen, ami alacsonyabb korlátot hoz létre a teljes csomópontok viszonylatában. Másodszor, és még fontosabb módon egy közbenső állapot fa gyökeret szerepeltetünk a blokkláncban a tranzakciók feldolgozása után. Még akkor is, ha a blokk validálása centralizált, addig, amíg van becsületes csomópont, a centralizációs probléma megkerülhető a protokoll validálásával. Ha egy bánász érvénytelen blokkot tesz közzé, vagy a blokk nincs megfelelően formázva, vagy az S[n] állapot pontatlan. Mivel az S[0] kódnak pontos, kell lennie egy első S[i] állapotnak, ami hibás ott, ahol az S[i-1] pontos. A hitelesítő csomópont megadja az i indexet egy "proof of invalidity" (érvénytelenségi bizonyíték) bizonyítékkal, ami olyan Patricia fa csomópontokból áll, amelyeknek fel kell dolgozniuk a APPLY(S[i-1],TX[i]) -> S[i] kifejezést. A csomópontok használni tudják ezeket a Patricia csomópontokat a számítás egy részének futtatásához, és látni fogják, ha a generált S[i] nem egyezik a megadott S[i] értékkel.

Egy másik, kifinomultabb támadásban rosszindulatú bányászok félkész blokkokat publikálnak, így a teljes információ nem is létezik annak megállapítására, hogy a blokk érvényes-e. A megoldás egy kihívásra reagáló protokoll: a hitelesítő csomópont cél tranzakciós indexek formájában "kihívásokat" adnak ki, majd amikor visszakapnak egy csomópontot, egy könnyű csomópont mindaddig érvénytelennek tekinti a blokkot, amíg egy másik csomópont, egy bányász, vagy egy másik hitelesítő vissza nem ad Patricia csomópont készleteket igazolva az érvényességet.

Következtetés

Az Ethereum protokollt eredetileg egy frissített kriptovaluta verziónak tekintették, ami haladó funkciókat is kínált, például blokkláncon lévő escrow-t, kivételi korlátokat, pénzügyi szerződéseket, szerencsejáték piacokat és hasonlókat egy nagyon általánosított programnyelven. Az Ethereum protokoll nem "támogatja" közvetlenül az alkalmazásokat, azonban a Turin-teljesség programnyelv megléte azt jelenti, hogy tetszőleges mennyiségű szerződés hozható létre bármilyen tranzakció típushoz vagy alkalmazáshoz. Még érdekesebb az Ethereummal kapcsolatban, hogy az Ethereum protokoll sokkal több puszta valutánál. A decentralizált fájl tárolással, számításokkal és kimenetelre fogadó piacokkal kapcsolatos protokollok több tucat hasonló koncepció mellett magukban rejtik a számítási ipar hatékonyságnövelésének potenciálját, és masszív lökést adnak más peer-to-peer protokolloknak egy korábban nem látott gazdasági réteg hozzáadásával. Végezetül pedig jelentős számú alkalmazás van, amely egyáltalán nem foglalkozik pénzzel.

Az Ethereum protokollban implementált tetszőleges állapot átmenet függvény koncepciója egyedi potenciált rejtő platformot kínál; szemben a zártvégű, egycélú protokollokkal, amelyeket egy bizonyos típusú alkalmazásra fejlesztenek az adattárolás, pénzügy vagy szerencsejáték világában, az Ethereum egy alapvetően nyílt végű koncepció, és hiszünk abban, hogy kiválóan szolgál nagyon sok pénzügyi és nem pénzügyi protokoll alapozó rétegeként az elkövetkező években.

Jegyzetek és további olvasnivaló

Jegyzetek

1. A kifinomult olvasó észreveheti, hogy gyakorlatilag egy Bitcoin cím az elliptikus görbe nyilvános kulcs hash-e, és nem a nyilvános kulcs maga. Azonban gyakorlatilag teljesen legitim kriptográfiai terminológia a pubkey hash nyilvános kulcsként történő hivatkozása. Ez azért van, mert a Bitcoin kriptográfiáját tekinthetjük egy egyedi digitális aláírás algoritmusnak, ahol a nyilvános kulcs az ECC pubkey hashjéből áll, az aláírás az ECC pubkey és az ECC aláírás együttesen, a hitelesítő algoritmusban pedig az aláírásban lévő ECC pubkey-t a nyilvános kulcsként rendelkezésre bocsátott ECC pubkey hashhel vetik összes, majd az ECC aláírást az ECC pubkey értékével hitelesítik.
2. Gyakorlatilag a 11 előző blokk mediánja.
3. Az Ethereum protokollnak egyszerűnek és praktikusnak kell lennie, de elképzelhető, hogy viszonylag összetettnek kell lennie, például méretezhetőnek, hogy internalizálni lehessen a tárolás költségeit, a sávszélességet és I/O-t a biztonság, adatvédelem és átláthatóság stb. érdekében. Ahol a komplexitás elengedhetetlen, a dokumentációnak a lehető legegyértelműbbnek, átfogóbbnak és naprakészebbnek kell lennie, így bárki, aki nem járatos az Ethereumban meg tudja tanulni és szakértővé válhasson.
4. Lásd az Ethereum Virtuális Gépről szóló Sárgakönyvet(opens in a new tab)↗ (amely hasznos specifikációkat tartalmaz, és referenciaként szolgálhat azoknak, akik a nulláról szeretnének Ethereum klienst építeni), továbbá számos témakör ismertetése is megtalálható az Ethereum wiki oldalán(opens in a new tab)↗, például a shard- fejlesztés, fő fejlesztés, dapp fejlesztés, kutatás, Casper K&F, és hálózati protokollok. A kutatásról és a lehetséges jövőbeli implementációkról lásd: ethresear.ch(opens in a new tab)↗.
5. Ennek egy másik kifejezési módja az absztrakció. A legfrissebb roadmap(opens in a new tab)↗ az absztrakt futtatás megtervezése, ahol a futtató motoroknak nem feltétlenül kell követniük egy kanonizáló specifikációt, de például testreszabható egy adott alkalmazáshoz vagy egy shard-hoz. (A futtató motorok heterogénsége nincs explicite leírva a roadmapban. Létezik heterogén sharding, amelyet Vlad Zamfir foglalt koncepcióba.)
6. Belső értelmezésben a 2 és "CHARLIE" szám, ez utóbbi big-endian bázis 256 reprezentáció. A számok 0-tól legfeljebb 2²⁵⁶-1-ig terjedhetnek.

További olvasnivaló

1. Valódi érték(opens in a new tab)↗
2. Okos-tulajdonság(opens in a new tab)↗
3. Okosszerződések(opens in a new tab)↗
4. B-pénz(opens in a new tab)↗
5. Újrahasznosítható proof-of-work(opens in a new tab)↗
6. Biztonságos tulajdonság címek tulajdonosi rendelkezéssel(opens in a new tab)↗
7. Bitcoin fehérkönyv(opens in a new tab)↗
8. Namecoin(opens in a new tab)↗
9. Zooko háromszög(opens in a new tab)↗
10. Colored coins fehérkönyv(opens in a new tab)↗
11. Mastercoin fehérkönyv(opens in a new tab)↗
12. Decentralizált autonóm vállalatok, Bitcoin Magazine(opens in a new tab)↗
13. Egyszerűsített fizetés hitelesítés(opens in a new tab)↗
14. Merkle fák(opens in a new tab)↗
15. Patricia fák(opens in a new tab)↗
16. GHOST(opens in a new tab)↗
17. StorJ és Autonóm ügynökök, Jeff Garzik(opens in a new tab)↗
18. Mike Hearn az Okos tulajdonságokról a Turing Fesztiválon(opens in a new tab)↗
19. Ethereum RLP(opens in a new tab)↗
20. Ethereum Merkle Patricia fák(opens in a new tab)↗
21. Peter Todd a Merkle összeg fákról(opens in a new tab)↗

A fehérkönyv történetéről lásd: https://github.com/ethereum/wiki/blob/old-before-deleting-all-files-go-to-wiki-wiki-instead/old-whitepaper-for-historical-reference.md(opens in a new tab)↗

Az Ethereum sok másik közösség által vezetett, nyílt forráskódú szoftver projekthez hasonlóan, a kezdeti elindulás óta fejlődött. Ha többet szeretnél megtudni az Ethereum legutóbbi fejlesztéseiről és az általunk elvégzett protokoll változtatásokról, akkor ezt az útmutatót ajánljuk.