A Bitcoin maghálózata nagyon sok tranzakciót is gond nélkül kezelhet, amennyiben elkészül a csomópont-szoftver egy elosztott változata (ami nem is jelentene komolyabb technikai problémát).

Megjegyzés: akiket Dan Kaminsky ezen oldal témájával kapcsolatos kritikáira adott válaszok érdekelnek, az itt találhatja meg, amit keres.

Skálázhatósági célok

A VISA átlagosan 2.000 tranzakciót kezel másodpercenként, tehát a napi csúcs 4.000/másodperc körül lehet, azonban a rendszerük akár 10.000-et is elbír – amely kapacitásra szükségük is van az ünnepi szezon legzsúfoltabb pillanataiban, amikor akár 8.500-ra is rúghat a másodpercenkénti tranzakciók száma (t/s).

Ezzel szemben a PayPal átlagosan 4.000.000 tranzakciót kezel naponta, 46 t/S átlaggal és 100 t/s csúcsértékkel.

Határozzuk meg kezdeti célként a 4.000 t/s-t. Persze ha azt akarjuk, hogy a Bitcoin kezelje a világgazdaság valamennyi tranzakcióját, ide értve a készpénzes ügyleteket is, akkor ennél nyilván sokkal magasabb értékre lesz szükség, feltehetőleg több százezer t/s magasságban, valamint hatékony védelemre a DoS támadások ellen (ami miatt a VISA-nak például nem kell aggódnia), amely utóbbiból következően még sokkal magasabb csúcsértékeket is tudnunk kell kezelni. Ahhoz azonban, hogy legalább elvi síkon számolgathassunk egy kicsit, kell egy kiinduló érték, még ha azt egy kissé önkényesen is választjuk meg.

Jelenlegi korlátok

A Bitcoin hálózatát jelenleg mesterségesen korlátozzák 7 t/s-re annak érdekében, hogy az emberek ne fújják fel túl nagyra a blokkláncot még azelőtt, hogy a hálózat és a közösség felkészülhetne a nagyobb tranzakcióforgalom kezelésére. Amint azonban eltávolítják ezt a mesterséges korlátot, úgy máris jelentős mértékben meg lehet majd emelni a másodpercenkénti tranzakciókeretet.

CPU

A protokoll két részből áll. A csomópontok “inv” üzenetekkel jelzik egymás felé, ha új tranzakció érkezik hozzájuk. Ha a fogadó csomóponthoz még nem jutott el a szóban forgó új tranzakció, akkor lekéri azt egy getdata üzenettel.

A dolog igazán költséges része a kriptográfia és a tranzakciók ellenőrzése a blokklánccal. Egy tranzakció ECDSA-ellenőrzése nagyjából 3 ms-ot vesz igénybe egy modern Intel magon. A RIPEMD-160 106 MB/s-mal dolgozik (számoljunk 100-zal az egyszerűség kedvéért), és nagyjából hasonló a helyzet az SHA256-tal is. 1 MB lehashelése tehát átlagosan 10 ms, 1 KB-é pedig 0,01 ms, ami eltörpül az ECDSA költsége mellett, és így nyugodtan figyelmen kívül is hagyhatjuk.

A tranzakcióellenőrzés leglassabb része tehát a bemenetek ellenőrzése, mivel ez egy átlagos mai hardveren ~3 ms-ot vehet igénybe bemenetenként. A jelek szerint a jelenlegi blokkláncban a legtöbb tranzakciónak csak egy bemenete van, míg egy kevésnek 5-6 – számoljunk tehát átlagosan 2 bemenettel. Azonban minden bemenet kétszer kerül ellenőrzésre: egyszer akkor, amikor először beérkezik, majd másodszor akkor, amikor egy azt tartalmazó blokk érkezik, így összesen 12 ms-mal számolhatunk tranzakciónként.

Ez pedig azt jelenti, hogy ma egy egymagos processzor némi tuninggal és RAM-ban tárolt blokklánccal, de ezen kívül minden egyéb speciális hardver nélkül átlagosan 80 tranzakciót képes ellenőrizni és elfogadni másodpercenként (ezen a ponton érdemes megjegyezni, hogy a hálózat jelenleg átlagosan 4 tranzakciót bonyolít le percenként). Ez pedig annyit tesz, hogy a VISA szintjének eléréséhez egy hálózati csomópontnak nagyjából 50 magra + egyéb bányászati eszközökre (csatolt gépekre/GPU-kra) lenne szüksége. És bár egy 50 magos gép összeállítása igen nehéz lenne, a beérkező “tx” üzeneteket már annál könnyebben el lehetne osztani több gép között. Egyetlen gép is könnyedén eloszthatná a VISA tranzakcióit ellenőrző-gépek egy kisebb csoportja között, amely aztán továbbítaná az ellenőrzőtt tranzakciók hashét a bányászokhoz, hogy beilleszthessék azokat a Merkle-fába.

Az összes “tx” üzenet fogadására és kezelésére tehát egy 12 4 magos gépből álló rackre lenne szükség.

Maradnak tehát a beérkező “inv” üzenetek. Ezeknek a kezelése lényegében egy parányi üzenet olvasásából, majd egy RAM-ellenőrzésből áll, hogy kiderüljön, hogy megvan-e már a kérdéses tranzakció. Ez nagyon-nagyon gyorsan lezajlik. Egyetlen mag is könnyedén képes kezelni másodpercenként akár több ezer “inv” üzenetet még akkor is, ha egy shardolt, memóriában tárolt blokklánc-indexből kell beolvasnia.

Hálózat

Induljunk ki tehát a VISA-féle 2.000 t/s átlagból. Az egyes tranzakciók mérete 0,2 KB-tól valamivel 1 KB fölé terjedhet, de a blockexplorer adataiból kiindulva a mai átlag kb. 0,5 KB-ra tehető. Tegyük fel tehát, hogy minél többen használják a Bitcoint, annál komplikáltabbá válnak a dolgok, és számoljunk tranzakciónként 1 KB-tal.

Egy megoldott blokk így átlagosan (1.024 bájt * 2.000 t/s * 600 másodperc (10 perc)) / 1024 B (1 KB) / 1024 KB (1 MB) / 1024 MB (1 GB) = 1,14 GB/blokk.

A megoldott blokkokat azonban csak a hozzád csatlakozottaknak kell elküldeni; ha feltételezzük, hogy a jövő óriási szupercsomópontjai akár 40-50 kapcsolattal is dolgozhatnak, úgy a legrosszabb esetben (ami annyit tesz, hogy az ember vagy megold egy blokkot vagy fogad egy olyat, amivel még egyetlen másik kapcsolata sem rendelkezik (bár ez módfelett valószínűtlen)) ~57 GB adatot kell elküldeni (kerekítsük 60-ra).

60 GB adat mondjuk 60 másodperc alatt való kezelése átlagosan 1 GB/s, avagy 8 Gb/s sebességet jelent.

Itt tehát az igazi kérdés az, hogy mennyibe kerül ez a sávszélesség? Nos, ez egy trükkös terület, mivel a különböző megállapodások miatt épp a legnagyobb fogyasztók fizetik a legkevesebbet. A világ Google-jai és Akamai-jai lényegesen kevesebbet fizetnek egy 10G-s hullámért, mint amennyit egy kis operátornak számláznak ki ugyanezért. A 8 Gb/s-ot pedig amúgy sem érnéd el túl gyakran; leginkább csak akkor, ha épp te oldottál meg egy blokkot, mivel blokktovábbítás esetén a kapcsolataid egy része nagy valószínűséggel már úgyis rendelkezik vele, így elég csak egy részüknek elküldened azt.

Szerencsére azonban nagy valószínűséggel egyetlen csomópontnak sem kell ilyen gyorsan továbbítania ennyi adatot. Feltételezve, hogy minden csomópont ugyanannyi másikhoz csatlakozik, átlagosan elég mindegyiküknek csak egy példányát továbbítania a beérkező blokkoknak. Még ha hozzád is érkezik be elsőként egy blokk, miután elküldted már 3-4 másik gépnek, az exponenciálisan terjed tovább a hálózatban, a bittorrent protokolljához hasonlóan. Az adatátviteli költségek felől az egyes netszolgáltatóknál tájékozódhatsz.

Tárhely

Nagyon magas tranzakciószám esetén az egyes blokkok mérete az 1 GB-ot is meghaladhatja, ezt az adattömeget pedig tárolni kell valahol. És bár gyorsaság szempontjából nem lenne célszerű teljes egészében a RAMban tárolni az egész blokkláncot, költségkímélés szempontjából a legjobb megoldás talán az lehet, ha csak a leggyakrabban használt részeit tároljuk RAMban, a többit pedig a merevlemezen. Ma már 200$ alatt is lehet kapni 3 TB-os merevlemezeket, a jövőben pedig csak egyre olcsóbbak lesznek, így blokkonként 1 GB-tal számolva minden 21. napi használatot követően lenne szükség egy újabb merevlemezre.

Hálózatszerkezet

Jelenleg a Bitcoin egy lapos P2P-hálózat, amelyben minden csomópont egyenlő. A hosszútávú cél azonban egy már tipikusabbnak mondható kétszintű szerkezet, ahol is az alacsony teljesítményű klienscsomópontok hosszabb életű, nagyteljesítményű szupercsomópontokhoz csatlakoznak. Valamilyen szinten már most is támogatja a protokoll ezt a megoldást (lásd a szolgáltatás-flageket a “version”/”address” üzenetekben), azonban a kliens-üzemmód csak részlegesen van kidolgozva, arra pedig még egyáltalán nincs kód, hogy mikor és milyen alapon történjen a kliens- és a szupercsomópont-üzemmód közti váltás.

A teljes blokkláncot tároló és minden tranzakciót ellenőrző szupercsomópontok üzemeltetési költsége a hálózat bővülésével arányosan lesz egyre magasabb, viszont a kétszintű szerkezetnek köszönhetően így is könnyen csatlakozhat bárki bármikor. Az első csatlakozás alkalmával a klienscsomópontoknak elég csak néhány fejlécet letölteniük (az utolsó ellenőrzőponttól a lánc végéig), így egy ilyen csomópontot akár egy okostelefon modemjén keresztül is lehet üzemeltetni. Értelemszerűen a pehelysúlyú kliensek biztonsági modellje némileg különbözik a teljes értékű csomópontokétól. Mert bár nem kell egy bizalmas csomóponttal kommunikálniuk (bármelyik megteszi), ennél a konfigurációnál mégis nagyon fontos, hogy a hálózat a lehető legtámadhatatlanabb legyen, mivel ebben az esetben a blokk tartalma nem kerül ellenőrzésre.

Optimalizálás

A fenti leírás a szoftver jelen állapotára vonatkozik. Számos olyan, viszonylag könnyen kivitelezhető optimalizálás is lehetséges azonban, amelyek drasztikusan csökkenthetik a csomópontok működési költségeit.

CPU

Az egyes tranzakciók CPU-költségét megduplázza az a tény, hogy a jelenlegi szoftver kétszer is ellenőriz minden egyes bemenetet – azonban erre egyáltalán semmi szükség nincs. Ha egy tranzakció egyszer már zöld utat kapott, úgy ezt a tényt fel lehet jegyezni, és így a blokkban való megjelenésekor már nem kell újra ellenőrizni. Ez lényegében megduplázná a magonkéntki kapacitást, így máris elég lenne csak 25 mag is a VISA-szintű tranzakcióforgalom kezeléséhez. Ennyit pedig már egyetlen csúcskategóriás szerverbe is bele lehet zsúfolni.

Tárhely

A fenti blokklánc-tárolási számítás abból az alapfeltevésből indul ki, hogy soha semmi nem kerül törlésre. Satoshi dolgozata azonban kitér arra is, hogy a Merkle-fa-elrendezés miatt hosszú távon az olyan tranzakciókat már nyugodtan lehet törölni, amelyeknek minden kimenete teljes egészében elköltésre került. A csomópontok arra törekednek, hogy minél kevesebb apró, elköltetlen kimenetük legyen, mivel ez azt jelentené, hogy egy nagyobb érmemennyiség elküldése rengeteg bemenetet igényelne, ebből következően nagyra duzzadna, és már akár tranzakciós díja is lenne. Mivel pedig a csomópontok folyamatosan küzdenek a töredezettség ellen, ezért az idő múlásával nagy valószínűséggel számos blokkból ki lehet metszeni szinte az összes tranzakciót, nagyban csökkentve így a tárhely-igényüket – legjobb esetben akár 80 bájtra is. 2011. májusában a szoftver még nem támogatta a metszést, azonban a potenciális tárhely-megtakarítás egyes számítások szerint elérheti a tranzakciók 71%-át, avagy a nyers blokkbájtok 73%-át.

Sávszélesség

A blokkok elosztásának hálózati költségei nagyban mérsékelhetőek azzal, amennyiben úgy módosítjuk a protokollt, hogy fejléc+hashlista formátumban továbbítsa a blokkokat. Mivel a csomópontok nagy valószínűséggel látták már a tranzakciókat azoknak az első szétküldésekor, ezért az egyes blokkok mérete triviális lenne (80 bájt + tranzakciónként még 32). Ha pedig egy csomópont még nem találkozott az egyik vagy a másik tranzakcióval, hát lekérheti azt a csatlakozott csomóponttól.

Hálózatszerkezet

Korábban a peerkeresés IRC útján történt. A 0.3.24-es verzió óta ezt átállították DNS-alapúra, drasztikusan felgyorsítva így az indulási időt a hálózat gyarapodása ellenére is.

Egyszerűsített fizetésellenőrzés

Elkészíthető egy olyan Bitcoin-kliens is, ami nem ellenőriz mindent, hanem vagy egy bizalmas csomóponthoz csatlakozik, vagy pedig elfogadja a magas nehézségi szintet az érvényesség bizonyítékaként. A BitCoinJ pontosan így működik.

A Satoshi dolgozatának idevágó része után EFE-nek (SPV) elnevezett üzemmódban a kliensek egy önkényesen kiválasztott teljes értékű csomóponthoz csatlakoznak, és csak a blokkfejléceket töltik le onnan. Ellenőrzik a lánc fejléceinek szabályszerű egymáshoz kapcsolódását, valamint azt, hogy elég magas-e a nehézség, majd egy bizonyos mintának megfelelő tranzakciókat kérnek le a távoli csomóponttól (például a címedre érkezett kifizetéseket), ami meg is küldi ezeket a blokkjukhoz kapcsolódó Merkle-águkkal együtt. A Merkle-fa-szerkezet felhasználásával így a blokk teljes tartalmának ismerete nélkül is megoldható a bizonyítás. A mintához illő protokollüzenetet még nem dolgozták ki, bár egy felvetést már megtárgyaltak 2011. májusában.

További optimalizálásként egy idő után eldobhatóak a már elég mélyre temetett blokkfejlécek is (tehát elég mondjuk csak 1.000 blokkot eltárolnod).

Az, hogy mekkora nehézség kell ahhoz, hogy kellőképpen biztos lehess benne, hogy a távoli csomópont nem ver át hamis tranzakciókkal, a fenyegetettségi modelled függvénye. Ha egy közismerten megbízható csomóponthoz csatlakozol, akkor a nehézség nem is érdekes. Ha viszont találomra választasz egyet, akkor a lényeg az, hogy a támadó számára költségesebb legyen egy hamis tranzakciót tartalmazó blokkszekvencia kibányászása annál, mint amennyit nyerhetne a csalással. Az elvárt eltemetettség mélységének meghatározásával a megerősítés időtényezőjének rovására teheted egyre költségesebbé a támadást.

Nullesetben (ha épp nincsenek használatban) az ezt a megközelítést alkalmazó programok dolgozhatnak rögzített tárhely/hálózat többletterheléssel és a küldött/fogadott tranzakciók mennyiségével arányos erőforrás-felhasználással is.

Forrás: Bitcoin Wiki

A lap szövege Creative Commons Nevezd meg! – Ne add el! – Így add tovább! 3.0 licenc alatt áll, felhasználni csak forrásmegjelöléssel, és ide mutató linkkel szabad.