It has been two days since we activated the farming rewards on Gemini. We have over 6.5k fully synced nodes and ~1.5 petabytes of storage pledged. As initially promised, we would like to share more details about how the reward system works and a bug that we have found and fixed promptly.
We have also released our latest snapshot, jun-13, which includes fixes to a frequently reported issue that results in nodes getting stuck and displaying a “Waiting for farmer to receive and acknowledge archived segment” warning. There are still some edge-cases it doesn’t cover, but it should address the most common issues. Please download the CLI or Subspace Desktop updates below
- CLI - Farming with the CLI | Subspace Labs Documentation
- Subspace Desktop - Release 0.6.7 · subspace/subspace-desktop · GitHub
Gemini Reward System
Many of you might have seen on the block explorer that when a block is produced, beyond the expected rewards.BlockReward event, there are now multiple rewards.VoteReward events being generated. The former is self-explanatory; it is the reward earned by the node that farmed (built) that particular block, while the latter is an extension to our consensus aimed at increasing the reward frequency for farmers and broader network participation.
Without going into technical implementation details, voting rewards are granted to farmers who have found a solution to the block challenge within an accepted range, which is set to be broader than what the block authoring difficulty range is. Currently, the consensus is set to reward the block author (producer) and nine voting rewards on average. What it means is that the block author is always guaranteed to receive the block reward, set as 0.1 tSCC currently, while the numbers of votes accepted into each block could vary, with each accepted voter also earning 0.1 tSCC. It is important to note that both block reward and voting reward are distributed proportionally to the amount of storage pledged by each farmer.
You might wonder why we extended our consensus with voting rewards. In short, we want to prevent the scenario where the difficulty of generating a block is so high, due to the total amount of space pledged, that it might take the median farmer months or years to earn the first reward. By introducing the voting reward, we can adjust the number of votes accepted without lowering the security of the core consensus model.
Some voting reward math for the nerds
The current voting implementation distributes 0.1 tSSC for every vote successfully included in a block and 0.1 tSCC for the block author. However, the reward isn’t dynamically split within each block. When the reward parameters are set, including the number of votes expected, the reward per block author and voter is fixed regardless of the number of actual votes being accepted into each block. If we take the initial setup as an example, with vote parameter = 9, it is not uncommon to see one vote in a block and 16 votes in another, but the average should converge toward the set parameter. As with block rewards, the chance of getting a voting reward is also proportional to the amount of space pledged. The net result is that instead of getting one 1 tSSC every N blocks, farmers will get 1/(V+1) tSSC every N/(V+1) blocks, where V is the expected number of votes per block on average. Currently V=9, meaning 0.1 tSSC per block is the standard voting reward. If we were to update the parameter to V=19, both block author and voters would earn 0.05 tSCC each. Again, the thinking is that it’s better to get a small amount per block versus waiting to win a full block reward. While sharding is seen as the longer-term solution, this provides an intermediate solution for more frequent rewards that will evolve into a more useful feature in future iterations of the protocol.
Reward propagation bug fixed
Within the first 24 hours of enabling farming rewards on Gemini, we noticed blocks were not including as many voting submissions per block as we initially expected (9 per block on avg). That triggered a deeper investigation and we discovered a minor bug caused by a missing tag that stopped votes from being propagated effectively across the network. Github pull request
That change was addressed within a few hours and has since been fixed via a forkless runtime update, so it didn’t require a new snapshot and it was enabled right away.