Update May 26, 2022

Our primary goal with Safe Network is data permanence. We store copies of data on devices that statistically are unlikely to be in the same region should, for example, a massive power cut or government-imposed internet take-down occur. For this purpose, the more copies the merrier, but that imposes demands on storage and, in particular, network bandwidth. This week we look at one approach to tackling this issue, which should allow more redundancy with less data flow.

General progress

@Anselme has fixed a consensus bug, implementing anti-entropy for handover as well as generations. More comprehensive join retries (where we ensure we’re in the current section state) have been merged too :muscle: .

@Chriso is digging into DBC implementation and has already completed all the CLI changes for passing a DBC to a new owner. He’s now turning his attention to the sn_api side for assigning the change DBC owner.

We can also report progress on the observability front with @yogesh making nice headway with the traceroute messages, making sure all the message flows (file and register) have a traceroute response back to the client from the adults and are logged in the tests.

And @davidrusu has been spreading the word, attending another Toronto CompSci meetup to talk through Tree CRDTs. “A great discussion all around”, he reports, and a great place to recruit interested parties to Safe Labs.

In the wider safe-world, the ongoing community project to support MaidSafeCoin on the ERC20 protocol continues unabated, and we are please to announce these efforts continue to bear fruit! So in addition to Uniswap eMAID is now also open for trading on P2PB2B!

You can thank the dedicated community members such as @Sotros25 and @Mightyfool who have taken it upon themselves for pushing this topic forward continually :clap:

Optimising data transfer

When someone makes a GET request, that kick starts a number of processes. First, the request is relayed to the elders in which section the chunk is stored. The elders then calculate which four adults store the chunk - the four XOR-closest to the chunk’s address - and each of those adults pass their copy of the chunk back to the elders, who then return them to the requesting client.

This provides redundancy, there are always four adults with a copy of the chunk, and also gives us a way to monitor performance. If one adult is significantly slower or less reliable, it can be demoted. But it comes with a price tag.

If the client contacts all seven section elders asking for a 1MB chunk ‘A’, and each elder in turn requests chunk A from the four adults holding it and returns them to the client, then potentially that’s 28MB (4x7) passing across the network for a single 1MB GET request.

Currently, we are using a halfway-house system where the client contacts three elders at random and those elders contact the four adults holding chunk A - so we potentially have 12MB (3x4) of data flowing across the network for a 1MB request - better, but still not great. And reducing contacts to three elders comes at a cost: if we have only three elders interacting with the adults we no longer have a supermajority to decide if one of the adults is dysfunctional, making dysfunction tracking more complex.

A solution we are looking at now is information dispersal algorithms (IDA, also known as erasure coding). This could help us significantly reduce the volume of data transfer per GET, by having adults pass a share of the data to the elders rather than the whole thing. The elders then pass these data shares back to the client, who reassembles them and, voila, chunk A is recreated. Potentially this could reduce the flows on a GET to just 1.4MB for a 1MB chunk.

So how does it work? First things first, we’re not proposing replacing replication with an IDA. Some projects do this (e.g. Solana) but for us there are too many tradeoffs. So, just as now, if an adult goes offline its data is replicated in full to another adult. The change is that adults will be able to split chunk A into seven pieces using an IDA and pass just one piece back to the elders on request, rather than the whole chunk, meaning that much less data is exchanged.

Once it has collected five out of the seven pieces, the client can reassemble chunk A.

This five-out-of-seven figure doubtless switched on a few mental lightbulbs :bulb:, because it’s the same threshold that we use for BLS consensus, but IDA is a different beast from threshold cryptography, designed for optimising data storage and transfer rather than secret sharing. In case you’re wondering where the extra 0.4 comes from (transferring a 1MB chunk using IDA requires 1.4MB of data flows), this is an unavoidable overhead from the way the algorithm works.

So, less stress on the network and the client too, and of course all seven elders are now in contact with the adults, making consensus over dysfunction much simpler.

Further optimisations should also be possible with this architecture too. Because of recent Membership changes, we now know which adult of the three holding chunk A is actually closest. So rather than asking for chunk A, the client can ask it directly for the first piece A[0] and the elders will go straight to the closest adult; the second piece A[1], the elders will ask the next-closest adult, and so on. Any failures are simply retried at another adult. This is more efficient and means we can potentially increase the number of replicas - adults holding chunk A - without any significant extra stress on the network, with obvious gains for data redundancy.

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!


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

And thanks so much for our new DEX functionality on Uniswap. It is very important for MAID holders to have DEX access. :racehorse:


Made the podium once more. Silver again!


Bronze better than nothing F5 hates Thursdays!!

Well done to all the team now to read :slight_smile:


just a random thought, that there is potential for an app that acknowledges user’s interest for priority and does not stress the network for large file retrieval if its not that urgent… but then the test of that would normally be price, yet GETs are for free. Free makes people and developers lazy?.. what negative feedback is there for selfish resource hogs… is there a burden on the user side for the number of chunks being requested…

Perhaps if streaming is made possible then seeking within files for just the bit that’s of interest, will always be better performing and attractive because of that difference… so, positive feedback through performance, rather than negative from price.

tldr; would be nice if GETs were efficient for the real need for the file.

Thanks as always for the hard work :+1:


Getting an error trying to click the like button on the OP!?


What prevents the client from GETting from a different number of elders? Like, if it chooses to only ask 1 elder, or all the elders, how could the client be punished?

Maybe the client has to send a number specifying which subchunk to request from each elder, and then some spam-suppression can be in place for requesting from too many elders?


I have seen that sporadically too


:point_up_2: awesome

is it a mountain or a mole hill to implement? next week, next month or next year? yes I know , when is not really permitted. :slight_smile:



My understanding is the client would not be able to do that as the logic is handled at the section level. So the client requests a chunk, and all the elders (or three currently) receive the request and then decide how to proceed.


Data being spread out geographically is obviously good for making sure data is always available / never lost. When retrieving data response times are also important, asking all nodes to provide a part of the data seems like it it would be slow and detecting failures at the point the data is required.

You could just ask the closest node for the data?

To validate all nodes have the chunk you can periodically ask them all too hash a random section with a random integer. (This can also be used to keep statistics of who is closest to that that elder).

Ideally you want to encourage the nodes that hold a chunk to be as far away from each other as possible, but also know the fastest path to retrieve the data. Makes me think of the Babel Routing Protocol


It does sound fantastic.

But yeah, is this potentially a year fix?

Overall, well done team


There are already libs for this. So it’s a matter of the Adults encoding the data and giving the correct piece to each elder who then returns these to the client. So much more mole hill than a mountain. It should be 1-2 weeks man hours I think. At least of that order.


I’m sorry i’m confused. How do you break a file into 7 pieces then reassemble it with only 5/7 of those pieces? That doesn’t seem logically possible. Where does the receiver get the 2/7 missing data from? I must have missed something.


Basically think of it as the file gets made larger by circa 40% and split in such a way that you can lose some pieces and still have the file reconstituted. Here’s a quick and easy paper on it https://www.eecs.harvard.edu/~michaelm/TALKS/RabinIDA.pdf Note we don’t have a large file issue and a normal Rabin ID A(or even reed Solomon) algo is enough


I appreciate the link but this is supposed to be easy reading? This is on par with reading a physics paper.


Thanks, but no thanks David. I stopped reading (due to sudden onset of migraine) at page 3, Abstract. An Information Dispersal Algorithm (IDA) is developed… :sunglasses: Southside! Beer Me!


For a quick read I recommend the Erasure Code page on Wikipedia:-

Skip the maths! I am not a mathematician and I refuse to try to understand the weird squiggles.

The key part of the explanation is:-

Alice wants to send her telephone number (555629) to Bob using err-mail. Err-mail works just like e-mail, except

  1. About half of all the mail gets lost.[1]
  2. Messages longer than 5 characters are illegal.
  3. It is very expensive (similar to air-mail).

Instead of asking Bob to acknowledge the messages she sends, Alice devises the following scheme.

  1. She breaks her telephone number up into two parts a = 555, b = 629, and sends 2 messages – “A=555” and “B=629” – to Bob.
  2. She constructs a linear function, f(i) = a + (b-a)(i-1), in this case f(i) = 555 + 74(i-1), such that f(1) = 555 and f(2) = 629.

Code d'effacement optimal 1.gif

  1. She computes the values f (3), f (4), and f (5), and then transmits three redundant messages: “C=703”, “D=777” and “E=851”.

Bob knows that the form of f ( k ) is f(i) = a + (b-a)(i-1), where a and b are the two parts of the telephone number. Now suppose Bob receives “D=777” and “E=851”.

Code d'effacement optimal 2.gif

Bob can reconstruct Alice’s phone number by computing the values of a and b from the values ( f (4) and f (5)) he has received. Bob can perform this procedure using any two err-mails, so the erasure code in this example has a rate of 40%.

The key point is that in order to transmit (in our case store) the information data has been created that is not the information but can be used to reconstruct the information.

Note that none of the fragments Alice sent:-
C=703", “D=777” and “E=851”

are the actual information - her actual phone number:-

or even contain any of the same data!

The downside is that more data has to be transmitted or stored to guarantee the integrity of the information.

I work in IT and have to explain object storage which uses erasure codes to protect data rather than RAID. In fact, RAID is a subset of erasure coding apparently. If you do the maths…

And talking of doing the maths - constructing this synthetic data to store the information and then recreating the information from it uses needs more processing and takes longer than just storing it. And that is why it is slower and generally has to have a cache layer in front of it to get any kind of performance.

The attraction is that it is more space efficient than using RAID and definitely more space efficient than replication. When the data is being accessed across the internet the speed of reconstructing the information isn’t generally an issue.


But if I’m understanding this correctly you aren’t actually reconstructing the information you’re just creating a map to where the information is located. It’s like transmitting torn map fragments or gps coordinates to where the data is hidden in XOR space. And since SAFE stores everything ad infinitum it’s just a matter of pointing to the right file location in order to retrieve the data. So perhaps the confusion lies in that you aren’t actually having the end user reconstruct the file at all but rather the coordinates for the file location. Or am I again missing something?

1 Like