Update 09 March, 2023

Just a quick progress report this week as we find ourselves across lots of jobs again, with no major new tool, development or idea to report.

Thanks for the comments on the payment-only network. We are evaluating this carefully from a technical perspective but also strategically. Close coordination with our legal team is required, so we’ll keep you updated as discussions progress.

We’ve been testing the stable set architecture using stateright and so far so good :grinning:. We’ve modelled the simultaneous loss of all seven elders and subsequent promotion of seven adults from the stable set. Stateright takes quite a while to grind through 160 million-odd states, but none of those is a fork, which is very encouraging. We’re not out of the woods yet, though, because while membership seems solid, functionality built on top of it may not be. So that’s the next step.

@Oetyng has been using this period between major jobs to do some spring cleaning and refactoring work. One of those is integrating reward keys into sn_node. The previously used ed2559 reward keys, which were stored in ~/.safe, cannot be used with DBCs as they are now. So we have updated them to BLS keys and added them to the node info, and - importantly - to the structure that is voted on in membership. The elders must know the reward key of a node so that they can validate incoming payments and verify that the transfer/store cost is paid to the nodes.

Later work will see:

  • Elders included in outputs when spending DBCs.
  • Elders confirming that spends contain outputs destined for them.
  • Implementing a commonly known deterministic transfer/store cost and distribution to nodes.
  • Including transfer/store cost in outputs when spending DBCs.
  • Elders confirming that the amounts in those outputs are sufficient.

He has also removed the ambiguous ‘peer’ concept, where clients and nodes were treated the same for messaging purposes, creating a clearer path for client and node related logic. This is a long due change, and with reward key integration the use of reward key as part of a node makes much more sense.

Also working on DBCs is @anselme who is looking again at payments now that the earlier RingCT design has been deprecated. Much of the previous code for payments should be usable and he is sorting through that now.

@roland has completed a course in OpenSearch - the platform we are using for telemetry.

We are still seeing bugs when nodes fail to join, and @qi_ma is on that one now.

Mostafa is fine tuning the consensus algorithm to ensure that all proposals are accompanied by supporting evidence.

@Chriso continues to simplify the CLI and remove wrappers and unused or unhelpful commands. Now’s the time to shout if there’s something you want to see in the CLI. Please use this thread for suggestions.

And last but not least @bochaco is upgrading Quinn and all dependencies of qJSON-RPC. He’s also looking at gRPC, the remote procedure call framework originally created by Google, since it seems inevitable that this is the way things are going with support for HTTP/3 & Quic. It offers many advantages over qJSON-RPC.

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!


Tada! :tada: first


Insider trading here, but why not… FIRST!

Doh! Second!


I thought I was getting slow… perhaps first to read. Good update… there’s a lot of value in bedding down what exists. Keep at it :+1:


First is the worst,
Second is the Best,
Third is the one with the hairy chest,
Fourth is the one that God loves best…


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


Great stuff team another step along the road we go :slight_smile:


Spring cleaning and housekeeping all 'round. Well it has to be done regularly or things get messy I suppose.

Good to hear that the Stateright system is off to the races and that the code is handling it! :tada: :clap: :clap: :clap:

Thanks for the hard work Maid team!



ChatGPT summary:

The update reports that there is no major new tool, development or idea to report this week. The team is evaluating the payment-only network carefully from a technical and strategic perspective with close coordination with their legal team.

They have been testing the stable set architecture using stateright, and membership seems solid, but functionality built on top of it may not be. They are now integrating reward keys into sn_node, which will be used to validate incoming payments and verify that the transfer/store cost is paid to the nodes.

The team is also still working on resolving bugs when nodes fail to join and fine-tuning the consensus algorithm to ensure all proposals are accompanied by supporting evidence. Finally, the team is upgrading Quinn and all dependencies of qJSON-RPC, and looking at gRPC, which offers many advantages over qJSON-RPC.

Privacy. Security. Freedom


Thanks for the update and hard work team! The use of Stateright is inspiring… should help some very difficult to find problems in a live network.


The headline this week should be the team continues to put its nose to the grindstone, for which we thank them and remember that many of the devs could make a lot more working on other less socially-valuable (some might say crucial) projects. So an extra layer of appreciation on top there folks - Thank you all.


Thx 4 the update Maidsafe devs

This is really great news

It might be useful to look at similar projects CLI, to get new or additional ideas.

This is what I love the most about this project, constant change, if need be.

Keep hacking super ants


I’m curious about what this telemetry is. I guess it’s a bit like google-analytics for nodes to report performance/operations that can be easily analyzed?

Is it something nodes from home can disable?

Is OpenSearch something that runs locally alongside each node or is it something that runs remotely and is an aggregation of several nodes info?


AIUI its disabled by default - you need to explicity enable Open Telemetry by building with features=otlp


Is this equivalent to a network restart? Seems at least in the same realm and very promising toward that goal of a graceful network restart.

Also have there been any tests or evidence to suggest further robustness when increasing section elder count from 7 to 9? That increases section size/adult count as well, yes?

Would a payments only network get these stable set improvements before launching?

I have a lot of questions :laughing:

Thanks @maidsafe for the amazing effort and progress, as always.


We are still modelling and will be able to answer all of this soon. Int terms of the 7->9 we don’t even need that as the elders are all known along with next elders. So lose 1 and immediately we still have the 7 top guys there. So much more insta promote approach.

I hope so for sure. But it may happen in 2 phases


So my second question regarding that would be is there any other benefit to section size being smaller or larger? I would assume smaller sections would be better? More decentralized and less attack surface. So in that case 7 elder count would be better? So maybe no benefit at all given stable set performance.


Interestingly the larger section size makes sybil attach much harder. We modelled a few years back sections over 60 were centuries before you could get a sybil attack by adding nodes and waiting.

Large section size also allows a lot to go wrong before you are small enough to lose elders, but that’s not so important as if a section got that small data is lost. So unless the kind of mass extinction of nodes happened and it was permanent then we risk data loses big time. If the mass loss was transient (the nodes restart), then we would be OK.

The actual elder coin in the section does matter actually and different to what you would imagine. The smaller elder count actually helps security for 2 reasons

  1. Giving younger (less trusted nodes) a vote (all elders are equal) actually reduces security.
  2. The smaller the decision maker group, the faster you get decisions.

So stable set addresses the 7 or 9 problem, but making it not matter as for crash failures we have almost immediate promotion.


So there is serious consideration to having a payments only network that is perpetual, even after SAFE network is launched and not just a test network to gather data on bugs and social interaction with it.

There are a number who believe this