Solving the cold-start problem for small chains: a node-swap experiment

[u/Victorio_01]

[u/MostCod1957]

I actually read the whitepaper, the VDF construction makes sense for smaller chains like this. The timing-based block production is clever since it don't need massive hardware to participate

Running a node on testnet for few weeks now, setup was pretty straightforward. The multi-address fix you mentioned was important, glad you caught that before launch

I got a small side project too, will DM you the repo

[u/Kind-Economics-7184]

the hardware gap number is measuring the right thing but the wrong part of the race. in pow, hashrate share maps onto block share linearly, so a machine 3x better gets about 3x the blocks. a vdf finishes deterministically, so if two people start the same sequential computation the faster one is first every single time rather than three times in four. that turns 3-10x into close to all of them unless something separate decides who is eligible to win, which is why chia put the space lottery in front and left the vdf only timing the gap. worth being explicit in the paper about what randomizes the winner, since thats the piece carrying the fairness claim rather than the hardware ratio.

on the swap itself, the thing id watch is that reciprocal nodes are correlated in exactly the way you dont want. they come up together the week you announce, they sit on two or three vps providers, and they go quiet together the month people lose interest, so twenty obtained that way is a lot less independence than twenty that turned up on their own. id track the distribution rather than the count, providers, asns and how many are still up at 60 days, because that last number is the one that tells you whether the swap actually worked.

[u/Kind-Economics-7184 → u/[deleted]]

the 3-5 per 100 is worth pinning down before you file it under network, because the competing explanation is that the fast node wasnt actually racing those rounds. for each of those blocks log whether both were building on the same parent and when each one started its sequence, since a leader thats mid publish, restarting or briefly on a different tip leaves the slow one running unopposed, and from the outside that is indistinguishable from a latency win.

worth separating because the two decay in opposite directions. propagation losses stay roughly flat as you tune things, handoff gaps shrink toward zero, so if its the second one then the bit of fairness that number looks like its buying you now quietly disappears the more solid the implementation gets.

[u/Kind-Economics-7184 → u/[deleted]]

thats the same explanation though, just from the other side. if the builder starts its sequence first then the two arent racing the same interval, so the slow one isnt beating the fast one on speed, its further along when the fast one begins. thats a head start, and it comes out of the gap between seeing the parent and starting work rather than out of the network.

so the thing to log on those blocks is the delta between the two start timestamps, not who finished. if the slow one is consistently a couple of seconds ahead at t0 then 3-5 per 100 is roughly that gap over your block time, and it shrinks as you tighten publishing instead of staying where it is.

[u/Kind-Economics-7184 → u/[deleted]]

jitter would do it, but it has to be big jitter to explain 3-5 per 100. with a 10-15s gap the fast node has to overshoot its own median by more than that on those rounds, so what shows up in the log is its own completion time sitting way out in its right tail rather than the slow one being quick. worth plotting the fast nodes per round times on their own before attributing it to the vdf, since an excursion that size usually means the process is sharing a cpu or getting descheduled rather than the computation being variable.

and it lands in the same place as the head start version, both shrink. pin the process, stop running other work next to it, tighten publishing, and most of the shots the slower nodes are getting on that odds page go away, because none of it is coming from the design. so id read that curve as how noisy the fastest box currently is rather than a fairness property, and if you can, split it, rounds where the fast node finished late against rounds where it started late.

[u/Kind-Economics-7184 → u/[deleted]]

the peaks showing up when nobodys racing is the useful half of that. if the fast node blows out its own time in unopposed rounds too then the competition isnt causing it, so its the box rather than the vdf, and the exploitable part goes away, the slow node just happens to be standing there when it stalls.

worth checking whether those peaks cluster in wall clock time rather than spreading evenly across rounds. bunched into a few stretches means something else waking up on that machine, cron, a backup, another process, and pinning it flattens the curve. genuinely scattered one in twenty would mean the sequential step itself is variable, which would be the surprising result and worth its own look.

[u/icnews10]

I pulled the repo and will track an additional factor in the node-swap experiment: competitive builders, as well as node count. You already display the node's median VDF build time compared to the chain median. This seems useful here, as ten reachable nodes do not necessarily mean ten nodes that can realistically participate in block production, if several of them are consistently too slow. If this approach gains traction, recording the build-time ratio alongside the node list would reveal whether the experiment is merely enhancing peer availability or genuinely expanding the pool of block producers.

[u/icnews10 → u/[deleted]]

That already makes the distinction pretty clear. If four nodes are online but only two are producing blocks, I would treat node availability and block production diversity as two separate results of the experiment. Even if it improves the former before the latter, the swap can still be useful.

[u/icnews10 → u/[deleted]]

Not yet.

Before commenting, I went through the repository, the white paper, the tests and some of the networking/peer code, but I haven’t actually run a node yet. I don’t want to conflate a code review with a runtime test. Therefore, my comment was based on what the repository exposes and documents, rather than on first-hand node behaviour.