dash/src/masternode/meta.cpp

139 lines
4.3 KiB
C++
Raw Normal View History

// Copyright (c) 2014-2022 The Dash Core developers
// Distributed under the MIT/X11 software license, see the accompanying
// file COPYING or http://www.opensource.org/licenses/mit-license.php.
#include <masternode/meta.h>
refactor: decouple db hooks from CFlatDB-based C*Manager objects, migrate to *Store structs (#5555) ## Motivation As highlighted in https://github.com/dashpay/dash-issues/issues/52, decoupling of `CFlatDB`-interacting components from managers of objects like `CGovernanceManager` and `CSporkManager` is a key task for achieving deglobalization of Dash-specific components. The design of `CFlatDB` as a flat database agent relies on hooking into the object's state its meant to load and store, using its (de)serialization routines and other miscellaneous functions (notably, without defining an interface) to achieve those ends. This approach was taken predominantly for components that want a single-file cache. Because of the method it uses to hook into the object (templates and the use of temporary objects), it explicitly prevented passing arguments into the object constructor, an explicit requirement for storing references to other components during construction. This, in turn, created an explicit dependency on those same components being available in the global context, which would block the backport of bitcoin#21866, a requirement for future backports meant to achieve parity in `assumeutxo` support. The design of these objects made no separation between persistent (i.e. cached) and ephemeral (i.e. generated/fetched during initialization or state transitions) data and the design of `CFlatDB` attempts to "clean" the database by breaching this separation and attempting to access this ephemeral data. This might be acceptable if it is contained within the manager itself, like `CSporkManager`'s `CheckAndRemove()` but is utterly unacceptable when it relies on other managers (that, as a reminder, are only accessible through the global state because of restrictions caused by existing design), like `CGovernanceManager`'s `UpdateCachesAndClean()`. This pull request aims to separate the `CFlatDB`-interacting portions of these managers into a struct, with `CFlatDB` interacting only with this struct, while the manager inherits the struct and manages load/store/update of the database through the `CFlatDB` instance initialized within its scope, though the instance only has knowledge of what is exposed through the limited parent struct. ## Additional information * As regards to existing behaviour, `CFlatDB` is written entirely as a header as it relies on templates to specialize itself for the object it hooks into. Attempting to split the logic and function definitions into separate files will require you to explicitly define template specializations, which is tedious. * `m_db` is defined as a pointer as you cannot instantiate a forward-declared template (see [this Stack Overflow answer](https://stackoverflow.com/a/12797282) for more information), which is done when defined as a member in the object scope. * The conditional cache flush predicating on RPC _not_ being in the warm-up state has been replaced with unconditional flushing of the database on object destruction (@UdjinM6, is this acceptable?) ## TODOs This is a list of things that aren't within the scope of this pull request but should be addressed in subsequent pull requests * [ ] Definition of an interface that `CFlatDB` stores are expected to implement * [ ] Lock annotations for all potential uses of members protected by the `cs` mutex in each manager object and store * [ ] Additional comments documenting what each function and member does * [ ] Deglobalization of affected managers --------- Co-authored-by: Kittywhiskers Van Gogh <63189531+kittywhiskers@users.noreply.github.com>
2023-09-24 16:50:21 +02:00
#include <flat-database.h>
#include <util/time.h>
#include <sstream>
refactor: decouple db hooks from CFlatDB-based C*Manager objects, migrate to *Store structs (#5555) ## Motivation As highlighted in https://github.com/dashpay/dash-issues/issues/52, decoupling of `CFlatDB`-interacting components from managers of objects like `CGovernanceManager` and `CSporkManager` is a key task for achieving deglobalization of Dash-specific components. The design of `CFlatDB` as a flat database agent relies on hooking into the object's state its meant to load and store, using its (de)serialization routines and other miscellaneous functions (notably, without defining an interface) to achieve those ends. This approach was taken predominantly for components that want a single-file cache. Because of the method it uses to hook into the object (templates and the use of temporary objects), it explicitly prevented passing arguments into the object constructor, an explicit requirement for storing references to other components during construction. This, in turn, created an explicit dependency on those same components being available in the global context, which would block the backport of bitcoin#21866, a requirement for future backports meant to achieve parity in `assumeutxo` support. The design of these objects made no separation between persistent (i.e. cached) and ephemeral (i.e. generated/fetched during initialization or state transitions) data and the design of `CFlatDB` attempts to "clean" the database by breaching this separation and attempting to access this ephemeral data. This might be acceptable if it is contained within the manager itself, like `CSporkManager`'s `CheckAndRemove()` but is utterly unacceptable when it relies on other managers (that, as a reminder, are only accessible through the global state because of restrictions caused by existing design), like `CGovernanceManager`'s `UpdateCachesAndClean()`. This pull request aims to separate the `CFlatDB`-interacting portions of these managers into a struct, with `CFlatDB` interacting only with this struct, while the manager inherits the struct and manages load/store/update of the database through the `CFlatDB` instance initialized within its scope, though the instance only has knowledge of what is exposed through the limited parent struct. ## Additional information * As regards to existing behaviour, `CFlatDB` is written entirely as a header as it relies on templates to specialize itself for the object it hooks into. Attempting to split the logic and function definitions into separate files will require you to explicitly define template specializations, which is tedious. * `m_db` is defined as a pointer as you cannot instantiate a forward-declared template (see [this Stack Overflow answer](https://stackoverflow.com/a/12797282) for more information), which is done when defined as a member in the object scope. * The conditional cache flush predicating on RPC _not_ being in the warm-up state has been replaced with unconditional flushing of the database on object destruction (@UdjinM6, is this acceptable?) ## TODOs This is a list of things that aren't within the scope of this pull request but should be addressed in subsequent pull requests * [ ] Definition of an interface that `CFlatDB` stores are expected to implement * [ ] Lock annotations for all potential uses of members protected by the `cs` mutex in each manager object and store * [ ] Additional comments documenting what each function and member does * [ ] Deglobalization of affected managers --------- Co-authored-by: Kittywhiskers Van Gogh <63189531+kittywhiskers@users.noreply.github.com>
2023-09-24 16:50:21 +02:00
std::unique_ptr<CMasternodeMetaMan> mmetaman;
refactor: decouple db hooks from CFlatDB-based C*Manager objects, migrate to *Store structs (#5555) ## Motivation As highlighted in https://github.com/dashpay/dash-issues/issues/52, decoupling of `CFlatDB`-interacting components from managers of objects like `CGovernanceManager` and `CSporkManager` is a key task for achieving deglobalization of Dash-specific components. The design of `CFlatDB` as a flat database agent relies on hooking into the object's state its meant to load and store, using its (de)serialization routines and other miscellaneous functions (notably, without defining an interface) to achieve those ends. This approach was taken predominantly for components that want a single-file cache. Because of the method it uses to hook into the object (templates and the use of temporary objects), it explicitly prevented passing arguments into the object constructor, an explicit requirement for storing references to other components during construction. This, in turn, created an explicit dependency on those same components being available in the global context, which would block the backport of bitcoin#21866, a requirement for future backports meant to achieve parity in `assumeutxo` support. The design of these objects made no separation between persistent (i.e. cached) and ephemeral (i.e. generated/fetched during initialization or state transitions) data and the design of `CFlatDB` attempts to "clean" the database by breaching this separation and attempting to access this ephemeral data. This might be acceptable if it is contained within the manager itself, like `CSporkManager`'s `CheckAndRemove()` but is utterly unacceptable when it relies on other managers (that, as a reminder, are only accessible through the global state because of restrictions caused by existing design), like `CGovernanceManager`'s `UpdateCachesAndClean()`. This pull request aims to separate the `CFlatDB`-interacting portions of these managers into a struct, with `CFlatDB` interacting only with this struct, while the manager inherits the struct and manages load/store/update of the database through the `CFlatDB` instance initialized within its scope, though the instance only has knowledge of what is exposed through the limited parent struct. ## Additional information * As regards to existing behaviour, `CFlatDB` is written entirely as a header as it relies on templates to specialize itself for the object it hooks into. Attempting to split the logic and function definitions into separate files will require you to explicitly define template specializations, which is tedious. * `m_db` is defined as a pointer as you cannot instantiate a forward-declared template (see [this Stack Overflow answer](https://stackoverflow.com/a/12797282) for more information), which is done when defined as a member in the object scope. * The conditional cache flush predicating on RPC _not_ being in the warm-up state has been replaced with unconditional flushing of the database on object destruction (@UdjinM6, is this acceptable?) ## TODOs This is a list of things that aren't within the scope of this pull request but should be addressed in subsequent pull requests * [ ] Definition of an interface that `CFlatDB` stores are expected to implement * [ ] Lock annotations for all potential uses of members protected by the `cs` mutex in each manager object and store * [ ] Additional comments documenting what each function and member does * [ ] Deglobalization of affected managers --------- Co-authored-by: Kittywhiskers Van Gogh <63189531+kittywhiskers@users.noreply.github.com>
2023-09-24 16:50:21 +02:00
const std::string MasternodeMetaStore::SERIALIZATION_VERSION_STRING = "CMasternodeMetaMan-Version-3";
CMasternodeMetaMan::CMasternodeMetaMan(bool load_cache) :
m_db{std::make_unique<db_type>("mncache.dat", "magicMasternodeCache")},
is_valid{
[&]() -> bool {
assert(m_db != nullptr);
return load_cache ? m_db->Load(*this) : m_db->Store(*this);
}()
}
{
}
CMasternodeMetaMan::~CMasternodeMetaMan()
{
if (!is_valid) return;
m_db->Store(*this);
}
UniValue CMasternodeMetaInfo::ToJson() const
{
UniValue ret(UniValue::VOBJ);
int64_t now = GetTime<std::chrono::seconds>().count();
ret.pushKV("lastDSQ", nLastDsq);
ret.pushKV("mixingTxCount", nMixingTxCount);
ret.pushKV("outboundAttemptCount", outboundAttemptCount);
ret.pushKV("lastOutboundAttempt", lastOutboundAttempt);
ret.pushKV("lastOutboundAttemptElapsed", now - lastOutboundAttempt);
ret.pushKV("lastOutboundSuccess", lastOutboundSuccess);
ret.pushKV("lastOutboundSuccessElapsed", now - lastOutboundSuccess);
return ret;
}
void CMasternodeMetaInfo::AddGovernanceVote(const uint256& nGovernanceObjectHash)
{
LOCK(cs);
// Insert a zero value, or not. Then increment the value regardless. This
// ensures the value is in the map.
const auto& pair = mapGovernanceObjectsVotedOn.emplace(nGovernanceObjectHash, 0);
pair.first->second++;
}
void CMasternodeMetaInfo::RemoveGovernanceObject(const uint256& nGovernanceObjectHash)
{
LOCK(cs);
// Whether or not the govobj hash exists in the map first is irrelevant.
mapGovernanceObjectsVotedOn.erase(nGovernanceObjectHash);
}
CMasternodeMetaInfoPtr CMasternodeMetaMan::GetMetaInfo(const uint256& proTxHash, bool fCreate)
{
LOCK(cs);
auto it = metaInfos.find(proTxHash);
if (it != metaInfos.end()) {
return it->second;
}
if (!fCreate) {
return nullptr;
}
it = metaInfos.emplace(proTxHash, std::make_shared<CMasternodeMetaInfo>(proTxHash)).first;
return it->second;
}
// We keep track of dsq (mixing queues) count to avoid using same masternodes for mixing too often.
// This threshold is calculated as the last dsq count this specific masternode was used in a mixing
// session plus a margin of 20% of masternode count. In other words we expect at least 20% of unique
// masternodes before we ever see a masternode that we know already mixed someone's funds earlier.
int64_t CMasternodeMetaMan::GetDsqThreshold(const uint256& proTxHash, int nMnCount)
{
auto metaInfo = GetMetaInfo(proTxHash);
if (metaInfo == nullptr) {
// return a threshold which is slightly above nDsqCount i.e. a no-go
return nDsqCount + 1;
}
return metaInfo->GetLastDsq() + nMnCount / 5;
}
void CMasternodeMetaMan::AllowMixing(const uint256& proTxHash)
{
auto mm = GetMetaInfo(proTxHash);
nDsqCount++;
mm->nLastDsq = nDsqCount.load();
mm->nMixingTxCount = 0;
}
void CMasternodeMetaMan::DisallowMixing(const uint256& proTxHash)
{
auto mm = GetMetaInfo(proTxHash);
mm->nMixingTxCount++;
}
bool CMasternodeMetaMan::AddGovernanceVote(const uint256& proTxHash, const uint256& nGovernanceObjectHash)
{
auto mm = GetMetaInfo(proTxHash);
mm->AddGovernanceVote(nGovernanceObjectHash);
return true;
}
void CMasternodeMetaMan::RemoveGovernanceObject(const uint256& nGovernanceObjectHash)
{
LOCK(cs);
for(const auto& p : metaInfos) {
p.second->RemoveGovernanceObject(nGovernanceObjectHash);
}
}
std::vector<uint256> CMasternodeMetaMan::GetAndClearDirtyGovernanceObjectHashes()
{
LOCK(cs);
std::vector<uint256> vecTmp = std::move(vecDirtyGovernanceObjectHashes);
vecDirtyGovernanceObjectHashes.clear();
return vecTmp;
}
refactor: decouple db hooks from CFlatDB-based C*Manager objects, migrate to *Store structs (#5555) ## Motivation As highlighted in https://github.com/dashpay/dash-issues/issues/52, decoupling of `CFlatDB`-interacting components from managers of objects like `CGovernanceManager` and `CSporkManager` is a key task for achieving deglobalization of Dash-specific components. The design of `CFlatDB` as a flat database agent relies on hooking into the object's state its meant to load and store, using its (de)serialization routines and other miscellaneous functions (notably, without defining an interface) to achieve those ends. This approach was taken predominantly for components that want a single-file cache. Because of the method it uses to hook into the object (templates and the use of temporary objects), it explicitly prevented passing arguments into the object constructor, an explicit requirement for storing references to other components during construction. This, in turn, created an explicit dependency on those same components being available in the global context, which would block the backport of bitcoin#21866, a requirement for future backports meant to achieve parity in `assumeutxo` support. The design of these objects made no separation between persistent (i.e. cached) and ephemeral (i.e. generated/fetched during initialization or state transitions) data and the design of `CFlatDB` attempts to "clean" the database by breaching this separation and attempting to access this ephemeral data. This might be acceptable if it is contained within the manager itself, like `CSporkManager`'s `CheckAndRemove()` but is utterly unacceptable when it relies on other managers (that, as a reminder, are only accessible through the global state because of restrictions caused by existing design), like `CGovernanceManager`'s `UpdateCachesAndClean()`. This pull request aims to separate the `CFlatDB`-interacting portions of these managers into a struct, with `CFlatDB` interacting only with this struct, while the manager inherits the struct and manages load/store/update of the database through the `CFlatDB` instance initialized within its scope, though the instance only has knowledge of what is exposed through the limited parent struct. ## Additional information * As regards to existing behaviour, `CFlatDB` is written entirely as a header as it relies on templates to specialize itself for the object it hooks into. Attempting to split the logic and function definitions into separate files will require you to explicitly define template specializations, which is tedious. * `m_db` is defined as a pointer as you cannot instantiate a forward-declared template (see [this Stack Overflow answer](https://stackoverflow.com/a/12797282) for more information), which is done when defined as a member in the object scope. * The conditional cache flush predicating on RPC _not_ being in the warm-up state has been replaced with unconditional flushing of the database on object destruction (@UdjinM6, is this acceptable?) ## TODOs This is a list of things that aren't within the scope of this pull request but should be addressed in subsequent pull requests * [ ] Definition of an interface that `CFlatDB` stores are expected to implement * [ ] Lock annotations for all potential uses of members protected by the `cs` mutex in each manager object and store * [ ] Additional comments documenting what each function and member does * [ ] Deglobalization of affected managers --------- Co-authored-by: Kittywhiskers Van Gogh <63189531+kittywhiskers@users.noreply.github.com>
2023-09-24 16:50:21 +02:00
std::string MasternodeMetaStore::ToString() const
{
std::ostringstream info;
LOCK(cs);
info << "Masternodes: meta infos object count: " << (int)metaInfos.size() <<
", nDsqCount: " << (int)nDsqCount;
return info.str();
}