Update January 13, 2022

[anon23746431]

Wow, you has been worked hard. There are so many piles to think about. However, there is also some joy when crossing the hurdle. Thx @maidsafe team

[neo]

@maidsafe

It may be possible to create a dedicated expandable partition only for Safe Network data, but that could be complex to do, given the range of platforms and operating systems.

Maybe not an actual partition but as said before, just use the disk and have a maximum value the user wishes to allocate to Safe. As space reduces the user is warned (level default but changeable for “power” users) with time to react (if asleep when reached) and either leave it as is or have the option to change the max amount of space.

This is a lot easier than partitioning since its just figures (warns & max) to check against.

@maidsafe

In this scheme elders will store any data put or retrieved from the section in a LRU (least recently used) cache. The capacity of the cache will be capped, with elders dropping less recently used data as necessary.

Would this cap be the storage size when it was only an adult? In other words rather than storaging chunks when it was an Adult, it is now storing cache data in that space. And have the Elders rewards since they are still providing storage resources.

@maidsafe

When an adult restarts or relocates it sends its chunks to the three closest elders to the chunk name and they store as much as possible in their cache. The elders in turn store each chunk to four adults.

This sound elegant but is double handling the chunks. Maybe to speed things up rather than going via the elders and only using one Adult you could have a method where the adult sends the chunks directly to the other Adults. And additionally the elders rather than storing and forwarding the chunks could instruct the other Adults with the chunks to do the same.

So the Adult being promoted/restarted/relocated will only have to do a portion of its chunks and the other Adults doing their portions.

Another advantage is the uplink speed of the Adult being promoted/restarted/relocated will not be such a limiting factor on how fast an Adult can be promoted/restarted/relocated

At say 40Mbit/Sec upload link, the link nominally can sustain 3 to 5 MBytes/Sec uploads. A 2 TB storage node will take a minimum of 110 hours if flat out at 5 MB/s

Now if that same Adult also had other Adults that hold its chunks helping out then you’d be looking at lot less. If all chunks were only on 3 other Adults then 111 hours comes down to 25-30 hours. But if more adults are hold various chunks in that adult then the time will be less.

But the worse is the effect on the Elder’s upload link by storing in its cache chunks being moved about. It there is the 2TB adult with 500GB through any one elder then its like 30 hours to receive the data and 30 hours to send it (obviously overlapping)

So while this maybe a simple way of using the elder to buffer a transfer, it may prove impracticable when Node storage sizes get over 500GB

Better for the elders to table the chunks in the Adult being promoted/restarted/relocated and allocate evenly the job of moving the chunks off to the adults holding the chunks.

If I understand the storage method then an adult may have other adults (A, B, C) holding some of the chunks and say adults (B,C,D) holding some others and adults (E,F,G) holding others since the 3 closest adults to a chunk will vary depending on the XOR address of the chunk.

Knowing that then the job of moving chunks when adult is promoted/restarted/relocated is shared across many adults saving a lot of real world time. This is especially important for promotion reducing the time to promote by about 1/5 or better.

Or have I misunderstood the process suggested

[TylerAbeoJordan]

Great update team! Nice to see everyone jumping quickly back on task after the holiday.

Hope everyone had a good break.

@neo

This sound elegant but is double handling the chunks.

100%. Hopeful that there is a more elegant way of managing this. I’m sure I’m missing lots of reasons why, but – as chunks are replicated and stored in nearest xor adult, why can’t elders just tell replacement adults to pick up that range of xor addressed chunks from existing copies? I’m guessing there isn’t a public sorted list of these chunks?

[jlpell]

@yogesh

Another option is to scale Elder sizes as the number of sections grows.

Seems like it would be easier/simpler to just limit vault sizes to a fixed value so that more sections were needed. That would increase the cpu/storage ratio of the network whe keeping the n*(n-1) intrasection communication overhead small.

“How much data can X elders quickly serve?” Consider an example where all nodes are required to have a fixed size of 100GB. A value of 100GB is small enough for any modern mobile device to handle. An entire section of 100 adult nodes would only take up 10TB. It now becomes reasonable for every elder to cache ALL data in the section (a 12TB hdd is getting cheaper by the day). Over time, elders could vote to increase the fixed vault sizes and place more resource demands on adults. This would be naturally constrained if elders need to cache the whole section. So an elder will vote to increase adult sizes only when it has enough storage to cache/hold the entire section itself. Since vault sizes are fixed to a known value, it’s easy for elders to do the math.

[RedPill22]

Happy to hear the community testnet is producing promising results.

[bochaco]

@jlpell

it would be easier/simpler to just limit vault sizes to a fixed value

@jlpell

Since vault sizes are fixed to a known value, it’s easy for elders to do the math.

I like this approach too, also because this would allow us to get rid of the “joins allowed” agreement among Elders, each Elder shall have the information to allow more nodes to join without the need to sync up with others. I think we should have everything following this pattern (if possible) so Elders don’t need to sync up or run any round of agreement to make any type of decision, but instead just use their own local knowledge of the section, plus section membership will soon be maintained by a BRB consensus algorithm.

[dirvine]

@bochaco

this would allow us to get rid of the “joins allowed”

True, this is a good point.

[Bogard]

@maidsafe

DKG work @davidrusu and @danda have been pushing ahead with.

The following idea would definitely qualify as an optimization so might not be too important at present, but since DKG is being looked at, I’d like to bring it up just in case.

Currently, there are two event types that call for DGK in safe network:

1. The set/subset of elders in a section change
2. A section split (set of elders change here too)

In both situations, the section’s public key changes, which requires updating the rest of the network, i.e., AE rounds needed. For the split-driven DKG case (2), that’s unavoidable. But in the simpler change in elders’ case (1), the public key could remain static even as the new set of elders are distributed new secret key shares. This would mean that the section key only has to change in the event of splits, cutting down on AE rounds / updates to network knowledge and linked list size.

The savings could be considerable if a subset of a section’s elders ends up changing often (e.g., due to DDoS or voted out for maliciousness, etc.), not to mention potentially less wait times for clients in these non-split elder churn situation. Static public keys for “non-split-related DKG” could also help mitigate key selling attacks by adding a third (3) situation for DKG where the same elders set update their secret key after a certain number of section/network events while requiring little to no AE / linked list updates.

Looking around, Dfinity’s Non-Interactive DKG (https://eprint.iacr.org/2021/339.pdf) has such property that “preserves the public key but creates a fresh secret sharing of the secret key and hands it to a set of receivers, which may or may not overlap with the original set of share holders”.

[bochaco]

@Bogard

the public key could remain static even as the new set of elders are distributed new secret key shares

This would allow old set of Elders to agree and sign things even after a subset/all of them were demoted/relocated (i.e. removed from the current Elders set), that’s why you actually want to change the pk of the section and add it to the section chain. Unless I’m missing something from the proposal?

[Bogard]

@bochaco

This would allow old set of Elders to agree and sign things even after a subset/all of them were demoted/relocated (i.e. removed from the current Elders set)

No, as with the current design, demoted elders wouldn’t be able to participate anymore because the secret key set would be different even as the public key remains the same. Definitely check out the paper I linked to above when you have a chance.

[19eddyjohn75]

Thx for the update Maidsafe devs

@maidsafe

yogesh has managed to fix a logic problem when promoting new elders, reducing the number of AE rounds, and consequently message exchanges, from 150 to 15

Like this

Really loved reading up on data handling, would love to see more of this literature

Keep hacking super ants

[jlpell]

@yogesh

if Adults are OK with sharing their IPs

Seems like this would violate network fundamentals. No one should be ok with this. Relying on shady VPNs doesn’t seem like a good solution…

[yogesh]

@jlpell

Seems like this would violate network fundamentals

Not precisely. If you think of it, Elders(top tier nodes in the network) need to let their IPs be known for the clients and nodes to contact them. Likewise, these adults that are OK to serve GET requests from clients would be treated as intermediate nodes(in between Elders and plain Adults) and could be rewarded a bit more(than plain Adults) for the extra service they do. This is all brainstorming though, nothing set in stone

[to7m]

At this stage, the elders will check for unresponsive adults. An adult is unresponsive if it performs significantly worse than its neighbours (the exact tolerance will be worked out experimentally). Unresponsive adults will have their node age halved and may be relocated.

One issue here is that a successful network might depend on adoption by people without competitive farming ability. So, ideally, someone with an old phone and 1 GB of free space would be able to farm enough to store some of their own data.

I don’t see the point in age halving. If a node is being evil, it would be simpler to set the age to 0. If a node is just being sub-par, taking a step as drastic as age halving could be overly harsh.

[Vort]

@to7m

So, ideally, someone with an old phone and 1 GB of free space would be able to farm enough to store some of their own data.

I think it is a very important goal.
Throwing away non-ideal resources is easy.
Finding use for them is what makes network strong.
Since in some situations their contribution may be crucial.

One of examples is from Tor network.
When traffic corruption by exit node is detected, network not throws it away, but changes its role so it can be used in guard and middle positions.

[peca]

@to7m

I don’t see the point in age halving. If a node is being evil, it would be simpler to set the age to 0. If a node is just being sub-par, taking a step as drastic as age halving could be overly harsh.

Sometimes telling apart evil actor sending wrong data from network glitch or from random data corruption is impossible. Halving is averaging things.

[to7m]

Surely for some offences it would be easier to determine malice, and thus there should be different punishments?

[Southside]

What should be the algorithim for reliably determining malice? And how expensive is it going to be to distinguish between a flaky connection and evil intent?
I’m not saying its not feasible but IMHO this is a tweak that can wait until after release. By which time we will have a better idea of just how a “well-behaved” node performs under varying GET and PUT load and be in a better place to determine “evil intent” or otherwise.

But for now KISS and just halve the age on any “misbehaviour”, whatever the root cause.

[to7m]

Good point about making it a post-release tweak. I guess there’s no reason the network should be delayed by this particular issue.

[SmoothOperatorGR]

we will have extensive testnets afaik the livenetwork will be a testnet that is considered full featured and run for a while great

so it could happen that we need the malice code in before declaring that we are live