Update 09 February, 2023

On the back of last week’s interesting testnet, which wasn’t functional for as long as others but nonetheless stayed up and produced some useful findings, we’ve decided to do a little explainer on nodes joining. This is something we are trying to make more reliable and easier for folks to try out. So if you notice some weird goings in your logs, that’ll be why.

Big shout out to @josh for his Gooey app, a friendly GUI to help overcome FCL (fear of the command line). Using Gooey you can PUT and GET files to your heart’s content, without feeling like you’re entering the Matrix. Initiatives like this, @happybeing’s Vdash monitoring app and @southside’s scripts are what makes this such a great community. :clap: :clap: :clap:

General progress

First some good news on the legals: Safe Network Foundation has been duly registered with the Geneva Commercial Register. @JimCollinson and @andrew.james have been working on this for many months and it represents a major milestone passed. We’ve also submitted a non-action letter to FINMA. This lays out legal opinion that SNT is a utility token for the purchase of storage and not a security, meaning we can crack on with launching. :tada:

We’re still digging into the stable set idea - using elders and the oldest adult nodes as primary data storage, while nodes that are going through the node age process are given less important secondary storage tasks to perform. @davidrusu is running experiments on that, while @anselme has been working through possible security implications.

The stable set idea brings a few interesting changes:

  • No DKG (as oldest nodes are instantly elders). This removes a significant network load on elder change.
  • No nodes in stable set relocate, so this is an append-only set
  • Nodes in stable set have no age marker, their age is their relative location in the set (based on first seen)
  • New elders sign old elders in the SAP (Section Authority Provider), this allows us to recover from lost consensus nodes (mass churn handling)
  • It’s likely we can handle partitions fairly easily with these changes, although we have no mechanism to allow partitioned networks to reconnect as yet.

@oetyng is deep into the comms between clients and nodes, getting redundant types and patterns cleaned up and trying to straighten things out there.

@anselme continues to refactor DBCs. Yesterday he replaced bls_bulletproofs with the upstream bulletproofs in sn_dbc . This not only makes the code safer as we use audited code, but also improves performance significantly!

2096 ms → 234 ms : Benchmarking reissue split 1 to 100
160s → 40s : running all tests

On the node front, @joshuef noticed that when a node rejoins it is given a different name, which requires some extra logic. That’s been fixed and nodes now rejoin with the same name.

@Chriso has succeeded in getting EC2 instances that participate in a testnet configured for telemetry collector and data prepper services, which is needed for load distribution and other tasks. He also has a testnet up and running on AWS which is submitting traces to OpenSearch. Should be a PR incoming.

@Roland has been writing an explainer on telemetry, why it’s needed and how we are using it, which we should be able to share soon.

@qi_ma is debugging node joins and relocation, and @bochacho is chipping away at messages and qp2p.

And @bzee has been stripping out redundant code from the node join process

Node join

Which brings us neatly to nodes from home. The last testnet was the first time in a while that we’ve enabled nodes joining from home (or cloud VM), and also the first ‘official’ test with smaller nodes (after a comnet saw successes there). Overall we were pleased that many folks managed to join, although PUTs seized up fairly quickly. We’ve identified what was going on here, with node relocations being sparser than we’d expected, our initial network was not “aged” enough to provide a stable startup phase.

Ideally we want everyone to be able to join from anywhere on any device, when the network needs more storage. There have been some issues with timeouts, when a node asks to join then loses connection with the elder, that we’ve mostly fixed now (nodes will receive a response saying that voting is underway, as opposed to no response; nodes also now just keep trying with the same name as opposed to switching names, which has confused the join process previously).

Some errors can occur when a node joins just after membership (the makeup of the section) has been shared between elders after a DKG session. When this happens, the new node does not get counted and there is a split view. It’s something @qi_ma is correcting now.

The safe node join flags of --skip-auto-port-forwarding and --public-addr have now been deprecated as we have removed the UPnP/IGD port forwarding, which has never been reliable. This has been cleared out to simplify qp2p for now. We may well bring this back down the line, but it’s not a priority at this time. You should just be able to join with safe node join --network-name now, although NAT will no doubt be an issue for some home nodes.

That’s because for nodes in a P2P network to be able to talk, they need to be able to find each other, but with NAT their exact address is hidden by the router which only shows the public IP. NAT was introduced as a hack to get around IPv4 running out of addresses, but unfortunately it has stuck around. Different routers and ISPs have different ways of implementing port forwarding, which not everyone will be confident to try anyway. IPv6 solves the problem, but unfortunately take-up is still quite low. It’s a problem for all decentralised networks, and we continue to look for solutions.

We plan to phase out the safe node command in favour of using the sn_node binary directly, as @Chriso suggests in this post. The node command is essentially a thin wrapper around the sn_node binary and doesn’t offer much advantage over just using the node binary directly. Furthermore, it leads to maintenance issues in terms of keeping supported arguments synchronised between the two. The node will most likely get its own install script. The safe node run-baby-fleming command will be retained, but probably become safe run-baby-fleming.

Useful Links

Feel free to reply below with links to translations of this dev update and moderators will add them here:

:russia: Russian ; :germany: German ; :spain: Spanish ; :france: French; :bulgaria: 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!


Wow, first. Been lucking into this a couple of times.

Wow! fantastic news :wink:

Really lots of good news it feels like. Thanks very much for the update team!


I’ll take silver today :sunglasses: hopefully I will get a node joined in the next test with all these improvements :pray:t2: keep it up team


will get bronze but I could get silver but my brain freezed and didnt reply when I opened the thread! :smiley:


awesome! 10 chaaaaaaaarrrrrrrrrrrr


Sounds like semplifications are happening all around, well done team!
:muscle: :fire:
Also thank you for the Node join explanation. :pray:


Thanks so much to the entire Maidsafe team for all of your hard work! :racehorse:


Awesome stuff in general.

When you say “duly registered”, does it mean filed, or ‘accepted’ e.g. is it a done deal, or the first gate has been passed.

Keep crushing it team!


Signed and sealed baby!


Great news @JimCollinson. Is the official registration available online and will the Foundation itself have a website?

Will the charity be wound up or continue in some form?


Signed and sealed baby!

Sweet music. Congrats and thanks for your tireless efforts.


Late to this party cos I am at Mrs Southsides party 21 again and its quiz night in the Allison so Il respond later if soberish.
But thanks to everyone, glad its done and dusted with the Swiss stuff, much impressed with the Gooey from Jòsh.


I like the stable set idea, and I know it’s in good hands, but there are a few points of confusion that would benefit from better clarification.

DKG’s role isn’t to select the elders (that’s for consensus), but rather to set a shared/common public key for the elders and thus the section. So how’s that being accomplished now? It seems the following way:

But how would new elder(s) coming along (selected through consensus though not mentioned) set the new shared public key by “signing old elders in the SAP”? Is the trick here that the shared public key is being done away with? i.e., the shared public key (Z) is a representation of a collection of individual elder public keys (a, b, c) and instead of using Z, you’re now using (a, b, c) directly? That would have certain implications (e.g., for addressing, funds transfers, etc.). Is something like this the plan or something else?

I presume sections are still a thing? So nodes from the “unstable” set will be promoted within (or to) these sections ensuring they grow and recover from lost/failed/byzantine nodes. Sections will also still split even if there are stable sets? And the stable sets are within sections, not forming sections of their own? i.e., a section is made up of stable set nodes (aka elders) and unstable set nodes (aka adults)?

PS: the stable set idea applied only as elders not relocating and with most other design the same would lessen DKG a lot, but not get rid of it. So DKG would only happen during splits and when an elder/stable node is lost/replaced. In a young network, split may happen frequently, but eventually, those too will slow down considerably in an older network so that DKG events occur mostly from lost/replaced elders. So it may be important to keep in mind that the demands of DKG on the young network may not be the same in an older/maturing network.


There can be multiple DKGs at once and handover comes into play there. It gets messy fast.

The shared key is now a set of keys. So when an elder changes, all other elders still keep using their own key. It’s much more instant and no DKG but has the downside of less space efficiency.

Elders are always the top of the stable set. The oldest 7.

Yes, it allows us to do this trick.

That’s right.


Yes, there is even a notion of ridding ourselves of the section tree, but that is quite radical (but a huge simplification). In the meantime, the signature would be a set of sigs. So all works the same way a section sig, but instead of a single sig it’s a set. So you have your set of sigs, check the section tree for an intersection and you are valid.



Yes, the stable set is full of nodes that do not relocate or have relocations to them. So an append only set.

I think the above answers may frame this more clearly, but DKG would not exist at all (possibly). If the stable set does what we want then I feel DKG is a massive hindrance to it (as we can have concurrent DKG, and they all need 100% participation and may all finish, so handover select the best one, I feel it’s a bit messy)


Just wondering if we will get to see the answers supplied? The questions that were presented in a topic about how the network/foundation will deal with some touchy issues.


Does the swiss transfer also mean the Bamboogarden fund is ready to come into action?


But weren’t relocations also a safety feature? So that there would be only a certain time window during which an attacker might get a rogue nodes in the same elder set? With stable set, an attacker could try to get one node in an elder position and then has ample time to try to take down other elders in order to get more of his own nodes to be elders in the same section? Or have I misunderstood something?


Relocations were not “also” a safety feature but the key factor.

In this new system, from what I deduce, all security depends on the growth of the sections being fast enough to prevent an attack

The change in security approach is huge. Have calculations been made?


Yes, you’re right and they still are. So to get to the stable set, nodes are relocated about the network. So no guessing where they end up.

Then they get in a stable set at the bottom and a long time later, they would become elders, but that time could be really long and measured in months/years when the network is large enough. So we still have the randomisation relocations bought us, but we don’t need it cradle to grave if you like.



isnt works effect there, that if “everybody” join to network with own home nodes, then in the evening, a lot of nodes turn off computer, and therefore its problem with stability…? thx