SWIP-21: Reserve doubling

[ct-ctrl]

this is to merge the swip-21 final draft into the SWIP repo to open it up for official review and comments.

[zelig]

we need:

• one or two diagrams
• discussion about push/retrieve protocols and the non-effect of reserve doubling on their correctness

[n00b21337]

We should probably mention that inclusion proofs will be checked "differently", as they are also dependent on "inProximity" function that checks bits of chunks. Or to be more precise they will get different depth than originally

for example

        if (!inProximity(entryProof2.proveSegment, _currentRevealRoundAnchor, winnerSelected.depth)) {
            revert OutOfDepthClaim(1);
        }

Winner is checked for depth, which actually is a revel struct, which has in it depth fetched from reported reveal.
So I suppose that we will also be checking sampling from increased reserve in this new feature.

[zelig]

We should probably mention that inclusion proofs will be checked "differently", as they are also dependent on "inProximity" function that checks bits of chunks. Or to be more precise they will get different depth than originally

for example

        if (!inProximity(entryProof2.proveSegment, _currentRevealRoundAnchor, winnerSelected.depth)) {
            revert OutOfDepthClaim(1);
        }

Winner is checked for depth, which actually is a revel struct, which has in it depth fetched from reported reveal. So I suppose that we will also be checking sampling from increased reserve in this new feature.

No, this does not change. the depth commited and revealed represents the depth of the playing reserve. The original address of the sampled chunk (coming from the proof) is correctly checked to match the anchor up to at least this depth. This is the retrievability validation proving that the chunk is located in the anchor's proximity within the committed depth.

Doubling the reserve means a node can play also when the sister neighbourhood is selected. It still must play with a sample of the chunks within the proximity of the anchor within the committed depth d. However, its own overlay is allowed to match the anchor up to only d-1 bits.

In general, operating with increased reserve means that registering a height m in the staking contract entitles your node to play if the difference between its proximity to the anchor and its committed depth is not greater than m. This is responsibility validation that is done as part of the reveal transaction.

[ldeffenb]

I see multiple (and necessary) mentions about "connecting to all peers in the sister neighborhood", but I suspect this will be problematic. The current kademlia attempts to connect to all nodes in the current neighborhood. This is good because the other nodes in the neighborhood are also trying to connect to us, and it "just works".

But consider a node that has doubled its reserve, it is now trying to connect to all immediate neighbors (as before), but now is also trying to connect to the nodes in the sister neighborhood as well. But the gotcha is that those nodes (at least, any that have not doubled) are NOT trying to connect to this node. So, all connections to the sister neighborhood nodes will be incoming connections to those peers which are purposely restricted so as not to overSaturate a node's connections. Without some kademlia changes, it may not be possible to achieve connections to "all" sister neighborhood nodes, and even less likely to be able to achieve (and maintain across peer connection periodic purges) this level of connections to cousin neighborhood nodes in a quadrupled (or more) configuration.

[zelig]

thanks for your feedback @ldeffenb

But consider a node that has doubled its reserve, it is now trying to connect to all immediate neighbors (as before), but now is also trying to connect to the nodes in the sister neighborhood as well. But the gotcha is that those nodes (at least, any that have not doubled) are NOT trying to connect to this node. So, all connections to the sister neighborhood nodes will be incoming connections to those peers which are purposely restricted so as not to overSaturate a node's connections.

like the jewish joke works:
1 this is not much more of a problem than in a nondoubled neighbourhoods, if 2 nodes are oversaturated then no connection is possible
2. neighbours can be checked for their height on the blockchain and can be made exempt
3. its only meant to be a few doubled nodes for each non-doubled one
4. there is no big harm in not being connected to all sister peers

Without some kademlia changes, it may not be possible to achieve connections to "all" sister neighborhood nodes, and even less likely to be able to achieve (and maintain across peer connection periodic purges) this level of connections to cousin neighborhood nodes in a quadrupled (or more) configuration.

This is kind of addressed in the text concluding that nodes are unlikely to go much farther ahead in doubling than the typical node. in other words the reserve size is expecyed to grow in a piecemeal fashion and uniformly

[n00b21337]

No, this does not change. the depth commited and revealed represents the depth of the playing reserve.

thnx, I reread SWIP and comment and I got what was meant.

[n00b21337]

We should add some lists of needed Tests for this SWIP