Runtime frissítések Polkadoton

A Polkadot tervezésekor a fejlesztők nagy hangsúlyt fektettek a láncok közötti interoperabilitás megalkotására, de nem csak ez kapott egyedüli kiemelt figyelmet.

Dr. Gavin Wood fő célkitűzései közé tartozott, hogy a Polkadot hálózatát ne csak egy évben néhány alkalommal lehessen lefrissíteni és ne csak a node üzemeltetői vehessenek részt ebben a folyamatban, hanem a token tulajdonosok is. Ebben az elgondolásban a DOT tokenek szavazati jogot képviselnek a hálózat irányításában, így a blokklánc sorsának eldöntése nem a validátorok kezében összpontosul, hanem a token tulajdonosok kezében, akik jóval többen vannak, mint a validátorok üzemeltetői.

E logika szerint végső soron a blokklánc irányítása egy jóval nagyobb és diverzebb összetételű embertömegnél összpontosul, mellyel a Polkadot protokolljának frissítései jóval decentralizáltabban és ezáltal demokratikusabban zajlanak le.

Mi a baj a hard forkokkal?

A Polkadot frissítései nem hard forkokkal történnek, mint más blokkláncok esetében, hanem egy sajátos logikájú technológiával, a Runtime frissítésekkel. Mielőtt még átbeszélnénk a Runtime frissítések logikáját, nézzük meg, hogy mi a baj a hard forkokkal!

Aki már néhány éve jelen van a crypto világban annak biztos nem kell megemlíteni, hogy milyen módon frissíthetőek a blokkláncok. A Polkadot Networkon kivül gyakorlatilag minden blokklánc hard forkok útján frissíti a hálózatát. Ekkor az adott blokkláncot üzemeltető bányászok/validátorok kb. egyidőben lefrissítik a szoftverüket egy új szoftverre, így a blokklánc a frissítés után az új szoftver paraméterei szerint kezdi el építeni a blokkokat.

Az előbb említett procedúrát azonban egyáltalán nem ilyen egyszerű a gyakorlatban kivitelezni. A világon decentralizáltan elszórt több ezer, vagy több tízezer node-ot lefrissíteni nem kis kihívás, ezeket az eseményeket legtöbbször a blokklánc fejlesztői szokták megszervezni, mely száz százalékban off-chain koordinációt igényel. Hard forkokat a mérhetetlenül nehézkes, nagyon körülményes és kétes kimenetelű természete miatt egy évben csak néhány alkalommal tudnak a fejlesztők levezényelni, így elmondhatjuk, hogy ezek az alkalmak csak elvétve, néhány havonta esedékesek. Ezenkívül a hard forkok egyik velejáró tulajdonsága, hogy meg van az esély arra, hogy nem az összes node frissíti le a szoftverét, így a node-ok közötti eddigi egyetemleges konszenzus a blokklánc állapotáról megoszlik, mely által a blokklánc nemes egyszerűséggel kettészakad. Egy ketté szakadt blokklánc azt eredményezi, hogy immáron már kettő egyetemleges blokkláncot futtatnak a két különböző szoftverrel rendelkező node-ok, így értelemszerűen mindkét blokkláncnak létrejön a saját egyedi tokenje.

Jellegzetes hard fork események

Emlékszel még a DAO hackre 2016-ból? Biztosan rémlik, hogy ekkor egy hard fork miatt kettészakították az Ethereum hálózatot és így létrejött az Ethereum mellett az Ethereum Classic. Hasonló hard fork jelenséget éltünk át nem régiben, pontosan 2022 őszén is. Ekkor az Ethereum Proof of Stake modellre történő átállásakor a bányászok miatt megmaradt a régi, eredeti Ethereum hálózat is, így ezzel ”létre jött” a sima ETH token mellett a régi blokkláncon az ETH PoW token is. Hasonlóképpen jöttek létre még évekkel ezelőtt az eredeti Bitcoin mellett a Bitcoin Gold és a Bitcoin Cash kriptovaluták is, a hard forkoknak ”köszönhetően”. A blokkláncok kettészakadásával azonban nem csak egy új token jön létre, hanem az adott blokkláncnak a felhasználói között is érdekellentétek alakulhatnak ki annak a kérdésnek az eldöntésekor, hogy melyik lánc valójában az ”igazi, egyetemleges” lánc.

Ha ma a Bitcoinra, vagy az Ethereumra tekintünk, úgy tűnhet, hogy ezek a hard forkok miatt keletkezett kettészakadások nem voltak nagy hatással ezekre a hálózatokra, de ez egy naiv kijelentés volna. Az, hogy mindkét hálózat ilyen nagy sikereket ért el a kettészakadások ellenére is még nem bizonyítja, hogy ezeknek a hálózatoknak a frissítése, tehát a blokkláncok korszerűsítésének folyamata hatékony lenne.

Összegzésül a hard forkok a következő problémákkal rendelkeznek:

1. Off-chain koordinációt igényel a fejlesztőktől és a node üzemeltetőktől

2. Lassú és igen nehézkes megszervezni, ezért ritkán lehet csak kivitelezni

3. A blokklánc sorsa nem a felhasználók, hanem a node üzemeltetők kezében van

4. Kétes kimenetelű, így magában rejti az eshetőséget, hogy a blokklánc kettészakad

5. A lánc kettészakadásával maga a közösség is kettészakadhat

Megoldás: On-chain governance rendszer és Runtime frissítések

Szóval hogyan kerüljük el, hogy a kedvenc blokkláncunk ne szakadhasson ketté a hard forkok ideje alatt és ne szakadjon vele együtt ketté a hálózat közössége? A Polkadot válasza erre egy nagyon szofisztikált on-chain governance rendszer, amiben minden egyes DOT token tulajdonos részt vehet, illetve egy technológiai áttörés, a Runtime frissítések alkalmazása.

On-chain governance rendszer

Minden rendszerben a döntéshozatal, tehát a kormányzás fő célja az adott rendszer egyes paramétereinek a módosítása. A nemzetállamok esetében ezen paraméterek változtatását új törvényekkel, vagy néhány kevésbé fejlett demokráciákban rendeletekkel végzik. A Polkadot esetében ezen paraméterek az on-chain adatok lennének, amelyeket modulonként lehet külön-külön frissíteni. A gyakorlatban az adott modul frissítése a blokklánc azon paramétereinek a frissítését jelenti, amely az adott modulhoz tartozik. Az egyes modulok paramétereinek megváltoztatását a DOT token holderek döntik el on-chain, tehát láncon alapuló szavazás útján. A döntéshozatalokban való részvételhez egy Polkadot tárcára és némi DOT tokenre van szükség. Amennyiben anyagi helyzetünk nem engedi meg, hogy nagy számú tokennel szavazhassunk a referendumokon, akkor lehetőség van időarányosan súlyozni a szavazati jogunkat, tehát ha több időre kötjük le DOT-jainkat, akkor 2x, 4x, ... de akár 6x többet ér a szavazati jogunk. Ha az adott runtime frissítésre a szavazáson résztvevők döntő többsége „Ay”-al, azaz Igennel szavaz, akkor a protokoll egy előre meghatározott blokkmagasságnál lefrissíti önmagát a későbbiekben vázolt Runtime frissítések elve szerint.

Amíg a javaslatokat és referendumokat a token tulajdonosok véglegesen megszavazzák, addig több időtényező, valamint on-chain társulás, illetve számos algoritmus formálhatja a szavazási eredmények végkimenetelét. A rendszer komplexitásához hozzátartozik a Technikai bizottság (Technical comittee), a Tanács (Council), illetve még két fontosabb algoritmus, amelyek az egyenlőbb döntéshozatalt szolgálják: a Phragmén választási algoritmus (Phragmen Election Algorithm), illetve az Adaptív kvórum torzító algoritmus (Adaptive Quorum Biasing) amely a szavazatok számához igazít egy ideális minimális részvételi számot.

A fentiekből is látszik, hogy a Polkadot governance rendszere igencsak összetett, így ennek a részleteit egy másik blogposztban fogom érinteni. Nekünk most legyen elég annyi, hogy a Polkadot moduljainak frissítéseit a token tulajdonosok diktálják on-chain szavazás útján, mindezt a https://polkadot.subsquare.io/ weboldalon.

Runtime frissítések:

Polkadoton a blokklánc kódját kisebb egységekre, ún. Pallet-ekre, vagy másnéven modulokra osztották. A teljesség igénye nélkül felsorolok néhányat belőlük:

A fenti modulok frissítését tudják a token tulajdonosok az eddigiekben részletezett módon megszavazni, de hogy lehetséges az, hogy nem a validátor üzemeltetőknek kell a szavazás kimenetele szerint lefrissíteni a validátor szoftverét egy újabb verzióra?

A Polkadot fejlesztői egészen egyszerű választ találtak erre: ahelyett, hogy a validátorokban helyeznék el a szoftvert, ami tartalmazza a blokklánc működési logikáját, inkább magába a blokkláncba integrálták azt. Tehát a validátorok a blokkláncban megtalálható működési logika szerint hagyják jóvá a blokkokat, nem pedig a saját hardverükre letöltött szoftver logikája szerint. Ezzel a megoldással a Polkadot blokkláncának kettészakítása nem lehetséges, így az is kizárt, hogy a jövőben találkozhatunk Polkadot Classic, vagy Polkadot 2.0, vagy esetleg Polkadot Gold blokkláncokkal és tokenekkel.

A Polkadot Runtime frissítéseinek köszönhetően a blokkláncot 2022-ben 15 alkalommal frissítették le, de a lánc létezése óta már több, mint 50 frissítést hajtottak végre rajta, mindezt bármiféle leállás nélkül, úgy, hogy nem, hogy a felhasználók, de még a validátor üzemeltetők sem vettek észre ezek közül a frissítések közül egyet sem!

Csak, hogy kontextusba helyezzük, ezt a számot az Ethereum 2022-ben 3 hard forkot, míg 2021-ben 4 hard forkot kapott. A nem blokklánc-világban kiadott frissítések közül az Apple 2022-ben összesen 16 iOS frissítést adott ki, így elmondhatjuk, hogy csak nem annyiszor frissítették le a Polkadotot 2022-ben, mint az iPhone-okat, ezzel is bizonyítva, hogy a Polkadot frissíthetősége megegyezik a hagyományos szoftverfrissítési ütemtervekkel. Ezenfelül nem csak a Polkadot élvezi a Runtime frissítések előnyeit, hanem az összes Substrate alapú blokklánc is. Minden Parachain és Parathread a Polkadot Runtime frissítésének elve szerint halad a korral és korszerűsíti magát, így ezáltal az egész Polkadot ökoszisztémában eddig több, mint 1000 fork nélküli Runtime frissítés ment végbe hibátlanul.

A leírtakkal kapcsolatban lenne néhány kérdésed? Hagyj üzenetet kommentben!

Készíts egy Polkadot tárcát a https://www.talisman.xyz/wallet segítségével, igényelj a Polkaverse leírása szerint egy kis a Energy-t és már mehet is a megosztás, like, komment!

Mindezt itt Polkaversen decentralizáltan ≈ szabadon.

Üdv: Viktor | Polkadot Ambassador

Felhasznált irodalom:

https://wiki.polkadot.network/docs/learn-governance

https://wiki.polkadot.network/docs/learn-runtime-upgrades

https://polkadot.network/blog/polkadot-2022-roundup