{"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\/hr\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","title":{"rendered":"Koliko TPS-a ima va\u0161 blockchain?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Omiljeno pitanje svakog netehni\u010dkog stru\u010dnjaka o bilo kojem distribuiranom sistemu je \u201eKoliko tps u va\u0161em blockchainu?\u201c. Me\u0111utim, broj koji se navedu kao odgovor obi\u010dno ima vrlo malo veze s onim \u0161to bi ispitiva\u010d \u017eeleo \u010duti. U stvari, \u017eeleo je pitati \u201eDa li va\u0161 blockchain odgovara mojim poslovnim zahtevima?\u201c, a ti zahtevi nisu samo jedan broj, ve\u0107 mno\u0161tvo uslova \u2014 od otpornosti mre\u017ee, zahteva za kona\u010dno\u0161\u0107u, veli\u010dine, karaktera transakcija, pa do mnogih drugih parametara. Tako da odgovor na pitanje \u201ekoliko tps\u201c verovatno ne\u0107e biti jednostavan, i gotovo nikada ne\u0107e biti potpun. Distribuirani sistem sa desetinama i stotinama \u010dvorova koji obavljaju prili\u010dno slo\u017eene izra\u010dune mo\u017ee se nalaziti u ogromnom broju razli\u010ditih stanja, povezanih sa stanjem mre\u017ee, sadr\u017eajem blockchaina, tehni\u010dkim kvarovima, ekonomskim problemima, napadima na mre\u017eu i mnogim drugim razlozima. Faze u kojima su problemi s performansama mogu se razlikovati od tradicionalnih usluga, dok je server blockchain mre\u017ee mre\u017ena usluga koja kombinuje funkcionalnosti baze podataka, web servera i torrent klijenta, \u0161to ga \u010dini izuzetno slo\u017eenim u pogledu optere\u0107enja na sve podsisteme: procesor, memorija, mre\u017ea, skladi\u0161te.<\/p>\n

<\/p>\n

Zanimljivo je da su decentralizovane mre\u017ee i blockchaini prili\u010dno specifi\u010dan i neobi\u010dan softver za programere centralizovanog softvera. Zato bih \u017eeleo da osvetlim va\u017ene aspekte performansi i otpornosti decentralizovanih mre\u017ea, pristupe njihovom merenju i identifikaciji uskih grla. Razmotri\u0107emo razli\u010dite probleme s performansama koji ograni\u010davaju brzinu pru\u017eanja usluga korisnicima blockchaina i istakao posebnosti karakteristi\u010dne za ovu vrstu softvera.<\/p>\n

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

Faze zahteva usluge od strane klijenta blockchaina<\/h2>\n

<\/p>\n

Da bi se ozbiljno govorilo o kvaliteti bilo kojeg slo\u017eenijeg servisa, potrebno je uzeti u obzir ne samo prosje\u010dne vrijednosti, ve\u0107 i maksimalne\/minimalne, medijane, percentile. Teoretski, mogu\u0107e je govoriti o 1000 tps u nekoj blockchain mre\u017ei, ali ako je 900 transakcija izvr\u0161eno izuzetno brzo, dok je 100 'zapelo' na nekoliko sekundi, onda prosje\u010dno vrijeme prikupljeno za sve transakcije nije sasvim po\u0161tena metrika za klijenta koji nije mogao zavr\u0161iti transakciju u nekoliko sekundi. Vremenski 'jami', uzrokovani propu\u0161tenim rundama konsenzusa ili podjelom mre\u017ee, mogu jako pokvariti servis koji je na testnim postavkama pokazivao odli\u010dnu izvedbu.<\/p>\n

<\/p>\n

Da biste identificirali takve bottleneckove, potrebno je dobro razumjeti faze u kojima stvarni blockchain mo\u017ee imati pote\u0161ko\u0107a u opslu\u017eivanju korisnika. Opisujmo ciklus dostave i procesiranja transakcije, kao i dobivanje novog stanja blockchaina, iz kojeg klijent mo\u017ee biti siguran da je njegova transakcija obra\u0111ena i uzeta u obzir.<\/p>\n

<\/p>\n

    \n
  1. transakcija se formira na klijentu<\/li>\n
  2. transakcija se potpisuje na klijentu<\/li>\n
  3. klijent odabire jedan od nodova i \u0161alje mu svoju transakciju<\/li>\n
  4. klijent se prijavljuje za a\u017euriranja state database nodova, \u010dekaju\u0107i na pojavu rezultata izvr\u0161enja svoje transakcije<\/li>\n
  5. nod distribuira transakciju putem p2p mre\u017ee<\/li>\n
  6. nekoliko, ili jedan BP (block producer) procesira akumulirane transakcije, a\u017euriraju\u0107i state database<\/li>\n
  7. BP formira novi blok, obradiv\u0161i potrebno broj transakcija<\/li>\n
  8. BP distribuira novi blok putem p2p mre\u017ee<\/li>\n
  9. novi blok dostavlja se nodu kojem se klijent obra\u0107a<\/li>\n
  10. nod a\u017eurira state database<\/li>\n
  11. nod vidi a\u017euriranje koje se ti\u010de klijenta i \u0161alje mu obavijest o transakciji<\/li>\n<\/ol>\n

    <\/p>\n

    Sada \u0107emo detaljnije razraditi te korake i opisati potencijalne probleme s performansama u svakom koraku. Za razliku od centraliziranih sustava, tako\u0111er \u0107emo razmotriti izvr\u0161avanje koda na klijentima mre\u017ee. Prili\u010dno \u010desto, prilikom mjerenja tps-a, vrijeme obrade transakcija prikuplja se s nodova, a ne s klijenata - to nije sasvim po\u0161teno. Klijentu nije stalo koliko je brzo nod obradio njegovu transakciju, najva\u017enije za njega je trenutak kada postane dostupna vjerodostojna informacija o toj transakciji uklju\u010dena u blockchain. Upravo ova metrike je su\u0161tinski vrijeme izvr\u0161enja transakcije. To zna\u010di da razli\u010diti klijenti, \u010dak i \u0161alju\u0107i istu transakciju, mogu dobiti potpuno razli\u010dita vremena koja ovise o kanalu, optere\u0107enju i blizini nodova, i sli\u010dno. Stoga je potpuno nu\u017eno mjeriti to vrijeme na klijentima, s obzirom na to da je to parametar koji treba optimizirati.<\/p>\n

    <\/p>\n

    Priprema transakcije na strani klijenta<\/h2>\n

    <\/p>\n

    Zapo\u010dnimo s prva dva mjesta: transakcija se formira i potpisuje od strane klijenta. \u010cudno je, ali to tako\u0111er mo\u017ee biti bottleneck u performansama blockchaina s gledi\u0161ta klijenta. To nije uobi\u010dajeno za centralizirane usluge koje preuzimaju sve prora\u010dune i operacije s podacima, dok klijent jednostavno priprema kratak zahtjev, sposoban zatra\u017eiti veliki volumen podataka ili prora\u010duna, dobivaju\u0107i gotov rezultat. U blockchainima klijentski kod postaje sve mo\u0107niji, dok je jezgra blockchaina sve lak\u0161a, a masivne prora\u010dunske zadatke obi\u010dno prepu\u0161taju klijentskom softveru. U blockchainima postoje klijenti koji mogu pripremiti jednu transakciju prili\u010dno dugo (govorim o raznim merkle proof-ima, succinct proof-ima, threshold potpisima i drugim slo\u017eenim operacijama na strani klijenta). Dobar primjer lagane on-chain verifikacije i te\u0161ke pripreme transakcije na klijentu je dokaz pripadnosti listi temeljen na Merkle-drvetu. \u010dlanak<\/a><\/noindex>.<\/p>\n

    <\/p>\n

    Tako\u0111er, ne smijemo zaboraviti da klijentski kod ne \u0161alje samo transakcije u blokchain, ve\u0107 prvo zahtijeva stanje blokchaina \u2014 a ta aktivnost mo\u017ee utjecati na optere\u0107enje mre\u017ee i \u010dvorova blokchaina. Stoga, prilikom mjerenja, bit \u0107e razumno emulirati pona\u0161anje klijentskog koda na \u0161to potpuniji na\u010din. \u010cak i ako u va\u0161em blokchainu postoje obi\u010dni lagani klijenti koji stavljaju obi\u010dan digitalni potpis na najjednostavniju transakciju prijenosa ne\u010dega, s godinama se ra\u010dunski zahtjevi na klijentskoj strani ipak pove\u0107avaju, kriptoalgoritmi postaju ja\u010di, i ovaj dio procesiranja mo\u017ee postati zna\u010dajna to\u010dka uskog grla u budu\u0107nosti. Zato budite oprezni i ne propustite situaciju u kojoj u transakciji koja traje 3.5 sekundi, 2.5 sekundi odlazi na pripremu i potpisivanje transakcije, i 1.0 sekundu na slanje u mre\u017eu i \u010dekanje odgovora. Za procjenu rizika od pojave ovog uskog grla potrebno je prikupljati metrike s klijentskih ra\u010dunala, a ne samo s \u010dvorova blokchaina.<\/p>\n

    <\/p>\n

    Slanje transakcije i pra\u0107enje njezinog statusa<\/h2>\n

    <\/p>\n

    Sljede\u0107a faza je slanje transakcije odabranom \u010dvoru blokchaina i dobivanje statusa prihva\u0107anja u bazu transakcija. Ova faza je sli\u010dna uobi\u010dajenom pristupu bazi podataka, \u010dvor mora zapisati transakciju u bazu i po\u010deti \u0161iriti informacije o njoj putem p2p mre\u017ee. Pristup procjeni performansi ovdje je sli\u010dan procjeni rada tradicionalnih mikroservisa Web API, pri \u010demu se same transakcije u blokchainima mogu a\u017eurirati i aktivno mijenjati status. Uop\u0107e, a\u017euriranje informacija o transakciji u nekim blokchainima mo\u017ee se dogoditi nekoliko puta, na primjer kada se prelazi izme\u0111u forkova lanaca ili kada BP izvje\u0161tava o namjeri uklju\u010divanja transakcije u blok. Ograni\u010denja u volumenu ove baze i broj transakcija u njoj mogu utjecati na performanse blokchaina. Ako je baza transakcija ispunjena do maksimalne mogu\u0107nosti, ili ne stane u radnu memoriju \u2014 performanse mre\u017ee mogu naglo pasti. Blokchaini nemaju centralizirane za\u0161tite od toka neva\u017enih poruka, i ako blokchain podr\u017eava transakcije velikog volumena i niske naknade, to mo\u017ee dovesti do preoptere\u0107enja baze transakcija \u2014 \u0161to je jo\u0161 jedna potencijalna to\u010dka uskog grla u performansama.<\/p>\n

    <\/p>\n

    U blockchain mre\u017eama, klijent \u0161alje transakciju bilo kojoj \u010dvoru blockchaina koji mu se svi\u0111a, hash transakcije obi\u010dno je poznat klijentu jo\u0161 prije slanja, tako da je sve \u0161to mu je potrebno uspostaviti vezu i nakon prijenosa \u010dekati da se blockchain promijeni, uklju\u010div\u0161i njegovu transakciju. Napominjemo da mjerenje 'tps' mo\u017ee donijeti potpuno razli\u010dite rezultate za razli\u010dite na\u010dine povezivanja s \u010dvorom blockchaina. To mo\u017ee biti obi\u010dni HTTP RPC ili WebSocket, \u0161to omogu\u0107uje realizaciju obrasca 'subscribe'. U drugom slu\u010daju, klijent \u0107e ranije primiti obavijest, a \u010dvor \u0107e potro\u0161iti manje resursa (prete\u017eno memorije i prometa) na odgovore o stanju transakcije. Stoga, prilikom mjerenja 'tps', treba razmotriti na\u010din povezivanja klijenata s \u010dvorovima. Zato, za procjenu rizika od pojave ovog uskog grla, benchmark blockchaina treba mo\u0107i emulirati klijente i s WebSocket i s HTTP RPC zahtjevima, u dijelovima koji odgovaraju stvarnim mre\u017eama, a tako\u0111er mijenjati karakter transakcija i njihovu veli\u010dinu.<\/p>\n

    <\/p>\n

    Za procjenu rizika pojave ovog bottleneck-a potrebno je tako\u0111er prikupljati metrike s klijentovih strojeva, a ne samo s blockchain \u010dvorova.<\/p>\n

    <\/p>\n

    Prenos transakcija i blokova putem p2p mre\u017ee<\/h2>\n

    <\/p>\n

    U blockchainima za prenos transakcija i blokova izme\u0111u sudionika koristi se peer-to-peer (p2p) umre\u017eavanje. Transakcije se \u0161ire mre\u017eom, po\u010dinju\u0107i od jednog od \u010dvorova, sve dok ne do\u0111u do peer-a - blok producenata, koji pakiraju transakcije u blokove i putem iste p2p mre\u017ee \u0161ire nove blokove svim \u010dvorovima u mre\u017ei. Osnova ve\u0107ine modernih p2p mre\u017ea su razli\u010dite modifikacije Kademlijevog protokola. Evo<\/a><\/noindex> dobar kratak pregled ovog protokola, a evo<\/a><\/noindex> \u2014 \u010dlanak s razli\u010ditim mjerenjima u mre\u017ei BitTorrent, prema kojem se mo\u017ee shvatiti \u2013 da su ove vrste mre\u017ea slo\u017eenije i manje predvidive od strogo konfiguriranih mre\u017ea centralizirane usluge. Tako\u0111er, evo<\/a><\/noindex> \u010dlanak o mjerenju razli\u010ditih zanimljivih metrika za Ethereum \u010dvorove.<\/p>\n

    <\/p>\n

    Ukratko, svaki peer u takvim mre\u017eama odr\u017eava svoj vlastiti dinami\u010dki popis drugih peer-a, od kojih tra\u017ei blokove informacija koji se adresiraju prema sadr\u017eaju. Kada primi zahtjev, peer ili proslijedi potrebne informacije, ili prenosi zahtjev sljede\u0107em pseudo-namjenskom peer-u sa popisa, a nakon \u0161to dobije odgovor, proslijedi ga tra\u017eitelju i na neko vrijeme ga ke\u0161ira, daju\u0107i taj blok informacija ranije sljede\u0107i put. Na taj na\u010din popularne informacije zavr\u0161avaju u velikom broju ke\u0161eva kod velikog broja peer-a, dok manje popularne postupno budu istisnute. Peer-ovi vode evidenciju o tome tko koliko informacija prenosi, a mre\u017ea nastoji poticati aktivne davatelje, pove\u0107avaju\u0107i njihovu ocjenu i osiguravaju\u0107i im vi\u0161i nivo usluge, automatski istiskuju\u0107i neaktivne sudionike iz popisa peer-a.<\/p>\n

    <\/p>\n

    Dakle, transakciju sada treba distribuirati po mre\u017ei kako bi je block-produceri vidjeli i uklju\u010dili u blok. \u010cvor aktivno 'dijeli' novu transakciju svima koji \u017eele i slu\u0161aju mre\u017eu, \u010dekaju\u0107i blok u kojem \u0107e se pojaviti potrebna transakcija kako bi obavijestili klijenta koji \u010deka. Vrijeme koje je potrebno mre\u017ei da razmjenjuje informacije o novim transakcijama i blokovima u p2p mre\u017eama ovisi o velikom broju \u010dimbenika: broju po\u0161tenih, aktivnih \u010dvorova (s mre\u017enog stajali\u0161ta), 'zagrijanosti' ke\u0161eva tih \u010dvorova, veli\u010dini blokova, transakcija, prirodi promjena, geografiji mre\u017ee, broju \u010dvorova i mnogim drugim \u010dimbenicima. Sveobuhvatno mjerenje metrike u\u010dinkovitosti u takvim mre\u017eama je slo\u017een posao, jer je potrebno istovremeno procijeniti vrijeme obrade zahtjeva i na klijentima i na peer-ovima (blockchain \u010dvorovima). Problemi u bilo kojem od p2p mehanizama, nepravilno uklanjanje i ke\u0161iranje podataka, neu\u010dinkovito upravljanje popisima aktivnih peer-ova i mnogi drugi \u010dimbenici mogu izazvati ka\u0161njenja koja uti\u010du na u\u010dinkovitost cijele mre\u017ee, a taj bottleneck je najslo\u017eeniji za analizu, testiranje i tuma\u010denje rezultata.<\/p>\n

    <\/p>\n

    Obrada lanca blokova i a\u017euriranje state database<\/h2>\n

    <\/p>\n

    Najva\u017eniji dio rada blockchain-a je algoritam konsenzusa, njegova primjena na nove blokove dobivene iz mre\u017ee i obrada transakcija sa zapisom rezultata u state database. Dodavanje novog bloka u lancu i odabir glavnog lanca koji slijedi trebaju raditi maksimalno brzo. Me\u0111utim, u stvarnom \u017eivotu 'trebalo bi' ne zna\u010di 'radi', i mo\u017eemo, na primjer, zamisliti situaciju u kojoj se dve duge konkurentske lance neprekidno prebacuju izme\u0111u sebe, mijenjaju\u0107i metapodatke tisu\u0107a transakcija u pool-u na svakom prebacivanju, i stalno vra\u0107aju\u0107i stanje state database. Ova faza je, s obzirom na definiranje bottlenecka, jednostavnija od mre\u017enog p2p sloja, jer su izvr\u0161enja transakcija i algoritam konsenzusa strogo determinirani, i mjerenje bilo \u010dega ovdje je lak\u0161e.
    \nGlavno je ne pobrkati slu\u010dajno pogor\u0161anje performansi ove faze s problemima mre\u017ee \u2014 nodovi sporije isporu\u010duju blokove i informacije o glavnom lancu i za vanjskog klijenta to mo\u017ee izgledati kao spora mre\u017ea, iako se problem krije potpuno na drugom mjestu.<\/p>\n

    <\/p>\n

    Za optimizaciju performansi u ovoj fazi korisno je prikupljati i nadzirati metrike s samih nodova, uklju\u010duju\u0107i one koje se odnose na a\u017euriranje state-database: broj blokova obra\u0111enih na nodu, njihova veli\u010dina, broj transakcija, broj prebacivanja izme\u0111u forkova lanaca, broj nevaljanih blokova, vrijeme rada virtualne ma\u0161ine, vrijeme pohrane podataka itd. To \u0107e omogu\u0107iti da ne pobrkamo mre\u017ene probleme s gre\u0161kama u algoritmima procesiranja lanaca.<\/p>\n

    <\/p>\n

    Virtualna ma\u0161ina koja procesira transakcije mo\u017ee biti koristan izvor informacija koje mogu optimizirati rad blockchaina. Koli\u010dina alokacija memorije, broj read\/write instrukcija i druge metrike vezane za u\u010dinkovitost izvr\u0161enja koda ugovora mogu dati mnogo korisnih informacija programerima. U isto vrijeme, pametni ugovori su programi, \u0161to zna\u010di da teoretski mogu tro\u0161iti sve resurse: cpu\/memory\/network\/storage, pa je procesiranje transakcija prili\u010dno neodre\u0111ena faza koja se tako\u0111er znatno mijenja pri prijelazu izme\u0111u verzija i kodiranju ugovora. Stoga su metrike koje se odnose na procesiranje transakcija tako\u0111er potrebne za u\u010dinkovitu optimizaciju performansi blockchaina.<\/p>\n

    <\/p>\n

    Obavje\u0161tavanje klijenta o aktivaciji transakcije u blockchainu<\/h2>\n

    <\/p>\n

    Ovo je zavr\u0161na faza primanja blockchain servisa od strane klijenta. U usporedbi s drugim fazama, ovdje nema velikih tro\u0161kova, no i dalje je potrebno uzeti u obzir mogu\u0107nost primanja opse\u017enog odgovora od \u010dvora (na primjer, pametan ugovor koji vra\u0107a niz podataka). U svakom slu\u010daju, ovaj trenutak je najva\u017eniji za onoga tko je postavio pitanje 'kolika je tps u va\u0161em blockchainu?', jer se u tom trenutku bilje\u017ei vrijeme primanja usluge. <\/p>\n

    <\/p>\n

    Na ovom mjestu mora biti zabilje\u017eeno ukupno vrijeme koje je klijent proveo \u010dekaju\u0107i odgovor od blockchaina, to je vrijeme koje \u0107e korisnik o\u010dekivati kao potvrdu u svojoj aplikaciji, a optimizacija tog vremena je glavni zadatak programera.<\/p>\n

    <\/p>\n

    Zaklju\u010dak<\/h1>\n

    <\/p>\n

    Kao rezultat, mogu\u0107e je opisati tipove operacija koje se izvode u blockchainima i podijeliti ih u nekoliko kategorija:<\/p>\n

    <\/p>\n

      \n
    1. kriptografske transformacije, izrada dokaza<\/li>\n
    2. peer-to-peer umre\u017eavanje, replikacija transakcija i blokova<\/li>\n
    3. procesiranje transakcija, izvr\u0161avanje pametnih ugovora<\/li>\n
    4. primjena promjena u blockchainu na state database, a\u017euriranje podataka o transakcijama i blokovima<\/li>\n
    5. read-only upiti na state database, API blockchain \u010dvorova, subscription servisi <\/li>\n<\/ol>\n

      <\/p>\n

      Uop\u0107e, tehni\u010dki zahtjevi za \u010dvorove modernih blockchaina su izuzetno zahtjevni - brzi CPU za kriptografiju, velika koli\u010dina RAM-a za pohranu i brzo pristupanje state databaseu, mre\u017ena interakcija koja koristi veliki broj istovremeno otvorenih veza, obiman storage. Ovi visoki zahtjevi i mno\u0161tvo razli\u010ditih tipova operacija neizbje\u017eno dovode do situacije da resursi \u010dvorova mogu biti nedovoljni, a tada bilo koja od razmatranih faza mo\u017ee postati usko grlo za ukupnu u\u010dinkovitost mre\u017ee.<\/p>\n

      <\/p>\n

      Prilikom razvoja i ocjenjivanja performansi blockchaina, morat \u0107ete uzeti u obzir sve te aspekte. Za to je potrebno prikupljati i analizirati metrike istovremeno s klijentima i \u010dvorovima mre\u017ee, tra\u017eiti korelacije me\u0111u njima, ocjenjivati vrijeme pru\u017eanja usluga klijentima, uzimati u obzir sve osnovne resurse: CPU\/memorija\/mre\u017ea\/pohrana, razumjeti kako se koriste i utje\u010du jedni na druge. Sve to \u010dini usporedbe brzina razli\u010ditih blockchainova u obliku 'koliko TPS' izuzetno nezahvalnim zadatkom, s obzirom da postoji ogroman broj razli\u010ditih konfiguracija i stanja. U velikim centraliziranim sustavima, klasterima od stotina servera, ti problemi su tako\u0111er slo\u017eeni i zahtijevaju prikupljanje velikog broja razli\u010ditih metrika, dok su u blockchainu, zbog p2p mre\u017ea, virtualnih ma\u0161ina, pametnih ugovora i unutarnje ekonomije, stupnjevi slobode znatno ve\u0107i, \u0161to \u010dini testove \u010dak i na nekoliko servera nepredvidivima i pokazuje samo vrlo pribli\u017ene vrijednosti koje jedva imaju veze s realno\u0161\u0107u.<\/p>\n

      <\/p>\n

      Zato, prilikom razvoja u jezgru blockchaina, za procjenu performansi i odgovor na pitanje 'je li se pobolj\u0161alo u odnosu na pro\u0161li put', koristimo prili\u010dno slo\u017een softver koji orkestrira pokretanje blockchaina s desecima \u010dvorova i automatskim pokretanjem benchmarka te prikupljanjem metrika. Bez tih informacija izuzetno je te\u0161ko otkloniti gre\u0161ke u protokolima koji rade s brojnim sudionicima.<\/p>\n

      <\/p>\n

      Dakle, kada dobijete pitanje 'koliko TPS u va\u0161em blockchainu?', ponudite sugovorniku \u010daj i provjerite je li spreman upoznati se s desecima grafikona, kao i saslu\u0161ati sve tri kutije problema s performansama blockchaina te va\u0161e prijedloge za njihovo rje\u0161avanje...<\/p>\n

      Izvor: 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\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\udd47Koliko TPS ima va\u0161 blockchain? | ProHoster","description":"Omiljeno pitanje o bilo kojem distribuiranom sustavu od netehni\u010dkog stru\u010dnjaka je 'Koliko TPS ima va\u0161 blockchain?'","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/36157","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=36157"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/36157\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=36157"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=36157"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=36157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}