More info on Proof of Resource and Security?


Enjoyed the PoR video, but just wondering if anyone can point me in the direction of any more detailed (but preferably reasonably accessible!) info on how it works.

As a related point, what level of security does PoR provide? Is it testing something absolute, or does it always depend on consensus?

At the risk of deviating too far for one thread, how do PoR, consensus by PARSEC and any other security mechanisms such as sharding combine to protect against attack?

To explain at least partly why I ask these questions, I’ve been following a couple of recent threads mostly focusing on the maths behind an attack on consensus, and although in isolation this maths maybe looks a little gloomy, it seems clear that other mechanisms are providing the primary protection from a purposeful attack such as stealing/printing Safecoin, or stealing data.

I may be on completely the wrong track but the attack that haunts me is a long term Sybil one by a large company, government or terrorist organisation that is willing to pay the price purely in order to destroy the network, by controlling a large number of vaults and then at a given moment simultaneously starting to lose data, or return scrambled data (on their own terms of consensus, in the random sections they happen to control at that moment.) Given what we are all hoping is at stake, the loss of even one piece of data in this way could surely be fatal for the network.


Basically you are asking how the core of the network works. There is a number of subsystems that dovetail together to provide these

Can I suggest you have a read up of the primer that a couple of forum members created and after digesting the primer then you might know the questions you need answering. From your questions it seems you are at a point of not knowing what you don’t know and the primer will help a lot.


Thanks. Yes, I suppose that is what I’m asking, and I suppose I am at a point of not knowing what I don’t know, I’m just trying to go beyond that point!
I thought I’d read the primer and understood it as far as it goes (and from what I understand the pertinent parts are a little out of date,) but I’ll try again and follow some of the links in it for more details.


For the best place to get an overview of the SAFE Network’s features, I would agree the primer is a goldmine.
We’re also building the SAFE devhub at Some of the information isn’t present there yet, but as it grows, it should be able to give you more and more of these kinds of answers. If you use it and find that information is lacking on certain points in particular, please let us know and we will try to improve it to the benefit of everyone :smiley:

Now, for your specific questions, I wouldn’t really say that Proof of Resources is a security feature on its own. I would rather describe it as one element of the system that makes the system overall more secure. The idea is that it restricts the power of a node that hasn’t acted reliably for a long time, so makes attacks more expensive, increasing security in that way.

To describe the relation between PoR, sharding and PARSEC, we need to describe at a high level how the network is structured.

The network is split into “sections” (groups of nodes) where each section has ownership of a part of the network. For instance, a specific section could be responsible for a certain piece of data. This action of splitting the network in sections is what we call sharding.
In these sections, a group of nodes is responsible for taking the decisions. These are called the elders. A node becomes an elder by aging, which happens when proving long term reliability. Proof of resources is also used when a node joins a section: they perform a ritual called the “resource proof” that allows them to demonstrate that they are worthy of joining the section. With random relocation, nodes are sometimes asked to migrate to a different section of the network. This is used partly to keep the network balanced (i.e: more healthy) and also to force nodes to go through that resource proof ritual more often to enforce they are and remain worthy of belonging in the network.
PARSEC is used amongst elders of a section to reach decisions that affect the entire group (for instance should we accept this new joiner in our midst?). The elders then communicate their decisions to the non-elders in this section and the non-elders can trust that decision because there is proof that it came from agreement by a quorum of nodes.

This may be a little dense. I hope it gives an overview of how things interplay, though :smiley:


Thanks very much for taking the time. I think it’s all starting to fit together a bit better now! One of the things I like about the project is that at a very basic level it’s kind of simple conceptually, but then it seems there’s the next level which is reasonably complicated putting it all together with specific details, and then of course there’s the level after that that you guys are working on! I’m keen to somehow work on the project so it seems that understanding the concepts fully at the middle level would be really useful for getting to grips with exactly what potentials and restrictions the network has. Like a few people on here I’m considering learning some of the code side of things eventually, and just trying to feel around and find out whether it’s low level fundamentals or high level fun stuff that would be the most interesting avenue for me. I think right now a lot of people in the world are wishing we understood a little better all the stuff that our lives are (or will be) based on!


I like the ritual illustration.

But there is also a need for a continuous proof of storage, something that checks that a node really stores the chunks it is supposed to store.


Yes, when data is requested a node must supply it. The group can be notified this did not happen. However, as a node relocates it will have to “get” all the data, sign it (data chain signature) and supply those signatures to the rest of the group. Then the group knows the node has stored all data, or at least processed it. This mix is as good as we can get AFAIK, then penalties for not providing the data will penalise the node who did not provide it, for any reason.


I thought this was in the system, but could not quickly find reference to it. Are you able to provide a direct link to info/doco and/or code base for this?


There is a crate that implements it (resource_proof) and that is used in routing peer manager


Ahhh it is still missing the bit I was hoping was there

Disk space measurements may also be added in future.