<disclaimer> These notes are my understanding by looking at code. I may be wrong. Do not take my word for it, verify it yourself. Much of what is below is my opinion. As sometimes is the case, following good practices the wrong way can make a project worse. That is not what I’m talking about here.</disclaimer>
Recent versions (0.20ish) of Bitcoin Core attempt to reorganize logic into objects with somewhat related functionality. In my opinion, this is one of the best ways to reduce complexity. External components communicate with the object with well defined interface. This can lead to decoupling, which makes unintended side effects less likely.
I am focusing on the NodeContext object, as I believe this would be a big benefit for the Komodo core code. I am using this space for some notes on how Bitcoin Core broke up the object model. I hope this post will help remove some notes scribbled on paper on my desk. And who knows, it may be useful for someone else.
Breakdown of NodeContext
The NodeContext object acts as a container for many of the components needed by the bitcoin daemon. The majority of the objects are std::unique_ptr. This is a good choice, as copies are explicit. Below are the components within NodeContext:
- addrman – Address Manager, keeps track of peer addresses
- conman – Connection Manager – handles connections, banning, whitelists
- mempool – Transaction mempool – transactions that as yet are not part of a block
- fee_estimator
- peerman – Peer manager, includes a task scheduler and processes messages
- chainman – Chain Manager, manages chain state. References ibd, snapshot, and active (which is either the ibd or the snapshot)
- banman – Ban manager
- args – Configuration arguments
- chain – The actual chain. This handles blocks, and has a reference to the mempool.
- chain_clients – clients (i.e. a wallet) that need notification when the state of the chain changes.
- wallet_client – A special client that can create wallet addresses
- scheduler – helps handles tasks that should be delayed
- rpc_interruption_point – A lambda that handles any incoming RPC calls while the daemon is in the process of shutting down.
One of the largest refactoring challenges in Komodo is the large number of global variables. Pushing them into their respective objects (especially chainmain and args objects) will help get rid of many of those globals. This will help compartmentalize code and make unit tests easier.