Consensus 28/32 or 8/8?

  • steal safecoins that the section looks after
  • create safecoins for unused safecoin addresses that the section looks after and take them
  • disrupt operations
  • delete/corrupt data
  • and other similar things
4 Likes

I see, so stealing safecoins from a section is ultimately stealing from the whole network? But isnt the whole network in complete consensus anyway? So trying to steal from a section would be pointless? If that makes sense…

1 Like

No. The point of Sections is to split up the network into different parts all looking after their piece of the network.

So each section looks after a section of the XOR address space and consensus is how the section makes decisions on what should be done when requests are made for resources it controls.

4 Likes

The ‘attack’ I was thinking of is managing >= 1/3 number of elder nodes of a section, what means you could disrupt that section. Meaining that you could make that section deliver no or garbage chunks, if I understand correctly.
A more difficult attack is managing > 2/3 of elder nodes of a section (if you haven’t noticed 1/3 + 2/3 = 1…). And I’ve read here that you could control a section in that case and e.g. you could steal safecoin controlled by that section.

3 Likes

Thanks neo & draw, makes sense now. I was always under the impression the WHOLE network was one big autonomous entity. But the different sections are actually what make up this entity, ie speaking to one another. I think.

4 Likes

Could these IP addresses be obfuscated in any way? Something like onion routing? Like that the traffic between elders is passed through a bit younger node, or something like that?

I think not: you could for example get the established connections of the vault be checking the output of a commando like netstat. As a Safe Network client you don’t know exactly where your data will be stored on the network (IP addresses are scrubbed), but that’s not the case here.
Although I don’t know how difficult it is to detect the aged nodes.

Just to summarise, no node can or should be trusted in a distributed network. It is only the consensus of many nodes which can be trusted (assuming the network has not been compromised).

3 Likes

No, IP addresses are always scrubbed.

Nodes only know the xor addresses of other nodes in the network.

1 Like

It could be that I’m mistaken, but in my understanding the vaults (or what I call nodes) in 1 section communicate with each other on ip level, and there is no ‘Safe Network’ persona (client or data manager) ‘between’ them. If there are persona’s (= sections, level higher) involved I understand that you can communicate with only knowing the Xor address. So the nodes in 1 section know each other IP adresses (is that not the routing table that was discussed in the past).

I’ll leave it to somebody who knows the code, but there is a routing table for xor routing, so maybe that’s what you are referring to. It seems an unlikely choice to create a security hole by abandoning xor addresses/routing in any part of the network, so I believe you are mistaken until somebody proves different.

2 Likes

Aware this discussion is based on someone having done that, but was hoping there might be a few more barriers in the way first!
Is it not possible for others communicating with a vault to check that the code is exactly as issued? Or just not desirable? I think I’d sort of assumed this was done as part of PoR.
Intuitively to a non-technical person like me, someone being able to modify the code and still be a trusted vault sounds kind of worrying in these situations! Given there is a direct line of communication, could a bad actor with modified code even distribute malware to other vaults? I presume the nature of the files/communications/programs means this isn’t a possibility, but seems worth asking. Still trying to understand all the ins and outs of the thing, and finding info at every turn in this thread.
(Sorry if these are naive questions)

If the code was closed source, so that only executables were distributed, you would feel safer, but you would only be safer from script-kiddies. It would be possible for the executable to be studied, reverse engineered, modified by skilled programmers, and the modified version used to join the network. So your feelings of safety would be misplaced.

SAFE code is open source, so anybody can get the source code, modify it slightly, compile it, and join the network. This may seem less safe to you, but it does two things. It let’s you (and computer security experts) easily audit what the code that you are running on your computer is actually doing. It also forces the network developers to design the network assuming that many of the participants are hostile. Designing with this assumption is the much safer option.

8 Likes

I think that answers your question with agreement?

Edit: or maybe not… I suppose they could be proxy connections via a node outside the section. I seem to remember that being mentioned, but I thought that may have been related to user requests?

2 Likes

Proxy really only applies to

  1. A client
  2. A joining node

Then the network of vaults establishes. So every vault knows it’s sections/groups IP:port and its neighbors IP:port. Clients go through a proxy the whole time and their IP is scrubbed on hop 1. Vaults IP is scrubbed on hop 1 as well, but they do communicate directly with each other via IP:port (encrypted communications though).

6 Likes

Apologies @draw, it appears you are correct and that IP addresses are known within a section.

4 Likes

side node - i came back to the chained section thing … but because somehow i didn’t get the calculations right i just went with the monte-carlo-simulation (2000 sections - 8 elders per section … )

because a simulation run with a couple hundred rounds is relatively time-consuming i did only take 500 here

he re-check is just super-simple an extension of the standard-monte-carlo where the algorithm checks if the one randomly selected other section is in control too

22/32 with 100k sections will follow …probably tomorrow xD …

here we go (no time so only graph)

EDIT: i added a simulation for 3 chained groups just show that the effectivity of chaining sections decreases rapidly with the number of chained sections

3 Likes

My statement has nothing to do with lowering requirement on an established network.
And setting other rules is not the same as supporting the network.

All I am saying is that rules can be dynamic based on network phase/size. They don’t have to be same for all phases and sizes.
So it’s about not requiring same rules for widely different conditions.
In several other topics the answer to questions about robustness have been “comes with numbers”. And in that light, the challenges of the infant state of the network, a rare occasion, might be better solved by other rules.

4 Likes

Curious Whitepaper about trust mechanisms to a Kademlia P2P Network.

Basically it deals with the same problems that Safe has to solve. The biggest difference is in the structure, carried out by Safe, with the disjoin sections.

Most proposed solutions are already implemented in Safe but it is a very interesting reading.

8 Likes

I agree this increases security but I have some thoughts about barriers for implementation.

  • Ideally security should be fungible, data should be fungible. Safecoin should not have ‘special’ rules for security (in this case chained group security). I’ve assumed the chaining mechanism is only applied to safecoin. If it’s for all data this point does not apply.

  • The non-chunk / non-xor-named / non-section-prefix-matching data stored by vaults is going to become bigger. For example, datachains are not kept as chunks on the network, they are ‘magical background data’ stored by each vault. With chained group security each vault also has to track ‘magical background data’ for chained verification. How far does this go? I think vaults should be focused on their chunks, not ‘other stuff’, and the chained group idea is a step in the wrong direction from a data perspective. This affects merges and splits especially since there is special non-xor-named vault and section state that must be managed alongside xor-named chunks.

  • It makes the idea of a section slightly broken. Who is in charge of the data now? It’s two sections. That means that the number of effective sections is reduced, instead creating psuedosections of combined real+chained sections. It’s still better than blockchain but imo it breaks the benefit and conceptual perimeter of a section.

I’m generally in favour of sections being held accountable by another section to increase security, but the design is pretty important to maintain fungibility of data, sections and security. And overall performance.

We all intuitively know what accountability is, but it’s worth reading the wikipedia about it since it contains some very strong structural guides about how to achieve it. https://en.wikipedia.org/wiki/Accountability

In particular for this case “the expectation of account-giving” is important for state management beyond end-user data.

8 Likes