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

Det mest stillede sp\u00f8rgsm\u00e5l om ethvert distribueret system fra en ikke-teknisk person er: \u201cHvor mange tps har jeres blockchain?\u201d. Det tal, der gives som svar, har dog sj\u00e6ldent noget at g\u00f8re med det, som sp\u00f8rgeren \u00f8nsker at h\u00f8re. I virkeligheden ville sp\u00f8rgsm\u00e5let v\u00e6re: \u201cEr jeres blockchain egnet til mine forretningskrav?\u201d, og disse krav handler ikke om et enkelt tal, men om en r\u00e6kke betingelser \u2014 herunder redundans i netv\u00e6rket, finalitetskrav, st\u00f8rrelser, karakteren af transaktioner og mange andre parametre. S\u00e5 svaret p\u00e5 sp\u00f8rgsm\u00e5let \u201chvor mange tps\u201d vil n\u00e6ppe v\u00e6re simpelt, og det vil n\u00e6sten aldrig v\u00e6re fuldst\u00e6ndigt. Et distribueret system med titusinder og hundredevis af noder, der udf\u00f8rer ret komplekse beregninger, kan befinde sig i et enormt antal forskellige tilstande, afh\u00e6ngigt af netv\u00e6rkets tilstand, indholdet af blockchainen, tekniske fejl, \u00f8konomiske problemer, angreb p\u00e5 netv\u00e6rket og mange andre \u00e5rsager. De faser, hvor der kan opst\u00e5 pr\u00e6stationsproblemer, adskiller sig fra traditionelle tjenester, og serveren i blockchain-netv\u00e6rket er en netv\u00e6rkstjeneste, der kombinerer funktionaliteten af en database, webserver og torrent-klient, hvilket g\u00f8r den ekstremt kompleks med hensyn til belastningsprofilen p\u00e5 alle undersystemer: CPU, hukommelse, netv\u00e6rk, lagring.<\/p>\n

<\/p>\n

Det viser sig, at decentrale netv\u00e6rk og blockchains er ret specifik og uvant software for udviklere af centraliseret software. Derfor vil jeg gerne belyse de v\u00e6sentlige aspekter af pr\u00e6station og robusthed i decentrale netv\u00e6rk, tilgange til m\u00e5ling af dem og identificering af flaskehalse. Vi vil se p\u00e5 forskellige pr\u00e6stationsproblemer, der begr\u00e6nser hastigheden af tjenesteydelser til blockchain-brugere og bem\u00e6rke de s\u00e6rlige tr\u00e6k, der kendetegner denne type software.<\/p>\n

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

Faserne for anmodning om service fra blockchain-klienten<\/h2>\n

<\/p>\n

For a fair assessment of the quality of any reasonably complex service, it is necessary to consider not only the average values but also the maximum\/minimum, median, and percentiles. Theoretically, one could speak of 1000 tps in some blockchain, but if 900 transactions were completed at a high speed while 100 'stalled' for several seconds, then the average time calculated across all transactions is not quite an honest metric for a client who could not complete a deal in a few seconds. Temporary 'pits' caused by skipped consensus rounds or network splits can severely undermine a service that demonstrated excellent performance in test environments.<\/p>\n

<\/p>\n

To identify such bottlenecks, it's crucial to have a thorough understanding of the stages where a real blockchain may encounter difficulties in serving users. Let's describe the transaction delivery and processing cycle, as well as how to obtain a new state of the blockchain, from which the client can verify 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 chooses one of the nodes and sends their transaction to it<\/li>\n
  4. the client subscribes to updates from the state's database of the node, waiting for the results of their transaction execution<\/li>\n
  5. the node disseminates the transaction across the p2p network<\/li>\n
  6. one or more 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 spreads the new block across the p2p network<\/li>\n
  9. the new block is delivered to the node that the client queries<\/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

    Lad os nu se n\u00e6rmere p\u00e5 disse trin og beskrive potentielle ydelsesproblemer i hvert trin. I mods\u00e6tning til centraliserede systemer vil vi ogs\u00e5 se p\u00e5 kodeudf\u00f8relse p\u00e5 netv\u00e6rksklienter. Det er ganske ofte, at tps-m\u00e5linger for behandlingstiden for transaktioner indsamles fra noder og ikke fra klienten \u2014 det er ikke helt retf\u00e6rdigt. Klienten er ligeglad med, hvor hurtigt noden har behandlet hans transaktion; det vigtigste for ham er, hvorn\u00e5r den p\u00e5lidelige information om denne transaktion, der er inkluderet i blockchainen, bliver tilg\u00e6ngelig for ham. Netop denne m\u00e5ling er i virkeligheden tiden for transaktionsudf\u00f8relsen. Dette betyder, at forskellige klienter, selv n\u00e5r de sender den samme transaktion, kan f\u00e5 helt forskellige tider, som afh\u00e6nger af kanalen, belastningen og nodens n\u00e6rhed, osv. S\u00e5 det er helt n\u00f8dvendigt at m\u00e5le denne tid p\u00e5 klienterne, da det netop er denne parameter, der skal optimeres.<\/p>\n

    <\/p>\n

    Forberedelse af transaktionen p\u00e5 klientsiden<\/h2>\n

    <\/p>\n

    Lad os starte med de to f\u00f8rste punkter: transaktionen dannes og signeres af klienten. Underligt nok kan dette ogs\u00e5 v\u00e6re et flaskehalsproblem for blockchainens ydeevne set fra klientens perspektiv. Dette er uvant for centraliserede tjenester, som h\u00e5ndterer alle beregninger og dataoperationer selv, mens klienten blot forbereder en kort foresp\u00f8rgsel, der har potentiale til at anmode om store m\u00e6ngder data eller beregninger og modtage det f\u00e6rdige resultat. I blockchain-teknologier bliver klientkoden mere og mere kraftfuld, mens blockchain-kernen bliver mere og mere letv\u00e6gts, og omfattende beregningsopgaver er blevet standard at give til klientsoftwaren. I blockchain findes der klienter, som kan forberede \u00e9n transaktion i ret lang tid (jeg taler om forskellige merkle-beviser, succinct proofs, threshold-signaturer og andre komplekse operationer p\u00e5 klientsiden). Et godt eksempel p\u00e5 let on-chain verifikation og tung transaktionsforberedelse p\u00e5 klienten er beviset for medlemskab i en liste baseret p\u00e5 Merkle-tr\u00e6et, her er... artikel<\/a><\/noindex>.<\/p>\n

    <\/p>\n

    Husk ogs\u00e5, at klientsystemet ikke blot sender transaktioner til blokchainen, men f\u00f8rst anmoder om blokchainens tilstand \u2014 og denne aktivitet kan p\u00e5virke netv\u00e6rksbelastningen og blokchain-noderne. N\u00e5r du foretager m\u00e5linger, kan det derfor v\u00e6re fornuftigt at efterligne klientkodens adf\u00e6rd s\u00e5 fuldst\u00e6ndigt som muligt. Selvom dit blokchain har almindelige letv\u00e6gtsklienter, der blot s\u00e6tter en almindelig digital underskrift p\u00e5 en simpel transaktion for overf\u00f8rsel af et aktiv, bliver den m\u00e6ngde beregninger, der skal udf\u00f8res p\u00e5 klienten, med hvert \u00e5r st\u00f8rre, krypteringsalgoritmerne styrkes, og denne del af behandlingen kan blive til en betydelig flaskehals i fremtiden. V\u00e6r derfor opm\u00e6rksom og lad v\u00e6re med at overse en situation, hvor en transaktion, der varer 3,5 sekunder, bruger 2,5 sekunder p\u00e5 forberedelse og underskrift af transaktionen, og 1,0 sekunder p\u00e5 at sende til netv\u00e6rket og vente p\u00e5 svar. For at vurdere risikoen for denne flaskehals skal du indsamle m\u00e5linger fra klientmaskiner og ikke kun fra blokchain-noder.<\/p>\n

    <\/p>\n

    Afsendelse af transaktion og overv\u00e5gning af dens status<\/h2>\n

    <\/p>\n

    N\u00e6ste skridt er at sende transaktionen til den valgte blokchain-node og f\u00e5 status for dens accept i transaction poolen. Dette skridt ligner en almindelig databaseforesp\u00f8rgsel; noden skal registrere transaktionen i puljen og begynde at sprede information om den via p2p-netv\u00e6rket. Tilgangen til at vurdere ydeevnen her ligner vurderingen af traditionelle mikrotjenester i Web API, idet selve transaktionerne i blokchains kan opdateres og aktivt \u00e6ndre status. Generelt kan opdateringen af informationen om en transaktion i nogle blokchains ske flere gange, for eksempel n\u00e5r der er skift mellem forkerne i k\u00e6den, eller n\u00e5r BP informerer om deres hensigt om at inkludere transaktionen i en blok. Begr\u00e6nsninger p\u00e5 st\u00f8rrelsen af denne pulje og antallet af transaktioner i den kan p\u00e5virke blokchainens ydeevne. Hvis transaktionspuljen er fyldt til den maksimalt mulige st\u00f8rrelse eller ikke kan rummes i hukommelsen, kan netv\u00e6rkets ydeevne falde dramatisk. Blokchains har ikke centraliserede midler til at beskytte mod str\u00f8mme af st\u00f8jende beskeder, og hvis blokchainen underst\u00f8tter store transaktioner med lave gebyrer, kan det f\u00f8re til overbelastning af transaktionspuljen \u2014 dette er endnu en potentiel flaskehals for ydeevnen.<\/p>\n

    <\/p>\n

    In blockchains, a client sends a transaction to any node of the blockchain they prefer; the hash of the transaction is usually known to the client even before sending it, so all they need to do is establish a connection and then wait for the blockchain to change its state, incorporating their transaction. It is noteworthy that measuring 'tps' can yield completely different results depending on the method of connecting to the node. This could be a regular HTTP RPC or WebSocket, which allows for implementing the 'subscribe' pattern. In the latter case, the client will receive a notification sooner, and the node will use fewer resources (mainly memory and traffic) to respond about the transaction status. Therefore, when measuring 'tps', it is crucial to take into account how clients connect to nodes. Consequently, to assess the risks of this bottleneck, blockchain benchmarks should be able to emulate clients using both WebSocket and HTTP RPC requests in proportions that correspond to real networks, as well as vary the nature and size of transactions.<\/p>\n

    <\/p>\n

    For at vurdere risici for denne flaskehals er det ogs\u00e5 n\u00f8dvendigt at indsamle metrics fra klientmaskiner, ikke kun fra blockchain-noder.<\/p>\n

    <\/p>\n

    Transmission af transaktioner og blokke over p2p-netv\u00e6rk<\/h2>\n

    <\/p>\n

    I blockchain-netv\u00e6rk bruges peer-to-peer (p2p) netv\u00e6rk til at transmitterer transaktioner og blokke mellem deltagerne. Transaktioner spredes i netv\u00e6rket, startet fra en af noderne, indtil de n\u00e5r til peer-block producers, som pakker transaktionerne i blokke og ved hj\u00e6lp af det samme p2p-netv\u00e6rk spreder de nye blokke til alle noder i netv\u00e6rket. Grundlaget for de fleste moderne p2p-netv\u00e6rk er forskellige modifikationer af Kademlia-protokollen. Her er<\/a><\/noindex> en god kort oversigt over denne protokol, og her<\/a><\/noindex> \u2014 en artikel med forskellige m\u00e5linger i BitTorrent-netv\u00e6rket, som g\u00f8r det muligt at forst\u00e5, at denne type netv\u00e6rk er mere kompleks og mindre forudsigelig end et stift konfigureret netv\u00e6rk af en centraliseret tjeneste. Derudover, her<\/a><\/noindex> en artikel om m\u00e5ling af forskellige interessante metrics for Ethereum-noder.<\/p>\n

    <\/p>\n

    Kort sagt, hver peer i s\u00e5danne netv\u00e6rk underst\u00f8tter sin egen dynamiske liste over andre peers, som den anmoder om blokke af information adresseret efter indhold. Ved modtagelse af en anmodning leverer peer'en enten den \u00f8nskede information eller videresender anmodningen til den n\u00e6ste pseudotilf\u00e6ldige peer fra listen. N\u00e5r den modtager et svar, sender den det tilbage til den anmodende og gemmer det i et cache i et stykke tid, s\u00e5 den kan levere denne informationsblock hurtigere ved n\u00e6ste anmodning. P\u00e5 denne m\u00e5de ender popul\u00e6r information i mange caches hos mange peers, mens upopul\u00e6r information gradvist bliver overskrevet. Peers holder styr p\u00e5, hvor meget information de har sendt til hinanden, og netv\u00e6rket fors\u00f8ger at stimulere aktive udbydere ved at h\u00e6ve deres rating og give dem en h\u00f8jere servicegrad, mens inaktive deltagere automatisk fjernes fra peer- listerne.<\/p>\n

    <\/p>\n

    S\u00e5 nu skal transaktionen spredes over netv\u00e6rket, s\u00e5 block-producerne kan se den og inkludere den i blokken. Noden 'deler' aktivt den nye transaktion med alle interesserede og lytter til netv\u00e6rket og venter p\u00e5 den blok, hvori den n\u00f8dvendige transaktion vises, for at informere den ventende klient. Tiden, det tager for netv\u00e6rket at videregive oplysninger om nye transaktioner og blokke i p2p-netv\u00e6rk, afh\u00e6nger af et stort antal faktorer: antallet af \u00e6rlige, fungerende noder i n\u00e6rheden (set fra netv\u00e6rksperspektiv), 'opvarmningen' af cache'en i disse noder, st\u00f8rrelsen p\u00e5 blokke, transaktioner, karakteren af \u00e6ndringer, netv\u00e6rkets geografi, antallet af noder og mange andre faktorer. Komplekse m\u00e5linger af ydeevne i s\u00e5danne netv\u00e6rk er en vanskelig opgave, da man samtidig skal evaluere behandlingstiden for foresp\u00f8rgsler b\u00e5de p\u00e5 klienter og p\u00e5 peer-noder (blockchain-noder). Problemer i nogen af p2p-mekanismerne, forkert udskiftning og caching af data, ineffektiv styring af aktive peer-lister, og mange andre faktorer kan f\u00f8re til forsinkelser, der p\u00e5virker effektiviteten af hele netv\u00e6rket, og denne flaskehals er den vanskeligste at analysere, teste og fortolke resultaterne fra.<\/p>\n

    <\/p>\n

    Behandling af blockchain k\u00e6den og opdatering af state database<\/h2>\n

    <\/p>\n

    Den vigtigste del af blockchainens funktion er konsensusalgoritmen, dens anvendelse p\u00e5 nye blokke, der indsamles fra nettet, og processeringen af transaktioner med indl\u00e6sning af resultater i state-databasen. Tilf\u00f8jelsen af en ny blok til k\u00e6den og den efterf\u00f8lgende valg af hovedk\u00e6den skal fungere s\u00e5 hurtigt som muligt. Men i det virkelige liv betyder 'skal' ikke n\u00f8dvendigvis 'fungerer', og man kan forestille sig en situation, hvor to lange konkurrerende k\u00e6der konstant skifter imellem hinanden, \u00e6ndrer metadata for tusindvis af transaktioner i puljen ved hvert skift og konstant producerer tilbagerulninger i state-databasen. Dette trin, i forhold til at bestemme flaskehalse, er lettere end det netv\u00e6rksp2p-lag, da udf\u00f8relsen af transaktioner og konsensusalgoritmen er strengt deterministiske, og det er lettere at m\u00e5le noget her.
    \nDet er vigtigt ikke at forveksle tilf\u00e6ldig degradering af ydeevnen i denne fase med netv\u00e6rksproblemer \u2014 noderne afleverer langsommere blokke og information om hovedk\u00e6den, og for en ekstern klient kan det se ud som et langsomt netv\u00e6rk, selvom problemet ligger et helt andet sted.<\/p>\n

    <\/p>\n

    For at optimere ydeevnen p\u00e5 dette trin er det nyttigt at indsamle og overv\u00e5ge metrikker fra selve noderne og inkludere dem, der vedr\u00f8rer opdateringen af state-databasen: antallet af blokke, der behandles p\u00e5 noden, deres st\u00f8rrelse, antallet af transaktioner, antal skift mellem k\u00e6deforkene, antallet af ugyldige blokke, tiden for den virtuelle maskine, tidsrammen for datalagring osv. Dette vil hj\u00e6lpe med ikke at forveksle netv\u00e6rksproblemer med fejl i algoritmerne til behandling af k\u00e6der.<\/p>\n

    <\/p>\n

    Den virtuelle maskine, der behandler transaktioner, kan v\u00e6re en nyttig informationskilde, der kan optimere blockchainens funktion. Antallet af hukommelsesallokeringer, antallet af read\/write-instruktioner og andre metrikker vedr\u00f8rende effektiviteten af koden for kontrakter kan give meget nyttig information til udviklere. Samtidig er smarte kontrakter programmer, og derfor kan de i teorien forbruge enhver form for ressourcer: cpu\/memory\/network\/storage, s\u00e5 behandlingen af transaktioner er et ret usikkert trin, der desuden \u00e6ndrer sig betydeligt ved overgangen mellem versioner og ved \u00e6ndringer af kontraktkoden. Derfor er metrikker, der vedr\u00f8rer behandling af transaktioner, ogs\u00e5 n\u00f8dvendige for effektiv optimering af blockchainens ydeevne.<\/p>\n

    <\/p>\n

    Modtagelse af meddelelse til kunden om aktivering af transaktionen i blockchainen<\/h2>\n

    <\/p>\n

    Dette er den afsluttende fase for kunden til at modtage blockchain-tjenesten. I mods\u00e6tning til de andre faser er der ikke store driftsomkostninger her, men det er stadig vigtigt at tage h\u00f8jde for muligheden for, at kunden modtager et omfattende svar fra noden (f.eks. en smart kontrakt, der returnerer et dataramme). Under alle omst\u00e6ndigheder er dette \u00f8jeblik det mest betydningsfulde for dem, der stiller sp\u00f8rgsm\u00e5let 'hvor mange TPS er der i jeres blockchain?', da tidspunktet for modtagelse af service registreres netop her. <\/p>\n

    <\/p>\n

    Her skal der n\u00f8dvendigvis sendes den samlede tid, som kunden har brugt p\u00e5 at vente p\u00e5 svar fra blockchainen; det er denne tid, brugeren vil forvente at f\u00e5 bekr\u00e6ftet i sin applikation, og optimeringen af denne tid er hovedopgaven for udviklerne.<\/p>\n

    <\/p>\n

    Konklusion<\/h1>\n

    <\/p>\n

    Som et resultat kan man beskrive typerne af operationer, der udf\u00f8res i blockchainer, og opdele dem i flere kategorier:<\/p>\n

    <\/p>\n

      \n
    1. kryptografiske transformationer, opbygning af beviser<\/li>\n
    2. peer-to-peer netv\u00e6rk, replikation af transaktioner og blokke<\/li>\n
    3. behandling af transaktioner, udf\u00f8relse af smart kontrakter<\/li>\n
    4. anvendelse af \u00e6ndringer i blockchainen p\u00e5 state database, opdatering af data om transaktioner og blokke<\/li>\n
    5. read-only foresp\u00f8rgsler til state database, API for blockchain noden, abonnementsservicer <\/li>\n<\/ol>\n

      <\/p>\n

      Generelt er de tekniske krav til noderne i moderne blockchains meget strenge\u2014hurtige CPU'er til kryptografi, store m\u00e6ngder RAM for at gemme og hurtigt tilg\u00e5 state database, netv\u00e6rksinteraktion der bruger et stort antal \u00e5bne forbindelser samtidig, og plads til stor lagring. Disse h\u00f8je krav og den mangfoldighed af forskellige operationstyper f\u00f8rer uundg\u00e5eligt til, at ressourcerne hos noderne kan v\u00e6re utilstr\u00e6kkelige, og s\u00e5 kan ethvert af de ovenfor n\u00e6vnte trin blive en flaskehals for den samlede ydeevne i netv\u00e6rket.<\/p>\n

      <\/p>\n

      N\u00e5r du udvikler og vurderer blockchainers ydeevne, skal du tage h\u00f8jde for alle disse aspekter. Det indeb\u00e6rer at indsamle og analysere metrikker fra b\u00e5de klienter og netv\u00e6rksnoder, finde korrelationer mellem dem, vurdere tiden for servicelevering til kunderne, tage h\u00f8jde for alle de vigtigste ressourcer: CPU\/memory\/netv\u00e6rk\/opbevaring, samt forst\u00e5, hvordan de anvendes og p\u00e5virker hinanden. Alt dette g\u00f8r sammenligningen af hastighederne p\u00e5 forskellige blockchains i form af 'hvor mange TPS' til en uendelig vanskelig opgave, da der findes et enormt antal forskellige konfigurationer og tilstande. I store centraliserede systemer, klynger af hundreder af servere, er disse problemer ogs\u00e5 komplekse og kr\u00e6ver ogs\u00e5 indsamling af et stort antal forskellige metrikker, men i blockchains, p\u00e5 grund af p2p-netv\u00e6rk, virtuelle maskiner, der behandler kontrakter, og intern \u00f8konomi, er antallet af frihedsgrader meget st\u00f8rre, hvilket g\u00f8r test selv p\u00e5 flere servere ikke sigende og kun viser ekstremt omtrentlige v\u00e6rdier, som n\u00e6sten ikke har forbindelse til virkeligheden.<\/p>\n

      <\/p>\n

      Derfor, n\u00e5r vi udvikler i kernen af blockchain, bruger vi ret kompleks software til at vurdere ydeevne og besvare sp\u00f8rgsm\u00e5let 'er det blevet bedre sammenlignet med sidste gang'. Denne software orkestrerer opstarten af blockchainen med dusinvis af noder og automatisk k\u00f8rsel af benchmarks og indsamling af metrikker. Uden disse oplysninger er det ekstremt sv\u00e6rt at debugge protokoller, der arbejder med mange deltagere.<\/p>\n

      <\/p>\n

      S\u00e5 n\u00e5r du f\u00e5r sp\u00f8rgsm\u00e5let 'hvor mange TPS er der i jeres blockchain?', tilbyd din samtalepartner en kop te og sp\u00f8rg, om de er klar til at se ti grafer og h\u00f8re om alle tre kasser af blockchainers ydeevneproblemer samt dine forslag til l\u00f8sninger...<\/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 der i din blockchain? | ProHoster","description":"Det mest popul\u00e6re sp\u00f8rgsm\u00e5l om ethvert distribueret system fra en ikke-teknisk specialist er \"Hvor mange TPS er der i din blockchain?\".","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/36157","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=36157"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/36157\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=36157"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=36157"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=36157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}