Progress doesn’t happen in a straight line, and that’s particularly true when breaking new ground. Sometimes that ground turns out to be a light, easily-tilled fertile loam and other times it’s thick clay. Which is a roundabout way of saying we’re still in sticky stuff and the testnet isn’t quite there yet.
This will be the last update this year although if we get something testnetty operational before the Christmas holidays we will of course let you know. (We are currently debugging some full adult issues, and wrestling github’s releases. Once we have those sorted we’re super keen to get something into folks hands to test out the latest CLI builds “soon” (as we say around these parts: YMMV ) ).
In the meantime we’d like to take the opportunity to review the last 6 months of the team’s efforts and ideas, because the other thing about progress is that it’s easier to see when you’re looking back down the mountain.
With all hands busy on getting the testnet out, we’ll skip the General Progress section this week and jump straight into the review.
In July we looked at Pedersen commitments and range proofs and their role in confidential transactions. Pedersen commitments are a form of zero-knowledge proof designed to hide the values in transactions while Range proofs make it cryptographically impossible for an output value to be outside of a certain range.
In August we were all knocked back severely by the sudden and tragic death of our office manager Sharon who had just given birth to a baby daughter. As David said: ‘Marsha will know her mum as we have known her, an absolute gem of a human being. Here’s to you Sharon, you made me a better person and will always be in my thoughts as will Marsha’ .
The month saw us moving functionality out of qp2p and into the Safe Network repository, to give us more control in handling connections.
Jim unveiled the results of some market research we’ve been conducting, including three significant categories of end users to target when the network’s ready. It also touched on the need to accommodate a healthy app ecosystem but not rely on it, and to offer immediate value to users while allowing the third party developer community time to mature.
September saw our first look at DBCs. DBCs are central to the design of Safe, providing 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. This post introduced concepts including ‘client writes spentbook’ and one-time keys, while a follow-up update stepped into unlinkability and fixed denominations.
Our implementation of DBCs is truly cutting edge, which means we’ve been trying different options in parallel to see which is the best fit. As such, some concepts including fixed denominations have been dropped in favour of Ring CT. We fully understand this can be difficult to follow (it’s tricky for us too! ) but we’re always keen to explain progress as it happens rather than after the fact, even if that does involve stepping into a few blind alleys. Among other advantages it allows us to test out ideas with the community.
DBC mints are still very much with us although implementation details are still evolving. We looked at some key features including the Spentbook and DBC ownership. Once again, our work is pushing the boundaries of what’s possible so expect some more toing-and-froing here too.
October saw us consolidating all the crates into a single repository safe_network. Unfortunately this was one of those occasions where the going was tougher than expected. We were a little overoptimistic at the time in saying the API and CLI repositories were pretty much ready to go, which is one of the reasons for the delayed testnet rollout.
As we were busying ourselves bashing the wee blighters we thought a bug backgrounder would be in order, so at the end of the month @joshuef explained the types of glitches we’re seeing and how we are eliminating them.
The start of November saw some graphical fireworks from Jim, as he demonstrated the mobile UI/UX he’s working on in terms of designing secure, resilient and usable credentials for Safe.
Then we turned the floor over to @bochaco to explain how we’re representing network knowledge - the processes by which Elders keep track of the topology of the network in the form of a DAG and also took a look at distributed consensus and how Safe bridges the gap between the store-forever transactions of blockchains and the distributed data management of Paxos and Raft.
And with the nights drawing in (in the northern hemisphere at least!), we huddled around the fire as @lionel.faber explained how Anti-Entropy is being applied to distributed key generation (DKG), the way we manage the agreement process between nodes, in order to handle asynchronous messaging.
Which brings us back to DBCs. As mentioned above, @danda and @davidrusu were working on alternative approaches and the one with the most workable benefits is building on RingCTs, the basics of which we described last 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!