Parano1d ① Proof-native Layer 1 ordered by PoW

[alt_x]

The data strongly suggests there is a code-level bottleneck in the block-production pipeline: the chain has zero block intervals below 6 seconds, with the first observed intervals appearing at 6 seconds. That indicates the implementation may be unable to produce and commit a new block within roughly 0–5 seconds under the current conditions.

A block is proof construction first, then PoW, so the shortest possible interval is the proof time plus however long it takes to find a valid nonce. The same miner producing all six is not evidence of a code-level bottleneck.

I think the right way to settle this is to run a stress test with no artificial blocktime floor. That would let us measure the actual time required to construct and commit a block, separately from the time required to find a valid PoW nonce.

It would also answer an important question: can a sufficiently powerful miner actually start mining the next block earlier than other miners because it can complete the block-construction/proof pipeline faster? If so, an efficient miner could gain an additional advantage by getting into the PoW phase sooner, rather than the advantage coming purely from raw hash rate.

The code is public. There is no artificial blocktime floor to remove. Block production is proof construction followed by PoW, exactly as implemented.

Please read the code before making more claims about the pipeline:
https://github.com/ignotusnemo/parano1d

I am happy to discuss specific code or measurements. I am not interested in debating AI-generated speculation.

Honestly, the language barrier feels almost impossible to overcome, even with translators. By the end of the discussion, the meaning seems to get distorted so badly that we end up talking past each other. And when the discussion turns to technology, it sometimes feels like the old Russian stereotype of engineering: half-finished technology, important steps being skipped, and a strong focus on getting the product to market instead of properly resolving the underlying technical issues. I’m trying to discuss the actual technology and measurable behavior, but we keep jumping over the intermediate steps needed to establish what is really happening

[IgnotusNemo]

Parano1d Testnet v2 is live.

The network has restarted from a new genesis. it includes a complete redesign of the P2P layer and the mining/reorg liveness path.

The old networking design moved headers, block bodies, recursive proofs and State through the same synchronization flow. Under real load, slow transfers could delay tip propagation, bind sync progress to one peer and leave miners working on stale parents.

UPD: Download the GUI wallet or Core daemon:
https://github.com/ignotusnemo/parano1d/releases/tag/v2.0.1

v2 validates and propagates headers first. Bodies, proofs and State are fetched separately as exact content-addressed objects and may come from different peers. Losing one source no longer discards verified progress. Competing branches are resolved using their exact bodies and one recursive terminal at the selected tip, then committed atomically. Snapshot transfer and peer resource usage are now bounded, and ordinary GUI and daemon nodes participate in peer discovery and relay traffic.

The block target was increased to 20 seconds to leave enough headroom for affordable 4-core VPS nodes to verify proofs, follow the tip and serve peers reliably under load.

Existing users can install v2.0.1 directly. On first start it removes the old chain data automatically while preserving wallet.key.

The full technical description is in the merged PR:
https://github.com/ignotusnemo/parano1d/pull/6

Now let’s give it a proper public stress test. Run nodes, mine, restart them, interrupt connections and try to break synchronization. If something fails, please post the logs and exact steps to reproduce it.


P.s. A rough mental model of the difference between the v1 and v2 networking designs:

[IgnotusNemo]

My old laptop

[Hashrateoptions]

My old laptop

https://www.talkimg.com/images/2026/08/15/U4joOD.png

But can be new restarts no thanks.

[IgnotusNemo]

But can be new restarts no thanks.

yes, this is testnet v2. there will definitely be a restart before mainnet

[Hashrateoptions]

But can be new restarts no thanks.

yes, this is testnet v2. there will definitely be a restart before mainnet

It was an sarcasm I had restart and all my coins are not valid btw linux gui can not be downloaded

[alt_x]

BLOCKTIME DISTRIBUTION

SECONDS    BLOCKS       PERCENT     

0          0               0.0000%
1          0               0.0000%
2          0               0.0000%
3          0               0.0000%
4          0               0.0000%
5          0               0.0000%
6          0               0.0000%
7          1               0.2058%
8          7               1.4403%
9          55             11.3169%
10         43              8.8477%
11         28              5.7613%
12         26              5.3498%
13         20              4.1152%
14         19              3.9095%
15         17              3.4979%
16         27              5.5556%
17         19              3.9095%
18         14              2.8807%
19         17              3.4979%
20         15              3.0864%

[IgnotusNemo]

But can be new restarts no thanks.

yes, this is testnet v2. there will definitely be a restart before mainnet

It was an sarcasm I had restart and all my coins are not valid btw linux gui can not be downloaded

 

CI builds are in progress, will be available soon
https://github.com/ignotusnemo/parano1d/actions/runs/31905214082

[IgnotusNemo]

Published

https://github.com/ignotusnemo/parano1d/releases/tag/v2.0.0

[alt_x]

Gui miner state "waiting" most of the time.

[IgnotusNemo]

Gui miner state "waiting" most of the time.

Download the latest version now. There is no "waiting" state in the GUI, only "SYNCING TIP". You downloaded a draft build.

[alt_x]

Gui miner state "waiting" most of the time.

Download the latest version now. There is no "waiting" state in the GUI, only "SYNCING TIP". You downloaded a draft build.

 I tried one from the latest release, and one from:
https://github.com/ignotusnemo/parano1d/actions/runs/31905214082/job/95061872608

 Both stay most of time as waiting.


Btw. Insane amount of work you have done in such small time.

[IgnotusNemo]

“Syncing tip” is normal behavior. It usually takes a few seconds when another miner finds a block, after which mining resumes automatically.

P.s. Use a more powerful CPU if you want to see that message less often

[IgnotusNemo]

Gui miner state "waiting" most of the time.

Download the latest version now. There is no "waiting" state in the GUI, only "SYNCING TIP". You downloaded a draft build.

 I tried one from the latest release, and one from:
https://github.com/ignotusnemo/parano1d/actions/runs/31905214082/job/95061872608

 Both stay most of time as waiting.


Btw. Insane amount of work you have done in such small time.

remove the current GUI and download it again from the v2.0.0 release: https://github.com/ignotusnemo/parano1d/releases/tag/v2.0.0

[alt_x]

It makes hardly any CPU load, and the top-right corner still says “Waiting.”
I’m not going to put real computing power behind this until I can see that the miner actually works.
I’m also still not seeing any 0–5 second block intervals in the chain, so I’m not betting anything on this yet.
Once these issues are resolved and the mining pipeline is demonstrably working as expected, the road is open.

[IgnotusNemo]

It makes hardly no CPU load and still at rigth top corner it says waiting.

If it says “WAITING FOR PEERS”, you are running the earlier v2.0.0 build.
Please download and reinstall  from the release page https://github.com/ignotusnemo/parano1d/releases/tag/v2.0.0.
The updated build shows “SYNCING TIP” and resumes mining automatically after verification.

I’m also still not seeing any 0–5 second block intervals in the chain, so I’m not betting anything on this yet.

You are still using a metric you do not understand. A block cannot appear before proof construction finishes, so 0–5 second intervals are not expected.

Read this: https://lab.parano1d.org/research/prove-once-search-nonces/

[alt_x]

It makes hardly no CPU load and still at rigth top corner it says waiting.

If it says “WAITING FOR PEERS”, you are running the earlier v2.0.0 build.
Please download and reinstall  from the release page https://github.com/ignotusnemo/parano1d/releases/tag/v2.0.0.
The updated build shows “SYNCING TIP” and resumes mining automatically after verification.

I’m also still not seeing any 0–5 second block intervals in the chain, so I’m not betting anything on this yet.

You are still using a metric you do not understand. A block cannot appear before proof construction finishes, so 0–5 second intervals are not expected.

I know how to install software and verify which version I’m running. I’ve already done that.

Honestly, it starts to feel like I’m interacting with an AI agent rather than the developer, because the interactivity is basically zero. I’m reporting concrete behavior and measurements, but the response keeps repeating installation instructions instead of engaging with the actual technical issue.

[alt_x]

From a small miner’s perspective, the concern is that the block-production pipeline creates a significant time disadvantage before PoW even begins.

If the chain’s observed minimum is around 6 seconds and the typical blocktime is around 15 seconds, a small miner may spend much of each cycle waiting for the next template/proof pipeline to become available.
A miner with a faster CPU can potentially complete proof construction / HistoryStep sooner and enter the nonce-search phase earlier.

That creates a potential two-layer advantage:

large/fast miner: faster proof construction → earlier PoW start → more time hashing
small miner: slower proof construction → later PoW start → less effective time competing

So the concern isn't simply “small miners have less hash rate.”
It's that they could also lose effective mining time before they even get to hash.

If that effect is significant at the observed ~15-second blocktime, then decentralization could become a serious problem.
A network where smaller miners are routinely waiting while better hardware gets into the PoW phase first could become increasingly concentrated in the hands of the fastest hardware.

I would phrase the conclusion carefully, though: the current data suggests this risk; it doesn't yet prove that small miners are excluded from mining.
A controlled benchmark measuring proof-construction time by CPU would establish whether that advantage is actually large enough to matter.

[IgnotusNemo]

From a small miner’s perspective, the concern is that the block-production pipeline creates a significant time disadvantage before PoW even begins.

If the chain’s observed minimum is around 6 seconds and the typical blocktime is around 15 seconds, a small miner may spend much of each cycle waiting for the next template/proof pipeline to become available.
A miner with a faster CPU can potentially complete proof construction / HistoryStep sooner and enter the nonce-search phase earlier.

That creates a potential two-layer advantage:

large/fast miner: faster proof construction → earlier PoW start → more time hashing
small miner: slower proof construction → later PoW start → less effective time competing

So the concern isn't simply “small miners have less hash rate.”
It's that they could also lose effective mining time before they even get to hash.

If that effect is significant at the observed ~15-second blocktime, then decentralization could become a serious problem.
A network where smaller miners are routinely waiting while better hardware gets into the PoW phase first could become increasingly concentrated in the hands of the fastest hardware.

I would phrase the conclusion carefully, though: the current data suggests this risk; it doesn't yet prove that small miners are excluded from mining.
A controlled benchmark measuring proof-construction time by CPU would establish whether that advantage is actually large enough to matter.

The current testnet target is 20 seconds, not 15.

Stronger hardware has an advantage in every PoW system. In Parano1d, faster hardware can also finish HistoryStep earlier and begin nonce search sooner.
The important difference is that PoW only orders already proof-valid State transitions. More compute cannot bypass proof verification or make an invalid transition valid.

[IgnotusNemo]

To avoid any confusion between builds and releases going forward, I moved the latest mining-readiness and exact-tip sync fixes into v2.0.1.

https://github.com/ignotusnemo/parano1d/releases/tag/v2.0.1

v2.0.1 is now the current release. It includes the minor synchronization fixes discussed above.
You can verify the installed GUI version in the upper-left corner, immediately next to the Parano1d logo. For the Core daemon, run parano1d --version in the terminal.

For future issue reports, please include the exact installed version and either the relevant log lines or the exact GUI panel and status where the problem appears.