{"id":36157,"date":"2019-10-31T22:09:55","date_gmt":"2019-10-31T19:09:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/skolko-tps-v-vashem-blokchejne\/"},"modified":"2019-10-31T22:09:55","modified_gmt":"2019-10-31T19:09:55","slug":"skolko-tps-v-vashem-blokchejne","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","title":{"rendered":"Kui palju TPS on teie plokiahelas?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

K\u00fcsimus, mis sageli tekib mis tahes hajutatud s\u00fcsteemi kohta mitte-tehnilise spetsialisti poolt, on \"Kui palju tps on teie plokiahelas?\" Ent vastuseks antud number ei haaku tavaliselt sellega, mida k\u00fcsija tegelikult kuulda tahaks. Tegelikult soovis ta k\u00fcsida: \"Kas teie plokiahel vastab minu ettev\u00f5tte n\u00f5uetele?\" Need n\u00f5udmised ei piirdu \u00fche numbriga, vaid koosnevad mitmest tingimusest \u2013 sealhulgas v\u00f5rgu talitlush\u00e4iretest, l\u00f5plikkuse n\u00f5uetest, tehingute suurusest, iseloomust ja paljusid teisi parameetreid. Seet\u00f5ttu on vastus k\u00fcsimusele \"kui palju tps\" harva lihtne ning peaaegu kunagi mitte ammendav. Hajutatud s\u00fcsteem, kus on k\u00fcmneid ja sadu s\u00f5lmi, mis teevad \u00fcsna keerulisi arvutusi, v\u00f5ib olla tohutul hulgal erinevates seisundites, mis on seotud v\u00f5rgu olukorra, plokiahela sisuga, tehniliste riketega, majanduslike probleemidega, r\u00fcnnakutega v\u00f5rgu vastu ja paljude muude p\u00f5hjustega. Etapid, mille jooksul v\u00f5ivad tekkida j\u00f5udlusprobleemid, erinevad traditsioonilistest teenustest, ning plokiahela v\u00f5rgu server on v\u00f5rgu teenus, mis \u00fchendab endas andmebaasi, veebi serveri ja torrent-klientide funktsioone, mist\u00f5ttu on sellel \u00e4\u00e4rmiselt keeruline koormuse profiil k\u00f5igis alams\u00fcsteemides: protsessor, m\u00e4lu, v\u00f5rk, salvestus.<\/p>\n

<\/p>\n

Nii juhtus, et detsentraliseeritud v\u00f5rgud ja plokiahelad on arendajatele, kes t\u00f6\u00f6tavad tsentraliseeritud tarkvaraga, t\u00f5eliselt spetsiifiline ja ebatavaline tarkvara. Seet\u00f5ttu sooviksin k\u00e4sitleda detsentraliseeritud v\u00f5rkude j\u00f5udluse ja vastupidavuse olulisi aspekte, l\u00e4henemisviise nende m\u00f5\u00f5tmiseks ja kitsaskohtade leidmiseks. Vaatame erinevaid j\u00f5udluse probleeme, mis piiravad plokiahelate teenuse pakkumise kiirus, ning m\u00e4rkime \u00e4ra selle tarkvarat\u00fc\u00fcbi omadused.<\/p>\n

<\/a><\/noindex><\/p>\n

Plokiahela kliendi teenuse taotlemise etapid<\/h2>\n

<\/p>\n

Ette ma oleksin aus r\u00e4\u00e4kida \u00fchegi rohkem-v\u00e4hem keeruka teenuse kvaliteedist, tuleb arvesse v\u00f5tta mitte ainult keskmisi v\u00e4\u00e4rtusi, vaid ka maksimaalseid\/minimaalseid, mediaane ja persentiile. Teoreetiliselt v\u00f5ib r\u00e4\u00e4kida 1000 tps mistahes plokiahela puhul, kuid kui 900 tehingut viidi l\u00e4bi erakordselt kiiresti, samas kui 100 tehingut \"j\u00e4\u00e4gid\" paariks sekundiks kinni, siis keskmine aeg, mis koguti k\u00f5igi tehingute osas, ei ole just k\u00f5ige ausam metrika kliendi jaoks, kes ei suutnud m\u00f5ne sekundi jooksul tehingut l\u00f5petada. Aja \"augud\", mis on p\u00f5hjustatud konsensuse voorude vahelt j\u00e4\u00e4misest v\u00f5i v\u00f5rgu jagunemisest, v\u00f5ivad t\u00f5siselt kahjustada teenust, mis testimistel n\u00e4itas suurep\u00e4raseid tulemusi.<\/p>\n

<\/p>\n

Selliste pudelikaelte tuvastamiseks on vajalik h\u00e4sti m\u00f5ista etappe, mille jooksul v\u00f5ib t\u00f5eline blockchain kasutajate teenindamisel raskusi kogeda. Kirjeldame tehingu tarnimise ja t\u00f6\u00f6tlemise ts\u00fcklit, samuti uue blockchaini oleku saamist, mille p\u00f5hjal klient saab veenduda, et tema tehing on t\u00f6\u00f6deldud ja arvesse v\u00f5etud.<\/p>\n

<\/p>\n

    \n
  1. tehingu vormistamine kliendis<\/li>\n
  2. tehingu allkirjastamine kliendis<\/li>\n
  3. klient valib \u00fche s\u00f5lme ja saadab sinna oma tehingu<\/li>\n
  4. klient tellib s\u00f5lme oleku andmebaasi uuendusi, oodates oma tehingu t\u00e4itmise tulemusi<\/li>\n
  5. s\u00f5lm levitab tehingu p2p v\u00f5rgus<\/li>\n
  6. mitmed v\u00f5i \u00fcks BP (block producer) t\u00f6\u00f6tlevad kogunenud tehingud, uuendades oleku andmebaasi<\/li>\n
  7. BP vormib uue bloki, t\u00f6\u00f6tledes vajaliku arvu tehinguid<\/li>\n
  8. BP levitab uue bloki p2p v\u00f5rgus<\/li>\n
  9. uus blokk toimetatakse s\u00f5lmeni, mille poole klient p\u00f6\u00f6rdub<\/li>\n
  10. s\u00f5lm uuendab oleku andmebaasi<\/li>\n
  11. s\u00f5lm n\u00e4eb kliendiga seotud uuendusi ja saadab talle tehingu teate<\/li>\n<\/ol>\n

    <\/p>\n

    N\u00fc\u00fcd vaatame l\u00e4hemalt neid etappe ja kirjeldame iga etapi v\u00f5imalikke j\u00f5udlusprobleeme. Erinevalt tsentraliseeritud s\u00fcsteemidest k\u00e4sitleme ka koodi t\u00e4itmist v\u00f5rgu klientide poolel. Suhteliselt tihti, kui m\u00f5\u00f5detakse tps-i, kogutakse tehingute t\u00f6\u00f6tlemise aega node'itelt, mitte kliendilt \u2014 see ei ole t\u00e4iesti aus. Kliendile ei puutu see kuigi palju, kui kiiresti node t\u00f6\u00f6tles tema tehingut; k\u00f5ige olulisem on, millal usaldusv\u00e4\u00e4rne teave k\u00f5nealuse tehingu kohta, mis on lisatud plokiahelasse, temani j\u00f5uab. Just see m\u00f5\u00f5dik on tegelikult tehingu t\u00e4itmise aeg. See t\u00e4hendab, et erinevad kliendid, isegi saates sama tehingu, v\u00f5ivad saada t\u00e4iesti erinevaid aegu, mis s\u00f5ltuvad kanalist, koormatusest ja node'i l\u00e4hedusest jne. Seet\u00f5ttu on t\u00e4iesti h\u00e4davajalik m\u00f5\u00f5ta seda aega klientide peal, kuna just seda parameetrit tuleb optimeerida.<\/p>\n

    <\/p>\n

    Tehingu ettevalmistamine kliendi poolel<\/h2>\n

    <\/p>\n

    Alustame kahest esimesest punktist: tehingu koostamine ja allkirjastamine kliendi poolt. Kuigi see v\u00f5ib tunduda ootamatuna, v\u00f5ib see samuti olla plokiahela j\u00f5udluse kitsaskohaks kliendi vaatepunktist. See on harjumatu tsentraliseeritud teenuste jaoks, kus k\u00f5ik arvutused ja andmete t\u00f6\u00f6tlemine j\u00e4\u00e4vad neile, ning klient valmistab lihtsalt l\u00fchikese p\u00e4ringu, mis suudab k\u00fcsida suurt hulka andmeid v\u00f5i arvutusi, saades valmis tulemuse. Plokiahelates muutub kliendi kood \u00fcha v\u00f5imsamaks, samas kui plokiahela tuum muutub \u00fcha kergemaks, ning massiivsed arvutus\u00fclesanded antakse tavaliselt kliendi tarkvara k\u00e4tte. Plokiahelates on kliente, kes v\u00f5ivad \u00fche tehingu ettevalmistamisega aega kulutada (r\u00e4\u00e4gin erinevatest merkle'i t\u00f5enditest, kokkuv\u00f5tlikest t\u00f5enditest, k\u00fcnnise allkirjadest ja muudest keerukatest toimingutest kliendi poolel). Hea n\u00e4ide kerge on-chain verifitseerimise ja raskete tehingute ettevalmistamise kohta kliendi poolel on t\u00f5end kuuluvusest loendisse, mis p\u00f5hineb Merkle-puus. artikkel<\/a><\/noindex>.<\/p>\n

    <\/p>\n

    \u00c4rge unustage, et kliendi kood ei saada lihtsalt tehinguid plokiahelasse, vaid k\u00f5igepealt k\u00fcsib plokiahela olekut \u2014 see tegevus v\u00f5ib m\u00f5jutada v\u00f5rgu koormust ja plokiahela node'e. Seet\u00f5ttu on m\u00f5istlik emuleerida kliendi koodi k\u00e4itumist nii t\u00e4ielikult kui v\u00f5imalik, kui teete m\u00f5\u00f5tmisi. Isegi kui teie plokiahelas on tavalised kerged kliendid, kes teevad tavalisi digitaalallkirju lihtsate tehingute jaoks, n\u00e4iteks varade \u00fclekandmiseks, suureneb iga aastaga arvutuste hulk kliendi poolel, kr\u00fcptograafilised algoritmid muutuvad tugevamaks ja see t\u00f6\u00f6tlemise osa v\u00f5ib muutuda tulevikus m\u00e4rkimisv\u00e4\u00e4rseks kitsaskohaks. Seet\u00f5ttu olge ettevaatlik, et mitte m\u00f6\u00f6da lasta olukorrast, kus 3,5-sekundilise tehingu jooksul kulub 2,5 sekundit tehingu ettevalmistamiseks ja allkirjastamiseks ning 1,0 sekundit saatmiseks v\u00f5rku ja vastuse ootamiseks. Selle kitsaskoha riski hindamiseks tuleb koguda m\u00f5\u00f5dikud kliendimasinatelt, mitte ainult plokiahela node'delt.<\/p>\n

    <\/p>\n

    Tehingu saatmine ja selle staatuse j\u00e4lgimine<\/h2>\n

    <\/p>\n

    J\u00e4rgmine etapp on tehingu saatmine valitud plokiahela node'isse ja selle staatuse saamine tehingute \u00fcleslaadimise kohal. See etapp sarnaneb tavalise andmebaasi p\u00e4rimisega, node peab tehingu \u00fcles kirjutama ja hakkama seda teavet levitama p2p-v\u00f5rgus. L\u00e4henemine siin oleva j\u00f5udluse hindamisel on sarnane traditsiooniliste mikroteenuste Web API hindamisele, kusjuures plokiahelates v\u00f5ivad iseeneslikud tehingud uuenduda ja aktiivselt oma staatust muuta. \u00dcldiselt v\u00f5ib tehingu teabe uuendamine m\u00f5nes plokiahelas toimuda mitu korda, n\u00e4iteks kettaahjude vahetamise korral v\u00f5i kui BP teavitavad plokiahela soovist tehingut plokki lisada. Selle tehingute hulga ja arvu piirangud v\u00f5ivad m\u00f5jutada plokiahela j\u00f5udlust. Kui tehingute hulk on t\u00e4idetud maksimaalse lubatud suurusega v\u00f5i ei mahu operatiivm\u00e4lu sisse, v\u00f5ib v\u00f5rgu j\u00f5udlus j\u00e4rsult langeda. Plokiahelad ei oma tsentraliseeritud kaitsemehhanisme pr\u00fcgis\u00f5numite voo vastu ning kui plokiahel toetab suure mahuga tehinguid ja madalaid tasusid, v\u00f5ib see p\u00f5hjustada tehingute hulga \u00fclekoormuse \u2014 see on veel \u00fcks potentsiaalne j\u00f5udluse kitsaskoht.<\/p>\n

    <\/p>\n

    Plokiahelates saadab klient tehingu igasse talle meelep\u00e4rasesse plokiahela s\u00f5lme, tehingu hash on tavaliselt kliendile teada juba enne saatmist, nii et k\u00f5ik, mida ta vajab, on saavutada \u00fchendus ja p\u00e4rast edastamist ootab ta, kuni plokiahel muudab oma seisundit, lisades tema tehingu. Tuleb m\u00e4rkida, et m\u00f5\u00f5tes \"tps\" v\u00f5ib saada t\u00e4iesti erinevaid tulemusi s\u00f5ltuvalt viisil, millega s\u00f5lmega \u00fchendust saada. See v\u00f5ib olla tavap\u00e4rane HTTP RPC v\u00f5i WebSocket, mis v\u00f5imaldab rakendada \"subscribe\" mustrit. Teises variandis saab klient teavituse varem ja s\u00f5lm kasutab v\u00e4hem ressursse (peamiselt m\u00e4lu ja liiklust) tehingu oleku vastamiseks. Seet\u00f5ttu on oluline m\u00f5\u00f5tes \"tps\" arvesse v\u00f5tta klientide \u00fchendust s\u00f5lmedega. Seega, et hinnata selle kitsaskoha tekke riske, peab plokiahela benchmark suutma emuleerida kliente nii WebSocketi kui ka HTTP RPC p\u00e4ringutega, proportsioonides, mis vastavad tegelikele v\u00f5rkudele, ning samuti muutma tehingute iseloomu ja nende suurust.<\/p>\n

    <\/p>\n

    Selle bottleneck'i tekke riskide hindamiseks tuleb koguda m\u00f5\u00f5dikud ka kliendi masinatelt, mitte ainult plokk-ahela s\u00f5lmedelt.<\/p>\n

    <\/p>\n

    Tehingute ja plokkide edastamine p2p-v\u00f5rgus<\/h2>\n

    <\/p>\n

    Plokk-ahelates kasutatakse osalejate vahel tehingute ja plokkide edastamiseks peer-to-peer (p2p) v\u00f5rkude. Tehingud levivad v\u00f5rgus, alustades \u00fchest s\u00f5lmest, kuni need j\u00f5uavad peer'ide-blokki tootjate juurde, kes pakivad tehingud plokkidesse ja levitavad uusi plokke k\u00f5igile v\u00f5rgus olevatele s\u00f5lmedele sama p2p kaudu. Enamikule t\u00e4nap\u00e4eva p2p v\u00f5rkudele tuginevad erinevad Kademlia protokolli modifikatsioonid. Siin<\/a><\/noindex> hea l\u00fchike \u00fclevaade sellest protokollist, ja siin on<\/a><\/noindex> \u2014 artikkel erinevate m\u00f5\u00f5tmiste kohta BitTorreni v\u00f5rgus, millest v\u00f5ib aru saada \u2014 et see t\u00fc\u00fcp v\u00f5rke on keerulisem ja v\u00e4hem ettearvatav kui rangelt seadistatud keskse teenuse v\u00f5rk. Samuti, siin on<\/a><\/noindex> artikkel erinevate huvitavate m\u00f5\u00f5dikute m\u00f5\u00f5tmisest Ethereum'i s\u00f5lmedes.<\/p>\n

    <\/p>\n

    Kokkuv\u00f5ttes toetab iga peer sellistes v\u00f5rkudes oma d\u00fcnaamilist nimekirja teistest peer-idest, kellelt ta p\u00e4rib teabeplokke, mis on adresseeritud sisu j\u00e4rgi. Kui peer saab p\u00e4ringu, annab ta kas vajaliku teabe edasi v\u00f5i edastab p\u00e4ringu j\u00e4rgmisele pseudojuhuslikule peer-ile nimekirjast ja, kui vastus on saadud, edastab selle p\u00e4rijale ning salvestab selle m\u00f5neks ajaks vahem\u00e4llu, edastades selle teabeploki j\u00e4rgmine kord varem. Nii satub populaarne teave mitmesse vahem\u00e4llu paljude peer-ide juurde, samas kui ebasoodsat teavet t\u00f5rjutakse j\u00e4rk-j\u00e4rgult. Peer-id j\u00e4lgivad, kes kellele kui palju teavet edastas, ning v\u00f5rk p\u00fc\u00fcab aktiveerida aktiivseid levitajaid, t\u00f5stes nende reitingut ja pakkudes neile k\u00f5rgemat teenindustaset, eemaldades automaatselt mitteaktiivseid osalejaid peer-ide nimekirjadest.<\/p>\n

    <\/p>\n

    N\u00fc\u00fcd tuleb tehing levitada v\u00f5rgus, et seda n\u00e4eksid block-producer'id ja see lisataks blokki. Node jagab aktiivselt uut tehingut k\u00f5igile soovijatele ja kuulab v\u00f5rgus, oodates blokki, mille indeksis ilmub vajalik tehing, et teavitada ootavat klienti. Aeg, mille jooksul v\u00f5rk edastab teavet uute tehingute ja blokki kohta p2p v\u00f5rkudes, s\u00f5ltub v\u00e4ga paljusid teguritest: ausate ja t\u00f6\u00f6tavate nodide hulgast (v\u00f5rgu seisukohalt), nende nodide vahem\u00e4lu \u201csoojendusest\u201d, blokkide ja tehingute suurusest, muudatuste iseloomust, v\u00f5rgu geograafiast, nodide arvust ja paljusid teisi tegureid. Komplekssete j\u00f5udlusmeetmete m\u00f5\u00f5tmine sellistes v\u00f5rkudes on keeruline, kuna tuleb samaaegselt hinnata p\u00e4ringute t\u00f6\u00f6tlemise aega nii klientide kui peer'ite (blockchain nodide) peal. Probleemid mistahes p2p mehhanismides, vale andmete v\u00e4ljav\u00f5tmine ja vahem\u00e4lud, ebaefektiivne aktiivsete peer'ide haldamine ja paljud teised tegurid v\u00f5ivad p\u00f5hjustada viivitusi, mis m\u00f5jutavad kogu v\u00f5rgu t\u00f5husust, ning see kitsaskoht on k\u00f5ige keerulisem anal\u00fc\u00fcsimiseks, testimiseks ja tulemuste t\u00f5lgendamiseks.<\/p>\n

    <\/p>\n

    Ploki ahela t\u00f6\u00f6tlemine ja oleku andmebaasi v\u00e4rskendamine<\/h2>\n

    <\/p>\n

    Bloki ahela k\u00f5ige olulisem osa on konsensuse algoritm, selle rakendamine uutega, mis on saadud v\u00f5rgu blokki ja tehingute t\u00f6\u00f6tlemine, salvestades tulemused state andmebaasi. Uue bloki lisamine ahelasse ja sellele j\u00e4rgnev p\u00f5hita ahela valimine peab toimuma v\u00f5imalikult kiiresti. Siiski, reaalses elus ei t\u00e4henda \"peab\" alati, et \"t\u00f6\u00f6tab\", ja n\u00e4iteks v\u00f5ib ette kujutada olukorda, kus kaks pikka konkureerivat ahelat vahetavad pidevalt omavahel, muutes tuhandete tehingute metainfot igas vahetuses ja tekitades pidevat tagasiviimist state andmebaasi olekusse. See etapp on bottleneck'i m\u00e4\u00e4ramisel lihtsam kui v\u00f5rgu p2p kiht, kuna tehingute teostamine ja konsensuse algoritm on rangelt m\u00e4\u00e4ratletud, ning siin on midagi m\u00f5\u00f5ta kergem.
    \nPeamine on mitte segi ajada selle etapi juhuslikku j\u00f5udluse halvenemist v\u00f5rguprobleemidega \u2014 s\u00f5lmed jagavad bloke ja peamise ahela teavet aeglasemalt ning v\u00e4liskliendi jaoks v\u00f5ib see tunduda kui aeglane v\u00f5rgu\u00fchendus, kuigi probleem on hoopis mujal.<\/p>\n

    <\/p>\n

    Perfektsuse optimeerimiseks on selle etapi puhul kasulik koguda ja j\u00e4lgida metrikat otse s\u00f5lmedest, ning h\u00f5lmata ka neid, mis puudutavad state-database'i uuendamist: plokkide arv, mida s\u00f5lm t\u00f6\u00f6tleb, nende suurus, tehingute arv, vahetuste arv ahela forkide vahel, valeplokkide arv, virtuaalse masina t\u00f6\u00f6aeg, andmete fikseerimise aeg jne. See aitab eristada v\u00f5rguprobleeme protsessimise algoritmide vigadest.<\/p>\n

    <\/p>\n

    Tehingute t\u00f6\u00f6tlev virtuaalne masin v\u00f5ib olla kasulik teabeallikas, mis suudab optimeerida blokeina t\u00f6\u00f6d. M\u00e4lu eraldamise arv, read\/write juhiste arv ja muud metrikad, mis puudutavad lepingute koodi t\u00e4itmise efektiivsust, v\u00f5ivad anda arendajatele palju kasulikku teavet. Samas, nutilepingud on programmid, mis t\u00e4hendavad, et nad v\u00f5ivad teoorias kasutama k\u00f5iki ressursse: cpu\/m\u00e4lu\/v\u00f5rk\/salvestus, seega on tehingute t\u00f6\u00f6tlemine \u00fcsna m\u00e4\u00e4ramatu etapp, mis muutub oluliselt versioonide vahel ning lepingute koodi muutmisel. Seet\u00f5ttu on metrikad, mis k\u00e4sitlevad tehingute t\u00f6\u00f6tlemist, samuti vajalikud blokeina j\u00f5udluse efektiivseks optimeerimiseks.<\/p>\n

    <\/p>\n

    Kliendi teavitamine tehingu aktiveerimisest plokiahelas<\/h2>\n

    <\/p>\n

    See the final stage of service acquisition for the blockchain by clients. Compared to other stages, there are no significant overheads here, but it is still worth considering the possibility of the client receiving a large response from the node (for example, a smart contract returning an array of data). In any case, this moment is the most important for anyone who asks, 'what is the TPS in your blockchain?', as it is at this moment that the service's response time is recorded. <\/p>\n

    <\/p>\n

    Siin on h\u00e4davajalik edastada kogu aeg, mida klient pidi ootama plokiahelt vastust, just seda aega ootab kasutaja oma rakenduses kinnitust ning selle optimeerimine on arendajate peamine \u00fclesanne.<\/p>\n

    <\/p>\n

    Kokkuv\u00f5te<\/h1>\n

    <\/p>\n

    Tulemuseks on v\u00f5imalik kirjeldada plokiahelates toimuvaid tehingute t\u00fc\u00fcpe ja jagada need mitmesse kategooriasse:<\/p>\n

    <\/p>\n

      \n
    1. kr\u00fcptograafilised muundamisprotsessid, t\u00f5endite koostamine<\/li>\n
    2. peer-to-peer v\u00f5rgustik, tehingute ja plokkide replikatsioon<\/li>\n
    3. tehingute t\u00f6\u00f6tlemine, nutilepingute t\u00e4itmine<\/li>\n
    4. muudatuste rakendamine plokiahelas state database-le, tehingute ja plokkide andmete uuendamine<\/li>\n
    5. ainult lugemise p\u00e4ringud state database-le, plokiahela nodi API, tellimiste teenused <\/li>\n<\/ol>\n

      <\/p>\n

      Tegelikult on kaasaegsete plokiahela nodide tehnilised n\u00f5uded \u00e4\u00e4rmiselt ranged \u2014 vajalikud on kiired CPU-d kr\u00fcptograafia jaoks, suur hulk operatiivm\u00e4lu andmete salvestamiseks ja kiireks ligip\u00e4\u00e4suks state database-le, v\u00f5rgu\u00fchendus, mis kasutab suurt hulka samaaegselt avatud \u00fchendusi, mahukas salvestusruum. Need k\u00f5rged n\u00f5uded ja erinevate tehingut\u00fc\u00fcpide rohkus toovad paratamatult kaasa, et nodi ressursid v\u00f5ivad osutuda ebapiisavaks ning sel juhul v\u00f5ib mis tahes eespool arutletud etapp muutuda koguv\u00f5rgu \u00fcldise j\u00f5udluse kitsaskohaks.<\/p>\n

      <\/p>\n

      When developing and evaluating the performance of blockchains, you will have to take all these factors into account. It is necessary to gather and analyze metrics simultaneously from both clients and the network nodes, look for correlations between them, assess the response time for clients, and consider all the main resources: CPU\/memory\/network\/storage, understanding how they are used and influence each other. All of this makes comparing the speeds of various blockchains in terms of 'how many TPS' a very thankless task, as there are a multitude of different configurations and states. In large centralized systems, clusters of hundreds of servers, these problems are also complex and require the collection of numerous different metrics. However, in blockchains, due to P2P networks, virtual machines processing contracts, and internal economies, the number of degrees of freedom is much larger, which makes testing even on several servers unrepresentative and showing only very approximate values, which have almost no connection to reality.<\/p>\n

      <\/p>\n

      Therefore, when developing in the core of the blockchain, to assess performance and answer the question 'has it improved compared to the last time', we use rather complex software that orchestrates the blockchain launch with dozens of nodes and automatically runs benchmarks and collects metrics. Without this information, it is extremely difficult to debug protocols operating with many participants.<\/p>\n

      <\/p>\n

      So, when asked 'what is the TPS in your blockchain?', offer your interlocutor some tea and clarify if they are ready to review a dozen graphs as well as hear all three boxes of the performance issues of blockchains and your suggestions for solving them...<\/p>\n

      Allikas: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

      \u041b\u044e\u0431\u0438\u043c\u044b\u043c \u0432\u043e\u043f\u0440\u043e\u0441\u043e\u043c \u043e \u043b\u044e\u0431\u043e\u0439 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 \u043e\u0442 \u043d\u0435\u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u0430 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u201c\u0421\u043a\u043e\u043b\u044c\u043a\u043e tps \u0432 \u0432\u0430\u0448\u0435\u043c \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0435?\u201d. \u041e\u0434\u043d\u0430\u043a\u043e, \u043d\u0430\u0437\u0432\u0430\u043d\u043d\u043e\u0435 \u0432 \u043e\u0442\u0432\u0435\u0442 \u0447\u0438\u0441\u043b\u043e \u043e\u0431\u044b\u0447\u043d\u043e \u0438\u043c\u0435\u0435\u0442 \u043c\u0430\u043b\u043e \u043e\u0431\u0449\u0435\u0433\u043e \u0441 \u0442\u0435\u043c, \u0447\u0442\u043e \u0445\u043e\u0442\u0435\u043b \u0431\u044b \u0443\u0441\u043b\u044b\u0448\u0430\u0442\u044c \u0432\u043e\u043f\u0440\u043e\u0448\u0430\u044e\u0449\u0438\u0439. \u041d\u0430 \u0434\u0435\u043b\u0435, \u043e\u043d \u0445\u043e\u0442\u0435\u043b \u0441\u043f\u0440\u043e\u0441\u0438\u0442\u044c \u201c\u043f\u043e\u0434\u043e\u0439\u0434\u0435\u0442 \u043b\u0438 \u0432\u0430\u0448 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d \u043f\u043e\u0434 \u043c\u043e\u0438 \u0431\u0438\u0437\u043d\u0435\u0441 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f\u201d, \u0438 \u044d\u0442\u0438 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f \u2014 \u044d\u0442\u043e \u043d\u0435 \u043e\u0434\u043d\u043e \u0447\u0438\u0441\u043b\u043e, \u0430 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0443\u0441\u043b\u043e\u0432\u0438\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36157","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Kui palju TPS on teie plokiahelas? | ProHoster","description":"Iga jaotatud s\u00fcsteemi puhul, mida k\u00fcsib mittekitsike spetsialist, on lemmik k\u00fcsimus \"Kui palju TPS teie plokiahelas on?\"","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u043a\u043e\u043b\u044c\u043a\u043e TPS \u0432 \u0432\u0430\u0448\u0435\u043c \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0435? | ProHoster","og:description":"\u041b\u044e\u0431\u0438\u043c\u044b\u043c \u0432\u043e\u043f\u0440\u043e\u0441\u043e\u043c \u043e \u043b\u044e\u0431\u043e\u0439 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 \u043e\u0442 \u043d\u0435\u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u0430 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u201c\u0421\u043a\u043e\u043b\u044c\u043a\u043e tps \u0432 \u0432\u0430\u0448\u0435\u043c \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0435?\u201d.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:09:55+00:00","article:modified_time":"2019-10-31T19:09:55+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36157","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 02:15:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:49:44","updated":"2026-01-22 02:15:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/36157","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=36157"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/36157\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=36157"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=36157"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=36157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}