[ANN][ZCD] Zycord | A P2P network of self-certifying state | Mainnet Oct 1

[andremangra]

Hi,
I'm really interested in your project!  

I’m preparing a local Windows RandomX build, without running the node or miner yet. I’ve opened GitLab Issue #36 with specific questions about the supported toolchain and which source snapshot to use:
https://gitlab.com/zycord-group/zycord-node/-/work_items/36

Could you take a look when you have a chance? I also saw that SECURITY.md does not list a private reporting channel. If someone identifies a potentially sensitive security issue, how should they contact you without posting the details publicly?

Thanks,
Andrea

The network starts small and grows on its own. On day one it handles about 90 certificates per second. That is low, and it is on purpose. A high ceiling at launch would be a ceiling the network has not yet proven it can propagate between nodes, and a block that propagates badly is a block that turns into a fork. So it starts with a low ceiling, and that ceiling rises with real demand. The 1 million is not a capacity that exists today.

This also keeps the fee market alive. Because capacity follows measured demand, block space always has a real price, instead of collapsing to the floor the way it does on networks that launch with far more capacity than use.

When the network detects that it needs to grow, it does so automatically, and it can at most double its capacity every year. If demand goes away, idle capacity shrinks back, slowly, and never below the launch value.

year	capacity
0	~90/s
7	~11,000/s
10	~90,000/s
~13.6	~1.1 million/s

The calculation is in the whitepaper, section 8.1, "Capacity across eras". And there is an important detail you caught: there is a deliberate limit inside the current era. No matter how full the network gets, growth stops at around 427 certificates per second. Passing that gate takes a hard fork, which in the project's schedule are the era transitions. It was designed this way because in Era 0 I chose to keep the surface of the blockchain small, so it is easier to program and audit. In the following eras there will be more people to do that safely.

And that limit is more than enough to reach Era 2. Even if the network grows at the maximum rate every single day, it reaches Era 2 at about 255 certificates per second, well below 427. The gate would only be reached some nine months after the era transition, and the era transition is exactly what moves the gate.

One more thing: the number is certificates, not transactions. A certificate can carry a single payment, or several batched by a sequencer. So 1 million certificates per second is the floor in transactions, not the ceiling.

On measuring sustained throughput: today there are few machines mining the testnet, so a test here would measure my setup and not the network. Once mainnet is live we will be able to measure it properly. What we have tested so far is something else: a thousand contract calls to the same recipient, in the same block, and all thousand were applied with zero skips. For comparison, we wrote the same contract the traditional way, which reads the balance, adds, and writes. With two tips at the same time, it already discarded one. With deltas, a thousand did not collide.

What this shows is the core idea of the project: all the heavy logic runs on the sender's machine, before publication. The miner executes nothing. It verifies that each certificate is well formed and signed, which is parallel work, and applies the result, which is a trivial operation: compare, add, write. That is what we have been validating on the testnet. That the mechanism we designed works.

Thanks for the capacity clarification. Keny has already provided a helpful technical reply in GitLab #36, so I won’t repeat the Windows build questions here.

I had one remaining question from my earlier post: is there a preferred private contact for reporting potentially sensitive security findings?

Thanks,
Andrea

[darkko]

Hi,
I'm really interested in your project!  

I’m preparing a local Windows RandomX build, without running the node or miner yet. I’ve opened GitLab Issue #36 with specific questions about the supported toolchain and which source snapshot to use:
https://gitlab.com/zycord-group/zycord-node/-/work_items/36

Could you take a look when you have a chance? I also saw that SECURITY.md does not list a private reporting channel. If someone identifies a potentially sensitive security issue, how should they contact you without posting the details publicly?

Thanks,
Andrea

The network starts small and grows on its own. On day one it handles about 90 certificates per second. That is low, and it is on purpose. A high ceiling at launch would be a ceiling the network has not yet proven it can propagate between nodes, and a block that propagates badly is a block that turns into a fork. So it starts with a low ceiling, and that ceiling rises with real demand. The 1 million is not a capacity that exists today.

This also keeps the fee market alive. Because capacity follows measured demand, block space always has a real price, instead of collapsing to the floor the way it does on networks that launch with far more capacity than use.

When the network detects that it needs to grow, it does so automatically, and it can at most double its capacity every year. If demand goes away, idle capacity shrinks back, slowly, and never below the launch value.

year	capacity
0	~90/s
7	~11,000/s
10	~90,000/s
~13.6	~1.1 million/s

The calculation is in the whitepaper, section 8.1, "Capacity across eras". And there is an important detail you caught: there is a deliberate limit inside the current era. No matter how full the network gets, growth stops at around 427 certificates per second. Passing that gate takes a hard fork, which in the project's schedule are the era transitions. It was designed this way because in Era 0 I chose to keep the surface of the blockchain small, so it is easier to program and audit. In the following eras there will be more people to do that safely.

And that limit is more than enough to reach Era 2. Even if the network grows at the maximum rate every single day, it reaches Era 2 at about 255 certificates per second, well below 427. The gate would only be reached some nine months after the era transition, and the era transition is exactly what moves the gate.

One more thing: the number is certificates, not transactions. A certificate can carry a single payment, or several batched by a sequencer. So 1 million certificates per second is the floor in transactions, not the ceiling.

On measuring sustained throughput: today there are few machines mining the testnet, so a test here would measure my setup and not the network. Once mainnet is live we will be able to measure it properly. What we have tested so far is something else: a thousand contract calls to the same recipient, in the same block, and all thousand were applied with zero skips. For comparison, we wrote the same contract the traditional way, which reads the balance, adds, and writes. With two tips at the same time, it already discarded one. With deltas, a thousand did not collide.

What this shows is the core idea of the project: all the heavy logic runs on the sender's machine, before publication. The miner executes nothing. It verifies that each certificate is well formed and signed, which is parallel work, and applies the result, which is a trivial operation: compare, add, write. That is what we have been validating on the testnet. That the mechanism we designed works.

Thanks for the capacity clarification. Keny has already provided a helpful technical reply in GitLab #36, so I won’t repeat the Windows build questions here.

I had one remaining question from my earlier post: is there a preferred private contact for reporting potentially sensitive security findings?

Thanks,
Andrea

I guess your answear is in the SECURITY.md file:

Security
Reporting
There is no private reporting channel, so assume anything filed is
public. For anything critical, do not open a public issue and do not post a
reproduction: open one naming the category and nothing else, and wait to be told
where to send the detail. Anything else belongs in the open. Say which rule is
broken, by id (V4, B3, F7); who does what in what order and what they gain;
and give a reproduction, ideally a test in core/fold or a scenario in sim/.
Critical means one signature billed twice; billing a third party by making their
certificate skip; creating value, whether supply growing other than by
emission(height), an asset over its cap, or a treasury write that is not the
fold's credit; a consensus split; encoding ambiguity that makes a valid block
unprovable or an invalid one pass; or non-determinism in the fold. In scope: this
repository and the parameter sets in spec/.

[kenyfran]

I came from your post in the Monero community. I like the project; I think it has potential.

I can contribute by doing a quick code review. The code seems well-written. I found some tests failing on Windows and macOS due to environment issues; I ran them myself as well.

I ran the project and the benchmark to compare the results against the stated figures.


 Node & wallet (devnet) — macOS Apple Silicon, dev @ 4b00615
 

• make build and make build-randomx both work. The RandomX binaries run and pass codesign --verify (the fix from !2 holds, no binutils needed).
• zcd vectors: 152/152 passed; genesis ids match.
• Devnet mined normally; created two wallets and sent a transfer (applied at height 16 (APPLIED)); the recipient's balance was confirmed.
• zcd ui serves on loopback only; the API returns 401 without the token.
• Small doc note: the README quickstart runs wallet balance / send without --devnet, which fails against a devnet node with a chain id mismatch.

  Benchmarks vs. your figures — median of 5 runs, -benchtime 2s, idle machine, 8 cores
 
 

Metric	Yours (10-core x86)	Mine (macOS Apple Silicon)
Sequential fold, one core	883,000 ops/s (~294K certs/s)	1,033,091 ops/s (~344K certs/s)
Block of 2,900 certs: verify	1,963 ms	1,416 ms
Block of 2,900 certs: apply	9.9 ms	8.4 ms direct / 11.4 ms by subtraction
Parallel share	99.5%	99.2%
Stateless verification, per core	1,470 certs/s	2,095 certs/s
Stateless verification, all cores	5,220/s (10 cores)	~6,200–7,000/s (8 cores)
Single signature verify	1,500/s	2,226/s

  My numbers are close to yours and mostly faster. The ratio behind the design holds: applying the block is about 1% of block time, and verification is about 99%.

  Two observations:
 

• The "1,963 ms to verify (parallel)" figure appears to be measured on one core: CheckBlockRules lives in core/, where goroutines are not allowed, and 2,900 / 1,470 per core
    ≈ 1.97 s. Through the node/verify pool the same block would take ~410 ms on this machine. It might be worth labelling it "parallelizable stage, single core".
• Core scaling of the verify pool: 1→2 workers 1.92x, 1→4 3.08x, 1→8 2.97x. The efficiency cores add nothing past 4 workers.

  Commands used (the docs/BENCHMARKS.md referenced in cevm_era0_bench_test.go isn't in the repo):
 

Code:

go test -run XXX -bench 'BenchmarkFoldLoop|BenchmarkApplyBlock|BenchmarkBlockRules|BenchmarkEra0Baseline' -benchtime 2s -count 5 ./core/fold/
  go test -run XXX -bench . -benchtime 2s -count 5 ./node/verify/

[thesimstoshi]

Zycord devlog – Sep 19 → Sep 24

🔜 v0.4.0 is being tagged in the next day. Everything below is in it.

First week with outside contributors: Windows 11, macOS Apple Silicon and Darwin builds, all passing the 152 RandomX vectors with matching genesis ids. They caught a regression of mine that broke the CI gate on every platform, and two merge requests from the community are already merged. Thank you!

✅ Block-body pruning: zycordd --retain-bodies keeps the last N bodies and reclaims the rest; the handshake advertises the floor (protocol v3), and a pruned block is answered as such instead of timing out
✅ Rule V10 now proves a double spend of a one-shot address as equivocation; before, it was invisible. Loosening only
✅ Co-signing service hardened to match: four paths that would have cost it its bond are closed
✅ Co-signed certificates were not being gossiped, so service-paid sends stayed pending for blocks: fixed
✅ Commit store refuses to continue after a failure in the one window where retrying would corrupt the log
✅ Release artefacts now built by a pipeline on a second machine, on tags only, in the canonical container
✅ Engine archives carry a TOOLCHAIN.txt naming the compilers that built them: a record, not a pin
✅ make test is now expected to pass on every published target, and the tree says so
✅ SECURITY.md: private reporting channels named (details in the next post)

🔜 Windows: file mode 0600 does nothing there, so the trust token and credit ledger rely on inherited ACLs. Decision taken: owner-only on every platform, Windows gets an explicit DACL. Please, anyone with a Windows Intel/AMD machine, help me with the patch.

[thesimstoshi]

On private reporting, since it was asked here and darkko quoted the old text: SECURITY.md was wrong on that point and has been updated.

While we are on testnet there is no coin and nothing to exploit for value, so everything can be filed in the open, and a public issue with a reproduction is the fastest route. Once mainnet is live, a finding that could be used against the running network is filed as a confidential issue on GitLab. Anyone who can open an issue can tick "This issue is confidential" when creating it; it is then visible only to the reporter and to project members with Reporter access or above. Put the reproduction in it. That option already works today, for anyone who would rather not disclose in the open.

What a report should contain is unchanged: the rule that breaks, by id, who does what in what order and what they gain, and a reproduction.

[thesimstoshi]

I came from your post in the Monero community. I like the project; I think it has potential.

I can contribute by doing a quick code review. The code seems well-written. I found some tests failing on Windows and macOS due to environment issues; I ran them myself as well.

I ran the project and the benchmark to compare the results against the stated figures.


 Node & wallet (devnet) — macOS Apple Silicon, dev @ 4b00615
 

• make build and make build-randomx both work. The RandomX binaries run and pass codesign --verify (the fix from !2 holds, no binutils needed).
• zcd vectors: 152/152 passed; genesis ids match.
• Devnet mined normally; created two wallets and sent a transfer (applied at height 16 (APPLIED)); the recipient's balance was confirmed.
• zcd ui serves on loopback only; the API returns 401 without the token.
• Small doc note: the README quickstart runs wallet balance / send without --devnet, which fails against a devnet node with a chain id mismatch.

  Benchmarks vs. your figures — median of 5 runs, -benchtime 2s, idle machine, 8 cores
 
 

Metric	Yours (10-core x86)	Mine (macOS Apple Silicon)
Sequential fold, one core	883,000 ops/s (~294K certs/s)	1,033,091 ops/s (~344K certs/s)
Block of 2,900 certs: verify	1,963 ms	1,416 ms
Block of 2,900 certs: apply	9.9 ms	8.4 ms direct / 11.4 ms by subtraction
Parallel share	99.5%	99.2%
Stateless verification, per core	1,470 certs/s	2,095 certs/s
Stateless verification, all cores	5,220/s (10 cores)	~6,200–7,000/s (8 cores)
Single signature verify	1,500/s	2,226/s

  My numbers are close to yours and mostly faster. The ratio behind the design holds: applying the block is about 1% of block time, and verification is about 99%.

  Two observations:
 

• The "1,963 ms to verify (parallel)" figure appears to be measured on one core: CheckBlockRules lives in core/, where goroutines are not allowed, and 2,900 / 1,470 per core
    ≈ 1.97 s. Through the node/verify pool the same block would take ~410 ms on this machine. It might be worth labelling it "parallelizable stage, single core".
• Core scaling of the verify pool: 1→2 workers 1.92x, 1→4 3.08x, 1→8 2.97x. The efficiency cores add nothing past 4 workers.

  Commands used (the docs/BENCHMARKS.md referenced in cevm_era0_bench_test.go isn't in the repo):
 

Code:

go test -run XXX -bench 'BenchmarkFoldLoop|BenchmarkApplyBlock|BenchmarkBlockRules|BenchmarkEra0Baseline' -benchtime 2s -count 5 ./core/fold/
  go test -run XXX -bench . -benchtime 2s -count 5 ./node/verify/

Thanks to kenyfran for running the benchmarks and posting the numbers. They exposed a real problem, and we got two things wrong.

1. The "parallel" label was wrong. The "1,963 ms to verify (parallel)" figure in the first post was measured on a single core. A node spreads that work across all of its cores, so the real time was shorter than what we published.

2. More cores were not helping. As your numbers showed, going from 4 to 8 workers gained almost nothing. The design is not the cause: every transaction can be checked on its own, so the work splits across cores. Our implementation was the cause. One of the extra security checks on signatures was written in a way that ran about 10 times slower than necessary. It also filled memory with temporary data, and cleaning that up kept pausing every core at once. Adding cores therefore did not add throughput.

We fixed it without changing any protocol rule. Every transaction is accepted or rejected exactly as before, and the tests check that on thousands of cases.

Issue: #42
Fix: merge request !48

New numbers for checking a block of 2,900 transactions. These are estimates: we measured with 1 to 6 cores on a machine that was also running other work.

Code:

Cores   Before    After
1       2.35 s    0.47 s
2       1.31 s    0.25 s
4       0.80 s    0.15 s
6       0.78 s    0.11 s

On 6 cores that is about 7x faster: roughly 25,000 transactions checked per second instead of 3,700. Signature checking alone is about 5x faster per core. More cores now help: 6 cores are 4.2x faster than 1, where before it stalled at 3x. There is still some room left, and we are working on it.

We will update the first post with the corrected numbers. If you can re-run the benchmarks after the fix is merged, we'd be glad to see your results.

[kaspa_grin]

I created a Telegram group to make it convenient for everyone to communicate and learn.


https://t.me/+ufeCItfHJWU3ZjBl