{"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\/no\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","title":{"rendered":"Hvor mange TPS har blockchain din?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Det mest stilte sp\u00f8rsm\u00e5let fra ikke-tekniske spesialister om ethvert distribuert system er \"Hvor mange tps har blokkjeden deres?\". Men tallet som blir gitt som svar, har vanligvis lite \u00e5 gj\u00f8re med det sp\u00f8rsm\u00e5let de \u00f8nsket \u00e5 stille. I realiteten \u00f8nsket de \u00e5 sp\u00f8rre \"passer blokkjeden deres til mine forretningsbehov?\", og disse behovene er ikke ett tall, men en rekke betingelser \u2013 her er b\u00e5de nettverksrobusthet, krav til endelighet, st\u00f8rrelser, karakteren av transaksjonene og mange andre parametere. S\u00e5 svaret p\u00e5 sp\u00f8rsm\u00e5let \"hvor mange tps\" vil sjelden v\u00e6re enkelt, og nesten aldri v\u00e6re komplett. Et distribuert system med titalls og hundretalls noder som utf\u00f8rer ganske komplekse beregninger, kan befinne seg i en enorm mengde forskjellige tilstander, knyttet til nettverkstilstanden, innholdet i blokkjeden, tekniske feil, \u00f8konomiske problemer, angrep p\u00e5 nettverket og mange andre \u00e5rsaker. Faser der ytelsesproblemer kan oppst\u00e5 er forskjellige fra tradisjonelle tjenester, og serveren til blokkjedenettverket er en nettjeneste som kombinerer funksjonaliteten til en database, web-server og torrent-klient, noe som gj\u00f8r den ekstremt komplisert med hensyn til belastningsprofil p\u00e5 alle undersystemer: prosessor, minne, nettverk, lagring.<\/p>\n

<\/p>\n

Det har vist seg at desentraliserte nettverk og blokkjeder er ganske spesifikke og uvante programmer for utviklere av sentralisert programvare. Derfor \u00f8nsker jeg \u00e5 belyse viktige aspekter ved ytelse og robusthet i desentraliserte nettverk, tiln\u00e6rminger til deres m\u00e5ling og identifisering av flaskehalser. Vi vil se p\u00e5 ulike ytelsesproblemer som begrenser hastigheten p\u00e5 tjenesteleveransen til brukerne av blokkjeder, og merke oss de s\u00e6rtrekkene som er typiske for denne typen programvare.<\/p>\n

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

Faser i foresp\u00f8rselen om tjeneste fra blokkjeden av kunden.<\/h2>\n

<\/p>\n

For an honest assessment of the quality of any moderately complex service, it is essential to consider not just the average values but also the maximums\/minimums, medians, and percentiles. Theoretically, one can claim 1000 tps in a blockchain, but if 900 transactions are executed at high speed while 100 'hang' for several seconds, then the average time calculated across all transactions is not a fair metric for a client who couldn't complete a deal within a few seconds. Temporal 'pits' caused by missed consensus rounds or network partitioning can significantly impair a service that demonstrated excellent performance on test benches.<\/p>\n

<\/p>\n

To identify such bottlenecks, it's crucial to understand the stages where a real blockchain might face difficulties in servicing users. Let's describe the cycle of delivery and processing of a transaction, as well as how to obtain the new state of the blockchain from which the client can ensure that their transaction has been processed and accounted for.<\/p>\n

<\/p>\n

    \n
  1. the transaction is formed on the client<\/li>\n
  2. the transaction is signed on the client<\/li>\n
  3. the client selects one of the nodes and sends their transaction to it<\/li>\n
  4. the client subscribes to updates from the state database node, waiting for the results of their transaction execution<\/li>\n
  5. the node propagates the transaction through the p2p network<\/li>\n
  6. one or several BPs (block producers) process the accumulated transactions, updating the state database<\/li>\n
  7. the BP forms a new block after processing the required number of transactions<\/li>\n
  8. the BP propagates the new block through the p2p network<\/li>\n
  9. the new block is delivered to the node that the client is addressing<\/li>\n
  10. the node updates the state database<\/li>\n
  11. the node sees the update concerning the client and sends them a notification about the transaction<\/li>\n<\/ol>\n

    <\/p>\n

    La oss n\u00e5 g\u00e5 n\u00e6rmere inn p\u00e5 disse trinnene og beskrive potensielle ytelsesproblemer i hvert trinn. I motsetning til sentraliserte systemer vil vi ogs\u00e5 se p\u00e5 utf\u00f8relsen av koden p\u00e5 klientene i nettverket. Det er ganske vanlig at n\u00e5r tps m\u00e5les, samles behandlingstiden for transaksjoner fra noder, ikke fra klienten \u2014 dette er ikke helt rettferdig. Klienten bryr seg ikke om hvor raskt noden har prosessert transaksjonen sin; det viktigste for dem er \u00f8yeblikket n\u00e5r p\u00e5litelig informasjon om denne transaksjonen, som er inkludert i blokkjeden, blir tilgjengelig for dem. Denne metrikken er i hovedsak tiden det tar \u00e5 utf\u00f8re en transaksjon. Dette betyr at forskjellige klienter, selv om de sender den samme transaksjonen, kan f\u00e5 helt forskjellige tider, avhengig av kanalen, belastning og avstand til noden, osv. Derfor er det helt n\u00f8dvendig \u00e5 m\u00e5le denne tiden p\u00e5 klientene, fordi det er denne parameteren som m\u00e5 optimaliseres.<\/p>\n

    <\/p>\n

    Forberedelse av transaksjonen p\u00e5 klientsiden<\/h2>\n

    <\/p>\n

    Vi begynner med de f\u00f8rste to punktene: transaksjonen blir dannet og signert av klienten. Merkelig nok kan dette ogs\u00e5 v\u00e6re et flaskehalser for ytelsen til blokkjeden sett fra klientens perspektiv. Dette er uvanlig for sentraliserte tjenester, som tar seg av alle beregninger og databehandling, mens klienten bare lager en kort foresp\u00f8rsel som kan be om store datamengder eller beregninger, og f\u00e5r et klart resultat. I blokkjeder blir klientkoden stadig mer og mer kraftig, mens blokkjernene blir lettere, og store beregningsoppgaver overf\u00f8res ofte til klientprogramvaren. I blokkjeder finnes det klienter som kan bruke lang tid p\u00e5 \u00e5 forberede \u00e9n transaksjon (jeg snakker om ulike merkle-prover, kortfattede prover, threshold-signaturer og andre komplekse operasjoner p\u00e5 klientsiden). Et godt eksempel p\u00e5 lett on-chain verifisering og tung forberedelse av transaksjonen p\u00e5 klienten er bevis p\u00e5 tilh\u00f8righet til en liste basert p\u00e5 Merkle-tre, her. article<\/a><\/noindex>.<\/p>\n

    <\/p>\n

    Det er ogs\u00e5 viktig \u00e5 huske at klientkoden ikke bare sender transaksjoner til blokkjeden, men f\u00f8rst ber om tilstanden til blokkjeden \u2014 og denne aktiviteten kan p\u00e5virke belastningen p\u00e5 nettverket og blokkjedenoder. S\u00e5 n\u00e5r du tar m\u00e5linger, vil det v\u00e6re fornuftig \u00e5 emulere klientkoden s\u00e5 n\u00f8yaktig som mulig. Selv om det i blokkjeden din er vanlige lette klienter som setter en enkel digital signatur p\u00e5 en enkel transaksjon for overf\u00f8ring av et hvilket som helst aktivum, blir det motstridende beregninger p\u00e5 klienten stadig mer omfattende hvert \u00e5r, kryptografiske algoritmer blir mer robuste, og denne delen av prosesseringen kan bli en betydelig flaskehals i fremtiden. V\u00e6r derfor forsiktig, og ikke oversett situasjonen der, i en transaksjon som varer i 3,5 sekunder, g\u00e5r 2,5 sekunder til forberedelse og signering av transaksjonen, og 1,0 sekunder til sending til nettverket og venting p\u00e5 svar. For \u00e5 vurdere risikoen for at denne flaskehalsen kan oppst\u00e5, b\u00f8r metrikkene samles inn fra klientmaskiner, ikke bare fra blokkjedenoder.<\/p>\n

    <\/p>\n

    Sende transaksjon og overv\u00e5ke dens status<\/h2>\n

    <\/p>\n

    Neste steg er \u00e5 sende transaksjonen til den valgte blokkjedenoden og motta status for aksept i transaksjonspoolen. Dette trinnet ligner p\u00e5 en vanlig databaseforesp\u00f8rsel; noden m\u00e5 registrere transaksjonen i poolen og begynne \u00e5 spre informasjon om den gjennom p2p-nettverket. Tiln\u00e6rmingen til ytelsesevaluering her ligner p\u00e5 evalueringen av tradisjonelle mikrotjenester i Web API, ettersom selve transaksjonene i blokkjeder kan oppdateres og aktivt endre status. Generelt kan oppdateringen av informasjonen om transaksjonen i enkelte blokkjeder skje flere ganger, for eksempel ved skifting mellom forker av kjeden eller n\u00e5r BP varsler om hensikten om \u00e5 inkludere transaksjonen i en blokk. Begrensninger i volumet av denne poolen og antall transaksjoner i den kan p\u00e5virke ytelsen til blokkjeden. Hvis transaksjonspoolen er fullstappet til maksimal st\u00f8rrelse, eller ikke f\u00e5r plass i det tilgjengelige minnet \u2014 kan nettverksytelsen falle dramatisk. Blokkjeder har ikke sentraliserte beskyttelsesmetoder mot str\u00f8mmen av s\u00f8ppelmeldinger, og hvis blokkjeden st\u00f8tter transaksjoner med stort volum og lave gebyrer, kan det f\u00f8re til overfylling av transaksjonspoolen \u2014 dette er enda en potensiell flaskehals for ytelse.<\/p>\n

    <\/p>\n

    In blockchains, the client submits a transaction to any node of the blockchain they prefer; the transaction hash is usually known to the client even before sending, so all they need is to establish a connection and then wait for the blockchain to change its state by including their transaction. It is worth noting that measuring 'tps' can yield vastly different results depending on the connection method to the blockchain node. This could be via standard HTTP RPC or WebSocket, which allows implementing the 'subscribe' pattern. In the latter case, the client will receive notifications sooner, and the node will consume fewer resources (mainly memory and bandwidth) in responding about the transaction's status. Therefore, when measuring 'tps', the method of connecting clients to nodes must also be taken into account. Consequently, to assess the risks of this bottleneck, the blockchain benchmark should be capable of emulating clients with both WebSocket and HTTP RPC requests, in proportions corresponding to real networks, as well as varying the nature and size of transactions.<\/p>\n

    <\/p>\n

    For \u00e5 vurdere risikoen for at denne flaskehalsen oppst\u00e5r, er det ogs\u00e5 n\u00f8dvendig \u00e5 samle inn data fra kundemaskiner, ikke bare fra blokkjedene.<\/p>\n

    <\/p>\n

    Overf\u00f8ring av transaksjoner og blokker via p2p-nettverk<\/h2>\n

    <\/p>\n

    I blokkjedene brukes peer-to-peer (p2p) nettverking for \u00e5 overf\u00f8re transaksjoner og blokker mellom deltakerne. Transaksjoner sprer seg i nettverket, begynner fra en av nodene, til de n\u00e5r peerene-block producerne, som pakker transaksjonene inn i blokker og bruker den samme p2p-teknologien til \u00e5 spre de nye blokkene til alle nodene i nettverket. Grunnlaget for de fleste moderne p2p-nettverk er ulike modifikasjoner av Kademlia-protokollen. Her er<\/a><\/noindex> en god kort oversikt over denne protokollen, og her<\/a><\/noindex> \u2014 en artikkel med ulike m\u00e5linger i BitTorrent-nettverket, som kan hjelpe til med \u00e5 forst\u00e5 at denne typen nettverk er mer kompleks og mindre forutsigbar enn en stivt konfigurert nettverk av en sentralisert tjeneste. Ogs\u00e5, her<\/a><\/noindex> en artikkel om m\u00e5ling av ulike interessante metrikker for Ethereum-noder.<\/p>\n

    <\/p>\n

    Kort sagt, hver peer i slike nettverk opprettholder sin egen dynamiske liste over andre peer-er, hvor den foresp\u00f8r informasjon om blokker adressert etter innhold. N\u00e5r en foresp\u00f8rsel mottas, gir peer-en enten den n\u00f8dvendige informasjonen, eller den videresender foresp\u00f8rselen til en tilfeldig valgt peer fra listen. N\u00e5r den f\u00e5r et svar, videresender den det til den som spurte og cacher informasjonen en stund, slik at denne blokken kan leveres raskere neste gang. Dermed ender popul\u00e6r informasjon opp i mange cacher hos et stort antall peer-er, mens upopul\u00e6r informasjon gradvis blir presset ut. Peer-er holder oversikt over hvem som har sendt hva til hvem, og nettverket pr\u00f8ver \u00e5 stimulere aktive delere ved \u00e5 heve rangeringen deres og gi dem et h\u00f8yere serviceniv\u00e5, mens det automatisk fjerner inaktive deltakere fra peer-listene.<\/p>\n

    <\/p>\n

    S\u00e5, m\u00e5 transaksjonen n\u00e5 distribueres over nettverket slik at block-producerne kan se den og inkludere den i blokken. Noden aktivt «deler» den nye transaksjonen med alle som \u00f8nsker det og lytter til nettverket, og venter p\u00e5 blokken hvor den n\u00f8dvendige transaksjonen vil dukke opp, for \u00e5 varsle den ventende klienten. Tiden det tar for nettverket \u00e5 overf\u00f8re informasjon om nye transaksjoner og blokker i p2p-nettverk avhenger av et sv\u00e6rt stort antall faktorer: antallet \u00e6rlige, fungerende noder i n\u00e6rheten (fra et nettverksperspektiv), «oppvarmingen» av cacheminnet til disse nodene, st\u00f8rrelsen p\u00e5 blokkene, transaksjonene, karakteren av endringene, geografien til nettverket, antallet noder og mange andre faktorer. Komplekse m\u00e5linger av ytelsesmetrikker i slike nettverk er en utfordrende oppgave, det er n\u00f8dvendig \u00e5 vurdere behandlingstiden for foresp\u00f8rslene b\u00e5de p\u00e5 klientene og p\u00e5 peerne (blockchain-nodene) samtidig. Problemer i noen av p2p-mekanismene, feilaktig utskifting og caching av data, ineffektiv h\u00e5ndtering av lister over aktive peerne, og mange andre faktorer kan f\u00f8re til forsinkelser som p\u00e5virker hele nettverkets effektivitet, og denne flaskehalsen er den mest utfordrende \u00e5 analysere, teste og tolke resultatene av.<\/p>\n

    <\/p>\n

    Prosesseringen av blokkekjeden og oppdatering av state-databasen.<\/h2>\n

    <\/p>\n

    Den viktigste delen av blokkjedens arbeid er konsensusalgoritmen, dens anvendelse p\u00e5 nye blokker mottatt fra nettverket og prosesseringen av transaksjoner med registrering av resultater i state database. \u00c5 legge til en ny blokk i kjeden og valget av hovedkjeden som f\u00f8lger med dette m\u00e5 fungere s\u00e5 raskt som mulig. Men, i det virkelige liv «m\u00e5» ikke bety «fungerer», og man kan for eksempel forestille seg en situasjon der to lange konkurrerende kjeder stadig bytter mellom hverandre, endrer metadataene til tusenvis av transaksjoner i puljen ved hvert bytte, og kontinuerlig ruller tilbake tilstanden i state database. Dette trinnet, n\u00e5r det gjelder \u00e5 identifisere flaskehalsene, er enklere enn det nettverksbaserte p2p-laget, da utf\u00f8relsen av transaksjoner og konsensusalgoritmen er strengt deterministiske, og det er enklere \u00e5 m\u00e5le noe her.
    \nDet viktigste er \u00e5 ikke forveksle tilfeldig nedgang i ytelsen p\u00e5 dette stadiet med nettverksproblemer \u2014 nodene gir tregere blokker og informasjon om hovedkjeden, og for en ekstern klient kan dette fremst\u00e5 som et sakte nett, selv om problemet ligger helt andre steder.<\/p>\n

    <\/p>\n

    For \u00e5 optimalisere ytelsen p\u00e5 dette stadiet er det nyttig \u00e5 samle og overv\u00e5ke metrikk fra selve nodene, og inkludere de som gjelder oppdateringen av statusdatabasen: antall blokker behandlet p\u00e5 noden, deres st\u00f8rrelse, antall transaksjoner, antall vekslinger mellom forgreiningene av kjeden, antall ugyldige blokker, tid brukt av den virtuelle maskinen, tid for datalagring osv. Dette vil hjelpe med \u00e5 ikke forveksle nettverksproblemer med feil i algoritmene for kjedeprosessering.<\/p>\n

    <\/p>\n

    Den prosesserende transaksjonsmaskinen kan v\u00e6re en nyttig informasjonskilde for \u00e5 optimere arbeidet med blockchain. Antall minnetildelinger, antall read\/write-instruksjoner og andre metrikker knyttet til effektiviteten av gjennomf\u00f8ringen av kontraktkode kan gi mye nyttig informasjon for utviklere. Samtidig er smarte kontrakter programmer, og dermed kan de teoretisk bruke enhver type ressurser: cpu\/memory\/network\/storage, s\u00e5 transaksjonsprosesseringen er et ganske ubestemt stadium, som for\u00f8vrig endres mye n\u00e5r man g\u00e5r mellom versjoner og ved endringer i kontraktkoden. Derfor er metrikker relatert til transaksjonsprosessering ogs\u00e5 n\u00f8dvendige for effektiv optimalisering av ytelsen til blockchain.<\/p>\n

    <\/p>\n

    Mottak av varsel fra kunden om aktivering av transaksjon i blokkjeden<\/h2>\n

    <\/p>\n

    Dette er den avsluttende fasen av tjenestemottak for kunden i blockchain, sammenlignet med de andre fasene er det ingen store kostnader her, men det er fortsatt viktig \u00e5 ta hensyn til muligheten for at kunden mottar et omfattende svar fra noden (for eksempel et smartkontrakt som returnerer et datamatrise). Uansett er dette \u00f8yeblikket det viktigste for den som stiller sp\u00f8rsm\u00e5let \u00abhvor mange TPS har deres blockchain?\u00bb, siden tiden for tjenestemottak registreres i dette \u00f8yeblikket. <\/p>\n

    <\/p>\n

    P\u00e5 dette stadiet er det viktig at den totale tiden kunden har brukt p\u00e5 \u00e5 vente p\u00e5 svaret fra blokkjeden blir sendt. Det er denne tiden brukeren vil forvente \u00e5 f\u00e5 bekreftet i applikasjonen sin, og det \u00e5 optimalisere denne tiden er hovedoppgaven for utviklerne.<\/p>\n

    <\/p>\n

    Konklusjon<\/h1>\n

    <\/p>\n

    Som et resultat kan man beskrive typene operasjoner som utf\u00f8res i blokkjeder og dele dem inn i flere kategorier:<\/p>\n

    <\/p>\n

      \n
    1. kryptografiske transformasjoner, oppbygging av bevis<\/li>\n
    2. peer-to-peer-nettverk, replikering av transaksjoner og blokker<\/li>\n
    3. behandling av transaksjoner, utf\u00f8relse av smartkontrakter<\/li>\n
    4. anvendelse av endringer i blokkjeden til state database, oppdatering av data om transaksjoner og blokker<\/li>\n
    5. read-only foresp\u00f8rsel til state database, API fra blokkjede-noden, abonnementstjenester <\/li>\n<\/ol>\n

      <\/p>\n

      Generelt er de tekniske kravene til nodene i moderne blokkjeder ekstremt strenge \u2014 det kreves raske CPU-er for kryptografi, stor mengde RAM slik at man kan lagre og raskt f\u00e5 tilgang til state database, nettverksinteraksjon som benytter mange samtidig \u00e5pne forbindelser, og betydelig lagring. Disse h\u00f8ye kravene og en overflod av forskjellige typer operasjoner f\u00f8rer uunng\u00e5elig til at nodene kan mangle ressurser, og da kan enhver av de vurderte trinnene bli en flaskehals for den samlede ytelsen i nettverket.<\/p>\n

      <\/p>\n

      Ved \u00e5 utvikle og vurdere ytelsen til blockchains, m\u00e5 du ta hensyn til alle disse punktene. For dette m\u00e5 du samle og analysere metrikker fra b\u00e5de kunder og noder i nettverket samtidig, lete etter korrelasjoner mellom dem, vurdere responstiden for kundene, ta hensyn til alle de grunnleggende ressursene: cpu\/minne\/nettverk\/lagring, forst\u00e5 hvordan de brukes og p\u00e5virker hverandre. Alt dette gj\u00f8r sammenligningen av hastighetene til ulike blockchains i form av 'hvor mange TPS' ekstremt takknemlig, ettersom det finnes et enormt antall forskjellige konfigurasjoner og tilstander. I store, sentraliserte systemer, klynger av hundrevis av servere, er disse problemene ogs\u00e5 komplekse og krever innsamling av mange forskjellige metrikker, men i blockchains, p\u00e5 grunn av p2p-nettverk, virtuelle maskiner som behandler kontrakter, intern \u00f8konomi, er antallet frihetsgrader mye st\u00f8rre, noe som gj\u00f8r at tester selv p\u00e5 flere servere er lite informativ og bare viser sv\u00e6rt omtrentlige verdier, nesten uten sammenheng med virkeligheten.<\/p>\n

      <\/p>\n

      Derfor, n\u00e5r vi utvikler i kjernen av blockchain, for \u00e5 vurdere ytelsen og svare p\u00e5 sp\u00f8rsm\u00e5let 'har det blitt bedre siden sist?', bruker vi ganske kompleks programvare som orkestrerer oppstarten av blockchain med dusinvis av noder og automatisk kj\u00f8ring av benchmark og innsamling av metrikker; uten denne informasjonen er det ekstremt vanskelig \u00e5 feils\u00f8ke protokoller som arbeider med mange deltakere.<\/p>\n

      <\/p>\n

      S\u00e5, n\u00e5r du mottar sp\u00f8rsm\u00e5let 'hvor mange TPS har deres blockchain?', tilby samtalepartneren en kopp te og sp\u00f8r om han er klar til \u00e5 se p\u00e5 et dusin diagrammer samt h\u00f8re om alle tre kasser med ytelsesproblemer fra blockchains og dine forslag til l\u00f8sninger\u2026<\/p>\n

      Kilde: 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\udd47Hvor mange TPS er det i blokkjeden din? | ProHoster","description":"Det mest popul\u00e6re sp\u00f8rsm\u00e5let fra en ikke-teknisk spesialist om enhver distribuert system er \u201cHvor mange TPS er det i blokkjeden din?\u201d.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","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\/no\/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\/no\/wp-json\/wp\/v2\/posts\/36157","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=36157"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/36157\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=36157"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=36157"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=36157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}