Ethereum: Van mit ünnepelni (!?)

Bő fél éve, hogy parity ethereum kliens egyik fejlesztője (Afri Scheodon) hosszan elmélkedett a dev.to-s cikkében arról, hogy a korábbi pletykák és spekulációk ellenére miért valótlan, hogy reális esélye lenne az Ethereum blokklánc 1 TB-os szint felé történő gyarapodásának. Afri számos indokot hozott fel emellett. A cikk tavaly november végén született, amikor az Ethereum blokklánc archive (full) mérete 326GB-nál tartott és a trace(+fat) állapota is még éppen belefért a 385GB-ba. Az akkor majd 2,5 éves blokklánc terjedelme alapján talán logikus következtetés is lehetett, hogy egyhamar nem lesz meg az 1TB… Nos Afri tévedett… de nem kicsit. Az elmúlt napokban átlépte az Ethereum (Ethereum Foundation) blokklánc teljes mérete (parity archive full) az 1 Tb méretet. Sőt azóta már az 1.1 TB-ot is. Ez önmagában hatalmas szó, hiszen ennél jobb bizonyítékát keresve sem lehet találni az Ethereum hatékonyságának és fontosságának. Maga az alap blokkláncon monetizált piaci érték közel 60 milliárd dollár körül vagy, de ha ehhez hozzáadjuk a blokkláncon – nyilvánosan – kibocsátott és tőzsdéken listázott tokenek piaci értékét, akkor ezen érték már kicsivel 100 milliárd US$ felé emelkedik, amivel az Ethereum blokkláncon aggregálódó piaci kapitalizáció látványosan közelíti meg a Bitcoin teljes piaci kapitalizációját.

Hogy mit mutat a varázsgömb? Hogy fog ez így tovább nőni? StopAndDecrypt készített egy igen komplex elemzést, ami egyébként lényegében jelen cikkemnek a teljes hátterét is adja. Az elemzés extrapolációja már júliusra 1,4TB feletti értéket mutat és tovább húzva a képzeletbeli vonalat még az év vége előtt bőven túl leszünk a 2 Tbyteos méreten is. Persze mindez koránt sem ennyire egyszerű. Hiszen a platform népszerűsége eddig sem és nyilván a jövőben sem lineárisan fog növekedni. Elnézve az egy éves, vagy akár csak a fél éves marketcap adatokat jól látható, hogy az Ethereumba beömlő mérhetetlen mennyiségű vagyon sem lineárisan gyarapodott.

Persze téves következtetés azt gondolni, hogy az Ethereum blockchain méretnövekedése exponenciális pályára lépne. Az elmúlt bő fél évben a méret havonta fixen 10GB körül gyarapodott. Ez a gyarapodás ennél sokkal nagyobbra nem nőhet, ami az egyik alapvetően Ethereum hálózati paraméterből származik: gas limit. A gas limit (ami egyébként most 8 millió gas) határozza meg, hogy blokkba mennyi elemi tranzakció kerülhet be, ami voltaképpen a blokkok méretét és ezáltal a blokklánc méretgyarapodását is befolyásolja. Minden egyes műveletnek amit egy tranzakció/smart contract futtatni tud van egy fix gas értéke. A matematikai műveletek kifejezetten olcsók, cserébe viszont a blokkláncot bővítő műveletek (store, array/hashmap append, tranzasction) kifejezetten borsosak. Egy egyszerű elemi tranzakció 21.000 gas-ba kerül, amiből következik, hogy egy blokkba egyébként jelenleg maximum 380 db sima tranzakció férhetne bele. Ugyanez az érték már egy alap funkciójú ERC20-as tokennél simán felfuthat akár 60-80.000 gas-ra is, hiszen az ERC20-as tokenek saját tokendb-t/inventoryt tartanak fenn, aminek a karbantartása közvetlen blokkláncban tárolt információ módosítást igényel. Egy komplexebb ERC20-as token esetén ez némileg több is lehet. Pont emiatt áll elő rendszeresen az az állapot, hogy amikor egy nagyobb és jobban marketingelt token kibocsátás történik, akkor akár órákig használhatatlanná válik az ethereum hálózat, hiszen ha egy blokkba csak 100-150 ERC20-as tranzakció fér bele és egyszerre akar whitelistről akár 4000-5000 individuum depositálni, akkor bizony 30-50 blokkot is kitömhet csak az adott ERC20-as token disztributálása.

Probléma-e az, hogy ma már 1TB adat van az Ethereum blokkláncon, vagy akár az, hogy év végére akár ez 2TB is lehet. Egyrészt ne felejtsük el, hogy itt egy peer-to-peer hálózatról beszélünk, ami több ezer másolatban tárolja a blokkláncot. Én kb 7-8 hónapja  döntöttem úgy utoljára, hogy készítek egy full syncet geth-el az Ethereum blokkláncból. Az SSD-s diszkű, stabil internet kapcsolattal rendelkező gépem szó szerint küzdött mint disznó a jégen és alig 3,5 nap alatt majdnem syncbe is került, majd onnan újabb 2 napig tartott, mire talált egy olyan peert, aki hajlandó volt syncig eljuttatni, ahol emlékeim szerint 1 hétig működött is minden, majd jött az out-of-sync és onnantól soha többé nem került a nodeom syncbe. A helyzet az, hogy perpillanat egy fully synced archive (+trace) node üzemeltetése már nem desktop kategóriás kérdés. Egy erre alkalmas cloud gép (aws, i3.xlarge) alap díja meghaladja a 600e HUF-ot évente és ezzel is csak talán ezt az évet lehet kihúzni. A folyamatosan növekedő gépigény nem csak a diszk kapcsán jelentkezik, az egyre komplexebb smartcontractok és tranzakciók validálása egyre tetemesebb memória és cpu időt is igényel. Ennek okán egyre inkább nehéz (vagy legalábbis költséges) Ethereum blokkláncra építeni új történetet. Persze senki ne ijedjen meg, ez nem vonatkozik az ICO-kra… ahhoz nem kell full archive node.

Ez az a pont, ahol érdemes tisztázni, hogy mi a francot is jelent ez a full, full archive, trace stb? Amilyen állapotokat meg szokás különböztetni (parity terminológiában): light, warp fast, full fast, archive, archive+trace. Röviden ezekről:

• A light sync csak a block headereket synceli, ami nem minősül semmilyen szintű validációnak, ez inkább csak egy inventory
• warp fast: Csak a legfrissebb blokkok objektumainak legfrissebb állapotát synceli és tárolja. Ez pl.: már arra jó lehet, hogy egy ERC20-as token unconfirmed transactionjeit validáljuk. Egy ilyen sync mai mérete 38GB körül van.
• full fast: ugyanaz mint a warp fast, de itt már az összes blokkra kiterjed a synclés. Így olyan objektumok aktuális állapotához is hozzáférünk, ami nagyon régóta nem változott. Egy ilyen sync mai mérete 30GB körül van.
• archive: Az összes blokkot teljes egészében tároljuk, így az objetumoknak (pl. hashmap) nem csak az aktuális állapotát ismerhetjük meg hanem azt is, hogy egy adott korábbi időpontban mi volt a map állapota. Ez akkor lehet hasznos, ha pl.: egy ERC20-as tranzakció kapcsán valaki problémát vet fel egy múltbeli esemény kapcsán. (Tipikus példa: kap az adott felhasználó multisig walletje tokent vestinggel, és szeretné látni, hogy melyik owner mikor húzta le az időarányos token mennyiséget). Ennek mai mérete 1.1TB
• archive+trace: A teljes blokklánc összes adata mellett a validációs folyamat trace állományai is tárolódnak. Ez főleg azoknak fontos és hasznos, akik aktívan folytatnak blokkláncon elemzést, tokenek/coinok nyomon követéstét, stb.

Miért ennyire brutálisan nagy a teljes blokklánc? Nyilvánvalóan a mérhetetlen igény a blokkláncon futó tartalmak kapcsán. A gyűjthető és szeretgethető cryptomacskák, krokodilok, teknősök az egész napos szórakozást nyújtó Pepe Farm és annak immáron lassan végtelen kópiája, az Etherpokemon, az etherlottók, szerencsejátékok és persze a naponta a végtelenhez közelítő ICO-k. Hogy miért éri meg bárkinek mérhetetlen mennyiség gas-t elégetni ezen játékok futtatására? Ez nyilvánvalóan az immáron 20 éve épülő gamification kultúra utóhatása, ami komplett generációkba nevelt bele egy olyan roppantul újszerű pénzügyi kultúrát, amire gyanúsan nem készült még fel a társadalom. De mielőtt ebbe jobban belemennék, ezt a gondolatmenetet inkább zárom is, mert ez a téma amúgy is megérne egy külön cikket.

Tényleg gondot jelent az, hogy a blokklánc immáron 1TB feletti méretre hízott? Vitalik Buterin (Ethereum atyja) szerint nem. Szerinte bárkinek bőségesen elég kell, hogy legyen a full fast blokklánc, hiszen abból bármilyen a blokkláncon tárolt objektum aktuális állapota bőségesen megállapítható és validálható. Márpedig a full fast sync előállítása során is validálódik a teljes blokklánc, így garantálható lehet egy full fast synced node esetén is az immutabilitás. Bár a logika kikezdhetetlen, de azért enyhén mégis számít. Hiszen egy ilyen node esetén csak az igazolt, hogy a syncelésnél a teljes blokklánc egyszer biztosan teljesen ellenőrizve lett. Persze minden csak megközelítés kérdése: Ha a Bitcoin által körvonalazott blockchain szemlélettel nézem az Ethereumot, akkor valóban az full archive node nyújt csak valódi immutability-t. Ezzel szemben persze nem árt az Ethereum esetén elvonatkoztatni a Bitcointól, hiszen az Ethereum nagyon sok szempontból újszerű megközelítést alkalmaz, ennek egyik fontos része, hogy a blokkláncon tárolt objektumok állapota változhat. Ha evidenciaként kezeljük, hogy ezen változásoknak mindig csak az utolsó állapota releváns, aktuális, akkor elfogadhatjuk, hogy egy full fast synced node immutabilitása megkérdőjelezhetetlen.

Szóval ez egyértelműen csak megközelítés kérdése. Ha akarom azt mondom, hogy az Ethereum blokklánc mérete 1.1TB és ez nagyon sok, de ha akarom azt is mondhatom, hogy csak kb. 60GB… ami kétségtelenül jobban néz ki. De akkor egy picit ragadjunk le még a archive blokklánc méreténél és kicsit filozofáljunk ennek a jövőképén, hisz bármennyire is jól hangzik a full fast synced node, de azt látni kell, hogy ezek mögött is archive nodeoknak kell állniuk, hiszen egy full fast synced nodeot is csak egy (több) archive noderól lehet felsyncelni. Ergo az archive nodeok az ökoszisztéma kritikus elemei és ezek darabszáma (pontosabban azok darabszámának drasztikus csökkenése erősen a centralizáció irányába hat)ayx

Miért gond a folyamatosan növekvő gépigény? Ez egy olyan téma, amit tavaly már számtalan alkalommal leírtam: minél nagyobb kihívás egyéni játékosként részt venni egy hálózat működtetésében, annál inkább centralizálódik az és annál inkább kiszolgáltatottá válnak a felhasználók a centrális szereplők hóborjának. Ez napnál világosabban tetten érhető például a Bitcoin Cash kapcsán. Fogja magát Craig Wright és egy tajvani konferencián benyögi, hogy: “akkor ennek az országnak nem engedem meg, hogy használja a technológiámat”, majd Ugandában egy blockchain konferencián közli, hogy “nekem több pénzem van mint az egész országotoknak egybevéve, nehogy már én könyörögjek, hogy használjátok a technológiámat”… Az ilyen fajta arrogancia hátterében egyértelműen a koncentrálódó hatalom és persze némi kettyó állhat csak.

Hogy mi a megoldás? Felhasználói oldalról nézve nyilván megvan mindenkinek a maga szabadságfoka, pont úgy nem kötelező használni az egyre inkább centralizálódó Ethereumot, ahogy nem kell használni a Bitcoint, vagy akár az US dollárt. Persze másrészről ezen pénzügyi platformokat nem véletlenül használjuk: ezekhez értünk, ezekre építkezünk. Nehéz átállni egy teljesen új megoldásra. Sokkal érdekesebb az a kérdés, hogy vajon mit kezd ezzel a problémával maga az Ethereum core dev team és persze maga Vitalik Buterin? A fejlesztőcsapat látványosan versenyt fut az idővel. A hosszúra nyúlt Casper (PoS) implementáció okán a scalability problémával nem igazán tudtak eddig foglalkozni a devek. Tavaly Vitalik kiszúrta a közösség szemét egy Plasma whitepaperrel (layer2 implementáció és egy rászabadította a közösségre a Raiden projektet, nemrégiben pedig a sharding kapcsán rukkolt elő egy proof of concepttel.

Mivel középút nincs, és mivel mindkét irány komoly előnyökkel kecsegtet, így minden bizonnyal egy komplex öszvér megoldás fog következni. Tehát a Proof of Stake implementálása után Vitalik és csapata feltételezhetően egyszerre vág bele a layer2 és a sharding implementálásba. A layer2-nek köszönhetően drasztikusan csökkenhet az onchain tranzakciók száma (kevesebb macskát kötnek láncra…), míg a shardingnak köszönhetően a hálózat sokkal inkább fogja jól kezelni a peak jellegű terheléseket és jelentősen nőhet az áteresztőképessége.

A layer-2-ről a Lightning Network kapcsán már nagyon sokszor írtam, így csak röviden ismételném magam:  A layer-2 megoldások (ide érve a Raider networköt is), a blockchain szintjén csak egy settlement layert hoznak létre, amivel kiemelnek a blokkláncból adott értéket, amivel a csatorna zárás pillanatáig szabadon rendelkezhetnek, a blokkláncra pedig csak a csatorna nyitó és záró egyenlege kerül, ami ennél fogva (függően a csatornán közlekedő tranzakciók számától) drasztikusan tudja csökkenteni a blokklánc méretnövekedését.

A sharding ezzel párhuzamosan a ‘nyers erőt’ veti be a biztonság rovására. (Bár ezen állítással Vitalik végletekbe menően nem ért egyet…) A decentralizált hálózat nagyszerűségét az adja, hogy biztos lehetsz abban, hogy a full nodeok minden tranzakciót validáltak és a genezis blokktól kezdődően minden tranzakció hiteles. A sharding lényege, hogy ezen bizalom csökken. A hálózati csomópontok csak azokat a tranzakciókat validálják, amik a saját shardjukban (darabjukban/részükben) zajlik, az összes többi shardban keletkező blokkoknak viszont csak a headerjét validálják. A header validáció a gyakorlatban nem sokat ér, valójában az ilyen módon validált blokkok kapcsán csak az kerül igazolásra, hogy egy másik – feltételezhetően becsületes – node minden bizonnyal jó munkát végzett… hiszen általában azt szokott végezni…

Konklúzió? Az Ethereum hálózat alapvetően bajban van, bár ez a baj dinamikusan jól kezelhető. Egyrészt a blokkonkénti gas limit talán még egy picit emelhető az uncle blokkok számának drasztikus növekedése nélkül is, másrészt pedig az Ethereum esetén egyáltalán nincs krízis a unconfirmed/pending transaction count miatt. A hálózat jól kezeli a bedugulásokat (sokkal jobban mint pl a Bitcoin). A lánc növekménye is relatív, valóban átléptük az 1TB-ot, sőt belátható időn belül el fogja érni a méret a 2TB-ot is, de ez a hálózat szereplőinek csak relatív kicsi hányadának okoz valós problémát. Ma teszt jelleggel kipróbáltam: geth-el (Go ethereum) light synccel egy átlagos internet kapcsolattal (és persze SSD-vel) megáldott gép kb 4-5 óra alatt boldogan tud syncelni, ez arra tökéletesen elég, hogy a saját gépeden tudd használni a Mistet/Ethereum Walletet, sőt a diszken sem foglal a sync után többet mint 0.5GB. Az pedig, hogy egyre nagyobb luxus full synced archiv nodet futtatni… nos a jelek szerint egyre kevésbé érdekel bárki is. Már persze ez az érdektelenség csak ideig óráig tartható fenn, hiszen ezen nodeok nagyon fontos részét képezik az ökoszisztémának. Ha Vitaliknak lesz igaza (és nyilván dolgozni fog azon, hogy így legyen), akkor ez a probléma is teljesen el fog tűnni a shardinggal, hiszen a shardingnak köszönhetően okafogyottá válik a fully synced archive node szükségessége. Persze ez utóbbira még minimum egy évet kell várni… Az óra pedig ketyeg. Az Ethereum dev csapata véleményem szerint most ugyanazt akarja eljátszani, amit majd egy éve a Bitcoin dev csapata játszott el:

Nem veszünk tudomást az akut problémáról és rohanunk előre, azt a kis időt pedig csak kibírják a felhasználók

A különbség talán csak annyi, hogy míg a Bitcoin könnyedén tudott egy rövid időre rebrandelődni egyfajta Store of Valuevá, addig az Ethereumnak erre nem igazán lesz lehetősége. Ma még ki lehet hozni egy komplexebb smart contract deployt 1 Ether körül, de ha ez az érték olyan drasztikus emelkedő pályára fog állni, mint ami tavaly történt a Bitcoin mining feek kapcsán, akkor működő tokenmodellek százai omolhatnak össze. Mára a kvázi sztenderdé vált 10-11 Gwei körüli gaspricet mindenki elfogadja, de koránt sem lesz ekkora kitörő öröm a tömegek arcán, ha az icok, a macskák és a robotok miatt ez az érték elkezd drasztikusan emelkedni. Márpedig érdemi tartalékkal nem rendelkezik a hálózat és ezt maga Vitalik is elismeri.

Fast sync datadir growth has flatlined at 10GB per monthfor the last six months and it’s not going to go much higher, if only because increasing the gaslimit much further would lead to uncle rate centralization issues. So we *already are* experiencing the worst of it and have been for half a year.

Final konklúzió 2.0: Aki az idei évben nagyobb smartcontractot kíván deployolni Ethereumra (pl. ERC20 tokent) az baromira húzzon bele és minél hamarabb készítsen össze mindent, mert félő, hogy ennek a költsége az év második felében drasztikusan emelkedhet. Csapatommal, mi is így teszünk az ILK token kapcsán!