Application owns a ledger-forming component, a p2p “overlay” component for connecting to peers and flooding messages between peers, a set-synchronization component for arriving at likely-in-sync candidate transaction sets, a transaction processing component for applying a consensus transaction set to the ledger, a crypto component for confirming signatures and hashing results, and a database component for persisting ledger changes. Two slightly-obscurely-named components are:
“BucketList”, stored in the directory “bucket”: the in-memory and on-disk linear history and ledger form that is hashed. A specific arrangement of concatenations-of-XDR. Organized around “temporal buckets”. Entries tending to stay in buckets grouped by how frequently they change.
HCP — “HcNet Consensus Protocol”, the component implementing the consensus algorithm.
Validators are kept as simple as possible and offload as much responsibility as they can to other parts of the system. In particular, validators do not store or serve long-term history archives; they do not operate a transactional (on disk) store for the “current state of the ledger”; they do not serve public HTTP requests directly. These roles are offloaded to servers that are better suited to these tasks, for which there are existing/better software stacks; validators should have an “even” and predictable system-load profile.
Validators are also kept as stateless as possible keeping disk and memory constraints in mind.
Set of core validator nodes. Running hcnet-core only. Tasked with:
SQL DB nodes. One per validator (or one + failover, however we make an SQL server sufficiently safe, eg. RDS). Directly associated with that validator. Tasked with:
Set of public HTTP nodes. Not running hcnet-core. Running apache/nginx/node/HTTP stack of choice. Flexible. Tasked with:
History archives. Long term blob storage in S3/GCS/Azure. Tasked with:
Support Agent
*Powered by HashCash