Miért nehéz mérni a blokklánc teljesítményét?

A teljesítmény és a skálázhatóság sokat vitatott kihívások a kriptográfiai térben, mind az 1. rétegbeli projektek (független blokkláncok), mind a 2. rétegbeli megoldások (mint például a rollupok és a láncon kívüli csatornák) szempontjából. Mégsem rendelkezünk szabványosított mérőszámokkal vagy benchmarkokkal. A számokat gyakran következetlen és hiányos módon jelentik, ami megnehezíti a projektek pontos összehasonlítását, és gyakran elfedi azt, ami a gyakorlatban a legfontosabb. 

Árnyaltabb és alaposabb megközelítésre van szükségünk a teljesítmény mérésére és összehasonlítására – olyanra, amely a teljesítményt több összetevőre bontja, és több tengelyen összehasonlítja a kompromisszumokat. Ebben a bejegyzésben meghatározom az alapvető terminológiát, felvázolom a kihívásokat, valamint irányelveket és kulcsfontosságú elveket ajánlok, amelyeket szem előtt kell tartani a blokklánc teljesítményének értékelésekor. 

Skálázhatóság kontra teljesítmény

Először is definiáljunk két fogalmat, a méretezhetőséget és a teljesítményt, amelyek szabványos számítástechnikai jelentéssel bírnak, amelyeket gyakran visszaélnek blokklánc-kontextusban. teljesítmény méri, hogy mi a rendszer jelenleg képes elérni. Amint azt alább tárgyaljuk, a teljesítménymutatók tartalmazhatják a másodpercenkénti tranzakciókat vagy a tranzakció-visszaigazolási idő mediánját. skálázhatóság, másrészt méri a a rendszer képessége a teljesítmény javítására erőforrások hozzáadásával.

Ez a megkülönböztetés fontos: A teljesítmény javításának számos megközelítése egyáltalán nem javítja a méretezhetőséget, ha megfelelően meghatározzák. Egy egyszerű példa egy hatékonyabb digitális aláírási séma, például a BLS aláírások használata, amelyek nagyjából feleakkoraak, mint a Schnorr vagy az ECDSA aláírások. Ha a Bitcoin áttérne az ECDSA-ról a BLS-re, a blokkonkénti tranzakciók száma 20-30%-kal nőhet, javítva a teljesítményt egyik napról a másikra. De ezt csak egyszer tehetjük meg – nincs még helytakarékosabb aláírási séma, amelyre váltani lehetne (a BLS-aláírások aggregálhatók is, hogy több helyet takarítsunk meg, de ez egy újabb egyszeri trükk).

Számos egyéb egyszeri trükk (például a SegWit) lehetséges a blokkláncokban, de a teljesítmény folyamatos javításához méretezhető architektúrára van szükség, ahol több erőforrás hozzáadásával idővel javul a teljesítmény. Ez a hagyományos bölcsesség sok más számítógépes rendszerben is, például egy webszerver építésében. Néhány gyakori trükkel egy nagyon gyors szervert építhet fel; de végső soron olyan többkiszolgálós architektúrára van szükség, amely képes kielégíteni az egyre növekvő igényeket azáltal, hogy folyamatosan hozzáadja a további szervereket.

A megkülönböztetés megértése segít elkerülni a gyakori kategóriahibákat, amelyek az olyan kijelentésekben találhatók, mint: „A Blockchain X nagyon skálázható, másodpercenként Y tranzakciót tud kezelni!” A második állítás lenyűgöző lehet, de ez a teljesítmény metrika, nem skálázhatósági mérőszám. Nem beszél arról, hogy erőforrások hozzáadásával javítható-e a teljesítmény.

A skálázhatóság eleve megköveteli a párhuzamosság kihasználását. A blokklánc térben úgy tűnik, hogy az 1. rétegbeli skálázás felosztást igényel, vagy olyasmit, ami felosztásnak tűnik. A sharding alapkoncepciója – az állapot felosztása, hogy a különböző validátorok egymástól függetlenül dolgozhassanak – szorosan illeszkedik a skálázhatóság definíciójához. A 2. rétegben még több lehetőség található, amelyek lehetővé teszik a párhuzamos feldolgozás hozzáadását – beleértve a láncon kívüli csatornákat, az összesítő szervereket és az oldalláncokat.

Késés/áteresztőképesség

Klasszikusan a blokklánc rendszer teljesítményét két dimenzióban, a késleltetésben és az áteresztőképességben értékelik: a késleltetés azt méri, hogy egy egyedi tranzakció milyen gyorsan erősíthető meg, míg az átviteli sebesség a tranzakciók összesített arányát méri az idő függvényében. Ezek a tengelyek egyaránt vonatkoznak az 1. és 2. rétegű rendszerekre, valamint sok más típusú számítógépes rendszerre (például adatbázis-lekérdező motorokra és webszerverekre).

Sajnos mind a késleltetést, mind az átviteli sebességet bonyolult mérni és összehasonlítani. Ezenkívül az egyes felhasználókat valójában nem érdekli az átviteli sebesség (ami egy rendszerszintű intézkedés). Ami igazán érdekli őket, az a késleltetés és a tranzakciós díjak – pontosabban az, hogy tranzakcióikat a lehető leggyorsabban és a lehető legolcsóbban visszaigazolják. Bár sok más számítógépes rendszert is költség/teljesítmény alapon értékelnek, a tranzakciós díjak némileg új teljesítménytengelyt jelentenek a blokklánc rendszerek számára, amelyek a hagyományos számítógépes rendszerekben nem igazán léteznek.

Kihívások a látencia mérésében

A késleltetés elsőre egyszerűnek tűnik: mennyi ideig tart a tranzakció megerősítése? De mindig többféleképpen lehet válaszolni erre a kérdésre.

Először is megmérhetjük a késleltetést a különböző időpontok között, és különböző eredményeket kaphatunk. Például akkor kezdjük el mérni a késleltetést, amikor a felhasználó helyileg megnyom egy „elküld” gombot, vagy amikor a tranzakció eléri a mempoolt? És akkor állítjuk meg az órát, amikor a tranzakció egy javasolt blokkban van, vagy ha egy blokkot egy vagy hat követési blokkal megerősítenek?

A legelterjedtebb megközelítés az érvényesítők álláspontját képviseli, amely attól az időponttól kezdve mérhető, amikor az ügyfél először közvetíti a tranzakciót, egészen addig az időpontig, amíg a tranzakció ésszerűen „megerősítik” (abban az értelemben, hogy a valós kereskedők úgy tekintenék, hogy beérkezett a fizetés, és kiadják az árut) . Természetesen a különböző kereskedők eltérő elfogadási feltételeket alkalmazhatnak, és akár egyetlen kereskedő is eltérő szabványokat alkalmazhat a tranzakció összegétől függően.

A validátor-központú megközelítés több olyan dolgot kihagy, ami a gyakorlatban számít. Először is figyelmen kívül hagyja a peer-to-peer hálózat késleltetését (mennyi idő telik el attól, hogy a kliens egy tranzakciót sugároz addig, amíg a legtöbb csomópont meghallotta?) és az ügyféloldali késleltetést (mennyi ideig tart a tranzakció előkészítése) az ügyfél helyi gépén?). Az ügyféloldali késleltetés nagyon kicsi és kiszámítható egyszerű tranzakciók, például Ethereum-fizetés aláírása esetén, de jelentős lehet bonyolultabb esetekben, például a védett Zcash-tranzakció helyességének bizonyítása esetén.

Még ha szabványosítottuk is a késleltetéssel mérni kívánt időablakot, a válasz szinte mindig az ez attól függ,. Egyetlen kriptovaluta rendszer sem kínált rögzített tranzakciós késleltetést. Egy alapvető hüvelykujjszabály, amelyet emlékezni kell:

A késleltetés egy eloszlás, nem egyetlen szám.

A hálózatépítő kutatói közösség már régóta megértette ezt (lásd például ezt kiváló beszéd Gil Tene-től). Különös hangsúlyt kap a disztribúció „hosszú farka”, mivel a nagyon megnövekedett késleltetés a tranzakciók (vagy webszerver-lekérdezések) akár 0.1%-ánál is súlyosan megviseli. hatás végfelhasználó.

A blokkláncoknál a megerősítési késleltetés számos okból változhat:

Adagolás: a legtöbb rendszer valamilyen módon kötegelt tranzakciókat hajt végre, például a legtöbb Layer 1 rendszeren blokkokba. Ez változó késleltetéshez vezet, mivel egyes tranzakcióknak meg kell várniuk, amíg a köteg megtelik. Másoknak szerencséje lehet, és utoljára csatlakoznak a csoporthoz. Ezek a tranzakciók azonnal megerősítésre kerülnek, és nem tapasztalnak további késést.

Változó torlódás: a legtöbb rendszer torlódástól szenved, ami azt jelenti, hogy több tranzakció kerül feladásra (legalábbis bizonyos esetekben), mint amennyit a rendszer azonnal kezelni tud. A zsúfoltság mértéke változhat, ha a tranzakciókat előre nem látható időpontokban sugározzák (gyakran absztrahálva Poisson folyamat), vagy ha az új tranzakciók aránya a nap vagy a hét folyamán változik, vagy külső eseményekre, például egy népszerű NFT-bevezetésre reagálva.

Konszenzusos rétegbeli eltérés: Egy tranzakció megerősítéséhez az 1. rétegen általában egy elosztott csomópontkészletre van szükség ahhoz, hogy konszenzusra jussanak egy blokkról, amely a torlódástól függetlenül változó késleltetéseket adhat hozzá. A munkabizonyítási rendszerek előre nem látható időpontokban találnak blokkokat (szintén absztrakt Poisson-folyamat). A tét-ellenőrző rendszerek különféle késleltetéseket is hozzáadhatnak (például ha nem elegendő számú csomópont van online egy bizottság létrehozásához egy körben, vagy ha nézetmódosításra van szükség egy vezető összeomlásakor).

Ezen okok miatt egy jó iránymutatás a következő:

A várakozási idővel kapcsolatos állításoknak a megerősítési idők eloszlását (vagy hisztogramját) kell bemutatniuk, nem pedig egyetlen számot, például az átlagot vagy a mediánt.

Míg az összefoglaló statisztikák, például az átlag, a medián vagy a százalékos értékek részleges képet adnak, a rendszer pontos értékeléséhez a teljes eloszlást figyelembe kell venni. Egyes alkalmazásokban az átlagos késleltetés jó betekintést nyújthat, ha a várakozási idő eloszlása ​​viszonylag egyszerű (például Gauss-féle). De a kriptovalutában ez szinte soha nem így van: Általában a lassú megerősítési időknek hosszú a vége.

Jó példa erre a fizetési csatorna hálózatok (pl. Lightning Network). A klasszikus L2 skálázási megoldások ezek a hálózatok legtöbbször nagyon gyors fizetési visszaigazolást kínálnak, de esetenként csatorna-visszaállítást igényelnek, ami nagyságrendekkel növelheti a késleltetést.

És még ha jó statisztikákkal is rendelkezünk a pontos késleltetési eloszlásról, ezek valószínűleg idővel változni fognak, ahogy a rendszer és a rendszer iránti igény változik. Az sem mindig világos, hogyan lehet összehasonlítani a késleltetési eloszlásokat a versengő rendszerek között. Vegyünk például egy olyan rendszert, amely egyenletesen elosztott késleltetéssel erősíti meg a tranzakciókat 1 és 2 perc között (90 másodperces átlaggal és mediánnal). Ha egy versengő rendszer a tranzakciók 95%-át 1 perc alatt pontosan, a másik 5%-át pedig 11 percen belül igazolja vissza (átlag 90 másodperc és 60 másodperces medián), melyik rendszer a jobb? A válasz valószínűleg az, hogy egyes alkalmazások az előbbit, mások pedig az utóbbit részesítik előnyben.

Végül fontos megjegyezni, hogy a legtöbb rendszerben nem minden tranzakció egyenlő prioritást kap. A felhasználók többet fizethetnek azért, hogy magasabb prioritást kapjanak a bevonásért, így a fentiek mellett a késleltetés a fizetett tranzakciós díjak függvényében változik. Összefoglalva:

A késleltetés összetett. Minél több adatot közölnek, annál jobb. Ideális esetben a teljes késleltetési eloszlásokat különböző torlódási körülmények között kell mérni. A késleltetés különböző összetevőkre történő lebontása (helyi, hálózati, kötegelés, konszenzusos késleltetés) szintén hasznos.

Kihívások az áteresztőképesség mérésében

Az áteresztőképesség is első pillantásra egyszerűnek tűnik: hány tranzakciót tud feldolgozni egy rendszer másodpercenként? Két elsődleges nehézség merül fel: mi is az a „tranzakció”, és azt mérjük-e, mit csinál egy rendszer ma, vagy mire lenne képes?

Míg a „tranzakciók másodpercenként” (vagy tps) de facto szabvány a blokklánc teljesítményének mérésére, a tranzakciók mértékegységként problematikusak. Az általános célú programozhatóságot („intelligens szerződések”) vagy akár korlátozott funkciókat kínáló rendszerek esetében, mint például a Bitcoin multiplex tranzakciói vagy a többjeles ellenőrzés lehetőségei, az alapvető probléma a következő:

Nem minden tranzakció egyenlő.

Ez nyilvánvalóan igaz az Ethereumra, ahol a tranzakciók tetszőleges kódot tartalmazhatnak, és tetszőlegesen módosíthatják az állapotot. A gáz fogalmát az Ethereumban a tranzakció által végzett munka teljes mennyiségének számszerűsítésére (és díjak felszámítására) használják, de ez erősen az EVM végrehajtási környezetre jellemző. Nincs egyszerű módja annak, hogy összehasonlítsuk az EVM-tranzakciók készlete által végzett munka teljes mennyiségét mondjuk egy Solana-tranzakciókészlettel a BPF-környezet használatával. Bármelyik bitcoin-tranzakcióval való összehasonlítása is hasonlóan nehézkes.

A tranzakciós réteget konszenzusos rétegre és végrehajtási rétegre szétválasztó blokkláncok ezt egyértelműbbé tehetik. A (tiszta) konszenzusos rétegben az áteresztőképesség mértékegységben a lánchoz adott bájtokban mérhető. A végrehajtási réteg mindig összetettebb lesz.

Az egyszerűbb végrehajtási rétegek, például az összesítő szerverek, amelyek csak fizetési tranzakciókat támogatnak, elkerülik a számszerűsítés nehézségeit. A kifizetések azonban ebben az esetben is változhatnak a bemenetek és kimenetek számában. Fizetési csatorna a tranzakciók a szükséges „ugrások” számában változhatnak, ami befolyásolja az átvitelt. Az összesítő kiszolgáló átviteli sebessége pedig attól függhet, hogy a tranzakciók kötegét milyen mértékben lehet „nettósítani” az összefoglaló módosítások kisebb halmazára.

Az áteresztőképességgel kapcsolatos másik kihívás a mai teljesítmény empirikus mérésén túlmenően az elméleti kapacitás értékelése. Ez mindenféle modellezési kérdést vezet be a potenciális kapacitás értékeléséhez. Először is el kell döntenünk a végrehajtási réteg reális tranzakciós terheléséről. Másodszor, a valódi rendszerek szinte soha nem érik el az elméleti kapacitást, különösen a blokklánc rendszerek. Robusztussági okokból reméljük, hogy a csomópont-megvalósítások heterogének és változatosak a gyakorlatban (ahelyett, hogy az összes kliens egyetlen szoftvermegvalósítást futtatna). Ez még nehezebbé teszi a blokklánc átviteli sebesség pontos szimulációit. 

Átlag:

Az átviteli sebességre vonatkozó állítások gondos magyarázatot igényelnek a tranzakciós munkaterhelésről és az érvényesítők populációjáról (mennyiségük, megvalósításuk és hálózati kapcsolatuk). Világos szabvány hiányában elegendő egy olyan népszerű hálózat, mint az Ethereum, korábbi munkaterhelése.

A késleltetés és az áteresztőképesség kompromisszumai

A késleltetés és a teljesítmény általában kompromisszumot jelent. Mint Lefteris Kokoris-Kogias vázolja, ez a kompromisszum gyakran nem zökkenőmentes, egy inflexiós ponttal, ahol a várakozási idő meredeken nő, amikor a rendszerterhelés megközelíti a maximális átviteli sebességet.

A nulla tudású összesítő rendszerek természetes példát mutatnak az átviteli sebesség/latencia kompromisszumra. A tranzakciók nagy tételei megnövelik a bizonyítási időt, ami növeli a várakozási időt. A láncon belüli lábnyom azonban mind a bizonyítási méret, mind az érvényesítési költség tekintetében amortizálódik több, nagyobb kötegmérettel rendelkező tranzakció után, ami növeli az átviteli sebességet.

Tranzakciós díjak

Érthető, hogy a végfelhasználókat jobban érdekli a várakozási idő és a közötti kompromisszum díjak, nem a késleltetés és az áteresztőképesség. A felhasználóknak nincs közvetlen okuk arra, hogy egyáltalán törődjenek az átviteli sebességgel, csak az, hogy gyorsan, a lehető legalacsonyabb díjak mellett tudják visszaigazolni a tranzakciókat (egyes felhasználók jobban törődnek a díjakkal, mások pedig a késleltetéssel). Magas szinten a díjakat több tényező is befolyásolja:

1. Mekkora piaci kereslet van a tranzakciókra?
2. Milyen általános áteresztőképességet ér el a rendszer?
3. Összességében mennyi bevételt biztosít a rendszer az érvényesítőknek vagy a bányászoknak?
4. Ennek a bevételnek mekkora része a tranzakciós díjakon és az inflációs jutalmakon alapul?

Az első két tényező hozzávetőlegesen a kereslet/kínálat görbéi, amelyek piacelszámoló árhoz vezetnek (bár azt állítják, hogy a bányászok kartellként lépnek fel, hogy e pont fölé emeljék a díjakat). Ha minden más nem változik, a nagyobb átviteli sebesség általában alacsonyabb díjakat eredményez, de sokkal több történik.

Konkrétan a fenti 3. és 4. pont a blokklánc-rendszer tervezésének alapvető kérdései, de egyikhez sem hiányoznak a jó elvek. Megértjük valamennyire annak előnyeit és hátrányait, ha a bányászok inflációs jutalmakból bevételt szereznek a tranzakciós díjakkal szemben. A blokklánc konszenzusos protokollok sok közgazdasági elemzése ellenére azonban még mindig nincs széles körben elfogadott modellünk arra vonatkozóan, hogy mekkora bevételre van szükség a validátorokhoz. Manapság a legtöbb rendszer alapos feltételezésekre épül, hogy mekkora bevétel elegendő ahhoz, hogy az érvényesítők becsületesen viselkedjenek anélkül, hogy megfojtanák a rendszer gyakorlati használatát. Az egyszerűsített modelleknél kimutatható, hogy az 51%-os támadás felszerelésének költsége az érvényesítők jutalmával skálázódik.

A támadások költségeinek emelése jó dolog, de azt sem tudjuk, hogy mekkora biztonság az „elég”. Képzeld el, hogy két vidámparkba mennél. Egyikük azt állítja, hogy 50%-kal kevesebbet költ az utazás karbantartására, mint a másik. Jó ötlet elmenni ebbe a parkba? Lehetséges, hogy hatékonyabbak, és kevesebb pénzért ugyanolyan biztonságot kapnak. Lehet, hogy a másik többet költ, mint amennyi az utazások biztonságához szükséges, de semmi haszna nincs. De az is lehet, hogy az első park veszélyes. A blokklánc rendszerek hasonlóak. Ha kiszámolja az átviteli sebességet, az alacsonyabb díjakkal rendelkező blokkláncok díjai alacsonyabbak, mivel kevésbé jutalmazzák (és így ösztönzik) az érvényesítőiket. Ma nincsenek megfelelő eszközeink annak felmérésére, hogy ez rendben van-e, vagy sebezhetővé teszi-e a rendszert a támadásokkal szemben. Átfogó:

A rendszerek közötti díjak összehasonlítása félrevezető lehet. Annak ellenére, hogy a tranzakciós díjak fontosak a felhasználók számára, a rendszer kialakításán kívül számos tényező befolyásolja őket. Az áteresztőképesség jobb mérőszám a rendszer egészének elemzéséhez.

Következtetés

A teljesítmény tisztességes és pontos értékelése nehéz. Ez ugyanúgy igaz egy autó teljesítményének mérésére is. Csakúgy, mint a blokkláncok esetében, a különböző embereket más dolgok érdekelnek. Az autóknál egyes felhasználóknak a végsebesség vagy a gyorsulás, mások a benzines futásteljesítmény, míg mások a vontatási kapacitás fontosak. Mindezek értékelése nem triviális. Az Egyesült Államokban például a Környezetvédelmi Ügynökség részletes iránymutatásokat tart fenn arra vonatkozóan, hogyan kell értékelni a gázfogyasztást, és hogyan kell azt bemutatni a felhasználóknak a kereskedésben.

A blokklánc tér nagyon messze van ettől a szabványosítási szinttől. Bizonyos területeken a jövőben elérhetjük, hogy szabványosított munkaterhelésekkel értékeljük a rendszer átvitelét, vagy szabványosított grafikonokat a késleltetési eloszlások bemutatásához. Az értékelők és építtetők számára egyelőre az a legjobb megközelítés, ha a lehető legtöbb adatot összegyűjtik és közzéteszik, az értékelési módszertan részletes leírásával, hogy azok reprodukálhatók és összehasonlíthatók legyenek más rendszerekkel.