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 
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:
- MintNode peers within a Section.
- Sharding: Each Section is responsible for a subset of DBCs.
- Client Aggregation
- 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:
Russian ; 
German ; 
Spanish ; 
French; 
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!
keep on plugging away team, looking forward to the next testnet 
