We’ve been dangling the prospect of an update on the Safe economy for the last couple of weeks now, and we’re pleased to be able to deliver with an overview of our current thinking on Digital Bearer Certificates (DBCs). There are still a few balls in the air marked “one-time keys” and “denominations” but we’re definitely converging on a workable solution that will be fast, private and secure.
As with many other Safe innovations, the aims of DBCs are simplicity and making the client do the work wherever possible - which usually amounts to the same thing. We want to avoid having to store state (e.g account balances) on the network, or to resort to conditional logic, both of which breed complexity. Instead we are rolling out Anti-Entropy in many communications, where the flow is: try -> success (carry on) | fail (retry), while keeping track of state is the job of the Client.
We know that you’re all itching to get your hands dirty again with a new testnet, but to make it worthwhile we want to make sure the network is stable with multiple sections and that AE is working properly across the board.
General Progress
We’re trying to nail an intermittent issue that is seeing different Elders in a section receiving different messages from the same node (this should not happen) and/or choosing different Adults to store the same chunk. Also Elders sometimes write data, which is the Adults’ job. @Qi_Ma and @lionel.faber have been looking at these messaging anomalies.
We’ve had a push to finish implementing AE on the client, with @bochaco and @yogesh leading the charge. There are still some niggly issues there and @lionel.faber has been helping out with debugging Client AE and has already identified one of the causes of the anomalous behaviour as Elders having different section keys.
@oetyng has finished his refactor of self-encryption (which has now been merged into main), and has also been working on refactoring the way chunks are handled.
And @danda has been looking at the question of denominations of DBCs: in selecting denominations for our currency, what values should we choose and why? What appears to be a simple enough question actually involves some interesting trade-offs between network efficiencies and human usability.
An overview of DBCs
A DBC is a unique ‘digital voucher’ that has value by virtue of the fact it has been provably issued by a trusted mint as part of an economic system. To spend a DBC you need to get it reissued by a mint. The mint can take your DBC and reissue it as two or more new DBCs if you wish (e.g. payment to a shop, the remainder as change to you), and multiple DBCs can be reissued as a single DBC.
The important thing for us is that DBCs provide a quick, safe, flexible way to make payments that is compatible with multisig/threshold signature cryptography and can be used online and offline. They simplify many aspects of the Safe Network economy.
The current state of affairs
Currently our DBC system involves the following:
Sharding: The mint is sharded between sections, such that every section is responsible for reissuing only certain DBCs, determined by the DBC name/id.
Decentralised Mint Nodes: Within a section, individual mint nodes (Elders) operate autonomously, without coordination. A Client performing a reissue operation must obtain a ReissueShare from a supermajority of mint nodes (at least 5 of 7). Each ReissueShare contains a BLS SignatureShare. The client combines these SignatureShare to obtain a full Signature. The Client adds this Signature to the DBC contents to form a complete DBC, ready for spending.
DBC Ownership: Each DBC has an owner, identified by a PublicKey. This enables DBCs to be stored and transferred in cleartext without anyone stealing them. The mint verifies that the owner has properly signed each input DBC when it is spent (reissued).
Amount hiding: DBC amounts are hidden such that only the sender and receiver can know it. Not even the mint nodes can see the amount. Yet the mint can verify that the sum of input DBCs matches the sum of output DBCs through the use of Pedersen commitments and rangeproofs (bulletproofs).
Spentbook: Each Mint node writes to a Spentbook. During each reissue the mint node will first verify that all input DBCs are not already in the Spentbook (have not been spent) and that all signatures and outputs are correct. It then records each input as spent in the Spentbook. Ideally we want to move this to the client, see below.
Future Improvements
We’re still looking at where we can make enhancements to the DBC system, and the following are all under consideration:
One time keys: The mint nodes would enforce that each public key can only be used in a single reissue transaction. This can help with privacy because it prevents keys being used in multiple transactions.
Client writes to Spentbook: With this setup, the client would write Spentbook entries before contacting the mint. The benefit of this is that the reissue call becomes idempotent, meaning that a client could make the same reissue call many times and receive the same response each time.
Blind Signatures: This would bring us a true ownerless “bearer” certificate. A pure form of untraceable digital cash, if you will.
Public Spentbook: Making the Spentbook public is considered desirable/necessary for the public to audit the money supply, i.e. to verify that additional money has not been created either through fraud/theft or bugs/errors.
For anyone interested in diving deeper, our DBC code is in the sn_dbc crate.
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!
So much more a validator role, but not a creator role. More to be done, but looking good