Skip to content

SWIP-44: eligibility for sampling and game participation during reserve-expanding pull-sync #92

Open
significance wants to merge 4 commits into
masterfrom
feat/amend-schelling-point-radius-decrease
Open

SWIP-44: eligibility for sampling and game participation during reserve-expanding pull-sync #92
significance wants to merge 4 commits into
masterfrom
feat/amend-schelling-point-radius-decrease

Conversation

@significance
Copy link
Copy Markdown
Member

No description provided.

Copy link
Copy Markdown
Member

@zelig zelig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

jaw-dropping accuracy, cannot find a problem with this SWIP

@zelig zelig changed the title 🚧 WIP 🚧 amend schelling point during radius change SWIP-44: amend schelling point during radius change Apr 21, 2026
@zelig zelig changed the title SWIP-44: amend schelling point during radius change SWIP-44: reserve-expanding sync eligibility Apr 21, 2026
@zelig zelig changed the title SWIP-44: reserve-expanding sync eligibility SWIP-44: eligibility for sampling and game participation during reserve-expanding pull-sync Apr 21, 2026
@zelig zelig added improvement enhancement of an existing protocol/strategy/convention protocol describes a process every swarm node must implement and adhere to labels Apr 21, 2026
Comment thread SWIPs/SWIP-44.md Outdated
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:
Copy link
Copy Markdown

@acud acud May 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
@significance
Copy link
Copy Markdown
Member Author

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

improvement enhancement of an existing protocol/strategy/convention protocol describes a process every swarm node must implement and adhere to

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants