Sentinel for beginners

In this topic I will try to explain “Sentinel”. There is a nice document about it on the Maidsafe-Github but it get’s quite technical quite fast. At the top it’s stated that Sentinel is about “network consensus, authority and crypto usage”. David did a presentation on Sentinel which can be found here.

Let’s start at the beginning. Your client connected you on ip-level to the network using CRUST. That’s the part where you can have connections based on UDP, TCP, etc. It creates holes in your firewall/NAT when needed and makes sure you can connect on ip-level to start with. The next step for you is to join a group with a maximum size of 32 nodes. When you want to do anything at that level, you need at least 28 of them (over 85%) to reach consensus and give you permission. At the same time, you’ll control others in that group in the same way. But let’s step back a little. How do we know who is who? Not only on a local level within the 32-nodes, but outside these nodes as well? We can be all safe and well within our group, while on the other hand some very corrupt nodes try to connect to us with bad intention. This is where Sentinel comes in. While we’re in our own group, we need to connect to other groups to be part of SAFEnet. All nodes on SAFEnet will use private and public keys for communications. So if node “ABC” connects to node “XYZ” it will encrypt all data with the public key of “XYZ”. On the other hand “XYZ” will encrypt all data using the public key of “ABC”. After encryption, only the person with the private key will be able to decrypt the data. Next to this PKI (Public Key Infrastructure) we’ll use digital signatures as well. So when node “ABC” says “I’m a very happy node” and it uses a signature (like “xxGhdljsdsjKbndghwh”), all other nodes can confirm that the line of text came from node “ABC”. If one would change only one letter or space in that line of text, the signature from “ABC” would be invalid. So nodes can decrypt data that was sent to them, and sign data and messages using it’s own digital signature.

Groups will do the same as well in SAFEnet. So when you want to PUT data to the network (like uploading some pictures of your dog) you need at least 28 nodes in the group to sign your request. But now let’s go back to the question: How do we know who is who? How do we know that the group that wants to connect to our group is indeed a valid group in SAFEnet and not some Skype-nodes that got drunk? Well here’s the magic of Sentinel. We want nodes that are close to each other to form groups. So let’s think lineair for a second, and assume we have nodes with addresses like 110, 111, 112, 113 and 114. They’re quite close to each other so they should be part of the same group. If a bad node shows up in that group, and it got corrupted we might see that a node with address 998 got into the same group as well. The group shouldn’t allow it (the network prevents this) but what if the group was completely corrupt?

The solution to this problem is quite simple but very great at the same time. When our group get’s a request from another group who want’s to connect to us, we’ll just ask the network if this group is valid. We do this by sending a message to the closest nodes of the group, and ask them if they confirm that this group, containing these nodes exists. So we might find node 109 replying to us and says: “Yes, I know these nodes, they’re quite close to me”.
Now we have at least some confirmation that these nodes are recognized by SAFEnet and we can try to get more info. So Sentinel will ask the group to give us all their public keys and signatures (of all the 32 nodes), and a message signed by the whole group as well. When they do, we now have some more info about them. But Sentinel is still not satisfied and will ask for more info. So it will encrypt a message to all the nodes in that group using their public keys. As we learned in this topic, only the nodes with the private keys will be able to decrypt that message. So when they just sent some random signed info, they can never reply to us. But on the other hand, when they indeed gave their public keys and are fair nodes, they will reply. And that’s the moment Sentinel is satisfied. It learned about some new nodes who are in a group. It sended a message out of the “backdoor” to the group’s closest nodes in the network. These closest nodes replied and confirmed to us that SAFEnet has indeed a group of nodes like that. Sentinel got their public keys and tested if they indeed are the owners of the private keys as well. Now all is well and confirmed, Sentinel got some new friends. A group of up to 32 nodes it trusts. But as you might have guessed. The other group has their own Sentinel as well. And it did the same research on us. Just to make sure that our group wasn’t a bunch of drunk Skype-nodes as well :wink:


Thanks for putting this together. It is really helpful.

Very nice, thanks a lot. Question: how is the backdoor found?

Great question, I’m wondering myself :wink: I use the word “backdoor” because Sentinel asks the network if these nodes exist by asking their closest nodes. So the communication through the “frontdoor” is the communication with the new group/nodes. If Sentinel asks others if the new group (to us) exists, it will route the question using other groups (backdoor). But when our group only knows 1 group, yeah, that’s a great question :slight_smile: I don’t know how this bootstrapping works. I also don’t know how the system will start with only 4 or 8 or 12 nodes in the network. Maybe @BenMS or @dirvine can jump in if they have a bit of time.

That’s a useful introduction.

How long does Sentinel trust its friends; does it retest after a while or test on every occasion?

I think it will trust the group as long it’s connected to them. But now and than new nodes in that group will show up, so it needs to get the public keys and info (PublicFob) from these new nodes as well. Probably signed by the whole group, without asking the whole group to reply all info again. Just a little update when new nodes show up.

1 Like

You bootstrap on an IP network and then find nodes on the DHT network (routing). When the network is smaller than Quorum_size the sentinel takes a dynamic number up to quorum size.

We use loose parallelism to send checks for groups via several channels and check return messages against crypto signatures. That way we confirm

  1. This is the correct group that sent messages (by ID)
  2. Check signatures to confirm it’s not a fraud attempt

You can think of it as we check the group member names are correct then query the names cryptographically to make sure it is really them.
Then we are happy and check message validity


The Sentinel presentation is interesting and @18:30 talks of the importance of network ‘state’ but how is DHT/routing ‘state’ defined cf how close nodes are together? x=??

How many Sentinels will there be… relative to other elements of the network. Might an DDOS attack on Sentinels be a problem or does every node play host to a Sentinel?

Is making ‘at least one connection per protocol’ some liability?.. Could that be a signal that is unusual for a network that doesn’t typically use all those. I expect SAFE will necessarily want to adopt a natural form of network traffic.

What effect might flooding have where there are caches?; so, for example, flood address relocations over a ten minute period; will that just dilute address relocation’s capability and could that ever pose a problem is sustained?

DHT state is the network state required to know where chunks are (can be computations safecoin etc.). The state is decentralised i.e. no 2 nodes hold same data. This is where you see a large venn diagram where nodes share come data in common, but not all.

In our case state includes (but not limited to), client accounts (how much safecoin for storage), DataManager (where are the chunks in this group stored), PmidManager (what nodes are storing and on line status). This has added to it version managers (another NaeManager specialisation like DataManager) which links structured data (data with constant address but changing content).

Messaging and Public Names add some more, you will see us refer to this state as accounts which may be confusing, but many personas have such state, many of this is non persistent (and small) and much is persistent (like client accounts).

So state is transient info required to allow the networks intelligence to build if you like.


How does this work when I PUT data to the network? I’m connected to 31 nodes, but how do they know if I did pay any Safecoin? Or is the same group responsible for the Safecoin as well? Or do I have 1 group of 32 nodes as close nodes, another group as client-managers?

:frowning: Sorry this sprint is manic. The ClientManagers are responsible for checking you have paid X safecoin, they reduce this allowance per Put. The rest of the groups will obey the group consensus of the client Managers. so a node has no authority to Put direct it must be a group so you need to persuade a group to do the Put. You persuade them by spending a safecoin and they do the Put. They do not need to charge a whole safecoin and wont, but you see what I mean.


@Peter_Jankuliak made a great overview of one of the Sentinel structures we have; it’s a great highlight of one aspect of the interlocking security and consensus algorithm in the SAFE network.