Transaction Flow

To further the understanding of the entire lifecycle of transactions in AxiomLedger, this section will track the flow of a transaction through various components within a validator node, analyzing the transaction processing logic at each component. The diagram below illustrates the workflow of an AxiomLedger validator dealing with a transaction: By examining the transaction workflow across node components, we can clearly see the end-to-end process from the transaction entering the node to being packaged into a block, including validation, ordering, consensus, and other processing phases. The logic implemented at each component will be detailed in the following sections.

​

Submit Transactions

As an end user, you can directly construct blockchain raw transactions through a wallet (e.g. MetaMask) or through a DApp. Then you need to sign these transactions with your private key (typically also done through a wallet) before sending them to a blockchain node. A valid transaction submitted to the blockchain must include at least:

• The raw transaction body
• The user’s public key
• The user’s signature for the transaction

​

Receive Transactions

The RPC interface module of AxiomLedger is responsible for receiving transaction requests submitted by end users. To be compatible with the Ethereum ecosystem, AxiomLedger implements most Ethereum RPC interface specifications and also provides additional customized governance service interfaces. To prevent DoS attacks, the RPC interface module has flow control capabilities. When transaction requests exceed the system processing limit, the request will be rejected directly. For transactions within the processing capacity, they will be forwarded to the internal admission control service for subsequent processing.

​

Validate Transactions

The admission control component will validate the security of submitted transactions, which mainly includes:

• Transaction format validity check: Verify if the transaction parameters conform to specifications.
• Signature validity check: Validate if the user’s signature is valid.
• Balance check: Check if the user has sufficient balance to pay for Gas fees.
• Sequence number check: Verify if the transaction sequence number is in ascending order.

Invalid transactions that fail validation are discarded directly, while valid transactions are cached in the transaction pool.

​

Consensus on Transactions

For transactions in the transaction pool, AxiomLedger will perform two operations:

1. Broadcast the transaction to neighboring nodes on the blockchain network via P2P services.
2. If the validator node is the primary node of the consensus nodes, it will periodically fetch batched transactions from the transaction pool and initiate a consensus proposal. The consensus algorithm will then execute rounds of consensus steps to ensure that the majority of validator nodes on the network reach consensus on the order of these batch transactions.

This allows quick propagation of transactions across the network, while the consensus algorithm ensures all nodes reach consensus on the transaction ordering, which guarantee the consistency of transaction sequences and the security of blockchain data.

​

Execute Transactions

Batched transactions (blocks) confirmed by the consensus algorithm are input into the executor for execution. The AxiomLedger executor calls different executors to process transactions based on transaction type. System transactions are processed by calling system contracts, while regular transactions are processed by the ethereum virtual machine. After transaction execution is complete, the world state is changed. The executor sends the world state changes along with the block over to the ledger module.

​

Persisting States

The ledger module calls different storage engines for data storage based on the types of data change. World state changes are persisted in the underlying KV database, while block data are stored using sequential database.