How does SAFE Network do churn?

What is the latest mechanism by which the nodes are accepted into a section, kicked out of one and promoted to elders etc.?

I have read the primer but I want an explanation in one place. How do I know for sure that a node belongs in a section or not? Does it use consensus?

2 Likes

When a node asks to join the network, the section contacted will assign the node an ID to use and the node is redirected there. Consensus is used.

The section that the node has been assigned to by that initial request to join the network then accepts the node or rejects it. The node can be rejected if there is already a infant node in that section, or if the section has all the nodes it wants.

Can someone confirm if the initial section contacted sends a message to the assigned section or if its pure crypto sigs that verifies the new node was assigned to that assigned section.

Yes consensus is used to make all these decisions. No node can make a decision on its own. The decision making unit in the safe network is the section and consensus is used in the decision making to ensure its validated.

This is why to cause problems in the safe network the attackers need to have 34% of elder nodes to disrupt consensus and 67% to enforce the attackers decisions.

The promotion to elder is part of the ageing process and if the section has enough elders then no more nodes will be promoted.

The churn process is the part I need to educate myself more on. So sorry what I said is to do with initial joining to the network. Churning process involves removing the node from the section and reallocating it to another section.

11 Likes

This is what I’ve been told by another

Nodes age increments by 1 when they are relocated.

Nodes may be selected for relocation whenever a new Network Event (NE) is created (this is the same thing as a Block in the datachain being created). A NE is created when a vault joins or departs the section. Thus, relocations may trigger another relocation within the section being relocated to and so on in a cascading manner.

The process for picking the node to relocate is

hash the NE
however many trailing 0s are in the hash is the age of the vaults that may be relocated (or the next youngest age if none of that age)
if there are multiple candidates for relocation, the one closest in xor distance to the NE hash is chosen

It’s described in RFC-0045 Node Ageing - Choosing a node to relocate

Also in Data Chains Deeper Dive first post

8 Likes

Thank you for the detailed explanation!

3 Likes

Thanks Neo for answering most of the points already :grinning:

I have read the primer but I want an explanation in one place.

As Neo mentioned, the “one place” that is currently the most up-to-date and contains the most information about this topic is Data Chains Deeper Dive

Currently, a message is sent from the initial section to the assigned section. This is not set in stone though (depending on profiling etc.)

The current view is:
Sections merge when

  • Number of adults drops to 0
    or
  • The sibling section wants to merge

A section splits when

  • both child halves have at least GROUP_SIZE + BUFFER_SIZE peers with age >= 4

An elder is promoted when

  • they become one of the GROUP_SIZE oldest nodes in the section (with a tie-breaker rule: see Data Chains Deeper Dive)

The constants (GROUP_SIZE, BUFFER_SIZE etc.) are far from set in stone at the moment. We think that by being efficient, PARSEC probably bought us some flexibility to increase them from the initial idea. In the end, testing will determine the right sizes.

For more details, I would recommend reading Data Chains Deeper Dive. Just keep in mind that where there is speech of “quorum agreement”, that bit is replaced with PARSEC for consensus now.

8 Likes

In addition to the excellent points already raised I’d like to add that churn is currently only initiated by changes in the vault graph, ie

  • a vault joins, or
  • a vault departs, or
  • a vault is relocated

This means a totally stable network does not experience any churn.

This will probably have to change. Imagine an extremely stable network and extremely high upload rate. Not many new vaults will be allowed (because of age restrictions) so data is distributed only to existing vaults; they’ll get larger and larger. This larger vault size makes it even harder for new vaults to join when those rare moments of churn come about.

So I think that attempting a relocation after X PUT events is a good idea since it will allow new vaults to join during high periods of uploading and contribute to keeping vault size manageable for very stable networks (which ideally the network would be very stable).

6 Likes