Ensuring data integrity on Safe

But how do you know then that the farmer isn’t just requesting the data from the network instead of holding it themselves?

1 Like

How easy will that be? And does it matter if only a small percentage of people do it? With billions of nodes, the pay will be negligible, is it worth bothering to lie at all?

Never thought of that. Wouldn’t the data map tell you where chunks are located and then polling those vaults for it then they must have it and if they don’t or don’t deliver in decent time frame then they get demoted? Could the network not know which section and vault the data originated from? If that vault is asking for that exact same data and then punishing for that behavior?

Someone would have to have the data or the gig is up for all not holding but I your suggestion is interesting to think about, a vault gets a PoR poll and they just GET that data and deliver it as if it were their own. I don’t have the slightest clue how you practically would do that but I’m guessing there is a practical way of avoiding it as well.

If they do the GET then they fail the request. The nodes have to send their hash of the content so that the elders can determine which node to supply it. The one that is trying to request the data to fake it would not be able to succeed doing that.


So each vault/node hash’s the chunk they are initially given? Is that done with a node ID? Where can I read up more on this? If it’s in the primer I must’ve overlooked it.

Not sure but I do know the nodes have to respond with the flag to say they have it and ready to send it and the elders have to know its valid data. Then they choose which node sends it. I think at this stage its just whichever is first to respond.


Okay. That’s the lottery aspect to winning a farming reward, aye?
I’m sure we’ll be hearing more about all of this sooner or later with upcoming test nets!


He would need to know where it is stored or ask the Elders who are questioning him. So kinda admits right there he has not got it.


Yes, the penalties part is not in code yet, or the checking chunks. It’s relatively straight forward though. Elders will randomly create a nonce, send to chunk holders to prepend that to the data, rehash it and send back the result. Any outliers will be picked up and penalised in that way. As a final check the elders can just request the chunk where there are discrepancies and see for themselves who is cheating. So no state or lists are required to be kept.


I love the way this is solved by the inherent distributed nature of close group consensus. The fact that elders are aware of what is going on in their neck of the woods, make it extremely tricky to fool them.

You know what? Some folks have thought very carefully about this stuff! Loving it! :sunglasses:


Thank you for clarification on this. Based solely on what we found on the forum there was some confusion. It seemed that there would be no ongoing audit of chunks via nonce/hash and that penalties would only occur when a client made a GET and the vault failed to deliver. Three cheers for Close Group Consensus!:cowboy_hat_face:

Am I correct in presuming that the elders record a list of all chunks hashes/addresses that have been saved to their section(s)? Is that a datachain?


Yes :+1:

Not at this time, we went a bit further and instead of holding the data chain, we hold only the section chain (section keys). The data itself holds the section signature that the data is valid (NetworkAuthority). So the data chain si much simpler as it’s validity/Authority is held in the section chain data and the signature (network granted store) is held in the data.


Could have a different client make the request as a proxy, no?

Yes, he could as long as it was fast enough, but he is gonna chew up his own bandwidth to do that. If he can do it and get away with it then we don’t really lose anything. He does though. HE also has to believe the one he gets is right, one more bad dude and then it’s a bit of a spiral, he could give the wrong data and so on, so it’s a good thing to screw about with these notions.


Presumably, the elders would still know that a second request has come in before the first was answered by the rogue node? That could be a sign of abuse.

Also, this would ensure that the rogue node was slower than the others, as they will have already served what the rogue wants. I doubt they would get rewarded for this performance, right?

If they don’t get rewarded, there is little incentive to bother to do it either.


It isn’t clear if passing the challenge gets you a reward, or just lets you keep participating. I’d see the incentive as trying to prune data that isn’t generating much GET rewards.

Edit: maybe these posts can move to the data integrity thread?


I think that answer is here


What I am saying is that when asked he has to go get the data from somewhere. Another Adult is not necessarily gonna give it to him (other than via the Elders) so he would be caught there. If he puts the data somewhere else, like a 2ndry disk/tertiary storage and he can get it in time, then we don’t really care.

What this means is we should prevent Adults giving chunks to other Adults without going via the Elders? @yogesh and @lionel.faber can dig into this. It is likely that unless a check is in motion that Adults can share data like this, but there could be edge cases/consistency issues doing that. Let’s see though.

There is a notion that Adults should not even know each other, this is another good case for that being the design.


I missed this I think.

Yes this is possible. The client would get the 2 copies and send one to the node and then it replies with this, but can it do that in time? That was the first part of the comment above.

1 Like

I should add, do we care, if we check X chunks per minute or whatever it is, this is gonna be a busy client/node combination. To obfuscate that he can start loads of clients but might make the situation worse. Instead of the check the nodes will be sending the correct data to the Elders, they will see this slow dude and right there he is in a trouble spot, he might get away with it, but if we catch him, he’s toast.

I think there will be a few cat and mouse games like this, but it’s a lot of work for a small amount of disk space. We could get a more intelligent hacker who says, hey you know what if we cache all that data it saves us doing this song and dance routine :wink: In any case we do need to test this, so perhaps we will try and create this exact scenario to see what it means in terms of who’s got the greatest cost, the network or that attacker.

Good probing @Antifragile :+1: