SWIP-44: eligibility for sampling and game participation during reserve-expanding pull-sync #92
SWIP-44: eligibility for sampling and game participation during reserve-expanding pull-sync #92significance wants to merge 4 commits into
Conversation
zelig
left a comment
There was a problem hiding this comment.
jaw-dropping accuracy, cannot find a problem with this SWIP
| interval during which the node computes its reserve sample for the current | ||
| redistribution round. | ||
|
|
||
| **Algorithm 3 (Sync Suspension Protocol).** On entry to the sampling window: |
There was a problem hiding this comment.
while there are still a lot of details for me to digest with this proposal, this part for me is particularly alarming. getting sync to work well is hard enough; why do we want to introduce an architectural change that basically goes against every common sense of having a reasonable UX? do we see ethereum preventing you from submitting a transaction while a block is mined?
i really don't think that continuously turning syncing on and off is a good idea, not at all. also, how do you prevent pushsync chunks from coming in during this time-window? from my perspective all of these considerations must be handled on the persistence abstraction level, not on the protocol level.
the eligibility predicate alone guarantees no pullsync in bins >= d, making sync suspension redundant. sub-depth sync may continue uninterrupted during sampling. pushsync concurrency is a pre-existing concern orthogonal to this proposal.
|
@acud on closer inspection syncing around newly arrived chunks should be out of scope for this change the intention was to avoid the sync state guarding participation to the game. i have reformulated the swip to amend the guard to be more sympathetic to the requirements and hence obviated the need to pause historical sync in the new bin the problem with pushsync newly arrived chunks is orthogonal and something to be addressed in a different forum |
No description provided.