'n Gunstelingvraag oor enige verspreide stelsel van 'n nie-tegniese persoon is "Hoeveel tps is op jou blokketting?" Die nommer wat in antwoord gegee word, het egter gewoonlik min gemeen met wat die vraagsteller graag wil hoor. Trouens, hy wou vra "sal jou blokketting by my besigheidsvereistes pas," en hierdie vereistes is nie een nommer nie, maar baie voorwaardes - hier is netwerkfouttoleransie, finaliteitvereistes, groottes, aard van transaksies en baie ander parameters. Die antwoord op die vraag "hoeveel tps" is dus onwaarskynlik eenvoudig, en amper nooit volledig nie. 'n Verspreide stelsel met tien of honderde nodusse wat redelik komplekse berekeninge uitvoer, kan in 'n groot aantal verskillende toestande wees wat verband hou met die toestand van die netwerk, die inhoud van die blokketting, tegniese foute, ekonomiese probleme, aanvalle op die netwerk en baie ander redes . Die stadiums waarin prestasieprobleme moontlik is verskil van tradisionele dienste, en 'n blokkettingnetwerkbediener is 'n netwerkdiens wat die funksionaliteit van 'n databasis, webbediener en torrentkliënt kombineer, wat dit uiters kompleks maak in terme van die lasprofiel op alle substelsels : verwerker, geheue, netwerk, berging

Dit gebeur so dat gedesentraliseerde netwerke en blokkettings redelik spesifieke en ongewone sagteware vir gesentraliseerde sagteware-ontwikkelaars is. Daarom wil ek belangrike aspekte van die prestasie en volhoubaarheid van gedesentraliseerde netwerke uitlig, benaderings om dit te meet en knelpunte te vind. Ons sal kyk na verskeie prestasiekwessies wat die spoed van die verskaffing van dienste aan blockchain-gebruikers beperk en let op die kenmerke wat kenmerkend is van hierdie tipe sagteware.

Stadiums van 'n diensversoek deur 'n blockchain-kliënt

Om eerlik te praat oor die kwaliteit van enige min of meer komplekse diens, moet jy nie net gemiddelde waardes in ag neem nie, maar ook maksimum/minimum, mediane, persentiele. Teoreties kan ons praat oor 1000 tps in een of ander blokketting, maar as 900 transaksies met enorme spoed voltooi is, en 100 vir 'n paar sekondes "vasgesit" het, dan is die gemiddelde tyd wat ingesamel word oor alle transaksies nie 'n heeltemal regverdige maatstaf vir 'n kliënt nie. wie ek nie die transaksie binne 'n paar sekondes kon voltooi nie. Tydelike "gate" wat veroorsaak word deur gemiste konsensusrondtes of netwerkverdelings kan 'n diens wat uitstekende prestasie op toetsbanke getoon het, grootliks verwoes.

Om sulke knelpunte te identifiseer, is dit nodig om 'n goeie begrip te hê van die stadiums waarop 'n ware blokketting probleme kan ondervind om gebruikers te bedien. Kom ons beskryf die siklus van lewering en verwerking van 'n transaksie, sowel as die verkryging van 'n nuwe toestand van die blokketting, waaruit die kliënt kan verifieer dat sy transaksie verwerk en verantwoord is.

die transaksie word op die kliënt gevorm
die transaksie word op die kliënt onderteken
die kliënt kies een van die nodusse en stuur sy transaksie daarna
die kliënt teken in op opdaterings van die staatsdatabasis van die nodus en wag vir die resultate van sy transaksie om te verskyn
die nodus versprei die transaksie oor die p2p-netwerk
verskeie of een BP (blok produsent) prosesse opgehoopte transaksies, die opdatering van die staat databasis
BP vorm 'n nuwe blok nadat die vereiste aantal transaksies verwerk is
BP versprei 'n nuwe blok oor die p2p-netwerk
die nuwe blok word afgelewer by die nodus waartoe die kliënt toegang het
node werk staat databasis op
die nodus sien die opdatering rakende die kliënt en stuur vir hom 'n transaksiekennisgewing

Kom ons kyk nou van nader na hierdie stadiums en beskryf die potensiële prestasiekwessies by elke stadium. Anders as gesentraliseerde stelsels, sal ons ook kode-uitvoering op netwerkkliënte oorweeg. Dikwels, wanneer TPS gemeet word, word die transaksieverwerkingstyd van die nodusse afgehaal, en nie van die kliënt nie - dit is nie heeltemal regverdig nie. Die kliënt gee nie om hoe vinnig die nodus sy transaksie verwerk het nie; die belangrikste ding vir hom is die oomblik wanneer betroubare inligting oor hierdie transaksie wat in die blokketting ingesluit is, vir hom beskikbaar word. Dit is hierdie maatstaf wat in wese die transaksie-uitvoeringstyd is. Dit beteken dat verskillende kliënte, selfs wat dieselfde transaksie stuur, heeltemal verskillende tye kan ontvang, wat afhang van die kanaal, vrag en nabyheid van die nodus, ens. Dit is dus absoluut nodig om hierdie tyd op kliënte te meet, aangesien dit die parameter is wat geoptimaliseer moet word.

Voorbereiding van 'n transaksie aan die kliëntkant

Kom ons begin met die eerste twee punte: die transaksie word gevorm en deur die kliënt onderteken. Vreemd genoeg kan dit ook 'n bottelnek van blokkettingprestasie uit die kliënt se oogpunt wees. Dit is ongewoon vir gesentraliseerde dienste, wat alle berekeninge en bedrywighede met data oorneem, en die kliënt berei eenvoudig 'n kort versoek voor wat 'n groot hoeveelheid data of berekeninge kan aanvra, om 'n klaargemaakte resultaat te verkry. In blokkettings word die kliëntkode meer en kragtiger, en die blokkettingkern word al hoe meer liggewig, en massiewe rekenaartake word gewoonlik na die kliëntsagteware oorgedra. In blokkettings is daar kliënte wat een transaksie vir 'n redelike lang tyd kan voorberei (ek praat van verskeie merkle-bewyse, bondige bewyse, drempelhandtekeninge en ander komplekse operasies aan die kliëntkant). 'n Goeie voorbeeld van maklike on-ketting verifikasie en swaar voorbereiding van 'n transaksie op die kliënt is bewys van lidmaatskap in 'n lys gebaseer op Merkle-tree, hier статья.

Moet ook nie vergeet dat die kliëntkode nie net transaksies na die blokketting stuur nie, maar eers navraag doen oor die toestand van die blokketting - en hierdie aktiwiteit kan die opeenhoping van die netwerk en blokkettingnodes beïnvloed. Dus, wanneer metings geneem word, sal dit redelik wees om die gedrag van die kliëntkode so volledig as moontlik na te boots. Selfs al is daar in jou blokketting gewone ligte kliënte wat 'n gereelde digitale handtekening op die eenvoudigste transaksie plaas om een of ander bate oor te dra, is daar elke jaar steeds meer massiewe berekeninge op die kliënt, kripto-algoritmes word sterker, en hierdie deel van die verwerking kan in die toekoms 'n groot bottelnek word. Wees dus versigtig en moenie die situasie mis nie wanneer, in 'n transaksie wat 3.5 s duur, 2.5 s spandeer word aan die voorbereiding en ondertekening van die transaksie, en 1.0 s aan die stuur daarvan na die netwerk en wag vir 'n antwoord. Om die risiko's van hierdie bottelnek te evalueer, moet jy statistieke van kliëntmasjiene insamel, en nie net van blokketting-nodusse nie.

Stuur 'n transaksie en monitor die status daarvan

Die volgende stap is om die transaksie na die geselekteerde blokkettingnodus te stuur en die status van aanvaarding daarvan in die transaksiepoel te ontvang. Hierdie stadium is soortgelyk aan 'n gewone databasistoegang; die nodus moet die transaksie in die poel opneem en inligting daaroor deur die p2p-netwerk begin versprei. Die benadering tot die beoordeling van prestasie hier is soortgelyk aan die beoordeling van die prestasie van tradisionele Web API-mikrodienste, en die transaksies self in blokkettings kan opgedateer word en aktief hul status verander. Oor die algemeen kan die opdatering van transaksie-inligting op sommige blokkettings verskeie kere plaasvind, byvoorbeeld wanneer daar tussen kettingvurke oorgeskakel word of wanneer BP's hul voorneme aankondig om 'n transaksie in 'n blok in te sluit. Beperkings op die grootte van hierdie poel en die aantal transaksies daarin kan die prestasie van die blokketting beïnvloed. As die transaksiepoel tot die maksimum moontlike grootte gevul is, of nie in RAM pas nie, kan netwerkprestasie skerp daal. Blokkettings het geen gesentraliseerde maniere om teen 'n vloed van gemorsboodskappe te beskerm nie, en as die blokketting hoëvolume transaksies en lae fooie ondersteun, kan dit die transaksiepoel laat oorloop - nog 'n potensiële prestasie-bottelnek.

In blokkettings stuur die kliënt 'n transaksie na enige blokkettingnodus waarvan hy hou, die hash van die transaksie is gewoonlik aan die kliënt bekend voordat dit gestuur word, dus al wat hy hoef te doen is om die verbinding te bewerkstellig en, na oordrag, te wag vir die blokketting om te verander sy toestand, wat sy transaksie moontlik maak. Let daarop dat deur "tps" te meet, jy heeltemal verskillende resultate kan kry vir verskillende metodes om aan 'n blokkettingnodus te koppel. Dit kan 'n gewone HTTP RPC of 'n WebSocket wees wat jou toelaat om die "subscribe"-patroon te implementeer. In die tweede geval sal die kliënt vroeër 'n kennisgewing ontvang, en die nodus sal minder hulpbronne (hoofsaaklik geheue en verkeer) spandeer op antwoorde oor die transaksiestatus. Wanneer “tps” dus gemeet word, is dit nodig om die manier waarop kliënte met nodusse koppel, in ag te neem. Daarom, om die risiko's van hierdie bottelnek te evalueer, moet die maatstaf blokketting in staat wees om kliënte na te boots met beide WebSocket en HTTP RPC versoeke, in verhoudings wat ooreenstem met werklike netwerke, sowel as die aard van transaksies en hul grootte verander.

Om die risiko's van hierdie bottelnek te evalueer, moet jy ook statistieke van kliëntmasjiene insamel, en nie net van blokketting-nodusse nie.

Oordrag van transaksies en blokke via p2p-netwerk

In blokkettings word eweknie-netwerk (p2p) gebruik om transaksies en blokke tussen deelnemers oor te dra. Transaksies versprei deur die netwerk, vanaf een van die nodusse, totdat hulle eweknieblokprodusente bereik, wat transaksies in blokke verpak en, met dieselfde p2p, nuwe blokke na alle netwerknodusse versprei. Die basis van die meeste moderne p2p-netwerke is verskeie wysigings van die Kademlia-protokol. Hier 'n goeie opsomming van hierdie protokol, en hier - 'n artikel met verskeie metings in die BitTorrent-netwerk, waaruit 'n mens kan verstaan dat hierdie tipe netwerk meer kompleks en minder voorspelbaar is as 'n streng gekonfigureerde netwerk van 'n gesentraliseerde diens. Ook, hier artikel oor die meting van verskeie interessante statistieke vir Ethereum-nodusse.

Kortom, elke eweknie in sulke netwerke hou sy eie dinamiese lys van ander eweknieë van waar dit blokke inligting aanvra wat deur inhoud aangespreek word. Wanneer 'n eweknie 'n versoek ontvang, gee dit óf die nodige inligting óf stuur die versoek na die volgende pseudo-ewekansige eweknie uit die lys, en nadat hy 'n antwoord ontvang het, gee dit dit deur aan die versoeker en kas dit vir 'n rukkie, wat hierdie blok inligting vroeër die volgende keer. So beland populêre inligting in 'n groot aantal kas van 'n groot aantal eweknieë, en ongewilde inligting word geleidelik vervang. Eweknieë hou rekord van wie hoeveel inligting aan wie oorgedra het, en die netwerk probeer aktiewe verspreiders stimuleer deur hul graderings te verhoog en hulle van 'n hoër vlak van diens te voorsien, wat outomaties onaktiewe deelnemers van eweknielyste verplaas.

Dus, die transaksie moet nou deur die netwerk versprei word sodat blokprodusente dit kan sien en dit by die blok kan insluit. Die nodus "verdeel" aktief 'n nuwe transaksie aan almal en luister na die netwerk, en wag vir 'n blok in die indeks waarvan die vereiste transaksie sal verskyn om die wagtende kliënt in kennis te stel. Die tyd wat dit neem vir die netwerk om inligting aan mekaar oor te dra oor nuwe transaksies en blokke in p2p-netwerke hang af van 'n baie groot aantal faktore: die aantal eerlike nodusse wat naby werk (vanuit 'n netwerk oogpunt), die "warm- up" van die kas van hierdie nodusse, die grootte van blokke, transaksies, die aard van veranderinge, netwerkgeografie, aantal nodusse en baie ander faktore. Komplekse metings van prestasiemaatstawwe in sulke netwerke is 'n komplekse aangeleentheid; dit is nodig om die versoekverwerkingstyd op beide kliënte en eweknieë (blockchain-nodusse) gelyktydig te evalueer. Probleme in enige van die p2p-meganismes, verkeerde data-uitsetting en -kas, ondoeltreffende bestuur van lyste van aktiewe eweknieë, en baie ander faktore kan vertragings veroorsaak wat die doeltreffendheid van die hele netwerk as geheel beïnvloed, en hierdie knelpunt is die moeilikste om te ontleed , toets en interpretasie van resultate.

Blockchain-verwerking en staatsdatabasisopdatering

Die belangrikste deel van die blokketting is die konsensusalgoritme, die toepassing daarvan op nuwe blokke wat van die netwerk ontvang word en die verwerking van transaksies met die aantekening van die resultate in die staatsdatabasis. Om 'n nuwe blok by die ketting te voeg en dan die hoofketting te kies, behoort so vinnig as moontlik te werk. In die werklike lewe beteken "behoort" egter nie "werk" nie, en 'n mens kan jou byvoorbeeld 'n situasie voorstel waar twee lang mededingende kettings voortdurend tussen mekaar wissel, wat die metadata van duisende transaksies in die poel by elke skakelaar verander , en voortdurend die staatsdatabasis terugrol. Hierdie stadium, in terme van die definisie van die bottelnek, is eenvoudiger as die p2p-netwerklaag, want transaksie uitvoering en konsensus algoritme is streng deterministies, en dit is makliker om enigiets hier te meet.
Die belangrikste ding is om nie ewekansige agteruitgang in die prestasie van hierdie stadium met netwerkprobleme te verwar nie - nodusse is stadiger om blokke en inligting oor die hoofketting te lewer, en vir 'n eksterne kliënt kan dit soos 'n stadige netwerk lyk, hoewel die probleem in 'n heeltemal ander plek.

Om prestasie op hierdie stadium te optimaliseer, is dit nuttig om statistieke van die nodusse self in te samel en te monitor, en dit in te sluit wat verband hou met die opdatering van die staat-databasis: die aantal blokke wat op die nodus verwerk word, hul grootte, die aantal transaksies, die aantal skakelaars tussen kettingvurke, die aantal ongeldige blokke, virtuele masjien se werkingstyd, datatoewysingstyd, ens. Dit sal voorkom dat netwerkprobleme met foute in kettingverwerkingsalgoritmes verwar word.

'n Virtuele masjien wat transaksies verwerk, kan 'n nuttige bron van inligting wees wat die werking van die blokketting kan optimaliseer. Die aantal geheue-toekennings, die aantal lees/skryf-instruksies en ander maatstawwe wat verband hou met die doeltreffendheid van kontrakkode uitvoering kan baie nuttige inligting aan ontwikkelaars verskaf. Terselfdertyd is slim kontrakte programme, wat beteken dat hulle in teorie enige van die hulpbronne kan verbruik: cpu/geheue/netwerk/berging, so transaksieverwerking is 'n taamlik onsekere stadium, wat boonop baie verander wanneer tussen weergawes beweeg word en wanneer kontrakkodes verander word. Daarom is maatstawwe wat verband hou met transaksieverwerking ook nodig om blokkettingprestasie effektief te optimaliseer.

Ontvangs deur die kliënt van 'n kennisgewing oor die insluiting van 'n transaksie in die blokketting

Dit is die finale stadium van die blokkettingkliënt wat die diens ontvang; in vergelyking met ander stadiums is daar geen groot oorhoofse koste nie, maar dit is steeds die moeite werd om die moontlikheid te oorweeg dat die kliënt 'n lywige reaksie van die nodus sal ontvang (byvoorbeeld 'n slim kontrak 'n verskeidenheid data terugstuur). In elk geval, hierdie punt is die belangrikste vir die een wat die vraag gevra het "hoeveel tps is in jou blokketting?", want Op hierdie oomblik word die tyd van ontvangs van die diens aangeteken.

Op hierdie plek is daar altyd 'n versending van die voltyd wat die kliënt moes spandeer om te wag vir 'n antwoord van die blokketting; dit is hierdie keer dat die gebruiker sal wag vir bevestiging in sy aansoek, en dit is die optimalisering daarvan wat die hooftaak van die ontwikkelaars.

Gevolgtrekking

As gevolg hiervan kan ons die tipe bewerkings wat op blokkettings uitgevoer word beskryf en dit in verskeie kategorieë verdeel:

kriptografiese transformasies, bewyskonstruksie
eweknie-netwerk, transaksie- en blokreplikasie
transaksieverwerking, uitvoering van slim kontrakte
die toepassing van veranderinge in die blokketting op die staatsdatabasis, die opdatering van data oor transaksies en blokke
leesalleen-versoeke na staatsdatabasis, blockchain node API, intekeningdienste

Oor die algemeen is die tegniese vereistes vir moderne blokketting-nodusse uiters ernstig - vinnige SVE's vir kriptografie, 'n groot hoeveelheid RAM om die staatsdatabasis te stoor en vinnig toegang te verkry, netwerkinteraksie met 'n groot aantal gelyktydig oop verbindings en groot berging. Sulke hoë vereistes en die oorvloed van verskillende tipes bedrywighede lei onvermydelik daartoe dat nodusse dalk nie genoeg hulpbronne het nie, en dan kan enige van die stadiums wat hierbo bespreek is nog 'n knelpunt vir die algehele netwerkprestasie word.

Wanneer u die prestasie van blokkettings ontwerp en evalueer, sal u al hierdie punte in ag moet neem. Om dit te doen, moet jy gelyktydig metrieke van kliënte en netwerknodusse insamel en ontleed, kyk vir korrelasies tussen hulle, skat die tyd wat dit neem om dienste aan kliënte te verskaf, neem al die hoofbronne in ag: cpu/geheue/netwerk/berging , verstaan hoe hulle gebruik word en beïnvloed mekaar. Dit alles maak die vergelyking van die snelhede van verskillende blokkettings in die vorm van "hoeveel TPS" 'n uiters ondankbare taak, aangesien daar 'n groot aantal verskillende konfigurasies en toestande is. In groot gesentraliseerde stelsels, groepe van honderde bedieners, is hierdie probleme ook kompleks en vereis ook die versameling van 'n groot aantal verskillende metrieke, maar in blokkettings, as gevolg van p2p-netwerke, virtuele masjiene wat kontrakte verwerk, interne ekonomieë, die aantal grade van vryheid is baie groter, wat die toets selfs op verskeie bedieners maak, dit is nie-aanwysend en toon slegs uiters benaderde waardes wat amper geen verband met die werklikheid het nie.

Daarom, wanneer ons in die blokkettingkern ontwikkel, om prestasie te evalueer en die vraag te beantwoord "het dit verbeter in vergelyking met die vorige keer?" Ons gebruik redelik komplekse sagteware wat die bekendstelling van 'n blokketting met dosyne nodusse orkestreer en outomaties 'n maatstaf bekendstel en statistieke insamel. ; Sonder hierdie inligting is dit uiters moeilik om protokolle te ontfout wat met veelvuldige deelnemers werk.

Dus, wanneer jy die vraag ontvang "hoeveel TPS is in jou blokketting?", bied jou gespreksgenoot 'n bietjie tee aan en vra of hy gereed is om na 'n dosyn grafieke te kyk en ook na al drie blokkies blokkettingprestasieprobleme te luister en jou voorstelle vir los hulle op...

Bron: will.com

Hoeveel TPS is op jou blockchain?