If you Google Digital Bearer Certificates (DBCs) you’ll find that this forum comes up in the first page of results, which is pretty amazing when you think they date back to the 1990s. This week as we prepare to integrate DBCs with the rest of the codebase we’re going to do a quick review of the history of DBCs, what they are and what they aim to achieve. Next week we’ll go over how we’re tailoring DBCs to take advantage of the unique architecture of the Safe Network. We’re breaking brand-new ground here folks!
@yogesh has tidied up the last bits of automating the Metricbeat service on testnets and we now have a dashboard that visualises all our testnet nodes’ metrics (see this PR). We’ll be testing this internally asap, and then hopefully opening it up to the community thereafter.
Meanwhile @JimCollinson has been updating crypto exchanges and listing sites including CoinMarketCap to update them about the ERC20 eMaid option and also highlight the potential of DBCs. In parallel he’s been working on the new whitepapers, with a focus on Token distribution in particular, which we look forward to hearing with you all via the Request for Comment (RFC) process in due course.
@joshuef has merged a large refactor of some of the node internals, pulling
sn_interface out of
sn_node as this is common code used for both nodes and clients. The end goal here will be to get a separate top level crate for both
clients in the
safe_network repo. Somewhat similar to our prior modular repo structure… but everything in the monorepo to keep updates smooth. This should help keep the code modular and more easy to test, as well as (hopefully) make it a bit easier for newcomers to the repos to get into the code.
There’s been good progress on the membership front. We’re seeing where some issues lie with different elders having a slightly different view of section members, which looks like it has been the sticking point for section startup and splits. There’s a couple of angles of attack there, so we’re investigating those now.
And last but definitely not least on the engineering front, @anselme and @qi_ma have made some positive steps with handover consensus (the process by which elders pass on their data/knowledge on changes to section membership) and are currently working with @davidrusu to get this working properly on section splits.
Finally, you’ll have noticed that eMaid is now available . Many community members have been asking for this option for a long time, but this apparently simple move is actually extremely complex and would have taken too much time for the MaidSafe team to organise, to the detriment of the network. So huge thanks to @Sotros25, @SwissPrivateBanker, @Bamboogarden and others for stepping up and making it happen. A fantastic achievement.
Digital Bearer Certificates
DBCs aren’t new, but amazingly, given their potential usefulness, they are not well known even in the crypto space. Because of that, as we start to integrate DBCs into the network we thought a little backgrounder would be in order.
They 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 and remove the need for section wallets or similar mechanisms to manage SNT transfers. Transactions using DBCs are very quick and low on resources - unlike blockchain transactions.
DBCs were first proposed by Nick Szabo in 1997 as a way of digitally transferring and storing value. They’re not much to look at, just a long string of characters, but those characters encode important information such as the value, the owner’s key, the recipient’s key and the signature of the mint that issued or reissued it.
DBCs can be transferred to another party online (e.g. email) or offline (QR code), split into multiple DBCs or combined into a new one.
A DBC has two important characteristics (1) it needs to be valid (2) it can only be spent once. The first of these is achieved by requiring each DBC to be signed by a mint, and the second by requiring a DBC to be reissued by a mint before it can be spent.
A mint is a simple application for issuing and reissuing DBCs, and for checking they are valid and have not already been spent.
The mint keeps a record (often called a spend book) of all the DBCs it has reissued and each time a DBC is submitted for reissue it checks this record first. The other check that the mint does is to verify the signature encoded in the DBC. In the ‘classic’ DBC design, only the mint that issued the DBC can check this signature. So long as the signature is OK the DBC will record it in the spend book.
Some DBC designs use blind signatures, which allow DBCs to be verified without the mint or the receiver of a reissued DBC being able to know its value, the sender’s identity, or other factors.
The beauty of DBCs is that they are simple, quick and flexible. So long as you have access to the mint you can split them, combine them, pay for goods and receive change, similar to cash.
One downside is that they are hard to secure, as the mint is a single point of failure.
For one reason or another, DBCs have failed so far to live up to their potential. Digital Money and DBCs [PDF] is a great non-technical read on attempts to create digital cash.
But the design of Safe Network, with autonomous sections each capable of performing the issuing, reissuing and auditing of DBCs gives us a unique advantage.
So, we’re taking this centralised concept and leveraging the Safe Network’s secure decentralisation to shard the central mints, allowing for a decentralised distributed ledger.
More on that next week.
Feel free to reply below with links to translations of this dev update and moderators will add them here:
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!