Bármely elosztott rendszerrel kapcsolatos leggyakoribb kérdés a nem technikai szakemberek részéről az, hogy „mennyi tps van a blokkláncában?”. Azonban a válaszban megnevezett szám általában alig áll kapcsolatban azzal, amit a kérdező hallani szeretne. Valójában azt akarta kérdezni, hogy „megfelel-e a blokklánca az üzleti követelményeimnek?”, és ezek a követelmények nem egyetlen számot jelentenek, hanem számos feltételt — ide tartozik a hálózat megbízhatósága, a véglegesség követelményei, a tranzakciók mérete, típusa és sok egyéb paraméter. Így a „mennyi tps” kérdésre adott válasz valószínűleg nem lesz egyszerű, és szinte soha nem lesz teljes. Az elosztott rendszer, amely tucatnyi és száznyi csomóponttal bonyolult számításokat végez, rengeteg különböző állapotban lehet, amelyek a hálózat állapotával, a blokklánc tartalmával, technikai hibákkal, gazdasági problémákkal, támadásokkal és sok egyéb okkal kapcsolatosak. Azok a lépések, ahol teljesítményproblémák léphetnek fel, eltérnek a hagyományos szolgáltatásoktól, és a blokklánc-hálózat szervere egy hálózati szolgáltatás, amely ötvözi az adatbázis, a webkiszolgáló és a torrent kliens funkcióit, ami rendkívül összetett terhelési profilt jelent minden alkotóelem, beleértve a processzort, a memóriát, a hálózatot és a tárolást.

Úgy alakult, hogy a decentralizált hálózatok és blokkláncok meglehetősen specifikus és szokatlan szoftverek a központosított szoftverek fejlesztői számára. Ezért szeretném bemutatni a decentralizált hálózatok teljesítményével és stabilitásával kapcsolatos fontos szempontokat, az azok mérésére és a szűk keresztmetszetek felderítésére tett megközelítéseket. Megvizsgáljuk a teljesítménnyel kapcsolatos különböző problémákat, amelyek korlátozzák a blokkláncok felhasználók számára történő szolgáltatásának sebességét, és kiemeljük azokat a jellemzőket, amelyek e típusú szoftverekre jellemzőek.

A blokklánc ügyfél által indított szolgáltatás kérelmének lépései

A bármely viszonylag bonyolult szolgáltatás minőségének reális értékeléséhez figyelembe kell venni nemcsak az átlagos értékeket, hanem a maximális és minimális, medián és percentilis adatokat is. Elméletileg lehet beszélni 1000 tps-ről valamilyen blokkláncon, de ha 900 tranzakció hihetetlen sebességgel ment végbe, míg 100 „megrekedt” pár másodpercre, akkor az összes tranzakcióból összeállított átlagos idő nem teljesen korrekt méret a kliens számára, aki néhány másodperc alatt nem tudta befejezni az üzletet. Az időbeli „lyukak”, amelyeket a konszenzus elmulasztott körök vagy a hálózat megosztása okoz, jelentősen ronthatják a szolgáltatást, amely a tesztkörnyezetben kiváló teljesítményt mutatott.

Az ilyen szűk keresztmetszetek azonosításához jól kell érteni azokat a lépéseket, ahol a valódi blokklánc nehézségekkel találkozhat a felhasználók kiszolgálása során. Írjuk le a tranzakció szállítási és feldolgozási ciklusát, valamint a blokklánc új állapotának megszerzését, amelyből a kliens megbizonyosodhat arról, hogy tranzakciója feldolgozásra került és figyelembe lett véve.

a tranzakció a kliensen formálódik
a tranzakció a kliensen aláírásra kerül
a kliens kiválaszt egy nodot és elküldi neki a tranzakcióját
a kliens feliratkozik a node state database frissítéseire, várva a tranzakciója végrehajtásának eredményét
a node elterjeszti a tranzakciót a p2p hálózaton
több vagy egy BP (blokktermelő) feldolgozza a felhalmozott tranzakciókat, frissítve a state database-t
a BP új blokkot képez, feldolgozva a szükséges számú tranzakciót
a BP elterjeszti az új blokkot a p2p hálózaton
az új blokk eljut a node-hoz, amelyhez a kliens fordul
a node frissíti a state database-t
a node észleli a kliensre vonatkozó frissítést, és értesítést küld a tranzakcióról

Most már nézzük részletesebben ezeket a lépéseket, és írjuk le a potenciális teljesítményproblémákat minden egyes szakaszban. A centralizált rendszerektől eltérően figyelembe vesszük a kód futtatását a hálózat klienseken is. Elég gyakran a tps mérésénél a tranzakciók feldolgozási idejét a node-októl, és nem a kliensektől gyűjtik — ez nem teljesen fair. A kliens részéről lényegtelen, hogy mennyire gyorsan dolgozta fel a node a tranzakcióját; a legfontosabb számára az az időpont, amikor a tranzakciójáról szóló megbízható információ, amely a blokkláncba került, elérhetővé válik számára. Ez a mérőszám lényegében a tranzakció végrehajtási ideje. Ez azt jelenti, hogy különböző kliensek, még akkor is, ha ugyanazt a tranzakciót küldik el, teljesen eltérő időkben kaphatják azt, ami a csatornától, a forgalomtól és a node közelségétől stb. függ. Így elengedhetetlen, hogy ezt az időt a klienseken mérjük, mivel ez az a paraméter, amit optimalizálni kell.

A tranzakció előkészítése a kliens oldalán

Kezdjük az első két ponttal: a tranzakciót a kliens állítja össze és írja alá. Furcsán hangzik, de ez is lehet a blokklánc teljesítményének szűk keresztmetszete a kliens szempontjából. Ez szokatlan a centralizált szolgáltatások számára, ahol minden számítást és adatkezelést maguk végeznek, míg a kliens csupán egy rövid kérést készít elő, ami képes egy nagy adat- vagy számítási mennyiséget kérni, és a kész eredményt kapja meg. A blokkláncokban a kliens kód egyre erősebbé válik, míg a blokklánc mag egyre könnyebbé, a hatalmas számítási feladatokat pedig a kliens szoftvernek szokták átadni. A blokkláncokban léteznek olyan kliensek, amelyek egy tranzakciót meglehetősen hosszú ideig képesek előkészíteni (különböző merkle proof-okról, succinct proof-okról, threshold aláírásokról és egyéb bonyolult műveletekről a kliens oldalán van szó). Egy jó példa a könnyű on-chain ellenőrzésre és a tranzakció nehéz előkészítésére a kliensek részéről a Merkle-fán alapuló listához való tartozás bizonyítása. cikk.

Ne felejtsük el, hogy az ügyfélkód nem csupán tranzakciókat küld a blokkláncra, hanem először lekéri a blokklánc állapotát - ez a tevékenység hatással lehet a hálózat terhelésére és a blokklánc csomópontokra. Ezért, amikor méréseket végzünk, hasznos, ha a lehető legteljesebb mértékben modellezzük az ügyfélkód viselkedését. Még akkor is, ha a blokkláncunkban szokványos, könnyű kliensek vannak, akik egyszerű digitális aláírást helyeznek el egy egyszerű tranzakciónál valamilyen eszköz átvitelére, az ügyfélen végzett számítások mennyisége évről évre növekszik, a kriptográfiai algoritmusok erősödnek, és ez a feldolgozási rész a jövőben jelentős szűk keresztmetszetté válhat. Legyünk óvatosak, és ne hagyjuk figyelmen kívül az olyan helyzeteket, amikor egy 3,5 másodpercig tartó tranzakció 2,5 másodpercet vesz igénybe a tranzakció előkészítésére és aláírására, és 1,0 másodpercet az elküldésére a hálózatba és a válaszra való várakozásra. A potenciális szűk keresztmetszetek kockázatainak felmérése érdekében metrikákat kell gyűjteni az ügyfélszámítógépekről, nem csupán a blokklánc csomópontokról.

Tranzakció küldése és állapotának nyomon követése

A következő lépés a tranzakció elküldése a választott blokklánc csomópontra, valamint a tranzakciós medencébe való befogadásának státuszának megszerzése. Ez a lépés hasonló egy szokványos adatbázis-lekérdezéshez; a csomópontnak rögzítenie kell a tranzakciót a medencében, és el kell kezdenie terjeszteni az információt a p2p hálózaton. A teljesítményértékelési megközelítés itt hasonló a hagyományos mikroszolgáltatások Web API működésének értékeléséhez, ráadásul maguk a tranzakciók a blokkláncokban frissíthetők, aktívan változtathatják státuszukat. Általánosságban elmondható, hogy a tranzakció információjának frissítése egyes blokkláncokban többször is bekövetkezhet, például lánc forkok közötti váltások esetén, vagy amikor a BP-k a tranzakció blokkba való beillesztésének szándékáról tájékoztatnak. A medencére és az abban található tranzakciók számára vonatkozó korlátozások befolyásolhatják a blokklánc teljesítményét. Ha a tranzakciós medence eléri a maximális méretét, vagy ha nem fér el a memóriában - a hálózat teljesítménye drámaian csökkenhet. A blokkláncok nem rendelkeznek központosított védelmi eszközökkel a szemétüzenetek áramlása ellen, és ha a blokklánc nagy volumennel és alacsony díjakkal támogatja a tranzakciókat, az a tranzakciós medence túlcsordulásához vezethet - ez egy újabb potenciális teljesítménybeli szűk keresztmetszet.

A blokkláncokban a kliens bármelyik általa kedvelt blokklánc csomópontba elküldi a tranzakciót, a tranzakció hash-a általában ismert a kliens számára még az elküldés előtt, így mindössze annyira van szüksége, hogy kapcsolatot létesítsen, és a küldés után várjon, amíg a blokklánc megváltoztatja az állapotát, belefoglalva a tranzakciót. Érdemes megjegyezni, hogy a „tps” mérésénél teljesen eltérő eredményeket kaphatunk a blokklánc csomópontjával való kapcsolódás különböző módjai alapján. Ez lehet hagyományos HTTP RPC vagy WebSocket, amely lehetővé teszi a „feliratkozás” mintázat megvalósítását. Az utóbbi esetben a kliens korábban értesítést kap, és a csomópont kevesebb erőforrást (főként memóriát és forgalmat) használ az állapotjelentésekre. Ezért a „tps” mérésénél figyelembe kell venni a kliensek csomópontokkal való kapcsolódásának módját. Így a bottleneck megjelenésének kockázatának értékeléséhez a blokklánc benchmarknak képesnek kell lennie arra, hogy emulálja a klienseket WebSocket és HTTP RPC kérésekkel, arányokban, amelyek megfelelnek a valós hálózatoknak, valamint módosítsa a tranzakciók jellegét és azok méretét.

A bottleneck megjelenésének kockázatának értékeléséhez ügyelni kell arra is, hogy méreteket gyűjtsünk az ügyfélgépekről, nem csupán a blokklánc csomópontokról.

Tranzakciók és blokkok továbbítása p2p hálózaton

A blokkláncokban a tranzakciók és blokkok küldésére a peer-to-peer (p2p) hálózatot használják a résztvevők között. A tranzakciók egy csomóponttól elindulva terjednek a hálózaton, amíg el nem érik a peer-eket, a blokkgyártókat, akik a tranzakciókat blokkokba csomagolják, és a p2p hálózaton keresztül új blokkokat terjesztenek a hálózat összes csomópontján. A legtöbb modern p2p hálózat alapja a Kademlia protokoll különböző módosításai. Íme jó rövid áttekintés erről a protokollról, és itt van — egy cikk különböző mérésekkel a BitTorrent hálózaton, amelyből megérthetjük, hogy ez a fajta hálózat bonyolultabb és kevésbé kiszámítható, mint a szigorúan konfigurált központi szolgáltatás hálózata. Ezen kívül, itt van cikk különböző érdekes mérések Ethereum nodok számára.

Röviden, ezekben a hálózatokban minden peer saját dinamikus listáját tartja fenn a többi peer-ről, akiktől információs blokkokat kérdezhet. Amikor egy kérés érkezik, a peer vagy átadja a szükséges információt, vagy a listáról egy véletlenszerű peer-nek továbbítja a kérést, majd a választ visszaküldi a kérdezőnek, és egy ideig cache-eli az információt, hogy legközelebb gyorsabban tudja átadni. Így a népszerű információk számos cache-ben fellelhetők sok peer-nél, míg a népszerűtlenek fokozatosan eltűnnek. A peer-ek nyomon követik, hogy ki mennyi információt adott át, és a hálózat próbálja ösztönözni az aktív megosztókat, növelve a rangsorukat és biztosítva számukra a magasabb szintű szolgáltatást, automatikusan kiszorítva a nem aktív résztvevőket a peer-listákból.

Most tehát a tranzakciót el kell juttatni a hálózaton, hogy a block-producer-ek észleljék és beépítsék azt a blokkba. A node aktívan "megfelel" az új tranzakciónak, és hallgatja a hálózatot, várva a blokkra, amelyben a szükséges tranzakció megjelenik, hogy értesítse az várakozó ügyfelet. Az idő, amíg a hálózat átadja egymásnak az új tranzakciókról és blokkokról szóló információkat a p2p hálózatokban, nagyon sok tényezőtől függ: az aktív és környező (hálózati szempontból) node-ok számától, azok cache-einek "melegétől", a blokkok és tranzakciók méretétől, a változások jellegétől, a hálózat topológiájától, a node-ok számától és számos egyéb tényezőtől. A teljesítménymetrikák összetett méréseiben a p2p hálózatokban nehéz feladat, mivel egy időben kell értékelni a kérelmek feldolgozási idejét mind az ügyfeleken, mind a peer-eken (blockchain node-okon). Bármelyik p2p mechanizmusban előforduló problémák, az adatok nem megfelelő kiszorítása és cache-elése, a aktív peer-ek listájának hatékony kezelése, valamint számos egyéb tényező késleltetéseket okozhat, amelyek befolyásolják az egész hálózat hatékonyságát, és ez a szűk keresztmetszet – a legbonyolultabb az elemzés, tesztelés és az eredmények értelmezése szempontjából.

A blokklánc feldolgozása és az állapotadatbázis frissítése

A blokklánc működésének legfontosabb része a konszenzus algoritmus, annak alkalmazása az új, a hálózatból származó blokkokra, valamint a tranzakciók feldolgozása és az eredmények rögzítése az állapot adatbázisban. Az új blokk hozzáadása a lánchoz és az ezt követő fő lánc kiválasztása a lehető leggyorsabban kell, hogy működjön. Azonban a valós életben a "kell" nem egyenlő a "működik"-kel, és például elképzelhető egy olyan helyzet, amikor két hosszú, versengő lánc folyamatosan váltogatja egymást, megváltoztatva ezer tranzakció metainformációit a medencében minden váltáskor, és folyamatosan visszaállítva az állapot adatbázis állapotát. Ez a szakasz, a szűk keresztmetszet meghatározása szempontjából, egyszerűbb, mint a hálózati p2p réteg, mivel a tranzakciók végrehajtása és a konszenzus algoritmus szigorúan meghatározott, és itt könnyebb bármit is mérni.
Fontos, hogy ne keverjük össze a teljesítmény véletlenszerű romlását ezen a szakaszon a hálózati problémákkal — a csomópontok lassabban adják át a blokkokat és az alaplánccal kapcsolatos információt, ami egy külső kliens számára lassú hálózatnak tűnhet, holott a probléma egészen máshol rejlik.

A teljesítmény optimalizálása érdekében ezen a szakaszon hasznos gyűjteni és figyelemmel kísérni a csomópontokból származó metrikákat, és ezeket belefoglalni a state-database frissítésével kapcsolatosakat is: a csomóponton feldolgozott blokkok száma, azok mérete, a tranzakciók száma, a láncváltozások száma, a nem érvényes blokkok száma, a virtuális gép működési ideje, az adatok rögzítésének időtartama, stb. Ez lehetővé teszi a hálózati problémák és a láncfeldolgozási algoritmusok hibáinak összekeverésének elkerülését.

A tranzakciókat feldolgozó virtuális gép hasznos információforrást jelenthet a blokklánc működésének optimalizálásához. A memóriaallokációk mennyisége, a read/write utasítások száma és egyéb metrikák, amelyek a szerződések kódjának végrehajtásának hatékonyságára vonatkoznak, sok hasznos információt nyújthatnak a fejlesztők számára. Ugyanakkor a smart contractok programok, így elméletileg bármilyen erőforrást felhasználhatnak: cpu/memória/hálózat/tárhely, ezért a tranzakciók feldolgozása egy meglehetősen bizonytalan szakasz, amely ráadásul jelentősen változik a verziók közötti váltáskor és a szerződések kódjának módosításakor. Ezért a tranzakciók feldolgozására vonatkozó metrikák is szükségesek a blokklánc teljesítményének hatékony optimalizálásához.

Ügyfél értesítése a tranzakció blokkláncra való aktiválásáról

Ez a blokklánc szolgáltatás ügyféltől való megszerzésének végső szakasza. Más szakaszokkal összehasonlítva itt nincsenek jelentős költségek, de figyelembe kell venni a lehetőséget, hogy az ügyfél volumentekintetben nagy válaszokat kap a csomóponttól (például okos szerződés, amely adatokat ad vissza tömb formájában). Mindenesetre ez a pillanat a legfontosabb azon kérdés szempontjából, hogy „mennyi TPS van a blokkláncotokban?”, mert ezen a ponton rögzül a szolgáltatás megszerzésének ideje.

Ez a szakasz kötelezően tartalmazza a teljes időt, amelyet az ügyfél a blokklánctól való válaszra való várakozásra fordított, ezt az időt a felhasználó az alkalmazásában a megerősítés várakozásaként fogja értelmezni, és ennek optimalizálása a fejlesztők fő feladata.

Zárás

Ennek eredményeképpen leírhatók a blokkláncokban végrehajtott műveletek típusai, és ezek több kategóriába sorolhatók:

kriptográfiai konverziók, bizonyítékok készítése
peer-to-peer hálózatépítés, tranzakciók és blokkok replikációja
tranzakciók feldolgozása, okos szerződések végrehajtása
változások alkalmazása a blokkláncra állapot adatbázisra, tranzakciók és blokkok adataik frissítése
csak olvasható lekérdezések állapot adatbázisra, blokklánc csomópont API, előfizetési szolgáltatások

Általánosságban elmondható, hogy a modern blokkláncok csomópontjaira vonatkozó technikai követelmények rendkívül szigorúak — gyors CPU-k a kriptográfiához, nagy mennyiségű RAM a state database tárolásához és gyors eléréséhez, hálózati interakció, amely sok párhuzamos kapcsolatra épít, és jelentős tárhely. Ezek a magas követelmények és a különböző típusú műveletek bősége elkerülhetetlenül azt eredményezi, hogy a csomópontok erőforrásai nem elegendőek, és ebben az esetben bármelyik fent említett lépés a hálózat teljesítményének szűk keresztmetszetévé válhat.

A blokkláncok teljesítményének kidolgozásakor és értékelésekor figyelembe kell venni ezeket a szempontokat. Ehhez gyűjteni és elemezni kell a metrikákat a kliensektől és a hálózat csomópontjaitól egyidejűleg, keresni kell a kölcsönhatásokat, értékelni a szolgáltatások ügyfeleknek történő biztosításának idejét, figyelembe kell venni az összes alapvető erőforrást: cpu/memória/hálózat/tárolás, megérteni, hogyan használják ezeket és hogyan befolyásolják egymást. Mindez rendkívül nehézzé teszi különböző blokkláncok sebességeinek összehasonlítását olyan formában, hogy „mennyi TPS”, mivel számos különböző konfiguráció és állapot létezik. Nagy központosított rendszerekben, száz szerverből álló klaszterekben ezek a problémák szintén bonyolultak és nagy mennyiségű különböző metrika gyűjtését igénylik, de a blokkláncok esetében, a p2p hálózatok, virtuális gépek, intelligens szerződések, belső gazdaság miatt a szabadság foka sokkal magasabb, ami miatt még néhány szerveren végzett tesztelés is nem reprezentatív és csupán rendkívül durva értékeket mutat, amelyek alig kapcsolódnak a valósághoz.

Ezért, amikor a blokklánc magjában dolgozunk, a teljesítmény értékeléséhez és az „javult-e az előző alkalomhoz képest” kérdés megválaszolásához meglehetősen összetett szoftvert használunk, amely koordinálja a blokklánc elindítását sok csomóponttal és automatikus benchmark futtatással, valamint metrikák gyűjtésével. E nélkül az információ nélkül rendkívül nehéz debuggolni a protokollokat, amelyek sok résztvevővel működnek.

Így, ha megkérdezik, „mennyi TPS van a blokkláncodban?”, ajánlj fel a beszélgetőpartnernek egy csésze teát, és pontosan derítsd ki, hogy hajlandó-e megismerkedni egy tucat grafikkal, valamint meghallgatni a blokkláncok teljesítményének problémáival kapcsolatos három doboz problémát és a megoldásokra vonatkozó javaslataidat...

Forrás: habr.com