{"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\/nl\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","title":{"rendered":"Hoeveel TPS heeft uw blockchain?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Een veelgestelde vraag van niet-technische experts over elke gedistribueerd systeem is \u201cHoeveel TPS heeft uw blockchain?\u201d. Echter, het getal dat als antwoord wordt gegeven, heeft meestal weinig te maken met wat de vraagsteller daadwerkelijk wil weten. In werkelijkheid wilde hij vragen \u201cpast uw blockchain bij mijn zakelijke vereisten?\u201d, en deze vereisten zijn geen enkel getal, maar een veelheid aan voorwaarden \u2014 zowel de fouttolerantie van het netwerk als de vereisten voor finaliteit, de grootte, het karakter van transacties en vele andere parameters. Dus het antwoord op de vraag \u201choeveel TPS\u201d zal zeker niet eenvoudig zijn en bijna nooit compleet. Een gedistribueerd systeem met tientallen en honderden knooppunten die vrij complexe berekeningen uitvoeren, kan zich in een enorm aantal verschillende toestanden bevinden, die verband houden met de staat van het netwerk, de inhoud van de blockchain, technische storingen, economische problemen, aanvallen op het netwerk en vele andere redenen. De fasen waarin prestatieproblemen kunnen optreden, verschillen van traditionele services, en de server van een blockchain-netwerk is een netwerkservice die de functionaliteit van een database, webserver en torrentclient combineert, wat het uiterst complex maakt qua belastingprofiel op alle subsysteem: CPU, geheugen, netwerk, opslag.<\/p>\n

<\/p>\n

Het is zo dat gedecentraliseerde netwerken en blockchains vrij specifieke en ongebruikelijke software zijn voor ontwikkelaars van gecentraliseerde software. Daarom wil ik belangrijke aspecten van de prestaties en veerkracht van gedecentraliseerde netwerken belichten, benaderingen voor hun meting en het vinden van bottlenecks. We zullen verschillende prestatieproblemen onderzoeken die de snelheid van de service-aanbieding aan blockchain-gebruikers beperken en de kenmerken opmerken die typisch zijn voor dit soort software.<\/p>\n

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

Fasen van de service-aanvraag door een blockchain-klant<\/h2>\n

<\/p>\n

Om eerlijk te kunnen spreken over de kwaliteit van een gemiddelde ingewikkelde service, moet je niet alleen rekening houden met de gemiddelde waarden, maar ook met de maximale\/minimale waarden, mediaan en percentielen. In theorie kun je praten over 1000 tps in een bepaalde blockchain, maar als 900 transacties met grote snelheid zijn uitgevoerd en 100 'vastliepen' voor enkele seconden, dan is de gemiddelde tijd, berekend over alle transacties, geen eerlijke metriek voor een klant die niet in staat was om de deal in enkele seconden te voltooien. Tijdelijke 'gaten', veroorzaakt door gemiste consensusrondes of netwerk splitsingen, kunnen de dienst ernstig verpesten, die in testomgevingen uitstekende prestaties toonde.<\/p>\n

<\/p>\n

Om dergelijke knelpunten te identificeren, is het essentieel om goed te begrijpen op welke momenten de echte blockchain problemen kan ondervinden bij het bedienen van gebruikers. Laten we de cyclus van levering en verwerking van transacties beschrijven, evenals het verkrijgen van een nieuwe status van de blockchain, waaruit de klant kan opmaken dat zijn transactie is verwerkt en geregistreerd.<\/p>\n

<\/p>\n

    \n
  1. de transactie wordt gevormd op de klantzijde<\/li>\n
  2. de transactie wordt ondertekend op de klantzijde<\/li>\n
  3. de klant kiest een van de nodes en verzendt zijn transactie naar die node<\/li>\n
  4. de klant meldt zich aan voor updates van de state database van de node, in afwachting van de resultaten van de uitvoering van zijn transactie<\/li>\n
  5. de node verspreidt de transactie via het p2p-netwerk<\/li>\n
  6. meerdere of \u00e9\u00e9n BP (block producer) verwerkt de verzamelde transacties en werkt de state database bij<\/li>\n
  7. BP vormt een nieuwe blok door het vereiste aantal transacties te verwerken<\/li>\n
  8. BP verspreidt de nieuwe blok via het p2p-netwerk<\/li>\n
  9. de nieuwe blok wordt afgeleverd aan de node waar de klant toegang toe heeft<\/li>\n
  10. de node werkt de state database bij<\/li>\n
  11. de node ziet de update die betrekking heeft op de klant en stuurt hem een melding over de transactie<\/li>\n<\/ol>\n

    <\/p>\n

    Laten we deze stappen nu gedetailleerd bekijken en de potenti\u00eble prestatieproblemen op elk van deze stappen beschrijven. In tegenstelling tot gecentraliseerde systemen, zullen we ook de uitvoering van code aan de netwerk clients bekijken. Bij het meten van de tps wordt de verwerkingstijd van transacties vaak verzameld van nodes in plaats van van de client \u2014 dit is niet helemaal eerlijk. Voor de client is het niet relevant hoe snel de node zijn transactie heeft verwerkt; het belangrijkste voor hem is het moment waarop betrouwbare informatie over deze transactie, die in de blockchain is opgenomen, beschikbaar voor hem wordt. Deze metriek is in feite de transactie-uitvoeringstijd. Dit betekent dat verschillende clients, zelfs wanneer ze dezelfde transactie verzenden, totaal verschillende tijden kunnen ontvangen, afhankelijk van het kanaal, de belasting en de nabijheid van de node, enzovoort. Daarom is het absoluut noodzakelijk om deze tijd op de clients te meten, omdat precies deze parameter moet worden geoptimaliseerd.<\/p>\n

    <\/p>\n

    Voorbereiding van de transactie aan de kant van de client<\/h2>\n

    <\/p>\n

    Laten we beginnen met de eerste twee punten: de transactie wordt gevormd en ondertekend door de client. Het klinkt misschien vreemd, maar dit kan ook een bottleneck zijn voor de prestaties van de blockchain vanuit het perspectief van de client. Dit is ongebruikelijk voor gecentraliseerde diensten, waar alle berekeningen en dataverwerkingen door hen worden uitgevoerd, en de client gewoon een korte aanvraag voorbereidt die een grote hoeveelheid data of berekeningen kan opvragen, en het resultaat ontvangt. In blockchain-systemen wordt de clientcode steeds krachtiger, terwijl de blockchain-kern steeds lichter wordt, en omvangrijke rekentaken worden doorgaans aan de client software gegeven. In blockchains zijn er clients die vrij lang \u00e9\u00e9n transactie kunnen voorbereiden (ik heb het over verschillende merkle bewijsstukjes, beknopte bewijsstukken, threshold handtekeningen en andere complexe bewerkingen aan de kant van de client). Een goed voorbeeld van lichte on-chain verificatie en zware voorbereiding van een transactie aan de client is het bewijs van lidmaatschap van een lijst op basis van een Merkle-boom. artikel<\/a><\/noindex>.<\/p>\n

    <\/p>\n

    Vergeet ook niet dat de clientcode niet alleen transacties naar de blockchain verzendt, maar eerst de status van de blockchain opvraagt \u2014 en deze activiteit kan invloed hebben op de belasting van het netwerk en de blockchain-nodes. Dus, bij het uitvoeren van metingen, is het verstandig om het gedrag van de clientcode zo volledig mogelijk te emuleren. Zelfs als er in uw blockchain alleen maar gewone lichte clients zijn die een standaard digitale handtekening zetten op een eenvoudige transactie voor het overdragen van een bepaald asset, neemt het aantal massa-berekeningen aan de clientzijde elk jaar toe, worden de crypto-algoritmen sterker, en deze verwerkingscomponent kan in de toekomst een significante bottleneck worden. Wees daarom voorzichtig en mis de situatie niet waarin voor een transactie die 3,5 seconden duurt, 2,5 seconden gaat naar de voorbereiding en ondertekening van de transactie, en 1,0 seconde naar het verzenden naar het netwerk en het wachten op een antwoord. Om de risico's van deze bottleneck te beoordelen, is het belangrijk om metrics van clientmachines te verzamelen, en niet alleen van de blockchain-nodes.<\/p>\n

    <\/p>\n

    Transactie verzenden en de status ervan volgen<\/h2>\n

    <\/p>\n

    De volgende stap is het verzenden van de transactie naar de gekozen blockchain-node en het ontvangen van de status van opname in de pool van transacties. Deze stap lijkt op een reguliere database-aanroep, de node moet de transactie in de pool opnemen en beginnen met het verspreiden van informatie erover via het p2p-netwerk. De benadering voor het beoordelen van de prestaties hier is vergelijkbaar met die van traditionele microservices Web API's, waarbij de transacties in blockchains actief kunnen worden bijgewerkt en hun status kunnen wijzigen. In feite kan de informatie over een transactie in sommige blockchains meerdere keren worden bijgewerkt, bijvoorbeeld bij overschakelingen tussen forks van de keten of wanneer BP aangeven voornemen om de transactie in een blok op te nemen. Beperkingen op de grootte van deze pool en het aantal transacties daarin kunnen invloed hebben op de prestaties van de blockchain. Als de transactiepool vol is tot de maximaal mogelijke grootte, of niet in het RAM past \u2014 kan de netwerksnelheid aanzienlijk dalen. Blockchains hebben geen gecentraliseerde middelen om de stroom van junkberichten tegen te gaan, en als de blockchain transacties van grote omvang en lage kosten ondersteunt, kan dit leiden tot het overbelasten van de transactiepool \u2014 dit is weer een potenti\u00eble bottleneck voor de prestaties.<\/p>\n

    <\/p>\n

    In blockchains stuurt de klant een transactie naar een willekeurige node van de blockchain die hem bevalt, de hash van de transactie is meestal al bekend bij de klant voordat deze wordt verzonden, dus wat hij nodig heeft, is een verbinding tot stand te brengen en na de overdracht te wachten tot de blockchain zijn staat verandert en zijn transactie opneemt. Merk op dat het meten van 'tps' totaal verschillende resultaten kan opleveren voor verschillende manieren van verbinding maken met de node van de blockchain. Dit kan de gebruikelijke HTTP RPC zijn of een WebSocket die het 'subscribe'-patroon mogelijk maakt. In het tweede geval krijgt de klant eerder een melding, en de node verbruikt minder middelen (voornamelijk geheugen en verkeer) om antwoorden te geven over de status van de transactie. Daarom moet bij het meten van 'tps' rekening worden gehouden met de manier waarop klanten verbinding maken met nodes. Om de risico's van dit knelpunt te beoordelen, moet de benchmark van de blockchain in staat zijn om klanten te emuleren met zowel WebSocket als HTTP RPC-verzoeken, in verhoudingen die overeenkomen met echte netwerken, en moet het ook het karakter en de grootte van transacties kunnen aanpassen.<\/p>\n

    <\/p>\n

    To assess the risks of this bottleneck, it is also necessary to collect metrics from client machines, not just from blockchain nodes.<\/p>\n

    <\/p>\n

    Transaction and block transmission over a p2p network<\/h2>\n

    <\/p>\n

    In blockchains, peer-to-peer (p2p) networking is used to transmit transactions and blocks among participants. Transactions are spread across the network starting from one of the nodes until they reach peers-block producers who bundle transactions into blocks and distribute the new blocks to all nodes in the network via the same p2p process. The basis of most modern p2p networks is various modifications of the Kademlia protocol. Hier is<\/a><\/noindex> a good brief overview of this protocol, and hier is<\/a><\/noindex> \u2014 an article with various measurements in the BitTorrent network, from which it can be understood that this type of network is more complex and less predictable than a rigidly configured centralized service network. Also, hier is<\/a><\/noindex> an article on measuring various interesting metrics for Ethereum nodes.<\/p>\n

    <\/p>\n

    In het kort, elke peer in dergelijke netwerken onderhoudt zijn eigen dynamische lijst van andere peers, waarvan hij blokken informatie aanvraagt die op inhoud zijn gericht. Bij ontvangst van een verzoek geeft de peer ofwel de benodigde informatie, of hij draagt het verzoek over aan de volgende pseudo-willekeurige peer in de lijst. Na het ontvangen van een antwoord, geeft hij dit door aan de aanvraager en cachet hij het gedurende enige tijd, zodat hij deze informatie bij de volgende keer eerder kan aanbieden. Op deze manier komt populaire informatie in veel caches van een groot aantal peers terecht, terwijl impopulaire informatie geleidelijk wordt verdrongen. Peers houden bij hoeveel informatie ze aan elkaar hebben doorgegeven, en het netwerk probeert actieve aanbieders te stimuleren door hun ranking te verhogen en hen een hoger serviceniveau te bieden, terwijl het tegelijkertijd inactieve deelnemers automatisch uit de peerslijsten verwijdert.<\/p>\n

    <\/p>\n

    Nu moet de transactie door het netwerk worden verspreid, zodat block-producers deze kunnen zien en deze aan een blok kunnen toevoegen. De node \u2018deelt\u2019 actief de nieuwe transactie met iedereen die het wil, en luistert naar het netwerk terwijl het wacht op een blok waarin de gewenste transactie verschijnt, om de wachtende klant te informeren. De tijd die het netwerk nodig heeft om informatie over nieuwe transacties en blokken uit te wisselen in p2p-netwerken hangt af van een groot aantal factoren: het aantal eerlijke, werkende nodes in de buurt (aangaande het netwerk), de 'verhitheid' van de caches van deze nodes, de grootte van blokken, transacties, de aard van de wijzigingen, de geografie van het netwerk, het aantal nodes en nog veel meer factoren. Gecombineerde metingen van prestatiemetrics in dergelijke netwerken zijn complex, aangezien het noodzakelijk is om gelijktijdig de verwerkingstijden van verzoeken op zowel de klanten als de peers (blockchain nodes) te evalueren. Problemen in een van de p2p-mechanismen, onjuist dataverplaatsing en caching, ineffectief beheer van lijsten met actieve peers en vele andere factoren kunnen vertragingen veroorzaken die de effici\u00ebntie van het hele netwerk be\u00efnvloeden, en deze bottleneck is het moeilijkst te analyseren, testen en de resultaten te interpreteren.<\/p>\n

    <\/p>\n

    Verwerking van de keten van blokken en bijwerking van de state database<\/h2>\n

    <\/p>\n

    Het belangrijkste onderdeel van de werking van de blockchain is het consensusalgoritme, de toepassing ervan op nieuwe blokken die uit het netwerk zijn ontvangen en de verwerking van transacties met registratie van de resultaten in de state database. Het toevoegen van een nieuw blok aan de keten en de daaropvolgende keuze van de hoofdketen moet zo snel mogelijk plaatsvinden. Echter, in de praktijk betekent 'moet' niet noodzakelijk 'werkt', en je kunt je bijvoorbeeld een situatie voorstellen waarin twee lange concurrerende ketens voortdurend omschakelen, waardoor de metadata van duizenden transacties in de pool bij elke omschakeling verandert en voortdurende terugvallen in de staat van de state database plaatsvinden. Dit stadium is, wat betreft het bepalen van de bottleneck, eenvoudiger dan de netwerk p2p-laag, omdat de uitvoering van transacties en het consensusalgoritme strikt deterministisch zijn, en het meten van iets hier eenvoudiger is.
    \nHet belangrijkste is om de toevallige degradatie van de prestaties in deze fase niet te verwarren met netwerproblemen \u2014 de nodes leveren blokken en informatie over de hoofdketen trager, wat voor de externe klant kan overkomen als een langzaam netwerk, terwijl het probleem heel ergens anders ligt.<\/p>\n

    <\/p>\n

    Voor prestatieoptimalisatie in deze fase is het nuttig om metrics van de nodes zelf te verzamelen en te monitoren, en deze op te nemen, waaronder die welke betrekking hebben op de update van de state-database: het aantal blokken dat op de node wordt verwerkt, hun grootte, het aantal transacties, het aantal schakelacties tussen fork-ketens, het aantal ongeldige blokken, de verwerkingstijd van de virtuele machine, de tijd om gegevens vast te leggen, enzovoort. Dit helpt om netwerkproblemen niet te verwarren met fouten in de algoritmes voor ketenverwerking.<\/p>\n

    <\/p>\n

    De virtuele machine die transacties verwerkt kan een waardevolle informatiebron zijn om de blockchain-prestaties te optimaliseren. Het aantal geheugenallocaties, het aantal read\/write-instructies, en andere metrics die betrekking hebben op de effici\u00ebntie van het uitvoeren van contractcode kunnen veel nuttige informatie bieden aan ontwikkelaars. Tegelijkertijd zijn smart contracts programma's, wat betekent dat ze in theorie elk van de middelen kunnen verbruiken: cpu\/memory\/network\/storage, dus de verwerking van transacties is een vrij onbepaald stadium dat bovendien sterk verandert bij de overgang tussen versies en bij het aanpassen van contractcode. Daarom zijn metrics met betrekking tot transactieverwerking ook nodig voor effectieve optimalisatie van de blockchain-prestaties.<\/p>\n

    <\/p>\n

    De notificatie van de klant over het inschakelen van de transactie in de blockchain<\/h2>\n

    <\/p>\n

    Dit is de laatste fase van het ontvangen van de blockchain-service door de klant. In vergelijking met andere fasen zijn er hier geen grote overheadkosten, maar het is nog steeds belangrijk om rekening te houden met de mogelijkheid dat de klant een grote respons van de node ontvangt (bijvoorbeeld een smart contract dat een array van gegevens teruggeeft). Hoe dan ook, dit moment is het belangrijkste voor degene die vraagt \"hoeveel tps heeft uw blockchain?\", aangezien op dit moment de tijd van het ontvangen van de service wordt vastgelegd. <\/p>\n

    <\/p>\n

    Op dit punt moet de volledige tijd die de klant heeft besteed aan het wachten op een antwoord van de blockchain, worden verzonden. Dit is namelijk de tijd die de gebruiker zal verwachten voor bevestiging in zijn applicatie, en het optimaliseren daarvan is de belangrijkste taak voor ontwikkelaars.<\/p>\n

    <\/p>\n

    Conclusie<\/h1>\n

    <\/p>\n

    Als resultaat kunnen we de typen operaties die in blockchains worden uitgevoerd beschrijven en deze in verschillende categorie\u00ebn indelen:<\/p>\n

    <\/p>\n

      \n
    1. cryptografische transformaties, opbouw van bewijzen<\/li>\n
    2. peer-to-peer netwerken, replicatie van transacties en blokken<\/li>\n
    3. verwerking van transacties, uitvoering van smart contracts<\/li>\n
    4. toepassing van wijzigingen in de blockchain op de state database, bijwerken van gegevens over transacties en blokken<\/li>\n
    5. read-only aanvragen aan de state database, API van de blockchain node, abonnementsdiensten <\/li>\n<\/ol>\n

      <\/p>\n

      Over het algemeen zijn de technische vereisten voor nodes van moderne blockchains zeer ernstig: dit zijn snelle CPU's voor cryptografie, veel RAM om de state database op te slaan en er snel toegang toe te krijgen, netwerkinfrastructuur die een groot aantal gelijktijdig open verbindingen ondersteunt, omvangrijke opslag. Deze hoge eisen en de overvloed aan verschillende soorten operaties leiden er onvermijdelijk toe dat de nodes mogelijk niet genoeg middelen hebben, en dan kan elke van de hierboven besproken fasen een bottleneck worden voor de algehele netwerkprestaties.<\/p>\n

      <\/p>\n

      Bij het ontwikkelen en evalueren van de prestaties van blockchains moet u al deze aspecten in overweging nemen. Hiervoor moet u gelijktijdig metrics verzamelen en analyseren van zowel klanten als nodes in het netwerk, correlaties tussen hen zoeken, de tijd voor het leveren van services aan klanten evalueren, rekening houden met alle belangrijke middelen: cpu\/memory\/network\/storage, en begrijpen hoe deze worden gebruikt en elkaar be\u00efnvloeden. Dit maakt de vergelijking van snelheden van verschillende blockchains in termen van \"hoeveel TPS\" een bijzonder ondankbare taak, omdat er een enorme verscheidenheid aan configuraties en toestanden bestaat. In grote gecentraliseerde systemen, clusters van honderden servers, zijn deze problemen ook complex en vereisen ze het verzamelen van een groot aantal verschillende metrics, maar in blockchains, vanwege p2p-netwerken, virtuele machines, contractverwerkende processen en interne economie, zijn er veel meer vrijheidsgraden, waardoor een test, zelfs op enkele servers, niet representatief is en slechts zeer benaderende waarden oplevert die nauwelijks met de werkelijkheid verband houden.<\/p>\n

      <\/p>\n

      Daarom, bij het ontwikkelen in de kern van de blockchain, voor het evalueren van de prestaties en het beantwoorden van de vraag \"is het verbeterd in vergelijking met de vorige keer\", gebruiken we vrij complexe software die de lancering van de blockchain orkestreert met tientallen nodes en automatische benchmark- en metricsverzameling. Zonder deze informatie is het extreem moeilijk om protocollen te debuggen die met veel deelnemers werken.<\/p>\n

      <\/p>\n

      Dus, wanneer u de vraag \"hoeveel TPS heeft uw blockchain?\" krijgt, bied uw gesprekspartner dan een kopje thee aan en vraag of hij bereid is om zich bekend te maken met een tiental grafieken en ook te luisteren naar alle drie de dozen met prestatieproblemen van blockchains en uw voorstellen voor oplossingen...<\/p>\n

      Bron: 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\udd47Hoeveel TPS heeft uw blockchain? | ProHoster","description":"Een veelgestelde vraag over elke gedistribueerd systeem door een niet-technisch specialist is 'Hoeveel tps heeft uw blockchain?'","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/36157","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=36157"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/36157\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=36157"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=36157"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=36157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}