Migrating from Gemini 3f to Gemini 3g

Gemini 3f to 3g Changes

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.

UDP Communication

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/ is being used will need to be checked to see if an equivalent udp parameter is now also required.

No Farming While Plotting by Default

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.

Dropped Execution Flag

The node no longer requires the --execution flag as the default wasm value is always used.

Plotting Complexity

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.

State Pruning Flag

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.

1 Like

Okay, but how to migrate from 3f to 3g in a proper way? I mean, should we delete plots (I believe that yes), wipe or purge, or any other hints maybe?

3g is a new network. 3f plots will not work on 3g. You can wipe your 3f node and plot to free up all the space it is using. Or you could resize your plot - the choice is yours. An explanation on how to wipe can be found in the Switching to a new snapshot from older/different versions of Subspace section of the docs here.

Will it replot all my existing plot files to 3g network specs?

It will not. The idea behind resizing 3f is that you could tune the amount of storage you are allocating to each network as you squeeze the last few inventivized blocks out of 3f and get plotted on 3g. It’s an option. The same as wiping 3f and starting on 3g.

How about --listen-addr? By default there is no UDP mentions in node’s --help, as for --dsn-listen-on.

--listen-addr doesn’t support UDP yet. Just open official docs and check what is in there, it should be correct.

1 Like

:man_shrugging: Official docs. :slightly_smiling_face:

They are correct, we want users to expose both UDP and TCP port for all 3 port numbers because we want to use UDP/QUIC for Substrate as well, it just doesn’t support QUIC right now so we don’t take advantage of that. I have seen people still using old setups from 3f for 3g, so the earlier we add those ports to docs the more likely it is that users will have them forwarded on routers once we start taking advantage of that.

Got it, thanks! 20 characters )