What is the minimum section size value for a node?

Hi all,

I have been looking through the source code to get an understanding of how safenet works and I came across group size which is set to

let group_size = routing_node.min_section_size();

Within the node file within the routing repo, when the state machine is created the min_section_size is set to

let min_section_size = dev_config.min_section_size.unwrap_or(MIN_SECTION_SIZE);

Which is an optional property in the config_handler, I realise that MIN_SECTION_SIZE is declared at the beginning of the node class but it never seems to be initialised. Is there a reason behind this?

There is also a function which refers to self

 pub fn min_section_size(&self) -> usize {

The machine is setup here

  let (_, machine) = self.make_state_machine(&mut ev_buffer);

I’m confused as to where the value of min_section_size is coming from can anyone shed some light on this? Apologies if this is an obvious query.

Kind Regards


To clarify a little bit on Andy’s work here, he’s attempting to find the code where the vault / client / other personas decide how many vaults / clients they are connected to (or are in their local group) for calculating the PUT cost.

No it’s not - that’s just a rust import statement for the symbol. It’s defined here


I have to admit, in that case, I’m a little bit confused by what’s going on here. As far as I can see, all of the quorum mathematics seems to be calculating the numerator / denominator against MIN_SECTION_SIZE, rather than the actual number of vaults within the local group.

Am I correct in assuming that’s because all of the vaults are currently managed by SafeNet and the number has just been hard coded for now? If so, is there a branch which contains the production maths used to calculate the number of connected vaults?

I could be way off in my assumption, of course.

vaults are group-sized in a section. Section size does not necessarily correspond to vault group. Vault group size is the min-section-size: https://github.com/maidsafe/safe_vault/blob/2c3935ce78bd3d7508dff40d2e1f18fd5d1526a9/src/vault.rs#L79


Nice work @Shane This IMO is just static constant madness. min section size is group size now. The quorum is >50% of valid voters. The valid voters are the group (not the section).

The confusion is that we do not care really about more than group size nodes in terms of consensus, now. For the older code (this stuff) then it is the group size closest nodes to an address that are in charge of whatever is at teat address. so it is always group size really. There were historic code snippets that used a different figure for split and merge (mainly merge) and min section size seems to have been deemed more accurate. I would say now that is not the case. It also causes confusion like this.

So imagine the quorum in vaults is 5 where group size is 8. As the group is the closest to an address it is always 8 as long as the network is 8 or more peers. This is not the case in routing though, but that is about to change quite a bit in the current cycle.


Cost is not dependent on group/section size. It is dependent on operations requested. So if you update a MD then that it one “PUT” cost. Doesn’t matter how many nodes are storing the MD.

1 Like

According to the proposed SafeCoin implementation RFC:

StoreCost = FR * NC / GROUP_SIZE

Where FR = Farming Rate and NC = Number of clients.

So yes, it’s dependant on the operation requested, but the cost of that operation itself is dependant on Group Size and the number of clients currently connected. What we’re trying to discover is how NC, FR and GROUP_SIZE are deduced.

You are both correct. That RFC defines and shows how these are calculated, but be aware those measurements will change with data chains. The process / algorithm however will reflect the same calculation mechanism if that makes sense. GROUP_SIZE is set, NC is measured and FR is altered dynamically.

Am I correct in thinking that at the moment the published code does not represent the RFC here since it’s still a proposal? I think this gets to the root of the problem myself and @AndyAlban have been having - we’ve been looking for the code for calculating this but getting no-where (since it doesn’t exist yet).

Is there a branch on the Maidsafe Rust repos which is currently working on the algorithms for this RFC or is it still TODO?

That defines the “PUT” cost.

And then to update one MD costs one “PUT”.

The reason for saying it this way is that the MD you are updating will most likely have a different number of nodes in its section than the section you are connecting through and so your calculations would be wrong.

The section you are connecting through works out the “PUT” cost and the section holding the MD just does the operation no matter how many more/less nodes it has storing the MD than your connecting section

Ahhhh, I see the distinction you’re making now, the cost isn’t related to the XOR location of your client, it’s related to the XOR location of the MDATA you’re storing, yes?

No cost is related to your (the client) XOR location and the XOR location of the MData is not involved.

Your (the client) location charges you. The MData location does the actual work.

This could change of course. But you would be better off comparing the before and after value stored in the “PUT” balance of the client’s account to get actual cost rather than trying to work it out as it could change between your calculation and the when the “PUT” is done

Farming rate which is used to determine the “PUT” cost in safecoin value is dynamic and so if you calculate the safecoin amount of a “PUT” then do the actual “PUT” the farming rate could be different between those two times and your calculations would be wrong.

But if you look at the “PUT” balance immediately before and after the “PUT” then you would get the actual change in put balance.

And to throw a spanner into the works. If the user is doing multiple things on SAFE then even grabbing the put balance difference could include other “PUTS” done by the user in another APP.

1 Like

Yes that is correct safecoin will be done after data chains and some vault rework.

1 Like

The payment cost in the SAFE Network, is easy to understand if we think in two different balances.

We have a balance in Puts. If you want to store some data as Immutable data or store or modify a MutableData, you must pay to the network one Put for each chunk of immutable data or one Put for each storage or modification of any MD.
That’s all. You don’t need to worry who or when this data will be stored.

We have a balance in safecoin. With one safecoin we can buy Puts that will increment our balance of Puts. The quantity of Puts, that the network will give for one safecoin, is variable. If exist surplus of storage in the network the quantity of Puts per safecoin increases, if exist shortage decrease. Once spend, this variations don’t affect the balance of Puts.