Testnet
Right up until these last few minutes today we have been pulling all the parts together with the aim of running a hosted public test network. It’s not available to all right now, but it is up and running (and breaking 
). We had hoped to release details to join our network tonight at least as a node only (no clients) network, but have pulled back at the last minute to resolve some issues we’ve found. We are still working on this to get that Christmas present for everyone. Keep your eyes peeled over the next few days to see how we go. We are likely to get enough stability to host a public network and open the floodgates for you to help us hammer out any further loose ends.
While we resolve the issues we’ve found, if anyone would like to launch their own local network, or even a shared network with friends, the code is all public so we invite you to do so. You’ll no doubt eventually come across some issues that we have tonight, but you’ll get a sneak preview of some exciting progress such as Section Splits, AT2 Token Payments and Accepting New Nodes When Resources Are Required.
How do I launch a local testnet on my machine?
You will be able to create a Safe on this network, log in, upload data, create keys and wallets, and all the other commands described in the CLI User Guide. This guide will take you through starting a local section, but of course it can be applied to starting/connecting to any shared section, hosted by anyone, with a few tweaks as per the afore mentioned User Guide.
First off, lets clear out some old files you may still have from a previous testnet to make sure they don’t interfere or cause confusion:
$ rm -rf ~/.safe
Now download the latest CLI binary via our install script with the following command:
$ curl -so- https://sn-api.s3.amazonaws.com/install.sh | bash
This script downloads the correct binary for your OS, installs in the correct directory and adds it to your path.
Next you should update your Authenticator daemon and Node to today’s latest releases. You can do as follows:
$ safe auth install
$ safe node install
We can now launch a network using:
$ safe node run-baby-fleming
This will launch 8 nodes on your machine: 5 adults and 3 elders.
We can also add further nodes to the network, this is achieved using safe node join as follows.
Note that you may need to set the RUST_LOG environment variable before starting your node to prevent the logs from being too verbose.
## for Linux and Mac OS
$ export RUST_LOG=sn_node=trace
## Windows (command prompt)
$ set RUST_LOG=trace
## Windows (powershell)
$ $env:RUST_LOG="sn_node=trace"
And then start the node with:
$ safe node join
Storing nodes' generated data at /Users/maidsafe/.safe/node/local-node
Starting a node to join a Safe network...
Launching with node executable from: /Users/maidsafe/.safe/node/sn_node
Node started with hardcoded contact(s): ["127.0.0.1:12000"]
Launching node...
Node logs are being stored at: /Users/maidsafe/.safe/node/local-node/sn_node.log
Your node will now launch and attempt to connect to your local network. You can keep an eye on its progress via its logs, which can be found at ~/.safe/node/local-node/sn_node.log.
Before working your way through the rest of the CLI commands remember to authenticate and create your Safe.
Enjoy having a play and, as always, do please let us know how you get on. More details and insight into the innovations included in the latest releases will be presented once we believe it is stable enough for us to host and invite you to join for a much larger scale testnet than could be hosted locally.
Known issue
There is a known issue in this release which we are still working on to fix. The first time authorising the CLI application with authd, using the $ safe auth unlock --self-auth command (please see this section of the User Guide for more info about this command), you may get an error when trying to upload a file, or write data to the network, for example this error may be returned:
[2020-12-17T20:21:06Z ERROR safe] sn_cli error: [Error] NetDataError - Failed to store Public Sequence data: Data error -> Unexpected error: Could not get history for key PublicKey::Ed25519(d802d5..) - ClientError::DataError -> Unexpected("Could not get history for key PublicKey::Ed25519(d802d5..)")
In such scenario, please just go ahead and run the same command again, to unlock a ‘Safe’ as before, and then try again with writing data to the network.
Safe Client, Nodes and qp2p
Safe Network Transfers Project Plan
Safe Client Project Plan
Safe Network Node Project Plan
A lot of work has been put into tying up the rewards flow, with the main thing being the distributed actor (section wallet) run by the Elders. Section wallet replicas are now in another section.
Additionally, a different initiating step has been added for the distributed actor, which converges with the regular AT2 flow. This allows the replicas to accumulate the signatures of the actor shares, and send it back to the actors, before they hook back onto the AT2 flow with sending in the transfer validation. This is on the verge of completion.
We’ve also been updating dependencies of the sn_api repo, as we continue making the necessary changes to this repo codebase to adapt to new sn_client APIs, fixing issues and trying to get all our automated tests to pass when they are run against a local network. We’ve made good progress on this, and we have most of the sn_api tests passing with some minor issues still to fix and some more work on the test themselves.
Some effort was also put into the CLI to get all commands to work on top of the changes in sn_api. So far we’ve been able to run most of the commands successfully against a local network, and now we also need to work on making sure the automated tests pass as they need some minor changes as well.
On the Client side we’ve cleaned up some potential bugs around the simulated-payouts, where due to the nature of those faked signatures, several messages could be returned to/from nodes, which was resulting in incorrect balances being found.
Otherwise, as some have noted on the forum, we’ve been setting up some simple scripts to aid with internal testnet creation/destruction so we can keep pushing the testnets and testing new functionality more easily.
BRB: Byzantine Reliable Broadcast
Work this week centered around integrating the new dynamic membership code with the pre-existing deterministic secure broadcast implementation. That integration is now working. Further work is being done to make the code production quality, such as minor refactoring to remove all unwrap() and panic() calls.
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; 
Japanese; 
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!
.
