Rusty Kaspa v2.1.0, released on 22 September, changes how a new or returning node catches up with the network. Instead of sending some of the largest sync data packages as single messages, upgraded peers can pass them in smaller pieces. The update also puts stricter limits on incoming network traffic and repairs a file-access flaw in the web dashboard of a mining tool (release notes).
A node checks Kaspa blocks for itself rather than accepting another computer's account of the network. A new node needs data from peers before it can follow new blocks as they arrive. A machine returning after a long absence can face the same catch-up. The software calls the process initial block download, or IBD.
Moving the same data in smaller pieces
Part of IBD involves block headers, brief records that identify blocks, and proof data a node uses to check the history it receives. Under the new peer-to-peer protocol version 11, large batches of headers, pruning-point proofs and related data are sent in chunks of about 20 MiB. Earlier transfers could put much larger amounts into one message, creating framing bottlenecks or timeouts during sync (merged sync change).
The code caps a complete proof or trusted-data transfer at 1 GiB and gives it a deadline. That keeps chunking from replacing one oversized message with an unending series of smaller ones. If a peer cannot deliver within those limits, the receiving node can end that exchange (proof transfer code).
Protocol 11 remains compatible with protocol 10 peers. Two upgraded nodes can use the chunked exchange, while a newer node can still use the older format with a peer that has not updated. Operators do not have to wait for every node on the network to change at once (release notes).
The change tackles how bulky transfers travel between peers. It does not reduce the amount of data a node must check, and the release gives no measured promise that the whole sync will finish faster. Disk speed, connection quality and the peers available still shape that experience.
Earlier limits for oversized traffic
v2.1.0 also cuts the largest peer-to-peer message a node will decode from 1 GB to 256 MB. Block messages larger than 2 MB are rejected before normal validation, and the software bounds a compressed part of block headers that could otherwise expand too far (release notes, message-size code).
These checks happen as data enters the node. Refusing oversized input early avoids spending more memory and processing time on data that will be discarded. The release also tightens arithmetic checks in production node and Stratum code, while keeping consensus and UTXO indexing under a separate policy that stops on invalid calculations (arithmetic safety policy).
A mining dashboard fix
The Stratum bridge is a separate program in the Rusty Kaspa project that connects mining software to a node. Its web dashboard had a path traversal flaw. A crafted request for a dashboard file could make the program look beyond the folder meant to hold those files. The new code rejects abnormal path segments and checks that a disk file remains inside the dashboard folder (patched code).
The bridge also changes how it handles web requests so one slow connection cannot hold up the dashboard, and it limits how much monitoring data can accumulate under changing labels (merged bridge work, release notes). The file-access flaw concerns the bridge dashboard, not transaction validation on the Kaspa network.
The release recommends v2.1.0 for node, mining and infrastructure operators on mainnet and testnets. A new node can keep talking to older peers, while the chunked transfers take effect when both sides support protocol 11. Operators who use the Stratum bridge get its dashboard and connection fixes when they update that software (release notes).
