Orosz rulett Ethereum módra

A történelem ismétli önmagát. Miközben a Bitcoin kapcsán már megnyugodni látszanak a kedélyek a skálázási vita kapcsán (nem… nem oldódott meg semmi, csak már kevésbé érdekel bárki is a vita, mindenki beletörődött, hogy ez van; ezzel kell élni)… szóval aközben most az Ethereum háza táján zajlik valami nagyon hasonló történet. Kisebb belső háború folyik éppen a bányászok és a core fejlesztők között, mely persze sok szempontból mondvacsinált, de mégis csak sok az áthallás:

  • A minerek növelni akarják a blokkokat, ezáltal csökkentve a hálózat terhelését, ami implicit csökkentené a költségeket, de valójában csak a bányászok anyagi hasznát hajtja fel azáltal, hogy sokkal több tranzakció tud átmenni.
  • A core fejlesztők (élükön Szilányi Péterrel) viszont több szempontból is kifakadnak, mivel a bővítés miatt tovább növekedik a full nodeok erőforrás igénye, ami szükségképpen a centralizáció felé vezet. Ráadásul a növelés lassítja a full nodeok feldolgozását, ami miatt növekedni fog az orphan blokkok aránya is.

Eléggé dejá vu szituáció…

A dolognak talán egyetlen szépséghibája, hogy míg Bitcoin esetén ebből a kérdésből valóban egy nagyon komoly belső polgárháború lett (BIP-148 aktiváció vs SegWit-2), addig ethereumon a minerek szépen zárt ajtók mögött megegyeztek és felcsavarták a blokkonkénti gaslimitet 10 millióról 12 millióra.

Hogy ez mennyire egy látszat megoldás volt csak, azt mi sem bizonyítja jobban, mint hogy az átállás óta ugyanúgy tele vannak a nagyobb blokkok is, illetve az átlagos gasPrice továbbra is 25 és 40 gwei közül alakul szinte konstansan.

Persze ha a történetnek itt lenne vége, akkor nem írok róla külön bejegyzést. De a helyezet ennél kacifántosabb. Ahogy szokott lenni, Vitaliknak általában van egy jó ötlete, amivel a problémát meg lehet kerülni vagy újraértelmezni:

EIP-1559 – A megoldás(?)

Idén április 13-án terjesztette be Vitalik, néhány további fejlesztővel közösen a 1559-es sorszámú Ethereum fejlesztési kezdeményezését. Ennek a célja alapjaiban újragondolni a teljes fee market modellt.

Jelenleg az Ether tranzakciók díja teljesen szabadáras és aukción dől el, hogy mely tranzakciók kerülnek blokkba és melyek maradnak a várakozási sorban. Bárki bármekkora feevel (gasPrice) be tud rakni bármilyen tranzakciót, annak reményében, hogy az előbb-utóbb blokkba kerül. A legtöbb tárca/kliens/node a szokásos költség saccolási metódust használja, aminek lényege, hogy az előző blokkokba került tranzakciók gasPrice értékét átlagolják és súlyozzák, majd az így keletkező értékre még ráraknak egy kicsit ha a blokk tele volt. Ez a megközelítéssel egyrészt az a baj, hogy nagyon könnyen az egekbe tud repülni a gasPrice, másrészt a minerek profitmaximalizálása miatt akár előfordulhat, hogy hibás becslések jönnek ki. Ennek negatív hatását valószínűleg már sokan megtapasztalták, amikor megpróbáltak “olcsón” elküldeni egy tranzakciót leterheltebb időszakban.

Mit is jelent pontosan ez a profitmaximalizálás miatt keletkező becslési hiba? A probléma alapja az, hogy egyszerűen a jelen idő alapján akarunk egy jövőbeli eseményre saccolni. Ez azt eredményezi, hogy amikor éppen hírtelen nagyon sok tranzakció tódul be a hálózatra, akkor alábecsülésre kerülnek a tranzakciós díjak, amikor viszont csökken a hálózat terhelése, akkor viszont a fee-k még nagyon sokáig magasan maradnak és csak lassan csökkennek. Előbbi probléma azt eredményezi, hogy nagyon sok tranzakció egyszerűen nem tud blokkba kerülni és beszorul a mempoolba hosszú időre. Utóbbi pedig azt, hogy gyakran 2-3x többet fizetnek egy-egy tranzakcióért, mint amennyit valóban kéne, hogy bekerüljön az a következő blokkba… ami explicit eredményezi, hogy a következő blokkba kerülő tranzakciók is sokkal drágábbak lesznek, mint ami indokolt lenne.

A EIP-1559 kezdeményezés a problémát a következőképpen hivatott orvosolni: bevezetésre kerül három újabb protokoll paraméter, ezek a: BASEFEE, GASPREMIUM és FEECAP.

Ezek közül a BASEFEE egy a hálózat által kiszámolt és nem módosítható érték. Alap értéke az 1 gwei, ami akkor növekszik, ha az előző blokk tele volt és akkor csökken, ha nem volt tele.

VARIANCE HUB OKTATÁSI CSOMAGOK!

Minden tranzakció küldésénél két paramétert lehet majd megadni: GASPREMIUM (kvázi a miner borravalója), illet a FEECAP, ami a maximum gwei-ben mért gasPrice, amit hajlandó a küldő kifizetni. Logikusan a GASPREMIUM értékének valahol 0 és “nem-túl-sok” között kéne lennie, míg a FEECAP-ot tudjuk úgy értelmezni és számolni, mint ahogy korábban a gasPrice-t számoltuk

Ezt követően a matek már egyszerű. A tranzakció gasPrice értéke a BASEFEE+GASPREMIUM lesz, de nem haladhatja meg a FEECAP-et.

GASPRICE = min(BASEFEE+GASPREMIUM , FEECAP)

Mit jelent ez a gyakorlatban:

JELENLEG, ha az jön ki a gasPrice becslésnél, hogy a tranzakció várható költsége mondjuk 52 gwei kell hogy legyen és bekerül az adott tranzakció a blokkba, akkor a miner zsebre rakja az 52 gwei*txgas jutalmat, függetlenül attól, hogy egyébként mondjuk 38 gweivel is bele fért volna az adott blokkba.

EIP-1559 aktiválása után: Legyen mondjuk a BASEFEE 20 gwei és mondjuk ajánljunk fel a minereknek +10 gwei borravalót (GASPREMIUM), de limitáljuk ezt maximum 50 gwei FEECAP-en. Ebben az esetben ha a soron következő blokkba bekerül a tranzakció, akkor annak a díja garantáltan 30 gwei lesz. Viszont ha mégsem kerülne be, akkor sincs pánik, mert a következő blokkra már a protokoll fentebb húzza a BASEFEE-t pl 21 gwei-re és amennyiben az így keletkező 31 gwei (BASEFEE+GASPREMIUM) ajánlatommal már beleférek a következő blokkba, akkor tutira benne is leszek, ráadásul tutira 31 gwei gasPrice tranzakciós költséggel… annak ellenére, hogy egyébként ez a tranzakció nekem akár 50 gwei-t is megért volna (FEECAP).

És akkor jöjjön a csavar

Az előző pontban bemutatott EIP-1559-es metódus alapvetően egyszerű és nagyszerű, de közismert, hogy egy ilyen modellnek, bizony meg kell állnia a helyét az olyan eltérő anyagi motivációkkal rendelkező komplex rendszerben is, mint az Ethereum. Hiszen jól látható, hogy a BASEFEE-t igazából könnyedén lehet manipulálni, ha folyamatosan be vannak tömve a blokkok és máris dől a lóvé a minerekhez.

Erre Vitalik és barátainak megoldása végtelenül egyszerű:

A BASEFEE minden esetben elégetésre kerül, tehát azt NEM írhatják jóvá maguknál a minerek jutalomként.

Ergo a minerek kizárólag a GASPREMIUM-ot tudják jóváírni bevételként. Ez – a fenti példánál maradva – azt jelenti, hogy bár az adott tranzakció tényleges költsége akár lehet 31 gwei is amikor blokkba kerül, de a miner akkor is csak a GASPREMIUM értékét (10 gwei) írhatja jóvá magánál bevételként. Ezzel gyakorlatilag jelentősen letörve a minerek előnyét a becslések és eszkalációk miatt elszabaduló bányász költségek kapcsán.

Valóban megoldja a problémákat?

Bár az EIP-1559 által előterjesztett módosítás elegáns, egyszerű és jól kezeli a problémát, de sajnos nem tudja teljesen kizárni a manipuláció lehetőségét a bányászok oldaláról. Egyrészt a minerek tudják manipulálni a BASEFEE-t. Ehhez csak annyi kell, hogy folyamatosan olyan blokkokat készítsenek, amelyek nincsennek tele (tehát nem kerül elfogyasztásra a teljes 12 milliós blokkonkénti gas limit). Így:

  • Egyrészt ki tudják kapcsolni a teljes BASEFEE modellt, ezáltal visszahozva a jelenlegihez hasonló aukciós fee modellt.
  • Másrészt mivel ehhez a blokkok nem lesznek tele, így amikor éppen felgyűlnek a pending tranzakciók, akkor azok méginkább nem fognak beleférni a blokkba és méginkább elszállnak az tranzakciós költségek.

Ehhez persze az kell, hogy a nagyobb bányászok (cirka 60%+) megegyezzen ebben a stratégiában. Sajnos az elmúlt években a Bitcoin esetén már bebizonyosodott, hogy a nagyobb bányász poolok hajlamosak ilyen jellegű háttérmegegyezéseket kötni.

A EIP-1559 egyértelműen vízválasztó lehet az Ethereum jövője kapcsán. Vagy tényleg jól sül el és a bányászok önös anyagi érdeke lehetetlenné teszi a manipulációt… ha mégsem így lesz, akkor még a mostaninál is durvább vadnyugati időszak várható a tranzakciós költségek kapcsán.

INLOCK - ezúttal legyél Te a Bank!
Bookmark the permalink.

6 Comments

  1. Segítenél értelmezni a BTC utalások ezen grafikonját ?
    https://bitcoinfees.earn.com/

    Én úgy gondolom, hogy mesterségesen van limitálva az utalások száma, mivel mindig „állnak sorba” , még véletlen se fogynak el a várakozók soha az évek során, és a másik véglet se alakul ki,hogy mondjuk egy hónapos sor legyen. (vagy a feldolgozást limitálják, vagy kamu utalásokat tesznek bele)
    Pl. egy éve is kb. ennyien álltak sorba, tehát egy év alatt pont annyit utaltak el ahány megbízást kaptak… (valahogy mégse érik magukat utol soha még véletlen se)
    Tehát úgy látom elég komoly „szakszervezetként” tömörülnek kartellbe a bányászok.
    Azt gondolnám, hogy elég lenne néhány sztrájktörő, aki taktikázás helyett egyszerűen csak a legdrágábbakat utalja el,( learatva a nagy hasznot) és nem válogat bele az olcsóbbakból mint mások, hogy felverjék az „azonnaliutalás” minimumárát.
    Nincsenek ilyen sztrájktörők? (elegen) Vagy rosszul gondolom?

    Másfelől ha a megbízók viselkednének összetartóan, és csak kétféle díjat lennének hajlandóak fizetni (néhány kivétel nem számítana) tehát 1 sat/byte akinek ráér, és 2 🙂 akinek sürgős, akkor a bányászok nem tudnának taktikázni.

    Vagy esetleg akár az a helyzet is előállhat, hogy egyszer csak úgy döntenek a bányászok, hogy önkényesen meghatároznak egy „brutál minimálárat” és a következő blokkba csak olyat raknak ami ezt teljesíti, valamint azokat amik nagyon régen várnak?
    Még egy kérdés: Hogyan lehet 0 fee-t beállítani? ( azok valahogy soha nem várakoznak…)
    Te hogy látod ezeket?

    • Nem kell ahhoz manipulálni semmit, hogy mindig legyen sor. Ha megnézel egy hónapos mempool ábrát (pl itt: https://jochen-hoenicke.de/queue/#0,30d), akkor láthatod, hogy igen sűrűn eljut a hálózat oda, hogy szinte teljesen kiürül a queue, de nullára csak akkor tudna kiürülni, ha egymást követően 2 blokk is totálisan üres lenne, ehhez arra lenne szükség, hogy egymást követő átlag 10 percben egyetlen bitcoin tranzakció se szűkellen. Ennek esélye mára eléggé kicsi. Látható, hogy a tranzakciók száma a középidő szerinti nulla óra és reggel 8, illetve a hétvégi napokon alacsony. Ennek fő oka, hogy ez már a távol-keleti piaczárás és az európai piacnyitás közötti időablak.

      A legtöbb node implementáció nem engedi, hogy beállíts 0 fee-t, ennek oka eléggé prózai: ha a bányászok befogadnák a nullás költségű tranzakciókat, akkor szét lehetne spamelni a hálózatot. Ennek ellenére, lehetséges úgy manipulálni a fullnode kódját, hogy mégis befogadjon 1 sat/byte alatti tranzakciót, sőt előfordul, hogy ilyeneket ki is bányásznak, bár elég ritkán. Fontos, hogy a tranzakció összerakásánál nem a sat/byte fee-t adod meg, hanem konkrétan a fee összegét. Tehát tudsz olyan tx-et gyártani, ahol a fee konkrétan 1 sat… tehát nem 1 sat/byte. Ezeket a különböző statisztikai oldalak, mint pl a bitcoinfees egyszerűen csak 0 sat/byte kategóriába rakják; ami nem jelent azt, hogy ezért ténylegesen NEM történt volna fee fizetés.

      Van egyébként egy historikus szabály, ami értelmében a nodeok befogadhatnak és ki is bányászhatnak nulla költséggel is tx-et, ennek feltételei:
      – a tx script ne legyen nagyobb 1000 bytenál
      – minden output legalább 0.01 BTC vagy nagyobb legyen
      – illetve van még egy kitétel a prioritásra, de ezt a feltételt tudtommal már egyetlen bányász sem alkalmazza.

  2. Hát Csabi,

    Le a kalappal, hogy ennyi időt beleteszel. Az INLOCK egy jó project!

    Minden, amit azon felül teszel. Az meg még jobb. Találkoztunk az elmúlt években, de az mindegy is. Építsd tovább a magyar crypto világot, jól csinálod!

    Csak ennyit akartam mondani.

    Valaki, mint Satoshi 🙂

  3. Pingback: Az Ethereum kissé lemaradt a DeFi tokenek mögött | Kripto Akadémia

  4. “Ehhez csak annyi kell, hogy folyamatosan olyan blokkokat készítsenek, amelyek nincsennek tele”

    Marhára nem értek az egészhez, de ilyen egyáltalán miért engedélyezett?! Minden blokk legyen feltöltve min. 95%-osan és kész. Aki ezt notóriusan megszegi, az keressen magának más munkát. Nem értem, miért nem építenek a rendszerbe fékeket. Persze ez normális, hiszen nem értek hozzá. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *