Today, something happened that I did not expect.
I was working on a completely unrelated mobile application, deep into implementation details, when a small architectural insight suddenly clicked. It was nothing spectacular on its own, just a clean solution to a problem. But it was a problem I had struggled with for years while working on ZooBC.
I stopped. Literally stopped coding. I stared at the screen for a long moment, and in that silence, I felt something I had not felt in a very long time. Clarity. Not emotional nostalgia, not regret, but technical clarity.
Today, I dropped everything I was working on and went back to ZooBC.
The original ZooBC vision still makes sense to me. Proof of Participation is still a strong idea. Rewarding consistent, honest participation instead of raw computational power or token accumulation feels even more relevant today than it did years ago. Concepts like spine blocks for fast synchronization, a node registry to limit centralization, and receipts as cryptographic proof of participation have aged better than I expected.
What has not aged well is the implementation.
Working again with the original ZooBC codebase, written in Go between 2019 and 2021, made its limitations impossible to ignore. Transaction validation logic is spread across too many packages. Consensus timing is buried inside nested conditionals that are hard to reason about. Module boundaries are blurred, and every new feature seems to require understanding half of the system. Even worse, nodes tend to slowly degrade over time, often dying after running continuously for a couple of months.
Today, it became clear to me that the problem was never the idea. The problem was the foundation.
So today, I made a decision I have been avoiding for years. ZooBC needs to be rebuilt from scratch.
Not refactored. Not patched. Rebuilt.
And this time, in C++.
The choice is not about nostalgia or personal preference. It is about control. Blockchain nodes need predictable performance. They cannot afford garbage collector pauses or opaque memory behavior during critical consensus windows. C++ gives me direct control over memory, cache behavior, and threading, which is exactly what this system needs.
Portability matters too. The same C++ code can run on cloud servers, Raspberry Pis, and everything in between. One codebase, consistent behavior, no surprises.
There is also something liberating about the constraints C++ imposes. Explicit ownership and lifecycle management force architectural clarity. When you can see exactly how resources are managed, reasoning about the system becomes possible again.
The existing Go implementation will not be wasted. It becomes the reference. Every algorithm, constant, and edge case already exists in working code. I am not starting from zero. I am starting from understanding.
I have no idea yet how long this will take. Probably months. There is no team, no roadmap, no launch date, and no promises. Just me, the code, and a vision that refuses to die.
Will I be able to make it this time? I honestly do not know.
But today, for the first time in four years, I believe I might build something truly amazing again.
If you are curious enough, follow along.
