Egy pénteki teleconfon került elő a címben szereplő kérdés. Mivel ott sem időm, sem lehetőségem nem volt erre válaszolni, ezért gondoltam keyboardot ragadok. Amúgy is időszerű egy ilyen témáról írni, hiszen régen volt már tech jellegű cikk a blogon.
Az alap kérdés egyébként nem is az volt, hogy mennyi Bitcoin node létezik, hanem az, hogy honnan tudjuk pl. egy Ethereum hard forknál, hogy a fullnodeok mekkora arányban alkalmazzák már az új konszenzus protokollt, illetve, hogy vajon egy hard fork milyen mértékben érinti negatívan az adott hálózat védettségét azáltal, hogy régebbi nodeok tömege kerül out-of-syncbe.
Az első node kérdése
Maguk a kérdések alapvetően jogosak, hisz mint az Ethereum, mind a Bitcoin egy peer-to-peer hálózat, így logikusan nincs olyan központi nyilvántartás, ahol meg lehetne tekinteni a nodeok állapotát, verzióját, stb.
Azonban a peer-to-peer lényege, hogy ismerünk peereket. Márpedig egy bitcoin kliens indításakor bizony nem feltételezhető az, hogy ezzel az információval rendelkezünk alapból. Így mindig trükkös kérdés, hogy vajon hogyan találjuk meg a több full nodeot.
Kis történelmi kitekintés: Eredendően a Bitcoin erre a célja az IRC protokollt használta hasonlóan. Bár tartok tőle, hogy az olvasók nagy részének nem túl sok fogalma van az IRC-ről, de a 90-es évek végén ez volt a legnépszerűbb chat kliense az akkori ébredező Internet generációnak.
A bitcoind indításakor automatikusan csatlakozott az egyik IRC szerverre és onnan gyűjtötte össze a magukat hírdető peerek adatait. Azonban az IRC protokoll háttérbe szorulásával és a szerverek lelövésével ez a metódus egyre inkább háttérbe szorult és 2013-ban az IRCSeed support hivatalosan is kikerült a Bitcoin kliensből.
A korai időszakban a Bitcoin Core kódbázis fixen rögzített nagy bizonyossággal elérhető full nodeokat tartalmazott. Ennek a kódját és a korai seed szerverek elérhetőségét még Satoshi rakta bele a kódba.
Hogy működik
A domain nevekből látható, hogy ezek a bitcoin core fejlesztők kezében lévő domainek (theBlueMatt, DashJr, Sipa, Jonas Schnelli, Peter Todd). Ezek a DNS-ek úgy működnek, hogy átlagosan 30-40 full node ip címét adják vissza, ám a konkrét lista folyamatosan változik. Tehát 24 óra alatt akár több ezer garantáltan működőképes full node ip címét is ki lehet nyerni ezzel a módszerrel.
Oké, de honnan lehet tudni, hogy mennyi van?
Maga a Bitcoin protokoll úgy lett kialakítva, hogy a nodeok a lehető legnagyobb biztonsággal működjenek, minek érdekében folyamatosan több tucat másik full nodedal tartják a kapcsolatot és kapják meg a legfrissebb chain stateket és frissítik a mempool információikat a függőben lévő tranzakciókról.
Amikor egy full node kapcsolódik egy másik full nodehoz, akkor “bemutatkozik”. Közli a saját verzióját. Ergo, ha kellően sok full nodeod van a hálózaton, amik ráadásul még esetleg prioritással is rendelkeznek a dns seedekben, akkor nagy valószínűséggel egy idő után az összes full node kapcsolódni fog hozzád, így szépen lassan kialakul egy képed arról, hogy mennyi full node létezik és hol milyen verzió fut.
Ezt a módszert alkalmazza a Luke DashJr féle DNS seed discovery tool is.
Akkor mennyi is van pontosan?
Teljesen pontos számot nem lehet tudni, de a DNS seedeken keresztül felfedezhető nodeok száma Bitcoin esetén valahol 70-80.000 körül lehet.
Ebből közelítőleg 10.000 fullnode “listening” típusú. Ezzel kapcsolatban is vannak ám félreértések. A listening nem azt jelenti, hogy csak hallgatózik a hálózaton és nem alkalmas full nodeként működni, hanem azt, hogy ezek nyílt internetről elérhetők. Azaz tcp/8333 porton keresztül megszólítható az adott full node.
Mi a helyzet a Ethereummal?
Természetesen, mint majd minden esetben; az Ethereum ezt is másképpen csinálja. A Ethereum referencia implementációja (a geth) a bootnode megközelítésre esküszik. Ennek lényege, hogy a geth indításakor meg kellene adni minden esetben egy ismert nodeot, amiről lehetne elkérni néhány peer adatait. Mivel ezt az esetek többségében nem adja meg senki, ezért mind a geth, mind a parity nodeok tartalmaznak néhány beégetett bootnodeot, melyeken keresztül ez végrehajtódhat. Ezek a nodeok a geth esetén egyébként az Ethereum Foundation saját – erre a célra fenntartott – nodejai. Emellett az Ethereum rendelkezik egy saját Network Discovery Protokollal, amin keresztül képes full nodeokat keresni.
Mivel az Ethereum (geth és parity) esetén a bootnode protokoll sokkal centralizáltabb így még könnyebben lehet megállapítani, hogy megközelítőleg mennyi és milyen verziót futtató full node létezhet. Az ethernodes.org felmérése szerint egyébként közel 7200 ethereum full node létezhet, melynek egyre nagyobb része már az ethereum foundation referencia kliensét a geth-et futtatja. Ez a tendencia a jövőben egyre inkább növekedni fog, mivel a parity fél-hivatalosan is elkezdte feladni az Ethereum 1.0 kliensének a fejlesztését, helyett a Ethereum 2.0-ra és a saját PolkaDot projektjére koncentrál.
A témával kapcsolatban az jutott még eszembe, hogy egy 51%-os támadásnak hardfork esetén lényegesen nagyobb lehet a valószínűsége, mivel biztosan vannak minerek/fullnode-ok, amik nincsenek lefrissítve időben. Pláne, ha kéthetente kell mindezt megtenni, mert mondjuk elfelejtik növelni a difficulty bombot. 😉
Lássuk be ennek az esélye igen kicsi. Addig amíg egy volunteer full node üzemeltető esetleg benéz vagy átalszik egy hard forkot, addig egy olyan miner full node üzemeltető, akinek egyébként ez adja a fő üzleti bevételét, szóval tőle akár az is elvárható lenne, hogy hetente fel legyen készülve egy hardforkra.
A bányászattal nem foglalkozó full nodeok összességében semmit sem befolyásolnak. Nincs hatásuk sem a difficultyra, sem pedig a hálózat védelmére pl egy 51% attack ellen.
Mining nélküli full nodeok futtatására két ésszerű oka lehet bárkinek is:
– Közvetlenül dolgozza fel a blockokat. Lásd pl egy block explorer, elemző cucc, akiknek nem elég pl egy infura szerű funkció, mert kell nekik a trade log is.
– Közvetlenül akarnak ellenőrizni tranzakciókat, mert üzletileg vagy paranoia okból kifolyólag egyetlen másik full nodeban sem bíznak meg. Ez utóbbi tipikusan azoknál játszik, akik pl. ügyfél balanceokat tartanak nyilván (pl. exchangek, custodial walletek, vagy egyéb kriptora épülő szolgáltatók. lásd pl. INLOCK)
Mindkét esetben igaz, hogy szintén elemi érdeke a fullnode fenntartójának, hogy fel legyen készülve egy-egy hard forkra.
Emellett persze számtalan – jellemzően ideológiai – okot lehet még felhozni, hogy miért van értelme futtatni saját full nodeot… De ezek nagy része valójában inkább csak destabilizálja a hálózatot. Különösen az olyan hálózatokat mint pl az Ethereum, ahol a tranzakció broadcast és block propagation eléggé késélen táncol a gyorsan pörgő blokkok miatt.
Hardforkról jut eszembe: volt, aki panaszolta, hogy a követekző Eth forkot miért pont jan. 1-re tették (amikor mindenki másnapos 😛 )… Persze azt nem percre, hanem blokkszámra ütemezik, az időt csak becsülni lehet.
https://twitter.com/peter_szilagyi/status/1209100969268645888
kis technikai kiegeszites: a fixed seedek most is vannak (eleg sok):
https://github.com/bitcoin/bitcoin/blob/master/src/chainparamsseeds.h
egy full node le tudja kerdezni egy masik node alltal ismert ipket, majd ezekhez kapcsolodva:
– tudja hogy az adott ip el-e meg
– onnan is uj ipket kerhet le
nyilvan a tuzfal/router mogotti node-okra nem tud csatlakozni.
es ha jol emlekszem mintha lenne relayonly node kod is valahol: ez csak tovabbitja a block/tranzakcio adatokat (ofc ellenorzes utan), de nem tarolja azokat.
illetve a blockchain.info uzemeltet speciallis nodeokat (asszem ezek is csak relayek), ezekhez lehet kapcsolodni is. ha eleg sok ilyen node van szerte a vilagban, akkor eleg nagy valoszinuseggel fog egy random qt/daemon/akarmi wallet egy ilyen nodehoz kapcsolodni, igy nekik pontos kepuk van a tenyleges node szamrol. (mellesleg innen tudjak hogy egy txet melyik iprol kuldetek: amelyik sajat node eloszor megkapja a tranzakcio adatokat, az tudja a kuldo ipjet)
“Hogy működik mindez ma? A Bitcoin esetén az ultimate megoldás a DNS seed support. Be van a kódba égetve 6 darab domainnév, ezek: bitcoin.sipa.be, dnsseed.bluematt.me, dnsseed.bitcoin.dashjr.org, seed.bitcoinstats.com, seed.btc.petertodd.org, bitcoin.jonasschnelli.ch
A domain nevekből látható, hogy ezek a bitcoin core fejlesztők kezében lévő domainek (theBlueMatt, DashJr, Sipa, Jonas Schnelli, Peter Todd). Ezek a DNS-ek úgy működnek, hogy átlagosan 30-40 full node ip címét adják vissza, ám a konkrét lista folyamatosan változik. Tehát 24 óra alatt akár több ezer garantáltan működőképes full node ip címét is ki lehet nyerni ezzel a módszerrel.”
Ez nem SPOF egy kicsit, vagy tul centralizalt az iranyitas? Mi van abban a helyzetben ha tegyuk fel a 6db core fejleszto egyszerre dont ugy, hogy leveri az adott hardcoded domaineket? Hogy garantalt az, hogy ezzel nem benitjak meg a bitcoint es teszik tonkre a halozatot ?
Ez az attack vectort semmiképpen nem nevezném potenciális single point of failure-nek, hiszen ehhez mind a 6 root dns-t kompromittálni kellene, szóval ez inkáb 6 point of failure lenne, amire nem igazán szokás készülni. Mindezektől függetlenül, ha ez mégis megtörténne, akkor:
– a root dns kizárólag akkor releváns, ha a node totálisan nulláról indul, minden más esetben el vannak tárolva a korábbi peerek és azokhoz fordul.
– ha mégis előfordulna, hogy egyik root dns sem válaszol, akkor pedig – ahogy erre előző kommentben Elbandi felhívta a figyelmem – el van tárolva a kódban több mint 100 full node elérhetőség, beleérve ipv6-os és tor-on keresztül elérhető stabil végpontokkal.
FYI: DNS hijacking
Ismerem az alapvető attack vektorokat, így a dns hijackinget is. De azon túl, hogy jól hangzik mégis hogyan képzeled el egy bitcoin root dns kapcsán a DNS hijackinget mit támadási vektort?
(1) Tegyük fel elnyeled az összes root dns rekordot, akkor sincs semmi csoda, az összes új node, ami tőled kéri el a dns-t, az megy az előre rögzített seedek felé.
(2) Preparálod a root seed dns válaszokat, hogy ne a valódi nodeok felé menjenek hanem mondjuk egy általad létrehozott manipulált full nodera, amiben nincs egy darab block sem, vagy max csak néhány tucat van. És ezzel mit érsz el? Azt, hogy néhány nulláról syncelt node hülyeséget fog tartalmazni? Nem nagy ügy.
(3) Preparálod a root seed dns válaszokat, hogy ne a valódi nodeok felé menjenek hanem mondjuk egy általad létrehozott manipulált full nodera, ami fullra van syncelve és akkor mi van? Annak az esélye, hogy te valaha ki tudod számolni akár csak egy blokknak a hashét is az ma már erősen közelít a nullához egy “magunkfajta” haladó számára. De ha még mondjuk valamilyen istenverte szerencsével vagy brutális mennyiségű pénz belepumpálásával el is tudod érni, hogy kiszámolj egy új blockot, akkor is mi van? Egyrészt ez biztosan nem fog neked sikerülni 10 perc alatt, de talán még napok alatt sem. Addig a hijackelt node üzemeltetőjének minden bizonnyal feltűnik, hogy valami nincs rendben és ha csak egyetlen full nodeot is elér rajtad, akkor is már érvényelül a longest-chain elv és semmit sem érték a preparált kamu blokkoddal. Arról nem is beszélve, ha valami istenverte csodával mégis tudnál longest chaint csinálni, akkor mégis mit írnál bele? Milyen tranzakciókal? Max csak olyan pénzt tudsz mozgatni, amivel amúgy is rendelkeztél, ellentétben az input signature invalid lesz.
Szóval értem én hogy jól hangzik bedobni egy DNS hijacket, de ezen túlmenően mégis mit érsz el vele a konkrét esetben? A DNS hijacking legjobb szándékkal is csak nagyon lokális szinten tud működni, leginkább ISP szinten. Ezt biztos nem nevezném SPOF attack vectornak a bitcoin hálózat szempontjából.
Ha esetleg mégis valamilyen egyéb scenariot kihagytam volna a DNS hijacking kapcsán, akkor hozz képbe kérlek.
Csak azt akartam mondani, hogy állami szinten a boot megakasztható.
Ahhoz minimum az összes előre rögzített full nodeot elérését is blockolni kellene. Persze nem kizárt, de ha ez meg is történne valaha, akkor sem tud teljes szintű lenni a lezárás, hiszen kézzel is meg tudsz adni peer nodeot, nem is beszélve bitcoin esetén ugye a satelite syncről. Kevés olyan internetes technológiát tudok ma elképzelni, aminek a lokális (országszintű) ellehetetlenítéséhez több erőforrást kéne mozgósítani, mint a bitcoin esetében. Mondjuk konkrétan egyet sem tudnék mondani.