With the release of the Gemini 3g network we wanted to take a few moments to talk about the changes between the last iteration and this new version. Note that our documentation is the source of truth for how to run our software and should always be checked carefully when changing versions and especially when changing network.
The latest node and farmer employ both UDP and TCP network communications. The implications are that you will need to update any port forwarding rules you may be using to ensure both communication protocols are enabled and CLI options in case you have customized them.
This is particularly important for Docker users as their
ports configuration will need to be updated. Please check our example in the documentation to see how they should look now.
Anywhere an address in this format
/ip4/0.0.0.0/tcp/30433 is being used will need to be checked to see if an equivalent
udp parameter is now also required.
Historically, the farmer would farm (try and provide solutions from plotted sectors to earn rewards) while it was plotting. Now the farmer does not farm while plotting by default. This is to ensure that the plotting process occurs in the most efficient manner possible as fast as possible. This behavior can be changed by providing the
--farm-during-initial-plotting flag to the farmer on the command line, but expect performance decrease and warnings if you do so.
The node no longer requires the
--execution flag as the default
wasm value is always used.
The complexity when plotting has been increased by a factor of 8 for security reasons. Early builds of what has become the Gemini 3f farmer would take up to 8x as long to plot a sector. Thanks to optimizations delivered by the core contributors, the process has been turbocharged and real-world plotting speeds seem to be coming out at considerably less than 8x the time it took on 3f. We’d love to hear about your experiences with the increased difficulty.
With the introduction of Proof-of-Time (PoT), a new, optional role has been added to the node. This is timekeeping. Timekeepers supply the flags below and help protect the security of the network. Our hope is that those who can spare a high-performance core for the health and success of the project will help out by running a decentralized network of timekeepers.
--timekeeper - to become a timekeeper.
--timekeeper-cpu-cores - to specify which cores timekeeper should use rather than random cores. On 13900/K/F/KF/KS and 14900/K processors physical cores 5 and 6 are the fastest, so it is recommended to set this value to
8-11, which corresponds to 4 logical cores behind those physical cores.
Read more on timekeeping in our documentation.
We have been providing the
--state-pruning archive pruning flag to the node up to this point, it is recommended to change it to
--state-pruning archive-canonical in order to decrease node disk usage a bit.
There are many other features, enhancements and bug fixes in this latest incarnation of Subspace but the above are the ones that will need a farmer’s immediate attention as they migrate onto the new network.