Daemon
In this section, we will describe how IBax nodes interact with each other from a technical perspective.
About the server daemon
The server daemon needs to run on every network node, which executes various server functions and supports IBax's blockchain protocol. In the blockchain network, the daemon distributes blocks and transactions, generates new blocks, and verifies blocks and transactions received, and it can avoid the fork issue.
Honor node daemon
A honor node runs the following server daemons:
BlockGenerator daemon
Generating new blocks.
BlockCollection daemon
Downloading new blocks from other nodes.
Confirmations daemon
Confirming that blocks on the node also exist on most other nodes.
Disseminator daemon
Distributing transactions and blocks to other honor nodes.
QueueParserBlocks daemon
Blocks in the queue, which contains blocks from other nodes.
Block processing logic is the same as BlockCollection daemon.
QueueParserTx daemon
Verifying the transactions in queue.
Scheduler daemon
Running contracts as scheduled.
Guardian node daemon
A guardian node runs the following server daemons:
BlockCollection daemon
Confirmations daemon
Disseminator daemon
QueueParserTx
Scheduler
BlockCollection daemon
This daemon downloads blocks and synchronizes the blockchain with other network nodes.
Blockchain synchronization
This daemon synchronizes the blockchain by determining the maximum block height in the blockchain network, requesting new blocks, and solving the fork issue in the blockchain.
Check for blockchain updates
This daemon sends requests from the current block ID to all honor nodes.
If the current block ID of the node running the daemon is less than the current block ID of any honor node, the blockchain network node is considered out of date.
Download new blocks
The node that returns the largest current block height is considered the latest node. The daemon downloads all unknown blocks.
Solving the fork issue
If a fork is detected in the blockchain, the daemon moves the fork backward by downloading all blocks to a common parent block. When found the common parent block, a blockchain rollback is performed on the node running the daemon, and the correct block is added to the blockchain until the latest one is included.
Tables
The BlocksCollection daemon uses the following tables:
block_chain
transactions
transactions_status
info_block
Request
The BlockCollection daemon sends the following requests to other daemons:
Type 10 points to the largest block ID among all honor nodes.
Type 7 points to the data with the largest block ID.
BlockGenerator daemon
The BlockGenerator daemon generates new blocks.
Pre-verification
The BlockGenerator daemon analyzes the latest blocks in the blockchain to make new block generation plans.
If the following conditions are met, a new block can be generated:
The node that generated the latest block is in a node within the honor node list and runs the daemon.
The shortest time since the latest unverified block was generated.
Block generation
A new block generated by the daemon contains all new transactions, which can be received from the Disseminator daemon of other nodes or generated by the node running the daemon. The block generated is stored in the node database.
Tables
The BlockGenerator daemon uses the following tables:
block_chain (saves new blocks)
transactions
transactions_status
info_block
Request
The BlockGenerator daemon does not make any request to other daemons.
Disseminator daemon
The Disseminator daemon sends transactions and blocks to all honor nodes.
Guardian node
When working on a guardian node, the daemon sends transactions generated by its node to all honor nodes.
Honor node
When working on a honor node, the daemon sends blocks generated and transaction hashes to all honor nodes.
Then, the honor node responds to transaction requests unknown to it. The daemon sends the complete transaction data as a response.
Tables
The Disseminator daemon uses the following tables:
transactions
Request
The Disseminator daemon sends the following requests to other daemons:
Type 1 Send transactions and block hashes to the honor node.
Type 2 Receive transaction data from the honor node.
Confirmations daemon
The Confirmations daemon checks whether all the blocks in its node exist on most other nodes.
Block confirmation
A block confirmed by multiple node in the network is considered as a confirmed block.
The daemon confirms all blocks one by one starting from the first that is currently not confirmed in the database.
Each block is confirmed in the way as follows:
Sending a request containing the ID of the block being confirmed to all honor nodes.
All honor nodes respond to the block hash.
If the hash responded matches the hash of the block on the daemon node, the confirmation counter value is increased. If not, the cancellation counter value is increased.
Tables
The Confirmations daemon uses the following tables:
confirmation
info_block
Request
The Confirmations daemon sends the following requests to other daemons:
Type 4 Request block hashes from the honor node.
TCP service protocol
The TCP service protocol works on honor nodes and guardian nodes, which uses the binary protocol on TCP to requests from the BlocksCollection, Disseminator, and Confirmation daemons.
Request type
Each request has a type defined by the first two bytes of the request.
Type 1
Request sender
This request is sent by the Disseminator daemon.
Request data
Hashes of the transaction and block.
Request processing
The block hash is added to the block queue.
Analyzes and verifies the transaction hashes, and select transactions that have not yet appeared on the node.
Response
No. After processing the request, a Type 2 request is issued.
Type 2
Request sender
This request is sent by the Disseminator daemon.
Request data
The transaction data, including the data size:
data_size (4 bytes)
Size of the transaction data, in bytes.
data (data_size bytes)
The transaction data.
Request processing
Verifies the transaction and add it to the transaction queue.
Response
No.
Type 4
Request sender
This request is sent by the Confirmations daemon.
Request data
Block ID.
Response
Block hash.
Returns 0 if not having a block with this ID.
Type 7
Request sender
This request is sent by the BlockCollection daemon.
Request data
Block ID.
block_id (4 bytes)
Response
The block data, including data size.
data_size (4 bytes)
Size of the block data, in bytes.
data (data_size bytes)
The block data.
The connection is closed if not having a block with this ID.
Type 10
Request sender
This request is sent by the BlockCollection daemon.
Request data
No.
Response
Block ID.
block_id (4 bytes)
Last updated