Period submission will stop if there is a gap in a slot list

[troggy]

There is a problem with current plasma bridge implementation. Consider the following use case:

Given:

• network with validator slots [0, 1, 2]. CAS quorum is 3 (3 period votes required to notarize a period submission)
• validator slot 1 is being logged out. Slot list becomes [0, null, 2]

Expected: the rest of validators continue successfully submitting periods with CAS quorum of 2.

Actual: plasma bridge will require 3 CAS sigs and will reject submissions with 2 CAS sigs → period submission and eventually consensus will stop.

[johannbarbie]

Expected: the rest of validators continue successfully submitting periods with CAS quorum of 2.

is this really the right expectation? the bridge assumes that all slots are always taken (hence the auction setup in PosOperator). in a network of 2/3 according to tendermint the consensus would also stop.

[troggy]

in a network of 2/3 according to tendermint the consensus would also stop. I can change the description to include >4 slots example. Doesn't change anything.

E.g. slot list like [0, null, null, 3, 4, 5] will work for tendermint and leap-node, but won't work for leap-contracts (because epochLength 6 requires 5 CAS sigs)

[troggy]

is this really the right expectation?

we have a logout procedure, hence the expectation. If we only had validator swap instead of logout, only then the assumption of "all slots area always taken" is correct

[johannbarbie]

is it technically possible to move slot 5 to slot 1 with the current implementation? then empty 5 and reduce epoch length?

[troggy]

is it technically possible to move slot 5 to slot 1 with the current implementation? then empty 5 and reduce epoch length?

sounds like a good idea, but cannot tell offhand if it will work right away

[troggy]

one more idea: store a bitmap of taken slots onchain (256 bits is just enough). How expensive it is to use such a bitmap during period submission (only single SLOAD ~and we have a 0..255 loop already~ reuse the loop?) ?

[johannbarbie]

If we only had validator swap instead of logout

interesting idea. should we remove the logout? it would clear up the design assumptions, and simplify the code. but how to reduce epochLength then, if the last slot can never be emptied?

[troggy]

if we use swaps we have no way to slash a slot when there is no waiting list. Also I don't think that automatically setting slots makes sense — we want to make sure the new validator is up and there is no way to make it onchain

[johannbarbie]

store a bitmap of taken slots onchain (256 bits is just enough). How expensive it is to use such a bitmap during period submission (only single SLOAD and we have a 0..255 loop already) ?

45,000 for full iteration of the bitmap, and another 2000 for sload 🤔

[troggy]

the loop will be capped by epochLength, so 256 iterations is the worst case. And we have this loop already here so little extra cost?

[johannbarbie]

i can give it a try and measure the extra cost. but isn't this opening a way bigger complexity in the node? now the node needs to track the slots in detail, not only epochLength, and make sure to submit exactly the right amount of sigs?

[troggy]

now the node needs to track the slots in detail, not only epochLength, and make sure to submit exactly the right amount of sigs?

node is already ignoring epochLength, but using the number of taken slots instead. Need to test it though for period votes

[troggy]

now the node needs to track the slots in detail

Addressed for period vote checks here

make sure to submit exactly the right amount of sigs

Addressed here

[troggy]

should be solved via https://github.com/leapdao/leap-contracts/issues/266