The core folder
The heart of the Blockchain Development Kit (BDK).
Last updated
The heart of the Blockchain Development Kit (BDK).
Last updated
This subchapter contains a brief overview of each one of the components inside the src/core folder.
The blockchain.h file contains the Blockchain and Syncer classes.
The Blockchain class acts as the mother class that unites all the other components described throughout the docs, including the Syncer. Think of it as "the power button on AppLayer's PC case" - its objective is to be the entry point of the system and act as a mediator for the other components, passing around data to each other, such as (but not limited to):
The global options singleton
The P2P connection manager
The database
The blockchain history/storage (for blocks and contract events)
The blockchain state (which contains the rdPoS protocol in itself)
The HTTP server
The consensus protocol
The Syncer class is responsible for syncing the blockchain with other nodes in the network, as well as handling proper transaction broadcasts and block creations (if the node happens to be a Validator).
The consensus.h file contains the Consensus class - responsible for processing blocks and transactions in the blockchain and applying the network's consensus rules into them.
The dump.h file contains the Dumpable, DumpManager and DumpWorker classes - together they are responsible for dumping the blockchain's components from memory to disk when required (e.g. blocks, transactions, contracts, the state itself, etc.)
Dumpable is an abstraction of a dumpable object - that is, any component that inherits it is able to dump itself to disk. All classes that inherit it must implement their own dumping routine accordingly.
DumpManager is the class that manages a list of Dumpable components in the blockchain, iterating through each of them and dumping them one by one when told to.
DumpWorker acts as a worker thread for DumpManager, doing the actual work of dumping each Dumpable component sent by DumpManager in a separate thread. This allows for parallel dumps, speeding up the process significantly, which is important when there are many objects or particularly heavy ones (e.g. State) that need to be dumped ASAP without hanging the entire blockchain.
The rdpos.h file contains the rdPoS class - the implementation of the Random Deterministic Proof of Stake algorithm used by the AppLayer network - as well as the Validator class. rdPoS is also considered a smart contract (it derives from BaseContract), but as it is an essential part of the AppLayer core protocol, it remains in the core folder.
The state.h file contains the State class - an abstraction of the blockchain's current state of accounts, balances, nonces, transactions, token balances and deployed contracts at the current block in the network, responsible for owning and maintaining all of those and a few other shared inner variables.
A node's state and its data can only be altered through the process of block creation, either by creating a block itself, or receiving one from the network. In AppLayer's case, the class is often used for querying account data (current balance and nonce) and also processing and validating blocks and their transactions, as well as contract calls, following requirements such as (not limited to, but those are some of the most common):
Ensuring replay protection (e.g. checking if the transaction has already been validated)
Checking if the sender address exists and has enough balance to make the transaction
Checking if the sender address nonce is valid (if it matches what was sent in the transaction)
Checking if the transaction is not already in the mempool, thus avoiding double spends
The storage.h file contains the Storage class - an abstraction of the blockchain's history, storing and maintaining a collection of blocks approved and validated by the network, other nodes, or itself through time. Those blocks store transactions, contracts, accounts, emitted contract events (if the node is initialized with the RPC_TRACE indexing mode set) and other blockchain-related data. Said data can't be altered once it's in the blockchain, it can only be searched for or read from.
On node initialization, if there are no blocks (e.g. the blockchain was just deployed and initialized for the first time), a "genesis" block is automatically created and loaded in memory. The "latest" block is always kept in memory, with subsequent older blocks being dumped to and queried constantly from the database. This makes the blockchain lightweight memory-wise and extremely responsive.
Searching for and reading from blocks in history is done in several places in the system, so when the Storage and DB classes are working together, they act as the end point of the blockchain's operations history.
Not all functions from the class update the state. Check the docs for more info on that.
