What Is Changing
As announced on October 8th, Bee v2.8.3 includes security fixes. Swarm Foundation held back the details until the release was available, and they are described below. Alongside them, the release gives full-node operators more control over redistribution, fixes a bug that could quietly stop a node from uploading, and makes nodes lighter on memory and more compatible with common RPC providers.
Danger
Upgrade to v2.8.3 now. This release fixes two issues that could let malicious content or a malicious peer tie up a node's resources. Every node operator should upgrade, and it is most urgent for public gateways and full nodes.
Info
The upgrade is non-disruptive. It includes no breaking p2p protocol changes and needs no manual migration. A few things are worth knowing before you upgrade:
- Full nodes run a one-time reserve check on their first start, which can make that start take longer. See A Healthier Reserve below.
- Operators who set
gas-limit-fallbackthemselves should review it. See Other Operator Improvements below. - Developers who use ACT with
POST /chunksorPOST /socshould read API & Developer Changes below. - Operators with monitoring alerts on Bee's logs should check the Monitoring and Alerts section below.
The network's minimum supported version remains v2.8.0.
Security Fixes
Malformed content can no longer stall downloads.
Specially crafted content could make a download request run indefinitely, keeping a CPU core busy until the node was restarted, and repeated requests could tie up more of the node.
Any node type could be affected through the endpoints that read files, such as /bytes and /bzz.
Nodes that fetch content for untrusted users, such as public gateways or apps that pass user-supplied references to Bee, were the most exposed.
Bee now checks a file's structure as it reads it and stops with an error when the content is malformed.
A single peer can no longer exhaust a full node's incoming streams.
Full nodes now limit how many pull-sync streams one peer can keep open at the same time: 128 for syncing and 4 for cursor requests.
Previously, a faulty or malicious peer could hold open enough idle streams to use up the node's capacity for incoming streams, after which the node stopped accepting streams from other peers as well.
A peer that goes over the limit is now disconnected, and the node logs peer exceeded concurrent stream limit, disconnecting.
Light and ultra-light nodes do not serve pull-sync and were not affected.
Pause Redistribution Without Restarting
Full-node operators can now switch redistribution participation off and back on while the node is running. Until now, the only way to opt out was to change the node's configuration and restart it, and restarting a node after it had committed to a round but before it revealed could get its stake frozen.
When participation is paused, the node stops entering new rounds but finishes any round it is already part of.
Before taking a node down for maintenance, check GET /redistributionstate: it is safe to stop the node when hasCommittedThisRound is false, or once hasRevealedThisRound is true.
Tip
To pause participation:
curl -X PATCH http://localhost:1633/redistributionstate \
-H "Content-Type: application/json" \
-d '{"enabled": false}'
Send {"enabled": true} to resume.
The setting is not saved across restarts: participation switches back on whenever the node restarts.
Uploads No Longer Stall Silently
Bee v2.8.3 fixes a bug where a single invalid chunk could stop a node from uploading anything to the network, without logging an error. The stall survived restarts, so an affected node could stay stuck for hours.
After upgrading, the invalid chunk is dropped and any pending uploads resume on their own. No manual action is needed.
A Healthier Reserve
Nodes now check more carefully that the chunks they receive from peers are valid, so invalid chunks are no longer stored in a node's reserve.
Any invalid chunks that earlier versions already stored are cleaned up automatically, once, the first time the node starts on v2.8.3.
Info
On full nodes with a large reserve, this one-time check can make the first start on v2.8.3 take noticeably longer than usual, and it shows no progress while it runs.
If there is anything to check, the node logs verifying non-cac reserve chunks when the check starts and removed rogue reserve chunks when it is done.
When a full node's neighborhood is selected in a redistribution round, the node samples its reserve, which can mean working through millions of chunks. Bee v2.8.3 makes this much lighter: in testing, the memory used during a sampling round fell by more than half. The result of the sampling is unchanged.
Sampling also skips chunks from soon-to-expire postage batches earlier, which makes it faster on nodes that hold many of them. If a node cannot read its list of postage batches, it now skips that round's sample instead of risking one that disagrees with its neighborhood.
Postage Sync with More RPC Providers
Some RPC providers limit how many blocks a single request can cover. Nethermind, for example, allows up to 1,000 blocks by default, while Bee could ask for up to 5,000 at a time. A node using such a provider could fall behind on postage data and eventually shut itself down.
Bee now asks for 1,000 blocks at a time by default, so it works with these providers out of the box, and the value is configurable. Bee also now waits between retries when an RPC call fails, which eases the load on your RPC endpoint. The postage snapshot bundled with Bee is refreshed as well, so a new node has fewer blocks of postage history to catch up on.
Tip
The smaller default means a catching-up node makes more RPC calls than before.
If your provider allows wider block ranges, you can raise the value, for example in bee.yaml:
postage-sync-block-range: 5000
The equivalent flag is --postage-sync-block-range and the environment variable is BEE_POSTAGE_SYNC_BLOCK_RANGE.