{"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\/en\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","title":{"rendered":"How many TPS does your blockchain have?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A common question from a non-technical specialist about any distributed system is, 'How many TPS does your blockchain have?'. However, the number given in response often has little to do with what the inquirer really wants to know. In reality, they want to ask, 'Will your blockchain meet my business requirements?', and these requirements are not a single number, but a multitude of conditions\u2014network fault tolerance, finality requirements, sizes, nature of transactions, and many other parameters. So the answer to the question 'how many TPS' is unlikely to be simple and almost never complete. A distributed system with dozens and hundreds of nodes performing quite complex computations can exist in an enormous number of different states related to the state of the network, the contents of the blockchain, technical failures, economic issues, network attacks, and many other reasons. The stages at which performance problems may arise differ from traditional services, and a server in a blockchain network acts as a network service that combines the functionalities of a database, web server, and torrent client, making it extremely complex in terms of load profiles across all subsystems: CPU, memory, network, storage.<\/p>\n

<\/p>\n

It so happens that decentralized networks and blockchains are quite specific and unfamiliar software for developers of centralized software. Therefore, I would like to highlight important aspects of performance and resilience of decentralized networks, approaches to measuring them, and identifying bottlenecks. We will examine various performance issues that limit the speed of service delivery to blockchain users and note the characteristics specific to this type of software.<\/p>\n

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

Stages of service request by a blockchain client<\/h2>\n

<\/p>\n

To honestly discuss the quality of any moderately complex service, it's essential to consider not just average values, but also maximum\/minimum values, medians, and percentiles. Theoretically, one might speak of 1000 tps in some blockchain, but if 900 transactions were completed at high speed while 100 'hung' for several seconds, the average time calculated across all transactions is not a fair metric for a client who couldn't complete their transaction in those few seconds. Temporary 'pits' caused by missed consensus rounds or network splits can severely degrade a service that performs excellently in testing environments.<\/p>\n

<\/p>\n

To identify such bottlenecks, it's essential to understand the stages where a real blockchain might face difficulties in serving its users. Let's describe the delivery cycle and transaction processing, as well as obtaining the new state of the blockchain, from which the client can verify that their transaction has been processed and recorded.<\/p>\n

<\/p>\n

    \n
  1. The transaction is formed on the client side.<\/li>\n
  2. The transaction is signed on the client side.<\/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 of the node, awaiting the results of their transaction execution.<\/li>\n
  5. The node propagates the transaction through the p2p network.<\/li>\n
  6. One or more block producers process the accumulated transactions, updating the state database.<\/li>\n
  7. The block producer forms a new block by processing the required number of transactions.<\/li>\n
  8. The block producer propagates the new block through the p2p network.<\/li>\n
  9. The new block is delivered to the node that the client is querying.<\/li>\n
  10. The node updates the state database.<\/li>\n
  11. The node sees the update related to the client and sends them a notification about the transaction.<\/li>\n<\/ol>\n

    <\/p>\n

    Now let's take a closer look at these stages and describe the potential performance issues at each step. Unlike centralized systems, we will also consider code execution on the network clients. Quite often, when measuring TPS, the transaction processing time is collected from nodes rather than from the client \u2014 this is not entirely fair. The client doesn\u2019t care how quickly the node processed their transaction; what matters most to them is when reliable information about that transaction, included in the blockchain, becomes available to them. This metric is essentially the transaction execution time. This means that different clients, even when sending the same transaction, can receive completely different times, depending on the channel, load, and proximity of the node, etc. Therefore, it is crucial to measure this time on the clients, as this is the parameter that needs to be optimized.<\/p>\n

    <\/p>\n

    Transaction Preparation on the Client Side<\/h2>\n

    <\/p>\n

    Let's start with the first two points: the transaction is formed and signed by the client. Strangely enough, this can also be a performance bottleneck of the blockchain from the client's perspective. This is unusual for centralized services, where all calculations and data operations are handled internally, and the client simply prepares a short request capable of querying a large volume of data or computations, receiving a ready result. In blockchains, the client code is becoming increasingly powerful, while the blockchain core is becoming lighter, and massive computational tasks are typically delegated to client software. In blockchains, there are clients that can prepare a single transaction for quite a while (I am talking about various Merkle proofs, succinct proofs, threshold signatures, and other complex operations on the client side). A good example of light on-chain verification and heavy transaction preparation on the client is the proof of membership in a list based on a Merkle tree. article<\/a><\/noindex>.<\/p>\n

    <\/p>\n

    It is also important to remember that the client code does not just send transactions to the blockchain, but first queries the state of the blockchain\u2014this activity can affect the load on the network and blockchain nodes. Therefore, when conducting measurements, it is wise to emulate the behavior of the client code as fully as possible. Even if your blockchain has regular lightweight clients that simply sign a basic transaction transferring some asset, the amount of computational load on the client is increasing each year, cryptographic algorithms are strengthening, and this part of the processing could become a significant bottleneck in the future. So be cautious and do not overlook a situation where, in a transaction lasting 3.5 seconds, 2.5 seconds are spent on preparation and signing, and 1.0 second is for sending to the network and awaiting a response. To assess the risks of this bottleneck emerging, metrics should be collected from client machines and not just from blockchain nodes.<\/p>\n

    <\/p>\n

    Sending a transaction and monitoring its status<\/h2>\n

    <\/p>\n

    The next step is to send the transaction to the selected blockchain node and obtain its acceptance status into the transaction pool. This stage is similar to a regular database call, where the node needs to record the transaction in the pool and begin spreading information about it through the P2P network. The approach to assessing performance here resembles that of evaluating traditional Web API microservices, where transactions in blockchains can be updated and actively change status. In general, updating transaction information in some blockchains can occur multiple times, for instance, when switching between forks of the chain or when block producers inform about their intention to include a transaction in a block. Restrictions on the size of this pool and the number of transactions within it can influence blockchain performance. If the transaction pool is filled to its maximum capacity or cannot fit into memory\u2014network performance can sharply decline. Blockchains do not have centralized means to protect against the flow of spam messages, and if a blockchain supports large transactions and low fees, this can lead to the transaction pool being overwhelmed\u2014this is yet another potential performance bottleneck.<\/p>\n

    <\/p>\n

    In blockchains, a client sends a transaction to any node they prefer, and the transaction hash is usually known to the client even before sending. Therefore, all they need is to establish a connection and then wait for the blockchain to change its state by including their transaction. It\u2019s worth noting that measuring 'tps' can yield vastly different results depending on the method of connecting to the blockchain node. This could be a standard HTTP RPC or a WebSocket, which allows for implementing a 'subscribe' pattern. In the latter case, the client will receive notifications sooner, and the node will spend fewer resources (primarily memory and bandwidth) on transaction status responses. Thus, when measuring 'tps,' it\u2019s crucial to consider the client\u2019s connection method to the nodes. Consequently, to assess the risks of this bottleneck, the blockchain benchmark should be able to emulate clients using both WebSocket and HTTP RPC requests in proportions reflecting actual networks, while also varying the nature and size of transactions.<\/p>\n

    <\/p>\n

    To assess the risks of this bottleneck, metrics should also be collected from client machines, not just from blockchain nodes.<\/p>\n

    <\/p>\n

    Transmission of transactions and blocks over a p2p network<\/h2>\n

    <\/p>\n

    In blockchains, peer-to-peer (p2p) networking is used for transmitting transactions and blocks between participants. Transactions spread across the network, starting from one of the nodes, until they reach the peers, the block producers, who package the transactions into blocks and distribute new blocks across all nodes in the network through the same p2p method. The foundation of most modern p2p networks is various modifications of the Kademlia protocol. Here<\/a><\/noindex> a good brief overview of this protocol, and here<\/a><\/noindex> \u2014 the article includes various measurements in the BitTorrent network, which demonstrates that such networks are more complex and less predictable than a rigidly configured centralized service network. Also, here<\/a><\/noindex> an article on measuring various interesting metrics for Ethereum nodes.<\/p>\n

    <\/p>\n

    In short, each peer in such networks maintains its own dynamic list of other peers from which it requests blocks of information addressed by content. Upon receiving a request, the peer either provides the requested information or forwards the request to the next pseudo-random peer from the list, and after receiving a response, it conveys it to the requester while caching it for a while, supplying this block of information earlier next time. Thus, popular information ends up in many caches across numerous peers, while unpopular content is gradually displaced. Peers keep track of who has transferred how much information to whom, and the network seeks to incentivize active distributors by enhancing their ratings and providing them with a higher service level, automatically expelling inactive participants from the peer lists.<\/p>\n

    <\/p>\n

    Therefore, the transaction must now be disseminated across the network so that the block producers can see it and include it in a block. The node actively 'distributes' the new transaction to everyone interested and listens to the network, waiting for the block that will include the desired transaction in its index to notify the waiting client. The time it takes for the network to relay information about new transactions and blocks in P2P networks depends on a vast number of factors: the number of honest nodes operating nearby (from a networking perspective), the 'warming up' of these nodes' caches, the size of blocks, transactions, the nature of changes, the geography of the network, the number of nodes, and many other factors. Comprehensive measurements of performance metrics in such networks are complex; it is necessary to evaluate request processing times on both clients and peers (blockchain nodes) simultaneously. Issues in any of the P2P mechanisms, incorrect eviction and caching of data, inefficient management of active peer lists, and many other factors can lead to delays affecting the efficiency of the entire network. This bottleneck is the most challenging to analyze, test, and interpret results.<\/p>\n

    <\/p>\n

    Processing the blockchain and updating the state database<\/h2>\n

    <\/p>\n

    The most important part of blockchain operation is the consensus algorithm, its application to new blocks received from the network, and the processing of transactions with the recording of results in the state database. Adding a new block to the chain and selecting the main chain that follows should be as fast as possible. However, in real life, 'should' does not mean 'works', and one can imagine a situation where two long competing chains constantly switch between themselves, altering the metadata of thousands of transactions in the pool with each switch and causing constant rollbacks of the state database. This stage, in terms of identifying the bottleneck, is simpler than the network P2P layer since the execution of transactions and the consensus algorithm are strictly deterministic, making it easier to measure anything here.
    \nThe main thing is not to confuse random performance degradation at this stage with network issues\u2014nodes are delivering blocks and information about the main chain more slowly, which may appear to external clients as a slow network, even though the problem lies entirely elsewhere.<\/p>\n

    <\/p>\n

    To optimize performance at this stage, it is useful to collect and monitor metrics from the nodes themselves, including those related to updating the state database: the number of blocks processed at the node, their size, the number of transactions, the count of switches between chain forks, the number of invalid blocks, the runtime of the virtual machine, the data confirmation time, etc. This will help distinguish network issues from errors in the chain processing algorithms.<\/p>\n

    <\/p>\n

    The virtual machine processing transactions can be a valuable source of information capable of optimizing blockchain performance. The number of memory allocations, the count of read\/write instructions, and other metrics related to the efficiency of executing contract code can provide developers with a wealth of useful information. At the same time, since smart contracts are programs, in theory, they can consume any resources: CPU\/memory\/network\/storage, making transaction processing a relatively ambiguous stage that varies significantly between versions and changes to contract code. Therefore, metrics regarding transaction processing are also necessary for effective optimization of blockchain performance.<\/p>\n

    <\/p>\n

    Client Notification of Transaction Inclusion in Blockchain<\/h2>\n

    <\/p>\n

    This is the final stage of obtaining service for the blockchain client. Unlike other stages, there are no significant overhead costs here, but one should still take into account the possibility of receiving a large response from the node (for example, a smart contract returning an array of data). In any case, this moment is the most important for anyone who asks the question, 'What is the TPS in your blockchain?', as it marks the time of service receipt. <\/p>\n

    <\/p>\n

    At this point, there must be an indication of the total time the client spent waiting for a response from the blockchain. This is the time the user expects confirmation in their application, and optimizing this time is the primary task for developers.<\/p>\n

    <\/p>\n

    Conclusion<\/h1>\n

    <\/p>\n

    As a result, we can describe the types of operations performed in blockchains and categorize them into several groups:<\/p>\n

    <\/p>\n

      \n
    1. cryptographic transformations, proof construction<\/li>\n
    2. peer-to-peer networking, transaction and block replication<\/li>\n
    3. transaction processing, smart contract execution<\/li>\n
    4. applying changes in the blockchain to the state database, updating transaction and block data<\/li>\n
    5. read-only queries to the state database, blockchain node APIs, subscription services <\/li>\n<\/ol>\n

      <\/p>\n

      Overall, the technical requirements for nodes in modern blockchains are extremely demanding\u2014fast CPUs for cryptography, large volumes of RAM for storing and quickly accessing the state database, network interactions requiring many simultaneously open connections, and substantial storage. Such high demands and the abundance of various types of operations inevitably lead to nodes potentially running out of resources, making any of the aforementioned stages a bottleneck for overall network performance.<\/p>\n

      <\/p>\n

      When developing and evaluating blockchain performance, you will have to consider all these aspects. This requires collecting and analyzing metrics from both clients and network nodes simultaneously, searching for correlations between them, assessing the time it takes to provide service to clients, and accounting for all key resources: CPU\/memory\/network\/storage. Understanding how they are used and affect each other makes comparing the speeds of different blockchains in terms of 'how many TPS' an extremely thankless task, as there are numerous configurations and states. In large centralized systems, clusters of hundreds of servers, these problems are also complex and require gathering a vast array of metrics. However, in blockchains, due to P2P networks, virtual machines, contract processing, and internal economies, the number of degrees of freedom is much greater, making tests even on several servers unrepresentative and reflecting only approximate values that bear little relation to reality.<\/p>\n

      <\/p>\n

      Therefore, when developing at the blockchain core to evaluate performance and answer the question, 'Has it improved compared to last time?', we use fairly complex software that orchestrates the launch of the blockchain with dozens of nodes and automatically runs benchmarks while collecting metrics. Without this information, it is extremely difficult to debug protocols that involve multiple participants.<\/p>\n

      <\/p>\n

      So, upon receiving the question, 'What is the TPS in your blockchain?', offer the interlocutor some tea and clarify if they are ready to review a dozen graphs and hear about all the various performance issues of blockchains along with your suggestions for their solutions...<\/p>\n

      Source: 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\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\udd47How many TPS does your blockchain have? | ProHoster","description":"A non-technical specialist's favorite question about any distributed system is \"How many TPS does your blockchain have?\"","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","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\/en\/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\/en\/wp-json\/wp\/v2\/posts\/36157","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=36157"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/36157\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=36157"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=36157"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=36157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}