Update 23 February, 2023

More than anything else, the thing that makes reliable decentralised and distributed networking difficult is asynchronicity: we just can’t guarantee that message A will arrive before message B, or even if it will arrive at all. With a few nodes that’s OK, but in a section with tens of nodes the number of possible event and messaging combinations is huge, and a real challenge to reason over. This week we take a look at Stateright, a very useful tool for testing our algorithmic assumptions since it tries all the different possibilities.

General progress

@bochaco is testing the network’s response to different chunk sizes, including how it handles data maps. Small chunks are faster to transmit, but they make for much larger data maps, so we have to recursively self-encrypt them until they are less than chunk_size. There are other rather technical trade offs too, but basically we’re looking for an optimum size for our chunks.

@anselme and @dirvine are looking at a reason field for DBC SpentProofs - the proof of a transaction. This is a new field that contains the reason for the expenditure. It could be the hash of chunks paid for or a purchase order number, or some other sort of label. The important thing is the elders will be able to tell if it is valid or not (for example, if it is payment for a single chunk, does the Tx match the storage price for the data?).

Why do this? Simplification and security. It could mean that we can do away with the need for elders to sign data. So, no more risk of ‘old key attack’ where if a bad actor gets hold of a previous key they could use it to validate data. With this design, old elders’ signatures will no longer be valid.

The flow:

  • Client asks for quote to store data: 1 SNT please
  • Client reissues a 1 SNT DBC for the elders with a reference to the data as DBC reason
  • Client tells elders it is spent by sending SpentBook entries for that DBC (the entries contain the reason)
  • Elders check that reason and update their SpentBooks
  • The DBC is now officially spent for reason
  • Client asks the current elders for a signed copy of that SpentBook entry
  • Once client gets enough signatures, it can store the data by providing a current-section signed copy of the SpentBook entry along with the data
  • The elders check if the section signed (meaning most elders see the same reason) SpentBook entry refers to the data, and stores it.

We continue to remove read/write locks in the code for better performance and simplification (no multithreading unless absolutely necessary). @joshuef is working to remove the big one around the node state itself.

As some sharp-eyed community members have already spotted @oetyng is modelling a simplified version of a payment network.

@chriso is working on improving aspects of the CLI including reworking the update command.

And @davidrusu has been getting stuck into Stateright.


Stateright is a Rust library that promises to be a big help in testing assumptions. Basically, it’s a model checker that runs through every possible combination of events to check whether a stated assumption is valid.

Decentralised networks are hard to model for a variety of reasons: nodes can die, nodes can be Byzantine, messages can be delayed, messages can arrive out of order or not at all, you can get unexpected race conditions, etc, etc. Stateright helps us work through all those possibilities.

As an example, we might want to know whether DBC doublespend is possible with our current design. We model the assumption “Doublespend is not possible” in code, add that to our existing code base and set Stateright on it. Stateright will then run through every single combination as allowed in our algorithm model. It will delay messages, make two elders fail at once, and send events out of order. Once it has exhausted every possibility without being able to doublespend, we get a nice green tick - our assumption is valid. Every state it found was right.

If something fails, it optionally redirects us to a GUI where we can step through the messages that led to failure and work out what the problem was.

The great thing is, it tries everything, not just a subset of possible combinations. On decentralised networks it’s the edge cases that kill you, and with Stateright, unlike other methods which use sampling, you can be sure it’s covered them all. There may be millions of combinations to run through but so long as we’ve written the assumptions properly it is pretty quick.

The other thing is that it is a big help in iteratively correcting our code. It is a few extra functions we can put in our production codebase to check models. We will most likely use this to write specific pieces of production code and do so in a model. When the model is satisfied we take that production code and get it into Safe.

You can find out more about Stateright in the docs or from this video - which even though it’s an intro is quite technical.

Better still, here is a link to our current experiments. For the nosy/interested/curious just clone this repo GitHub - maidsafe/stableset-experiments. We use the master branch from Stateright, so you will need to also clone that in the same folder where you cloned the experiments repo.

Be aware, though, this is real-life Safe Labs experimental data and changes significantly day to day as we up the ante in our searches for simplicity.

If you do a cargo run --release and then open you will see the GUI. You can then manually click what messages to send or indeed click run to completion and it will show you where any current issues are. Be aware we almost always have issues there as we are iteratively testing, so don’t feel disheartened, it’s actually great :grinning:.

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!


first :innocent:

very nice to see the focus shift in bug-fixing towards the payment flows and rigorous testing of close to realworld conditions :slight_smile:
I know it will all still take longer than I expect or hope - but it feels like we’re getting closer =)


Second… …yay


Grabs a podium by the skin of my teeth!

Stateright explorer is dead easy to get running - we’ll soon see how easy to use :slight_smile:

If you have been playing with your rust toolchains - i needed nightly to look at Ribir - you will need to do rustup override set stable and then it JustWorks (so far on 30 secs poking)


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


And how far is payment network btw? Understood I correctly that some network was far enough and now u work on simplified solutions of payments? Thx


Close enough to be exciting.

A payment network is required in the full Network anyway, so if we can see how things function and test and iterate on a separate payments network via feature gating, or without much divergent work, it’s well worth doing things in parallel.


We are still working on the payments network. The above is safe labs research and relates closely to using payments even more than today. For instance, rather than sign for data, why not include a payment receipt for the data, making it network valid?

Why is that good?

Well, because the clients sign their own DBC spend, not the network (remember how I have this thing about network authority etc.). Note: and remember, this is Safe labs at work, it might not work yet. So we make clients do work, the network cannot copy that unless it itself pays for data and keep in mind DBC is auditable back to genesis. So a neat trick there, simpler, more secure and easier to understand.

There is a ton more at play here, but depending on the labs results we will release what could be a significant improvement to p2p networking, in my opinion anyway. If it works it will mean being able to run thousands of nodes on a computer, also running nodes on tiny devices and much more.

As @JimCollinson says this does not change the payments network, but it may make it more powerful in many ways. It’s a kinda magic :wink:


Another great update in treating stuff with Stateright brute force checking for Edge cases :slight_smile:

Looking forward to the next test net keep up the good work team :slight_smile:


Given the above, is there any point in working on a faucet for a testnet to put testSNT into the wallets of testers for playing with DBCs, or is this just going to get in the way?


I am not sure, actually. Right now everything is in the way :smiley: :smiley:


OK I will play with stableset ← err err Stateright Explorer and try to understand it a bit better

I am considering attaching a spare monitor in portrait mode to better visualise this


Thx 4 the update Maidsafe devs

Stateright sounds almost like quantum computing to work through all possibilities.

My head hertz, how meticulously you super ants work to code this up and integrate
the useful stuff.

Guess that’s why I stick around so long in this class, you always learn new stuff and
will keep learning even after going through all the code, if you can.

I will never ask “when lunch?”, because when a clueless consumer is handed a replicator
made by Maidsafe your getting more than lunch…


Please do keep hacking super ants


On left

Status → shows states tried, all unique states and depth of the tries, i.e. how many levels deep of finding new routes (states) to take.



Shows the properties we are looking to achieve i.e. no doublespend all membership sets converge and so on.

Path of actions

Here you manually click on messages in any order you wish. If you select Per State in the checkbox you will see for every message we are either green or we found a counterexample.

I usually though click the run to completion and it does that automatically, but for early testing, it’s good to have the manual option.

If we find a counterexample, it looks like this (I will make a bug) Below you will see the counterexample it found. I clicked on that to show you this picture. You can see the sequence diagram of messages it sent to get the counterexample (bug). It also shows the state of all nodes, what they know etc.

If you go through the path of actions you can see the sequence diagram filling up and there you will find the bug.

Then of course you work out why and then fix it :smiley: :smiley: It’s very very good


Thank you for that, David.

I will need to power down to either re-enable the onboard graphics or fit a second card cos I already have 3 monitors attached to my Nvidia card.

Once I have finished footering with the physicals, I’ll start a seperate thread for Stateright Explorer posts and repost your msg above at the top.


So validating data is far more efficient than signing for data. Less intensive for Elders, less messaging, back and forth etc because the client does the work and by having its interaction with the network logged in a reason, then Elders can look and say “those events match up”?

Just trying to fully understand this on top of the stable set work.

SafeLabs sounds like it’s already bearing fruit and this experimental stuff is exciting, especially if it makes things much more simpler and much more powerful.


That’s pretty much it. For farming elders check the payment was made. Previously then they signed the data, but in this experiment, we simply link the payment to the data. So 2 birds, one stone. That’s cool, but what’s better is that the network is not involved in signing the data here and as you say less work, but also, it fixes a huge issue, here it is.

When keys are old and useless they may still be valuable, folk can buy them and then sign stuff as elders, previous elders have the same authority as current elders. So if they sign data/DBCs etc. and we use that as authority the network has power. With this new concept, we take almost all that power away.

At the same time, we also remove all the code related to sigs, aggregation, validation and strict order. It’s actually a massive step, should it prove fruitful. It removes a ton of work, and a ton of code and makes nodes much simpler and much less CPU-intensive. A caveat, we still have a lot of serialisation, but we do lose a ton of CPU-intensive sig checks and DKG (100% participation).

If this pans out labs has paid for itself many times over and we all get a much simpler, more secure network with nodes that can run with much less hardware requirements.

I like it a lot and :pray: what we think does pan out.


The added security, huge win. The lighter nodes, could change everything.

One thing at a time, eh? I bet you all will whip it. :wink:


I feel really strongly that nodes should be as light as possible, if we are truly a solution for all humanity I feel they have to be super lightweight I am not a fan of the huge machines that are contract based “deals” between humans. I think a truly global network needs to be everywhere They also need to be able to farm for a tiny period and so on.

This labs experiment gives us a glimpse of Safe as it should be.