The network component provides peer-to-peer communication primitives to other components of a validator. Peer-to-peer protocol is to synchronize nodes securely and efficiently. Highest level sits the Network Plugin, which exchanges messages between the node and its peers to sync blocks and transactions. To achieve this overarching goal, the system delegates functionality into four main components:
Network Plugin: defines the protocol to sync blocks and forward transactions between peers.
Chain Controller: dispatches/manages blocks and transactions received, within the node.
Network Serializer: serializes messages, blocks, and transactions for network transmission.
Local Network: holds the node’s local copy of the blockchain, including reversible blocks.
RPC — Allows sending/receiving RPCs to/from other peers. It notifies upstream handlers about inbound RPCs. The upstream handler is passed a channel through which can send a serialized response to the caller.
Health Checker — Performs periodic liveness probes to ensure the health of a peer/connection. It resets the connection with the peer if a configurable number of probes fail in succession. Probes currently fail on a configurable static timeout.
Direct Send — Allows sending/receiving messages to/from remote peers. It notifies upstream handlers of inbound messages.
The Plasma data persistence layer, peer-to-peer networking, and contract code scheduling. For development environments, nodeos enables you to set up a single node blockchain network. Ionode offers a wide range of features through plugins which can be enabled or disabled at start time via the command line parameters or configuration files. Usage - Configuring and using, node setups/environments:
Plugins - Using plugins, plugin options, mandatory vs. optional.
Replays - Replaying the chain from a snapshot or a blocks.log file.
Logging - Logging config/usage, loggers, appenders, logging levels.
Troubleshooting - Common troubleshooting questions.
Ledger history is represented by a Merkle accumulator. Each time a transaction T is added to the blockchain, a Blockchain info o structure containing the transaction T, the root hash for the state Merkle tree after the execution of T and the root hash for the event Merkle tree generated by T is appended to the accumulator. The ledger state at each version is represented by a sparse Merkle tree that has the state of all accounts. The keys are the 256-bit hash of the addresses, and their corresponding value is the state of the entire account serialized as a binary blob. While a tree of size 2^256 is an intractable representation, subtrees consisting entirely of empty nodes are replaced with a placeholder value, and subtrees consisting of exactly one leaf are replaced with a single node.
The Ledger History State is useful for capturing historical data about the blockchain state. The History state receives blockchain data from other connected nodes and caches the data into files. The Ledger listens on a socket for applications to connect and sends data back based on the plugin options specified when starting ionode.
PLK - key vault service for Ionode Database fillers connect - listen to the ledger and write to the database of confirmed transactions.
PostgreSQL - PostgreSQL is a powerful, open source object-relational database system that uses and extends the SQL language combined with many features that safely store and scale the most complicated data workloads. The origins of PostgreSQL date back to 1986 as part of the POSTGRES project at the University of California at Berkeley and has more than 30 years of active development on the core platform.
RocksDB - RocksDB is very flexible, which is both good and bad. You can tune it for a variety of workloads and storage technologies. Inside of Facebook we use the same code base for in-memory workload, flash devices and spinning disks.
Hashicorp Vault - Secure, store and tightly control access to tokens, passwords, certificates, encryption keys for protecting secrets and other sensitive data using a UI, CLI, or HTTP API.