{"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\/sk\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","title":{"rendered":"Ko\u013eko TPS je vo va\u0161om blockchaine?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Ob\u013e\u00fabenou ot\u00e1zkou ka\u017ed\u00e9ho netechnick\u00e9ho odborn\u00edka o akejko\u013evek distribuovanej s\u00fastave je \u201eKo\u013eko tps m\u00e1 v\u00e1\u0161 blockchain?\u201c. Odpove\u010f na t\u00fato ot\u00e1zku v\u0161ak obvykle m\u00e1 len m\u00e1lo spolo\u010dn\u00e9ho s t\u00fdm, \u010do by chcel po\u010du\u0165 p\u00fdtaj\u00faci sa. V skuto\u010dnosti sa p\u00fdtal \u201eVyhovuje v\u00e1\u0161 blockchain mojim obchodn\u00fdm po\u017eiadavk\u00e1m?\u201c, a tieto po\u017eiadavky nie s\u00fa len jedno \u010d\u00edslo, ale mno\u017estvo podmienok \u2014 zah\u0155\u0148aj\u00fa tu aj odolnos\u0165 siete proti v\u00fdpadkom, po\u017eiadavky na kone\u010dnos\u0165, ve\u013ekosti, charakter transakci\u00ed a mnoho in\u00fdch parametrov. Tak\u017ee odpove\u010f na ot\u00e1zku \u201eko\u013eko tps\u201c pravdepodobne nebude jednoduch\u00e1 a takmer nikdy nebude \u00fapln\u00e1. Distribuovan\u00e1 s\u00fastava so desiatkami a stovkami uzlov vykon\u00e1vaj\u00facich dos\u0165 zlo\u017eit\u00e9 v\u00fdpo\u010dty m\u00f4\u017ee ma\u0165 obrovsk\u00e9 mno\u017estvo r\u00f4znych stavov, ktor\u00e9 s\u00fa spojen\u00e9 so stavom siete, obsahom blockchainu, technick\u00fdmi poruchami, ekonomick\u00fdmi probl\u00e9mami, \u00fatokmi na sie\u0165 a mno\u017estvom in\u00fdch d\u00f4vodov. F\u00e1zy, v ktor\u00fdch m\u00f4\u017eu nasta\u0165 probl\u00e9my s v\u00fdkonnos\u0165ou, sa l\u00ed\u0161ia od tradici\u00f3rnych slu\u017eieb, pri\u010dom server blockchainovej siete predstavuje sie\u0165ov\u00fa slu\u017ebu, ktor\u00e1 kombinuje funk\u010dnos\u0165 datab\u00e1zy, webov\u00e9ho servera a torrent klienta, \u010do ju rob\u00ed mimoriadne zlo\u017eitou z h\u013eadiska profilu za\u0165a\u017eenia v\u0161etk\u00fdch subsyst\u00e9mov: procesora, pam\u00e4te, siete, \u00falo\u017eiska.<\/p>\n<p><\/p>\n<p>Stalo sa, \u017ee decentralizovan\u00e9 siete a blockchainy s\u00fa pomerne \u0161pecifick\u00fdm a nezvy\u010dajn\u00fdm softv\u00e9rom pre v\u00fdvoj\u00e1rov centralizovan\u00e9ho softv\u00e9ru. Preto by som r\u00e1d osvetlil d\u00f4le\u017eit\u00e9 aspekty v\u00fdkonu a stability decentralizovan\u00fdch siet\u00ed, pr\u00edstupy k ich meraniu a nach\u00e1dzaniu bottleneckov. Presk\u00famame r\u00f4zne probl\u00e9my v\u00fdkonnosti, ktor\u00e9 obmedzuj\u00fa r\u00fdchlos\u0165 poskytovania slu\u017eieb pou\u017e\u00edvate\u013eom blockchainov a poznamen\u00e1me \u0161pecifik\u00e1, ktor\u00e9 s\u00fa pre tento typ softv\u00e9ru charakteristick\u00e9.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2 id=\"etapy-zaprosa-servisa-klientom-blokcheyna\">F\u00e1zy po\u017eiadavky na slu\u017ebu klientom blockchainu<\/h2>\n<p><\/p>\n<p>Aby sme mohli \u010destne hovori\u0165 o kvalite ak\u00e9hoko\u013evek zlo\u017eit\u011bj\u0161\u00edho servisu, mus\u00edme zv\u00e1\u017ei\u0165 nielen priemery, ale aj maxim\u00e1lne a minim\u00e1lne hodnoty, medi\u00e1ny a percentily. Teoreticky m\u00f4\u017eeme hovori\u0165 o 1000 tps v nejakom blockchaine, ale ak 900 transakci\u00ed prebehlo s obrovskou r\u00fdchlos\u0165ou, zatia\u013e \u010do 100 \u2013 \u201ezaseklo\u201c sa na nieko\u013eko sek\u00fand, priemern\u00fd \u010das z\u00edskan\u00fd zo v\u0161etk\u00fdch transakci\u00ed nie je \u00faplne spravodlivou metrikou pre z\u00e1kazn\u00edka, ktor\u00fd nemohol dokon\u010di\u0165 obchod za nieko\u013eko sek\u00fand. \u010casov\u00e9 \u201ejamy\u201c, sp\u00f4soben\u00e9 vynechan\u00fdmi kolami konsenzu alebo rozdelen\u00edm siete, m\u00f4\u017eu v\u00e1\u017ene pokazi\u0165 servis, ktor\u00fd na testovac\u00edch link\u00e1ch ukazoval vynikaj\u00facu v\u00fdkonnos\u0165.<\/p>\n<p><\/p>\n<p>Na identifik\u00e1ciu tak\u00fdch bottleneckov je potrebn\u00e9 dobre rozumie\u0165 etap\u00e1m, v ktor\u00fdch m\u00f4\u017ee re\u00e1lny blockchain za\u017e\u00edva\u0165 \u0165a\u017ekosti pri obsluhe pou\u017e\u00edvate\u013eov. Po\u010fme op\u00edsa\u0165 cyklus dod\u00e1vky a spracovania transakci\u00ed, ako aj z\u00edskania nov\u00e9ho stavu blockchainu, z ktor\u00e9ho si klient m\u00f4\u017ee overi\u0165, \u017ee jeho transakcia bola spracovan\u00e1 a zoh\u013eadnen\u00e1.<\/p>\n<p><\/p>\n<ol>\n<li>transakcia sa formuje na klientovi<\/li>\n<li>transakcia sa podpisuje na klientovi<\/li>\n<li>klient si vyberie jednu z n\u00f3d a posiela do nej svoju transakciu<\/li>\n<li>klient sa podpisuje na aktualiz\u00e1cie state database n\u00f3d, \u010dakaj\u00fac na v\u00fdsledky spracovania svojej transakcie<\/li>\n<li>n\u00f3d \u0161\u00edri transakciu po p2p sieti<\/li>\n<li>nieko\u013eko alebo jeden BP (block producer) spracov\u00e1va nahromaden\u00e9 transakcie, aktualizuj\u00fac state database<\/li>\n<li>BP vytv\u00e1ra nov\u00fd blok spracovan\u00edm po\u017eadovan\u00e9ho po\u010dtu transakci\u00ed<\/li>\n<li>BP \u0161\u00edri nov\u00fd blok po p2p sieti<\/li>\n<li>nov\u00fd blok je doru\u010den\u00fd do n\u00f3d, na ktor\u00fa sa klient obracia<\/li>\n<li>n\u00f3d aktualizuje state database<\/li>\n<li>n\u00f3d vid\u00ed aktualiz\u00e1ciu t\u00fdkaj\u00facu sa klienta a posiela mu ozn\u00e1menie o transakcii<\/li>\n<\/ol>\n<p><\/p>\n<p>Po\u010fme sa podrobnej\u0161ie venova\u0165 t\u00fdmto krokom a op\u00edsa\u0165 potenci\u00e1lne probl\u00e9my s v\u00fdkonom v ka\u017edom z nich. Na rozdiel od centralizovan\u00fdch syst\u00e9mov sa budeme zaobera\u0165 aj vykon\u00e1van\u00edm k\u00f3du na klientoch siete. Pomerne \u010dasto pri meran\u00ed tps sa \u010das spracovania transakci\u00ed zbiera z uzlov, nie z klienta \u2014 to nie je \u00faplne f\u00e9r. Klientovi je jedno, ako r\u00fdchlo uzol spracoval jeho transakciu; najd\u00f4le\u017eitej\u0161\u00ed je pre neho okamih, kedy sa mu spr\u00edstupnia presn\u00e9 inform\u00e1cie o tejto transakcii, zahrnutej v blockchaine. Pr\u00e1ve t\u00e1to metrika je v podstate \u010dasom vykonania transakcie. To znamen\u00e1, \u017ee r\u00f4zni klienti, aj ke\u010f posielaj\u00fa t\u00fa ist\u00fa transakciu, m\u00f4\u017eu ma\u0165 \u00faplne odli\u0161n\u00e9 \u010dasy, ktor\u00e9 z\u00e1visia od kan\u00e1la, za\u0165a\u017eenia a bl\u00edzkosti uzla at\u010f. Preto je nevyhnutn\u00e9 mera\u0165 tento \u010das na klientoch, preto\u017ee tento parameter je potrebn\u00e9 optimalizova\u0165.<\/p>\n<p><\/p>\n<h2 id=\"podgotovka-tranzakcii-na-storone-klienta\">Pr\u00edprava transakcie na strane klienta<\/h2>\n<p><\/p>\n<p>Za\u010dneme s prv\u00fdmi dvoma bodmi: transakcia je vytvoren\u00e1 a podp\u00edsan\u00e1 klientom. Akoby to bolo prekvapuj\u00face, aj to m\u00f4\u017ee by\u0165 bottleneckom v\u00fdkonu blockchainu z poh\u013eadu klienta. To je nezvy\u010dajn\u00e9 pre centralizovan\u00e9 slu\u017eby, ktor\u00e9 si ber\u00fa v\u0161etky v\u00fdpo\u010dty a oper\u00e1cie s d\u00e1tami, zatia\u013e \u010do klient jednoducho pripravuje kr\u00e1tku po\u017eiadavku schopn\u00fa po\u017eiada\u0165 o ve\u013ek\u00e9 mno\u017estvo d\u00e1t alebo v\u00fdpo\u010dtov a obdr\u017e\u00ed hotov\u00fd v\u00fdsledok. V blockchanoch sa klientske k\u00f3dy st\u00e1vaj\u00fa \u010doraz mocnej\u0161\u00edmi, zatia\u013e \u010do blockchain jadro je \u010doraz \u013eah\u0161ie, a \u0165a\u017ek\u00e9 v\u00fdpo\u010dtov\u00e9 \u00falohy s\u00fa zvy\u010dajne odovzd\u00e1van\u00e9 klientsk\u00e9mu softv\u00e9ru. V blockchanoch existuj\u00fa klienti, ktor\u00ed m\u00f4\u017eu pripravova\u0165 jednu transakciu pomerne dlho (hovor\u00edm o r\u00f4znych merkle proof-och, succinct proof-och, threshold podpisoch a in\u00fdch zlo\u017eit\u00fdch oper\u00e1ci\u00e1ch na strane klienta). Dobr\u00e9 pr\u00edklady \u013eahkej on-chain verifik\u00e1cie a \u0165a\u017ekej pr\u00edpravy transakcie na klientovi je d\u00f4kaz patrnosti k zoznamu zalo\u017een\u00fd na Merkle-strome. <noindex><a rel=\"nofollow\" href=\"https:\/\/hackernoon.com\/evolution-of-airdrop-from-common-spam-to-the-merkle-tree-30caa2344170\">\u010dl\u00e1nok<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p>Takisto netreba zab\u00fada\u0165, \u017ee klientsky k\u00f3d nielen posiela transakcie do blockchainu, ale najsk\u00f4r \u017eiada stav blockchainu \u2014 a t\u00e1to \u010dinnos\u0165 m\u00f4\u017ee ovplyvni\u0165 za\u0165a\u017eenie siete a nodov blockchainu. Preto, ak mer\u00e1te, bude rozumn\u00e9 emulova\u0165 spr\u00e1vanie klientsk\u00e9ho k\u00f3du \u010do najpresnej\u0161ie. Aj ke\u010f vo va\u0161om blockchain sa pou\u017e\u00edvaj\u00fa be\u017en\u00ed \u013eahk\u00ed klienti, ktor\u00ed podpisuj\u00fa jednoduch\u00e9 transakcie na prevod nejak\u00e9ho akt\u00edva, s ka\u017ed\u00fdm rokom mno\u017estvo v\u00fdpo\u010dtov na strane klienta neust\u00e1le narast\u00e1, kryptografick\u00e9 algoritmy sa posil\u0148uj\u00fa a t\u00e1to \u010das\u0165 spracovania sa m\u00f4\u017ee sta\u0165 v\u00e1\u017enym bottleneckom v bud\u00facnosti. Preto bu\u010fte opatrn\u00ed a nenechajte si ujs\u0165 situ\u00e1ciu, ke\u010f v transakcii trvaj\u00facej 3,5 sekundy 2,5 sekundy ide na pr\u00edpravu a podpis transakcie a 1,0 sekundy na odoslanie do siete a \u010dakanie na odpove\u010f. Na hodnotenie rizika vzniku tohto bottlenecku je potrebn\u00e9 zbiera\u0165 metriky z klientsk\u00fdch strojov, nie len z blockchainov\u00fdch nodov.<\/p>\n<p><\/p>\n<h2 id=\"otpravka-tranzakcii-i-monitoring-ee-statusa\">Odoslanie transakcie a sledovanie jej stavu<\/h2>\n<p><\/p>\n<p>\u010eal\u0161\u00edm krokom je odoslanie transakcie do vybran\u00e9ho nodu blockchainu a z\u00edskanie stavu jej prijatia do transak\u010dn\u00e9ho poolu. Tento krok je podobn\u00fd be\u017en\u00e9mu pr\u00edstupu k datab\u00e1ze, nod mus\u00ed zap\u00edsa\u0165 transakciu do poolu a za\u010da\u0165 \u0161\u00edri\u0165 inform\u00e1cie o nej cez p2p sie\u0165. Pr\u00edstup k hodnoteniu v\u00fdkonnosti je tu podobn\u00fd hodnoteniu pr\u00e1ce tradi\u010dn\u00fdch mikroslu\u017eieb Web API, pri\u010dom sam\u00e9 transakcie v blockchaine sa m\u00f4\u017eu aktualizova\u0165 a akt\u00edvne meni\u0165 stav. V\u0161eobecne sa aktualiz\u00e1cia inform\u00e1ci\u00ed o transakcii v niektor\u00fdch blockchainoch m\u00f4\u017ee sta\u0165 viackr\u00e1t, napr\u00edklad pri prechode medzi forkmi re\u0165azca alebo ke\u010f BP oznamuj\u00fa \u00famysel zaradi\u0165 transakciu do bloku. Obmedzenia na objem tohto poolu a po\u010det transakci\u00ed v \u0148om m\u00f4\u017eu ovplyvni\u0165 v\u00fdkonnos\u0165 blockchainu. Ak je pool transakci\u00ed naplnen\u00fd na maxim\u00e1lnu mo\u017en\u00fa ve\u013ekos\u0165, alebo sa nezmest\u00ed do opera\u010dnej pam\u00e4te \u2014 v\u00fdkonnos\u0165 siete m\u00f4\u017ee prudko klesn\u00fa\u0165. Blockchainy nemaj\u00fa centralizovan\u00e9 prostriedky na ochranu pred tokom spamov\u00fdch spr\u00e1v, a ak blockchain podporuje transakcie ve\u013ek\u00e9ho objemu a n\u00edzke poplatky, m\u00f4\u017ee to vies\u0165 k preplneniu transak\u010dn\u00e9ho poolu \u2014 toto je \u010fal\u0161\u00ed potenci\u00e1lny bottleneck v\u00fdkonnosti.<\/p>\n<p><\/p>\n<p>V blockchains, klient posiela transakciu na ak\u00fako\u013evek uzol blockchatu, ktor\u00fd si vyberie, hash transakcie je zvy\u010dajne klientovi zn\u00e1my e\u0161te pred odoslan\u00edm, tak\u017ee v\u0161etko, \u010do potrebuje, je zabezpe\u010di\u0165 spojenie a po odoslan\u00ed \u010daka\u0165, kedy blockchain zmen\u00ed svoj stav a zahrnie jeho transakciu. Poznamenajme, \u017ee pri meran\u00ed \u201etps\u201c m\u00f4\u017eeme z\u00edska\u0165 \u00faplne odli\u0161n\u00e9 v\u00fdsledky pre r\u00f4zne sp\u00f4soby pripojenia k uzlu blockchatu. M\u00f4\u017ee to by\u0165 be\u017en\u00fd HTTP RPC alebo WebSocket, ktor\u00fd umo\u017e\u0148uje realizova\u0165 vzor \u201esubscribe\u201c. V druhom pr\u00edpade klient dostane ozn\u00e1menie sk\u00f4r a uzol minie menej zdrojov (predov\u0161etk\u00fdm pam\u00e4te a d\u00e1tov\u00e9ho prenosu) na odpovede o stave transakcie. Preto pri meran\u00ed \u201etps\u201c je potrebn\u00e9 zoh\u013eadni\u0165 sp\u00f4sob pripojenia klientov k uzlom. Preto na hodnotenie rizika vzniku tohto bottlenecku, benchmark blockchatu by mal vedie\u0165 emulova\u0165 klientov s WebSocket a HTTP RPC po\u017eiadavkami, v prerozdelen\u00ed zodpovedaj\u00facom skuto\u010dn\u00fdm sie\u0165am, a tie\u017e meni\u0165 charakter transakci\u00ed a ich ve\u013ekos\u0165.<\/p>\n<p><\/p>\n<p>Na pos\u00fadenie riz\u00edk vzniku tohto bottlenecku je tie\u017e potrebn\u00e9 zbiera\u0165 metriky z klientskych strojov, a nie len z blockchainov\u00fdch uzlov.<\/p>\n<p><\/p>\n<h2 id=\"peredacha-tranzakciy-i-blokov-po-p2p-seti\">Prenos transakci\u00ed a blokov cez p2p sie\u0165<\/h2>\n<p><\/p>\n<p>V blockchains sa na prenos transakci\u00ed a blokov medzi \u00fa\u010dastn\u00edkmi pou\u017e\u00edva peer-to-peer (p2p) networking. Transakcie sa \u0161\u00edria sie\u0165ou, po\u010dn\u00fac jedn\u00fdm z uzlov, k\u00fdm nedosiahnu peer-ov-block producer-ov, ktor\u00ed balia transakcie do blokov a pomocou rovnak\u00e9ho p2p \u0161\u00edria nov\u00e9 bloky po v\u0161etk\u00fdch uzloch siete. Z\u00e1kladom v\u00e4\u010d\u0161iny modern\u00fdch p2p siet\u00ed s\u00fa r\u00f4zne modifik\u00e1cie protokolu Kademlia. <noindex><a rel=\"nofollow\" href=\"https:\/\/cardanodocs.com\/technical\/protocols\/p2p\/\">Tu s\u00fa<\/a><\/noindex> dobr\u00fd stru\u010dn\u00fd preh\u013ead tohto protokolu, a <noindex><a rel=\"nofollow\" href=\"https:\/\/web.njit.edu\/~dingxn\/papers\/BT-JSAC.pdf\">tu<\/a><\/noindex> \u2014 \u010dl\u00e1nok s r\u00f4znymi meraniami v sieti BitTorrent, pod\u013ea ktor\u00e9ho je mo\u017en\u00e9 pochopi\u0165 \u2014 \u017ee tento typ siet\u00ed je zlo\u017eitej\u0161\u00ed a menej predv\u00eddate\u013en\u00fd ne\u017e pevne nakonfigurovan\u00e1 sie\u0165 centralizovanej slu\u017eby. Taktie\u017e, <noindex><a rel=\"nofollow\" href=\"https:\/\/zanema.com\/papers\/imc18_ethpeers.pdf\">tu<\/a><\/noindex> \u010dl\u00e1nok o meran\u00ed r\u00f4znych zauj\u00edmav\u00fdch metr\u00edk pre uzly Ethereum.<\/p>\n<p><\/p>\n<p>V skratke, ka\u017ed\u00fd peer v tak\u00fdchto sie\u0165ach udr\u017eiava svoj vlastn\u00fd dynamick\u00fd zoznam in\u00fdch peerov, od ktor\u00fdch si \u017eiada bloky inform\u00e1ci\u00ed, ktor\u00e9 s\u00fa adresovan\u00e9 pod\u013ea obsahu. Pri prijat\u00ed \u017eiadosti peer bu\u010f odovzd\u00e1 potrebn\u00e9 inform\u00e1cie, alebo prenesie po\u017eiadavku nasleduj\u00facemu pseudon\u00e1hodn\u00e9mu peerovi zo zoznamu; po obdr\u017ean\u00ed odpovede ju odovzd\u00e1 \u017eiadaj\u00facemu a na ur\u010dit\u00fd \u010das ju ke\u0161uje, \u010d\u00edm tento blok inform\u00e1ci\u00ed sk\u00f4r odovzd\u00e1va pri \u010fal\u0161ej \u017eiadosti. Takto sa popul\u00e1rne inform\u00e1cie nach\u00e1dzaj\u00fa v mnoh\u00fdch ke\u0161och u mno\u017estva peerov, zatia\u013e \u010do nepou\u017e\u00edvan\u00e9 inform\u00e1cie sa postupne vytl\u00e1\u010daj\u00fa. Peerovia sleduj\u00fa, kto komu ko\u013eko inform\u00e1ci\u00ed odovzdal, a sie\u0165 sa sna\u017e\u00ed stimulova\u0165 akt\u00edvnych odovzd\u00e1vate\u013eov, zvy\u0161ovan\u00edm ich hodnotenia a poskytovan\u00edm vy\u0161\u0161ej \u00farovne slu\u017eby, automaticky vytl\u00e1\u010daj\u00fac neakt\u00edvnych \u00fa\u010dastn\u00edkov zo zoznamov peerov.<\/p>\n<p><\/p>\n<p>Tak\u017ee teraz je potrebn\u00e9 roz\u0161\u00edri\u0165 transakciu po sieti, aby ju videli block-produceri a zahrnuli ju do bloku. Noda akt\u00edvne 'distribuuje' nov\u00fa transakciu v\u0161etk\u00fdm z\u00e1ujemcom a po\u010d\u00fava sie\u0165, \u010dakaj\u00fac na blok, v ktorom sa objav\u00ed po\u017eadovan\u00e1 transakcia, aby mohla informova\u0165 \u010dakaj\u00faceho klienta. \u010cas, po\u010das ktor\u00e9ho sie\u0165 pren\u00e1\u0161a medzi sebou inform\u00e1cie o nov\u00fdch transakci\u00e1ch a blokoch v p2p sie\u0165ach, z\u00e1vis\u00ed od ve\u013ek\u00e9ho mno\u017estva faktorov: po\u010dtu \u010destn\u00fdch, funguj\u00facich nodov v bl\u00edzkosti (z poh\u013eadu siete), 'ohriatia' cache t\u00fdchto nodov, ve\u013ekosti blokov, transakci\u00ed, charakteru zmien, geografick\u00fdch podmienok siete, po\u010dtu nodov a mnoh\u00fdch \u010fal\u0161\u00edch faktorov. Komplexn\u00e9 meranie metr\u00edk v\u00fdkonu v tak\u00fdchto sie\u0165ach je zlo\u017eit\u00e1 \u00faloha, je potrebn\u00e9 s\u00fa\u010dasne hodnoti\u0165 \u010das spracovania po\u017eiadaviek ako na klientoch, tak na peer-och (blockchain nod\u00e1ch). Probl\u00e9my v akomko\u013evek z p2p mechanizmov, nespr\u00e1vne nahradenie a cacheovanie \u00fadajov, neefekt\u00edvne riadenie zoznamov akt\u00edvnych peer-ov a mno\u017estvo \u010fal\u0161\u00edch faktorov m\u00f4\u017eu by\u0165 pr\u00ed\u010dinou oneskoren\u00ed, ktor\u00e9 ovplyv\u0148uj\u00fa efekt\u00edvnos\u0165 celej siete ako celku, a tento bottleneck je naj\u0165a\u017e\u0161ie analyzova\u0165, testova\u0165 a interpretova\u0165 v\u00fdsledky.<\/p>\n<p><\/p>\n<h2 id=\"processing-cepochki-blokov-i-obnovlenie-state-database\">Spracovanie re\u0165azca blokov a aktualiz\u00e1cia state database<\/h2>\n<p><\/p>\n<p>Najd\u00f4le\u017eitej\u0161ou s\u00fa\u010das\u0165ou fungovania blockchainu je konsensu\u00e1lny algoritmus, jeho aplik\u00e1cia na nov\u00e9 bloky z\u00edskan\u00e9 zo siete a spracovanie transakci\u00ed so zaznamen\u00e1van\u00edm v\u00fdsledkov do state database. Pridan\u00edm nov\u00e9ho bloku do re\u0165azca a n\u00e1sledn\u00fdm v\u00fdberom hlavn\u00e9ho re\u0165azca by mal prebieha\u0165 \u010do najr\u00fdchlej\u0161ie. Av\u0161ak v re\u00e1lnom \u017eivote 'm\u00f4\u017ee' neznamen\u00e1 'funguje', a m\u00f4\u017eeme si napr\u00edklad predstavi\u0165 situ\u00e1ciu, ke\u010f dve dlh\u00e9 konkuren\u010dn\u00e9 re\u0165azce neust\u00e1le prep\u00ednaj\u00fa medzi sebou, menia metadata tis\u00edcok transakci\u00ed v poole pri ka\u017edom prepnut\u00ed a neust\u00e1le vyvol\u00e1vaj\u00fa n\u00e1vraty stavu state database. Tento krok je z h\u013eadiska ur\u010denia bottlenecku jednoduch\u0161\u00ed ne\u017e sie\u0165ov\u00e1 p2p vrstva, preto\u017ee vykon\u00e1vanie transakci\u00ed a konsensu\u00e1lny algoritmus s\u00fa striktne deterministick\u00e9 a meranie \u010dohoko\u013evek tu je jednoduch\u0161ie.<br \/>\nHlavn\u00e9 je nezamie\u0148a\u0165 n\u00e1hodn\u00fa degrad\u00e1ciu v\u00fdkonu tohto kroku s probl\u00e9mami v sieti \u2014 uzly pomal\u0161ie poskytuj\u00fa bloky a inform\u00e1cie o hlavnom re\u0165azci a pre vonkaj\u0161ieho klienta to m\u00f4\u017ee vyzera\u0165 ako pomal\u00e1 sie\u0165, hoci probl\u00e9m sa nach\u00e1dza \u00faplne inde.<\/p>\n<p><\/p>\n<p>Na optimaliz\u00e1ciu v\u00fdkonu v tomto kroku je u\u017eito\u010dn\u00e9 zbiera\u0165 a monitorova\u0165 metriky priamo z uzlov a zahrn\u00fa\u0165 do nich aj tie, ktor\u00e9 sa t\u00fdkaj\u00fa aktualiz\u00e1cie \u0161t\u00e1tnej datab\u00e1zy: po\u010det blokov spracov\u00e1van\u00fdch na uzle, ich ve\u013ekos\u0165, po\u010det transakci\u00ed, po\u010det prepnut\u00ed medzi forkami re\u0165azca, po\u010det neplatn\u00fdch blokov, \u010das prev\u00e1dzky virtu\u00e1lnych strojov, \u010das potvrdenia \u00fadajov a pod. To umo\u017en\u00ed nezamie\u0148a\u0165 sie\u0165ov\u00e9 probl\u00e9my s chybami v algoritmoch spracovania re\u0165azcov.<\/p>\n<p><\/p>\n<p>Virtu\u00e1lna ma\u0161\u00ednka sprac\u00favaj\u00faca transakcie m\u00f4\u017ee by\u0165 u\u017eito\u010dn\u00fdm zdrojom inform\u00e1ci\u00ed, schopn\u00fdm optimalizova\u0165 fungovanie blockchainu. Mno\u017estvo alok\u00e1ci\u00ed pam\u00e4te, po\u010det read\/write in\u0161trukci\u00ed a in\u00e9 metriky t\u00fdkaj\u00face sa efektivity vykon\u00e1vania k\u00f3du zml\u00fav m\u00f4\u017eu poskytn\u00fa\u0165 mnoho u\u017eito\u010dn\u00fdch inform\u00e1ci\u00ed pre v\u00fdvoj\u00e1rov. Z\u00e1rove\u0148 s\u00fa smart kontrakty programy, a preto teoreticky m\u00f4\u017eu spotrebova\u0165 ak\u00e9ko\u013evek prostriedky: cpu\/memory\/network\/storage, tak\u017ee spracovanie transakci\u00ed je pomerne neur\u010dit\u00fd krok, ktor\u00fd navy\u0161e zna\u010dne men\u00ed prechodom medzi verziami a zmenou k\u00f3du zml\u00fav. Preto s\u00fa metriky t\u00fdkaj\u00face sa spracovania transakci\u00ed tie\u017e potrebn\u00e9 pre efekt\u00edvnu optimaliz\u00e1ciu v\u00fdkonu blockchainu.<\/p>\n<p><\/p>\n<h2 id=\"poluchenie-klientom-uvedomleniya-o-vklyuchenii-tranzakcii-v-blokcheyn\">Notifik\u00e1cia klienta o aktiv\u00e1cii transakcie v blockchaine<\/h2>\n<p><\/p>\n<p>Toto je posledn\u00fd krok v procese z\u00edskavania slu\u017eby od klienta v blockchaine; v porovnan\u00ed s in\u00fdmi krokmi nie s\u00fa ve\u013ek\u00e9 n\u00e1klady, no st\u00e1le treba bra\u0165 do \u00favahy mo\u017enos\u0165, \u017ee klient dostane obsiahlu odpove\u010f od uzla (napr\u00edklad smart kontrakt pred\u00e1vaj\u00faci pole \u00fadajov). V ka\u017edom pr\u00edpade je to pr\u00e1ve tento moment najd\u00f4le\u017eitej\u0161\u00ed pre toho, kto sa p\u00fdta: \u201eA ko\u013eko TPS je vo va\u0161om blockchaine?\u201c, preto\u017ee pr\u00e1ve v tejto chv\u00edli sa zaznamen\u00e1va \u010das z\u00edskania slu\u017eby. <\/p>\n<p><\/p>\n<p>V tomto bode sa nevyhnutne posiela celkov\u00fd \u010das, ktor\u00fd klient str\u00e1vil \u010dakan\u00edm na odpove\u010f od blockhainu, pr\u00e1ve tento \u010das bude pou\u017e\u00edvate\u013e o\u010dak\u00e1va\u0165 ako potvrdenie v svojej aplik\u00e1cii, a jeho optimaliz\u00e1cia je hlavnou \u00falohou v\u00fdvoj\u00e1rov.<\/p>\n<p><\/p>\n<h1 id=\"zaklyuchenie\">Z\u00e1ver<\/h1>\n<p><\/p>\n<p>V\u00fdsledkom toho m\u00f4\u017eeme op\u00edsa\u0165 typy oper\u00e1ci\u00ed, ktor\u00e9 sa v blockhainoch vykon\u00e1vaj\u00fa, a rozdeli\u0165 ich do nieko\u013ek\u00fdch kateg\u00f3ri\u00ed:<\/p>\n<p><\/p>\n<ol>\n<li>kryptografick\u00e9 transform\u00e1cie, vytv\u00e1ranie d\u00f4kazov<\/li>\n<li>peer-to-peer networking, replik\u00e1cia transakci\u00ed a blokov<\/li>\n<li>spracovanie transakci\u00ed, vykon\u00e1vanie smart kontraktov<\/li>\n<li>aplik\u00e1cia zmien v blockchaine na stavov\u00fa datab\u00e1zu, aktualiz\u00e1cia \u00fadajov o transakci\u00e1ch a blokoch<\/li>\n<li>read-only po\u017eiadavky na stavov\u00fa datab\u00e1zu, API nodu blockhainu, subscription slu\u017eby <\/li>\n<\/ol>\n<p><\/p>\n<p>Technick\u00e9 po\u017eiadavky na nody modern\u00fdch blockchainov s\u00fa ve\u013emi pr\u00edsne \u2014 ide o r\u00fdchle CPU pre kryptografiu, ve\u013ek\u00fd objem RAM na uchov\u00e1vanie a r\u00fdchly pr\u00edstup k stavovej datab\u00e1ze, sie\u0165ov\u00fa interakciu, ktor\u00e1 vyu\u017e\u00edva ve\u013ek\u00fd po\u010det s\u00fa\u010dasne otvoren\u00fdch spojen\u00ed, objemn\u00fd storage. Tak\u00e9to vysok\u00e9 po\u017eiadavky a mno\u017estvo r\u00f4znych typov oper\u00e1ci\u00ed nevyhnutne vedie k tomu, \u017ee nodom m\u00f4\u017ee nedosta\u010dova\u0165 prostriedkov, a vtedy sa ak\u00e1ko\u013evek z vy\u0161\u0161ie uveden\u00fdch et\u00e1p m\u00f4\u017ee sta\u0165 \u010fal\u0161\u00edm bottleneckom pre celkov\u00fd v\u00fdkon siete.<\/p>\n<p><\/p>\n<p>Pri v\u00fdvoji a hodnoten\u00ed v\u00fdkonnosti blockchainov mus\u00edte bra\u0165 do \u00favahy v\u0161etky tieto faktory. Na to je potrebn\u00e9 zbiera\u0165 a analyzova\u0165 metriky s\u00fa\u010dasne z klientov a uzlov siete, h\u013eada\u0165 korel\u00e1cie medzi nimi, hodnoti\u0165 \u010das poskytovania slu\u017eby z\u00e1kazn\u00edkom, zoh\u013ead\u0148ova\u0165 v\u0161etky hlavn\u00e9 zdroje: CPU \/ pam\u00e4\u0165 \/ sie\u0165 \/ \u00falo\u017eisko, a rozumie\u0165, ako sa vyu\u017e\u00edvaj\u00fa a navz\u00e1jom ovplyv\u0148uj\u00fa. To v\u0161etko rob\u00ed porovn\u00e1vanie r\u00fdchlosti r\u00f4znych blockchainov na z\u00e1klade \u201eko\u013eko TPS\u201c mimoriadne v\u010fa\u010dn\u00fdm, preto\u017ee existuje obrovsk\u00e9 mno\u017estvo r\u00f4znych konfigur\u00e1ci\u00ed a stavov. V rozsiahlych centralizovan\u00fdch syst\u00e9moch, klastroch z desiatok serverov, s\u00fa tieto probl\u00e9my tie\u017e zlo\u017eit\u00e1 a vy\u017eaduj\u00fa zbieranie ve\u013ek\u00e9ho mno\u017estva r\u00f4znych metr\u00edk. No v blockhainoch, kv\u00f4li P2P sie\u0165am, virtu\u00e1lnym strojom, spracov\u00e1vaj\u00facim kontrakty, vn\u00fatornej ekonomike, je po\u010det stup\u0148ov vo\u013enosti ove\u013ea v\u00e4\u010d\u0161\u00ed, \u010do rob\u00ed testovanie aj na nieko\u013ek\u00fdch serveroch nevypovedaj\u00facim a ukazuj\u00facim iba ve\u013emi pribli\u017en\u00e9 hodnoty, ktor\u00e9 maj\u00fa takmer \u017eiadny vz\u0165ah k realite.<\/p>\n<p><\/p>\n<p>Preto, pri v\u00fdvoji v jadre blockchainu, na hodnotenie v\u00fdkonnosti a na zodpovedanie ot\u00e1zky \u201ezlep\u0161ilo sa to v porovnan\u00ed s predch\u00e1dzaj\u00facim pokusom?\u201c pou\u017e\u00edvame pomerne zlo\u017eit\u00fd softv\u00e9r, ktor\u00fd orchestruje spustenie blockchainu s desiatkami uzlov a automatick\u00fdm spusten\u00edm benchmarku a zbieranie metr\u00edk; bez t\u00fdchto inform\u00e1ci\u00ed je nesmierne \u0165a\u017ek\u00e9 ladenie protokolov, ktor\u00e9 pracuj\u00fa s mnoh\u00fdmi \u00fa\u010dastn\u00edkmi.<\/p>\n<p><\/p>\n<p>Tak\u017ee, ak dostanete ot\u00e1zku \u201eko\u013eko TPS je vo va\u0161om blockchaine?\u201c, pon\u00faknite svojmu rozhovorov\u00e9mu partnerovi \u010daj a op\u00fdtajte sa, \u010di je pripraven\u00fd obozn\u00e1mi\u0165 sa s desiatkami grafov a tie\u017e vypo\u010du\u0165 si v\u0161etky tri tabu probl\u00e9my v\u00fdkonnosti blockchainov a va\u0161e n\u00e1vrhy na ich rie\u0161enie\u2026<\/p>\n<p>Zdroj: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/459763\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\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 [&hellip;]<\/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<!-- All in One SEO 5.0.5 - aioseo.com -->\n\t<meta name=\"description\" content=\"\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.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.5\" \/>\n\t\t<meta property=\"og:locale\" content=\"sk_SK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"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\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\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\" \/>\n\t\t<meta property=\"og:description\" content=\"\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.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:09:55+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:09:55+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Ko\u013eko TPS vo va\u0161om blockchainu? | ProHoster","description":"Ob\u013e\u00fabenou ot\u00e1zkou o akejko\u013evek distribuovanej s\u00fastave od netechnick\u00e9ho odborn\u00edka je \u201eKo\u013eko tps vo va\u0161om blockchainu?\u201c.","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","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\/sk\/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\/sk\/wp-json\/wp\/v2\/posts\/36157","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=36157"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/36157\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=36157"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=36157"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=36157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}