Update 18 August, 2022

Development Updates
1

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.

Cheers to @southside for testing the latest builds and providing logs :pray:. Looking into those spikes and node failures now.

General progress

@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.

SNT emissions

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 GenesisProofs.

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?

Useful Links

Feel free to reply below with links to translations of this dev update and moderators will add them here:

:russia: Russian ; :germany: German ; :spain: Spanish ; :france: French; :bulgaria: Bulgarian

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!

63 Likes
3

first !!! so ah um

22 Likes
4

Silver today!

19 Likes
5

Congrats Southside! You made it into the update with yer tests and logs.

18 Likes
6

Anything except Genesis DBC - RootDBC makes much more sense. IMHO there should only be one Genesis DBC, there will be many many RootDBCs.

16 Likes
7

What about database updates, multi->single threaded conversions and all other things which blocks testnets launch? Still blocked? It is the first thing which is important to know from weekly update.

12 Likes
8

Root and Genesis suggest only one whereas there seem to be many (one per upload). So maybe StorageDBC, NewDBC or TokenIssueDBC?

I’m confused about how the unissued SNT is getting there as this can’t be issued by the client, yet the client is creating the transaction? Maybe I’m just not understanding!

13 Likes
9

This much is true… I change my vote to TokenIssueDBC.

12 Likes
10

Well done to all the team for all the hard work.
all the late night git hub action lately has been getting me exited :slight_smile:

11 Likes
11

Ready for next comnet. :cowboy_hat_face:

14 Likes
12

On a related note I’m trying (and failing - see a new topic I will start soon Do My Homework Please) to write a script to grab all the logs from baby-fleming and store them in a set of sub-dirs to get tarred up and made available to the devs.

See ths sn_node-genesis? It’s a total PITA. ^
Can we no just have the genesis node as node0 and number the following nodes from 1?

I want to get this script written so that many more folk will feel comfortable about testing and reporting on the latest builds. This will give confidence that errors/anomalies I find are valid and unrelated to anthing I have done locally.

^ I have to do ugly shit like this which, while it works OK, just feels kludgy.

TIMESTAMP=$(/usr/bin/date +%Y%m%d_%H%M)

cd $HOME/.safe/node/baby-fleming-nodes/
for i in  {1..11};
	do 
		mkdir -p $HOME/saved-logs/$TIMESTAMP/sn_node-$i/
	done
mv 		$HOME/saved-logs/$TIMESTAMP/sn_node-1 $HOME/saved-logs/$TIMESTAMP/sn_node-genesis
6 Likes
13

Thanks so much to the entire Maidsafe team for all of your hard work! :racehorse:

9 Likes
14

This emission stuff isn’t quite adding up for me yet.

A few q’s off the top of my head:

Is there still a total supply cap? What is it? how calculated?
Or is it a tail emission, more like monero?
If a fixed supply cap, how is it enforced with these new emission rules?
speaking of, what are the emission rules?
Tx are generally an expensive operation. Uploads payments are tiny. How can percentages of tiny amounts be distributed to multiple parties efficiently, for free?

Every client/peer will know the validity of the true first Genesis DBC because they have it’s hash hard-coded. And all other coins can be traced back to it. These freshly minted coins seem less secure, in that they only have a single section’s signature giving them authenticity. At first glance, it seems to me that this is lowering the bar to inflating the total money supply. no?

regarding a name, well “coinbase” is the industry standard established by bitcoin. So at least it would be familiar to people. Otherwise, I’d use “Mint” in the name. Perhaps “MintedCoin” or “FreshMint”. :wink:

19 Likes
15

FreshMint passes the smell test.

10 Likes
16

Is there an option to design for failure; there’s often a thought in security it seems for three layers of defense. If there is only one kind of storage node, there is option for one kind of failure to affect storage? What code is perfect, is rare. What if there were other kinds of node, rare-use backup large nodes that are huge data lakes and different because they are a last resort; perhaps even option to see backups made offline, with some tracking of what is stored how. Pay more for extra assurance perhaps too?

That just reflecting on how natural systems are adapted for survival by absorbing the threat they are challenged with. It’s only because of variety we survive as a species? The flip side might be that large node become a target but timing of stresses and coincidence of many errors, make for much less likely any failure of storage. Lots of nearly perfect things are easier to maintain than one perfect thing?

:+1:

7 Likes
17

There are several issues we are on as you can see every week. Single-threaded is pretty much done AFAIK, the database is gone, but we are sealing up membership, dkg and also some work on a network layer issue we have. For every single bug, we are on it’s best to follow Github. The big stuff we try and post here mind you.

It’s not there, as in it did into come from genesis. Instead, a genesis event happens (this is a non-minable event) and effectively creates a token amount. These are limited in number to the total amount allowed (~2^32).

The event is still being considered, but imagine for simplicity a store is paid for, and the section signature plus the hash of all of your chunks to be stored plus your own key, starts with 001101110110111 and at that address, there is no genesis event, so it’s free. In that address, we write the genesis event (your payment plus section sig) and then it’s yours. The mint knows this is how a genesis happens and can check your sig is that of the payers and issue (reissue) you the tokens.

This is a simplification of the algo we are considering for the genesis event, not the actual algo, but here you can see it’s not guessable as you need the data to have hashed to these hashes, plus all the sigs to align and you need to have paid.

Now the payment is >= to the reward, so also no point in creating and paying for these to get a reward as the reward is not more than the payment.

These 2 points are the last wee niggles we are ironing out. (well spotted :wink: ) The other one is the initial payment cost and then how that reduces until we lose nodes or don’t gain any, how fast it increases to make it profitable to farm again, etc.

With those, we have a solid approach that encompasses the store/cost balance.

Hopefully, answered, or avoided for now, with the above.

18 Likes
18

We have a pack of chewing gum with that name IIRC :slight_smile:

8 Likes
19

I’d like to see you Wriggle out of using FreshMint now :slight_smile:

9 Likes
20

Ok, so iiuc in this simplification you are saying that the freshly minted tokens would be paid to the client that is doing the upload… or at least that the client could specify the payee, which would normally be themselves.

But in the OP, it is talking about more complicated mechanism(s) to reward adults/farmers instead.

So my initial thought is, why not just go with the simple approach and reward the client/uploader? Farmers would still receive the regular PUT payment.

The client/uploader is a participant in the system, adding value by increasing the stored data and just by increasing the network size/effect of participants. For them, receiving the reward could be like winning a lottery… every once in a while an upload is nearly free, or at least has a substantial discount. I think of it like at the gas station, I occasionally get 10 or 20 cents off per gallon, for being a loyal customer.

A significant problem with minting money (any money) is how to distribute it widely and fairly to the entire population. Participants that receive the money first, typically have advantage over others.

So I like this concept because it distributes the new money more widely, beyond farmers, to average end-users.

21 Likes