| | | | | Mottó:
Jól csak a szívével lát az ember.
Ami igazán lényeges,
az a szemnek láthatatlan.
/Antoine de Saint-Exupéry:
A kis herceg/ | | 2022. május 4. | | | | | Blockchain: NFT, ETHereum, METAverzum | | | | | | Virtuális világban, virtuális pénzzel, virtuális sört lehet virtuálisan ízlelgetni, a virtuális Heineken Silver révén, 2022-03-17 óta, a Decentraland nevű metaverzumban (ami egyike a néhány metaverzumnak, mint a Facebook Horizon Worlds, a Somnium Space, a The SandBox, a The Nemesis vagy a Cryptovoxels). A metaverzumokhoz hasonló játékok, a 3D-s - Minecraft vagy The Sims 4 jellegű - VR (Virtual Reality) világok jelenleg is népszerűek, amelyekben akár nagyobb csomagokat (világokat, kiegészítőket, küldetéseket), akár kisebb dolgokat, tárgyakat - pl. World of Warcraft esetében fegyvereket, páncélokat - lehet venni micropayment tranzakciók révén, amik egyedi ügyféligényeket elégítenek ki, testreszabják a karaktereket. Az élmény szempontjából pedig úgy tűnik, hogy a felhasználók számára a virtuális tapasztalatok sok területen helyettesíthetik a valós tapasztalatokat, bár Steven Spielberg filmje (Ready Player One, 2018) pont azt emeli ki - végletekig leegyszerűsített érvként -, hogy "bármennyire is rettenetes tud lenni a valóság, mégis az az egyetlen hely, ahol lehet egy jót enni" (és inni), ezért "kedden és csütörtökön zárva tart az OASIS, [...] az embereknek többet kell a valóságban lenniük, mert [...] a valóság az egyetlen dolog, ami valódi". Ha viszont a felhasználók számára ennyire egymást helyettesítő termékké válik a valós- és virtuális világ, akkor kérdés, hogy fel kell-e még egyáltalán tenni a kérdést, ami Platóntól Morpheusig sokszor elhangzott: "Mi a valóság? Hogy határoznád meg? Mivel?" (Mátrix, 1999).
A virtuális pénz is lehet alternatívája a valós pénznek, készpénznek, sőt, egészen sokféle és eltérő szempontról lehet hallani a használata kapcsán (a befektetési célú használattól eltekintve is): van, ahol a bankjegyhamisítás visszaszorítása a cél a virtualizálással, máshol a gyors nemzetközi pénzmozgás miatt van terítéken a bevezetése, de pl. Kínában a tranzakciók átláthatósága fontos, míg Svédországban a minimális készpénzállomány miatt erős a függőség a bankkártya-társaságoktól (VISA, MasterCard), így azok mellé szeretnének egy virtuális, állami megoldást is bevezetni (backup gyanánt). A crypto currency témakörből a Bitcoin (BTC) tranzakciók és blokkláncok felépítésével már foglalkoztam (ld. korábbi Bitcoin - Aprópénz? bejegyzést), ezúttal az Ethereum (ETH) adatstruktúrákat néztem meg jobban, hiszen a metaverzumos világok többsége erre alapoz a virtuális fizetőeszközöknél (FT) vagy a smart contract révén megvásárolt dolgoknál (NFT).
A virtuális pénztárcánkba kerülhetnek "hagyományos", tömegesen előállított (pl. bányászott) virtuális pénzérmék is, illetve egyedi (pl. sorszámmal ellátott) pénzérmék, tárgyak, tokenek is (pl. a World of Warcraft világában egy olyan kilencélű kard, aminek a pengéjére a saját nevem van gravírozva). Az előbbiek esetében a pénzérmék között nincs különbség - mindegy, hogy Pista vagy Béla adta nekem az 5 Ft-os érméjét, a lényeg, hogy van nálam egy 5 Ft-os érme -, azaz azok helyettesíthetők (fungible token, FT), az utóbbiaknál viszont ez nincs így - hiszen nem mindegy, hogy kinek a neve van gravírozva a kilencélű kard pengéjére -, azaz azok nem helyettesíthetők (non-fungible token, NFT).
Az alábbiakban nem lesz szó befektetési tanácsokról, árfolyammozgások mögötti okokról, új érmék vagy tranzakciók jóváhagyásához szükséges döntési mechanizmusokról (Proof-of-Work vs. Proof-of-Stake), viszont megnézzük bit szinten - egy-egy valós blokk, tranzakció, NFT alapján - az adatstruktúrákat, hogy egészen pontosan mit és hogy fednek le a kriptográfiai adatok (pl. hash), miért lehet az Ethereum (ETH) az alapja egy smart contract megoldásnak vagy CBDC (Central Bank Digital Currency) rendszernek.
FT (fungible token)
Az elemzéshez ki kell választani egy blokkot a rendszerben! A tranzakciókat tároló blokk meghivatkozása sorszám (number) vagy lenyomat (hash) alapján:- /data/.../decoded_raw_block/number
(0x23cace = 2345678) - /data/.../decoded_raw_block/hash
(0xda214d1b1d458e7ae0e626b69a52a59d19762c51a53ff64813c4d31256282fdf)
A /data/.../decoded_raw_block/transactions elemben szerepelnek a tranzakciók a lenyomatukkal (hash) meghivatkozva (pl. 0x0c79e3ae36150eb36d6a631cc8d6250db4b9b832a82ac58ea356357f5987debe).
Az elemzéshez ki kell választani egy tranzakciót a blokkból! A tranzakciós adatokat tároló tranzakció meghivatkozása lenyomat (hash) alapján:- /data/...
(0x0c79e3ae36150eb36d6a631cc8d6250db4b9b832a82ac58ea356357f5987debe)
A /data/.../raw_transaction elemben szerepelnek a tranzakciós adatok.
Az elemzéshez fel kell dolgozni a tranzakciós adatokat a tranzakcióból! A tranzakciós adatok között szerepel, hogy kitől (/from), kinek (/to), mi (/value/hex 0x0e0c8912851e356c összegű pénz, viszont a /data értéke 0x, azaz NULL) kerül átadásra.
NFT (non-fungible token)
Az elemzéshez ki kell választani egy blokkot a rendszerben! A tranzakciókat tároló blokk meghivatkozása sorszám (number) vagy lenyomat (hash) alapján:- /data/.../decoded_raw_block/number
(0xabade2 = 11251170) - /data/.../decoded_raw_block/hash
(0xf6e2ef3d39186079e62dd0d9c78ff576a5c5ab82c1fe4c2df63e69a6c23143fc)
A /data/.../decoded_raw_block/transactions elemben szerepelnek a tranzakciók a lenyomatukkal (hash) meghivatkozva (pl. 0x7eac0efd1296d58c1133b1bcba1a85fc5edf6404cc00c1d389e7dbeaafc4fa92).
Az elemzéshez ki kell választani egy tranzakciót a blokkból! A tranzakciós adatokat tároló tranzakció meghivatkozása lenyomat (hash) alapján:- /data/...
(0x7eac0efd1296d58c1133b1bcba1a85fc5edf6404cc00c1d389e7dbeaafc4fa92)
A /data/.../raw_transaction elemben szerepelnek a tranzakciós adatok.
Az elemzéshez fel kell dolgozni a tranzakciós adatokat a tranzakcióból! A tranzakciós adatok között szerepel, hogy kitől (/from), kinek (/to, ami NFT mint() esetében a smart contract azonosítója), mi (/value/hex 0x00 összegű pénz, viszont a /data értéke összetett, további feldolgozást igényel) kerül átadásra.
A /data a művelet típusát (pl. mint() vagy transferFrom() függvényhívás), illetve a művelet paramétereit (pl. mint() esetén a token azonosítója, digitális aláírás értéke, eladó/küldő azonosítója, token metadata elérhetősége, illetve transferFrom() esetén az eladó/küldő azonosítója, vevő/fogadó azonosítója, token azonosítója) tartalmazza. A mint() esetén a token metadata elérhetősége egy URL, ahol egy JSON adathalmaz érhető el, ami a token (pl. kép) paramétereit (neve, leírása, elérhetősége) tartalmazza.
Az elemzéshez fel kell dolgozni a token metadata állományt a tranzakciós adatokból! A token metadata állományban szerepel az adott token (pl. kép) neve (/name), leírása (/description), elérhetősége (/image és /external_url), illetve esetleges egyéb attribútumai (/attributes).
A token metadata, illetve maga a token (pl. kép) elérhetősége, az URL viszont nem csak ezek helyét, hanem a lenyomatát (hash) is megadja, azaz kriptográfiai értelemben biztosított az end-to-end védettség. A lenyomat képzése (hash) azonban nem annyira egyszerű, ugyanis a háttérben az állományok darabokra (chunk) tördelve kerülnek tárolásra az IPFS (InterPlanetary File System) decentralizált tárhelyen (ami felett több, úgy nevezett IPFS pinning service is futhat, mint pl. Pinata), majd ezen darabokból képzett Merkle-tree hash-fa alapján kerül kiszámításra a UnixFS-alapú (Unix File System) DAG (Directed Acyclic Graph) adatstruktúrán a CID (Content IDentifier) specifikáció szerinti lenyomat (hash) érték. Ennek a lenyomatnak a base58 kódolt formája kerül a token metadata vagy token (pl. kép) elérhetőségét megadó URL-be. (Az alábbi képeken egy egyszerűbb - egy darabkából álló - eset látható, a file tartalma mindössze a "test" string volt.)
Az FT (fungible token) és NFT (non-fungible token) adatstruktúrák tulajdonságait egymás mellé téve látszik, hogy a fontos különbség a tranzakciós adatoknál van, ahol tetszőleges műveleteket, függvényhívásokat is le lehet írni (ld. /data ahol a művelet típusa lehet pl. mint() vagy transferFrom() függvényhívás), ezért lehetséges, hogy az Ethereum (ETH) nem csak crypto currency megoldásként használható, mint a Bitcoin (BTC), hanem általánosabb dolgokat, akár egy smart contract logikát is bele lehet képzelni.
Kriptográfiai rétegek
A kriptográfiai rétegeket elemezgetve látszik, hogy a blokk, illetve a blokkban tárolt tranzakció létrehozása és feldolgozása hasonló kriptográfiai műveletek elvégzését igényli: különböző lenyomatokat (hash) kell kiszámolni, illetve digitális aláírásokat kell létrehozni/ellenőrizni. A lenyomatok és digitális aláírások lefedettségének és sorrendiségének értelmezése szükséges ahhoz, hogy egyértelmű lehessen, hogy mely adatok milyen módon vannak védve.
A legtöbb esetben az adatok egy RLP (Recursive Length Prefix) transzformáción esnek át és csak utána kerülnek végrehajtásra a kriptográfiai műveletek (pl. lenyomatképzés). Az RLP specifikációja (https://eth.wiki/fundamentals/rlp) nagyon hasonlít a kriptográfiai világban is széles körben használt ASN.1 (Abstract Syntax Notation One) szabványra, ahol a TLV (Type/Tag-Length-Value) adathármassal írnak le egy-egy elemet, azonban az RLP esetében a TL (Type/Tag-Length) egybeolvad.
A tranzakcióban (feldolgozott raw_transaction elemben) található digitális aláírás (signature), illetve eladó/küldő adatra való visszavezetés (public key recovery) értelmezése: Az alább felsorolt adatok, a megadott sorrendben kerülnek összefűzésre, RLP-kódolásra, lenyomatolásra. Az adathalmazból látszik, hogy ez visszavezethető az eladó/küldő (from) értékére (0xea674fdde714fd979de3edf0f56aa9716b898ec8).- nonce
- gasPrice
- gasLimit
- to
- value
- data
A tranzakcióban (feldolgozott raw_transaction elemben) található lenyomat (hash) értelmezése: Az alább felsorolt adatok, a megadott sorrendben kerülnek összefűzésre, RLP-kódolásra, lenyomatolásra. Az adathalmazból látszik, hogy ez (0x0c79e3ae36150eb36d6a631cc8d6250db4b9b832a82ac58ea356357f5987debe) lefedi, azaz védi az eladó/küldő (from), vevő/fogadó (to), összeg (value), egyéb adat (data) és a digitális aláírás (v, r, s) értéket is.- nonce
- gasPrice
- gasLimit
- to
- value
- data
- v
- r
- s
A blokkban található lenyomat (hash) értelmezése: Az alább felsorolt adatok, a megadott sorrendben kerülnek összefűzésre, RLP-kódolásra, lenyomatolásra. Az adathalmazból látszik, hogy ez (0xda214d1b1d458e7ae0e626b69a52a59d19762c51a53ff64813c4d31256282fdf) lefedi, azaz védi többek közt a tranzakciók lenyomatait (transactionsRoot hash, Merkle-Patricia-tree) és a Proof-of-Work (integer) értéket (nonce) is.- parentHash
- sha3Uncles
- miner
- stateRoot
- transactionsRoot
- receiptsRoot
- logsBloom
- difficulty
- number
- gasLimit
- gasUsed
- timestamp
- extraData
- mixHash
- nonce
Az Ethereum (ETH) indulása óta a Proof-of-Work döntési mechanizmust (consensus mechanism) támogatta, de a 2022. évi váltással a Proof-of-Stake módszerre (amihez közeli a Proof-of-Authority is) már nem a számítási kapacitás alapján korlátozza egy felhasználó "hatalmát", hanem néhány kitüntetett entitásnak ad jóváhagyási jogosultságot (pl. a birtokolt pénz mennyiségétől, vagy jegybanki szerepkörtől függően, ld. CBDC témakör). A döntési mechanizmus változása az adatstruktúrákban is okoz módosulást, hiszen több paraméter feleslegessé válik (pl. difficulty). A fejlemény egyszerűsödést is jelent, de az Ethereum (ETH) még így is komplex, sok időt igényel a működés megismerése és alkalmazások ráépítése. Márpedig a rendszer teljes és pontos ismerete nélkül hibatűrő, kritikus infrastruktúrában működő kódok faragása nehéz... A kriptográfia helyes alkalmazása önmagában is igényel már extra szakértelmet a fejlesztőknél, nem véletlen, hogy katonai IT rendszereknél annak idején irányadó volt a KISS (Keep It Simple, Stupid) szemlélet. Hát, ez a crypto currency világ nem ilyen...
Kapcsolódó anyagok:
| | | vissza | | | | | |
|
