Most of the team are occupied in refactoring Authority, the code that tells us which actors can do what actions and what level of authorisation they require. We hand over to a young chap called @dirvine to explain further.
General progress
Other fixes are ongoing too.
@anselme has fixed an error in the sn_sdkg crate that involved making vote handling recursive. With this, a node doing DKG on its own would recursively reach termination upon handling their first vote in one call! (Not good).
@bochaco is continuing to debug communications between nodes, together with @qi_ma, and also correcting issues found with single-threaded commands and queries/queries in the continuous integration (CI) pipeline.
Meanwhile @bzee and @chriso continue to examine the workings of Quinn, the Rust implementation of the Quic protocol for establishing and maintaining connections between peers, with a view to refactoring qp2p.
Refactoring Authority
At the moment we have per-message Authority and that authority is split between node, client, section and section_part. It’s both confusing and bug prone. More recently, we have been digging into Authority, what it means and what it buys us.
The first step in this clean up is to remove message authority and focus on Operations. By that we mean the operation in the message is where we want to check authority and also be able to apply it directly to data. This part saves us, 1: having the authority (signatures) twice and 2: ensuring any data mutation (including storage) has the relevant Authority.
To break this down a little. To store chunks or a container (a register) we require that clients pay. When they have paid, each elder returns a part section signature. The client then aggregates the signature to create a section signature. That section signature stays with the data and makes the data NetworkValid. So there is no sense in signing the whole message, just the part that says Store ABC where ABC is the data name. So each piece of data now has SectionAuthority and we don’t care what message or format we receive the signed operation in.
So what, some may ask. Well in essence what we are doing now is quite exciting from several points of view:
- Less code again
- More concrete data types
- Removing the requirement of any message signatures (caveat in a minute).
- And the big one … see below
The astute may at this point notice a big win for decentralised networks here. With SectionSigned data elements and the SectionTree from a few updates back we have network agnostic valid data. i.e. any network that also trusts our SectionTree, even the majority of it (in the case of a mega hack) can validate and trust the NetworkValid data. This feature allows data to move to other networks, or even Safe II, who knows?
However, we do have nodes sign messages, and we think of that as Evidence. Nodes message each other and clients with data or suggestions (like node X is dead or node Y wants to join etc.) and we treat their messages as infrastructure commands (i.e. transient) or client service commands (give me data). As these messages lead to consequences on the network we require the nodes to behave. If they are found to misbehave we must have irrefutable proof of bad behaviour so we can punish them. The signed message gives us irrefutable proof of a node’s behaviour.
Taking all this into account the current refactor is rather quick, it’s only a few days, but it buys us a ton of simplicity and at the same time gives us more flexibility in storing/republishing data. Imagine you find some old data on your node, it’s not on the network but should be. Then you should not need to pay to store it, you should just say here is SectionSigned data, you MUST store it. It’s the network’s contract with the planet.
Not only that, the clients who pay to store, actually pay to get SectionAuthority on the data, making it NetworkValid. Now this means they can add the section authority to their data and choose to store it at any time they wish. They can also republish it if the network somehow failed them.
There are 3 or 4 of us taking this task this week and already, we are seeing improvements in clarity and possibly finding some weird bugs as we remove the old code from way back (messaging still has some very old code there). It’s a really neat refactor that will make bug hunting so much more simple as it makes the network operations more simple. It also makes the network simpler to explain.
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!
I think this often happens when you manage to take something complex and find a simpler solution, but is often very hard so 
… so getting us a lot closer to beta.
