This week we’re looking in a bit more depth into SNT emissions. That is how, after the initial distribution of tokens at the inception of the network, the remaining 70% of the total supply will be created and securely distributed as a consequence of people uploading data over the long term. We’ve been thinking a bit deeper about how this should work so that it is as simple and secure as possible, and have cut out a couple of steps from our original design.
@Davidrusu has rationalised the logs so that each one is a single line to make them easier to parse and eliminate extraneous information. Unfortunately in the process we’ll have borked @happybeing’s Vdash - but hopefully not in a way that’s too hard to unbork again.
Much of the rest of the work is testing testing testing. Following a suggestion from @Chriso we’re making some changes to how tests affect the nightly build, introducing a staging branch and prioritising fixing test failures that prevent a release there, so that the code is always release-ready or close to it.
And @anselme has fixed an issue in the BLS ephemeral key broadcast step in DKG. Both the BLS key broadcast and the DKG votes are working properly now and all members are receiving all the votes, an important step.
When users upload data to the network, they pay. We don’t want every payment to result in SNT emissions, just a proportion of them, and we want that proportion to vary in accordance with the needs of the network. If the network requires more storage space the proportion of uploads resulting in an SNT emission increases to attract more storage nodes, when there’s plenty of space it decreases. The exact mechanism for this is still under discussion, but we hope to bring you more detail shortly.
A payment that results in the creation of a new (
Genesis) DBC is called (for now) a
Genesis event. The
Genesis event requires a
GenesisProof which is a file that encodes information about the value of the DBC and its recipients.
The value of the
Genesis DBC is easy enough - it’s a fixed portion of the value of the storage transaction (eg 90% of the initial payment might be rewarded).
The recipients part is where things are a little more complex. The
Genesis event from a transaction happens in only one section, and all elders and the storing nodes get paid in proportion to their node age. But the membership of a section is constantly churning, so how do we know which nodes to pay?
Information about section elders is held in the Section Authority Provider (SAP) but this may not be bang up to date, and while it is being updated through AE the membership may change again.
So a better way would be to use recipients from the
Genesis event payment. The client is told on the store request (quote) who to pay, including the SAP (elders) and the storing nodes. The nodes’ ages at the time of the quote can be calculated from their ID. That way, any of the recipients can reissue the DBC to themselves and the other recipients at any time, and payment will be guaranteed to reach them even if they are no longer in the section, the process is deterministic.
However, our first port of call for reissuing will always be the client (the payer), since that takes some strain off the network. We’re discussing if one of the DBC reward recipients might be the client itself, creating an incentive for the client to do the reissuing, but if that fails then any of the network nodes mentioned in the
GenesisProof can do it instead.
Only paying for storing adults, rather than all adults in a section (another possible scenario), works well as it means fewer DBCs and fewer messages. Over time, the payments are made randomly over the section/network because the storage nodes are decided by the XOR address of the data chunks.
So that’s what we are working towards now. We still need to figure out how to set the store cost, how to make mining SNTs uneconomic for rogue sections, and where to store the
We’re also keen to drop the ‘Genesis’ moniker for new DBCs as it’s confusing. One suggestion is
RootDBC - what think ye, oh community?
Feel free to reply below with links to translations of this dev update and moderators will add them here:
As an open source project, we’re always looking for feedback, comments and community contributions - so don’t be shy, join in and let’s create the Safe Network together!