Architecture

​

Introduction

This section provides a detailed introduction to the architecture of AxiomLedger, covering a comprehensive overview from the entire network to individual nodes and component levels. First, looking at the network topology, AxiomLedger is composed of multiple validator nodes connected via a Peer-to-Peer (P2P) mechanism. These validator nodes form the infrastructure of AxiomLedger. Next, looking inside the internal structure of each validator node. each of them comprises various core components that collectively perform functions such as transaction processing and consensus. Finally, we will analyze the details of each core component, including their responsibilities, interaction interfaces, and more.

​

Network Topology

The AxiomLedger network consists of the following main components (as shown in the figure below):

• Blockchain nodes: Connected via P2P networks, using consensus algorithms to maintain a common ledger. Node roles are divided into new nodes, candidate nodes and validator nodes (including special block proposer nodes), according to their degree of participation in consensus. Node roles can be converted to each other, please refer to Consensus for details.
• Wallet services: The bridge for users and DApps to interact with the blockchain, responsible for constructing and forwarding transactions.
• Blockchain browsers: Connect to blockchain nodes, store and parse on-chain data, and provide visual access to blockchain data for users.

Specifically, new nodes are nodes that havn’t obtained network access permission through a governance vote, candidate nodes are nodes that are currently not participating in consensus block production, validator nodes are nodes that participate in block production through elections, and block proposer nodes are validator nodes responsible for packing blocks.

​

Node Architecture

To facilitate the reuse of core services by decentralized nodes, the Axiomesh ecosystem adopts a modular design pattern that separates the kernel, system, and application layers. The kernel layer is responsible for fundamental functions of the decentralized system, such as P2P, storage, monitoring, configuration, and more. The System layer can utilize the services provided by the kernel layer to build decentralized system services, including blockchain services, Layer 2 (execution layer) services, cross-chain bridge services, and decentralized storage (data availability) services, etc. Finally, at the application layer, decentralized applications (such as stablecoins, RWAs, NFTs, DeFi) can be developed using the API services provided by the system layer. Below, we will focus on the component architecture of AxiomLedger（the system layer） validator nodes, including EVM-compatible RPC service, transaction executor, blockchain ledger service, transaction memory pool, consensus algorithm, cross-chain bridge, and access control logic.

​

Core components

AxiomLedger nodes are responsible for core business operations of the blockchain network such as ledger data storage, transaction execution, state services, etc. Each blockchain node consists of multiple related logical components.

​

RPC

In order to be compatible with EVM ecosystem tools, AxiomLedger’s interface services adopt Ethereum-compatible JSON RPC services. The core interfaces for accessing EVM are implemented to be compatible, including contract deployment, invocation, basic chain information query, etc. In addition, the Axiomesh blockchain extends interfaces related to interacting with native governance services on the blockchain, including proposal management, governance member management, node upgrades, etc.

​

TxPool

The transaction pool component is mainly used to cache and manage transactions submitted to blockchain nodes that have not yet been packaged and executed. The data in the transaction pool is only fully synchronized between validator nodes. Transactions in the transaction pool come from two sources, one is transactions submitted by applications received directly through the RPC service of the node itself, and the other is transactions forwarded from other validator nodes or candidate nodes through the network service. When the current node is the block proposer in the consensus algorithm, the consensus algorithm will pull a certain number of transactions from the transaction pool to form a block, and broadcast this block to other validators in the network. After this block is consented by the consensus network, each validator node executes the transactions in the block and updates the ledger records.

​

Executor

The executor component is the core component that executes transaction logics in blockchain nodes. The executor receives a list of transactions ordered by consensus, executes specific transactions by invoking the underlying contract execution engine, and generates temporary ledger changes. After the execution results are consented, the changed data are written to persistent ledger state database through the ledger. The executor invokes different contract execution engines depending on the transaction type. AxiomLedger contains built-in contract execution engines and equivalent EVM contract execution engines:

• Built-in contract execution engine: Used to execute built-in system contracts, including governance contracts, upgrade contracts, economic management contracts, epoch management contracts and other blockchain system management contracts.
• EVM equivalent execution engine: Used to execute contracts submitted by external users, including various DApp business logic contracts such as ERC20, ERC721, and DEX.

​

Consensus

The consensus component is responsible for determining the order of blockchain transactions and verifying the consistency of the blockchain ledger state. AxiomLedger adopts the dBFT (delegated Byzantine Fault Tolerance) consensus algorithm, balancing node scalability and fast finality. dBFT introduces the concept of epoch on the basis of traditional BFT algorithms. At the beginning of each epoch, the dBFT algorithm uses a randomly verifiable function to elect a fixed number of new validator node sets from the node set consisting of validators and candidates. These new validators will continue to work until the beginning of the next epoch.

​

Ledger

The ledger component provides the ability to manage blockchain world state data and block data. The state data includes account related information such as balance, permissions, nonce value, etc. For special accounts such as contract accounts, it also contains the contract bytecode and all related changed states involved in the contracts. In addition, the ledger also provides the ability to manage block data. Block data includes blocks, transactions, transaction receipts and other persistent non-mutable data, mainly providing storage and query services for such data. In addition, the ledger module can also rely on the Merkle tree to provide the ability of Merkle proof of critical data within the ledger. The ledger component is responsible for managing the world state and block data of the blockchain:

1. State data: Include account information such as balance, permissions, nonce, etc. For smart contract accounts, it also contains contract bytecode and related state changes.
2. Block data: Include blocks, transactions, transaction receipts and other persistent non-state change data, providing storage and query services.
3. Merkle proof: Merkle proofs of critical data in the ledger can be generated through the Merkle tree.

The ledger component targets two types of data: state data and block data, utilizing data structures suitable for their access patterns respectively. This allows for efficient management of core blockchain data while supporting the generation of Merkle proofs, enhancing data verifiability. Such a design enables the ledger component to meet various requirements of blockchain, including state changes, historical records, and data proofs.

​

Bridge

The cross-chain bridge component is responsible for managing AxiomLedger’s cross-chain related services, including ingress and egress channels for cross-chain transactions, relay routing for cross-chain transactions, and oracles for cross-chain services.

​

Admission Control

The admission control component provides the capability of secure validation for transactions. This component provides basic transaction validity check services, including transaction format, signature information, gas fees, etc.