Daemons

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:

  • BlockGenerator daemon

    Generates new blocks.

  • BlockCollections daemon

    Downloads new blocks from other nodes.

  • Confirmations daemon

    Confirms that blocks present at the node are also present at the majority of other nodes.

  • Disseminator daemon

    Distributes transactions and blocks to other full nodes.

  • QueueParserBlocks daemon

    Processes blocks from the block queue. The block queue contains blocks from other nodes.

    Block processing logic is the same as BlockCollections daemon.

  • QueueParserTx daemon

    Validates transactions from the transaction queue.

  • Notificator daemon

    Sends notifications to users.

  • Scheduler daemon

    Runs contracts on schedule.

Regular node daemons

A regular node (a node that only sends transactions) runs the following backend daemons:

BlockCollections daemon

BlockCollections daemon downloads blocks and synchronizes the blockchain with other network nodes.

Blockchain synchronization

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.

Fork resolution

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.

Tables

BlockCollections daemon uses the following tables:

  • block_chain (writes received blocks)
  • config
  • full_nodes
  • main_lock
  • node_public_key
  • transactions
  • transactions_status
  • info_block

Database lock

Yes.

Requests

BlockCollections daemon makes the following requests to other daemons:

  • Type 10 to all full nodes (maximum block number).
  • Type 7 to a node with maximum block number (block data).

BlockGenerator daemon

BlockGenerator daemon generates new blocks.

Scheduling

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.

Block generation

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.

Tables

BlockGenerator daemon uses the following tables:

  • block_chain (saves new blocks)
  • config
  • system_recognized_states
  • full_nodes
  • main_lock
  • node_public_key
  • transactions
  • transactions_status
  • info_block
  • incorrect_tx

Database lock

Yes.

Requests

BlockGenerator daemon makes no requests to other daemons.

Disseminator daemon

Disseminator daemon sends transactions and blocks to full nodes.

Regular node

When working at a regular node, the daemon sends transactions generated by its node to all full nodes.

Full node

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.

Tables

Disseminator daemon uses the following tables:

  • config
  • system_recognized_states
  • full_nodes
  • transactions

Database lock

No.

Requests

Disseminator daemon makes the following requests to other daemons:

  • Type 1 to full nodes (transaction and block hashes).
  • Type 2 from full nodes (transaction data).

Confirmations daemon

Confirmations daemon checks that all blocks from its node are present at the majority of other nodes.

Block confirmation

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.

Tables

Confirmations daemon uses the following tables:

  • confirmation
  • info_block
  • full_nodes

Database lock

No.

Requests

Confirmation daemon makes the following requests to other daemons:

  • Type 4 to full nodes (block hash request).

Tcpcerver protocol

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.

Request types

Every request has a type definded by first two bytes of a request.

Type 1

Request sender

Disseminator daemon sends this request.

Request data

Transaction and block hashes.

Request handling

Block hashes are added to blocks queue.

Transaction hashes are analyzed and transactions that aren’t already present at the node are selected.

Response

None. Type 2 requests are made after handling this request.

Type 2

Request sender

Disseminator daemon sends this request.

Request data

Transaction data, including data size.

  • data_size (4 bytes)

    Size of the transaction data, in bytes.

  • data (data_size bytes)

    Transaction data.

Request handling

Transaction is validated and added to the transactions queue.

Response

None.

Type 4

Request sender

Confirmations daemon sends this request.

Request data

Block ID.

Response

Block hash.

If a block with this ID is not present, 0 value is returned.

Type 7

Request sender

BlockCollections daemon sends this request.

Request data

Block ID.

  • block_id (4 bytes)

Response

Block data, including data size.

  • data_size (4 bytes)

    Size of the block data, in bytes.

  • data (data_size bytes)

    Block data.

If a block with this ID is not present, connection is closed.

Type 10

Request sender

BlockCollections daemon sends this request.

Request data

None.

Response

Block identifier.

  • block_id (4 bytes)