Hoff gwestiwn am unrhyw system ddosbarthedig gan berson annhechnegol yw “Sawl tps sydd ar eich blockchain?” Fodd bynnag, fel arfer nid oes gan y nifer a roddir mewn ymateb lawer yn gyffredin â'r hyn yr hoffai'r holwr ei glywed. Mewn gwirionedd, roedd am ofyn "a fydd eich blockchain yn cyd-fynd â fy ngofynion busnes," ac nid yw'r gofynion hyn yn un rhif, ond mae llawer o amodau - dyma oddefgarwch namau rhwydwaith, gofynion terfynoldeb, maint, natur trafodion a llawer o baramedrau eraill. Felly mae'r ateb i'r cwestiwn "faint tps" yn annhebygol o fod yn syml, a bron byth yn gyflawn. Gall system ddosbarthedig gyda degau neu gannoedd o nodau sy'n perfformio cyfrifiadau eithaf cymhleth fod mewn nifer enfawr o wahanol wladwriaethau sy'n gysylltiedig â chyflwr y rhwydwaith, cynnwys y blockchain, methiannau technegol, problemau economaidd, ymosodiadau ar y rhwydwaith a llawer o resymau eraill . Mae'r camau y mae problemau perfformiad yn bosibl yn wahanol i wasanaethau traddodiadol, ac mae gweinydd rhwydwaith blockchain yn wasanaeth rhwydwaith sy'n cyfuno ymarferoldeb cronfa ddata, gweinydd gwe a chleient torrent, sy'n ei gwneud yn hynod gymhleth o ran y proffil llwyth ar bob is-system. : prosesydd, cof, rhwydwaith, storfa

Mae'n digwydd felly bod rhwydweithiau datganoledig a blockchains yn feddalwedd eithaf penodol ac anarferol ar gyfer datblygwyr meddalwedd canolog. Felly, hoffwn dynnu sylw at agweddau pwysig ar berfformiad a chynaliadwyedd rhwydweithiau datganoledig, dulliau o’u mesur a dod o hyd i dagfeydd. Byddwn yn edrych ar faterion perfformiad amrywiol sy'n cyfyngu ar gyflymder darparu gwasanaethau i ddefnyddwyr blockchain ac yn nodi'r nodweddion sy'n nodweddiadol o'r math hwn o feddalwedd.

Camau cais am wasanaeth gan gleient blockchain

Er mwyn siarad yn onest am ansawdd unrhyw wasanaeth mwy neu lai cymhleth, mae angen i chi ystyried nid yn unig gwerthoedd cyfartalog, ond hefyd uchafswm/lleiafswm, canolrifau, canraddau. Yn ddamcaniaethol, gallwn siarad am 1000 tps mewn rhai blockchain, ond pe bai 900 o drafodion wedi'u cwblhau gyda chyflymder enfawr, a 100 yn "sownd" am ychydig eiliadau, yna nid yw'r amser cyfartalog a gesglir dros yr holl drafodion yn fetrig hollol deg i gleient. pwy na allwn i gwblhau'r trafodiad mewn ychydig eiliadau. Gall “tyllau” dros dro a achosir gan rowndiau consensws a fethwyd neu holltiadau rhwydwaith ddifetha gwasanaeth sydd wedi dangos perfformiad rhagorol ar feinciau prawf yn fawr.

Er mwyn nodi tagfeydd o'r fath, mae angen dealltwriaeth dda o'r camau y gall blockchain go iawn ei chael yn anodd gwasanaethu defnyddwyr. Gadewch i ni ddisgrifio'r cylch o gyflwyno a phrosesu trafodiad, yn ogystal â chael cyflwr newydd o'r blockchain, y gall y cleient wirio bod ei drafodiad wedi'i brosesu a'i gyfrif amdano.

y trafodiad yn cael ei ffurfio ar y cleient
mae'r trafodiad wedi'i lofnodi ar y cleient
mae'r cleient yn dewis un o'r nodau ac yn anfon ei drafodiad ato
mae'r cleient yn tanysgrifio i ddiweddariadau i gronfa ddata cyflwr y nod, gan aros i ganlyniadau ei drafodiad ymddangos
mae'r nod yn dosbarthu'r trafodiad dros y rhwydwaith p2p
Mae sawl neu un BP (cynhyrchydd bloc) yn prosesu trafodion cronedig, gan ddiweddaru cronfa ddata'r wladwriaeth
Mae BP yn ffurfio bloc newydd ar ôl prosesu'r nifer gofynnol o drafodion
Mae BP yn dosbarthu bloc newydd dros y rhwydwaith p2p
mae'r bloc newydd yn cael ei ddanfon i'r nod y mae'r cleient yn ei gyrchu
nod yn diweddaru cronfa ddata'r wladwriaeth
mae'r nod yn gweld y diweddariad ynghylch y cleient ac yn anfon hysbysiad trafodiad ato

Nawr, gadewch i ni edrych yn agosach ar y camau hyn a disgrifio'r problemau perfformiad posibl ar bob cam. Yn wahanol i systemau canolog, byddwn hefyd yn ystyried gweithredu cod ar gleientiaid rhwydwaith. Yn aml iawn, wrth fesur TPS, cesglir yr amser prosesu trafodion o'r nodau, ac nid gan y cleient - nid yw hyn yn gwbl deg. Nid yw'r cleient yn poeni pa mor gyflym y prosesodd y nod ei drafodiad; y peth pwysicaf iddo yw'r foment pan fydd gwybodaeth ddibynadwy am y trafodiad hwn sydd wedi'i gynnwys yn y blockchain ar gael iddo. Y metrig hwn yn y bôn yw'r amser cyflawni trafodion. Mae hyn yn golygu y gall gwahanol gleientiaid, hyd yn oed anfon yr un trafodiad, dderbyn amseroedd hollol wahanol, sy'n dibynnu ar sianel, llwyth ac agosrwydd y nod, ac ati. Felly mae'n gwbl angenrheidiol mesur yr amser hwn ar gleientiaid, gan mai dyma'r paramedr y mae angen ei optimeiddio.

Paratoi trafodiad ar ochr y cleient

Gadewch i ni ddechrau gyda'r ddau bwynt cyntaf: mae'r trafodiad yn cael ei ffurfio a'i lofnodi gan y cleient. Yn rhyfedd ddigon, gall hyn hefyd fod yn dagfa o berfformiad blockchain o safbwynt y cleient. Mae hyn yn anarferol ar gyfer gwasanaethau canolog, sy'n cymryd drosodd yr holl gyfrifiadau a gweithrediadau gyda data, ac mae'r cleient yn syml yn paratoi cais byr a all ofyn am lawer iawn o ddata neu gyfrifiadau, gan gael canlyniad parod. Mewn blockchains, mae cod y cleient yn dod yn fwy a mwy pwerus, ac mae'r craidd blockchain yn dod yn fwy a mwy ysgafn, ac mae tasgau cyfrifiadurol enfawr fel arfer yn cael eu trosglwyddo i feddalwedd y cleient. Mewn blockchains, mae yna gleientiaid sy'n gallu paratoi un trafodiad am amser eithaf hir (rwy'n siarad am wahanol broflenni merkle, proflenni cryno, llofnodion trothwy a gweithrediadau cymhleth eraill ar ochr y cleient). Enghraifft dda o ddilysu ar-gadwyn hawdd a pharatoi'n drwm ar drafodiad ar y cleient yw prawf o aelodaeth mewn rhestr yn seiliedig ar Merkle-tree, yma erthygl.

Hefyd, peidiwch ag anghofio nad yw cod y cleient yn anfon trafodion i'r blockchain yn unig, ond yn gyntaf yn holi am gyflwr y blockchain - a gall y gweithgaredd hwn effeithio ar dagfeydd y rhwydwaith a nodau blockchain. Felly, wrth gymryd mesuriadau, byddai'n rhesymol efelychu ymddygiad y cod cleient mor llwyr â phosibl. Hyd yn oed os yn eich blockchain mae cleientiaid ysgafn cyffredin sy'n rhoi llofnod digidol rheolaidd ar y trafodiad symlaf i drosglwyddo rhywfaint o ased, bob blwyddyn mae cyfrifiadau mwy enfawr ar y cleient o hyd, mae algorithmau crypto yn cryfhau, a gall y rhan hon o'r prosesu troi yn dagfa sylweddol yn y dyfodol. Felly, byddwch yn ofalus a pheidiwch â cholli'r sefyllfa pan fydd 3.5s, mewn trafodiad sy'n para 2.5s, yn cael ei wario ar baratoi a llofnodi'r trafodiad, ac 1.0s ar ei anfon i'r rhwydwaith ac aros am ymateb. Er mwyn asesu risgiau'r dagfa hon, mae angen i chi gasglu metrigau o beiriannau cleientiaid, ac nid o nodau cadwyni yn unig.

Anfon trafodiad a monitro ei statws

Y cam nesaf yw anfon y trafodiad i'r nod blockchain a ddewiswyd a derbyn statws ei dderbyn i'r gronfa trafodion. Mae'r cam hwn yn debyg i fynediad cronfa ddata rheolaidd; rhaid i'r nod gofnodi'r trafodiad yn y gronfa a dechrau dosbarthu gwybodaeth amdano trwy'r rhwydwaith p2p. Mae'r dull o asesu perfformiad yma yn debyg i asesu perfformiad microwasanaethau API Gwe traddodiadol, a gellir diweddaru'r trafodion eu hunain mewn blockchains a mynd ati i newid eu statws. Yn gyffredinol, gall diweddaru gwybodaeth trafodion ar rai cadwyni bloc ddigwydd sawl gwaith, er enghraifft wrth newid rhwng ffyrc cadwyn neu pan fydd BPs yn cyhoeddi eu bwriad i gynnwys trafodiad mewn bloc. Gall cyfyngiadau ar faint y pwll hwn a nifer y trafodion ynddo effeithio ar berfformiad y blockchain. Os yw'r gronfa trafodion wedi'i llenwi i'r maint mwyaf posibl, neu os nad yw'n ffitio mewn RAM, gall perfformiad rhwydwaith ostwng yn sydyn. Nid oes gan Blockchains unrhyw ddulliau canolog o amddiffyn rhag llifogydd o negeseuon sothach, ac os yw'r blockchain yn cefnogi trafodion cyfaint uchel a ffioedd isel, gall hyn achosi i'r gronfa trafodion orlifo - tagfa perfformiad bosibl arall.

Mewn blockchains, mae'r cleient yn anfon trafodiad i unrhyw nod blockchain y mae'n ei hoffi, mae hash y trafodiad fel arfer yn hysbys i'r cleient cyn ei anfon, felly y cyfan sydd angen iddo ei wneud yw cyflawni'r cysylltiad ac, ar ôl ei drosglwyddo, aros i'r blockchain newid ei gyflwr, gan alluogi ei drafodiad. Sylwch, trwy fesur “tps” gallwch gael canlyniadau hollol wahanol ar gyfer gwahanol ddulliau o gysylltu â nod blockchain. Gall hwn fod yn HTTP RPC rheolaidd neu WebSocket sy'n eich galluogi i weithredu'r patrwm “tanysgrifio”. Yn yr ail achos, bydd y cleient yn derbyn hysbysiad yn gynharach, a bydd y nod yn gwario llai o adnoddau (cof a thraffig yn bennaf) ar ymatebion am statws y trafodiad. Felly wrth fesur “tps” mae angen ystyried y ffordd y mae cleientiaid yn cysylltu â nodau. Felly, i asesu risgiau'r dagfa hon, rhaid i'r blockchain meincnod allu efelychu cleientiaid â cheisiadau WebSocket a HTTP RPC, mewn cyfrannau sy'n cyfateb i rwydweithiau go iawn, yn ogystal â newid natur trafodion a'u maint.

Er mwyn asesu risgiau'r dagfa hon, mae angen i chi hefyd gasglu metrigau o beiriannau cleientiaid, ac nid o nodau cadwyni yn unig.

Trosglwyddo trafodion a blociau trwy rwydwaith p2p

Mewn blockchains, defnyddir rhwydweithio cyfoedion-i-cyfoedion (p2p) i drosglwyddo trafodion a blociau rhwng cyfranogwyr. Mae trafodion yn lledaenu ledled y rhwydwaith, gan ddechrau o un o'r nodau, nes iddynt gyrraedd cynhyrchwyr blociau cyfoedion, sy'n pacio trafodion yn flociau a, gan ddefnyddio'r un p2p, yn dosbarthu blociau newydd i bob nod rhwydwaith. Sail y rhan fwyaf o rwydweithiau p2p modern yw amrywiol addasiadau i brotocol Kademlia. Yma crynodeb da o'r protocol hwn, a yma - erthygl gyda mesuriadau amrywiol yn y rhwydwaith BitTorrent, y gallwch chi ddeall bod y math hwn o rwydwaith yn fwy cymhleth ac yn llai rhagweladwy na rhwydwaith wedi'i ffurfweddu'n anhyblyg o wasanaeth canolog. Hefyd, yma erthygl am fesur amrywiol fetrigau diddorol ar gyfer nodau Ethereum.

Yn fyr, mae pob cymar mewn rhwydweithiau o'r fath yn cynnal ei restr ddeinamig ei hun o gymheiriaid eraill y mae'n gofyn am flociau o wybodaeth y mae cynnwys yn mynd i'r afael â nhw. Pan fydd cyfoed yn derbyn cais, mae naill ai'n rhoi'r wybodaeth angenrheidiol neu'n trosglwyddo'r cais i'r cyfoed ffug-hap nesaf o'r rhestr, ac ar ôl cael ymateb, mae'n ei drosglwyddo i'r ceisydd ac yn ei storio am ychydig, gan roi hyn bloc o wybodaeth yn gynharach y tro nesaf. Felly, mae gwybodaeth boblogaidd yn dod i ben mewn nifer fawr o caches o nifer fawr o gyfoedion, ac mae gwybodaeth amhoblogaidd yn cael ei disodli'n raddol. Mae cyfoedion yn cadw cofnodion o bwy sydd wedi trosglwyddo faint o wybodaeth i bwy, ac mae'r rhwydwaith yn ceisio ysgogi dosbarthwyr gweithredol trwy gynyddu eu graddfeydd a darparu lefel uwch o wasanaeth iddynt, gan ddisodli cyfranogwyr anweithgar yn awtomatig o restrau cyfoedion.

Felly, mae angen dosbarthu'r trafodiad yn awr ledled y rhwydwaith fel y gall bloc-gynhyrchwyr ei weld a'i gynnwys yn y bloc. Mae'r nod yn “dosbarthu” trafodiad newydd i bawb ac yn gwrando ar y rhwydwaith, gan aros am floc yn y mynegai y bydd y trafodiad gofynnol yn ymddangos ohono er mwyn hysbysu'r cleient sy'n aros. Mae'r amser y mae'n ei gymryd i'r rhwydwaith drosglwyddo gwybodaeth am drafodion a blociau newydd i'w gilydd mewn rhwydweithiau p2p yn dibynnu ar nifer fawr iawn o ffactorau: nifer y nodau gonest sy'n gweithio gerllaw (o safbwynt rhwydwaith), y “cynnes- i fyny” o caches y nodau hyn, maint y blociau, trafodion, natur y newidiadau , daearyddiaeth rhwydwaith, nifer y nodau a llawer o ffactorau eraill. Mae mesuriadau cymhleth o fetrigau perfformiad mewn rhwydweithiau o'r fath yn fater cymhleth; mae angen gwerthuso'r amser prosesu ceisiadau ar yr un pryd ar gyfer cleientiaid a chyfoedion (nodau blockchain). Gall problemau mewn unrhyw un o'r mecanweithiau p2p, dadfeddiannu data anghywir a caching, rheolaeth aneffeithiol o restrau o gyfoedion gweithredol, a llawer o ffactorau eraill achosi oedi sy'n effeithio ar effeithlonrwydd y rhwydwaith cyfan yn ei gyfanrwydd, a'r dagfa hon yw'r anoddaf i'w dadansoddi , profi a dehongli canlyniadau.

Prosesu Blockchain a diweddaru cronfa ddata'r wladwriaeth

Y rhan bwysicaf o'r blockchain yw'r algorithm consensws, ei gymhwysiad i flociau newydd a dderbynnir gan y rhwydwaith a phrosesu trafodion gyda chofnodi canlyniadau yng nghronfa ddata'r wladwriaeth. Dylai ychwanegu bloc newydd at y gadwyn ac yna dewis y brif gadwyn weithio cyn gynted â phosibl. Fodd bynnag, mewn bywyd go iawn, nid yw “dylai” yn golygu “gweithio”, a gall rhywun, er enghraifft, ddychmygu sefyllfa lle mae dwy gadwyn hir sy'n cystadlu yn gyson yn newid rhyngddynt eu hunain, gan newid metadata miloedd o drafodion yn y pwll wrth bob switsh. , a dychwelyd cronfa ddata'r wladwriaeth yn gyson. Mae'r cam hwn, o ran diffinio'r dagfa, yn symlach na'r haen rhwydwaith p2p, oherwydd mae gweithredu trafodion ac algorithm consensws yn hollol benderfyniaethol, ac mae'n haws mesur unrhyw beth yma.
Y prif beth yw peidio â drysu diraddio ar hap ym mherfformiad y cam hwn gyda phroblemau rhwydwaith - mae nodau'n arafach wrth gyflwyno blociau a gwybodaeth am y brif gadwyn, ac i gleient allanol gall hyn edrych fel rhwydwaith araf, er bod y broblem yn gorwedd mewn lle hollol wahanol.

Er mwyn optimeiddio perfformiad ar hyn o bryd, mae'n ddefnyddiol casglu a monitro metrigau o'r nodau eu hunain, a chynnwys ynddynt y rhai sy'n ymwneud â diweddaru cronfa ddata'r wladwriaeth: nifer y blociau a brosesir ar y nod, eu maint, nifer y trafodion, nifer y switshis rhwng ffyrch cadwyn, nifer y blociau annilys, amser gweithredu peiriannau rhithwir, amser ymrwymo data, ac ati. Bydd hyn yn atal problemau rhwydwaith rhag cael eu drysu â gwallau mewn algorithmau prosesu cadwyn.

Gall peiriant rhithwir prosesu trafodion fod yn ffynhonnell wybodaeth ddefnyddiol a all wneud y gorau o weithrediad y blockchain. Gall nifer y dyraniadau cof, nifer y cyfarwyddiadau darllen / ysgrifennu, a metrigau eraill sy'n ymwneud ag effeithlonrwydd gweithredu cod contract ddarparu llawer o wybodaeth ddefnyddiol i ddatblygwyr. Ar yr un pryd, mae contractau smart yn rhaglenni, sy'n golygu mewn theori y gallant ddefnyddio unrhyw un o'r adnoddau: cpu / cof / rhwydwaith / storio, felly mae prosesu trafodion yn gam eithaf ansicr, sydd, yn ogystal, yn newid yn fawr wrth symud rhwng fersiynau ac wrth newid codau contract. Felly, mae angen metrigau sy'n ymwneud â phrosesu trafodion hefyd i wneud y gorau o berfformiad blockchain yn effeithiol.

Derbyniad gan y cleient o hysbysiad am gynnwys trafodiad yn y blockchain

Dyma gam olaf y cleient blockchain sy'n derbyn y gwasanaeth; o'i gymharu â chamau eraill, nid oes unrhyw gostau gorbenion mawr, ond mae'n dal yn werth ystyried y posibilrwydd y bydd y cleient yn derbyn ymateb swmpus o'r nod (er enghraifft, contract smart dychwelyd amrywiaeth o ddata). Beth bynnag, y pwynt hwn yw'r pwysicaf i'r un a ofynnodd y cwestiwn "sawl tps sydd yn eich blockchain?", oherwydd Ar hyn o bryd, mae amser derbyn y gwasanaeth yn cael ei gofnodi.

Yn y lle hwn, mae anfon yr amser llawn y bu'n rhaid i'r cleient ei dreulio yn aros am ymateb gan y blockchain bob amser; yr amser hwn y bydd y defnyddiwr yn aros am gadarnhad yn ei gais, a'i optimeiddio yw'r prif dasg y datblygwyr.

Casgliad

O ganlyniad, gallwn ddisgrifio'r mathau o weithrediadau a gyflawnir ar blockchain a'u rhannu'n sawl categori:

trawsnewidiadau cryptograffig, adeiladu prawf
rhwydweithio cyfoedion-i-cyfoedion, trafodion a dyblygu bloc
prosesu trafodion, gweithredu contractau smart
cymhwyso newidiadau yn y blockchain i gronfa ddata'r wladwriaeth, diweddaru data ar drafodion a blociau
ceisiadau darllen yn unig i nodi cronfa ddata, API nod blockchain, gwasanaethau tanysgrifio

Yn gyffredinol, mae'r gofynion technegol ar gyfer nodau blockchain modern yn hynod ddifrifol - CPUs cyflym ar gyfer cryptograffeg, llawer iawn o RAM i storio a chael mynediad cyflym i gronfa ddata'r wladwriaeth, rhyngweithio rhwydwaith gan ddefnyddio nifer fawr o gysylltiadau agored ar yr un pryd, a storfa fawr. Mae gofynion mor uchel a digonedd o wahanol fathau o weithrediadau yn anochel yn arwain at y ffaith nad oes gan nodau ddigon o adnoddau, ac yna gall unrhyw un o'r camau a drafodir uchod ddod yn dagfa arall ar gyfer perfformiad cyffredinol y rhwydwaith.

Wrth ddylunio a gwerthuso perfformiad cadwyni bloc, bydd yn rhaid i chi ystyried yr holl bwyntiau hyn. I wneud hyn, mae angen i chi gasglu a dadansoddi metrigau ar yr un pryd gan gleientiaid a nodau rhwydwaith, chwilio am gydberthynas rhyngddynt, amcangyfrif yr amser y mae'n ei gymryd i ddarparu gwasanaethau i gleientiaid, ystyried yr holl brif adnoddau: cpu / cof / rhwydwaith / storio , deall sut y cânt eu defnyddio a dylanwadu ar ei gilydd. Mae hyn i gyd yn ei gwneud yn dasg hynod ddiddiolch i gymharu cyflymderau gwahanol gadwyni bloc ar ffurf “faint o TPS”, gan fod yna nifer fawr o wahanol gyfluniadau a gwladwriaethau. Mewn systemau canolog mawr, clystyrau o gannoedd o weinyddion, mae'r problemau hyn hefyd yn gymhleth ac mae angen casglu nifer fawr o wahanol fetrigau hefyd, ond mewn cadwyni bloc, oherwydd rhwydweithiau p2p, contractau prosesu peiriannau rhithwir, economïau mewnol, nifer y graddau o ryddid yn llawer mwy, sy'n gwneud y prawf hyd yn oed ar nifer o weinyddion, mae'n anarwyddol ac yn dangos dim ond gwerthoedd bras iawn nad oes ganddynt bron unrhyw gysylltiad â realiti.

Felly, wrth ddatblygu yn y craidd blockchain, i werthuso perfformiad ac ateb y cwestiwn “a yw wedi gwella o gymharu â'r tro diwethaf?” rydym yn defnyddio meddalwedd eithaf cymhleth sy'n trefnu lansiad blockchain gyda dwsinau o nodau ac yn lansio meincnod yn awtomatig ac yn casglu metrigau heb y wybodaeth hon mae'n anodd iawn dadfygio protocolau sy'n gweithio gyda chyfranogwyr lluosog.

Felly, pan fyddwch chi'n derbyn y cwestiwn “faint o TPS sydd yn eich blockchain?”, cynigiwch de i'ch interlocutor a gofynnwch a yw'n barod i edrych ar ddwsin o graffiau a hefyd gwrando ar bob un o'r tri blwch o broblemau perfformiad blockchain a'ch awgrymiadau ar gyfer eu datrys...

Ffynhonnell: hab.com

Faint o TPS sydd ar eich blockchain?