Újraírtuk a BlockBen blokklánc- és egyenlegkezelésének magját. 30–40× gyorsabb, milliszekundum alatti műveletek, és egy olyan felépítés, amelyben nincs egyetlen olyan pont, amelynek kiesése megállítaná a rendszert. Ez a cikk arról szól, mi történt 2026. augusztus 31-én a tervezettnél hosszabb rendszerfrissítés mögött — és miért kellett hozzá egy saját protokollt kitalálni.
Nemrégiben a tervezettnél hosszabb időt vett igénybe a rendszer upgrade. Ennek nagyon jó oka volt, és nem az, amire elsőre gondolna az ember: a kód gyorsan átment, az AWS infrastruktúra-változás viszont éles környezetben lassabban futott le, mint teszten. Valószínűleg felhőszolgáltatói túlterhelés volt. Azt nem tudjuk megígérni, hogy ez legközelebb nem fordul elő. Azt viszont igen, hogy a rendszer, amit közben beüzemeltünk, megérte a várakozást.
Ha ma reggel elindítottad a BlockBen appot, talán érezted, hogy mintha egy picit gyorsabban töltene be. Nem a képzeleted játszik veled. Az elmúlt hónapok egyik legnagyobb technológiai fejlesztése került be a rendszerbe: gyakorlatilag teljesen újraírtuk és újragondoltuk a blokklánc- és egyenlegkezelésünk legfontosabb komponenseit.
Ez az a fajta fejlesztés, amelyet kívülről nehéz észrevenni. Nincs új gomb, nincs új képernyő, nincs új animáció. Csak minden gyorsabb, stabilabb és sokkal nagyobb terhelésre felkészített lett a háttérben. Most megpróbálom elmondani, mit is építettünk — úgy, hogy ne kelljen hozzá informatikusnak lenni, de mégis lássátok benne a mérnöki munkát, ne csak egy marketingszámot.
Mi volt a baj a régivel?
A BlockBen rendszerének több több „agya" is van, de most kettőről szeretnék beszélni. Az egyik a Ledger: ez rendezi a tranzakciókat blokkokba, ez építi a blokkláncot, és ez állítja elő azokat a kriptográfiai bizonyítékokat, amelyeket a QantrumScan segítségével bárki ellenőrizhet. (erről egy másik cikkben még fogok írni) A másik az egyenlegkezelő réteg (belső nevén Balancer): ez tartja nyilván a számlák egyenlegét, ez dönti el minden egyes tranzakciónál, hogy van-e rá fedezet, és ez könyveli le a változást.
A régi rendszerben ez a kettő két külön világ volt. Külön kód, külön belső nyelv, külön adatszerkezetek. Mindkettő működött, mindkettő tudott bővülni — de nem voltak elég gyorsak, és ami hosszú távon rosszabb: idővel elkezdtek széttartani. Ugyanazt a problémát két helyen, kétféleképpen oldottuk meg, és két helyen kellett karbantartani, tesztelni, hibát keresni.
Amikor leültünk újratervezni, az első felismerés nem a sebességről szólt, hanem arról, hogy a két rendszer belülről ugyanúgy működik. Mindkettő egy nagy adathalmazt kezel, amelyet több részre osztunk, hogy több gép dolgozhasson rajta párhuzamosan. Mindkettőnél minden egyes részt több gép szolgál ki egyszerre, hogy ha az egyik kiesik, a többi továbbvigye. Mindkettőnél ezek a gépek vezetőt választanak maguk közül, és ha a vezető nem jól végzi a dolgát, leváltják. És mindkettőnél előfordul, hogy egy tranzakció több részt érint egyszerre, amit vagy mind egyszerre kell végrehajtani, vagy sehogy.
Két látszólag teljesen különböző üzleti feladat, ugyanazzal a belső mintával. Ekkor dőlt el, hogy nem két rendszert gyorsítunk, hanem egy közös alapot építünk, amelyre mindkettő ráül. Ehhez egy teljesen egyedi protokollt dolgoztunk ki. A belső neve: Phantom protokoll. Erről még hallani fogtok a jövőben.
Az egyenleg miért nem egy oszlop egy táblázatban?
Sokan azt gondolják, hogy egy egyenleg nyilvántartása egyszerű: van egy szám, hozzáadunk, kivonunk. Aki dolgozott banki rendszerekkel, az tudja, hogy ez sosem így van.
Egy tranzakciónak van rögzítési napja és értéknapja, és a kettő nem mindig ugyanaz — a rendszernek mindkét nézetet helyesen kell tudnia bármelyik múltbeli napra. Van zárolt egyenleg és elkölthető egyenleg. Vannak számlák, amelyek nem mehetnek mínuszba — ilyenek az ügyfélszámlák. És vannak olyanok, ahol azt is megtiltjuk, hogy egy tranzakció közben, egy pillanatra is, mínuszba menjenek, még ha a vége pozitív is lenne.
És van egy különleges típus, amely jó példa arra, hol dől el egy pénzügyi rendszer sebessége. Gondoljunk egy bevételi számlára, amelyre gyakorlatilag minden tranzakció könyvel valamit. Ha ezt a számlát ugyanúgy kezelnénk, mint egy ügyfélszámlát — minden tranzakciónál megállunk, ellenőrizzük az egyenleget, zároljuk —, akkor a rendszer összes tranzakciója egyetlen kapun menne át, egymás után várakozva. Ez olyan, mint amikor egy sokpénztáras üzletben minden vásárlónak ugyanannál az egy pénztárosnál kell aláírnia egy papírt, mielőtt fizethet. Ezért ezeket a számlákat másképp kezeljük: rájuk párhuzamosan lehet könyvelni, és az egyenleget nem minden tételnél, hanem időszakonként számoljuk el. Levenni róluk pedig csak a már elszámolt összeg erejéig lehet — de ez már számviteli kérdés, nem technológiai.
A lényeg: a Balancer egy könyvelési motor, amelynek minden döntése tranzakciónként, milliszekundumok alatt kell, hogy megszülessen. Ehhez az egyenlegellenőrzés teljes egészében memóriában fut, nem adatbázis-lekérdezéssel. A „megnézem, mennyi van, aztán írok" módszer ugyanis párhuzamos terhelés alatt nem biztonságos — két tranzakció ugyanazt az egyenleget látja, és mindkettő azt hiszi, van fedezet. Egy pénzügyi rendszerben ezt nem engedhetjük meg, még egy ezred másodpercre sem.
Phantom: aki koordinál, annak nem kell emlékeznie
Nézzük meg pontosan mi is probléma: ha egy tranzakció több számlát is érint — mondjuk egy ügyfélszámlát az egyik egységen és egy bevételi számlát a másikon —, a két egységnek együtt kell döntenie: vagy mindkettő véglegesít, vagy egyik sem. Az informatika erre ötven éve ugyanazt a mintát használja: egy koordinátor előbb megkérdez mindenkit, hogy készen áll-e, aztán kiadja a döntést.
Ennek a mintának ötven éve ugyanaz a gyenge pontja: a koordinátornak emlékeznie kell. Naplót kell vezetnie arról, kiket kérdezett meg. Ha a koordinátor összeomlik a kérdés és a döntés között, a résztvevők ott ülnek várakozva, zárolt egyenlegekkel, egy döntésre, amely sosem jön meg — hacsak valaki elő nem ássa a halott koordinátor naplóját. A világ legnagyobb rendszerei erre a problémára építettek hatalmas, bonyolult védelmi rétegeket. Mind működik. Mind bonyolult. Mind lassít.
A fordított kérdés
Mi másképp tettük fel a kérdést. Nem azt kérdeztük meg, hogy hogyan védjük meg a koordinátort. Azt kérdeztük: miért kell neki egyáltalán emlékeznie?
A résztvevők ugyanis már tudják magukról, hogy készen álltak-e. Az egyetlen hiányzó információ az, hogy kiket kértek fel — és ezt oda lehet adni maguknak a résztvevőknek. Képzeljünk el egy tárgyalást, ahol a jegyző nem vezet jegyzőkönyvet, hanem minden résztvevő kap egy cetlit, amin rajta van, ki ül az asztalnál. Ha a jegyző eltűnik, bármelyik új jegyző bejön, elkér egy cetlit bárkitől, körbenéz, és azonnal tudja, ki hiányzik. Nem kell keresnie semmit. Nem kell találgatnia.
A Phantom protokollban ez a „cetli" néhány bájt, amelyet minden résztvevő megkap. Ettől kezdve a koordinátornak nincs semmije, amit el lehetne veszíteni. Kiszámolja a döntést, elküldi, elfelejti. Ha összeomlik, bármelyik másik példány — akár egy frissen indított — 1 másodperc alatt átveszi és befejezi, amit az előző elkezdett. Nálunk a koordinátor nem is külön szerver: minden háttérfolyamatba be van építve. Ezért mondom, hogy a rendszerben nincs központi koordinátor. Nincs egyetlen olyan pont, amelynek kiesése megállítaná a tranzakciókat.
A Phantom másik fontos tulajdonsága, hogy ha egy tranzakció csak egy részt érint, a teljes kérdezz-felelek elmarad: az egység egyetlen körben ellenőriz, ír és véglegesít. Ez nagyjából megfelezi az időt. És mivel a bevételi típusú számlákat bármelyik egységen tudjuk könyvelni, a tranzakciók nagy részét úgy tudjuk végrehajtani, hogy egyetlen részt érintsenek. Itt találkozik a két döntés, a számlatípus és a protokoll, és itt születik meg a „bizonyos műveleteknél 1 ms alatti végrehajtás" adata.
A Phantom-ban a számomra legszebb gondolat nem technikai. Az egész iparág arra fektetett évtizedeket, hogy a koordinátort hibatűrővé tegye. Mi azt mondtuk: tegyük eldobhatóvá. Ha nincs benne semmi, amit érdemes megvédeni, akkor a kiesése egyszerűen nem esemény. A protokollt a jövőben szeretnénk nyílt forráskódúvá tenni (nem a BlockBen-specifikus részeket), mely így rengeteg elosztott rendszer működését teheti egyszerűbbé, gyorsabbá és biztonságosabbá.
Miért fut el egy Ledger 1 CPU-n?
Ez egy nagyon izgalmas kérdés, de igyekszem most közérthetően elmondani.
A blokkláncok drága titka
A blokklánc-technológiában a legdrágább dolog a konszenzus: az, ahogyan a hálózat résztvevői meggyőződnek arról, hogy egy változás valóban megtörtént, és mindenki ugyanazt látja. A nyílt blokkláncok ezt úgy oldják meg, hogy minden résztvevő minden tranzakciót feldolgoz és a teljes láncot tárolja. Ez az oka annak, hogy egy nyílt blokklánc csomópont több terabájtnyi adatot cipel, és a hálózat nem lesz gyorsabb attól, hogy több gép csatlakozik, inkább a leglassabbhoz igazodik. (Tudom, leegyszerűsítettem, mert a valóságban a nyilt blokklánc prtokollok tartalmaznak védelmet a leglassabb gép ellen, de most ettől az egyszerűsítés miatt tekintsünk el)
Ezért él az a kép, hogy a blokklánc lassú és erőforrás-éhes.
Másolat helyett bizonyíték
A Qantrum rendszerben a bizalmat nem az adja, hogy mindenki mindent lát, hanem a kriptográfiai bizonyíték. Ez megváltoztatja az egész egyenletet.
Nem kell, sőt, nem szabad, a több terabájtos adathalmazt mindenkinek átküldeni. Elegendő minden Ledgerről egyetlen, állandó méretű bizonyítékot tárolni, amely az addigi összes tranzakciót képes hitelesíteni. Igen, jól olvasod: a blokklánc teljes állapotának bizonyítéka ugyanakkora, akár száz, akár százmillió tranzakciót tartalmaz. Olyan ez, mint egy pecsét egy könyv utolsó oldalán, amely az egész könyvet igazolja — és ha bárki egyetlen betűt átír bármelyik korábbi oldalon, a pecsét többé nem stimmel.
Nem egy általános célú, mindent-tudó bizonyítási rendszert használunk, amelyekről a szakmában olvasni lehet, és amelyek drágák és lassúak. Célprotokollokat fejlesztettünk arra a néhány konkrét állításra, amelyet egy pénzügyi ledgernek bizonyítania kell. Ezért a bizonyítékképzés rendkívül gyors. És ezért elegendő egy Ledgernek 1 CPU és 2–3 GB memória.
Ha gyorsítani akarunk, nem nagyobb gépet veszünk. Felosztjuk a blokklánc állapotát több részre, több Ledger fog dolgozni, és párhuzamosan több blokklánc épül.
Több lánc, amely egymásról tanúskodik
Jogos kérdés: ha több blokklánc épül párhuzamosan, nem esik szét a rendszer több, egymásról nem tudó láncra? Hogyan lehet az egészet egy pontból ellenőrizni?
A megoldás egyszerű. Minden Ledger rendszeres időközönként beírja a saját pecsétjét a többi Ledger láncába, ugyanúgy, mint bármilyen más tranzakciót. A másik láncban ez egy normál bejegyzés lesz, saját bizonyítékkal, saját pecséttel. Idővel minden lánc tartalmaz hivatkozást minden másik lánc állapotára. Olyan ez, mint két főkönyv, amelyek rendszeresen aláírják egymás utolsó oldalát: ha valaki az egyiket meghamisítja, a másik leleplezi.
Nincs központi blokklánc. Van egy háló, amelyben minden lánc tanúskodik a többiről — és bármelyikből kiindulva bármelyik tranzakció ellenőrizhető. Ez az a réteg, amelyet a QantrumScan verifier használ, amikor beilleszted a Signed Data Hash értékét.
Mi történik, ha kiesik valami?
Jelenleg két Ledger — két független blokklánc-képző egység — működik a BlockBen rendszerében, egyenként három gépből álló csoportban. Ugyanez a felépítés működik az egyenlegkezelő rétegnél is. A három gép vezetőt választ; a vezető dolgozik, a másik kettő figyeli, és ha a vezető kiesik, azonnal leváltják. Mindhárom gép külön helyen fut, egymástól függetlenül.
A jelenlegi infrastruktúra kb. 2 000 tranzakció/másodperc terhelésre van méretezve. Ha több kell, nem költöztetünk: új egységet nyitunk, a munka egy részét átirányítjuk rá — működés közben, leállás nélkül —, és a kapacitás az egységek számával együtt nő.
De ezt nem elég leírni. Tesztelni kell. És nem csak azért, mert mi így gondoljuk: a DORA európai rendelet előírja, hogy egy pénzügyi szolgáltató rendszeresen tesztelje, hogyan viselkedik a rendszere, amikor valami elromlik.
Ha egy csoport egyik gépe kiesik: semmi nem történik. Nagyon gyorsan, szinte észrevétlenül beáll az új vezető, és megy tovább a feldolgozás. Nincs visszautasított tranzakció.
Ha egy egész csoport kiesik: az adott egység megáll. A másik egység ettől még működőképes — ezt hívjuk részleges működésnek. Az érintett ügyfelek átmenetileg nem tudnak tranzakciót indítani, a többiek igen. A visszaállás teljesen automatikus: amikor a gépek újra elérhetők, felveszik és folytatják a munkát.
A tesztelés során vizsgáltunk szerverleállásokat, hálózati útvonalak megszűnését, egyéb rendszerkomponensek kiesését. És volt monkey teszt is: nem mi idéztük elő a hibát, hanem egy erre írt program generált véletlenszerű hibákat az infrastruktúrában, miközben a rendszer terhelés alatt volt. A cél nem az, hogy a rendszer sose hibázzon, olyan rendszer nincs. A cél az, hogy minden hibára legyen definiált válasz, és egyetlen komponens kiesése se hagyja a rendszert olyan állapotban, amelyből nem tud magától felállni.
A számok, és hogy mit jelentenek
- ~30–40× gyorsabb blokklánc- és egyenlegkezelés a korábbi verzióhoz képest.
- Bizonyos műveleteknél 1 milliszekundum alatti végrehajtási idő.
Ezek belső mérések: azt mérik, mennyi idő alatt születik meg a döntés és válik véglegessé a rendszer szívében. Nem tartalmazzák a mobilalkalmazás és a szerver közötti utat, a bejelentkezést, az ellenőrzéseket — vagyis nem azt, hogy mennyi idő alatt látod a képernyőn. Mi ezt a számot tartjuk fontosnak, mert ez az, ami az architektúrától függ, és ez az, ami a terhelés növekedésével számít. Amit a képernyőn látsz, az is javult, de azt már nem ez a réteg határozza meg többet.
A 30–40× nem egyetlen trükkből jön. Jön abból, hogy a tranzakciók nagy része egyetlen körben lezárul. Jön a memóriában futó egyenlegellenőrzésből. És jön abból, hogy a két komponens egy közös, Rustban írt alapon fut, amelyet egyszer terveztünk meg jól, kettő helyett.
Mi jön még?
A smart contract végrehajtó még az eredeti verzión fut. Ez a következő lépés. Az új végrehajtó tesztverziójánál az első méréseink 40–50×-es gyorsulást mutatnak — de ez tesztfázis, a számok változhatnak, és éles környezetben mindig más a kép. Amikor élesben lesz, ugyanígy leírjuk a tapsztaltakat.
A Phantom protokoll nyílt forráskódú kiadása még nincs időzítve. A leírás kész, a rendszer élesben fut rajta, de a kiadáshoz dokumentáció, referencia-implementáció és tesztkészlet kell. Nem szeretnénk félkész dolgot kipublikálni.
A jelenlegi két egység elegendő a mai és a belátható terhelésre. Új egység nyitását éles környezetben még nem kellett elvégeznünk, teszten már igen. Amikor először lesz rá szükség élesben, az is egy külön cikk lesz. 😉
A kenyérpirító esete, avagy diszruptívnak kell lenni
És akkor hogy is van ez a kenyérpirító eset? 😃
Fél évvel ezelőtt, egy meeting közepén, amikor ezeket a célokat először kimondtam, az egyik fejlesztőnk (mai napig itt cseng a nyugodt hangja a fejemben) megkérdezte:
„Most tényleg azt akarod, hogy egy kenyérpirítón is elfusson a blockchain-képző? Te egy őrült vagy..."
Jogos kérdés volt. A blokklánc rendszerekről az a kép él, hogy erőforrás-éhesek, lassúak és nehezen bővíthetők. Ez sok esetben igaz is, de nem azért, mert a blokkláncnak ilyennek kell lennie, hanem azért, mert a legtöbb rendszer úgy építi a bizalmat, hogy mindenki mindent lemásol. Ha a bizalmat bizonyítékok adják, nem másolatok, akkor egy gépnek nem kell mást csinálnia, mint a saját részét rendezni és igazolni. Az pedig elfut 1 CPU-n.
Mi pénzügyi infrastruktúrát építünk. Ott más az elvárás, és (mint kiderült) más a lehetőség is.
Úgy néz ki, mégsem voltunk teljesen őrültek. 😃
Megálmodtuk. Megépítettük. És most már működik.
És hogy miért kell ekkora teljesítmény?
Gondolom, már sejtitek.
A StockLock indulásával sok tranzakcióra számítunk a meglévő ügyfeleinktől. A jövőbeni új szolgáltatások ugyanezt az alapot fogják használni, és új felhasználók érkezésére számítunk. Nem a mai forgalomra méreteztünk, hanem arra, ami utána jön, és úgy, hogy amikor jön, ne költöztetni kelljen, hanem bekapcsolni egy újabb feldolgozó egységet.
Ezért írtuk újra. Ezért nincs benne központi koordinátor. Ezért bővíthető leállás nélkül. Ezért fut el egy kenyérpirítón.
