Thanks to the great effort and participation in the recent Vaults from home testnet iteration 1, we were able to identify some issues and areas for improvement in terms of network performance and memory usage of the Vault binary. Today we are happy to announce iteration 2 of the new and improved Vaults from home testnet.
As with the previous iteration, today’s release includes a single section network of ten nodes that are deployed on DigitalOcean. Seven of these are the initial bootstrap nodes to join the network, hence they are the Elders. The remaining nodes are two Adults and one Infant. See the Further Information section at the bottom of this post for an explanation of Elder, Adult and Infant nodes.
As a user you can run a Vault that will join the section, will eventually be promoted to an Adult, and then given the responsibility of holding Immutable Data chunks. The Vault uses the IGD protocol to forward the internal port number on your computer to an external port on the router. This will allow the other nodes to seamlessly communicate with your running vault. As vaults running from home may go offline, we need to ensure that a minimum number of copies of each Immutable Data chunk is always available on the network. The Vault binary released today includes a data recovery mechanism to maintain this copy count.
What’s new
We have changed the way signature accumulation is done in Vaults. Previously, Routing handled the signature accumulation internally with some additional information that is limited to the internals of Routing. Because of this, Vaults could not make use of the BLS signature aggregation that was already being done. We have refactored the implementation in such a way that the Vault handles the accumulation of the signatures for client messages, instead of Routing.
With the Vault handling signature aggregation instead of Routing, we can now make use of the aggregated signature to validate responses against their associated request to ensure that the request was approved by the section. This removes the need for caching requests and ahead of time responses in memory, significantly reducing memory utilisation of the Vaults.
This iteration of the testnet also includes a change that delegates the responsibility of duplicating data (when a data holder leaves the network) to the node that would be responsible for the new copy. This removes a significant amount of processing that was previously performed by Elders.
Sequence data type
A new data type has been implemented and included in this iteration of the testnet. As most of you will know, we’ve been working on transitioning our native SAFE data types to become CRDTs (Conflict-free Replicated Data Type). We’ve started by migrating our previous AppendOnlyData to a new data type called Sequence, which is implemented as a CRDT.
From a user’s point of view, there is no change to the APIs and CLI commands we’ve been exposing so far - the CLI commands to create and manipulate FilesContainers & NRS Maps are all the same, although they are now stored on the network as Sequence data.
Nevertheless, there are a couple of new commands supported by the CLI to create public and private Sequence data on the network with any type of raw data, as well as append new items to it once stored using its XOR-URL, e.g.:
$ safe seq store "my initial note"
Public Sequence stored at: "safe://hnyyyyp3yb3dczuaaiwx1mb5491xir4kz1hex3d1pc34oxwicy7scm3x4ybfo"
$ safe cat safe://hnyyyyp3yb3dczuaaiwx1mb5491xir4kz1hex3d1pc34oxwicy7scm3x4ybfo
Public Sequence (version 0) at "safe://hnyyyyp3yb3dczuaaiwx1mb5491xir4kz1hex3d1pc34oxwicy7scm3x4ybfo":
my initial note
A new section in the CLI User Guide has been added with more detailed information about this new safe seq store command, and several others, so we definitely recommend you take a look at it to fully understand the different functionality offered by them.
What it doesn’t do
As discussed above, this iteration of the testnet is solely focused on fixing the issues identified in iteration 1, which we released on 11th June. Some notable limitations which we highlighted with the previous iteration remain:
-
Section splits have not been implemented.
If the single section network we are running breaches its size limit then we may need to restart it. There isn’t an exact number of nodes which will trigger a split, this depends on how the nodes on the shared network are prefixed and so divided into subsections, with node churn making prefix members vary. We can say for certain that the minimum number of nodes that could trigger a split is 1000. We have increased this value to delay the section split in this testnet iteration. -
If your router does not (correctly) support the IGD protocol, you will not be able to take part in this testnet iteration.
Don’t worry, we have solutions for you but would like to save them for a future iteration of the testnet so we can concentrate today on ensuring that our improvements are effective, our IGD solution works as expected, and to get a general overview of how many participants out there actually have routers with working IGD. If your router does not correctly support IGD then you will see the message below in your vault logsAutomatic Port forwarding Failed. Check if UPnP is enabled in your router's settings and try again. Note that not all routers are supported in this testnet. Visit https://forum.autonomi.community for more information.If you do not see this exact message in your vault logs, leave your vault running. In the previous iteration, we saw several instances of log messages such as
Could not send the IGD response: sending on a disconnected channel - "SendError(..)"which could be interpreted by some as IGD failing, but this is not the case and your vault should eventually start contributing to the network.
Instructions for updating and joining as a Node
You can bootstrap to the network using the nodes running on DigitalOcean as hardcoded contacts, then watch the logs as your vault joins the network, progresses to Adult status, and plays its part in hosting Immutable Data Chunks. Of course, you will also be able to create an account 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 connecting to the shared section started by MaidSafe, but of course it can be applied to connecting to any shared section, hosted by anyone.
To connect you should first make sure that your CLI, Authenticator daemon and Vault are all updated to today’s latest releases. If you already have a version of each of these installed, you can update as follows:
$ safe update
$ safe auth update
$ safe vault update
If you need to install these fresh then you will find instructions for each in our user guide:
You now need the network configuration containing the details of a hardcoded contact that will bootstrap you to the shared section. We store and update these connection details on S3 for you to easily point your configuration to. If you have connected to this or previous iterations of our shared section then you may already have a shared-section network profile saved on your machine. You can confirm this and update it to the latest configuration we have posted using safe networks check:
$ safe networks check
Checking current setup network connection information...
Fetching 'my-network' network connection information from '~/.config/safe-cli/networks/my-network_vault_connection_info.config' ...
Fetching 'shared-section' network connection information from 'https://safe-vault-config.s3.eu-west-2.amazonaws.com/shared-section/vault_connection_info.config' ...
'shared-section' network matched. Current set network connection information at '~/.config/safe_vault/vault_connection_info.config' matches 'shared-section' network as per current config
If you don’t have a configuration in your results which points to the exact S3 location listed in the results above, you can add using safe networks add:
$ safe networks add shared-section https://safe-vault-config.s3.eu-west-2.amazonaws.com/shared-section/vault_connection_info.config
Network 'shared-section' was added to the list
Now you need to ensure you are set to use this shared-section configuration that we have updated/added, we can use safe networks switch shared-section for this:
$ safe networks switch shared-section
Switching to 'shared-section' network...
Fetching 'shared-section' network connection information from 'https://safe-vault-config.s3.eu-west-2.amazonaws.com/shared-section/vault_connection_info.config' ...
Successfully switched to 'shared-section' network in your system!
If you need write access to the 'shared-section' network, you'll need to restart authd, login and re-authorise the CLI again
We now have our CLI, Authenticator daemon and Vault components up-to-date, and we have the latest hardcoded contact details to bootstrap to the shared section so everything is in place and we’re ready to launch our vault and add it as a node. This is achieved using safe vault join as follows. Note that you need to set the RUST_LOG environment variable before starting your vault to prevent the logs from being too verbose.
## for Linux and Mac OS
$ export RUST_LOG=safe=trace
## Windows (command prompt)
$ set RUST_LOG=trace
## Windows (powershell)
$ $env:RUST_LOG="safe=trace"
And then start the vault with:
$ safe vault join
Creating '/Users/maidsafe/.safe/vault/local-vault' folder
Storing vaults' generated data at /Users/maidsafe/.safe/vault/local-vault
Starting a vault to join a SAFE network...
Launching with vault executable from: /Users/maidsafe/.safe/vault/safe_vault
Node started with hardcoded contact: 161.35.36.185:12000
Launching vault...
Vault logs are being stored at: /Users/maidsafe/.safe/vault/local-vault/safe_vault.log
Your vault will now launch and attempt to connect to the shared network. You can keep an eye on its progress via its logs, which can be found at ~/.safe/vault/local-vault/safe_vault.log.
Do I need to run a vault to participate?
The highlight and primary aim of this release is to be able to run a vault from your own home (IGD dependent) and watch as it plays a part in a wider network, but you do not need to run a vault in order to participate in the shared section testing. Whether you are running a vault or not, you can still connect to the network as a client and do everything you could do on the previous single section networks that you may have ran from home or that MaidSafe hosted and you connected to. See the CLI User Guide for a comprehensive list of available commands and instructions on how to use them.
Further Information
What is IGD?
IGD is short for Internet Gateway Device Standardized Device Control Protocol. As most people running vaults from home will be behind a router, IGD allows us to automatically map the port that your vault runs on, and so seamlessly allows data to flow in and out of your vault. Without correctly functioning IGD, a user would need to manually set up this port forwarding on their router.
Incorrectly Functioning IGD
Many routers that claim to support IGD through Universal Plug and Play (UPnP) actually do not implement it properly and so will not connect to this version of the testnet - your log file will display this message:
Automatic Port forwarding Failed. Check if UPnP is enabled in your router's settings and try again. Note that not all routers are supported in this testnet. Visit https://forum.autonomi.community for more information.
If you do not see this exact message in your vault logs, leave your vault running. We have seen instances of log messages such as Could not send the IGD response: sending on a disconnected channel - "SendError(..)" which could be interpreted by some as IGD failing, but this is not the case and your vault should eventually start contributing to the network.
If your router has a UPnP option in its settings, please ensure it is enabled. If it still doesn’t connect to the shared section, with the logs reporting the same Automatic Port forwarding Failed, then sit tight and skip this particular iteration of the testnet. We would like to isolate those with IGD correctly implemented at first, fix any issues resulting from them, then open up to allow others to enable manual port forwarding and join in. We don’t anticipate there will be a lengthy delay before an iteration which includes manual port forwarding is made available.
Where are my vault logs?
When you launch your vault you should see the location of your log file printed on screen - this will be ~/.safe/vault/local-vault/safe_vault.log. You can tail your logs with a command such as tail -f ~/.safe/vault/local-vault/safe_vault.log
What are Elder, Adult and Infant nodes in the SAFE Network?
These terms are related to Node Ageing. Node age means that as vaults prove themselves over exponentially long periods of time (age) then they grow older by 1. Each time they age they will be moved to a different section (for security, and of course once multi-section networks are operational) and take on a new name.
Many people will run a vault briefly and that is great, but we don’t want the network to do much work with unknown new vaults. We call these Infants and as infants we don’t ask much of them, but we do monitor that they are there. We don’t remember Infants so they cause no lasting network footprint when they restart. We intentionally don’t record infant information to save network resources.
As an Infant does some work and hangs around long enough it will be promoted to Adult by increasing its age by 1 and relocated to a new section (in a multi-section network) .
The 7 oldest vaults in a section are the most trusted, we call these Elders and they make the decisions, provide network (section) authority, and decide what Adults will store what data. The Elders are the controllers of the section and the only vaults in a section that communicate with other sections. We can consider Adults as the disk space of the Elder group.
For more information on Node Ageing in the SAFE Network, have a read of the SAFE Network Primer section on it.
Where can I report any issues found?
The ant colony is only as strong as its worker ants, and you are the backbone of this colony. Please let us know if you come across any issues in your testing. You can do so by reporting these issues in the comments on this topic’s thread. We will monitor and investigate these as soon as we can.
thx for the hardwork Maidsafe devs
