Miksi Blockchainin suorituskykyä on vaikea mitata

Suorituskyky ja skaalautuvuus ovat paljon keskusteltuja haasteita kryptoalalla, ja ne liittyvät sekä Layer 1 -projekteihin (itsenäiset lohkoketjut) että Layer 2 -ratkaisuihin (kuten rullat ja ketjun ulkopuoliset kanavat). Meillä ei kuitenkaan ole standardoituja mittareita tai vertailuarvoja. Luvut raportoidaan usein epäjohdonmukaisesti ja epätäydellisesti, mikä vaikeuttaa projektien tarkkaa vertailua ja usein hämärtää käytännössä tärkeimmän. 

Tarvitsemme vivahteikkaamman ja perusteellisemman lähestymistavan suorituskyvyn mittaamiseen ja vertailuun – sellaisen, joka jakaa suorituskyvyn useisiin komponentteihin ja vertaa kompromisseja useiden akselien välillä. Tässä viestissä määrittelen perusterminologian, hahmotan haasteita ja tarjoan ohjeita ja keskeisiä periaatteita, jotka on pidettävä mielessä lohkoketjun suorituskykyä arvioitaessa. 

Skaalautuvuus vs. suorituskyky

Ensin määritellään kaksi termiä, skaalautuvuus ja suorituskyky, joilla on standardinmukaiset tietojenkäsittelytieteen merkitykset, joita käytetään usein väärin lohkoketjuissa. Suorituskyky mittaa mitä järjestelmä on jotka tällä hetkellä pystyvät saavuttamaan. Kuten alla kerrotaan, tehokkuusmittarit voivat sisältää tapahtumia sekunnissa tai mediaanitapahtuman vahvistusajan. skaalautuvuustoisaalta mittaa järjestelmän kyky parantaa suorituskykyä lisäämällä resursseja.

Tämä ero on tärkeä: Monet suorituskyvyn parantamiseen tähtäävät lähestymistavat eivät paranna skaalautuvuutta ollenkaan, kun ne määritellään oikein. Yksinkertainen esimerkki on tehokkaamman digitaalisen allekirjoituksen käyttö, kuten BLS-allekirjoitukset, jotka ovat suunnilleen puolet Schnorr- tai ECDSA-allekirjoituksista. Jos Bitcoin siirtyisi ECDSA:sta BLS:ään, tapahtumien määrä lohkoa kohti voisi nousta 20-30 %, mikä parantaa suorituskykyä yhdessä yössä. Mutta voimme tehdä tämän vain kerran – ei ole vielä tilaa säästävää allekirjoitusjärjestelmää, johon vaihtaa (BLS-allekirjoituksia voidaan myös yhdistää tilan säästämiseksi, mutta tämä on toinen kertaluonteinen temppu).

Useat muut kertaluonteiset temput (kuten SegWit) ovat mahdollisia lohkoketjuissa, mutta tarvitset skaalautuvan arkkitehtuurin jatkuvan suorituskyvyn parantamiseksi, jossa resurssien lisääminen parantaa suorituskykyä ajan myötä. Tämä on perinteinen viisaus myös monissa muissa tietokonejärjestelmissä, kuten web-palvelimen rakentamisessa. Muutaman yleisen tempun avulla voit rakentaa yhden erittäin nopean palvelimen; mutta viime kädessä tarvitset usean palvelimen arkkitehtuurin, joka pystyy vastaamaan jatkuvasti kasvavaan kysyntään lisäämällä jatkuvasti ylimääräisiä palvelimia.

Eron ymmärtäminen auttaa myös välttämään yleisen luokkavirheen, joka löytyy lauseista, kuten "Blockchain X on erittäin skaalautuva, se pystyy käsittelemään Y tapahtumaa sekunnissa!" Toinen väite voi olla vaikuttava, mutta se on a suorituskyky metriikka, ei skaalautuvuusmittari. Se ei kerro kyvystä parantaa suorituskykyä lisäämällä resursseja.

Skaalautuvuus edellyttää luonnostaan ​​rinnakkaisuuden hyödyntämistä. Lohkoketjutilassa Layer 1 -skaalaus näyttää vaativan sirpalointia tai jotain, joka näyttää sirpaloitumiselta. Shardingin peruskonsepti – tilan jakaminen osiin, jotta eri validaattorit voivat käsitellä itsenäisesti – vastaa läheisesti skaalautuvuuden määritelmää. Layer 2:ssa on vielä enemmän vaihtoehtoja, jotka mahdollistavat rinnakkaiskäsittelyn lisäämisen – mukaan lukien ketjun ulkopuoliset kanavat, kokoelmapalvelimet ja sivuketjut.

Latenssi vs. suoritusteho

Perinteisesti lohkoketjujärjestelmän suorituskykyä arvioidaan kahdella ulottuvuudella, latenssilla ja suorituskyvyllä: Latenssi mittaa, kuinka nopeasti yksittäinen tapahtuma voidaan vahvistaa, kun taas läpimenokyky mittaa tapahtumien kokonaisnopeutta ajan kuluessa. Nämä akselit koskevat sekä Layer 1- että Layer 2 -järjestelmiä sekä monia muita tietokonejärjestelmiä (kuten tietokantakyselymoottoreita ja web-palvelimia).

Valitettavasti sekä latenssi että suoritusteho ovat monimutkaisia ​​mitata ja vertailla. Lisäksi yksittäiset käyttäjät eivät itse asiassa välitä suorituskyvystä (joka on järjestelmän laajuinen mitta). He todella välittävät viiveestä ja tapahtumamaksuista – tarkemmin sanottuna siitä, että heidän tapahtumansa vahvistetaan mahdollisimman nopeasti ja edullisesti. Vaikka monia muita tietokonejärjestelmiä arvioidaan myös kustannus/suorituskykyperusteisesti, tapahtumamaksut ovat hieman uusi lohkoketjujärjestelmien suorituskykyakseli, jota ei oikeastaan ​​ole perinteisissä tietokonejärjestelmissä.

Haasteita latenssin mittaamisessa

Latenssi näyttää aluksi yksinkertaiselta: kuinka kauan tapahtuman vahvistaminen kestää? Mutta tähän kysymykseen on aina useita eri tapoja vastata.

Ensinnäkin voimme mitata latenssia eri ajankohtien välillä ja saada erilaisia ​​tuloksia. Aloitammeko esimerkiksi viiveen mittaamisen, kun käyttäjä painaa "lähetä"-painiketta paikallisesti vai kun tapahtuma osuu muistiin? Ja pysäytetäänkö kello, kun tapahtuma on ehdotetussa lohkossa vai kun lohko vahvistetaan yhdellä tai kuudella seurantalohkolla?

Yleisin lähestymistapa on validaattoreiden näkökulmasta, joka mittaa siitä hetkestä, kun asiakas lähettää tapahtuman ensimmäisen kerran siihen hetkeen, jolloin tapahtuma on kohtuullisesti "vahvistettu" (sillä mielessä, että reaalimaailman kauppiaat katsoisivat maksun vastaanotetuksi ja vapauttaisivat tavarat) . Tietenkin eri kauppiaat voivat soveltaa erilaisia ​​hyväksymisehtoja, ja jopa yksi kauppias voi käyttää erilaisia ​​​​standardeja tapahtuman summasta riippuen.

Validaattorikeskeisestä lähestymistavasta puuttuu useita käytännössä tärkeitä asioita. Ensinnäkin se jättää huomioimatta peer-to-peer-verkon latenssin (kuinka kauan kestää siitä, kun asiakas lähettää tapahtuman siihen, kun useimmat solmut ovat kuulleet sen?) ja asiakaspuolen latenssin (kuinka kauan tapahtuman valmistelu kestää? asiakkaan paikallisella koneella?). Asiakaspuolen viive voi olla hyvin pieni ja ennustettavissa yksinkertaisissa tapahtumissa, kuten Ethereum-maksun allekirjoittamisessa, mutta se voi olla merkittävä monimutkaisemmissa tapauksissa, kuten suojatun Zcash-tapahtuman oikeellisuuden todistamisessa.

Vaikka standardoimmekin mitattavan aikaikkunan latenssilla, vastaus on melkein aina se riippuu. Mikään koskaan rakennettu kryptovaluuttajärjestelmä ei ole tarjonnut kiinteää transaktioviivettä. Perus nyrkkisääntö, joka on muistettava:

Latenssi on jakauma, ei yksittäinen luku.

Verkostoituva tutkimusyhteisö on ymmärtänyt tämän jo pitkään (katso esimerkiksi tämä erinomainen keskustelu Gil Teneltä). Erityisesti painotetaan jakelun "pitkää häntää", koska erittäin kohonnut viive jopa 0.1 prosentissa tapahtumista (tai verkkopalvelinkyselyistä) on vakava vaikutus loppukäyttäjät.

Lohkoketjuissa vahvistusviive voi vaihdella useista syistä:

Erä: useimmat järjestelmät yhdistävät tapahtumat jollakin tavalla, esimerkiksi lohkoiksi useimmissa Layer 1 -järjestelmissä. Tämä johtaa muuttuvaan latenssiin, koska joidenkin tapahtumien on odotettava erän täyttymistä. Toisilla saattaa käydä tuuri ja liittyä joukkoon viimeisenä. Nämä tapahtumat vahvistetaan heti, eivätkä ne koe ylimääräistä latenssia.

Vaihtuva ruuhka: useimmat järjestelmät kärsivät ruuhkasta, mikä tarkoittaa, että enemmän tapahtumia kirjataan (ainakin osan ajasta) kuin järjestelmä pystyy välittömästi käsittelemään. Ruuhkaisuus voi vaihdella, kun tapahtumat lähetetään arvaamattomina aikoina (usein abstrahoituna Poisson-prosessi) tai kun uusien tapahtumien määrä muuttuu päivän tai viikon aikana tai vastauksena ulkoisiin tapahtumiin, kuten suosittu NFT-julkaisu.

Konsensustason varianssi: Tapahtuman vahvistaminen kerroksessa 1 vaatii yleensä hajautetun joukon solmuja päästäkseen yksimielisyyteen lohkosta, mikä voi lisätä muuttuvia viiveitä ruuhkasta riippumatta. Proof-of-work -järjestelmät löytävät lohkoja arvaamattomina aikoina (myös abstraktisti Poisson-prosessi). Panostodistusjärjestelmät voivat myös lisätä erilaisia ​​viiveitä (esimerkiksi jos verkossa ei ole tarpeeksi solmuja komitean muodostamiseksi kierroksella tai jos näkymää tarvitaan johtajan kaatumisen vuoksi).

Näistä syistä hyvä ohje on:

Latenssia koskevien väitteiden tulee esittää vahvistusaikojen jakauma (tai histogrammi) yhden luvun, kuten keskiarvon tai mediaanin, sijaan.

Vaikka yhteenvetotilastot, kuten keskiarvo, mediaani tai prosenttipisteet, antavat osittaisen kuvan, järjestelmän tarkka arvioiminen edellyttää koko jakauman huomioon ottamista. Joissakin sovelluksissa keskimääräinen latenssi voi antaa hyvän käsityksen, jos latenssijakauma on suhteellisen yksinkertainen (esimerkiksi Gaussin). Mutta kryptovaluutoissa se ei ole lähes koskaan näin: Yleensä hitaiden vahvistusaikkojen pyrstö on pitkä.

Maksukanavaverkot (esim. Lightning Network) ovat hyvä esimerkki. Klassinen L2-skaalausratkaisu, nämä verkot tarjoavat erittäin nopeat maksuvahvistukset suurimman osan ajasta, mutta joskus ne vaativat kanavan nollauksen, mikä voi lisätä viivettä suuruusluokkaa.

Ja vaikka meillä olisikin hyvät tilastot tarkasta latenssijakaumasta, ne todennäköisesti vaihtelevat ajan myötä järjestelmän ja järjestelmän kysynnän muuttuessa. Ei myöskään ole aina selvää, kuinka verrata latenssijakaumia kilpailevien järjestelmien välillä. Tarkastellaan esimerkiksi yhtä järjestelmää, joka vahvistaa tapahtumat tasaisesti jakautuneilla latenssilla 1–2 minuuttia (keskiarvo ja mediaani 90 sekuntia). Jos kilpaileva järjestelmä vahvistaa 95 % tapahtumista tarkasti 1 minuutissa ja loput 5 % 11 minuutissa (keskiarvo 90 sekuntia ja mediaani 60 sekuntia), mikä järjestelmä on parempi? Vastaus on luultavasti, että jotkut sovellukset suosivat ensin mainittua ja jotkut jälkimmäistä.

Lopuksi on tärkeää huomata, että useimmissa järjestelmissä kaikkia tapahtumia ei priorisoida samalla tavalla. Käyttäjät voivat maksaa enemmän saadakseen korkeamman prioriteetin sisällyttämiseen, joten kaikkien edellä mainittujen lisäksi viive vaihtelee maksettujen tapahtumamaksujen funktiona. Yhteenvetona:

Latenssi on monimutkainen. Mitä enemmän tietoja raportoidaan, sitä parempi. Ihannetapauksessa täydelliset latenssijakaumat tulisi mitata vaihtelevissa ruuhkaolosuhteissa. Viiveen jaottelu eri osiin (paikallinen, verkko, erä, konsensusviive) on myös hyödyllistä.

Haasteita suorituskyvyn mittaamisessa

Myös läpimeno näyttää ensi silmäyksellä yksinkertaiselta: kuinka monta tapahtumaa järjestelmä voi käsitellä sekunnissa? Kaksi ensisijaista vaikeutta syntyy: mitä "transaktio" tarkalleen ottaen tarkoittaa, ja mittaammeko, mitä järjestelmä tekee nykyään tai mitä se voisi tehdä?

Vaikka "tapahtumat sekunnissa" (tai tps) on de facto standardi lohkoketjun suorituskyvyn mittaamiseen, tapahtumat ovat ongelmallisia mittayksikkönä. Järjestelmissä, jotka tarjoavat yleiskäyttöistä ohjelmoitavuutta ("älykkäät sopimukset") tai jopa rajoitettuja ominaisuuksia, kuten Bitcoinin multipleksitapahtumat tai vaihtoehtoja usean merkkien varmentamiseen, perusongelma on:

Kaikki liiketoimet eivät ole samanarvoisia.

Tämä on tietysti totta Ethereumissa, jossa tapahtumat voivat sisältää mielivaltaisen koodin ja mielivaltaisesti muuttaa tilaa. Ethereumin kaasun käsitettä käytetään määrittämään tapahtuman suorittaman työn kokonaismäärä (ja veloittamaan siitä maksuja), mutta tämä on erittäin EVM-suoritusympäristöön liittyvää. Ei ole yksinkertaista tapaa verrata EVM-tapahtumien kokonaismäärää esimerkiksi Solana-tapahtumien joukkoon BPF-ympäristössä. Jommankumman vertaaminen joukkoon Bitcoin-tapahtumia on samalla tavalla täynnä.

Lohkoketjut, jotka erottavat tapahtumakerroksen konsensuskerrokseksi ja suorituskerrokseksi, voivat selventää tätä. (Puhaalla) konsensuskerroksella suoritusteho voidaan mitata tavuina, jotka lisätään ketjuun aikayksikköä kohti. Toteutuskerros on aina monimutkaisempi.

Yksinkertaisemmilla suoritustasoilla, kuten vain maksutapahtumia tukevat kokoelmapalvelimet, vältetään laskennan kvantifiointivaikeudet. Tässäkin tapauksessa maksut voivat kuitenkin vaihdella tulojen ja tulosten määrässä. Maksukanava tapahtumat voivat vaihdella vaadittujen "hyppyjen" määrässä, mikä vaikuttaa suorituskykyyn. Ja koontipalvelimen suorituskyky voi riippua siitä, missä määrin tapahtumaerä voidaan "nettottaa" pienemmiksi yhteenvetomuutoksiksi.

Toinen suorituskyvyn haaste on nykypäivän suorituskyvyn empiirisen mittaamisen lisäksi teoreettisen kapasiteetin arvioiminen. Tämä esittelee kaikenlaisia ​​​​mallinnuskysymyksiä mahdollisen kapasiteetin arvioimiseksi. Ensinnäkin meidän on päätettävä suoritustasolle realistinen tapahtumatyökuormitus. Toiseksi, todelliset järjestelmät eivät juuri koskaan saavuta teoreettista kapasiteettia, etenkään lohkoketjujärjestelmät. Vakavuussyistä toivomme, että solmutoteutukset ovat heterogeenisiä ja erilaisia ​​käytännössä (eikä kaikki asiakkaat käyttävät yhtä ohjelmistototeutusta). Tämä tekee lohkoketjun läpimenon tarkkojen simulaatioiden suorittamisesta entistä vaikeampaa. 

Yleensä ottaen:

Suorituskykyä koskevat väitteet edellyttävät huolellista selvitystä tapahtuman työmäärästä ja validaattorien joukosta (niiden määrästä, toteutuksesta ja verkkoyhteydestä). Selkeän standardin puuttuessa suositun verkon, kuten Ethereumin, historialliset työmäärät riittävät.

Latenssin ja läpäisykyvyn kompromissit

Latenssi ja suorituskyky ovat yleensä kompromissi. Kuten Lefteris Kokoris-Kogias linjaa, tämä kompromissi ei useinkaan ole tasainen, ja siinä on käännekohta, jossa latenssi kasvaa jyrkästi, kun järjestelmän kuormitus lähestyy maksimikapasiteettiaan.

Nollatiedon koontijärjestelmät ovat luonnollinen esimerkki suorituskyvyn ja latenssin välisestä kompromissista. Suuret tapahtumaerät pidentävät todistusaikaa, mikä lisää viivettä. Mutta ketjun jalanjälki, sekä todisteiden koon että validointikustannusten osalta, kuoletetaan useammilla tapahtumilla, joissa on suurempi eräkoko, mikä lisää läpimenoa.

palvelumaksut

Ymmärrettävästi loppukäyttäjät välittävät enemmän kompromissista latenssin ja palkkiot, ei latenssia ja suorituskykyä. Käyttäjillä ei ole suoraa syytä välittää suorituskyvystä ollenkaan, vain se, että he voivat vahvistaa tapahtumat nopeasti mahdollisimman alhaisilla maksuilla (jotkut käyttäjät välittävät enemmän maksuista ja toiset enemmän latenssista). Korkealla tasolla maksuihin vaikuttavat useat tekijät:

1. Kuinka paljon markkinoilla on kysyntää liiketoimille?
2. Millainen kokonaiskapasiteetti järjestelmällä saavutetaan?
3. Kuinka paljon kokonaistuloja järjestelmä tarjoaa validaattoreille tai kaivostyöläisille?
4. Kuinka suuri osa näistä tuloista perustuu transaktiomaksuihin vs. inflaatiopalkkioihin?

Kaksi ensimmäistä tekijää ovat karkeasti tarjonta/kysyntäkäyriä, jotka johtavat markkinoiden selvityshintaan (vaikka on väitetty, että kaivostyöläiset toimivat kartellina nostaakseen maksuja tämän pisteen yläpuolelle). Jos kaikki muu on sama, suuremman suorituskyvyn pitäisi yleensä johtaa alhaisempiin maksuihin, mutta tapahtumia on paljon enemmän.

Erityisesti yllä olevat kohdat 3 ja 4 ovat lohkoketjujärjestelmän suunnittelun peruskysymyksiä, mutta meiltä puuttuu hyviä periaatteita kummallekaan. Ymmärrämme jonkin verran eduista ja haitoista, joita kaivostyöntekijöille annetaan inflaatiopalkkioista verrattuna transaktiomaksuihin. Huolimatta monista lohkoketjujen konsensusprotokollien taloudellisista analyyseistä meillä ei kuitenkaan ole vieläkään laajalti hyväksyttyä mallia siitä, kuinka paljon tuloja on mentävä validaattoreille. Nykyään useimmat järjestelmät perustuvat valistuneeseen arvaukseen siitä, kuinka paljon tuloja riittää pitämään validaattorit toimimaan rehellisesti ilman, että järjestelmän käytännön käyttöä tukahdutetaan. Yksinkertaistetuissa malleissa voidaan osoittaa, että 51 %:n hyökkäyksen asennuskustannukset skaalautuvat validaattoreiden palkkioihin.

Hyökkäysten kustannusten korottaminen on hyvä asia, mutta emme myöskään tiedä, kuinka paljon turvallisuutta "riittää". Kuvittele, että harkitset menemistä kahteen huvipuistoon. Toinen heistä väittää kuluttavansa 50 % vähemmän ajon huoltoon kuin toinen. Onko hyvä idea mennä tähän puistoon? Voi olla, että ne ovat tehokkaampia ja saavat vastaavan turvallisuuden vähemmällä rahalla. Ehkä toinen kuluttaa enemmän kuin mitä tarvitaan pitääkseen kyydissä turvallisia, mutta siitä ei ole hyötyä. Mutta voi myös olla, että ensimmäinen puisto on vaarallinen. Blockchain-järjestelmät ovat samanlaisia. Kun otat huomioon suorituskyvyn, pienemmillä maksuilla varustetuilla lohkoketjuilla on alhaisemmat maksut, koska ne palkitsevat (ja siten kannustavat) validaattoreitaan vähemmän. Meillä ei ole nykyään hyviä työkaluja arvioida, onko tämä kunnossa vai jättääkö se järjestelmän alttiin hyökkäyksille. Yleensä ottaen:

Maksujen vertailu järjestelmien välillä voi olla harhaanjohtavaa. Vaikka tapahtumamaksut ovat käyttäjille tärkeitä, niihin vaikuttavat monet muut tekijät kuin itse järjestelmän suunnittelu. Suorituskyky on parempi mittari järjestelmän analysointiin kokonaisuutena.

Yhteenveto

Suorituksen oikeudenmukainen ja tarkka arvioiminen on vaikeaa. Tämä pätee myös auton suorituskyvyn mittaamiseen. Aivan kuten lohkoketjuissa, eri ihmiset välittävät eri asioista. Autojen kohdalla jotkut käyttäjät välittävät huippunopeudesta tai kiihtyvyydestä, toiset kaasun ajokilometreistä ja toiset hinauskapasiteetista. Kaikki nämä eivät ole triviaaleja arvioitavissa. Esimerkiksi Yhdysvalloissa Environmental Protection Agency ylläpitää yksityiskohtaisia ​​ohjeita siitä, miten kaasun mittarilukema arvioidaan ja kuinka se on esitettävä käyttäjille jälleenmyyjässä.

Lohkoketjutila on kaukana tästä standardointitasosta. Tietyillä alueilla voimme tulevaisuudessa päästä siihen standardoiduilla työkuormilla arvioimaan järjestelmän suorituskykyä tai standardoituja kaavioita latenssijakaumien esittämistä varten. Toistaiseksi arvioijien ja rakentajien paras tapa on kerätä ja julkaista mahdollisimman paljon tietoa ja yksityiskohtaista kuvausta arviointimenetelmistä, jotta se voidaan toistaa ja verrata muihin järjestelmiin.