reserve size doubling tasks

[istae]

Swip-21 can actually be tackled by a relatively small number of changes.

• [x] 1) user provides a whole-number radius delta, d through config options (default being 0)
• [x] 2) reserve capacity is now a dynamic value and each increase in d doubles the reserve capacity, eg 2^(22+d). When the new capacity is calculated initially, the reserve worker will automatically reduce the current storage radius until the reserve is full.
• [x] 3) in the ReserveSampler iterator, the chunks that are considered need to be filtered by checking that their proximity relative to the anchor is greater than equal to the current storage radius + d.
• [x] 4) salud package should no longer punish peers for having "wrong radiuses" relative to the network.
• [x] 5) consider what do to with the db cmds that rely on the reserve size.
• [x] 6) reserve should return the stat (neighborhood adress and size) of each neighborhood.
• [x] 7) new API for the stats above
• [x] 8) ABI changes. If node has been staked before and if there is a delta change then new bzz has to be staked. The node should err out if there is not enough bzz.
• [x] 9) commited depth changes in the redis contract and the agent

[zelig]

3. in the ReserveSampler iterator, the chunks that are considered need to be filtered by checking that their proximity relative to the anchor is greater than equal to the current storage radius + d.

should be - _h_ where h stands for height, ie. the number of doublings

[zelig]

In the light of being cautions about supporting anything more than double (due to problems of resource overload in case of height difference in a neighbourhood as well as sampling issues due to lack of proper indexing beyond height 1). So I recommend

1. the contract API as well as beewconfig to allow only the operation of 'increase height by one' as a permanent feature and
2. restrict height to 1 as a temporary feature in bee only.
3. full support for any height in both bee and the contract in the operational logic to keep implementation simple and lasting

[ldeffenb]

1. the contract API as well as beewconfig to allow only the operation of 'increase height by one' as a permanent feature and

Will a node be allowed to DECREASE the height? Like go from doubled back down to a single neighborhood?

[zelig]

1. the contract API as well as beewconfig to allow only the operation of 'increase height by one' as a permanent feature and

Will a node be allowed to DECREASE the height? Like go from doubled back down to a single neighborhood?

YES

[martinconic]

1. the contract API as well as beewconfig to allow only the operation of 'increase height by one' as a permanent feature and

Will a node be allowed to DECREASE the height? Like go from doubled back down to a single neighborhood?

YES

The height decrease should also be allowed only -1 at a time?

[nikipapadatou]

Apart from the points that @zelig raised, I would add that we also need a command that will provide this information to the node operator, i.e. what other neighbourhood(s) the node participates to, their depth etc.

[istae]

3. in the ReserveSampler iterator, the chunks that are considered need to be filtered by checking that their proximity relative to the anchor is greater than equal to the current storage radius + d.

should be - _h_ where h stands for height, ie. the number of doublings

Assuming the radius r passed to the sampler function is the local radius (one that has h subtracted from it), the chunks in the sample should come from the neighborhood whose proximity with the anchor is at least is r + h, no ? Because, we will end up sampling the entire reserve, including chunks from unrelated neighborhoods, if we filter by proximity r only.

[istae]

Apart from the points that @zelig raised, I would add that we also need a command that will provide this information to the node operator, i.e. what other neighbourhood(s) the node participates to, their depth etc.

By increasing the capacity by a factor of h, the radius will eventually drop by h, so the node's scope of it's neighborhood will expand by the factor. The existing APIs will continue to operate as normal, eg status endpoint, peer's list, etc. What new information do you want to provide to the user?

[ldeffenb]

What new information do you want to provide to the user?

Personally, I'd like to see at least the reserveSizeWithinRadius for each of the individual neighborhoods that are covered. The total isn't nearly as informative as the individual neighborhood counts.

[istae]

What new information do you want to provide to the user?

Personally, I'd like to see at least the reserveSizeWithinRadius for each of the individual neighborhoods that are covered. The total isn't nearly as informative as the individual neighborhood counts.

imo this should be a new endpoint, maybe /status/neighborhoods, where we return the reserve size and peer count of each neighborhood?

[ldeffenb]

imo this should be a new endpoint, maybe /status/neighborhoods, where we return the reserve size and peer count of each neighborhood?

Works for me. But what would the current reserveSizeWithinRadius be in all of the existing responses? And especially /status which then feeds into /status/peers? Would it be the total of the sister neighborhoods or what? It becomes a non-comparable number if some nodes are double (or eventually quadruple or more) of "normal" nodes.