Plej ŝatata demando pri iu ajn distribuita sistemo de ne-teknika persono estas "Kiom da tps estas sur via blokĉeno?" Tamen, la nombro donita en respondo kutime havas malmulte da komuna kun tio, kion la demandanto ŝatus aŭdi. Fakte, li volis demandi "ĉu via blokĉeno konvenos al miaj komercaj postuloj", kaj ĉi tiuj postuloj ne estas unu nombro, sed multaj kondiĉoj - jen reto-toleremo al misfunkciadoj, finaj postuloj, grandecoj, naturo de transakcioj kaj multaj aliaj parametroj. Do la respondo al la demando "kiom da tps" verŝajne ne estos simpla, kaj preskaŭ neniam kompleta. Distribuita sistemo kun dekoj aŭ centoj da nodoj farantaj sufiĉe kompleksajn kalkulojn povas esti en grandega nombro da malsamaj ŝtatoj rilataj al la stato de la reto, la enhavo de la blokĉeno, teknikaj misfunkciadoj, ekonomiaj problemoj, atakoj kontraŭ la reto kaj multaj aliaj kialoj. . La stadioj, ĉe kiuj eblas problemoj de rendimento, diferencas de tradiciaj servoj, kaj blokĉena retservilo estas retservo, kiu kombinas la funkciecon de datumbazo, retservilo kaj torenta kliento, kio faras ĝin ekstreme kompleksa laŭ la ŝarĝa profilo en ĉiuj subsistemoj. : procesoro, memoro, reto, stokado

Okazas, ke malcentralizitaj retoj kaj blokĉenoj estas sufiĉe specifaj kaj nekutima programaro por centralizitaj programistoj. Tial mi ŝatus reliefigi gravajn aspektojn de la agado kaj daŭripovo de malcentralizitaj retoj, alirojn al mezuri ilin kaj trovi botelojn. Ni rigardos diversajn rendimentajn problemojn, kiuj limigas la rapidecon provizi servojn al blokĉenaj uzantoj kaj rimarkos la karakterizaĵojn de ĉi tiu tipo de programaro.

Etapoj de serva peto de blokĉena kliento

Por honeste paroli pri la kvalito de iu pli-malpli kompleksa servo, oni devas konsideri ne nur averaĝajn valorojn, sed ankaŭ maksimumajn/minimumajn, medianojn, procentojn. Teorie, ni povas paroli pri 1000 tps en iu blokĉeno, sed se 900 transakcioj estis kompletigitaj kun grandega rapideco, kaj 100 estis "blokitaj" dum kelkaj sekundoj, tiam la averaĝa tempo kolektita super ĉiuj transakcioj ne estas tute justa metriko por kliento. kiun mi ne povis plenumi la transakcion en kelkaj sekundoj. Provizoraj "truoj" kaŭzitaj de maltrafitaj konsentaj rondoj aŭ retaj disiĝoj povas multe ruinigi servon, kiu montris bonegan agadon sur testbenkoj.

Por identigi tiajn botelojn, necesas havi bonan komprenon pri la stadioj, ĉe kiuj vera blokĉeno povas malfacile servi uzantojn. Ni priskribu la ciklon de liverado kaj prilaborado de transakcio, kaj ankaŭ akiri novan staton de la blokĉeno, de kiu la kliento povas kontroli, ke lia transakcio estis prilaborita kaj kalkulita.

la transakcio estas formita sur la kliento
la transakcio estas subskribita sur la kliento
la kliento elektas unu el la nodoj kaj sendas sian transakcion al ĝi
la kliento abonas ĝisdatigojn al la ŝtata datumbazo de la nodo, atendante ke la rezultoj de ĝia transakcio aperos
la nodo distribuas la transakcion tra la p2p reto
pluraj aŭ unu BP (blokproduktanto) procesas amasigitajn transakciojn, ĝisdatigante la ŝtatan datumbazon
BP formas novan blokon post prilaborado de la bezonata nombro da transakcioj
BP distribuas novan blokon tra la p2p reto
la nova bloko estas liverita al la nodo, kiun la kliento aliras
nodo ĝisdatigas ŝtatan datumbazon
la nodo vidas la ĝisdatigon pri la kliento kaj sendas al li transakcian sciigon

Nun ni rigardu pli detale ĉi tiujn stadiojn kaj priskribu la eblajn rendimentajn problemojn ĉe ĉiu stadio. Male al centralizitaj sistemoj, ni ankaŭ konsideros kodan ekzekuton ĉe retaj klientoj. Tre ofte, kiam oni mezuras TPS, la transakcia prilaborado estas kolektita de la nodoj, kaj ne de la kliento - ĉi tio ne estas tute justa. La kliento ne zorgas pri kiom rapide la nodo prilaboris sian transakcion; la plej grava afero por li estas la momento, kiam fidindaj informoj pri ĉi tiu transakcio inkluzivita en la blokĉeno disponeblas al li. Estas ĉi tiu metriko, kiu estas esence la transakcia ekzekuttempo. Ĉi tio signifas, ke malsamaj klientoj, eĉ sendante la saman transakcion, povas ricevi tute malsamajn tempojn, kiuj dependas de la kanalo, ŝarĝo kaj proksimeco de la nodo ktp. Do nepre necesas mezuri ĉi tiun tempon ĉe klientoj, ĉar ĉi tiu estas la parametro, kiu bezonas esti optimumigita.

Preparante transakcion ĉe la klienta flanko

Ni komencu per la unuaj du punktoj: la transakcio estas formita kaj subskribita de la kliento. Sufiĉe strange, ĉi tio ankaŭ povas esti botelkolo de blokĉena rendimento de la vidpunkto de la kliento. Ĉi tio estas nekutima por centralizitaj servoj, kiuj transprenas ĉiujn kalkulojn kaj operaciojn kun datumoj, kaj la kliento simple preparas mallongan peton, kiu povas peti grandan kvanton da datumoj aŭ kalkuloj, akirante pretan rezulton. En blokĉenoj, la klientokodo fariĝas pli kaj pli potenca, kaj la blokĉena kerno fariĝas pli kaj pli malpeza, kaj amasaj komputikaj taskoj estas kutime translokigitaj al la klienta programaro. En blokĉenoj, estas klientoj, kiuj povas prepari unu transakcion dum sufiĉe longa tempo (mi parolas pri diversaj merkle-pruvoj, koncizaj pruvoj, sojlaj subskriboj kaj aliaj kompleksaj operacioj ĉe la klienta flanko). Bona ekzemplo de facila surĉena kontrolo kaj peza preparado de transakcio ĉe la kliento estas pruvo de membreco en listo bazita sur Merkle-arbo, ĉi tie artikolo.

Ankaŭ, ne forgesu, ke la klientokodo ne simple sendas transakciojn al la blokĉeno, sed unue pridemandas la staton de la blokĉeno - kaj ĉi tiu agado povas influi la kongeston de la reto kaj blokĉenaj nodoj. Do, kiam oni prenas mezurojn, estus racie kopii la konduton de la klientokodo kiel eble plej tute. Eĉ se en via blokĉeno estas ordinaraj malpezaj klientoj, kiuj metas regulan ciferecan subskribon sur la plej simplan transakcion por translokigi iun valoraĵon, ĉiujare ankoraŭ estas pli amasaj kalkuloj pri la kliento, kriptaj algoritmoj plifortiĝas, kaj ĉi tiu parto de la prilaborado povas. iĝi signifa proplemkolo estonte. Sekve, atentu kaj ne maltrafu la situacion, kiam en transakcio daŭranta 3.5s, 2.5s estas elspezitaj por prepari kaj subskribi la transakcion, kaj 1.0s por sendi ĝin al la reto kaj atendi respondon. Por taksi la riskojn de ĉi tiu botelkolo, vi devas kolekti metrikojn de klientaj maŝinoj, kaj ne nur de blokĉenaj nodoj.

Sendante transakcion kaj kontrolante ĝian staton

La sekva paŝo estas sendi la transakcion al la elektita blokĉena nodo kaj ricevi la statuson akcepti ĝin en la transakcian naĝejon. Ĉi tiu stadio estas simila al regula datumbaza aliro; la nodo devas registri la transakcion en la naĝejo kaj komenci distribui informojn pri ĝi tra la p2p-reto. La aliro al taksado de rendimento ĉi tie estas simila al taksado de la agado de tradiciaj TTT-API-mikroservoj, kaj la transakcioj mem en blokĉenoj povas esti ĝisdatigitaj kaj aktive ŝanĝi sian statuson. Ĝenerale, ĝisdatigo de transakciaj informoj pri iuj blokĉenoj povas okazi plurfoje, ekzemple kiam ŝanĝas inter ĉenaj forkoj aŭ kiam BP-oj anoncas sian intencon inkluzivi transakcion en bloko. Limoj pri la grandeco de ĉi tiu naĝejo kaj la nombro da transakcioj en ĝi povas influi la agadon de la blokĉeno. Se la transakcia naĝejo estas plenigita al la maksimuma ebla grandeco, aŭ ne taŭgas en RAM, reto-rendimento povas malpliiĝi akre. Blokoĉenoj havas neniujn centralizitajn rimedojn por protekti kontraŭ inundo de rubomesaĝoj, kaj se la blokĉeno subtenas alt-volumajn transakciojn kaj malaltajn kotizojn, ĉi tio povas kaŭzi la transakcian naĝejon superflui - alia ebla rendimenta proplemkolo.

En blokĉenoj, la kliento sendas transakcion al iu ajn blokĉena nodo, kiun li ŝatas, la haŝo de la transakcio estas kutime konata de la kliento antaŭ ol sendado, do ĉio, kion li devas fari, estas atingi la konekton kaj, post transsendo, atendi ke la blokĉeno ŝanĝiĝos. ĝia stato, ebligante lian transakcion. Notu, ke mezurante "tps" vi povas akiri tute malsamajn rezultojn por malsamaj metodoj por konekti al blokĉena nodo. Ĉi tio povas esti regula HTTP RPC aŭ WebSocket, kiu ebligas al vi efektivigi la "aboni" ŝablonon. En la dua kazo, la kliento ricevos sciigon pli frue, kaj la nodo elspezos malpli da rimedoj (ĉefe memoro kaj trafiko) pri respondoj pri la transakcia stato. Do dum mezurado de "tps" necesas konsideri la manieron kiel klientoj konektas al nodoj. Tial, por taksi la riskojn de ĉi tiu botelkolo, la referenca blokĉeno devas povi emuli klientojn kun kaj WebSocket kaj HTTP RPC-petoj, en proporcioj respondaj al realaj retoj, kaj ankaŭ ŝanĝi la naturon de transakcioj kaj ilia grandeco.

Por taksi la riskojn de ĉi tiu botelkolo, vi ankaŭ devas kolekti metrikojn de klientaj maŝinoj, kaj ne nur de blokĉenaj nodoj.

Transdono de transakcioj kaj blokoj per reto p2p

En blokĉenoj, samulo-al-kunulo (p2p) retoj estas uzataj por translokigi transakciojn kaj blokojn inter partoprenantoj. Transakcioj disvastiĝas tra la reto, komencante de unu el la nodoj, ĝis ili atingas samnivelajn blokproduktantojn, kiuj pakas transakciojn en blokojn kaj, uzante la saman p2p, distribuas novajn blokojn al ĉiuj retaj nodoj. La bazo de la plej multaj modernaj p2p-retoj estas diversaj modifoj de la protokolo Kademlia. tie bona resumo de ĉi tiu protokolo, kaj jen - artikolo kun diversaj mezuroj en la reto BitTorrent, el kiu oni povas kompreni, ke ĉi tiu speco de reto estas pli kompleksa kaj malpli antaŭvidebla ol rigide agordita reto de centralizita servo. Ankaŭ, jen artikolo pri mezurado de diversaj interesaj metrikoj por Ethereum-nodoj.

Mallonge, ĉiu samulo en tiaj retoj konservas sian propran dinamikan liston de aliaj samuloj, de kiuj ĝi petas blokojn de informoj, kiuj estas traktitaj de enhavo. Kiam samulo ricevas peton, ĝi aŭ donas la necesajn informojn aŭ transdonas la peton al la sekva pseŭdo-hazarda samaĝulo el la listo, kaj ricevinte respondon, ĝi transdonas ĝin al la petanto kaj konservas ĝin por iom da tempo, donante ĉi tion. bloko de informoj pli frue la venontan fojon. Tiel, populara informo finiĝas en granda nombro da kaŝmemoroj de granda nombro da samuloj, kaj nepopulara informo estas iom post iom anstataŭigita. Samuloj konservas rekordojn de kiu transdonis kiom da informoj al kiu, kaj la reto provas stimuli aktivajn distribuistojn pliigante siajn rangigojn kaj provizante al ili pli altan nivelon de servo, aŭtomate delokigante neaktivajn partoprenantojn de kunullistoj.

Do, la transakcio nun devas esti distribuita tra la reto, por ke blok-produktantoj povu vidi ĝin kaj inkluzivi ĝin en la blokon. La nodo aktive "distribuas" novan transakcion al ĉiuj kaj aŭskultas la reton, atendante blokon en kies indekso aperos la postulata transakcio por sciigi la atendantan klienton. La tempo necesa por la reto por transdoni informojn pri novaj transakcioj kaj blokoj unu al la alia en p2p-retoj dependas de tre granda nombro da faktoroj: la nombro da honestaj nodoj laborantaj proksime (de reto-perspektivo), la "varma- supren” de la kaŝmemoroj de ĉi tiuj nodoj, la grandeco de blokoj, transakcioj, la naturo de ŝanĝoj , retgeografio, nombro da nodoj kaj multaj aliaj faktoroj. Kompleksaj mezuradoj de agado-metrikoj en tiaj retoj estas kompleksa afero; necesas samtempe taksi la peton prilaborado de kaj klientoj kaj kunuloj (blokĉenaj nodoj). Problemoj en iu ajn el la p2p-mekanismoj, malĝusta datuma eldomigo kaj kaŝmemoro, neefika administrado de listoj de aktivaj kunuloj kaj multaj aliaj faktoroj povas kaŭzi prokrastojn, kiuj influas la efikecon de la tuta reto entute, kaj ĉi tiu botelkolo estas la plej malfacile analizebla. , testo kaj interpreto de rezultoj.

Blockchain-pretigo kaj ŝtata datumbazo ĝisdatigo

La plej grava parto de la blokĉeno estas la konsenta algoritmo, ĝia apliko al novaj blokoj ricevitaj de la reto kaj la prilaborado de transakcioj kun registrado de la rezultoj en la ŝtata datumbazo. Aldoni novan blokon al la ĉeno kaj poste elekti la ĉefan ĉenon devus funkcii kiel eble plej rapide. Tamen, en la reala vivo, "devus" ne signifas "funkcias", kaj oni povas, ekzemple, imagi situacion kie du longaj konkurantaj ĉenoj konstante ŝanĝas inter si mem, ŝanĝante la metadatenojn de miloj da transakcioj en la naĝejo ĉe ĉiu ŝaltilo. , kaj senĉese refunkciigi la ŝtatan datumbazon. Ĉi tiu etapo, laŭ difino de la proplemkolo, estas pli simpla ol la p2p retotavolo, ĉar transakcia ekzekuto kaj konsenta algoritmo estas strikte determinismaj, kaj estas pli facile mezuri ion ajn ĉi tie.
La ĉefa afero estas ne konfuzi hazardan degradadon en la agado de ĉi tiu etapo kun retaj problemoj - nodoj estas pli malrapidaj en liverado de blokoj kaj informoj pri la ĉefa ĉeno, kaj por ekstera kliento tio povas aspekti kiel malrapida reto, kvankam la problemo kuŝas en tute alia loko.

Por optimumigi agadon en ĉi tiu etapo, estas utile kolekti kaj kontroli metrikojn de la nodoj mem, kaj inkluzivi en ili tiujn rilatajn al ĝisdatigo de la ŝtata datumbazo: la nombro da blokoj prilaboritaj sur la nodo, ilia grandeco, la nombro da transakcioj, la nombro da ŝaltiloj inter ĉenforkoj, la nombro da nevalidaj blokoj, funkciada tempo de virtuala maŝino, datum-tempo, ktp. Ĉi tio evitos, ke retaj problemoj estu konfuzitaj kun eraroj en ĉenaj prilaboraj algoritmoj.

Virtuala maŝino prilaboranta transakciojn povas esti utila fonto de informoj, kiu povas optimumigi la funkciadon de la blokĉeno. La nombro da memor-asignoj, la nombro da legado/skriba instrukcioj, kaj aliaj metrikoj rilataj al la efikeco de kontraktokodo ekzekuto povas provizi multajn utilajn informojn al programistoj. Samtempe, inteligentaj kontraktoj estas programoj, kio signifas, ke teorie ili povas konsumi iun ajn el la rimedoj: cpu/memoro/reto/stokado, do transakcia prilaborado estas sufiĉe necerta etapo, kiu krome multe ŝanĝiĝas dum moviĝado inter versioj. kaj dum ŝanĝado de kontraktokodoj. Tial ankaŭ necesas metrikoj rilataj al transakcia prilaborado por efike optimumigi la agadon de blokĉeno.

Ricevo de la kliento de sciigo pri la inkludo de transakcio en la blokĉeno

Ĉi tiu estas la fina etapo de la blokĉena kliento ricevanta la servon; kompare kun aliaj stadioj, ne estas grandaj superkostoj, sed ankoraŭ valoras konsideri la eblecon, ke la kliento ricevu grandan respondon de la nodo (ekzemple, inteligenta kontrakto). resendante tabelon da datumoj). Ĉiukaze, ĉi tiu punkto estas la plej grava por tiu, kiu demandis la demandon "kiom da tps estas en via blokĉeno?", ĉar En ĉi tiu momento, la tempo de ricevo de la servo estas registrita.

En ĉi tiu loko, ĉiam estas sendo de la plena tempo, kiun la kliento devis pasigi atendante respondon de la blokĉeno; estas ĉi tiu fojo, ke la uzanto atendos konfirmon en sia aplikaĵo, kaj estas ĝia optimumigo kiu estas la ĉefa tasko de la programistoj.

konkludo

Kiel rezulto, ni povas priskribi la specojn de operacioj faritaj sur blokĉenoj kaj dividi ilin en plurajn kategoriojn:

kriptografiaj transformoj, pruvkonstruo
samulo-al-kunula retigado, transakcio kaj blokreproduktado
transakcia pretigo, ekzekuto de inteligentaj kontraktoj
aplikante ŝanĝojn en la blokĉeno al la ŝtata datumbazo, ĝisdatigante datumojn pri transakcioj kaj blokoj
nurlegeblaj petoj al ŝtata datumbazo, blokĉena nodo API, abonservoj

Ĝenerale, la teknikaj postuloj por modernaj blokĉenaj nodoj estas ekstreme seriozaj - rapidaj CPUoj por kriptografio, granda kvanto da RAM por stoki kaj rapide aliri la ŝtatan datumbazon, reto-interago uzante grandan nombron da samtempe malfermitaj konektoj kaj granda stokado. Tiaj altaj postuloj kaj la abundo de malsamaj specoj de operacioj neeviteble kondukas al la fakto, ke nodoj eble ne havas sufiĉajn rimedojn, kaj tiam iu el la supre diskutitaj stadioj povas fariĝi alia botelo por la ĝenerala reto-agado.

Kiam vi desegnas kaj taksas la agadon de blokĉenoj, vi devos konsideri ĉiujn ĉi tiujn punktojn. Por fari tion, vi devas kolekti kaj analizi mezurojn samtempe de klientoj kaj retaj nodoj, serĉi korelaciojn inter ili, taksi la tempon necesan por provizi servojn al klientoj, konsideri ĉiujn ĉefajn rimedojn: cpu/memoro/reto/stokado. , komprenu kiel ili estas uzataj kaj influas unu la alian. Ĉio ĉi faras kompari la rapidojn de malsamaj blokĉenoj en la formo de "kiom da TPS" ege sendanka tasko, ĉar ekzistas grandega nombro da malsamaj agordoj kaj statoj. En grandaj centralizitaj sistemoj, aretoj de centoj da serviloj, ĉi tiuj problemoj ankaŭ estas kompleksaj kaj ankaŭ postulas la kolekton de granda nombro da malsamaj metrikoj, sed en blokĉenoj, pro p2p-retoj, virtualaj maŝinoj pritraktantaj kontraktojn, internajn ekonomiojn, la nombron da gradoj. de libereco estas multe pli granda, kio faras la teston eĉ sur pluraj serviloj, ĝi estas neindika kaj montras nur ege proksimumajn valorojn, kiuj preskaŭ ne havas rilaton kun la realo.

Sekve, dum evoluado en la blokĉeno, por taksi rendimenton kaj respondi la demandon "ĉu ĝi pliboniĝis kompare kun la lasta fojo?" ni uzas sufiĉe kompleksan programaron, kiu regas la lanĉon de blokĉeno kun dekoj da nodoj kaj aŭtomate lanĉas komparnormon kaj kolektas metrikojn. ; sen ĉi tiu informo estas ege malfacile sencimigi protokolojn, kiuj funkcias kun pluraj partoprenantoj.

Do, kiam vi ricevas la demandon "kiom da TPS estas en via blokĉeno?", proponu al via interparolanto iom da teo kaj demandu, ĉu li pretas rigardi dekduon da grafikaĵoj kaj ankaŭ aŭskultu ĉiujn tri skatolojn de problemoj de blokĉeno kaj viajn sugestojn por solvante ilin...

fonto: www.habr.com

Kiom da TPS estas sur via blokĉeno?