Rusty Kaspa Mempool Update<\/h1>\n
Kaspa<\/a> recently unveiled another significant advancement in the performance of their mempool, a term referring to the temporary holding space for unconfirmed transactions. The new mempool design can now manage a high-frequency 10-BPS network, even when saturated with hundreds of thousands of pending transactions.<\/p>\n Behind this achievement stands Michael Sutton<\/a> at the helm and documenting the process on Twitter\/X<\/a>, joined by the Rust powerlifter Tiram_88<\/a>.<\/p>\n Some months back, Kaspa halted its eleventh testnet, TN11. This decision was primarily made to refine everything associated with the pathways of the mempool\u2019s operations. Before this intervention, the focus was mainly on refining their consensus validation engine. This engine, created with parallel processing in mind, was tested and proved capable of handling approximately 32 BPS. However, challenges arose when attention shifted to the mempool. Its initial design was straightforward and needed to be refined to manage heavy loads, revealing bottlenecks that hindered performance.<\/p>\n \n \n This graph, Figure 1, illustrates the challenges of the previous mempool system under constant pressure. It showed significant strain when subjected to an influx of transactions more than a 10-BPS BlockDAG could efficiently manage. The system nearly halted at one point, especially between the 60 to 80-second marks, even though it was handling a mere 35,000 transactions. Two metrics stood out in this figure. The left demonstrates the operation time, while the right showcased the real-time mempool size. Both metrics reflected that the Build Block Template (BBT) and the block submission times were increasing at a high rate in correlation with the mempool size. This indicated the need for internal mempool algorithm optimization.<\/p>\n \u2014 The system needed to quickly build blocks, which is crucial for the network\u2019s responsiveness.<\/p>\n \u2014 Once a transaction was confirmed, it needed to be removed from the mempool promptly, ensuring a smooth operational flow.<\/p>\n \u2014 Maintain a consistent rate at which the new, unconfirmed transactions are accepted, regardless of the mempool\u2019s load.<\/p>\n The mempool then underwent a transformation. Large operations were fragmented into smaller, more manageable tasks, allowing many to run concurrently. Additionally, the internal algorithms of the mempool received significant overhauls for improved efficiency.<\/p>\n \n The results of these interventions were nothing short of impressive. Michael Sutton referred to Figures 2 and 3 to underscore the improvements. In tests, they attempted to send a staggering 1.4 million transactions to a node to prove that until the mempool reaches a stable size of 600 thousand transactions. Over 600 thousand, the transaction submissions will alternate pausing and resuming to maintain. Figure 2 showed that BBT times were around 25 milliseconds, while block submissions averaged 150 milliseconds. Simultaneously, Figure 3 highlights the transaction processing speed of over 2,000 transactions every second. Most notably, these figures remained stable, even with a considerable load on the mempool, indicating that the node performed seamlessly.<\/p>\n Kaspa\u2019s advancements signal a more resilient, efficient, and adaptable system. It\u2019s designed to manage a significant transactional load without compromising performance, marking a pivotal moment for Kaspa\u2019s breakthrough technological journey.<\/p>\n The days of frustrating delays, throughput limitations, and lengthy transaction times are poised to be things of the past. With a keen focus on quicker transactions, the revamped system efficiently processes tasks, even amidst high transaction volumes, ensuring unparalleled reliability.<\/p>\n Tip: <\/strong>With a potential to manage thousands of transactions seamlessly, Kaspa\u2019s 10-BPS mempool is the future of practical everyday commerce.<\/p>\n KASPA<\/a> | KASPA WIKI<\/a> | MEDIUM<\/a> | TELETYPE<\/a> | DISCORD<\/a> | TELEGRAM<\/a><\/p>\n TWITTER<\/a> | REDDIT<\/a> | GITHUB<\/a> | EXPLORER<\/a> | Bubblegum Lightning<\/a><\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section]<\/p>\n","protected":false},"excerpt":{"rendered":" New Mempool Implementation Manages Thousands of Pending Transactions Rusty Kaspa Mempool Update Kaspa recently unveiled another significant advancement in the performance of their mempool, a term referring to the temporary holding space for unconfirmed transactions. The new mempool design can now manage a high-frequency 10-BPS network, even when saturated with hundreds of thousands of pending […]<\/p>\n","protected":false},"author":34,"featured_media":46276,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"on","_et_pb_old_content":" Kaspa recently unveiled another significant advancement in the performance of their mempool, a term referring to the temporary holding space for unconfirmed transactions. The new mempool design can now manage a high-frequency 10-BPS network, even when saturated with hundreds of thousands of pending transactions.<\/p>\r\n Behind this achievement stands Michael Sutton<\/a> at the helm and documenting the process on Twitter\/X<\/a>, joined by the Rust powerlifter Tiram_88<\/a>.<\/p>\r\n Some months back, Kaspa halted its eleventh testnet, TN11. This decision was primarily made to refine everything associated with the pathways of the mempool\u2019s operations. Before this intervention, the focus was mainly on refining their consensus validation engine. This engine, created with parallel processing in mind, was tested and proved capable of handling approximately 32 BPS. However, challenges arose when attention shifted to the mempool. Its initial design was straightforward and needed to be refined to manage heavy loads, revealing bottlenecks that hindered performance.<\/p>\r\n\r\n This graph, Figure 1, illustrates the challenges of the previous mempool system under constant pressure. It showed significant strain when subjected to an influx of transactions more than a 10-BPS BlockDAG could efficiently manage. The system nearly halted at one point, especially between the 60 to 80-second marks, even though it was handling a mere 35,000 transactions. Two metrics stood out in this figure. The left demonstrated the operation time, while the right showcased the real-time mempool size. Both metrics reflected that the Build Block Template (BBT) and the block submission times were increasing at a high rate in correlation with the mempool size. This indicated the need for internal mempool algorithm optimization.<\/p>\r\n\r\n \u2014 The system needed to quickly build blocks, which is crucial for the network\u2019s responsiveness.<\/p>\r\n \u2014 Once a transaction was confirmed, it needed to be removed from the mempool promptly, ensuring a smooth operational flow.<\/p>\r\n \u2014 Maintain a consistent rate at which the new, unconfirmed transactions are accepted, regardless of the mempool\u2019s load.<\/p>\r\n\r\n The mempool then underwent a transformation. Large operations were fragmented into smaller, more manageable tasks, allowing many to run concurrently. Additionally, the internal algorithms of the mempool received significant overhauls for improved efficiency.<\/p>\r\n\r\n The results of these interventions were nothing short of impressive. Michael Sutton referred to Figures 2 and 3 to underscore the improvements. In tests, they attempted to send a staggering 1.4 million transactions to a node to demonstrate that until the mempool reaches a stable size of 600 thousand transactions. Over 600 thousand, the transaction submissions will alternate pausing and resuming to maintain. Figure 2 showed that BBT times were around 25 milliseconds, while block submissions averaged 150 milliseconds. Simultaneously, Figure 3 highlights the transaction processing speed of over 2,000 transactions every second. Most notably, these figures remained stable, even with a considerable load on the mempool, indicating that the node performed seamlessly.<\/p>\r\n\r\n Kaspa\u2019s advancements signal a more resilient, efficient, and adaptable system. It\u2019s designed to manage a significant transactional load without compromising performance, marking a pivotal moment for Kaspa\u2019s breakthrough technological journey.<\/p>\r\n The days of frustrating delays, throughput limitations, and lengthy transaction times are poised to be things of the past. With a keen focus on quicker transactions, the revamped system efficiently processes tasks, even amidst high transaction volumes, ensuring unparalleled reliability.<\/p>\r\n\r\n Tip: <\/strong>With a potential to manage thousands of transactions seamlessly, Kaspa\u2019s 10-BPS mempool is the future of practical everyday commerce.<\/p>\r\n KASPA<\/a> | KASPA WIKI<\/a> | MEDIUM<\/a> | TELETYPE<\/a> | DISCORD<\/a> | TELEGRAM<\/a><\/p>\r\n TWITTER<\/a> | REDDIT<\/a> | GITHUB<\/a> | EXPLORER<\/a> | Bubblegum Lightning<\/a><\/p>","_et_gb_content_width":"","inline_featured_image":false,"footnotes":""},"categories":[4,31],"tags":[],"post_folder":[],"yoast_head":"\n<\/h1>\n
Mempool Bottleneck<\/h1>\n
![\"\"](\"https:\/\/miro.medium.com\/v2\/resize:fit:640\/format:webp\/1*3sRodA2a_XeLcRuRTIsgmw.png)
<\/picture><\/div>\n<\/div><\/h1>\n
Optimization objectives<\/h1>\n
Results<\/h1>\n
![\"\"](\"https:\/\/miro.medium.com\/v2\/resize:fit:640\/format:webp\/1*RSe1z9Rpgvs5jBefyIA6fg.png)
<\/picture><\/div>\n<\/div>![\"\"](\"https:\/\/miro.medium.com\/v2\/resize:fit:640\/format:webp\/1*dXrQzlUtVMDguijEc4XyBQ.png)
<\/picture><\/div>\n<\/div><\/h1>\n
The Nutshell<\/h1>\n
Twitter Kaspa Update<\/a><\/h2>\n
New Mempool Implementation Manages Thousands of Pending Transactions<\/h4>\r\n
Rusty Kaspa Mempool\u00a0Update<\/h3>\r\n
![\"Image\"](\"https:\/\/pbs.twimg.com\/media\/F6EB3H7WAAAO8FP?format=png&name=900x900\")
Optimization objectives<\/h3>\r\n
Results<\/h3>\r\n
The Nutshell<\/h3>\r\n
Twitter Kaspa\u00a0Update<\/a><\/h4>\r\n