Zakaj je uspešnost blokovne verige težko izmeriti

Zmogljivost in razširljivost sta izziva, o katerih se veliko razpravlja v kriptoprostoru in sta pomembna tako za projekte ravni 1 (neodvisne verige blokov) kot za rešitve plasti 2 (kot so zbiranje in kanali zunaj verige). Vendar nimamo standardiziranih meritev ali meril. Številke se pogosto poročajo nedosledno in nepopolno, kar otežuje natančno primerjavo projektov in pogosto prikriva tisto, kar je v praksi najpomembnejše. 

Potrebujemo bolj niansiran in temeljit pristop k merjenju in primerjanju uspešnosti – pristop, ki razdeli zmogljivost na več komponent in primerja kompromise na več oseh. V tem prispevku opredeljujem osnovno terminologijo, orišem izzive ter ponujam smernice in ključna načela, ki jih je treba upoštevati pri ocenjevanju uspešnosti verige blokov. 

Razširljivost proti zmogljivosti

Najprej opredelimo dva izraza, razširljivost in zmogljivost, ki imata standardne računalniške pomene, ki se pogosto zlorabljajo v kontekstu verige blokov. Uspešnost meri, kaj je sistem trenutno sposoben doseči. Kot bomo razpravljali spodaj, lahko meritve uspešnosti vključujejo število transakcij na sekundo ali srednji čas potrditve transakcije. Prilagodljivost, po drugi strani pa meri sposobnost sistema, da izboljša zmogljivost z dodajanjem virov.

To razlikovanje je pomembno: številni pristopi k izboljšanju zmogljivosti sploh ne izboljšajo razširljivosti, če so pravilno definirani. Preprost primer je uporaba učinkovitejše sheme digitalnega podpisovanja, kot so podpisi BLS, ki so približno polovico manjši od podpisov Schnorr ali ECDSA. Če bi Bitcoin preklopil z ECDSA na BLS, bi se lahko število transakcij na blok povečalo za 20-30 %, kar bi čez noč izboljšalo učinkovitost. Toda to lahko storimo samo enkrat — ni še bolj prostorsko učinkovite podpisne sheme, na katero bi lahko preklopili (podpise BLS je mogoče tudi združiti, da prihranite več prostora, vendar je to še en enkraten trik).

Številni drugi enkratni triki (kot je SegWit) so možni v verigah blokov, vendar potrebujete razširljivo arhitekturo, da dosežete stalno izboljšanje zmogljivosti, pri čemer dodajanje več virov sčasoma izboljša zmogljivost. To je običajna modrost tudi v mnogih drugih računalniških sistemih, kot je izgradnja spletnega strežnika. Z nekaj običajnimi triki lahko zgradite en zelo hiter strežnik; a navsezadnje potrebujete večstrežniško arhitekturo, ki lahko zadovolji vedno večje povpraševanje z nenehnim dodajanjem dodatnih strežnikov.

Razumevanje razlike prav tako pomaga preprečiti napako pogoste kategorije, ki jo najdemo v izjavah, kot je: "Blockchain X je zelo razširljiv, lahko obravnava Y transakcij na sekundo!" Druga trditev je morda impresivna, vendar je performance metrika, ne metrika razširljivosti. Ne govori o zmožnosti izboljšanja učinkovitosti z dodajanjem virov.

Razširljivost sama po sebi zahteva izkoriščanje paralelizma. V prostoru verige blokov se zdi, da skaliranje plasti 1 zahteva razrez ali nekaj, kar je videti kot razrez. Osnovni koncept razrezovanja – razdelitev stanja na dele, tako da lahko različni validatorji obdelujejo neodvisno – se zelo ujema z definicijo razširljivosti. Na ravni 2 je še več možnosti, ki omogočajo dodajanje vzporedne obdelave — vključno s kanali zunaj verige, strežniki zbiranja in stranskimi verigami.

Zakasnitev v primerjavi s prepustnostjo

Klasično se delovanje sistema blockchain ocenjuje v dveh dimenzijah, zakasnitvi in ​​prepustnosti: zakasnitev meri, kako hitro je mogoče potrditi posamezno transakcijo, medtem ko prepustnost meri skupno stopnjo transakcij skozi čas. Te osi veljajo tako za sisteme ravni 1 kot za sisteme plasti 2, pa tudi za številne druge vrste računalniških sistemov (kot so poizvedovalni mehanizmi za baze podatkov in spletni strežniki).

Na žalost je tako zakasnitev kot prepustnost težko izmeriti in primerjati. Poleg tega posamezni uporabniki dejansko ne skrbijo za prepustnost (ki je merilo celotnega sistema). Kar jih resnično zanima, so zakasnitve in transakcijske provizije - natančneje, da so njihove transakcije potrjene čim hitreje in čim ceneje. Čeprav se številni drugi računalniški sistemi prav tako ocenjujejo na podlagi stroškov in uspešnosti, so transakcijske provizije nekoliko nova os delovanja za sisteme blockchain, ki v tradicionalnih računalniških sistemih v resnici ne obstajajo.

Izzivi pri merjenju latence

Zakasnitev se sprva zdi preprosta: koliko časa traja, da se transakcija potrdi? Toda vedno obstaja več različnih načinov za odgovor na to vprašanje.

Prvič, izmerimo lahko zakasnitev med različnimi točkami v času in dobimo različne rezultate. Na primer, ali začnemo meriti zakasnitev, ko uporabnik lokalno pritisne gumb »pošlji« ali ko transakcija doseže mempool? In ali ustavimo uro, ko je transakcija v predlaganem bloku ali ko je blok potrjen z enim nadaljnjim blokom ali šestimi?

Najpogostejši pristop zavzema stališče validatorjev, ki merijo od trenutka, ko stranka prvič odda transakcijo, do trenutka, ko je transakcija razumno "potrjena" (v smislu, da bi trgovci v resničnem svetu upoštevali prejeto plačilo in izdali blago) . Seveda lahko različni trgovci uporabljajo različna merila sprejemljivosti in celo en sam trgovec lahko uporablja različne standarde glede na znesek transakcije.

Pristop, osredotočen na validatorje, spregleda več stvari, ki so v praksi pomembne. Prvič, ignorira zakasnitev v omrežju enakovrednih (koliko časa traja od trenutka, ko odjemalec odda transakcijo, do trenutka, ko jo sliši večina vozlišč?) in zakasnitev na strani odjemalca (koliko časa traja priprava transakcije na odjemalčevem lokalnem računalniku?). Zakasnitev na strani odjemalca je lahko zelo majhna in predvidljiva za preproste transakcije, kot je podpis plačila Ethereum, vendar je lahko pomembna za bolj zapletene primere, kot je dokazovanje, da je zaščitena transakcija Zcash pravilna.

Tudi če smo standardizirali časovno okno, ki ga poskušamo izmeriti z zakasnitvijo, je odgovor skoraj vedno odvisno. Noben doslej zgrajen sistem kriptovalut ni nudil fiksne zakasnitve transakcij. Osnovno pravilo, ki si ga morate zapomniti, je:

Zakasnitev je porazdelitev, ne ena številka.

Raziskovalna skupnost omrežij je to že dolgo razumela (glej na primer to odličen govor Gila Teneja). Poseben poudarek je na "dolgem repu" distribucije, saj bo zelo povišana zakasnitev že pri 0.1 % transakcij (ali poizvedb spletnega strežnika) resno Vpliv končnim uporabnikom.

Pri verigah blokov se lahko zakasnitev potrditve razlikuje zaradi več razlogov:

Doziranje: večina sistemov na nek način združi transakcije v pakete, na primer v bloke v večini sistemov 1. ravni. To vodi do spremenljive zakasnitve, ker bodo nekatere transakcije morale počakati, da se serija napolni. Drugim se lahko posreči in se skupini pridružijo zadnji. Te transakcije so potrjene takoj in ne povzročajo dodatnih zakasnitev.

Spremenljivi zastoji: večina sistemov trpi zaradi prezasedenosti, kar pomeni, da je objavljenih več transakcij (vsaj nekaj časa), kot jih lahko sistem takoj obravnava. Kako prezasedena se lahko razlikuje, ko se transakcije oddajajo ob nepredvidljivih časih (pogosto abstrahirano kot a Poissonov proces) ali ko se stopnja novih transakcij spreminja čez dan ali teden ali kot odziv na zunanje dogodke, kot je priljubljena uvedba NFT.

Varianca konsenzne plasti: Potrditev transakcije na ravni 1 običajno zahteva porazdeljen nabor vozlišč, da doseže soglasje o bloku, kar lahko doda spremenljive zakasnitve ne glede na prezasedenost. Sistemi za dokazovanje dela najdejo bloke ob nepredvidljivih časih (tudi abstraktno Poissonov proces). Sistemi za dokaz vložka lahko dodajo tudi različne zakasnitve (na primer, če je na spletu premalo vozlišč za oblikovanje odbora v krogu ali če je potrebna sprememba pogleda kot odgovor na zrušitev vodilnega).

Iz teh razlogov je dobra smernica:

Trditve o zakasnitvi bi morale predstavljati porazdelitev (ali histogram) potrditvenih časov, namesto ene same številke, kot je povprečje ali mediana.

Medtem ko povzetek statistike, kot je povprečje, mediana ali percentili, zagotavlja delno sliko, natančno vrednotenje sistema zahteva upoštevanje celotne porazdelitve. V nekaterih aplikacijah lahko povprečna zakasnitev zagotovi dober vpogled, če je porazdelitev zakasnitve relativno preprosta (na primer Gaussova). Toda v kriptovaluti skoraj nikoli ni tako: običajno je dolg rep počasnih potrditvenih časov.

Dober primer so omrežja plačilnih kanalov (npr. Lightning Network). Klasična rešitev za skaliranje L2, ta omrežja večino časa ponujajo zelo hitre potrditve plačil, vendar občasno zahtevajo ponastavitev kanala, kar lahko poveča zakasnitev za velikostne rede.

In tudi če imamo dobre statistične podatke o natančni porazdelitvi zakasnitev, se bodo sčasoma verjetno spreminjale, ko se sistem in zahteve po sistemu spreminjajo. Prav tako ni vedno jasno, kako primerjati porazdelitev zakasnitev med konkurenčnimi sistemi. Na primer, upoštevajte sistem, ki potrjuje transakcije z enakomerno porazdeljeno zakasnitvijo med 1 in 2 minutama (s povprečjem in mediano 90 sekund). Če konkurenčni sistem potrdi 95 % transakcij točno v 1 minuti, ostalih 5 % pa v 11 minutah (s povprečjem 90 sekund in mediano 60 sekund), kateri sistem je boljši? Odgovor je verjetno, da bi nekatere aplikacije raje imele prvo, nekatere pa drugo.

Na koncu je pomembno omeniti, da v večini sistemov niso vse transakcije enako prednostno razvrščene. Uporabniki lahko plačajo več, da dobijo višjo prioriteto vključitve, zato se poleg vsega zgoraj navedenega zakasnitev spreminja kot funkcija plačanih transakcijskih provizij. V povzetku:

Zakasnitev je zapletena. Več podatkov je sporočenih, bolje je. V idealnem primeru je treba celotno porazdelitev zakasnitev izmeriti pod različnimi pogoji prezasedenosti. Koristne so tudi razčlenitve zakasnitve na različne komponente (lokalne, omrežne, paketne, soglasna zakasnitev).

Izzivi pri merjenju prepustnosti

Tudi prepustnost se na prvi pogled zdi preprosta: koliko transakcij lahko sistem obdela na sekundo? Pojavita se dve glavni težavi: kaj točno je "transakcija" in ali merimo, kaj sistem počne danes ali kaj bi lahko naredil?

Medtem ko je »transakcije na sekundo« (ali tps) dejanski standard za merjenje uspešnosti verige blokov, so transakcije kot merska enota problematične. Za sisteme, ki ponujajo možnost splošnega programiranja (»pametne pogodbe«) ali celo omejene funkcije, kot so Bitcoinove multipleksne transakcije ali možnosti za preverjanje več podpisov, je temeljna težava:

Vse transakcije niso enake.

To očitno velja za Ethereum, kjer lahko transakcije vključujejo poljubno kodo in poljubno spreminjajo stanje. Pojem plina v Ethereumu se uporablja za količinsko opredelitev (in zaračunavanje stroškov) celotne količine dela, ki ga opravi transakcija, vendar je to zelo specifično za okolje izvajanja EVM. Ni preprostega načina za primerjavo skupne količine dela, ki ga opravi nabor transakcij EVM, z na primer naborom transakcij Solana z uporabo okolja BPF. Primerjava enega ali drugega z nizom transakcij z bitcoini je podobno težka.

Verige blokov, ki ločijo transakcijsko plast na soglasno plast in izvršilno plast, lahko to pojasnijo. Na (čisti) konsenzni plasti se lahko prepustnost meri v bajtih, dodanih v verigo na časovno enoto. Izvedbeni sloj bo vedno bolj zapleten.

Enostavnejše izvedbene plasti, kot so skupni strežniki, ki podpirajo samo plačilne transakcije, se izognejo težavam pri kvantificiranju izračuna. Tudi v tem primeru pa se lahko plačila razlikujejo glede na število vhodov in izhodov. Plačilni kanal transakcije se lahko razlikujejo glede na potrebno število "skokov", kar vpliva na prepustnost. In prepustnost strežnika zbiranja je lahko odvisna od obsega, do katerega je mogoče serijo transakcij "povezati" z manjšim nizom sprememb povzetka.

Drug izziv pri prepustnosti je preseganje empiričnega merjenja današnje uspešnosti za oceno teoretične zmogljivosti. To uvaja vse vrste vprašanj modeliranja za oceno potencialne zmogljivosti. Najprej se moramo odločiti za realno transakcijsko delovno obremenitev za izvršilno plast. Drugič, pravi sistemi skoraj nikoli ne dosežejo teoretične zmogljivosti, zlasti sistemi blockchain. Zaradi robustnosti upamo, da so implementacije vozlišč v praksi heterogene in raznolike (namesto da vsi odjemalci izvajajo eno programsko implementacijo). Zaradi tega je natančne simulacije prepustnosti verige blokov še težje izvesti. 

Na splošno:

Trditve o prepustnosti zahtevajo natančno razlago delovne obremenitve transakcije in populacije validatorjev (njihove količine, izvedbe in omrežne povezljivosti). Ker ni nobenega jasnega standarda, zadostujejo zgodovinske delovne obremenitve iz priljubljenega omrežja, kot je Ethereum.

Kompromis med zakasnitvijo in prepustnostjo

Zakasnitev in prepustnost sta običajno kompromis. Kot Lefteris Kokoris-Kogias orisuje, ta kompromis pogosto ni gladek, z prelomno točko, kjer se zakasnitev močno poveča, ko se obremenitev sistema približa največji prepustnosti.

Zbirni sistemi brez znanja predstavljajo naravni primer kompromisa med prepustnostjo in zakasnitvijo. Velike serije transakcij povečajo čas dokazovanja, kar poveča zakasnitev. Toda odtis v verigi, tako glede velikosti dokazov kot stroškov validacije, se bo amortiziral z več transakcijami z večjimi velikostmi paketov, kar bo povečalo pretok.

Transakcijske pristojbine

Razumljivo je, da končne uporabnike bolj zanima kompromis med zakasnitvijo in Pristojbine, ne zakasnitev in prepustnost. Uporabniki nimajo neposrednega razloga, da bi sploh skrbeli za prepustnost, le da lahko hitro potrdijo transakcije za najnižje možne provizije (pri čemer nekatere uporabnike bolj skrbijo provizije, druge bolj zakasnitve). Na visoki ravni na pristojbine vpliva več dejavnikov:

1. Koliko je tržnega povpraševanja po transakcijah?
2. Kakšno skupno prepustnost doseže sistem?
3. Koliko skupnega prihodka sistem zagotavlja validatorjem ali rudarjem?
4. Koliko tega prihodka temelji na transakcijskih provizijah v primerjavi z inflacijskimi nagradami?

Prva dva dejavnika sta v grobem krivulji ponudbe/povpraševanja, ki vodita do tržne cene (čeprav se trdi, da rudarji delujejo kot kartel, da zvišajo pristojbine nad to točko). Če so vsi drugi enaki, bi morala večja pretočnost voditi k nižjim provizijam, vendar se dogaja veliko več.

Zlasti zgornji točki 3 in 4 sta temeljni vprašanji zasnove sistema blockchain, vendar nam primanjkuje dobrih načel za eno od njiju. Do neke mere razumemo prednosti in slabosti dajanja rudarjem prihodkov iz inflacijskih nagrad v primerjavi s transakcijskimi provizijami. Vendar kljub številnim ekonomskim analizam soglasnih protokolov blockchain še vedno nimamo splošno sprejetega modela za to, koliko prihodkov mora iti validatorjem. Danes večina sistemov temelji na utemeljenem ugibanju o tem, koliko prihodkov je dovolj, da se validatorji obnašajo pošteno, ne da bi ovirali praktično uporabo sistema. V poenostavljenih modelih, lahko se pokaže, da se stroški namestitve 51-odstotnega napada ujemajo z nagradami validatorjem.

Dvig stroškov napadov je dobra stvar, vendar tudi ne vemo, koliko varnosti je "dovolj". Predstavljajte si, da razmišljate o obisku dveh zabaviščnih parkov. Eden od njih trdi, da porabi 50 % manj za vzdrževanje vožnje kot drugi. Je dobra ideja iti v ta park? Mogoče je, da so učinkovitejši in dobijo enakovredno varnost za manj denarja. Morda drugi porabi več, kot je potrebno za varne vožnje, brez koristi. Lahko pa se zgodi tudi, da je prvi park nevaren. Sistemi veriženja blokov so podobni. Ko izločite prepustnost, imajo verige blokov z nižjimi provizijami nižje provizije, ker manj nagrajujejo (in s tem spodbujajo) svoje validatorje. Danes nimamo dobrih orodij, da bi ocenili, ali je to v redu ali pušča sistem ranljiv za napade. Na splošno:

Primerjava pristojbin med sistemi je lahko zavajajoča. Čeprav so transakcijske provizije za uporabnike pomembne, nanje poleg same zasnove sistema vplivajo številni dejavniki. Prepustnost je boljša metrika za analizo sistema kot celote.

zaključek

Pošteno in natančno ocenjevanje uspešnosti je težko. To velja tudi za merjenje zmogljivosti avtomobila. Tako kot pri verigah blokov bodo različni ljudje skrbeli za različne stvari. Pri avtomobilih bodo nekateri uporabniki skrbeli za najvišjo hitrost ali pospešek, drugi za porabo goriva in tretji za vlečno zmogljivost. Vse to ni trivialno za vrednotenje. V ZDA, na primer, Agencija za varstvo okolja vzdržuje podrobne smernice o tem, kako se ocenjuje poraba goriva in kako jo je treba predstaviti uporabnikom pri trgovcu.

Prostor blockchain je daleč od te ravni standardizacije. Na nekaterih področjih bomo morda v prihodnosti dosegli standardizirane delovne obremenitve za oceno prepustnosti sistema ali standardizirane grafe za predstavitev porazdelitev zakasnitev. Za ocenjevalce in graditelje je zaenkrat najboljši pristop, da zberejo in objavijo čim več podatkov s podrobnim opisom metodologije ocenjevanja, da jo je mogoče reproducirati in primerjati z drugimi sistemi.