Ei-teknisen henkilön suosikkikysymys kaikista hajautetuista järjestelmistä on "Kuinka monta tps:tä on lohkoketjussasi?" Vastauksessa annetulla numerolla on kuitenkin yleensä vähän yhteistä sen kanssa, mitä kysyjä haluaisi kuulla. Itse asiassa hän halusi kysyä "sopivatko lohkoketjusi liiketoiminnan vaatimuksiin", ja nämä vaatimukset eivät ole yksi numero, vaan monia ehtoja - tässä ovat verkon vikasietoisuus, lopullisuusvaatimukset, koot, tapahtumien luonne ja monet muut parametrit. Joten vastaus kysymykseen "kuinka monta tps" ei todennäköisesti ole yksinkertainen eikä lähes koskaan täydellinen. Hajautettu järjestelmä, jossa on kymmeniä tai satoja solmuja, jotka suorittavat melko monimutkaisia ​​laskelmia, voivat olla valtavassa määrässä erilaisia ​​​​tiloja, jotka liittyvät verkon tilaan, lohkoketjun sisältöön, teknisiin vioihin, taloudellisiin ongelmiin, verkkoon kohdistuviin hyökkäyksiin ja moniin muihin syihin. . Vaiheet, joissa suorituskykyongelmat ovat mahdollisia, eroavat perinteisistä palveluista, ja lohkoketjuverkkopalvelin on verkkopalvelu, jossa yhdistyvät tietokannan, web-palvelimen ja torrent-asiakkaan toiminnot, mikä tekee siitä erittäin monimutkaisen kaikkien alijärjestelmien kuormitusprofiilin suhteen. : prosessori, muisti, verkko, tallennustila

Sattuu niin, että hajautetut verkot ja lohkoketjut ovat melko erityisiä ja epätavallisia ohjelmistoja keskitetyille ohjelmistokehittäjille. Siksi haluan tuoda esille tärkeitä hajautettujen verkostojen suorituskyvyn ja kestävyyden näkökohtia, lähestymistapoja niiden mittaamiseen ja pullonkaulojen löytämiseen. Tarkastelemme erilaisia ​​suorituskykyongelmia, jotka rajoittavat palvelujen tarjoamisen nopeutta blockchain-käyttäjille, ja panemme merkille tämän tyyppisille ohjelmistoille ominaiset ominaisuudet.

Lohkoketjuasiakkaan palvelupyynnön vaiheet

Jotta voit puhua rehellisesti minkä tahansa enemmän tai vähemmän monimutkaisen palvelun laadusta, sinun on otettava huomioon paitsi keskiarvot myös maksimi/minimi, mediaanit, prosenttipisteet. Teoreettisesti voimme puhua 1000 tps:stä jossain lohkoketjussa, mutta jos 900 tapahtumaa saatiin päätökseen valtavalla nopeudella ja 100 jäi "jumiin" muutamaksi sekunniksi, niin kaikkien tapahtumien keskimääräinen kerätty aika ei ole täysin oikeudenmukainen mittari asiakkaalle. jolle en voinut suorittaa kauppaa muutamassa sekunnissa. Väliaikaiset "reiät", jotka aiheutuvat väliin jääneistä konsensuskierroksista tai verkkojakoista, voivat tuhota palvelun, joka on osoittanut erinomaista suorituskykyä testipenkeillä.

Tällaisten pullonkaulojen tunnistamiseksi on välttämätöntä ymmärtää hyvin vaiheet, joissa todellisella lohkoketjulla voi olla vaikeuksia palvella käyttäjiä. Kuvataan tapahtuman toimituksen ja käsittelyn sykli sekä lohkoketjun uuden tilan saaminen, josta asiakas voi varmistaa, että hänen tapahtumansa on käsitelty ja tilitetty.

1. kauppa muodostuu asiakkaasta
2. kauppa allekirjoitetaan asiakkaalla
3. asiakas valitsee yhden solmuista ja lähettää tapahtumansa siihen
4. asiakas tilaa päivitykset solmun tilatietokantaan odottaen tapahtumansa tulosten ilmestymistä
5. solmu jakaa tapahtuman p2p-verkon yli
6. useita tai yksi BP (lohkotuottaja) käsittelee kertyneitä tapahtumia ja päivittää tilatietokannan
7. BP muodostaa uuden lohkon käsiteltyään tarvittavan määrän tapahtumia
8. BP jakaa uuden lohkon p2p-verkon yli
9. uusi lohko toimitetaan solmuun, jota asiakas käyttää
10. solmu päivittää tilatietokannan
11. solmu näkee asiakasta koskevan päivityksen ja lähettää hänelle tapahtumailmoituksen

Tarkastellaan nyt näitä vaiheita lähemmin ja kuvataan mahdollisia suorituskykyongelmia kussakin vaiheessa. Toisin kuin keskitetyissä järjestelmissä, harkitsemme myös koodin suorittamista verkkoasiakkailla. Melko usein TPS:ää mitattaessa tapahtuman käsittelyaika kerätään solmuilta, ei asiakkaalta - tämä ei ole täysin reilua. Asiakas ei välitä kuinka nopeasti solmu käsitteli tapahtumansa, hänelle tärkeintä on hetki, jolloin luotettava tieto tästä lohkoketjuun sisältyvästä tapahtumasta tulee hänen saatavilleen. Tämä mittari on olennaisesti tapahtuman suoritusaika. Tämä tarkoittaa, että eri asiakkaat, vaikka lähettäisivät saman tapahtuman, voivat vastaanottaa täysin eri aikoja, jotka riippuvat kanavasta, kuormasta ja solmun läheisyydestä jne. Joten on ehdottoman välttämätöntä mitata tämä aika asiakkaista, koska tämä on parametri, joka on optimoitava.

Kaupan valmistelu asiakkaan puolella

Aloitetaan kahdesta ensimmäisestä kohdasta: asiakas muodostaa ja allekirjoittaa kaupan. Kummallista kyllä, tämä voi olla myös lohkoketjun suorituskyvyn pullonkaula asiakkaan näkökulmasta. Tämä on epätavallista keskitetyille palveluille, jotka ottavat kaikki laskelmat ja toiminnot tiedolla ja asiakas yksinkertaisesti laatii lyhyen pyynnön, joka voi pyytää suuren määrän dataa tai laskelmia ja saada valmiin tuloksen. Lohkoketjuissa asiakaskoodista tulee entistä tehokkaampi ja lohkoketjun ydin tulee yhä kevyemmäksi ja massiiviset laskentatehtävät siirtyvät yleensä asiakasohjelmistoon. Lohkoketjuissa on asiakkaita, jotka voivat valmistella yhtä tapahtumaa melko pitkään (puhun erilaisista merkletodistuksista, ytimekkäistä todisteista, kynnysallekirjoituksista ja muista monimutkaisista operaatioista asiakaspuolella). Hyvä esimerkki helposta ketjun varmentamisesta ja asiakkaan tapahtuman raskaasta valmistelusta on todistus jäsenyydestä Merkle-puuhun perustuvaan listaan, täältä artikkeli.

Älä myöskään unohda, että asiakaskoodi ei yksinkertaisesti lähetä tapahtumia lohkoketjuun, vaan kysyy ensin lohkoketjun tilaa - ja tämä toiminta voi vaikuttaa verkon ja lohkoketjun solmujen ruuhkautumiseen. Joten mittauksia tehtäessä olisi järkevää jäljitellä asiakaskoodin käyttäytymistä mahdollisimman täydellisesti. Vaikka lohkoketjussasi on tavallisia kevyitä asiakkaita, jotka antavat tavallisen digitaalisen allekirjoituksen yksinkertaisimpaan tapahtumaan siirtääkseen jonkin omaisuuden, asiakasta koskevia laskelmia tehdään joka vuosi yhä massiivisempia, krypto-algoritmit vahvistuvat, ja tämä osa käsittelystä voi muuttua merkittäväksi pullonkaulaksi tulevaisuudessa. Ole siis varovainen ja älä missaa tilannetta, kun 3.5s kestävässä tapahtumassa 2.5s kuluu tapahtuman valmisteluun ja allekirjoittamiseen ja 1.0s sen lähettämiseen verkkoon ja vastauksen odottamiseen. Tämän pullonkaulan riskien arvioimiseksi sinun on kerättävä mittareita asiakaskoneista, ei vain lohkoketjun solmuista.

Tapahtuman lähettäminen ja sen tilan seuranta

Seuraava vaihe on lähettää tapahtuma valittuun lohkoketjusolmuun ja vastaanottaa sen hyväksymisen tila tapahtumapooliin. Tämä vaihe on samanlainen kuin tavallinen tietokantakäyttö: solmun on tallennettava tapahtuma pooliin ja aloitettava sitä koskevien tietojen jakaminen p2p-verkon kautta. Lähestymistapa suorituskyvyn arviointiin tässä on samanlainen kuin perinteisten Web API -mikropalveluiden suorituskyvyn arviointi, ja itse lohkoketjuissa tapahtuvia tapahtumia voidaan päivittää ja muuttaa aktiivisesti niiden tilaa. Yleensä joidenkin lohkoketjujen tapahtumatietojen päivittäminen voi tapahtua useita kertoja, esimerkiksi vaihdettaessa ketjuhaarukoiden välillä tai kun BP:t ilmoittavat aikovansa sisällyttää tapahtuman lohkoon. Tämän poolin koon ja siinä olevien tapahtumien määrän rajoitukset voivat vaikuttaa lohkoketjun suorituskykyyn. Jos tapahtumapooli on täytetty mahdollisimman suuriksi tai ei mahdu RAM-muistiin, verkon suorituskyky voi laskea jyrkästi. Lohkoketjuilla ei ole keskitettyä keinoa suojautua roskapostitulvilta, ja jos lohkoketju tukee suuria tapahtumia ja alhaisia ​​maksuja, tämä voi aiheuttaa tapahtumapoolin ylivuodon – toinen mahdollinen suorituskyvyn pullonkaula.

Lohkoketjuissa asiakas lähettää tapahtuman mihin tahansa haluamaansa lohkoketjusolmuun, tapahtuman hash on yleensä asiakkaan tiedossa ennen lähettämistä, joten hänen tarvitsee vain saada yhteys ja lähetyksen jälkeen odottaa lohkoketjun muuttumista. sen tila, mikä mahdollistaa hänen tapahtumansa. Huomaa, että mittaamalla "tps" voit saada täysin erilaisia ​​​​tuloksia eri tavoille muodostaa yhteys lohkoketjusolmuun. Tämä voi olla tavallinen HTTP RPC tai WebSocket, jonka avulla voit toteuttaa tilausmallin. Toisessa tapauksessa asiakas saa ilmoituksen aikaisemmin ja solmu kuluttaa vähemmän resursseja (pääasiassa muistia ja liikennettä) vastauksiin tapahtuman tilasta. Joten mitattaessa "tps" on tarpeen ottaa huomioon tapa, jolla asiakkaat muodostavat yhteyden solmuihin. Tämän pullonkaulan riskien arvioimiseksi benchmark-lohkoketjun on kyettävä emuloimaan asiakkaita sekä WebSocket- että HTTP RPC-pyynnöillä todellisia verkkoja vastaavissa suhteissa sekä muuttamaan tapahtumien luonnetta ja kokoa.

Tämän pullonkaulan riskien arvioimiseksi sinun on myös kerättävä mittareita asiakaskoneista, ei vain lohkoketjun solmuista.

Tapahtumien ja lohkojen siirto p2p-verkon kautta

Lohkoketjuissa peer-to-peer (p2p) -verkkoa käytetään transaktioiden ja lohkojen siirtämiseen osallistujien välillä. Tapahtumat leviävät koko verkossa yhdestä solmusta alkaen, kunnes ne saavuttavat vertaislohkotuottajien, jotka pakkaavat tapahtumat lohkoihin ja jakavat samalla p2p:llä uudet lohkot kaikkiin verkon solmuihin. Useimpien nykyaikaisten p2p-verkkojen perustana ovat Kademlia-protokollan erilaiset modifikaatiot. Täällä hyvä yhteenveto tästä protokollasta ja täällä - artikkeli, jossa on erilaisia ​​​​mittauksia BitTorrent-verkossa, josta voidaan ymmärtää, että tämän tyyppinen verkko on monimutkaisempi ja vähemmän ennustettava kuin keskitetyn palvelun jäykästi konfiguroitu verkko. Myös, täällä artikkeli erilaisten mielenkiintoisten mittareiden mittaamisesta Ethereum-solmuille.

Lyhyesti sanottuna kukin tällaisten verkkojen vertaisverkko ylläpitää omaa dynaamista listaansa muista vertaisverkoista, joilta se pyytää tietolohkoja, joita sisältö käsittelee. Kun vertaiskumppani vastaanottaa pyynnön, se joko antaa tarvittavat tiedot tai välittää pyynnön luettelosta seuraavalle näennäissatunnaiselle vertaiselle ja saatuaan vastauksen välittää sen pyynnön esittäjälle ja tallentaa sen hetkeksi välimuistiin antaen tämän tietolohko aikaisemmin seuraavalla kerralla. Täten suosittu tieto päätyy suureen määrään suuren joukon vertaisten välimuistia ja epäsuosittu tieto korvataan vähitellen. Vertaiskäyttäjät pitävät kirjaa siitä, kuka on siirtänyt kuinka paljon tietoa kenelle, ja verkosto yrittää kannustaa aktiivisia jakelijoita korottamalla heidän luokituksiaan ja tarjoamalla heille korkeampaa palvelutasoa, mikä automaattisesti syrjäyttää ei-aktiiviset osallistujat vertaisluetteloista.

Joten tapahtuma on nyt hajautettava koko verkkoon, jotta lohkotuottajat voivat nähdä sen ja sisällyttää sen lohkoon. Solmu "jakaa" aktiivisesti uuden tapahtuman kaikille ja kuuntelee verkkoa odottaen lohkoa, jonka indeksiin vaadittu tapahtuma ilmestyy ilmoittaakseen odottavalle asiakkaalle. Aika, joka kuluu verkoilta tiedon siirtämiseen toisilleen uusista tapahtumista ja lohkoista p2p-verkoissa, riippuu hyvin monista tekijöistä: lähellä olevien rehellisten solmujen määrästä (verkon näkökulmasta katsottuna), ”lämpimästä ylös” näiden solmujen välimuistista, lohkojen koosta, tapahtumista, muutosten luonteesta, verkon maantieteellisestä sijainnista, solmujen määrästä ja monista muista tekijöistä. Suorituskykymittareiden monimutkaiset mittaukset tällaisissa verkoissa ovat monimutkainen asia, ja pyyntöjen käsittelyaika on arvioitava samanaikaisesti sekä asiakkailla että vertaisilla (lohkoketjusolmuilla). Ongelmat missä tahansa p2p-mekanismeissa, virheelliset tietojen häätö ja välimuisti, aktiivisten vertaisluetteloiden tehoton hallinta ja monet muut tekijät voivat aiheuttaa viiveitä, jotka vaikuttavat koko verkon tehokkuuteen, ja tämä pullonkaula on vaikein analysoida. , testaus ja tulosten tulkinta.

Blockchain-käsittely ja tilatietokannan päivitys

Lohkoketjun tärkein osa on konsensusalgoritmi, sen soveltaminen verkosta saatuihin uusiin lohkoihin ja tapahtumien käsittely sekä tulosten kirjaaminen tilatietokantaan. Uuden lohkon lisäämisen ketjuun ja sitten pääketjun valitsemisen pitäisi toimia mahdollisimman nopeasti. Todellisessa elämässä "pitäisi" ei kuitenkaan tarkoita "toimii", ja voidaan esimerkiksi kuvitella tilanne, jossa kaksi pitkää kilpailevaa ketjua vaihtavat jatkuvasti toisiaan ja muuttavat poolissa olevien tuhansien transaktioiden metatietoja kullakin vaihdolla. , ja rullaa jatkuvasti osavaltiotietokantaa. Tämä vaihe on pullonkaulan määrittelyn kannalta yksinkertaisempi kuin p2p-verkkokerros, koska tapahtuman suoritus ja konsensusalgoritmi ovat tiukasti deterministisiä, ja täällä on helpompi mitata mitä tahansa.
Tärkeintä ei ole sekoittaa tämän vaiheen suorituskyvyn satunnaista heikkenemistä verkkoongelmiin - solmut ovat hitaampia toimittamaan lohkoja ja tietoa pääketjusta, ja ulkoiselle asiakkaalle tämä voi näyttää hitaalta verkolta, vaikka ongelma piileekin aivan eri paikka.

Suorituskyvyn optimoimiseksi tässä vaiheessa on hyödyllistä kerätä ja seurata mittareita itse solmuista ja sisällyttää niihin tilatietokannan päivittämiseen liittyvät tiedot: solmussa käsiteltyjen lohkojen lukumäärä, niiden koko, tapahtumien määrä, ketjun haarukoiden välisten kytkimien lukumäärä, virheellisten lohkojen määrä, virtuaalikoneen toiminta-aika, tietojen toimitusaika jne. Tämä estää verkko-ongelmien sekoittamisen ketjunkäsittelyalgoritmien virheisiin.

Tapahtumia käsittelevä virtuaalikone voi olla hyödyllinen tietolähde, joka voi optimoida lohkoketjun toiminnan. Muistin varausten määrä, luku-/kirjoituskäskyjen määrä ja muut sopimuskoodin suorittamisen tehokkuuteen liittyvät mittarit voivat tarjota kehittäjille paljon hyödyllistä tietoa. Samaan aikaan älykkäät sopimukset ovat ohjelmia, mikä tarkoittaa teoriassa, että ne voivat kuluttaa mitä tahansa resursseja: prosessori/muisti/verkko/tallennus, joten tapahtumien käsittely on melko epävarma vaihe, joka lisäksi muuttuu suuresti versioiden välillä liikkuessa. ja sopimuskoodeja vaihdettaessa. Siksi myös tapahtumien käsittelyyn liittyviä mittareita tarvitaan lohkoketjun suorituskyvyn tehokkaaseen optimointiin.

Asiakkaan vastaanotto ilmoituksesta tapahtuman sisällyttämisestä lohkoketjuun

Tämä on viimeinen vaihe lohkoketjuasiakkaan vastaanottaessa palvelun, muihin vaiheisiin verrattuna suuria yleiskustannuksia ei synny, mutta silti kannattaa harkita mahdollisuutta, että asiakas saa solmulta laajan vastauksen (esim. älysopimuksen). palauttaa datajoukon). Joka tapauksessa tämä kohta on tärkein sille, joka kysyi "kuinka monta tps:tä on lohkoketjussasi?", koska Tällä hetkellä palvelun vastaanottamisaika kirjataan.

Tässä paikassa lähetetään aina koko aika, jonka asiakas joutui käyttämään lohkoketjun vastausta odottaessaan; juuri tällä kertaa käyttäjä odottaa vahvistusta sovelluksessaan, ja juuri sen optimointi on kehittäjien päätehtävä.

Johtopäätös

Tämän seurauksena voimme kuvata lohkoketjuille suoritettavien toimintojen tyyppejä ja jakaa ne useisiin luokkiin:

1. kryptografiset muunnokset, todistelurakentaminen
2. peer-to-peer -verkot, tapahtumat ja lohkon replikointi
3. tapahtumien käsittely, älykkäiden sopimusten toteuttaminen
4. lohkoketjun muutosten soveltaminen tilatietokantaan, tapahtumien ja lohkojen tietojen päivittäminen
5. vain luku -pyynnöt tilatietokantaan, lohkoketjusolmusovellusliittymään, tilauspalveluihin

Yleisesti ottaen nykyaikaisten lohkoketjusolmujen tekniset vaatimukset ovat erittäin vakavat - nopeat CPU:t salaukseen, suuri määrä RAM-muistia tilatietokannan tallentamiseen ja nopeaan käyttöön, verkkovuorovaikutus käyttämällä suurta määrää samanaikaisesti avoimia yhteyksiä ja suuri tallennustila. Tällaiset korkeat vaatimukset ja erityyppisten toimintojen runsaus johtavat väistämättä siihen, että solmuilla ei välttämättä ole tarpeeksi resursseja, jolloin mistä tahansa yllä mainituista vaiheista voi muodostua toinen pullonkaula koko verkon suorituskyvylle.

Kun suunnittelet ja arvioit lohkoketjujen suorituskykyä, sinun on otettava kaikki nämä kohdat huomioon. Tätä varten sinun on kerättävä ja analysoitava mittareita samanaikaisesti asiakkailta ja verkkosolmuilta, etsittävä korrelaatioita niiden välillä, arvioitava aika, joka kuluu palvelujen tarjoamiseen asiakkaille, otettava huomioon kaikki tärkeimmät resurssit: prosessori/muisti/verkko/tallennus , ymmärtää, miten niitä käytetään ja vaikuttaa toisiinsa. Kaikki tämä tekee eri lohkoketjujen nopeuksien vertaamisesta "kuinka monta TPS:ää" muodossa erittäin kiittämättömän tehtävän, koska erilaisia ​​konfiguraatioita ja tiloja on valtava määrä. Suurissa keskitetyissä järjestelmissä, satojen palvelimien klustereissa, nämä ongelmat ovat myös monimutkaisia ​​ja vaativat myös suuren määrän eri mittareiden keräämistä, mutta lohkoketjuissa johtuen p2p-verkoista, virtuaalikoneista, jotka käsittelevät sopimuksia, sisäisiä säästöjä, tutkintojen määrää. vapaus on paljon suurempi, mikä tekee testistä jopa useilla palvelimilla, se ei ole viitteellinen ja näyttää vain erittäin likimääräisiä arvoja, joilla ei ole juuri mitään yhteyttä todellisuuteen.

Siksi, kun kehitämme lohkoketjun ytimessä, arvioidaksemme suorituskykyä ja vastataksemme kysymykseen "onko se parantunut viime kerralla?", käytämme melko monimutkaista ohjelmistoa, joka ohjaa lohkoketjun käynnistämisen kymmenien solmujen kanssa ja käynnistää automaattisesti vertailuarvon ja kerää mittareita. Ilman näitä tietoja on äärimmäisen vaikeaa tehdä virheenkorjausprotokollia, jotka toimivat useiden osallistujien kanssa.

Joten kun saat kysymyksen "kuinka monta TPS:ää lohkoketjussasi on?", tarjoa keskustelukumppanillesi teetä ja kysy, onko hän valmis katsomaan tusinaa kaaviota ja kuuntelemaan myös kaikkia kolmea lohkoketjun suorituskykyongelmia ja ehdotuksiasi ratkaisemaan niitä...

Lähde: will.com