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 transactions.

Behind this achievement stands Michael Sutton at the helm and documenting the process on Twitter/X, joined by the Rust powerlifter Tiram_88.

Some months back, Kaspa halted its eleventh testnet, TN11. This decision was primarily made to refine everything associated with the pathways of the mempool’s 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.

Mempool Bottleneck

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.

Optimization objectives

— The system needed to quickly build blocks, which is crucial for the network’s responsiveness.

— Once a transaction was confirmed, it needed to be removed from the mempool promptly, ensuring a smooth operational flow.

— Maintain a consistent rate at which the new, unconfirmed transactions are accepted, regardless of the mempool’s load.

Results

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.

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.

The Nutshell

Kaspa’s advancements signal a more resilient, efficient, and adaptable system. It’s designed to manage a significant transactional load without compromising performance, marking a pivotal moment for Kaspa’s breakthrough technological journey.

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.

Twitter Kaspa Update

Tip: With a potential to manage thousands of transactions seamlessly, Kaspa’s 10-BPS mempool is the future of practical everyday commerce.

TWITTER | REDDIT | GITHUB | EXPLORER | Bubblegum Lightning

A Kaspa Performance Update