Egy nem műszaki személy kedvenc kérdése minden elosztott rendszerrel kapcsolatban: „Hány tps van a blokkláncon?” A válaszként megadott szám azonban általában kevéssé hasonlít ahhoz, amit a kérdező hallani szeretne. Valójában azt akarta kérdezni, hogy „megfelel-e a blokkláncod az üzleti követelményeimnek”, és ezek a követelmények nem egy szám, hanem sok feltétel – itt van a hálózati hibatűrés, a véglegességi követelmények, a méretek, a tranzakciók jellege és sok más paraméter. Tehát a „hány tps” kérdésre adott válasz valószínűleg nem lesz egyszerű, és szinte soha nem teljes. Egy elosztott rendszer több tíz vagy száz csomóponttal, amelyek meglehetősen bonyolult számításokat végeznek, nagyon sok különböző állapotban lehet a hálózat állapotától, a blokklánc tartalmától, műszaki hibáktól, gazdasági problémáktól, a hálózatot ért támadásoktól és sok más okból. . A teljesítményproblémák lehetséges szakaszai eltérnek a hagyományos szolgáltatásoktól, és a blokklánc hálózati szerver egy olyan hálózati szolgáltatás, amely egyesíti az adatbázis, a webszerver és a torrent kliens funkcionalitását, ami rendkívül bonyolulttá teszi az összes alrendszer terhelési profilját tekintve. : processzor, memória, hálózat, tároló

Előfordul, hogy a decentralizált hálózatok és blokkláncok meglehetősen specifikus és szokatlan szoftverek a központosított szoftverfejlesztők számára. Ezért szeretném kiemelni a decentralizált hálózatok teljesítményének és fenntarthatóságának fontos szempontjait, a mérési módszereket és a szűk keresztmetszetek feltárását. Megvizsgálunk különféle teljesítményproblémákat, amelyek korlátozzák a szolgáltatásnyújtás sebességét a blokklánc-felhasználók számára, és megjegyezzük az ilyen típusú szoftverekre jellemző funkciókat.

A blokklánc kliens szolgáltatásigénylésének szakaszai

Ahhoz, hogy egy többé-kevésbé összetett szolgáltatás minőségéről őszintén beszéljünk, nemcsak az átlagértékeket kell figyelembe venni, hanem a maximumot/minimumot, a mediánokat, százalékokat is. Elméletileg 1000 tps-ről beszélhetünk néhány blokkláncban, de ha 900 tranzakciót óriási sebességgel hajtottak végre, és 100 néhány másodpercre „ragadt”, akkor az összes tranzakcióra összegyűjtött átlagos idő nem teljesen korrekt mérőszám egy ügyfél számára. akit nem tudtam néhány másodperc alatt befejezni a tranzakciót. Az elmulasztott konszenzusos fordulók vagy hálózati felosztások által okozott ideiglenes „lyukak” nagymértékben tönkretehetik a tesztpadon kiváló teljesítményt mutató szolgáltatást.

Az ilyen szűk keresztmetszetek azonosításához jól meg kell értenünk azokat a szakaszokat, amelyekben egy valódi blokkláncnak nehézségei lehetnek a felhasználók kiszolgálásában. Ismertesse a tranzakció kézbesítésének és feldolgozásának ciklusát, valamint a blokklánc új állapotának megszerzését, amelyből az ügyfél ellenőrizheti, hogy tranzakciója feldolgozásra és elszámolásra került.

a tranzakció az ügyfélen jön létre
a tranzakciót aláírják az ügyfélen
az ügyfél kiválasztja az egyik csomópontot, és elküldi a tranzakcióját
a kliens feliratkozik a csomópont állapotadatbázisának frissítésére, megvárva a tranzakció eredményeinek megjelenését
a csomópont elosztja a tranzakciót a p2p hálózaton
több vagy egy BP (blokkgyártó) feldolgozza a felhalmozott tranzakciókat, frissíti az állapotadatbázist
A BP a szükséges számú tranzakció feldolgozása után új blokkot képez
A BP egy új blokkot oszt el a p2p hálózaton
az új blokkot arra a csomópontra szállítják, amelyhez az ügyfél hozzáfér
csomópont frissíti az állapotadatbázist
a csomópont látja az ügyfélre vonatkozó frissítést, és tranzakciós értesítést küld neki

Most nézzük meg közelebbről ezeket a szakaszokat, és írjuk le az egyes szakaszok lehetséges teljesítményproblémáit. A központosított rendszerekkel ellentétben figyelembe vesszük a kódvégrehajtást a hálózati klienseken is. A TPS mérése során gyakran a tranzakció feldolgozási idejét a csomópontoktól gyűjtik, és nem az ügyféltől - ez nem teljesen igazságos. Az ügyfelet nem érdekli, hogy a csomópont milyen gyorsan dolgozta fel tranzakcióját, számára a legfontosabb az a pillanat, amikor a blokkláncban szereplő tranzakcióról megbízható információ válik elérhetővé számára. Ez a mutató lényegében a tranzakció végrehajtási ideje. Ez azt jelenti, hogy a különböző kliensek, akár ugyanazt a tranzakciót küldik, teljesen eltérő időpontokat kaphatnak, ami függ a csatornától, a csomópont terhelésétől, közelségétől stb. Ezért feltétlenül szükséges ezt az időt a klienseken mérni, hiszen ez az a paraméter, amit optimalizálni kell.

Ügyféloldali tranzakció előkészítése

Kezdjük az első két ponttal: a tranzakciót az ügyfél alakítja és írja alá. Furcsa módon ez a blokklánc teljesítményének szűk keresztmetszete is lehet az ügyfél szemszögéből. Ez szokatlan a központosított szolgáltatásoknál, amelyek minden számítást és adatkezelést átvesznek, és a kliens egyszerűen elkészít egy rövid kérést, amely nagy mennyiségű adatot vagy számítást kérhet, így kész eredményt kap. A blokkláncokban a kliens kód egyre erősebbé válik, a blokklánc mag pedig egyre könnyebbé válik, és a hatalmas számítási feladatok általában átkerülnek a kliens szoftverre. A blokkláncokban vannak olyan kliensek, akik elég hosszú ideig tudnak egy tranzakciót előkészíteni (különféle merkle bizonyításokról, tömör bizonyításokról, küszöb aláírásokról és egyéb bonyolult műveletekről beszélek az ügyféloldalon). Jó példa a könnyű láncon belüli ellenőrzésre és a tranzakció nehéz előkészítésére az ügyfélen a Merkle-fa alapú listán való tagság igazolása, itt cikk.

Azt sem szabad elfelejteni, hogy a klienskód nem egyszerűen tranzakciókat küld a blokkláncnak, hanem először lekérdezi a blokklánc állapotát – és ez a tevékenység hatással lehet a hálózat és a blokklánc csomópontok torlódására. Tehát a mérések során célszerű a kliens kód viselkedését a lehető legteljesebb mértékben emulálni. Még ha a blokkláncodban vannak olyan egyszerű kliensek is, akik a legegyszerűbb tranzakciónál rendes digitális aláírást adnak át valamilyen eszköz átruházására, évről évre egyre nagyobb számításokat végeznek az ügyfélen, a titkosítási algoritmusok egyre erősebbek, és a feldolgozásnak ez a része jelentős szűk keresztmetszetté válik a jövőben. Ezért legyen óvatos, és ne hagyja ki azt a helyzetet, amikor egy 3.5 másodpercig tartó tranzakciónál 2.5 másodpercet a tranzakció előkészítésére és aláírására fordítanak, 1.0 másodpercet pedig a hálózatba küldésre és a válasz várására. Ennek a szűk keresztmetszetnek a kockázatainak felméréséhez mérőszámokat kell gyűjtenie az ügyfélgépekről, nem csak a blokklánc csomópontokról.

Tranzakció küldése és állapotának figyelése

A következő lépés az, hogy elküldjük a tranzakciót a kiválasztott blokklánc csomópontnak, és megkapjuk az elfogadás állapotát a tranzakciókészletbe. Ez a szakasz hasonló a szokásos adatbázis-hozzáféréshez: a csomópontnak rögzítenie kell a tranzakciót a készletben, és el kell kezdenie az információk terjesztését a p2p hálózaton keresztül. A teljesítmény értékelésének megközelítése itt hasonló a hagyományos Web API mikroszolgáltatások teljesítményének értékeléséhez, és maguk a blokkláncokban lévő tranzakciók frissíthetők és aktívan megváltoztathatók állapotuk. Általánosságban elmondható, hogy egyes blokkláncokon a tranzakciós információk frissítése többször is megtörténhet, például a láncvillák közötti váltáskor, vagy amikor a BP-k bejelentik, hogy szándékukat felvenni egy tranzakciót egy blokkba. A készlet méretének és a benne lévő tranzakciók számának korlátozása befolyásolhatja a blokklánc teljesítményét. Ha a tranzakciós készlet a lehető legnagyobb méretre meg van töltve, vagy nem fér bele a RAM-ba, a hálózati teljesítmény meredeken csökkenhet. A blokkláncoknak nincs központosított védelmük a kéretlen üzenetek özönével szemben, és ha a blokklánc támogatja a nagy volumenű tranzakciókat és az alacsony díjakat, ez a tranzakciós készlet túlcsordulását okozhatja, ami egy másik potenciális szűk keresztmetszet a teljesítményben.

A blokkláncokban a kliens bármely neki tetsző blokklánc csomópontra küld egy tranzakciót, a tranzakció hash-ét általában az ügyfél ismeri az elküldés előtt, így nem kell mást tennie, mint elérni a kapcsolatot, és az átvitel után megvárni, amíg a blokklánc megváltozik. állapotát, lehetővé téve a tranzakciót. Vegye figyelembe, hogy a „tps” mérésével teljesen eltérő eredményeket kaphat a blokklánc-csomóponthoz való csatlakozás különböző módszereinél. Ez lehet egy normál HTTP RPC vagy egy WebSocket, amely lehetővé teszi az „előfizetés” minta megvalósítását. A második esetben a kliens korábban kap értesítést, és a csomópont kevesebb erőforrást (főleg memóriát és forgalmat) fordít a tranzakció állapotára vonatkozó válaszokra. Tehát a „tps” mérésekor figyelembe kell venni, hogy az ügyfelek hogyan csatlakoznak a csomópontokhoz. Ezért a szűk keresztmetszet kockázatainak felméréséhez a benchmark blokkláncnak képesnek kell lennie arra, hogy a valós hálózatoknak megfelelő arányban emulálja a klienseket WebSocket és HTTP RPC kérések esetén, valamint módosítsa a tranzakciók jellegét és méretét.

A szűk keresztmetszet kockázatainak felméréséhez nem csak a blokklánc csomópontjairól, hanem az ügyfélgépekről is mérőszámokat kell gyűjtenie.

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

A blokkláncokban a peer-to-peer (p2p) hálózatot használják a tranzakciók és blokkok átvitelére a résztvevők között. A tranzakciók az egész hálózaton elterjednek, az egyik csomóponttól kezdve, egészen addig, amíg el nem érik a peer blokk-előállítókat, akik blokkokba csomagolják a tranzakciókat, és ugyanazt a p2p-t használva új blokkokat osztanak szét az összes hálózati csomóponthoz. A legtöbb modern p2p hálózat alapja a Kademlia protokoll különféle módosításai. Itt ennek a protokollnak egy jó összefoglalása, és itt - egy cikk a BitTorrent hálózatban különböző mérésekkel, amiből megérthető, hogy ez a fajta hálózat bonyolultabb és kevésbé kiszámítható, mint egy központi szolgáltatás mereven konfigurált hálózata. Is, itt cikk az Ethereum csomópontok különféle érdekes mérőszámainak méréséről.

Röviden, az ilyen hálózatokban minden peer fenntartja a saját dinamikus listáját a többi peer-ről, amelytől információblokkokat kér, amelyeket a tartalom címez. Amikor egy partner megkapja a kérést, megadja a szükséges információkat, vagy továbbítja a kérést a listából következő pszeudo-véletlen partnernek, majd miután megkapta a választ, továbbítja azt a kérelmezőnek, és egy ideig gyorsítótárba helyezi. a következő alkalommal korábban. Így a népszerű információk nagyszámú partner nagyszámú gyorsítótárába kerülnek, és a népszerűtlen információk fokozatosan lecserélődnek. A partnerek nyilvántartást vezetnek arról, hogy ki mennyi információt adott át kinek, a hálózat pedig igyekszik ösztönözni az aktív terjesztőket minősítésük növelésével és magasabb szintű szolgáltatással, automatikusan kiszorítva az inaktív résztvevőket a peer listákról.

Tehát a tranzakciót most el kell terjeszteni a hálózaton, hogy a blokkgyártók láthassák és belefoglalhassák a blokkba. A csomópont aktívan „eloszt” egy új tranzakciót mindenkinek, és figyeli a hálózatot, várva egy blokkot, amelynek indexében megjelenik a kívánt tranzakció, hogy értesítse a várakozó klienst. Az, hogy mennyi időbe telik a hálózatnak az új tranzakciókról és blokkokról való információ továbbítása egymásnak a p2p hálózatokban, nagyon sok tényezőtől függ: a közelben dolgozó becsületes csomópontok számától (hálózati szempontból), a „meleg- felfelé” ezen csomópontok gyorsítótárairól, a blokkok méretéről, a tranzakciókról, a változások természetéről, a hálózat földrajzi elhelyezkedéséről, a csomópontok számáról és sok más tényezőről. A teljesítménymutatók komplex mérése az ilyen hálózatokban összetett dolog, egyszerre kell értékelni a kérések feldolgozási idejét mind a klienseken, mind a partnereken (blokklánc csomópontok). Bármelyik p2p-mechanizmus problémái, helytelen adatkiürítés és gyorsítótár, az aktív partnerek listáinak nem hatékony kezelése és sok más tényező okozhat késéseket, amelyek befolyásolják a teljes hálózat egészének hatékonyságát, és ezt a szűk keresztmetszetet a legnehezebb elemezni. , teszt és az eredmények értelmezése.

Blockchain feldolgozás és állapotadatbázis frissítés

A blokklánc legfontosabb része a konszenzus algoritmus, annak alkalmazása a hálózatból érkező új blokkokra és a tranzakciók feldolgozása az eredmények rögzítésével az állapotadatbázisban. Új blokk hozzáadása a lánchoz, majd a főlánc kiválasztása a lehető leggyorsabban működjön. A való életben azonban a „kell” nem azt jelenti, hogy „működik”, és például elképzelhető egy olyan helyzet, amikor két hosszú, egymással versengő lánc folyamatosan vált egymás között, és minden egyes váltáskor megváltoztatja a poolban lévő tranzakciók ezreinek metaadatait. , és folyamatosan visszagörgetjük az állami adatbázist. Ez a szakasz a szűk keresztmetszet meghatározása szempontjából egyszerűbb, mint a p2p hálózati réteg, mert A tranzakció végrehajtása és a konszenzusos algoritmus szigorúan determinisztikus, és itt könnyebb bármit mérni.
A lényeg az, hogy ne keverjük össze a véletlenszerű leromlását ebben a szakaszban a hálózati problémákkal - a csomópontok lassabban szállítanak blokkokat és információkat a főláncról, és egy külső kliens számára ez lassú hálózatnak tűnhet, bár a probléma abban rejlik. teljesen más hely.

A teljesítmény optimalizálása érdekében ebben a szakaszban célszerű mérőszámokat begyűjteni és figyelni magukról a csomópontokról, és belefoglalni az állapot-adatbázis frissítéséhez kapcsolódó adatokat: a csomóponton feldolgozott blokkok számát, méretét, tranzakciók számát, a láncvillák közötti átkapcsolások száma, az érvénytelen blokkok száma, a virtuális gép működési ideje, az adatok véglegesítési ideje stb. Ez megakadályozza, hogy a hálózati problémákat összekeverjék a láncfeldolgozási algoritmusok hibáival.

A tranzakciókat feldolgozó virtuális gép hasznos információforrás lehet, amely optimalizálhatja a blokklánc működését. A memóriafoglalások száma, az olvasási/írási utasítások száma és egyéb, a szerződéskód végrehajtásának hatékonyságával kapcsolatos mérőszámok sok hasznos információval szolgálhatnak a fejlesztők számára. Ugyanakkor az intelligens szerződések programok, ami azt jelenti, hogy elméletileg az erőforrások bármelyikét felemésztik: cpu/memória/hálózat/tárhely, így a tranzakciók feldolgozása egy meglehetősen bizonytalan szakasz, ami ráadásul a verziók közötti mozgás során is nagymértékben megváltozik. és a szerződési kódok megváltoztatásakor. Ezért a tranzakciófeldolgozással kapcsolatos mérőszámokra is szükség van a blokklánc teljesítményének hatékony optimalizálásához.

Ügyféltől kapott értesítés egy tranzakció blokkláncba történő felvételéről

Ez az utolsó szakasza annak, hogy a blokklánc kliens megkapja a szolgáltatást, a többi szakaszhoz képest nincs nagy rezsiköltség, de még mindig érdemes mérlegelni annak lehetőségét, hogy a kliens terjedelmes választ kapjon a csomóponttól (például okos szerződést). egy adattömb visszaadása). Mindenesetre ez a pont a legfontosabb annak, aki feltette a „hány tps van a blokkláncodban?” kérdést, mert Ebben a pillanatban rögzítésre kerül a szolgáltatás átvételének időpontja.

Ezen a helyen mindig megtörténik a teljes idő elküldése, amelyet az ügyfélnek a blokklánc válaszára várva kellett töltenie; ekkor a felhasználó a megerősítést várja az alkalmazásában, és ennek optimalizálása a a fejlesztők fő feladata.

Következtetés

Ennek eredményeként leírhatjuk a blokkláncokon végzett műveletek típusait, és több kategóriába sorolhatjuk őket:

kriptográfiai transzformációk, proof konstrukció
peer-to-peer hálózat, tranzakció és blokk replikáció
tranzakció feldolgozás, okos szerződések végrehajtása
a blokklánc változásainak alkalmazása az állapotadatbázisban, a tranzakciók és blokkok adatainak frissítése
csak olvasható kérések állapotadatbázishoz, blokklánc csomópont API-hoz, előfizetési szolgáltatásokhoz

Általánosságban elmondható, hogy a modern blokklánc-csomópontok műszaki követelményei rendkívül komolyak - gyors CPU-k kriptográfiához, nagy mennyiségű RAM az állapotadatbázis tárolására és gyors eléréséhez, hálózati interakció nagyszámú, egyidejűleg nyitott kapcsolat használatával és nagy tárhely. Az ilyen magas követelmények és a különféle típusú műveletek bősége elkerülhetetlenül oda vezet, hogy a csomópontok nem rendelkeznek elegendő erőforrással, és akkor a fent tárgyalt szakaszok bármelyike újabb szűk keresztmetszetet jelenthet a teljes hálózati teljesítményben.

A blokkláncok tervezése és teljesítményének értékelése során mindezeket a szempontokat figyelembe kell vennie. Ehhez egyidejűleg kell összegyűjteni és elemezni a mérőszámokat az ügyfelektől és a hálózati csomópontoktól, keresni kell a köztük lévő összefüggéseket, meg kell becsülni az ügyfelek kiszolgálásához szükséges időt, figyelembe kell venni az összes fő erőforrást: cpu/memória/hálózat/tárhely , megértsék, hogyan használják őket, és befolyásolják egymást. Mindez rendkívül hálátlan feladattá teszi a különböző blokkláncok sebességének összehasonlítását „hány TPS” formájában, hiszen rengeteg különböző konfiguráció és állapot létezik. Nagy központosított rendszerekben, több száz szerverből álló klaszterekben ezek a problémák szintén összetettek, és szintén nagyszámú különböző mérőszám gyűjtését igénylik, de a blokkláncokban a p2p hálózatok, a szerződéseket feldolgozó virtuális gépek, a belső gazdaságosság, a fokszámok miatt. A szabadság sokkal nagyobb, ami miatt a teszt akár több szerveren is megtörténik, nem jelzésértékű, és csak rendkívül közelítő értékeket mutat, amelyeknek szinte semmi közük a valósághoz.

Ezért a blokklánc magban történő fejlesztés során a teljesítmény értékeléséhez és a „javult-e a legutóbbihoz képest?” kérdés megválaszolásához meglehetősen összetett szoftvert használunk, amely levezényli egy blokklánc elindítását több tucat csomóponttal, és automatikusan elindít egy benchmarkot és mérőszámokat gyűjt. Ezen információk nélkül rendkívül nehéz a több résztvevővel működő protokollok hibakeresése.

Tehát, amikor megkapja a kérdést: „Hány TPS van a blokkláncodban?”, kínáld meg a beszélgetőpartneredet egy teával, és kérdezd meg, hogy készen áll-e megnézni egy tucat grafikont, és meghallgatni a blokklánc teljesítményproblémák mindhárom dobozát és az Ön javaslatait. megoldani őket...

Forrás: will.com

Hány TPS van a blokkláncodban?