Daemons¶
This section describes how GAChain nodes interact with each other from the technical standpoint.
About the backend daemons¶
GAChain backend is go-gachain. It operates at every network node. Backend daemons perform individual functions of the backend and support GAChain 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.
Validating node daemons¶
A Validating 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 validating 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.
Scheduler daemon
Runs contracts on schedule.
Full node daemons¶
A Full node (a node that only sends transactions) runs the following backend daemons:
- BlockCollections daemon
- Confirmations daemon
- Disseminator daemon
- QueueParserTx
- Scheduler
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 validating nodes.
If the current block ID of the daemon’s node is less than the current block ID of any validating 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
- transactions
- transactions_status
- info_block
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)
- transactions
- transactions_status
- info_block
Requests¶
BlockGenerator daemon makes no requests to other daemons.
Disseminator daemon¶
Disseminator daemon sends transactions and blocks to all validating nodes.
Full node¶
When working at a full node, the daemon sends transactions generated by its node to all validating nodes.
Validating node¶
When working at a validating node, the daemon sends hashes of generated blocks and transactions to all validating nodes.
The validating nodes then respond with requests for transactions that are unknown to their nodes. The daemon sends full transaction data in response.
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 validating nodes. This request contrains the ID of the block that is being confirmed.
- All validating 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.
Tcpscerver protocol¶
A TCP server (tcpserver) works at full nodes and validating 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.
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 7¶
Request sender¶
BlockCollections daemon sends this request.
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.