Now that vaults are not persistent anymore, does that mean that your vault rank is reset whenever you turn off your system?
I can see the benefits of non-persistent vaults, but what is the view on reliability of the average vault? I imagine that rank is easier/faster to gain now, since there will be more churn so data travels around more? So if rank is easier/faster to get, doesn’t that mean it’s also less big of a deal to turn off your vault if you make a loss for a short time (in relation to power costs), or if there is negative news about SAFE? With persistent vaults I think turning off would be a rather big decision, since it would take a long time to recover rank.
Yikes! For me, this datum just falls out of the sky. Can someone please direct me to the context that this fits in? I’m missing the background of the parameters of a “persistent vault” and then, of course, the switch to them no longer being persistent.
Same here, that’s why I made this thread. The main difference is that you can’t reconnect and then farm with your old data anymore, you’ll have to start over every time you disconnected from the network. But what other implications this has, I can only guess.
Hmm. I can see that that makes for a much more dynamic network, but it also makes for a huge amount more data transfer. If I have 500 gb on my vault and turn off my machine, or the power goes out, etc., that half tb goes in the trash and I have to start filling it up again? That seems like a lot of bandwidth. It seems that it would encourage pretty small vault allocation for most people. I guess it would encourage large UPS as well, but you sometimes lose your internet connection with a power outage, even if your router is connected to the UPS.
@BenMS, is there a discussion thread or analysis to see on this. I couldn’t find it on the forum. We seek to understand . . . even if it is ultimately beyond us.
This is a security and simplicity proposition. There will be persistent data via archive nodes in due course. I continually strive to ensure we reduce account info and ensure all people get a chance to farm on even the smallest devices. This also means you do not have a persistent vault ID and it’s re calculated at every reboot. It has very interesting implications and will move data much faster across the network. To be persistent we had to store the vault private key locally (there are some options). This way there is nothing/nada to steal from your computer that is going to help any attacker. So it is pretty nice in many ways.
In essence it allows much smaller fast/off/on nodes to take part in the network easily. As a vault stays on longer it holds data for a while and grows rank (automatically) per session. It makes rank calculation very simple and also makes ‘gaming’ the system significantly harder (it was already very hard).
Archive nodes though will be required anyway to take care of very large aggregate chunks and these will look very similar to the older vaults, but much harder to become one.
I will do a write up about this and another few small changes that have some staggering implications for security very soon. As soon as we get testnet3 up and feature complete.
My only concern pops up with the idea that that is going to result in a lot more data moving around between vaults constantly, but I’m sure you’ve thought of that. It does make for a much more dynamic, untrackable picture.
Same for me, it will limit the amount of data I can dedicate to the network much more this way. On the other hand, it level the playing field even more between farmers. Not sure what to think of it. We’ll see when the details comes out.
I’m in favor of this and believe it will enable a faster Network. Here’s why…
Persistent Vaults
I wrote about a “10 minute back off period” in this thread Farming Question and realized it was more like a river with boulders thrown into it, disrupting the natural flow 10 minutes at a time. Every time a vault goes offline, the Network waits 10 minutes to relocate those chunks. Now stack the wait time with hundreds of vaults… increase it to thousands… get the picture?
Non-persistent Vaults
With @dirvine’s proposition, data chunks flow instantly to the next available vault and does not impede the flow as much. Add archive nodes (landfill vaults) that naturally filter inactive chunks (dirty water), and you get a river that is self-cleaning.
The end result, in addition to increase security and efficiency, is NEW farmers can jump right in and participate more quickly, while landfill farmers (older vaults), automatically collect inactive chunks and are compensated.
I don’t know if this is exactly how MaidSafe plans to implement it but I do support the logic behind it.
Points like this seem particularly problematic for me as I would have a download limit. 200 gb /month serves me well for my present consumption but if I’m farming and have to redownload every time I restart (which is fairly often on a dual boot machine). Then this could be a severe problem.
Well really, you should most likely invest 150 bucks into one of those credit card computers (banana pi, odroid, etc) and a hard drive if you want to get into farming proper.
I think the problem may be one of economics, rather than technology. If other cloud storage providers are storing bulk data to cheap disks, safe net storing to ram - in several locations - May be prohibitively expensive.
Maybe archive nodes will seamlessly transition data to disk at an economically appropriate time though? I think we need to make sure that is the case.
The short boot time before being able to contribute would be a great thing. Very handy for those who are unable to leave machines on for long periods.
Perhaps it should be up to the user? If they intend to be online for long periods, it makes sense to use persistent storage. For those who just want it to run in the background from time to time, non-persistent would be the better choice.
If the user incentive matches what is optimal for the network, it will be ideal.
Agreed,
Letting the farmer choose how they can best help the Network sounds more efficient. But maybe it’s easier to let the Network decide based on vault rank (i.e. behavior and performance). This way, the farmer doesn’t have to worry about it.
For example…
Rank ( 0 ~> 0.7 ) is classified as non-persistent.
Rank ( 0.8 ~> 1 ) is classified as persistent.
Persistent vaults are given persistent ID and a reboot grace period.
This could save the Network a lot of work by waiting a little bit before relocating a mountain of archive chunks when not necessary.
I’m sure we are getting ahead of ourselves and @dirvine will explain his proposition soon.
Sounds good! We just have to be aware the the user could override defaults if inclined. As long as both user and network benefit with the same setup, there should be little reason for the user to override anything though.
I meant if it was purely a client (read: vault)side setting. If the client defines its mode, then we have to be aware that the code could be changed to ignore network recommendations etc.
@dirvine, I see a major problem with non-persistent vaults. The idea of the SAFE Network is not only privacy and security, but also data security. What you are essentially setting up with non-persistent vaults is a large networked RAM storage, am I right? The only problem with ram is that if the power goes out, then you lose the data. Your argument is probably that if a machine goes off, then one of the other 4 machines on the network that are storing the chunks will copy the data. This sounds good, but then to attack the safe network, all you have to do is cause a great many machines to reboot/shutdown at the same time, or just close the SAFE program. This means that the network is not secured against a massive power outage, if the entire network (or most of it) was shut down, then all of the data would be lost. This seems less robust than with persistent vaults, where if the entire network turned off, then when it rebooted, the network would be fine. A network shutdown could be caused by anything such as a country wide power outage, windows automatic updates, a large-scale virus, or even something human related such as Earth day!
That’s one problem on a large scale, but what about something a little more commonplace, if a lot of people turned off their computers for Earth day, then that day, the total storage space the SAFE Network has available shrinks by maybe 20%. But what if the network is almost filled to capacity? Where does the data go? I think you absolutely need persistent vaults, not just non-persistent vaults. If I’m storing data, and something like this happens, I don’t want /any/ of my data to be lost. And if some data is not stored persistently, then there is a much greater chance that my data would be lost by bad luck or circumstance. I propose that you have both persistent and non-persistent vaults storing data. So if my data is stored 4 times, there is at least one copy stored on a persistent vault.
I don’t think that the non-persistent vault scheme equates to RAM storage.
If you want to make sure to have a seasoned vault which is effectively a persistent one, you just need to make sure that you have an always-on, UPS backed device that never goes off. There should be a marginal increase in ranking for such, but not so much that it edges out farming by others.
