These past two weeks, ZooBC stops being about correctness and starts being about reality.
Getting things right is only the first step. Once the system behaves correctly, the next question becomes unavoidable: how fast can it do it, and how predictably? A blockchain that works but feels sluggish will never survive real-world conditions.
So this phase is about tightening screws.
Not rewriting logic.
Not changing behavior.
Just making the same system move with less friction.
Finding the First Bottleneck
The first thing I look at is database access.
The initial implementation is clean and correct, but naive. Too many small queries. Too many round trips. Too many implicit fsyncs. It works, but it wastes time in places where time adds up quickly.
Originally, transaction execution looks like this:
// Before: Individual queries per transaction
for (const auto& tx : block.transactions) {
ExecuteTransaction(tx); // ~5 queries each
}
Every transaction quietly pays the cost of its own database interaction. That is fine for a few transactions. It is not fine for a block full of them.
The fix is simple, but powerful: batch operations inside a single database transaction.
// After: Batched within transaction
db_->BeginTransaction();
for (const auto& tx : block.transactions) {
ExecuteTransaction(tx); // Queries batched
}
db_->Commit(); // Single fsync
One transaction.
One fsync.
Same correctness, far less overhead.
Stop Asking the Same Question Repeatedly
The next improvement comes from watching the system ask itself the same questions over and over again.
What is the latest block?
Which nodes are currently active?
These values change infrequently, yet they are queried constantly. The solution is obvious once you see it.
The blockchain now caches the latest block and the active node list in memory. These caches are invalidated explicitly when the chain updates or when the node registry changes. No stale data. No guessing.
Hot data stays hot.
Cold data stays in the database.
Memory Is Not Free
C++ makes memory management explicit, which is both a blessing and a responsibility.
Transaction objects are created and destroyed constantly. Left unchecked, this leads to a lot of allocation churn. Even with a good allocator, calling malloc and free thousands of times per second adds unnecessary overhead.
The fix here is memory pooling.
Instead of allocating new transaction objects every time, a pool reuses previously allocated memory. Objects are reset and recycled. The logic stays the same, but the allocator stops being a bottleneck.
This is not glamorous optimization. It is the kind that only shows up in profiling graphs and long-running tests.
Which is exactly where it matters.
Parallel Where It Makes Sense
Not everything should be parallelized. But some things clearly should.
Transaction signature verification is one of them.
Ed25519 verification is CPU-intensive and completely independent per transaction. There are no shared resources, no ordering constraints, no side effects. It is the perfect candidate for parallel execution.
So validation now uses a pool of worker threads to verify signatures concurrently. Each transaction is checked independently, and the results are collected before execution continues.
The logic stays deterministic.
The work gets done faster.
Measuring the Impact
The results are immediately visible.
On test hardware, block processing time drops from roughly 200 milliseconds to about 80 milliseconds. That is not a theoretical improvement. It is something I can see directly in logs and monitors.
Memory usage is also noticeably lower. Roughly half of what the Go implementation consumes in similar scenarios. Explicit resource management does not forgive mistakes, but when done right, it pays off.
Quiet Satisfaction
There is no new feature to show this week. No protocol change. No screenshot-worthy UI.
Just a system that does the same work with less effort.
Late at night, sitting in my lab, I watch blocks flow through faster, smoother, with fewer spikes and stalls. This is the kind of progress that does not announce itself loudly, but it is the kind that makes everything else possible.
Speed matters.
And ZooBC is starting to feel light on its feet.
