May 3, 2025

Completed the last open issue. The entire stack is essentially lock-free, with synchronization primitives buried in C++ std lib (concurrent loops), ASIO, ZeroMQ, and our store primitives. But I used a simple std::mutex with std::unique_lock to synchronize between the candidate chain and confirmed chain. Basically we cannot allow popping of blocks from the candidate chain during the organization of blocks into the confirmed chain, since the candidate chain provides order for the confirmed chain. It would be possible to push this into a store atomic read of the full candidate branch, which hash the slight drawback of holding this set in a redundant temporary structure during organization. This would have to be captured before determining if the branch is strong. There would be a very small performance hit, but that would allow the implementation to not expose any synchronization primitives at the application layer.