Within the NodeContext
construction there are two members named chainman
and chain
. chainman
is occasion of ChainstateManager
and chain
is occasion of interfaces::Chain
. What’s the variations between these two? What’s the variations and why do we’d like each?
//! NodeContext struct containing references to chain state and connection
//! state.
//!
//! That is utilized by init, rpc, and check code to move object references round
//! with no need to declare the identical variables and parameters repeatedly, or
//! to make use of globals. Extra variables could possibly be added to this struct (notably
//! references to validation objects) to remove use of globals
//! and make code extra modular and testable. The struct is not meant to have
//! any member capabilities. It ought to simply be a set of references that may
//! be used with out pulling in undesirable dependencies or performance.
struct NodeContext {
//! libbitcoin_kernel context
std::unique_ptr<:context> kernel;
//! Init interface for initializing present course of and connecting to different processes.
interfaces::Init* init{nullptr};
std::unique_ptr addrman;
std::unique_ptr connman;
std::unique_ptr mempool;
std::unique_ptr netgroupman;
std::unique_ptr fee_estimator;
std::unique_ptr peerman;
std::unique_ptr chainman;
std::unique_ptr banman;
ArgsManager* args{nullptr}; // At present a uncooked pointer as a result of the reminiscence is just not managed by this struct
std::unique_ptr<:chain> chain;
//! Checklist of all chain purchasers (pockets processes or different shopper) linked to node.
std::vector<:unique_ptr>> chain_clients;
//! Reference to chain shopper that ought to used to load or create wallets
//! opened by the gui.
interfaces::WalletLoader* wallet_loader{nullptr};
std::unique_ptr scheduler;
std::perform rpc_interruption_point = [] {};
//! Declare default constructor and destructor that aren't inline, so code
//! instantiating the NodeContext struct does not have to #embrace class
//! definitions for all of the unique_ptr members.
NodeContext();
~NodeContext();
};
My assumptions are:
ChainstateManager
managesChainstate
s that arem_ibd_chainstate
andm_snapshot_chainstate
.Chainstate
has all knowledge of a sequence.
Whereas interfaces::Chain
is used for exterior parts akin to pockets, the one potential cause that involves my thoughts is that the chain
member is for exterior customers of bitcoind
. And by this truth, the implementation of interface::chain
have to be solely a easy wrapper over the ChainstateManager
, as a result of I believe all logic is applied there.