SAFE Datachain (work in progress)

Features
63

Looks like some new text:

A vault will allow majority - 1 nodes to join via the mechanism above.

On receiving a join request for a node (from routing), vaults will request the nodes DataChain

If this nodes DataChain is longer than an existing majority - 1 nodes, then nodes query the joining node for data from the chain and then it is allowed to join.

All nodes that can hold a lot of data will try and build their data chain from existing nodes holding such data (Archive Nodes). This data is transferred with the lowest priority.

On a churn even a node that is off line for a period may find on restart an existing node did build a chain and now this restarting node has to join another group to begin the process again of building a data chain.

Nodes will choose the sender of the data on Get requests. New nodes will only be expected to have data that has appeared since they joined (each node knows this via it’s own data chain"). New nodes can and will try (if they have resources) toGetdata from the group. When nodes have this data they can request full membership of the group. At that time they can be chosen to respond to anyGetrequest, thereby earning safecoin or rewards. Nodes may then continue to ask for data from archive nodes that are outwith the current group data. This may allow them to restart as an archive node, maximising their reward time as restarts are much faster since data does not need relocated.

On start a new node will ask 1 member for the group for the chain and all members for the genesis block only. This allows that node to verify the chain is current and is traverses back to genesis Ok. If there is doubt over chain validity, other nodes may be asked for the BlockIdentifiers only , should any block be missing then the node that sent this (signed) will be reported to the group and this action will mean that node is expelled, immediately.

A node on startup may request the genesis block from any group and store this locally.

Ahh, RFC now in the Maidsafe repo. Probably a new topic about this one soon in the RFCs :thumbsup:

3 Likes
64

Nodes that hold the longest DataChains may be considered to be archive nodes. Such nodes will be responsible for maintaining all network data for specific areas of the network address range. There will be less than group_size/2 archive nodes per group. These more reliable nodes and will have a vote weight higher than a less capable node within a group. There will still require to be a majority of group members who agree on votes though, regardless of these high weighted nodes. This is to prevent attacks where nodes lasting for long periods in a group cannot collude via some out of band method such as publishing ID’s on a website and soliciting other nodes in the group to collude and attack that group.

Isn’t this another drawback even though it’s not listed as one? The fact that these nodes are persistent in a way. Or is this covered by this:

There will be less than group_size/2 archive nodes per group.

Looks like a malicious group could still try to attack a group using the following strategic:

  • Create a lot of Archive Nodes and offer a lot of space.
  • Pick address range and try to become part of 20 different groups.
  • Start a lot of low_bandwidth nodes (artificially by throttling bandwidth per node) and start thousands of them.
  • Keep connecting over and over again to get in the same group as the Archive Nodes.

This way a combination of nodes and archive nodes might work together in some sort of botnet fashion to target a group. Will be quite hard but could it be done?

65

Current consideration is archive nodes have no consensus vote or very little, but still can earn a lot of safecoin. They should in no way ever form majorities though, regardless.

3 Likes
66

@dirvine Makes sense, you don’t want “elite groups” making important consensus decisions. At least that’s what I get out of it :stuck_out_tongue:

2 Likes