This section describes how Apla nodes interact with each other from the technical standpoint.
About the backend daemons¶
Apla backend is go-apla. It operates at every network node. Backend daemons perform individual functions of the backend and support Apla blockchain protocols. The daemons distribute blocks and transactions in the blockchain network, generate new blocks, validate received blocks and transactions, and resolve blockchain forks if they occur.
Full node daemons¶
A full node (a node that can generate new blocks and send transactions) runs the following backend daemons:
Generates new blocks.
Downloads new blocks from other nodes.
Confirms that blocks present at the node are also present at the majority of other nodes.
Distributes transactions and blocks to other full nodes.
Processes blocks from the block queue. The block queue contains blocks from other nodes.
Block processing logic is the same as BlockCollections daemon.
Validates transactions from the transaction queue.
Sends notifications to users.
Runs contracts on schedule.
BlockCollections daemon downloads blocks and synchronizes the blockchain with other network nodes.
BlockCollections daemon synchronizes blockchain by determining the maximum block number in the blockchain network, requesting new blocks, and resolving forks in the blockchain.
Blockchain update check¶
BlockCollections daemon sends a request for the current block ID to all full nodes.
If the current block ID of the daemon’s node is less than the current block ID of any full node, then the blockchain is considered outdated.
Downloading new blocks¶
The node that returned the maximum current block number is considered to be the most up-to-date node.
The daemon downloads all blocks that aren’t already known from it.
If a fork is detected in the blockchain, the daemon walks the fork backwards by downloading all blocks up to the common ancestor block.
When the common ancestor block is found, the rollback is performed on the daemon’s node blockchain, and correct blocks are added to the blockchain up to the newest block.
BlockCollections daemon uses the following tables:
- block_chain (writes received blocks)
BlockGenerator daemon generates new blocks.
BlockGenerator daemon schedules new block generation by analyzing the newest block in the blockchain.
New block can be generated if the following conditions are true:
- A node that generated the newest block is located next to the daemon’s node in the list of validating nodes.
- Minimum amount of time has passed since the newest block was generated.
When a new block is generated, the daemon includes all new transactions in it. These transactions can be received from other nodes (Disseminator daemon), or generated by daemon’s node. The resulting block is saved in the local database.
BlockGenerator daemon uses the following tables:
- block_chain (saves new blocks)
BlockGenerator daemon makes no requests to other daemons.
Disseminator daemon sends transactions and blocks to full nodes.
When working at a regular node, the daemon sends transactions generated by its node to all full nodes.
When working at a full node, the daemon sends hashes of generated blocks and transactions to all full nodes.
The full nodes then respond with requests for transactions that are unknown to their nodes. The daemon sends full transaction data in response.
Disseminator daemon uses the following tables:
Confirmations daemon checks that all blocks from its node are present at the majority of other nodes.
A block is considered confirmed when a number of nodes in a network have confirmed this block.
The daemon confirms all blocks, one by one, starting from the first block in the database that is not confirmed at the moment.
Each block is confirmed in this way:
- Confirmations daemon sends a request to all full nodes. This request contrains the ID of the block that is being confirmed.
- All full nodes respond with a hash of this block.
- If a hash from a response matches the hash of the block present at daemon’s node, then the confirmations counter is increased. If hashes don’t match, the disconfirmations counter is increased.
Confirmations daemon uses the following tables:
A TCP server (tcpserver) works at full nodes. The TCP server uses a binary protocol over TCP to handle requests from BlockCollections, Disseminator, and Confirmation daemons.
Every request has a type definded by first two bytes of a request.
Transaction and block hashes.
Block hashes are added to blocks queue.
Transaction hashes are analyzed and transactions that aren’t already present at the node are selected.
Transaction data, including data size.
data_size (4 bytes)
Size of the transaction data, in bytes.
data (data_size bytes)
Transaction is validated and added to the transactions queue.
If a block with this ID is not present,
0 value is returned.
- block_id (4 bytes)
Block data, including data size.
data_size (4 bytes)
Size of the block data, in bytes.
data (data_size bytes)
If a block with this ID is not present, connection is closed.