A Network that respects its users
The SAFE Network is an open source software project that is designing an alternative Internet incorporating Privacy, Security and Freedom at its core.
There are many components to the Network. At the lowest level of abstraction lies Crust, a communication layer that allows any two computers to connect to each other through home routers with end-to-end encryption. At a much higher level, the Authenticator is an application that allows a user to connect to a decentralised, permissionless network without the userās password and private key ever leaving their own machine. Between these two levels of abstraction lie many more components that make up the full design of the Network.
Weāve been building each of these layers (see our Github page for a complete list) and each component is now approaching varying degrees of completion. Integrated together for the first time over a year ago, they created a working network in the Authenticator release (a.k.a Alpha 2) of the SAFE Network.
The Routing layer
Looking at it from the backend, the Network has two key functionalities:
- the user can store data on it publicly or privately;
- the user can retrieve any public data on the Network or any private data that they own.
To use these features, front end (user) software - for example, the SAFE Web Browser - communicates with the SAFE Network via a set of APIās (Application Programming Interfaces).
At the heart of the Network lies the Routing layer. Seen from that layer, the Network starts as an unstructured set of computers that are connected to each other using Crust. Each computer then uses the Routing code to decide how to connect to other computers, what information to share with them and in what circumstances. The Network then emerges from a set of computers running the Routing software and fulfils those two key functionalities above.
The next big step: a permissionless decentralised network
The Alpha 2 Network is called alpha software (as opposed to a stable release) because a crucial element of the design is still outstanding: permissionless operation. For that reason, the current implementation of the Network runs on a set of trusted computers operated by MaidSafe, the company driving the effort of building the SAFE Network.
This is a staging post on the road to full release. By design, the SAFE Network is a decentralised network that runs on the storage and bandwidth of its users. Users provide resources to the Network by running a vault, which is a piece of software that lets your computer connect to others and follow the protocols that make up the Network.
The conceptual reason for taking this decentralised approach is simple: no entity can then gather usersā data without their consent. That is in stark contrast with the clearnet (the existing Internet) where most user data is centralised in data centres that are controlled by a handful of large corporations.
Because any user can run a vault anonymously, we canāt expect honest behaviour from every participant. In fact, it is a certainty that a proportion of the users of any successful network will be malicious actors trying to break some of the invariants of the network for personal gain.
This simple fact implies a technical challenge that must be solved: how do you trust a network if you canāt trust any individual participant?
Part of the answer: consensus
One key way to have trust emerge from a number of untrusted computers is by using an ordering consensus protocol.
Agreeing on the order in which events happened in a network is key. It means that all nodes can take consistent decisions about which actions should be taken and when.
Without the luxury of a set of trusted nodes or assumptions about the time it may take for messages to be communicated over the network, efficiently maintaining agreement between the nodes is a difficult mathematical problem. The name for this category of problem is ABFT, or Asynchronous Byzantine Fault Tolerance.
In May 2018, the routing team at Maidsafe released our solution to the ABFT problem: PARSEC (Protocol for Asynchronous Reliable, Secure and Efficient Consensus).
Since then, we have been hard at work writing the code that follows this set of mathematical rules. Not only has this covered the use cases in the White Paper, but weāve also extended the code to cover further areas that are crucial in practice (like identifying and dealing with malicious nodes on the Network).
We are now reaching a point where we can integrate PARSEC with the rest of the Routing code, with only a small number of loose ends to tie up.
Are we there yet?
In early 2018, consensus was one of the biggest unanswered questions in the design of the SAFE Network. So now it is answered, the obvious question is: āwhatās next?ā and how long will it be until you get your hands on the next iteration of the SAFE Network?
Enter SAFE-Fleming.
The design of the Routing layer in the Network has grown organically since the inception of the idea for the SAFE Network twelve years ago. Many design elements were presented and discussed using our RFC (Request For Comments) process. Some were actually implemented and are already operational in Alpha 2.
But with SAFE-Fleming, the time is approaching for the implementation of all of the features needed for a fully-functional permissionless decentralised network.
Hold your horses!
Weāre almost there. But before we jump straight into the implementation of the many design elements weāve built over the years, we are using the time wisely in order to take a holistic look at the Network design as a whole. Weāre ensuring that all components fit together nicely and handle the worst circumstances that they might face when the Network goes live.
This work is giving the team an opportunity to develop new insights on certain aspects of the Routing layerās design. We thought we would write up a series of posts to share some of these key insights with the community at large. One of our goals in doing so is to spark many interesting conversations with the SAFE community and keep us focused consistently on evolving the strongest possible design together.
