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 kulcsfn. 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ó:
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.
- Ha a hivatkozott UTXO nincs benne az
Ha az összes bemeneti UTXO egység összege kisebb, mint az összes kimeneti UTXO egység összege, hiba visszaadása.
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:
- Ellenőrizni, hogy a blokk által hivatkozott előző blokk létezik és érvényes.
- 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
- Ellenőrizni, hogy a blokk munkabizonyítéka érvényes-e.
- Legyen
S[0]
az előző blokk után lévő állapot. - Legyen
TX
a blokk tranzakciós listájan
tranzakcióval. Mindeni-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. - 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 2187. 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 2187-es cél esetében, a hálózatnak átlagosan ~269 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ű:
- 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")
- Megvárni amíg megérkezik a termék
- Egy másik tranzakció létrehozása, amiben ugyanazt a 100 BTC-t küldi el magának
- 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 azAPPLY'(S,TX)
hibaüzenetet ad vissza, a protokoll azAPPLY'(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 2k 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:
- 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.
- 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.
- 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.
- 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.
- 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.