Update 16 September, 2021

This week we’re going into a little more detail about distributed/sharded mints, how they fit with DBCs and privacy, and what they mean for both the network and the user experience.

General Progress

David Rusu and @danda have been experimenting with adding forced-one-time-keys to their work on blinded signatures, and also making the client write to the spentbook. A work in progress still, but looking good so far.

Lots of bug fixing this week. We’ve wrestling with another node memory issue around file puts. These memory spikes were caused by a message amplification issue caused by the AE flows at the client, as well as from adults back to clients. Fixes for those have been merged now and memory usage has reduced considerably.

With this we’ve started looking at getting more summaries regarding messaging on the network, with nodes set to print these stats alongside their resource usage in the logs. Once we have this in place we’ll start to look at using all this info in our testing systems to ensure no further amplification bugs can sneak in.

Related to this, @chris.connelly has been digging into qp2p, stripping out some of the connection pooling functionality which is no longer needed.

@oetyng is implementing the handling of backpressure (resistance or force opposing the desired flow of data through software). The idea is to have a node check its CPU load when taking requests. If it is above a certain level it will return a message containing the CPU load. The receiving node can then regulate their comms based on this information. After a while they go back to default settings.

There is no need to sync this information or come to any agreement. The handling of backpressure is like traffic guidelines. When most drivers follow the traffic guidelines, the traffic flows smoother, even if there are some nutty drivers :slight_smile: Meaning that although a bad node could choose to not follow the guidelines, since most nodes on the network will work correctly and follow the guidelines, the traffic will be improved compared to not having those guidelines.

At least this is the idea, and we will be trying this out for some time ahead now. It’s a new dimension of the network communication, sort of like AE has been, and it will require time to settle in.

@Anselme’s bug of choice has been the self encryption process which has been sending out some confusing errors that were crashing some unit tests. He’s now looking at refactoring the NRS to simplify it.

Meanwhile @Lionel.faber has improved the way that GitHub Actions works to automate the deployments of testnets on Digital Ocean, which has gone down very well with the team, and @Qi_Ma has figured out some anomalous behaviour with AE. With every bug squashed we get a little closer.

Oh and we were very happy to receive a PR from @davidpbrown. Great to have community members involved. If anyone wants to contribute you need to fork the repo first - more here.

DBC Mints

DBC Mints have been around since the 90’s but they never became very popular.

One serious issue preventing adoption is that they have typically been centralized and thus require that users of the system (token holders) trust the mint operator completely. A greedy mint operator could inflate the money supply without anyone else knowing, thereby stealing value from all the users. Also, the mint operator could simply disappear, and all the tokens become value-less overnight. So one must trust the mint operator not only today, but also tomorrow, and also that no third party, hacker, insider, or government can impact their operation.

Decentralization via sections (sharding) is a central feature of the Safe Network design. The SN DBC design leverages and builds on that to create a Mint that is both decentralized and scaleable. To date, no deployed cryptocurrency[1] has incorporated decentralized DBC mints that we are aware of, so this is a novel development. It is our aim to scale to worldwide usage with instant (and private) transaction settlements.

The decentralization functionality can be broken up into a few main areas:

  1. MintNode peers within a Section.
  2. Sharding: Each Section is responsible for a subset of DBCs.
  3. Client Aggregation
  4. Distributed Spentbook written by Client

Let’s look at each of these.

MintNode peers within a Section.

Within a section, each Elder is also designated as a MintNode. Thus, there are 7 nodes, with others ready and waiting to replace any node that fails. When the section is formed or membership changes, the nodes perform a round of distributed-key-generation (DKG) to create a shared BLS key. This is a multi-sig key, such that 5 of the 7 (super-majority) nodes must sign a piece of data for it to be considered valid. In the case of DBCs, the signed data is called a ReissueShare. These ReissueShares must be collected from a super-majority of nodes in a section to complete the reissue of DBC’s managed by that section.

Let’s say one of the nodes is malicious. Perhaps a client has colluded with a node to double spend one of it’s DBCs. The malicious node could respond with a fraudulent ReissueShare for the double spend, but this share on it’s own is useless, a client must convince a super-majority of nodes before it can collect enough ReissueShares to certify a double-spend reissue.

Further it is difficult in terms of time and resources to become a Mint Node (section Elder) in the first place. The Safe Network has a concept of Node Age by which Adult nodes must prove themselves to be reliable and honest over time. Only the most senior adult is selected as an Elder whenever an existing elder disappears. On top of this, a node cannot choose which section it will be in. All these strategies make it difficult for an attacker to achieve multiple malicious nodes in a section relevant to their DBC activity.

Sharding: Each Section is responsible for a subset of DBCs.

Sharding is a general term which means breaking up data so that different servers handle subsets of the data.

Our sharding approach is actually quite simple. The DBCs spend key (A universally unique one-time-key) determines which Section is responsible for handling it. The client software is responsible for sending an identical ReissueRequest to all mint nodes in all sections corresponding to DBC inputs in the ReissueRequest.

In the following example, we have 3 inputs, each of which are handled by different sections, each section responds with a super-majority (5 of 7) of reissue shares.

As a MintNode loops through the input DBCs, for each one it checks if it has responsibility or not. If a MintNode is responsible for a DBC, the Spentbook is consulted on whether this DBC has been spent already. So a MintNode ReissueShare only provides SignatureShare for the DBCs which a particular section has authority for.

Client Aggregation

When a user wants to reissue a DBC, the user’s client software contacts each of the 7 MintNodes for the section(s) responsible for the input DBC(s) and submits a ReissueRequest. Each node validates the request, and if everything is correct, it replies with a ReissueShare which contains a BLS SignatureShare.

The client software collects the ReissueShare replies from all the MintNodes it contacted and inspects them. If at least 5 nodes in a given section have responded correctly then the client can combine their SignatureShare in order to form a final Mint Signature for each output DBC. With the Signature in hand, the client then constructs the actual DBC(s) which can later be sent as input to another reissue.

Distributed Spentbook written by Client

This is a feature in development. The basic idea is that the Client commits to a given ReissueTransaction and publishes that commitment, identified by the DBC’s spend key (or a hash of the key), on the Safe Network before it makes a ReissueRequest. Each MintNode then only has to read the Spentbook entry for each DBC and validate that the entry is correctly signed by the DBC owner. This simplifies operations for the MintNode, which no longer needs to write any data, and keeps the MintNode’s reissue API idempotent. In other words, the Client can call reissue many times with the same ReissueRequest and always get the same response.

We plan to go into more detail about the Spentbook in a later update.

[1] A whitepaper was published in 2019 describing a decentralized DBC Mint system called Scrit. Scrit’s design is substantially different from ours, and it does not appear to have been publicly deployed as of this writing.

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!


Not first again, I mean!!! :joy:

This was pure luck again, mastery perhaps :thinking:

These dev updates are a wonderful way to learn about the Safe Network and the component technologies it uses. Great idea, lots of people will find reading these useful.

In case anyone fancies re-tweeting:


Second and I read it first, that’s certainly a win :trophy:


When a section splits, is there some ‘settling time’ required for all of the members of the section (now sections) to get synced up on the new status via AE? Does this imply some downtime for DBC spending during that period?


Should not be noticeable as Ae will update in real time. So there will be a retry required, perhaps, but that’s automatic (Ae) and clients will not see it happen.


Thx 4 the update Maidsafe devs.

Will read this interesting literature later :face_with_monocle:

Keep hacking super ants we’re almost at the finishline.

@happybeing :clap::crazy_face:


Despite waiting - and waiting - then waiting a bit more, @neik has failed to post yet - so I’ll do it for him.

He’d probably say something like " Thanks for the update guys, you really are an inspiration, a hope for the future and living proof that buying @southside beer is a worthy and worthwhile cause"

Or then again maybe not…

Anyhow I second most of what @neik would probably have said and simply add my own personal thanks for more interesting info on the nuts and bolts of the network.


Got to be fast these days to beat @happybeing to first :flushed: keep on plugging away team, looking forward to the next testnet :clap:t2:


Will it be 6 months? 12 months? Realistically till another testnet? To a provable network? I don’t understand anymore where all of this is going.

Is this network going to really happen? I’m sorry if I come across as all negative.

I will be called a sock puppet, a troll, or whatever it is. I just want to know, @maidsafe , what are your gut feelings? Is this going to work? Can somebody throw us a bone?

Is there something I can read or can somebody explain simply, is this going to work or not?


I think next testnet will be in a month or two. They are developing the DBC stuff now and likely that’s going to be added in before next testnet, so will be a little while at least.

I suspect we may be 3-6 months from full Fleming - all just my gut watching things move about.


I’m a big supporter and I really appreciate the hard work and perseverance.

But I’m completely lost too, I’d just like to know are the team any bit close to a working test net? :confused:


Exciting and hopefully contains an element of foreshadowing


I’m not trying to be negative here and/or persuade anybody about anything, but I told myself last January that if I don’t see anything tangible and substantial (my definition of it whatever that may mean) by Jan 2022. I will be liquidating my holdings at whatever price, wishing Maidsafe success and not look back.


I echo the same thing. Building the best network is one thing. Getting people to use is another. Seems like we are just working on the first. Every time I talk to someone about SafeNetwork, the first question they ask is “Are they ever going to go live?”


Hello everyone. I have been followed this project since 2017 and I got lost. As far I understand, the priority for the next testnet is stability. What is missing? Are there persisting some bugs?

The second thing I do not understand is why have you been developing AT2 for approx. 6 months and immediately after finishing the work you decided to replace it by DBC?

I am not technically skilled, so I can be easily wrong. I hope that your replies will help me understand the current situation.


The question for me is always, sell for what? I don’t know of any better project that offers more hope for humanity. Certainly not going to trade for fiat. What are you going to switch to?


Great work team. :slight_smile:


I bought some maidsafe at the IPO and then some more and I remember clearly that the price of maidsafe was roughly the same as the price of ETH $.08 (Guessing) , and went with what I thought was offering more hope for humanity. it’s been years and if I had bought ETH back them I would be in a position of having the option to help humanity with the profits.

I don’t regret my decision


Not everyone is advert to FIAT, he will probably sell to FIAT and invest. I would probably invest in real estate if I was in that position. I know of a lot of people who are doing really well with multiple rented residences.

1 Like