bee version 2.3.0 - reserve doubling
We are excited to announce that the Bee v2.3.0 release will be on December 4, 2024! The latest version of the Bee client includes exciting new features and improvements to existing functionalities. These changes include the new reserve doubling feature, new GSOC functionality, and enhancements to the price oracle.
Double reserve for optimized node rewards
The reserve doubling feature allows nodes to store blocks from their "sister" neighborhoods, effectively doubling their reserve size. By storing blocks from sister neighborhoods, nodes have the opportunity to participate in the reallocation game whenever their sister neighborhood is selected, thereby doubling their chances of participating in the reallocation game.
Although doubling the reserve space requires twice the disk space and will consume more bandwidth (the bandwidth utilization for block syncing doubles, while the bandwidth for block forwarding remains unchanged), its impact on CPU and RAM usage is minimal. This feature allows a single node to earn rewards as if it were two nodes operating in different neighborhoods, without needing all the additional resources that operating a second node typically requires. Reserve doubling provides node operators with greater flexibility in optimizing their nodes to maximize returns relative to the resources used.
Information
For a deeper explanation of the reserve doubling feature, please refer to swarm improvement proposal 21 (SWIP21).
GSoC enables new dynamic content on Swarm
The new GSOC (Graffiti Multiple Owner Blocks) feature (GSOC SWIP) is inspired by the GraffitiFeed feature originally designated by the Fair Data Association last year. One of the main goals of the GraffitiFeed and GSOC features is to allow multiple users to contribute to a single SoC (Single Owner Block). However, the Graffiti Feed was hindered by several significant limitations that reduced the practicality of the feature. GSoC addresses these issues and opens up new possibilities for dynamic content on Swarm. GSoC will support the building of applications such as multi-user forums, social media websites, chat applications, etc. It also provides an alternative for secure messaging, in conjunction with PSS.
More detailed information about the GSOC architecture and usage guide will be released soon! Be sure to follow Swarm on Twitter and join the official Discord group to stay updated.
Oracle enhancements bring more responsive pricing
When the price oracle was first introduced, limits were placed on how quickly it could change storage prices to prevent rapid changes in price from potentially causing data loss events. Now that the oracle has been running smoothly for quite a while, these limits are being relaxed to enhance the functionality of the price oracle. Enhancements to the price oracle will make pricing more dynamic and respond better to changes in network utilization. This update increases the rate at which postal prices can vary, allowing storage pricing to adjust more quickly based on current network conditions.
bee v2.3.0 guide
The bee v2.3.0 guide is divided into two parts. Part 1 contains a detailed guide for upgrading from Bee v2.2.0 to v2.3.0. Part 2 contains instructions for enabling the new reserve doubling feature.
Section 1: Update to 2.3.0
Since the v2.3.0 update includes new staking contracts, node operators must manually withdraw and restake their xBZZ before updating their nodes, as they did in the v2.2.0 update.
Information
The stake should be withdrawn before updating to 2.3.0.
Step 1.1: Withdraw xBZZ
When Bee v2.3.0 is released, the previous staking contracts will be disabled, and staking withdrawals will be enabled.
After disabling the contract, it can be enabled again by calling the DELETE method at the /stake endpoint:
curl -X DELETE http://localhost:1633/stake
This command will withdraw all stakes from the node to the node's Gnosis Chain address.
Confirm that the stake has been withdrawn:
curl -s http://localhost:1633/stake | jq
The value of stakedAmount should now be zero:
{
"stakedAmount": "0"
}
Step 1.2: Stop the node
This step will vary depending on how the node is set up:
sudo systemctl stop bee
or
docker compose down
or
docker stop <container_name_or_id>
Step 1.3: Update to 2.3.0 and restart
After withdrawing stakes and stopping the node, update the node to v2.3.0. The installation method will vary depending on the node settings. After the update, restart the node.
The specific restart command will depend on your installation method (Docker, install script, package installer, etc.).
*Warning It is always best practice to perform a full backup of the node before each upgrade of the Bee client. :::
Step 1.4: Restake xBZZ
After upgrading to v2.3.0 and restarting, xBZZ should rejoin the new staking contract so that the node can continue participating in the reallocation game.
To stake the required minimum of 10xBZZ:
curl -X POST localhost:1633/stake/100000000000000000
Information
If using the reserve doubling feature, this is the point in the update process where additional stakes can be added to meet the increased minimum stake requirement of 20xBZZ. For more details, see the next section.
Confirm that the staking transaction was successful:
curl -s http://localhost:1633/stake | jq
The expected output after the minimum stake of 10xBZZ:
{
"stakedAmount": "100000000000000000"
}
The expected output after the required minimum of 20xBZZ for reserve doubling:
{
"stakedAmount": "200000000000000000"
}
Upgrading to 2.3.0 is now complete. From here, the node will continue to participate normally in the reallocation game.
Section 2: Reserve Doubling Guide
After updating the node to v2.3.0 and manually migrating the stake, you can enable the double reserve feature by following these steps:
Step 2.1: Stake at least 20xBZZ
Information
This step can also be completed during the manual re-staking process. Step 1.4v2.3.0 update process. For details, see the previous section.
The reserve doubling feature increases the required minimum xBZZ value from 10xBZZ to 20xBZZ.
To double the reserve of nodes that already have a stake of 10xBZZ, only an additional 10xBZZ stake is needed, totaling 20xBZZ:
Information
As always, ensure to correctly convert stake parameters to PLUR, where 1PLUR equals 1e-16xBZZ. In the example below, we have converted from 10xBZZ to 100000000000000000 PLUR.
curl -X POST localhost:1633/stake/100000000000000000
Or for nodes with zero stake xBZZ, a stake of a whole 20xBZZ can be done at once:
curl -X POST localhost:1633/stake/200000000000000000
We can use GET /stake to confirm the total stake of our node at the endpoint:
curl -s http://localhost:1633/stake | jq
{
"stakedAmount": "200000000000000000"
}
Step 2.2: Set reserve-capacity-doubling to 1.
This can be done by setting the new reserve-capacity-doubling configuration option to 1 using your chosen configuration method.
Step 2.3: Restart the node
Ensure that the node has at least 20xBZZ staked and that the reserve-capacity-doubling option is set to 1, then restart the node.
After restarting the node, it should begin syncing blocks from its sister neighbors.
This /status/neighborhoods endpoint can be used to confirm that the node has doubled its reserve and is now syncing with its sister neighbors:
{
"neighborhoods": [
{
"neighborhood": "01111101011",
"reserveSizeWithinRadius": 1148351,
"proximity": 10
},
{
"neighborhood": "01111101010",
"reserveSizeWithinRadius": 1147423,
"proximity": 11
}
]
}
The expected output should contain two neighborhoods, namely the node's original neighborhood and its sister neighborhood.
We can also check /status to confirm our node is syncing new blocks at the endpoint:
curl -s http://localhost:1633/status | jq
{
"overlay": "be177e61b13b1caa20690311a909bd674a3c1ef5f00d60414f261856a8ad5c30",
"proximity": 256,
"beeMode": "full",
"reserveSize": 4192792,
"reserveSizeWithinRadius": 2295023,
"pullsyncRate": 1.3033333333333332,
"storageRadius": 10,
"connectedPeers": 18,
"neighborhoodSize": 1,
"batchCommitment": 388104192,
"isReachable": true,
"lastSyncedBlock": 6982430
}
We can see that the pullsyncRate value is greater than zero, indicating that our node is currently syncing blocks as expected.
Important details summary
The new reserve-capacity-doubling bee configuration option is used to double the node's reserve. 0 and 1.
To enable the node to participate in the reallocation game of its own neighborhood and its sister neighborhood, it must have a total of 20xBZZ staked (10xBZ for each neighborhood).
Doubling can be reversed by changing reserve-capacity-doubling back to 0 and restarting the node. Then there is a delay of 2 rounds, after which additional xBZZ beyond the minimum of 10xBZZ can be withdrawn.
After doubling, there will be a delay in the reallocation game until the node can participate in that game.
Warning
Restoring reserve-capacity-doubling back to 0 from... after staking 20xBZZ is not allowed to withdraw more than 10xBZZ of additional stakes.
How it works
To understand how reserve doubling works, we must first define some terms:
Proximity Order (PO) PO is a measure of how close a node is to a specific data block or other nodes. It is defined as the number of leading bits shared between two addresses. Proximity order plays an important role in how neighborhoods are defined, as a node's neighborhood extends to its storage depth, covering all nodes within that proximity range.
Storage depth: "Storage depth" indicates which blocks the node is responsible for storing. A node is responsible for storing blocks whose leading binary bits match its own storage depth. For example, at a storage depth of 5, a node with a leading bit of 01011 must store all blocks with the same leading binary bits of address 01011.
The nearby neighborhood is a set of nodes that are very close to each other based on the proximity order (PO), and each node in the network has a neighborhood defined by its storage depth, which defines the responsibility radius or boundary for storing blocks. Each node in the neighborhood is responsible for interacting with other nodes within the neighborhood to store and replicate data blocks, thereby ensuring data availability and redundancy.
The sister neighborhood of a sibling neighbor node is the neighborhood where the last effective bit of the node address (which is the bit at the position of the current storage depth) has been flipped (from 0 to 1 or from 1 to 0). For a depth 5 neighborhood defined by the leading bit of 01011, its sister neighborhood would be 01010.
The parent neighbor is a neighbor that includes two sibling neighbors when the storage depth is reduced by 1. For example, with the previous storage depth of 5, neighbor 01011 and its sister neighbor 01010, their parent neighborhood is depth 4, which is 0101.
When a node doubles its reserve space, it becomes responsible for storing its parent neighbor, which is the depth neighborhood D-1 where d is its original storage depth.
Information
SWIP21 describes doubling multiple times so that nodes can store all blocks from depth neighborhoods. D-2, D-3 to increase the original reserve fourfold, eightfold, or further doubling. However, Bee v2.3.0 only supports single doubling.
For example, for a storage depth 5 neighborhood with a leading binary bit of 01011, when its reserve is doubled, it will store all blocks falling into its parent neighborhood 0101 at depth 4, which contains both the original neighborhood 01011 and its sister neighborhood 01010.
Since the node stores blocks from its sister neighbors in addition to its own blocks, it will be able to produce reserve commitment hashes (hashes obtained from random sampling of blocks in the node's reserve used to prove that the node is storing the blocks it is responsible for) regardless of whether its own neighbors or its sister neighbors are selected to play, thus doubling its chances of participating in the reallocation game.
The reserve of the doubling node also needs to correspondingly increase the minimum required stake needed to participate in the reallocation game, so the node now needs a stake of 20xBZZ instead of the minimum of 10xBZZ to participate in the reallocation game of its own and its sister's neighborhood.
Section 3: Modify /rchash endpoint
This /rchash endpoint can be used to generate a sample reserve hash and can be used to benchmark the processor speed of the full node. Previously, the endpoint allowed random anchor parameters. In Bee v2.3.0, this has been modified to require anchor parameters to match the prefix bits of the node up to the current storage depth.
In total, the /rchash endpoint has 3 parameters: storage depth, anchor_01, and anchor_02:
/rchash/{depth}/{anchor_01}/{anchor_02}
The current depth of the node can be obtained from the /reservestate endpoint:
curl -sX GET http://localhost:1633/reservestate | jq
{
"radius": 15,
"storageRadius": 11,
"commitment": 128332464128
}
The value storageRadius is the node's storage depth. Use this value as the depth parameter for /rchash.
The two anchor values anchor_01 and anchor_02 must contain a prefix hexadecimal string that matches the bits of your own node up to the current storage depth. Therefore, for the current depth of 11, and since each hexadecimal digit represents 4 bits, 3 hexadecimal digits are sufficient. We will use 4 just to ensure we are covered in case of future depth increases. For a node with the overlay address e59aa85b5899cd62d54bcd9bf511824883512f7151df196820c0e6d1a02d964b, we will use the first 4 hexadecimal digits e59a:
curl -sX GET http://localhost:1633/rchash/11/e59a/e59a| jq
Conclusion
The reserve doubling feature introduced in the 2.3.0 update provides node operators with tools to enhance the efficiency of their setups while minimizing overhead, thus improving the economic viability of running a node. Node operators will have a new tool to optimize their nodes for scalability and profitability. For more support and to stay updated on all the latest Swarm news, make sure you follow us on Twitter for node operator inconsistencies.
