Ang paboritong tanong tungkol sa anumang distributed system mula sa isang hindi teknikal na tao ay "Ilang tps ang nasa iyong blockchain?" Gayunpaman, ang bilang na ibinigay bilang tugon ay karaniwang may kaunting pagkakatulad sa kung ano ang gustong marinig ng nagtatanong. Sa katunayan, gusto niyang magtanong "magkakasya ba ang iyong blockchain sa aking mga kinakailangan sa negosyo," at ang mga kinakailangan na ito ay hindi isang numero, ngunit maraming mga kundisyon - narito ang pagpapaubaya sa fault ng network, mga kinakailangan sa finality, mga sukat, likas na katangian ng mga transaksyon at maraming iba pang mga parameter. Kaya ang sagot sa tanong na "ilang tps" ay malamang na hindi simple, at halos hindi kumpleto. Ang isang distributed system na may sampu o daan-daang mga node na gumaganap ng medyo kumplikadong mga kalkulasyon ay maaaring nasa isang malaking bilang ng iba't ibang mga estado na may kaugnayan sa estado ng network, ang mga nilalaman ng blockchain, mga teknikal na pagkabigo, mga problema sa ekonomiya, pag-atake sa network at maraming iba pang mga kadahilanan . Ang mga yugto kung saan posible ang mga problema sa pagganap ay naiiba sa mga tradisyunal na serbisyo, at ang isang server ng network ng blockchain ay isang serbisyo sa network na pinagsasama ang pag-andar ng isang database, web server at torrent client, na ginagawang lubhang kumplikado sa mga tuntunin ng profile ng pag-load sa lahat ng mga subsystem. : processor, memorya, network, imbakan

Nangyayari na ang mga desentralisadong network at blockchain ay medyo tiyak at hindi pangkaraniwang software para sa mga sentralisadong software developer. Samakatuwid, gusto kong i-highlight ang mahahalagang aspeto ng pagganap at pagpapanatili ng mga desentralisadong network, mga diskarte sa pagsukat sa mga ito at paghahanap ng mga bottleneck. Titingnan namin ang iba't ibang mga isyu sa pagganap na naglilimita sa bilis ng pagbibigay ng mga serbisyo sa mga gumagamit ng blockchain at tandaan ang mga tampok na katangian ng ganitong uri ng software.

Mga yugto ng isang kahilingan sa serbisyo ng isang kliyente ng blockchain

Upang makapagsalita nang tapat tungkol sa kalidad ng anumang mas marami o hindi gaanong kumplikadong serbisyo, kailangan mong isaalang-alang hindi lamang ang mga average na halaga, kundi pati na rin ang maximum/minimum, median, percentiles. Sa teorya, maaari nating pag-usapan ang tungkol sa 1000 tps sa ilang blockchain, ngunit kung ang 900 na mga transaksyon ay nakumpleto na may napakalaking bilis, at 100 ay "natigil" sa loob ng ilang segundo, kung gayon ang average na oras na nakolekta sa lahat ng mga transaksyon ay hindi isang ganap na patas na sukatan para sa isang kliyente na hindi ko nakumpleto ang transaksyon sa loob ng ilang segundo. Ang mga pansamantalang "butas" na dulot ng mga hindi nakuhang consensus round o network split ay maaaring lubos na makasira sa isang serbisyo na nagpakita ng mahusay na pagganap sa mga test bench.

Upang matukoy ang mga naturang bottleneck, kinakailangan na magkaroon ng isang mahusay na pag-unawa sa mga yugto kung saan ang isang tunay na blockchain ay maaaring nahihirapang maghatid ng mga user. Ilarawan natin ang cycle ng paghahatid at pagproseso ng isang transaksyon, pati na rin ang pagkuha ng isang bagong estado ng blockchain, kung saan mapapatunayan ng kliyente na ang kanyang transaksyon ay naproseso at naitala.

ang transaksyon ay nabuo sa kliyente
ang transaksyon ay nilagdaan sa kliyente
pipili ang kliyente ng isa sa mga node at ipinapadala ang kanyang transaksyon dito
ang kliyente ay nag-subscribe sa mga update sa database ng estado ng node, naghihintay na lumitaw ang mga resulta ng transaksyon nito
ibinabahagi ng node ang transaksyon sa p2p network
ilan o isang BP (block producer) ang nagpoproseso ng mga naipon na transaksyon, ina-update ang database ng estado
Ang BP ay bumubuo ng isang bagong bloke pagkatapos iproseso ang kinakailangang bilang ng mga transaksyon
Namamahagi ang BP ng bagong block sa p2p network
ang bagong block ay inihahatid sa node na ina-access ng kliyente
ina-update ng node ang database ng estado
nakikita ng node ang update tungkol sa kliyente at pinadalhan siya ng notification sa transaksyon

Ngayon tingnan natin ang mga yugtong ito at ilarawan ang mga potensyal na isyu sa pagganap sa bawat yugto. Hindi tulad ng mga sentralisadong sistema, isasaalang-alang din namin ang pagpapatupad ng code sa mga kliyente ng network. Kadalasan, kapag sinusukat ang TPS, ang oras ng pagproseso ng transaksyon ay kinokolekta mula sa mga node, at hindi mula sa kliyente - hindi ito ganap na patas. Walang pakialam ang kliyente kung gaano kabilis naproseso ng node ang kanyang transaksyon; ang pinakamahalagang bagay para sa kanya ay ang sandali kung kailan magagamit sa kanya ang maaasahang impormasyon tungkol sa transaksyong ito na kasama sa blockchain. Ang sukatan na ito ang mahalagang oras ng pagpapatupad ng transaksyon. Nangangahulugan ito na ang iba't ibang mga kliyente, kahit na nagpapadala ng parehong transaksyon, ay maaaring makatanggap ng ganap na magkakaibang oras, na nakasalalay sa channel, pag-load at kalapitan ng node, atbp. Kaya talagang kinakailangan na sukatin ang oras na ito sa mga kliyente, dahil ito ang parameter na kailangang i-optimize.

Paghahanda ng isang transaksyon sa panig ng kliyente

Magsimula tayo sa unang dalawang punto: ang transaksyon ay nabuo at nilagdaan ng kliyente. Kakatwa, maaari rin itong maging bottleneck ng pagganap ng blockchain mula sa pananaw ng kliyente. Ito ay hindi pangkaraniwan para sa mga sentralisadong serbisyo, na kumukuha sa lahat ng mga kalkulasyon at pagpapatakbo na may data, at ang kliyente ay naghahanda lamang ng isang maikling kahilingan na maaaring humiling ng isang malaking halaga ng data o mga kalkulasyon, na nakakakuha ng isang handa na resulta. Sa mga blockchain, ang client code ay nagiging mas at mas malakas, at ang blockchain core ay nagiging mas at mas magaan, at napakalaking computing na gawain ay karaniwang inililipat sa client software. Sa mga blockchain, may mga kliyente na maaaring maghanda ng isang transaksyon sa loob ng mahabang panahon (pinag-uusapan ko ang tungkol sa iba't ibang merkle proofs, succinct proofs, threshold signatures at iba pang kumplikadong operasyon sa client side). Ang isang magandang halimbawa ng madaling on-chain na pag-verify at mabigat na paghahanda ng isang transaksyon sa kliyente ay patunay ng pagiging miyembro sa isang listahan batay sa Merkle-tree, dito artikulo.

Gayundin, huwag kalimutan na ang client code ay hindi lamang nagpapadala ng mga transaksyon sa blockchain, ngunit unang nagtatanong sa estado ng blockchain - at ang aktibidad na ito ay maaaring makaapekto sa pagsisikip ng network at mga blockchain node. Kaya, kapag kumukuha ng mga sukat, makatuwirang tularan ang pag-uugali ng code ng kliyente nang ganap hangga't maaari. Kahit na sa iyong blockchain ay may mga ordinaryong light client na naglalagay ng regular na digital signature sa pinakasimpleng transaksyon upang maglipat ng ilang asset, bawat taon ay mayroon pa ring mas malalaking kalkulasyon sa kliyente, ang mga crypto algorithm ay lumalakas, at ang bahaging ito ng pagproseso ay maaaring maging isang makabuluhang bottleneck sa hinaharap. Samakatuwid, mag-ingat at huwag palampasin ang sitwasyon kung kailan, sa isang transaksyon na tumatagal ng 3.5s, 2.5s ang ginugugol sa paghahanda at pagpirma ng transaksyon, at 1.0s sa pagpapadala nito sa network at paghihintay ng tugon. Upang masuri ang mga panganib ng bottleneck na ito, kailangan mong mangolekta ng mga sukatan mula sa mga makina ng kliyente, at hindi lamang mula sa mga blockchain node.

Pagpapadala ng isang transaksyon at pagsubaybay sa katayuan nito

Ang susunod na hakbang ay ipadala ang transaksyon sa napiling blockchain node at matanggap ang status ng pagtanggap nito sa transaction pool. Ang yugtong ito ay katulad ng isang regular na pag-access sa database; dapat itala ng node ang transaksyon sa pool at simulan ang pamamahagi ng impormasyon tungkol dito sa pamamagitan ng p2p network. Ang diskarte sa pagtatasa ng pagganap dito ay katulad ng pagtatasa sa pagganap ng mga tradisyonal na Web API microservice, at ang mga transaksyon mismo sa mga blockchain ay maaaring ma-update at aktibong baguhin ang kanilang katayuan. Sa pangkalahatan, ang pag-update ng impormasyon ng transaksyon sa ilang mga blockchain ay maaaring mangyari nang maraming beses, halimbawa kapag nagpalipat-lipat sa pagitan ng mga chain fork o kapag ang mga BP ay nagpahayag ng kanilang intensyon na magsama ng isang transaksyon sa isang bloke. Ang mga limitasyon sa laki ng pool na ito at ang bilang ng mga transaksyon dito ay maaaring makaapekto sa pagganap ng blockchain. Kung ang transaction pool ay napunan sa maximum na posibleng laki, o hindi kasya sa RAM, maaaring bumaba nang husto ang performance ng network. Ang mga blockchain ay walang sentralisadong paraan ng pagprotekta laban sa baha ng mga junk na mensahe, at kung sinusuportahan ng blockchain ang mataas na dami ng mga transaksyon at mababang bayad, maaari itong maging sanhi ng pag-apaw ng pool ng transaksyon—isa pang potensyal na bottleneck sa pagganap.

Sa mga blockchain, ang kliyente ay nagpapadala ng isang transaksyon sa anumang blockchain node na gusto niya, ang hash ng transaksyon ay karaniwang alam ng kliyente bago ipadala, kaya ang kailangan lang niyang gawin ay makamit ang koneksyon at, pagkatapos ng paghahatid, maghintay para sa blockchain na magbago estado nito, na nagpapagana sa kanyang transaksyon. Tandaan na sa pamamagitan ng pagsukat ng "tps" maaari kang makakuha ng ganap na magkakaibang mga resulta para sa iba't ibang paraan ng pagkonekta sa isang blockchain node. Ito ay maaaring isang regular na HTTP RPC o isang WebSocket na nagbibigay-daan sa iyong ipatupad ang pattern na "mag-subscribe". Sa pangalawang kaso, ang kliyente ay makakatanggap ng isang abiso nang mas maaga, at ang node ay gagastos ng mas kaunting mga mapagkukunan (pangunahin ang memorya at trapiko) sa mga tugon tungkol sa katayuan ng transaksyon. Kaya kapag sinusukat ang "tps" kinakailangang isaalang-alang ang paraan ng pagkonekta ng mga kliyente sa mga node. Samakatuwid, upang masuri ang mga panganib ng bottleneck na ito, ang benchmark na blockchain ay dapat na tularan ang mga kliyente na may parehong mga kahilingan sa WebSocket at HTTP RPC, sa mga proporsyon na naaayon sa mga tunay na network, pati na rin baguhin ang likas na katangian ng mga transaksyon at ang kanilang laki.

Upang masuri ang mga panganib ng bottleneck na ito, kailangan mo ring mangolekta ng mga sukatan mula sa mga makina ng kliyente, at hindi lamang mula sa mga blockchain node.

Pagpapadala ng mga transaksyon at block sa pamamagitan ng p2p network

Sa mga blockchain, ang peer-to-peer (p2p) networking ay ginagamit upang maglipat ng mga transaksyon at block sa pagitan ng mga kalahok. Kumalat ang mga transaksyon sa buong network, simula sa isa sa mga node, hanggang sa maabot nila ang mga producer ng peer block, na nag-pack ng mga transaksyon sa mga bloke at, gamit ang parehong p2p, namamahagi ng mga bagong block sa lahat ng node ng network. Ang batayan ng karamihan sa mga modernong p2p network ay iba't ibang mga pagbabago ng protocol ng Kademlia. Dito isang magandang buod ng protocol na ito, at dito - isang artikulo na may iba't ibang mga sukat sa network ng BitTorrent, kung saan mauunawaan ng isa na ang ganitong uri ng network ay mas kumplikado at hindi gaanong mahuhulaan kaysa sa isang mahigpit na na-configure na network ng isang sentralisadong serbisyo. Gayundin, dito artikulo tungkol sa pagsukat ng iba't ibang interesanteng sukatan para sa mga Ethereum node.

Sa madaling salita, ang bawat peer sa naturang mga network ay nagpapanatili ng sarili nitong dynamic na listahan ng iba pang mga peer kung saan humihiling ito ng mga bloke ng impormasyon na tinutugunan ng nilalaman. Kapag ang isang peer ay nakatanggap ng isang kahilingan, ito ay maaaring magbigay ng kinakailangang impormasyon o ipasa ang kahilingan sa susunod na pseudo-random na peer mula sa listahan, at pagkatanggap ng isang tugon, ito ay ipapasa sa humihiling at i-cache ito nang ilang sandali, na nagbibigay nito bloke ng impormasyon nang mas maaga sa susunod na pagkakataon. Kaya, ang sikat na impormasyon ay nagtatapos sa isang malaking bilang ng mga cache ng isang malaking bilang ng mga kapantay, at ang hindi sikat na impormasyon ay unti-unting pinapalitan. Ang mga kapantay ay nagtatago ng mga talaan kung sino ang naglipat ng kung gaano karaming impormasyon kung kanino, at sinusubukan ng network na pasiglahin ang mga aktibong distributor sa pamamagitan ng pagtaas ng kanilang mga rating at pagbibigay sa kanila ng mas mataas na antas ng serbisyo, na awtomatikong inialis ang mga hindi aktibong kalahok mula sa mga listahan ng peer.

Kaya, kailangan na ngayong ipamahagi ang transaksyon sa buong network para makita ito ng mga block-producer at isama ito sa block. Ang node ay aktibong "namamahagi" ng isang bagong transaksyon sa lahat at nakikinig sa network, naghihintay para sa isang bloke sa index kung saan lilitaw ang kinakailangang transaksyon upang maabisuhan ang naghihintay na kliyente. Ang oras na kinakailangan para sa network na maglipat ng impormasyon tungkol sa mga bagong transaksyon at mga bloke sa isa't isa sa mga p2p network ay nakasalalay sa napakalaking bilang ng mga kadahilanan: ang bilang ng mga matapat na node na nagtatrabaho sa malapit (mula sa punto ng view ng network), ang "warm- up” ng mga cache ng mga node na ito, ang laki ng mga bloke, mga transaksyon, ang likas na katangian ng mga pagbabago , heograpiya ng network, bilang ng mga node at marami pang ibang salik. Ang mga kumplikadong sukat ng mga sukatan ng pagganap sa naturang mga network ay isang kumplikadong bagay; kinakailangan na sabay na suriin ang oras ng pagproseso ng kahilingan sa parehong mga kliyente at mga kapantay (blockchain node). Ang mga problema sa alinman sa mga mekanismo ng p2p, hindi tamang pagtanggal ng data at pag-cache, hindi epektibong pamamahala ng mga listahan ng mga aktibong kasamahan, at marami pang ibang salik ay maaaring magdulot ng mga pagkaantala na makakaapekto sa kahusayan ng buong network sa kabuuan, at ang bottleneck na ito ang pinakamahirap na pag-aralan , pagsubok at interpretasyon ng mga resulta.

Pagproseso ng Blockchain at pag-update ng database ng estado

Ang pinakamahalagang bahagi ng blockchain ay ang consensus algorithm, ang aplikasyon nito sa mga bagong bloke na natanggap mula sa network at ang pagproseso ng mga transaksyon na may pagtatala ng mga resulta sa database ng estado. Ang pagdaragdag ng bagong bloke sa chain at pagkatapos ay ang pagpili sa pangunahing chain ay dapat gumana nang mabilis hangga't maaari. Gayunpaman, sa totoong buhay, ang "dapat" ay hindi nangangahulugang "gumagana", at maaari, halimbawa, isipin ng isang tao ang isang sitwasyon kung saan ang dalawang mahabang nakikipagkumpitensya na chain ay patuloy na nagpapalipat-lipat sa kanilang mga sarili, binabago ang metadata ng libu-libong mga transaksyon sa pool sa bawat switch , at patuloy na ibinabalik ang database ng estado. Ang yugtong ito, sa mga tuntunin ng pagtukoy sa bottleneck, ay mas simple kaysa sa layer ng p2p network, dahil ang pagpapatupad ng transaksyon at consensus algorithm ay mahigpit na deterministiko, at mas madaling sukatin ang anuman dito.
Ang pangunahing bagay ay hindi malito ang random na pagkasira sa pagganap ng yugtong ito na may mga problema sa network - ang mga node ay mas mabagal sa paghahatid ng mga bloke at impormasyon tungkol sa pangunahing kadena, at para sa isang panlabas na kliyente ito ay maaaring magmukhang isang mabagal na network, kahit na ang problema ay nakasalalay sa ibang lugar.

Upang ma-optimize ang pagganap sa yugtong ito, kapaki-pakinabang na kolektahin at subaybayan ang mga sukatan mula sa mga node mismo, at isama sa kanila ang mga nauugnay sa pag-update ng state-database: ang bilang ng mga bloke na naproseso sa node, ang kanilang laki, ang bilang ng mga transaksyon, ang bilang ng mga switch sa pagitan ng mga chain fork, ang bilang ng mga di-wastong bloke , oras ng pagpapatakbo ng virtual machine, oras ng pag-commit ng data, atbp. Pipigilan nito ang mga problema sa network na malito sa mga error sa mga algorithm sa pagproseso ng chain.

Ang mga transaksyon sa pagpoproseso ng virtual machine ay maaaring maging isang kapaki-pakinabang na mapagkukunan ng impormasyon na maaaring mag-optimize ng operasyon ng blockchain. Ang bilang ng mga paglalaan ng memorya, ang bilang ng mga tagubilin sa pagbasa/pagsusulat, at iba pang mga sukatan na nauugnay sa kahusayan ng pagpapatupad ng code ng kontrata ay maaaring magbigay ng maraming kapaki-pakinabang na impormasyon sa mga developer. Kasabay nito, ang mga matalinong kontrata ay mga programa, na nangangahulugan sa teorya na maaari nilang ubusin ang alinman sa mga mapagkukunan: cpu/memory/network/storage, kaya ang pagpoproseso ng transaksyon ay isang medyo hindi tiyak na yugto, na, bilang karagdagan, ay nagbabago nang malaki kapag lumilipat sa pagitan ng mga bersyon at kapag nagpapalit ng mga code ng kontrata. Samakatuwid, ang mga sukatan na nauugnay sa pagpoproseso ng transaksyon ay kailangan din upang epektibong ma-optimize ang pagganap ng blockchain.

Resibo ng kliyente ng isang abiso tungkol sa pagsasama ng isang transaksyon sa blockchain

Ito ang huling yugto ng kliyente ng blockchain na tumatanggap ng serbisyo; kumpara sa iba pang mga yugto, walang malalaking gastos sa overhead, ngunit sulit pa ring isaalang-alang ang posibilidad ng kliyente na makatanggap ng isang malaking tugon mula sa node (halimbawa, isang matalinong kontrata nagbabalik ng hanay ng data). Sa anumang kaso, ang puntong ito ang pinakamahalaga para sa nagtanong ng tanong na "ilang tps ang nasa iyong blockchain?", dahil Sa sandaling ito, ang oras ng pagtanggap ng serbisyo ay naitala.

Sa lugar na ito, palaging may pagpapadala ng buong oras na kailangang gugulin ng kliyente sa paghihintay ng tugon mula sa blockchain; sa pagkakataong ito na maghihintay ang user para sa kumpirmasyon sa kanyang aplikasyon, at ang pag-optimize nito ay ang pangunahing gawain ng mga developer.

Konklusyon

Bilang resulta, maaari naming ilarawan ang mga uri ng mga operasyon na isinagawa sa mga blockchain at hatiin ang mga ito sa ilang mga kategorya:

cryptographic transformations, patunay na konstruksyon
peer-to-peer networking, transaksyon at block replication
pagproseso ng transaksyon, pagpapatupad ng mga matalinong kontrata
paglalapat ng mga pagbabago sa blockchain sa database ng estado, pag-update ng data sa mga transaksyon at block
read-only na mga kahilingan sa state database, blockchain node API, mga serbisyo sa subscription

Sa pangkalahatan, ang mga teknikal na kinakailangan para sa mga modernong blockchain node ay napakaseryoso - mabilis na mga CPU para sa cryptography, isang malaking halaga ng RAM upang maiimbak at mabilis na ma-access ang database ng estado, pakikipag-ugnayan sa network gamit ang isang malaking bilang ng mga sabay-sabay na bukas na koneksyon, at malaking imbakan. Ang ganitong mataas na mga kinakailangan at ang kasaganaan ng iba't ibang uri ng mga operasyon ay hindi maaaring hindi humahantong sa katotohanan na ang mga node ay maaaring walang sapat na mapagkukunan, at pagkatapos ay alinman sa mga yugto na tinalakay sa itaas ay maaaring maging isa pang bottleneck para sa pangkalahatang pagganap ng network.

Kapag nagdidisenyo at nagsusuri ng pagganap ng mga blockchain, kailangan mong isaalang-alang ang lahat ng mga puntong ito. Upang gawin ito, kailangan mong kolektahin at pag-aralan ang mga sukatan nang sabay-sabay mula sa mga kliyente at mga node ng network, hanapin ang mga ugnayan sa pagitan nila, tantiyahin ang oras na kinakailangan upang magbigay ng mga serbisyo sa mga kliyente, isaalang-alang ang lahat ng pangunahing mapagkukunan: cpu/memory/network/storage , unawain kung paano ginagamit ang mga ito at naiimpluwensyahan ang isa't isa. Ang lahat ng ito ay gumagawa ng paghahambing ng mga bilis ng iba't ibang mga blockchain sa anyo ng "kung gaano karaming TPS" ang isang labis na walang pasasalamat na gawain, dahil mayroong isang malaking bilang ng iba't ibang mga pagsasaayos at estado. Sa malalaking sentralisadong sistema, mga kumpol ng daan-daang mga server, ang mga problemang ito ay kumplikado din at nangangailangan din ng koleksyon ng isang malaking bilang ng iba't ibang sukatan, ngunit sa mga blockchain, dahil sa mga p2p network, mga virtual machine na nagpoproseso ng mga kontrata, panloob na ekonomiya, ang bilang ng mga degree. ng kalayaan ay mas malaki, na ginagawa ang pagsubok kahit na sa ilang mga server, ito ay hindi nagpapahiwatig at nagpapakita lamang ng labis na tinatayang mga halaga na halos walang koneksyon sa katotohanan.

Samakatuwid, kapag bumubuo sa core ng blockchain, upang suriin ang pagganap at sagutin ang tanong na "bumuti ba ito kumpara sa huling oras?" Gumagamit kami ng medyo kumplikadong software na nag-oorchestrate sa paglulunsad ng isang blockchain na may dose-dosenang mga node at awtomatikong naglulunsad ng isang benchmark at nangongolekta ng mga sukatan. ; kung wala ang impormasyong ito, napakahirap i-debug ang mga protocol na gumagana sa maraming kalahok.

Kaya, kapag natanggap mo ang tanong na "ilang TPS ang nasa iyong blockchain?", ialok ang iyong kausap ng ilang tsaa at tanungin kung handa na ba siyang tumingin sa isang dosenang mga graph at makinig din sa lahat ng tatlong mga kahon ng mga problema sa pagganap ng blockchain at ang iyong mga mungkahi para sa paglutas sa kanila...

Pinagmulan: www.habr.com

Ilang TPS ang nasa iyong blockchain?