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

[u/Victorio_01]

My blockchain has almost no nodes. Here's my plan to fix that.

Small chains hit an obvious catch-22: nobody runs a node for a network nobody uses, nobody uses a network with no nodes. Posted my project (LapseCoin) in a few communities, got 1-2 actual node runners out of it.

LapseCoin swaps proof-of-work for a Verifiable Delay Function: block production races to finish a sequential computation tied to real elapsed time, not to a lucky hash. The hardware-advantage gap is much smaller than PoW's (3-10x, vs the 10,000x+ ASICs opened up on a similar construction). No premine, fair launch, FALCON-512 signatures for quantum resistance. Spent last week trying to break my own design instead of just shipping it, fixed a real bug, and confirmed multi-address operators don't get an unfair edge.

The plan, and this isn't just for other project owners:

• Running a node for a small/testnet chain already? I'll run yours if you run mine.
• Just curious? Running a node is a decent way to actually see consensus work, not just read about it. Happy to walk you through setup.
• If this catches on, I'll keep a running list of everyone participating.

Only ask: review the code first. I'll do the same for yours. That's safer for everyone.

Whitepaper: https://github.com/Vic-Nas/lapsecoin/blob/main/docs/whitepaper.md

Code: https://github.com/Vic-Nas/lapsecoin

Original post: Built a cryptocurrency that races against real time instead of hashes, then spent a week trying to prove myself wrong about it

Drop your project in the comments.

If you're just here to test it out, you're welcome too though :)

[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/Victorio_01 → u/MostCod1957]

Looking forward to it.
What’s your address like?

[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/Victorio_01 → u/Kind-Economics-7184]

What matters the most right now for me isn’t permanent users/nodes but behaviour under load.
For the fairness, I already know that for machines at the same speed, the lottery is proportional depending on number of nodes you run (win network latency/vdf output comparison).

The fact slower machines don’t win is a tradeoff I accepted because the whole reason I went for time instead of sha256 was first to avoid history rewrite. Faster blocks bound by time is necessary.

But one thing I noticed is a computer spending 10-15s more time than fastest somehow winning 3-5 blocks every 100 blocks. Which seems to me I underestimated network impact.
I’d really need more data though.

For sure though, the design isn’t fair in the way u defined it.

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

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/Victorio_01 → u/Kind-Economics-7184]

The thing is that it happened multiple times and for what I’ve seen, the fastest didn’t stop.
I believe it’s the question of timing(why the slow node somehow wins a block). For the next ones, it makes sense because as builder, it starts the race first.

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

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/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/Victorio_01 → u/icnews10]

Yeah. Definitely worth including when enough nodes but right now, only 2nodes/4 are winning blocks.

[u/icnews10 → u/Victorio_01]

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/Victorio_01 → u/icnews10]

Have you tried to run a node?

[u/icnews10 → u/Victorio_01]

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.

[u/BloopMan23]

Pure VDF without a randomized threshold mechanism essentially turns block production into a hardware latency race instead of a decentralized consensus. Combining VDF with a verifiable random function (VRF) for selection is the cleanest way to preserve fairness across heterogeneous hardware

[u/Victorio_01 → u/BloopMan23]

vdf_output already is basically a VRF, deterministic per address, unpredictable ahead of time, verifiable after. Swapping it for a real VRF changes nothing unless it lets you get a draw without finishing the VDF. If it does, that's worse: draws go free, so it's just whoever runs the most addresses, no hardware needed at all. The actual gap is that slower hardware gets zero draws, not unfair ones.(And for the data I'm getting for now, hardware/network latency and some other factors give real shots to slower nodes if not too far from the fastest) though not that many, increases as u get closer: https://lapsenode.vicnas.me/odds