In favorite fraach oer elk ferspraat systeem fan in net-technysk persoan is "Hoefolle tps binne op jo blockchain?" It nûmer dat yn antwurd wurdt jûn hat lykwols gewoanlik net folle mienskiplik mei wat de fraachsteller graach hearre wol. Yn feite woe hy freegje "sil jo blockchain passe by myn bedriuweasken," en dizze easken binne net ien nûmer, mar in protte betingsten - hjir binne netwurkfouttolerânsje, finaliteiteasken, grutte, aard fan transaksjes en in protte oare parameters. Dus it antwurd op 'e fraach "hoefolle tps" is net wierskynlik ienfâldich, en hast noait folslein. In ferspraat systeem mei tsientallen of hûnderten knopen dy't frij komplekse berekkeningen útfiere, kin wêze yn in grut oantal ferskillende steaten yn ferbân mei de steat fan it netwurk, de ynhâld fan 'e blockchain, technyske mislearrings, ekonomyske problemen, oanfallen op it netwurk en in protte oare redenen . De stadia wêryn prestaasjesproblemen mooglik binne ferskille fan tradisjonele tsjinsten, en in blockchain-netwurktsjinner is in netwurktsjinst dy't de funksjonaliteit fan in databank, webserver en torrentclient kombinearret, wat it ekstreem kompleks makket yn termen fan it loadprofyl op alle subsystemen : prosessor, ûnthâld, netwurk, opslach
It bart sa dat desintralisearre netwurken en blockchains frij spesifike en ûngewoane software binne foar sintralisearre software-ûntwikkelders. Dêrom wol ik wichtige aspekten beljochtsje fan de prestaasjes en duorsumens fan desintralisearre netwurken, oanpakken om se te mjitten en knelpunten te finen. Wy sille sjen nei ferskate prestaasjesproblemen dy't de snelheid beheine fan it leverjen fan tsjinsten oan blockchain-brûkers en notearje de skaaimerken fan dit soarte software.
Stappen fan in tsjinstfersyk troch in blockchain-kliïnt
Om earlik te praten oer de kwaliteit fan elke min of mear komplekse tsjinst, moatte jo net allinich de gemiddelde wearden rekkenje, mar ek maksimaal/minimum, medianen, percentiles. Teoretysk kinne wy prate oer 1000 tps yn guon blockchain, mar as 900 transaksjes waarden foltôge mei enoarme snelheid, en 100 waarden "stutsen" foar in pear sekonden, dan is de gemiddelde tiid sammele oer alle transaksjes net in folslein earlike metrysk foar in kliïnt dy't ik koe net ôfmeitsje de transaksje yn in pear sekonden. Tydlike "gaten" feroarsake troch miste konsensusrûnen of netwurksplitsingen kinne in tsjinst sterk ferneatigje dy't poerbêste prestaasje hat sjen litten op testbanken.
Om sokke knelpunten te identifisearjen, is it nedich om in goed begryp te hawwen fan 'e stadia wêryn in echte blockchain swierrichheid kin hawwe om brûkers te tsjinjen. Litte wy de syklus beskriuwe fan it leverjen en ferwurkjen fan in transaksje, en ek it krijen fan in nije steat fan 'e blockchain, wêrfan de kliïnt kin ferifiearje dat syn transaksje is ferwurke en ferantwurde.
- de transaksje wurdt foarme op de klant
- de transaksje wurdt tekene op de klant
- de klant selektearret ien fan de knopen en stjoert syn transaksje nei it
- de klant abonnearret op updates foar de steatdatabase fan 'e knooppunt, wachtsjend op' e resultaten fan har transaksje om te ferskinen
- it knooppunt ferspraat de transaksje oer it p2p-netwurk
- ferskate of ien BP (block producer) ferwurket opboude transaksjes, it bywurkjen fan de steat databank
- BP foarmet in nij blok nei it ferwurkjen fan it fereaske oantal transaksjes
- BP distribuearret in nij blok oer it p2p netwurk
- it nije blok wurdt levere oan it knooppunt dat de kliïnt tagong hat
- node updates steat databank
- de knooppunt sjocht de update oangeande de klant en stjoert him in transaksje notifikaasje
Litte wy no in tichterby besjen op dizze stadia en beskriuwe de potensjele prestaasjesproblemen yn elke poadium. Oars as sintralisearre systemen, sille wy ek koade-útfiering beskôgje op netwurkkliïnten. Hiel faak, by it mjitten fan TPS, wurdt de ferwurkingstiid fan transaksjes sammele fan 'e knopen, en net fan' e kliïnt - dit is net hielendal earlik. De klant makket it net út hoe fluch it knooppunt syn transaksje ferwurke; it wichtichste foar him is it momint dat betroubere ynformaasje oer dizze transaksje opnommen yn 'e blockchain foar him beskikber wurdt. It is dizze metrik dy't yn essinsje de tiid foar útfiering fan transaksjes is. Dit betsjut dat ferskate kliïnten, sels it ferstjoeren fan deselde transaksje, folslein ferskillende tiden kinne ûntfange, dy't ôfhinklik binne fan it kanaal, de lading en de tichtby fan 'e knooppunt, ensfh. Sa is it perfoarst needsaaklik om dizze tiid op kliïnten te mjitten, om't dit de parameter is dy't optimisearre wurde moat.
It tarieden fan in transaksje oan 'e klantkant
Litte wy begjinne mei de earste twa punten: de transaksje wurdt foarme en tekene troch de klant. Frjemd genôch kin dit ek in knelpunt wêze fan blockchain-prestaasjes út it eachpunt fan 'e klant. Dit is ûngewoan foar sintralisearre tsjinsten, dy't alle berekkeningen en operaasjes mei gegevens oernimme, en de kliïnt taret gewoan in koart fersyk op dat in grutte hoemannichte gegevens of berekkeningen oanfreegje kin, it krijen fan in klear resultaat. Yn blockchains wurdt de kliïntkoade mear en machtiger, en de blockchain-kearn wurdt hieltyd lichter, en massive komputertaken wurde meastentiids oerdroegen oan 'e kliïntsoftware. Yn blockchains binne d'r kliïnten dy't ien transaksje foar in lange tiid kinne tariede (ik ha it oer ferskate merkle-bewiis, succinct bewiis, drompel-hântekeningen en oare komplekse operaasjes oan 'e kliïntside). In goed foarbyld fan maklike on-chain ferifikaasje en swiere tarieding fan in transaksje op 'e klant is bewiis fan lidmaatskip yn in list basearre op Merkle-tree, hjir .
Ferjit ek net dat de kliïntkoade net gewoan transaksjes nei de blockchain stjoert, mar earst freget de steat fan 'e blockchain - en dizze aktiviteit kin ynfloed hawwe op de oerlêst fan it netwurk en blockchain-knooppunten. Dat, by it nimmen fan mjittingen, soe it ridlik wêze om it gedrach fan 'e kliïntkoade sa folslein mooglik te emulearjen. Sels as yn jo blockchain gewoane ljochtkliïnten binne dy't in reguliere digitale hantekening sette op 'e ienfâldichste transaksje om wat asset oer te dragen, binne d'r alle jierren noch mear massive berekkeningen op' e kliïnt, krypto-algoritmen wurde sterker, en dit diel fan 'e ferwurking kin wurde yn 'e takomst in wichtich knelpunt. Wês dêrom foarsichtich en mis de situaasje net as, yn in transaksje dy't 3.5s duorret, 2.5s wurde bestege oan it tarieden en ûndertekenjen fan 'e transaksje, en 1.0s oan it ferstjoeren nei it netwurk en wachtsje op in antwurd. Om de risiko's fan dit knelpunt te beoardieljen, moatte jo metriken sammelje fan kliïntmasines, en net allinich fan blockchain-knooppunten.
It ferstjoeren fan in transaksje en tafersjoch op syn status
De folgjende stap is om de transaksje te stjoeren nei de selekteare blockchain-knooppunt en ûntfange de status fan it akseptearjen yn 'e transaksjepool. Dit poadium is fergelykber mei in gewoane database tagong; de knooppunt moat de transaksje opnimme yn it swimbad en begjinne ynformaasje oer it te fersprieden fia it p2p-netwurk. De oanpak foar it beoardieljen fan prestaasjes hjir is fergelykber mei it beoardieljen fan 'e prestaasjes fan tradysjonele Web API-mikrotsjinsten, en de transaksjes sels yn blockchains kinne bywurke wurde en har status aktyf feroarje. Yn 't algemien kin it bywurkjen fan transaksjeynformaasje op guon blokken meardere kearen foarkomme, bygelyks by it wikseljen tusken kettingfoarken of as BP's har bedoeling oankundigje om in transaksje yn in blok op te nimmen. Limiten op 'e grutte fan dit swimbad en it oantal transaksjes dêryn kinne de prestaasjes fan' e blockchain beynfloedzje. As de transaksje pool is fol oan de maksimale mooglike grutte, of past net yn RAM, netwurk prestaasjes kin sakje skerp. Blockchains hawwe gjin sintralisearre middels om te beskermjen tsjin in oerstreaming fan junkberjochten, en as de blockchain transaksjes mei hege folume en lege fergoedingen stipet, kin dit de transaksjepool oerrinne - in oare potinsjele knelpunt foar prestaasjes.
Yn blockchains stjoert de klant in transaksje nei elke blockchain-knoop dy't hy liket, de hash fan 'e transaksje is normaal bekend by de klant foar it ferstjoeren, dus alles wat hy hoecht te dwaan is de ferbining te berikken en, nei oerdracht, wachtsje op' e blockchain om te feroarjen syn steat, wêrtroch syn transaksje. Tink derom dat troch "tps" te mjitten kinne jo folslein oare resultaten krije foar ferskate metoaden fan ferbining mei in blockchain-knooppunt. Dit kin in gewoane HTTP RPC wêze as in WebSocket wêrmei jo it "abonnearje" patroan kinne ymplementearje. Yn it twadde gefal sil de kliïnt earder in notifikaasje krije, en it knooppunt sil minder boarnen (benammen ûnthâld en ferkear) besteegje oan antwurden oer de transaksjestatus. Dus by it mjitten fan "tps" is it nedich om rekken te hâlden mei de manier wêrop kliïnten ferbine mei knopen. Dêrom, om de risiko's fan dizze knipehals te beoardieljen, moat de benchmark-blockchain klanten kinne emulearje mei sawol WebSocket- as HTTP RPC-oanfragen, yn proporsjes dy't oerienkomme mei echte netwurken, en ek de aard fan transaksjes en har grutte feroarje.
Om de risiko's fan dit knelpunt te beoardieljen, moatte jo ek metriken sammelje fan kliïntmasines, en net allinich fan blockchain-knooppunten.
Oerdracht fan transaksjes en blokken fia p2p netwurk
Yn blockchains wurdt peer-to-peer (p2p) netwurk brûkt om transaksjes en blokken oer te dragen tusken dielnimmers. Transaksjes ferspraat oer it netwurk, begjinnend fan ien fan 'e knooppunten, oant se berikke peer blok produsinten, dy't pakke transaksjes yn blokken en, mei help fan deselde p2p, fersprieden nije blokken nei alle netwurk knooppunten. De basis fan de measte moderne p2p-netwurken is ferskate oanpassingen fan it Kademlia-protokol. in goede gearfetting fan dit protokol, en - in artikel mei ferskate mjittingen yn it BitTorrent-netwurk, wêrfan men kin begripe dat dit soarte netwurk komplekser en minder foarsisber is as in rigid konfigureare netwurk fan in sintralisearre tsjinst. Ek, artikel oer it mjitten fan ferskate nijsgjirrige metriken foar Ethereum-knooppunten.
Koartsein, elke peer yn sokke netwurken ûnderhâldt syn eigen dynamyske list fan oare peers wêrfan it blokken fan ynformaasje freget dy't oanpakt wurde troch ynhâld. As in peer in fersyk ûntfangt, jout hy de nedige ynformaasje of jout it fersyk troch oan de folgjende pseudo-willekeurige peer út 'e list, en nei't er in antwurd krige, jout it troch oan 'e oanfreger en cache it foar in skoft, wêrtroch dit blok ynformaasje earder de folgjende kear. Sa komt populêre ynformaasje telâne yn in grut tal caches fan in grut oantal peers, en wurdt ympopulêre ynformaasje stadichoan ferfongen. Peers hâlde registers fan wa't hoefolle ynformaasje oerdroegen hat oan wa, en it netwurk besiket aktive distributeurs te stimulearjen troch har wurdearrings te ferheegjen en har in heger nivo fan tsjinst te jaan, automatysk ynaktive dielnimmers fan peerlisten te ferpleatsen.
Dat, de transaksje moat no oer it netwurk ferdield wurde, sadat blokprodusinten it kinne sjen en yn it blok opnimme. It knooppunt aktyf "ferspriedt" in nije transaksje oan elkenien en harket nei it netwurk, wachtsjend op in blok yn 'e yndeks wêrfan de fereaske transaksje sil ferskine om de wachtsjende klant te melden. De tiid dy't it netwurk duorret om ynformaasje oer nije transaksjes en blokken nei elkoar oer te bringen yn p2p-netwurken hinget ôf fan in heul grut oantal faktoaren: it oantal earlike knooppunten dy't yn 'e buert wurkje (út it eachpunt fan it netwurk), de "waarm- up" fan 'e caches fan dizze knopen, de grutte fan blokken, transaksjes, de aard fan feroaringen, netwurkgeografy, oantal knopen en in protte oare faktoaren. Komplekse mjittingen fan prestaasjesmetriken yn sokke netwurken binne in komplekse saak; it is needsaaklik om tagelyk de ferwurkingstiid fan fersyk te evaluearjen op sawol kliïnten as peers (blockchain-knooppunten). Problemen yn ien fan 'e p2p-meganismen, ferkearde gegevensútkearing en caching, net effektyf behear fan listen mei aktive peers, en in protte oare faktoaren kinne fertragingen feroarsaakje dy't de effisjinsje fan it heule netwurk as gehiel beynfloedzje, en dit knelpunt is it dreechste te analysearjen , test en ynterpretaasje fan resultaten.
Blockchain-ferwurking en bywurkjen fan steatdatabase
It wichtichste diel fan 'e blockchain is it konsensusalgoritme, har tapassing op nije blokken ûntfongen fan it netwurk en de ferwurking fan transaksjes mei it opnimmen fan' e resultaten yn 'e steatdatabase. It tafoegjen fan in nij blok oan 'e keatling en dan it selektearjen fan' e haadketen moat sa gau mooglik wurkje. Yn it echte libben betsjut "moat" lykwols net "wurket", en men kin bygelyks in situaasje foarstelle wêr't twa lange konkurrearjende keatlingen konstant tusken har wikselje, en feroarje de metadata fan tûzenen transaksjes yn it swimbad by elke skeakel , en hieltyd de steatsdatabank weromdraaie. Dit poadium, yn termen fan it definiearjen fan 'e knelpunt, is ienfâldiger dan de p2p netwurklaach, om't transaksje útfiering en konsensus algoritme binne strikt deterministysk, en it is makliker om te mjitten neat hjir.
It wichtichste is om willekeurige degradaasje yn 'e prestaasjes fan dit poadium net te ferwikseljen mei netwurkproblemen - knooppunten binne stadiger yn it leverjen fan blokken en ynformaasje oer de haadketen, en foar in eksterne kliïnt kin dit lykje op in traach netwurk, hoewol it probleem leit yn in folslein oar plak.
Om de prestaasjes op dit poadium te optimalisearjen, is it handich om metriken fan 'e knopen sels te sammeljen en te kontrolearjen, en yn har op te nimmen dy't relatearre binne oan it bywurkjen fan' e steatdatabase: it oantal blokken ferwurke op 'e knooppunt, har grutte, it oantal transaksjes, it oantal skeakels tusken kettingvorken, it oantal ûnjildige blokken, operaasjetiid fan firtuele masines, tiid foar gegevensferfier, ensfh. Dit sil foarkomme dat netwurkproblemen betize wurde mei flaters yn algoritmen foar ketenferwurking.
In firtuele masine dy't transaksjes ferwurkje kin in nuttige boarne fan ynformaasje wêze dy't de wurking fan 'e blockchain kin optimisearje. It oantal ûnthâld tawizings, it oantal lêzen / skriuwe ynstruksjes, en oare metriken yn ferbân mei de effisjinsje fan kontrakt koade útfiering kin leverje in soad nuttige ynformaasje oan ûntwikkelders. Tagelyk binne tûke kontrakten programma's, wat betsjut dat se yn teory ien fan 'e boarnen kinne konsumearje: cpu / ûnthâld / netwurk / opslach, sadat transaksjeferwurking in nochal ûnwisse poadium is, dy't boppedat sterk feroaret by it ferpleatsen tusken ferzjes en by it feroarjen fan kontrakt koades. Dêrom binne metriken yn ferbân mei transaksjeferwurking ek nedich om de prestaasjes fan blockchain effektyf te optimalisearjen.
Untfangst troch de kliïnt fan in notifikaasje oer it opnimmen fan in transaksje yn 'e blockchain
Dit is de lêste etappe fan 'e blockchain-kliïnt dy't de tsjinst ûntfangt; yn ferliking mei oare stadia binne d'r gjin grutte overheadkosten, mar it is noch altyd de muoite wurdich te beskôgjen dat de klant in voluminous antwurd krijt fan 'e knooppunt (bygelyks in tûk kontrakt in array fan gegevens weromjaan). Yn alle gefallen is dit punt it wichtichste foar dejinge dy't de fraach stelde "hoefolle tps binne yn jo blockchain?", om't Op dit stuit wurdt de tiid fan it ûntfangen fan de tsjinst opnommen.
Op dit plak is d'r altyd in ferstjoering fan 'e folsleine tiid dy't de klant moast besteegje wachtsjen op in antwurd fan' e blockchain; it is dizze kear dat de brûker sil wachtsje op befêstiging yn syn applikaasje, en it is syn optimalisaasje dat is de wichtichste taak fan de ûntwikkelders.
konklúzje
As gefolch kinne wy de soarten operaasjes beskriuwe dy't wurde útfierd op blockchains en ferdield yn ferskate kategoryen:
- kryptografyske transformaasjes, bewiiskonstruksje
- peer-to-peer netwurken, transaksje en blokkearje replikaasje
- transaksje ferwurkjen, útfiering fan smart kontrakten
- it tapassen fan wizigingen yn 'e blockchain oan' e steatdatabase, bywurkjen fan gegevens oer transaksjes en blokken
- allinnich-lêsoanfragen foar steatdatabase, blockchain node API, abonnemintstsjinsten
Yn 't algemien binne de technyske easken foar moderne blockchain-knooppunten ekstreem serieus - snelle CPU's foar kryptografy, in grutte hoemannichte RAM om te bewarjen en fluch tagong ta de steatdatabase, netwurkynteraksje mei in grut oantal tagelyk iepen ferbiningen en grutte opslach. Sokke hege easken en de oerfloed fan ferskate soarten operaasjes liede ûnûntkomber ta it feit dat knooppunten miskien net genôch boarnen hawwe, en dan kin ien fan 'e hjirboppe besprutsen stadia in oare knelpunt wurde foar de algemiene netwurkprestaasjes.
By it ûntwerpen en evaluearjen fan de prestaasjes fan blockchains, moatte jo al dizze punten rekken hâlde. Om dit te dwaan moatte jo metriken tagelyk sammelje en analysearje fan kliïnten en netwurkknooppunten, sykje nei korrelaasjes tusken har, skatte de tiid dy't it nimt om tsjinsten oan kliïnten te leverjen, rekken hâlde mei alle haadboarnen: cpu / ûnthâld / netwurk / opslach , begripe hoe't se brûkt wurde en beynfloedzje inoar. Dit alles makket it fergelykjen fan de snelheden fan ferskate blockchains yn 'e foarm fan "hoefolle TPS" in ekstreem tankbere taak, om't d'r in grut oantal ferskillende konfiguraasjes en steaten binne. Yn grutte sintralisearre systemen, klusters fan hûnderten servers, binne dizze problemen ek kompleks en fereaskje ek it sammeljen fan in grut oantal ferskillende metriken, mar yn blockchains, troch p2p-netwurken, firtuele masines dy't kontrakten ferwurkjen, ynterne ekonomyen, it oantal graden fan frijheid is folle grutter, wat makket de test sels op ferskate servers, it is net-yndikatyf en toant allinich ekstreem sawat wearden dy't hast gjin ferbining hawwe mei de realiteit.
Dêrom, by it ûntwikkeljen fan 'e blockchain-kearn, om prestaasjes te evaluearjen en de fraach te beantwurdzjen "is it ferbettere yn ferliking mei de lêste kear?" Wy brûke frij komplekse software dy't de lansearring fan in blockchain mei tsientallen knopen orkestreart en automatysk in benchmark lanseart en metriken sammelt ; sûnder dizze ynformaasje is it ekstreem lestich om protokollen te debuggen dy't wurkje mei meardere dielnimmers.
Dus, as jo de fraach ûntfange "hoefolle TPS binne yn jo blockchain?", Bied jo petearpartner wat tee en freegje oft hy ree is om te sjen nei in tsiental grafiken en harkje ek nei alle trije doazen fan blockchain-prestaasjesproblemen en jo suggestjes foar se oplosse ...
Boarne: www.habr.com