Watchers instead of Consensus

Features
1

I wrote about Watchers before, but I wanted to write about it in more detail as an alternative to Consensus.

For the past several weeks, I have really been thinking about the concepts of the SAFE network (which I consider to have just the right architecture, and can’t wait to see it gradually bring about a revolution on the internet in several areas at once). I was interested in figuring out how the concepts work together across existing technologies and SAFE, and how things can seamlessly work between the current Web, domains, Kademlia, close consensus and so on.

So here is the thing about consensus: it can be either done by voting (ie whatever the majority believes is the truth, even “fake news”) or proof (like is done in science and math).

The second one is what I call Watchers. Basically it is a different consensus algorithm than “majority wins”. Each close consensus participant is watching the others like a hawk.

In this conception, every file has a history (it is essentially a cryptographically signed chain of hashes).

Every time some request to take an action on the “head” of the chain comes in, it is sent to all the close participants by the network. Each participant independently validates this request, and makes a decision whether it is valid.

If a participant can prove that another participant honored an invalid request (eg it had an unauthorized signature, or it was not on the head of the chain) it packages the Claim of Violation, stores it and gossips to all the other participants (and possibly elsewhere on the network).

In this conception, the core enforcement of rules comes from the clients and/or routers! It is presumably in the interest of at least the subsequent recipients of the file/safecoin to make sure it is valid. Because if they don’t care or are dishonest, then at some point an honest, self-interested client will reject the safecoin/file and won’t honor the payment in the real world. So by ignoring the Claims of Violation they are only hurting themselves.

The clients can check the claim, since they have the whole history of the file, etc. Some claims are easy to check, eg that a validator signed off on the head of a file history, but then backtracked and forked the history, signing off on another head, too. Other claims require the client checking the entire history of the file.

Claims of Violation can be like a bet. Essentially a close consensus participant is claiming “irreconcilable differences” and desires a “divorce” from the other participant. Then the rest of the participants can decide which “spouse” they will continue to be friends with.

Ultimately however the decision is made by the end-users or routers. More generally, even without Kademlia, they would insist that new publishers appear to join the one they consider “honest”. There is no concept of who is “really right”, but rather honoring what the end-users want and are willing to pay safecoins for.

This means that you can’t penalize the “violator” participant(s) by taking away some bounty. However, they will immediately henceforth be ignored by all honest participants in the network, including end-users, and therefore not earn any MORE safecoins and essentially have to start over from the beginning with a young vault age.

This system works best if queries about “what is the head of the file history” and so on are done completely anonymously, eg through proxies a la Tor, so that participants can’t keep up a sharade by perfectly giving different answers to different requesters. They will therefore be caught much sooner in a lie by honest participants.

I arrived at this by thinking about safecoins and currency. After A paid token T to B, who is the most invested in making sure that everyone knows that T belongs to B? B is! So B periodically does those anonymous checks (“who owns T?” ie “what is the latest state of the file?”) and is ready to complain if the answer is anything but the correct one. But B can also have agents do it, the agents are essentially the other members of the close consensus which watch one another, and know whenever such a query comes in since all queries about T are routed to them.

This is already done in SAFE network via proof of storage. If a vault isn’t storing the latest version of the file, that’s a violation. I am saying that it should instantly be kicked out of the section by any honest vault in that section, but ultimately it is the end-users who are most motivated to figure out the truth and ENFORCE it by asking for another section to be formed, along with the vaults they consider honest, but without the ones they consider dishonest.

If various sets of end-users disagree for some reason on what history is valid, this essentially is equivalent of forking a section. Each set of end-users ends up with a section of vaults that agree with their reasoning.

So I have generalized the situation and that’s what it looks like, Kademlia or not.

1 Like
2

I want to introduce one other innovation that’s pretty easy to implement:

  1. Authorized user submits request to undertake an action on the head of a history of some file

  2. Request is routed (eg by Kademlia) to a group of validators (eg close consensus)

  3. After they group-sign the new resulting state, it must be ENDORSED by the original actor(s) by signing again. And only then submitted to the record.

Why? Because then, if there is a netsplit between the validators and they cannot reach a consensus within some timeframe, the user can simply issue the SAME request but with a difference nonce, resulting in a completely different hash so it will be handled by a DIFFERENT set of validators (I am assuming here that the Kademlia is based on the hash of the transaction).

Now whichever set of validators returns the group-signed consensus first, the user endorses that one, and if the other one finishes afterward, the user will simply ignore it and not endorse it.

This way A can pay B for instance even if the network has netsplit, by issuing requests every few seconds until finally some close consensus set happens to have 2/3 of the participants in the same network partition as A!

3

Hmhmm - sorry for the brief response (slightly running right now) - just to understand it right… Are you suggesting to turn every file/Safecoin into a blockchain (but in contrary to blockchain only the close group checks it) ? :thinking:

Okay now you’re confusing me completely… If (!) the network would split one part would need to die imo - or they could exist independently from each other… But on first glance this doesn’t look to me like a desirable ‘solution’…? Could you elaborate why this would be wanted…? (I might miss the obvious now - the theory is that an attacker would stop after a while if the network doesn’t split anyway…? )

2 Likes
4

Also sorry for the brief response, but your view of how the safe network works is in error and assumes that is dong things other than what it does. So when you claim something is better than the SAFE network you are in fact only claiming itis better than the model of a network that you created to compare watchers to.

The nodes are the routers and are watching what the other nodes are doing like hawks. They all message each other about bad behaving nodes and watching.

Clients cannot in any way be used as watchers because they do not participate in the network operations in any way and are always to be treated as bad actors and never trusted. The nodes are also watching the clients and not allowing them to do anything that would harm the network or the data.

Also we come back to the basic underlying and overriding concept that if you can subvert the operation of even one section then what the watchers say or do cannot solve ANYTHING and the network will be subverted.

BTW in essence SAFE network does have watchers, just not called watchers and not requiring toothless 3rd party computers. The section certainly has all its nodes watching each other and routes out bad nodes and decision makers. Each section will not act on bad requests from any other section and in effect each section is watching its neighbours.

6 Likes
5

Yes, I thought that every file/safecoin is already a blockchain in some sense. And the vaults in a section are essentially watching each other like hawks and periodically requesting “proof of storage” to make sure the file is stored correctly. All I’m talking about is a file having a history, a safecoin having a history, etc. where you store the “latest version”, or the “head” of the file/safecoin. And “proof of storage” is always checking that you have the head.

If this request to prove storage is issued anonymously (e.g. through onion routing) then no vault will be able to keep up a charade for long, and therefore will be found out to be a cheater. However the question is who gets to decide who’s right and who’s wrong?

My point was that, ultimately, this is a question of routing. If you think X is wrong about Y, you stop routing requests to X about Y. But who is the “you” in this scenario? In the case of safecoin, the best “you” is the recipients of the safecoin. You don’t strictly need Kademlia here, I mean the recipient simply wouldn’t want to deal with X anymore and will demand that some group without X continue to store the fact that they own the safecoin.

Claims of Violation will be presumably rare (because if the network is honest, it’s one strike and you’re off the team, having to start over as a young vault in a new section). So you can store the whole context along with the Claim of Violation.

I didn’t claim this was better than the SAFE network. I simply generalized this to a certain application: files with histories, or currencies circulating (changing owners). I am talking about the general principles. You can think of a Venn diagram where one circle says “Kademlia+Churn / Consensus” and another circle says “Watchers / Migration”. I am saying the combination of those two would be stronger than just one.

Yes, exactly. I adjusted my idea of “watchers” to include the vaults in the actual section itself, not any third party computers. What I described is already happening, with periodic “proof of storage”. If you just make it anonymous through a proxy, and gossip Claims of Violation to kick out bad nodes after one violation, then that’s what I am talking about.

Basically it’s as you said above, each file/safecoin has its own “blockchain” i.e. history. Now it comes time for A to pay B. It makes transaction T1, but the consensus takes too long (e.g. because of netsplit). So A makes transaction T2 which says same thing, but is sent to a different section because its nonce (and therefore hash) is different. One of those comes back first, A endorses it and ignores all the subsequent results if/when they ever come back.

This way A can pay B even if a section can’t reach a consensus (because e.g. more than 1/3 of the section are malicious, or netsplit).

6

They are not in any sense. They are like files in a NAS. Simply stored with an index to find them

SAFE already does this. There is no need for new system to implement this for files or safecoin. And the section Nodes already kick out bad nodes that try to do wrong things.

The SAFE network vaults are the NODES and are watching each other. Its just that they are not referred to as watchers since watching is a SMALL part of the overall operation

So lets throw away one of the biggest advantages to implement a new layer that is already being done so you can comvert each safecoin into its own blockchain.

No lets keep to the current system and have “watching” built in and anonymity and speed and not take another 2 years of design, programming, testing cycles just to basically wreck a brilliant system that provides the security, anonymity, and checks needed. (Sorry if I sound harsh against you, its not intended just discussing the idea in a harsh way)

If that were to happen then the coin is simply sent again. If bad acting in the network were able to cause this to fail every time then your described system would also be hacked because it works on the nodes in the network and if you can take over the section to act badly then you cannot trust the watching of other sections being compromised. Basically if the basic operation of SAFE can be compromised then your system can be too. The only way to overcome that is not to have a autonomous network but many networks each watching the one under it till you get to some authority

Again you need to understand the SAFE operations before trying to claim it is deficient in its consensus. Your low level description of how SAFE works is quite wrong.

1 Like
7

How does a section kick out vaults which are behaving “badly”?

8

Simple, just ignore them and tell all the neighboring sections about it.

9

But who makes the decision to ignore them and how do they know that they are behaving badly?

10

The watching nodes. They know because they are watching each others actions. This is why having special watchers/personas is a waste and doubling up on what is already being done. The watching function is not referred to as “watching”/“watchers” and why your concept of the safe network is flawed

11

Forget my concept and tell me how do the nodes know who is right, the one who complains or the one who is being complained about?

12

This is the essence of the way safe works and is not easy to explain quickly. Search on “user:dirvine consensus” and that should give some good results.

My explanation is simple and may not be stated right so please excuse any apparent/real mistakes. Basically the consensus not only is voting but is also judging the responses by all nodes. As nodes age they get more and more trusted and relied upon. So assuming the section has not been compromised there will be a majority of good elder nodes. Thus any node disagreeing is noted and if they behave badly too many times the node is demoted and eventually rejected. Remember all communications are via protocols and so no need to examine a node to see if its faulty, just look to see if it follows the protocols correctly.

Obvious if the section is compromised then all bets off including any additional watching installed on the vaults (Nodes)

13

This is planned,but as an optional thing for the user to keep a “receipt” of a transaction and not for being used in consensus. I don’t think the specification for exactly how this will work is done yet though.

1 Like
14

It depends on who is right about what. But in general, who is right = who provides a valid signature.

Client actions: it depends if the action is signed correctly by the client, the client is punished by being rate limited or disconnected (presumably they try to join again at another part of the network).

Messaging between sections: messages are signed by the section so can be verified, and are sent via a secure messaging protocol (see RFC-0037 Disjoint Groups: Message Routing)

History of network structure (ie members of sections): datachains can provide verification that the group being joined is valid (see RFC-0029 Data Chains)

There are lots of ways that verification happens in the network, I don’t think the current design is lacking in that respect since mostly it’s based on signatures which are proofs not beliefs.

6 Likes
15

In the Node Ageing RFC you have more information on how to measure a node.

Measuring a node

As a node forwards messages to other groups that group can confirm a message was sent or not. As data is relayed via group messages (such as Put) then the group selects the node to forward the message based on it’s closeness to the name of the data. This process distributes the workload of forwarding messages throughout the group. A nice feature is the receiving group can be trusted and if they receive the message from every member of this group which node is sending the data they can also confirm the data never arrived. Thereby they will send back a resend request to the group with the name of the node that did not send the data in time. This node can then be disconnected or have it’s age reduced (initially disconnecting will probably work best).

If a node does not send NodeBlocks then it potentially damages the group integrity. Any node that has not sent a link NodeBlock since the last churn event should be disconnected, if and only if, there are data Nodeblocks transmitted between churn events (to prevent relocate when churn is high).

If a node misses X NodeBlocks sequentially then it should be disconnected. Initially this may be set at G/2.

This process is a small part of a nodes work on the network, a very nice measure would be delivery of data to the client. This is more complex as we do not trust client nodes. This is an area of further investigation though (see below).

5 Likes
16

By the way I just saw this and realized that other outsiders of the project like Vitalik Buterin have had similar concerns about “what if a consensus group fails”.

1 Like
17

And so should any thinking person have these concerns. If one doesn’t then they are taking the network on pure trust. Trust is fine if its been proven trustworthy but we are not there yet. So then the other option is to learn about it and learn of the mechanisms used for the security and integrity of the consensus mechanism. This is where some of the work is being done at the moment and maybe Thursday update will shed more light on how close to completion it is. And of course be careful how you read other project considerations of SAFE’s consensus since some may feel threatened by SAFE and wish to downplay SAFE.

2 Likes
18

Yep def be careful about what anyone says about other projects, investigate for yourself. About being threatened by SAFE and wishing to downplay SAFE — I can tell you that I had the opposite reaction when I learned that SAFE was an open source project with Kademlia, Churn, full Self Encryption and Proof of Resource. My reaction was “tech envy”, that what we built should be scrapped and built on top of SAFE.

But then I realized that SAFE is not launching any time soon and we need to ship. So we may have to reimplement some ideas of SAFE just so we can launch. At the very least in the meantime we can build an OSI Layer 7 software platform that is compatible with the Web and later with SAFE when it launches, so SAFE becomes only one of the domains. A very benign “landlord” but still just one of several possible ones (IPFS etc.)

So we can build the Watchers and the Permissionless Timestamping so everyone keeps the “source of truth” on their own choice of devices and backups on domains, and SAFE can be used as a really durable domain.

Because we care almost totally about the mutable data aspect of appending to files, essentially implementing DAGs canonically, with deterministic Javascript (google it) rules for whether an action is valid or not. And this is out of the scope of your beta let alone your alpha (though I heard SAFE plans to have a Domain specific language for access rules I have yet to see even a spec for it). So we need to at least build the complementary technology. But if SAFE doesn’t launch by some time in 2019 then we may have to reimplement or fork some of it to at least have something working for Intercoin.

1 Like