Last week we noted that Digital Bearer Certificates (DBCs) have been around for quite some time but have failed to gain traction as a basis for digital cash. In part this is because they required some sort of centralised governance. We believe that with Safe Network’s unique architecture, DBCs will finally live up to their potential. We explain why below.
General Progress
Membership has now been integrated into the Safe Network. This is the culmination of an epic slog by the whole team and it represents a major milestone.
Membership is the consensus mechanism which ensures elders can keep track of the adults and other elders in their section. Closely related is handover - the process by which data is exchanged between nodes on churns and splits. @qi_ma and @anselme are making solid progress here too. Distributed key generation (DKG), the mechanism by which new Elders reach agreement on the new section key, still has a few glitches to work through (or around) and that’s our main focus now that membership is out of the way.
We’ve set up initial benchmarks for some simple upload paths so we can a) check for regressions, but also b) get some nice visual output on relative performance as PRs are merged.
Meanwhile, new boy @Roland is getting sucked into the code, tightening up the workings of the resource proof module. And @bochaco has been making great progress with the DBC integration into the CLI.
DBCs on Safe Network
DBCs are a key component of the Safe Network, providing a quick, secure, flexible way to make payments that is compatible with multisig/threshold signature cryptography and can be used online and offline. They simplify many of the workings of the Safe Network economy.
Most digital cash schemes feature a mint to issue DBCs and to check they are valid when they are presented back to the mint for reissue. They also need a record of transactions called a spend book or spentbook. With centralised systems, the mint and spentbook becomes a single point of failure, which is one reason these schemes have failed to take off.
However, a decentralised network allows ‘the mint’ to become multiple mints, with each section running and controlling its own spentbook. Indeed, this was our original design, but having a spentbook in each section made keeping track of transactions a challenge - we want to avoid having to sync between sections at all costs.
So, given that DBC’s will be used to pay for data-storage, we get into a bit of a chicken or the egg problem for how to store the spentbook on the network. We need to write to the spentbook to spend a DBC, but if the spentbook was backed by the existing data-types, we’d require a DBC payment to spend a DBC!
To circumvent this, we’re looking to introduce a new data type on the network optimised for the spentbook that does not take a payment to update.
When a client initiates a transaction, perhaps to pay for a data upload or to make a payment to someone else, it makes the request to the relevant section. The elders check the operation is valid and that the DBC does not already have a spentbook entry associated with it. Provided all is OK, they sign the data and write the spentbook to the network.
The fact that the spentbook is a piece of data on the network which can be referred to by anyone has some highly desirable consequences.
First, it means data which has been paid for and signed by a section (i.e. valid in the eyes of the network) can be republished any number of times for no extra charge. The elders simply check if there is a spentbook entry for a given chunk (which would have this “Network validation” attached). This allows us to handle lost outputs, machine reboots, elder churn, etc., and if the network needs to be upgraded we can easily revalidate all data.
It also means that we can do away with the concept of a mint, as the section elders are validating the DBCs as part of the process of writing the spentbook, which is a simplification and a burden removed from the busy elders.
The spentbook is linked all the way back to the genesis DBC meaning it can be audited. The design is still being finalised, but it involves having an ordering DAG that represents the spentbook but can be easily traversed. More on that soon.
The design of Safe Network offers intrinsic Sybil resistance, helping to secure transactions. The elders, of course, are the most trusted nodes in the section. Nodes are demoted for bad behaviour (Node Age), and an attacker can’t predict which section his or her node will end up in, so once the network is large, controlling a section would be infeasibly difficult.
Also in Safe we make extensive use of multisig cryptography, which was not a feature of the original DBC designs. It allows us to handle scenarios where, for example, a payment can only be made if a certain number of signatories have signed it off.
Another important advance on the original DBC is unlinkability. We are using Ring Confidential Transactions to obfuscate the sender, the receiver and the amount transacted, making it as cash-like as possible.
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!
