Ոչ տեխնիկական անձի կողմից ցանկացած բաշխված համակարգի մասին սիրված հարցը հետևյալն է. «Քանի՞ tps կա ձեր բլոկչեյնում»: Այնուամենայնիվ, ի պատասխան տրված թիվը սովորաբար քիչ ընդհանրություն ունի այն ամենի հետ, ինչ կցանկանար լսել հարց տվողը: Իրականում, նա ուզում էր հարցնել՝ «արդյո՞ք ձեր բլոկչեյնը կհամապատասխանի իմ բիզնեսի պահանջներին», և այդ պահանջները մեկ թիվ չեն, այլ բազմաթիվ պայմաններ. ահա ցանցի սխալների հանդուրժողականությունը, վերջնականության պահանջները, չափերը, գործարքների բնույթը և շատ այլ պարամետրեր: Այսպիսով, «քանի tps» հարցի պատասխանը դժվար թե պարզ լինի և գրեթե երբեք ամբողջական: Տասնյակ կամ հարյուրավոր հանգույցներով բաշխված համակարգը, որը բավականին բարդ հաշվարկներ է կատարում, կարող է լինել հսկայական թվով տարբեր վիճակներում՝ կապված ցանցի վիճակի, բլոկչեյնի բովանդակության, տեխնիկական խափանումների, տնտեսական խնդիրների, ցանցի վրա հարձակումների և բազմաթիվ այլ պատճառների հետ։ . Այն փուլերը, որոնցում հնարավոր են կատարողականի խնդիրները, տարբերվում են ավանդական ծառայություններից, և բլոկչեյն ցանցային սերվերը ցանցային ծառայություն է, որը համատեղում է տվյալների բազայի, վեբ սերվերի և հեղեղի հաճախորդի գործառույթները, ինչը այն չափազանց բարդ է դարձնում բոլոր ենթահամակարգերի բեռնվածության պրոֆիլի առումով: : պրոցեսոր, հիշողություն, ցանց, պահեստ
Պատահում է, որ ապակենտրոնացված ցանցերը և բլոկչեյնները բավականին հատուկ և անսովոր ծրագրեր են կենտրոնացված ծրագրային ապահովման մշակողների համար: Ուստի ես կցանկանայի ընդգծել ապակենտրոնացված ցանցերի գործունեության և կայունության կարևոր ասպեկտները, դրանք չափելու և խոչընդոտներ գտնելու մոտեցումները: Մենք կանդրադառնանք տարբեր կատարողական խնդիրներին, որոնք սահմանափակում են բլոկչեյն օգտագործողներին ծառայությունների մատուցման արագությունը և կնշենք այս տեսակի ծրագրակազմին բնորոշ առանձնահատկությունները:
Բլոկչեյն հաճախորդի կողմից ծառայության պահանջի փուլերը
Ցանկացած քիչ թե շատ բարդ ծառայության որակի մասին անկեղծ խոսելու համար պետք է հաշվի առնել ոչ միայն միջին արժեքները, այլև առավելագույն/նվազագույնը, մեդիանները, տոկոսները։ Տեսականորեն, մենք կարող ենք խոսել 1000 tps-ի մասին որոշ բլոկչեյնում, բայց եթե 900 գործարքներ կատարվել են հսկայական արագությամբ, և 100-ը «կցվել» են մի քանի վայրկյանով, ապա բոլոր գործարքների վրա հավաքված միջին ժամանակը լիովին արդար չափիչ չէ հաճախորդի համար: ով ես չկարողացա մի քանի վայրկյանում ավարտել գործարքը: Ժամանակավոր «անցքերը», որոնք առաջանում են բաց թողնված կոնսենսուսի ռաունդների կամ ցանցի պառակտումների հետևանքով, կարող են մեծապես փչացնել ծառայությունը, որը գերազանց կատարում է ցուցադրել փորձարկման նստարաններում:
Նման խոչընդոտները բացահայտելու համար անհրաժեշտ է լավ պատկերացում կազմել այն փուլերի մասին, որոնց դեպքում իրական բլոկչեյնը կարող է դժվարություններ ունենալ օգտատերերին սպասարկելու համար: Եկեք նկարագրենք գործարքի առաքման և մշակման ցիկլը, ինչպես նաև բլոկչեյնի նոր վիճակի ստացումը, որից հաճախորդը կարող է ստուգել, որ իր գործարքը մշակվել և հաշվառվել է:
- գործարքը ձևավորվում է հաճախորդի վրա
- գործարքը կնքվում է հաճախորդի վրա
- հաճախորդը ընտրում է հանգույցներից մեկը և իր գործարքն ուղարկում դրան
- հաճախորդը բաժանորդագրվում է հանգույցի պետական տվյալների բազայի թարմացումներին՝ սպասելով իր գործարքի արդյունքների հայտնվելուն
- հանգույցը գործարքը բաշխում է p2p ցանցի վրա
- մի քանի կամ մեկ BP (բլոկ արտադրող) վերամշակում է կուտակված գործարքները՝ թարմացնելով պետական տվյալների բազան
- BP-ն նոր բլոկ է կազմում անհրաժեշտ թվով գործարքների մշակումից հետո
- BP-ն նոր բլոկ է տարածում p2p ցանցի վրա
- նոր բլոկը առաքվում է այն հանգույցին, որին հաճախորդը մուտք է գործում
- հանգույցը թարմացնում է պետական տվյալների բազան
- հանգույցը տեսնում է հաճախորդի վերաբերյալ թարմացումը և նրան ուղարկում գործարքի մասին ծանուցում
Այժմ եկեք ավելի սերտ նայենք այս փուլերին և նկարագրենք յուրաքանչյուր փուլում կատարման հնարավոր խնդիրները: Ի տարբերություն կենտրոնացված համակարգերի, մենք կդիտարկենք նաև ցանցի հաճախորդների վրա կոդի կատարումը: Շատ հաճախ, TPS-ը չափելիս, գործարքի մշակման ժամանակը հավաքվում է հանգույցներից, և ոչ թե հաճախորդից, սա ամբողջովին արդար չէ: Հաճախորդին չի հետաքրքրում, թե հանգույցը որքան արագ է մշակել իր գործարքը, նրա համար ամենակարևորը այն պահն է, երբ բլոկչեյնում ներառված այս գործարքի մասին վստահելի տեղեկատվությունը դառնում է իր համար։ Հենց այս չափանիշն է, ըստ էության, գործարքի կատարման ժամանակը: Սա նշանակում է, որ տարբեր հաճախորդներ, նույնիսկ ուղարկելով նույն գործարքը, կարող են ստանալ բոլորովին տարբեր ժամանակներ, որոնք կախված են կապուղուց, բեռնվածությունից և հանգույցի մոտիկությունից և այլն: Այսպիսով, բացարձակապես անհրաժեշտ է այս ժամանակը չափել հաճախորդների վրա, քանի որ սա այն պարամետրն է, որը պետք է օպտիմալացվի:
Հաճախորդի կողմից գործարքի պատրաստում
Սկսենք առաջին երկու կետերից՝ գործարքը ձևավորվում և ստորագրվում է հաճախորդի կողմից: Տարօրինակ կերպով, սա հաճախորդի տեսանկյունից կարող է նաև լինել բլոկչեյնի աշխատանքի խոչընդոտ: Սա անսովոր է կենտրոնացված ծառայությունների համար, որոնք ստանձնում են տվյալների հետ կապված բոլոր հաշվարկներն ու գործառնությունները, և հաճախորդը պարզապես պատրաստում է կարճ հարցում, որը կարող է պահանջել մեծ քանակությամբ տվյալներ կամ հաշվարկներ՝ ստանալով պատրաստի արդյունք: Բլոկչեյններում հաճախորդի կոդը դառնում է ավելի ու ավելի հզոր, իսկ բլոկչեյնի միջուկը դառնում է ավելի ու ավելի թեթև, և զանգվածային հաշվողական առաջադրանքները սովորաբար փոխանցվում են հաճախորդի ծրագրակազմին: Բլոկչեյններում կան հաճախորդներ, որոնք կարող են բավականին երկար ժամանակ պատրաստել մեկ գործարք (ես խոսում եմ տարբեր merkle-ապացույցների, հակիրճ ապացույցների, շեմային ստորագրությունների և հաճախորդի կողմից այլ բարդ գործողությունների մասին): Հեշտ շղթայական ստուգման և հաճախորդի վրա գործարքի ծանր պատրաստման լավ օրինակ է Merkle-tree-ի վրա հիմնված ցուցակին անդամակցելու ապացույց, այստեղ .
Նաև մի մոռացեք, որ հաճախորդի կոդը պարզապես գործարքներ չի ուղարկում բլոկչեյն, այլ նախ հարցնում է բլոկչեյնի վիճակը, և այս գործունեությունը կարող է ազդել ցանցի և բլոկչեյն հանգույցների գերբեռնվածության վրա: Այսպիսով, չափումներ կատարելիս խելամիտ կլինի հնարավորինս ամբողջական կերպով ընդօրինակել հաճախորդի կոդի վարքագիծը: Նույնիսկ եթե ձեր բլոկչեյնում կան սովորական թեթև հաճախորդներ, որոնք սովորական թվային ստորագրություն են դնում որոշ ակտիվներ փոխանցելու համար ամենապարզ գործարքի վրա, ամեն տարի հաճախորդի վրա դեռ ավելի զանգվածային հաշվարկներ են կատարվում, կրիպտո ալգորիթմներն ուժեղանում են, և մշակման այս մասը կարող է. ապագայում վերածվել զգալի խոչընդոտի: Ուստի, զգույշ եղեք և բաց մի թողեք այն իրավիճակը, երբ 3.5 վրկ տևողությամբ գործարքում 2.5 վրկ ծախսվում է գործարքը պատրաստելու և ստորագրելու վրա, իսկ 1.0՝ այն ցանց ուղարկելու և պատասխանի սպասելու վրա։ Այս խցանման ռիսկերը գնահատելու համար դուք պետք է չափումներ հավաքեք հաճախորդի մեքենաներից, և ոչ միայն բլոկչեյն հանգույցներից:
Գործարքի ուղարկում և դրա կարգավիճակի մոնիտորինգ
Հաջորդ քայլը գործարքն ուղարկելն է ընտրված բլոկչեյն հանգույցին և ստանալ այն գործարքների լողավազան ընդունելու կարգավիճակ: Այս փուլը նման է սովորական տվյալների բազայի մուտքին, հանգույցը պետք է գրանցի գործարքը լողավազանում և սկսի դրա մասին տեղեկատվություն տարածել p2p ցանցի միջոցով: Այստեղ կատարողականի գնահատման մոտեցումը նման է ավանդական Web API միկրոծառայությունների կատարողականի գնահատմանը, և բլոկչեյններում կատարված գործարքներն իրենք կարող են թարմացվել և ակտիվորեն փոխել իրենց կարգավիճակը: Ընդհանուր առմամբ, որոշ բլոկչեյնների վերաբերյալ գործարքների մասին տեղեկատվության թարմացումը կարող է տեղի ունենալ մի քանի անգամ, օրինակ՝ շղթայական պատառաքաղների միջև անցնելիս կամ երբ BP-ները հայտարարում են գործարքը բլոկում ներառելու իրենց մտադրության մասին: Այս լողավազանի չափի և դրանում գործարքների քանակի սահմանափակումները կարող են ազդել բլոկչեյնի աշխատանքի վրա: Եթե գործարքների ֆոնդը լցված է առավելագույն հնարավոր չափով կամ չի տեղավորվում RAM-ում, ցանցի արդյունավետությունը կարող է կտրուկ նվազել: Բլոկչեյնները չունեն անպետք հաղորդագրությունների հեղեղից պաշտպանվելու կենտրոնացված միջոցներ, և եթե բլոկչեյնն աջակցում է մեծ ծավալի գործարքների և ցածր վճարների, դա կարող է հանգեցնել գործարքների լողավազանի լցվել՝ մեկ այլ պոտենցիալ կատարողական խոչընդոտ:
Բլոկչեյններում հաճախորդը գործարք է ուղարկում ցանկացած բլոկչեյն հանգույցի, որն իրեն դուր է գալիս, գործարքի հեշը սովորաբար հայտնի է հաճախորդին նախքան ուղարկելը, ուստի այն ամենը, ինչ նա պետք է անի, հասնել կապին և փոխանցելուց հետո սպասել, որ բլոկչեյնը փոխվի: իր վիճակը՝ հնարավորություն տալով նրա գործարքին։ Նկատի ունեցեք, որ «tps» չափելով՝ կարող եք բոլորովին այլ արդյունքներ ստանալ բլոկչեյն հանգույցին միանալու տարբեր մեթոդների համար։ Սա կարող է լինել սովորական HTTP RPC կամ WebSocket, որը թույլ է տալիս իրականացնել «բաժանորդագրվել» օրինակը: Երկրորդ դեպքում հաճախորդը ավելի վաղ ծանուցում կստանա, և հանգույցը ավելի քիչ ռեսուրսներ կծախսի (հիմնականում հիշողություն և տրաֆիկ) գործարքի կարգավիճակի վերաբերյալ պատասխանների վրա: Այսպիսով, «tps» չափելիս անհրաժեշտ է հաշվի առնել, թե ինչպես են հաճախորդները միանում հանգույցներին: Հետևաբար, այս խցանման ռիսկերը գնահատելու համար հենանիշային բլոկչեյնը պետք է կարողանա ընդօրինակել հաճախորդներին և՛ WebSocket, և՛ HTTP RPC հարցումներով՝ իրական ցանցերին համապատասխան համամասնություններով, ինչպես նաև փոխել գործարքների բնույթը և դրանց չափը:
Այս խցանման ռիսկերը գնահատելու համար անհրաժեշտ է նաև չափումներ հավաքել հաճախորդի մեքենաներից, և ոչ միայն բլոկչեյն հանգույցներից:
Գործարքների և բլոկների փոխանցում p2p ցանցի միջոցով
Բլոկչեյններում գործընկերների հետ (p2p) ցանցն օգտագործվում է մասնակիցների միջև գործարքներ և բլոկներ փոխանցելու համար: Գործարքները տարածվում են ցանցով մեկ՝ սկսած հանգույցներից մեկից, մինչև հասնեն հավասարակցական բլոկների արտադրողներին, որոնք գործարքները փաթեթավորում են բլոկների մեջ և օգտագործելով նույն p2p-ը, նոր բլոկներ են բաժանում ցանցի բոլոր հանգույցներին: Շատ ժամանակակից p2p ցանցերի հիմքը Kademlia արձանագրության տարբեր փոփոխություններն են: լավ ամփոփում այս արձանագրության, և - BitTorrent ցանցում տարբեր չափումներով հոդված, որտեղից կարելի է հասկանալ, որ ցանցի այս տեսակն ավելի բարդ է և ավելի քիչ կանխատեսելի, քան կենտրոնացված ծառայության կոշտ կազմաձևված ցանցը: Նաև, հոդված Ethereum հանգույցների համար տարբեր հետաքրքիր չափումների չափման մասին:
Մի խոսքով, նման ցանցերում յուրաքանչյուր հասակակից պահպանում է այլ հասակակիցների իր սեփական դինամիկ ցանկը, որտեղից նա պահանջում է տեղեկատվության բլոկներ, որոնք հասցեագրված են բովանդակությամբ: Երբ հասակակիցը հարցում է ստանում, նա կա՛մ տալիս է անհրաժեշտ տեղեկատվությունը, կա՛մ հարցումը փոխանցում է ցուցակից հաջորդ կեղծ պատահական հասակակիցին, և ստանալով պատասխան՝ այն փոխանցում է հայցողին և պահում է որոշ ժամանակ՝ տալով սա. հաջորդ անգամ ավելի վաղ տեղեկատվության բլոկ: Այսպիսով, հանրաճանաչ տեղեկատվությունը հայտնվում է մեծ թվով հասակակիցների մեծ թվով քեշերում, և ոչ հանրաճանաչ տեղեկատվությունը աստիճանաբար փոխարինվում է: Գործընկերները գրանցում են այն մասին, թե ով ում է փոխանցել որքան տեղեկատվություն, և ցանցը փորձում է խթանել ակտիվ դիստրիբյուտորներին՝ բարձրացնելով նրանց վարկանիշները և նրանց մատուցելով ավելի բարձր մակարդակի ծառայություններ՝ ինքնաբերաբար հեռացնելով ոչ ակտիվ մասնակիցներին գործընկերների ցուցակներից:
Այսպիսով, գործարքն այժմ պետք է բաշխվի ամբողջ ցանցով, որպեսզի բլոկ արտադրողները կարողանան տեսնել այն և ներառել այն բլոկում: Հանգույցը ակտիվորեն «բաշխում է» նոր գործարք բոլորին և լսում է ցանցը՝ սպասելով մի բլոկի, որի ինդեքսում կհայտնվի պահանջվող գործարքը՝ սպասող հաճախորդին ծանուցելու համար: Ժամանակը, որ տևում է ցանցին p2p ցանցերում նոր գործարքների և բլոկների մասին տեղեկատվությունը միմյանց փոխանցելու համար կախված է շատ մեծ թվով գործոններից՝ մոտակայքում աշխատող ազնիվ հանգույցների քանակից (ցանցի տեսանկյունից), «ջերմ վեր» այս հանգույցների քեշերից, բլոկների չափը, գործարքները, փոփոխությունների բնույթը, ցանցի աշխարհագրությունը, հանգույցների քանակը և շատ այլ գործոններ: Նման ցանցերում կատարողականի չափանիշների համալիր չափումները բարդ խնդիր են, անհրաժեշտ է միաժամանակ գնահատել հարցումների մշակման ժամանակը և՛ հաճախորդների, և՛ գործընկերների (բլոկչեյն հանգույցների) վրա: p2p մեխանիզմներից որևէ մեկի հետ կապված խնդիրներ, տվյալների սխալ հեռացում և պահում, ակտիվ գործընկերների ցուցակների անարդյունավետ կառավարում և շատ այլ գործոններ կարող են առաջացնել ուշացումներ, որոնք ազդում են ամբողջ ցանցի արդյունավետության վրա, և այս խցանումն ամենադժվարն է վերլուծել: , արդյունքների թեստ և մեկնաբանում։
Blockchain-ի մշակում և պետական տվյալների բազայի թարմացում
Բլոկչեյնի ամենակարևոր մասը կոնսենսուսի ալգորիթմն է, դրա կիրառումը ցանցից ստացված նոր բլոկների վրա և գործարքների մշակումը արդյունքների գրանցմամբ պետական տվյալների բազայում: Շղթային նոր բլոկ ավելացնելը և այնուհետև հիմնական շղթան ընտրելը պետք է հնարավորինս արագ աշխատի: Այնուամենայնիվ, իրական կյանքում «պետք է» չի նշանակում «աշխատանքներ», և կարելի է, օրինակ, պատկերացնել մի իրավիճակ, երբ երկու երկար մրցակցող շղթաներ անընդհատ փոխվում են միմյանց միջև՝ յուրաքանչյուր անջատիչում փոխելով լողավազանի հազարավոր գործարքների մետատվյալները: , և անընդհատ հետ գլորելով պետական տվյալների բազան։ Այս փուլը, շիշը սահմանելու առումով, ավելի պարզ է, քան p2p ցանցային շերտը, քանի որ գործարքների կատարումը և կոնսենսուսի ալգորիթմը խիստ դետերմինիստական են, և այստեղ ավելի հեշտ է որևէ բան չափել:
Հիմնական բանը այս փուլի կատարման պատահական դեգրադացիան չշփոթել ցանցային խնդիրների հետ. հանգույցներն ավելի դանդաղ են առաքում բլոկները և հիմնական շղթայի մասին տեղեկատվություն, իսկ արտաքին հաճախորդի համար դա կարող է դանդաղ ցանցի տեսք ունենալ, չնայած խնդիրը կայանում է նրանում. բոլորովին այլ տեղ.
Այս փուլում կատարողականը օպտիմալացնելու համար օգտակար է հավաքել և վերահսկել չափումները հենց հանգույցներից և դրանցում ներառել վիճակագրական տվյալների բազայի թարմացման հետ կապված չափումներ՝ հանգույցում մշակված բլոկների քանակը, դրանց չափը, գործարքների քանակը, շղթայական պատառաքաղների միջև անջատիչների թիվը, անվավեր բլոկների քանակը, վիրտուալ մեքենայի աշխատանքի ժամանակը, տվյալների փոխանցման ժամանակը և այլն: Սա թույլ չի տա ցանցի խնդիրները շփոթել շղթայի մշակման ալգորիթմների սխալների հետ:
Վիրտուալ մեքենայի մշակման գործարքները կարող են լինել տեղեկատվության օգտակար աղբյուր, որը կարող է օպտիմալացնել բլոկչեյնի աշխատանքը: Հիշողության հատկացումների քանակը, կարդալու/գրելու հրահանգների քանակը և պայմանագրային կոդի կատարման արդյունավետության հետ կապված այլ չափումներ կարող են շատ օգտակար տեղեկատվություն տրամադրել մշակողներին: Միևնույն ժամանակ, խելացի պայմանագրերը ծրագրեր են, ինչը նշանակում է, որ տեսականորեն նրանք կարող են սպառել ցանկացած ռեսուրս՝ պրոցեսոր/հիշողություն/ցանց/պահեստ, ուստի գործարքների մշակումը բավականին անորոշ փուլ է, որը, ի լրումն, մեծապես փոխվում է տարբերակների միջև շարժվելիս: և պայմանագրային ծածկագրերը փոխելիս: Հետևաբար, գործարքների մշակման հետ կապված չափանիշները նույնպես անհրաժեշտ են բլոկչեյնի կատարողականը արդյունավետորեն օպտիմալացնելու համար:
Հաճախորդի կողմից բլոկչեյնում գործարք ներառելու մասին ծանուցման ստացում
Սա բլոկչեյն հաճախորդի կողմից ծառայությունը ստանալու վերջին փուլն է, համեմատած մյուս փուլերի հետ՝ մեծ ծախսեր չկան, բայց դեռ արժե հաշվի առնել, որ հաճախորդը հանգույցից ծավալուն պատասխան ստանա (օրինակ՝ խելացի պայմանագիր): վերադարձնելով տվյալների զանգված): Ամեն դեպքում, այս կետը ամենակարևորն է նրա համար, ով տվել է «Քանի՞ tps կա ձեր բլոկչեյնում» հարցը, քանի որ. Այս պահին գրանցվում է ծառայության ստացման ժամը։
Այս վայրում միշտ ուղարկվում է այն ամբողջ ժամանակը, որը հաճախորդը պետք է ծախսեր՝ սպասելով բլոկչեյնից պատասխան ստանալուն, այս անգամն է, որ օգտատերը կսպասի հաստատմանը իր հավելվածում, և հենց դրա օպտիմալացումն է. ծրագրավորողների հիմնական խնդիրը.
Ամփոփում
Արդյունքում մենք կարող ենք նկարագրել բլոկչեյնների վրա կատարված գործողությունների տեսակները և դրանք բաժանել մի քանի կատեգորիաների.
- կրիպտոգրաֆիկ փոխակերպումներ, ապացույցների կառուցում
- հասակակիցների ցանցեր, գործարքներ և բլոկների կրկնօրինակում
- գործարքների մշակում, խելացի պայմանագրերի կատարում
- բլոկչեյնում փոփոխություններ կիրառելով պետական տվյալների բազայում, թարմացնելով գործարքների և բլոկների տվյալները
- միայն կարդալու հարցումներ պետական տվյալների բազայի, բլոկչեյն հանգույցի API-ի, բաժանորդային ծառայությունների համար
Ընդհանուր առմամբ, ժամանակակից բլոկչեյն հանգույցների տեխնիկական պահանջները չափազանց լուրջ են՝ կրիպտոգրաֆիայի արագ պրոցեսորներ, մեծ քանակությամբ RAM՝ պետական տվյալների բազա պահելու և արագ մուտք գործելու համար, ցանցային փոխազդեցություն՝ օգտագործելով մեծ թվով միաժամանակ բաց կապեր և մեծ պահեստ: Նման բարձր պահանջները և տարբեր տեսակի գործառնությունների առատությունը անխուսափելիորեն հանգեցնում են նրան, որ հանգույցները կարող են չունենալ բավարար ռեսուրսներ, և այնուհետև վերը քննարկված ցանկացած փուլ կարող է դառնալ ևս մեկ խոչընդոտ ցանցի ընդհանուր աշխատանքի համար:
Բլոկչեյնների աշխատանքը նախագծելիս և գնահատելիս դուք ստիպված կլինեք հաշվի առնել այս բոլոր կետերը: Դա անելու համար դուք պետք է միաժամանակ հավաքեք և վերլուծեք չափանիշները հաճախորդներից և ցանցային հանգույցներից, փնտրեք դրանց միջև փոխհարաբերություններ, գնահատեք հաճախորդներին ծառայություններ մատուցելու ժամանակը, հաշվի առնեք բոլոր հիմնական ռեսուրսները՝ պրոցեսոր/հիշողություն/ցանց/պահեստավորում: , հասկանալ, թե ինչպես են դրանք օգտագործվում և ազդում միմյանց վրա: Այս ամենը «քանի TPS»-ի տեսքով տարբեր բլոկչեյնների արագությունները համեմատելը չափազանց անշնորհակալ խնդիր է դարձնում, քանի որ կան հսկայական թվով տարբեր կոնֆիգուրացիաներ և վիճակներ: Խոշոր կենտրոնացված համակարգերում, հարյուրավոր սերվերների կլաստերներում, այս խնդիրները նույնպես բարդ են և պահանջում են նաև մեծ թվով տարբեր չափանիշների հավաքում, սակայն բլոկչեյններում՝ p2p ցանցերի, պայմանագրերի մշակման վիրտուալ մեքենաների, ներքին տնտեսությունների, աստիճանների քանակի պատճառով։ ազատությունը շատ ավելի մեծ է, ինչը թեստը դարձնում է նույնիսկ մի քանի սերվերների վրա, այն ոչ ցուցիչ է և ցույց է տալիս միայն չափազանց մոտավոր արժեքներ, որոնք գրեթե կապ չունեն իրականության հետ:
Հետևաբար, երբ զարգանում ենք բլոկչեյնի միջուկում, գնահատելու կատարողականը և «արդյո՞ք այն բարելավվել է նախորդ անգամվա համեմատ» հարցին պատասխանելու համար մենք օգտագործում ենք բավականին բարդ ծրագրակազմ, որը կազմակերպում է բլոկչեյնի գործարկումը տասնյակ հանգույցներով և ավտոմատ կերպով գործարկում է հենանիշ և հավաքում չափումներ։ Առանց այս տեղեկատվության չափազանց դժվար է կարգաբերել արձանագրությունները, որոնք աշխատում են բազմաթիվ մասնակիցների հետ:
Այսպիսով, երբ դուք ստանում եք «Քանի՞ TPS ձեր բլոկչեյնում» հարցը, առաջարկեք ձեր զրուցակցին թեյ և հարցրեք, թե արդյոք նա պատրա՞ստ է դիտել տասնյակ գրաֆիկներ, ինչպես նաև լսել բլոկչեյնի աշխատանքի բոլոր երեք տուփերը և ձեր առաջարկները: դրանք լուծելով...
Source: www.habr.com