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. Additionally, the ledger module can rely on JMT to provide the capability of proving historical data within the ledger.
The ledger component is responsible for managing the world state and block data of the blockchain:
State data: Include account information such as balance, permissions, nonce, etc. For smart contract accounts, it also contains contract bytecode and related state changes.Block data: Include blocks, transactions, transaction receipts and other persistent non-state change data, providing storage and query services.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.
Core Capabilities
Native Smart Account
The Native Smart Account (NSA) is one of the key initiatives to lower the entry barrier for users and realize large-scale blockchain commercial applications. Axiomesh ensures higher execution efficiency and more flexible authentication methods (such as ZK authentication, aggregate signature authentication) through chain-native support for smart accounts. It also directly provides practical capabilities such as gas fee payment, compatibility with Web2 login, account key recovery, limited authorization within a validity period, etc., greatly reducing the entry barriers for developers and end-users.
Native Smart Account
Learn about Native Smart Account
Decentralized Confidential Protocol with Auditability
The absence of privacy protection on public chains is one of the core factors hindering users, especially enterprise users, from using and building blockchain business applications. Therefore, Axiomesh needs to provide users with powerful privacy protection capabilities. Combining design principles, Axiomesh proposes a compliance-compliant and privacy-compatible protection protocol called Decentralized Confidential Protocol with Auditability (DCPA). DCPA adopts a twin token model in its overall architecture to ensure the composability and flexibility of the protocol. Based on cutting-edge cryptographic technology, it ensures the security and privacy of transaction content and identity under the premise of regulatory compliance.
Decentralized Confidential Protocol with Auditability
Learn about Decentralized Confidential Protocol with Auditability
Trusted Inter-Module Communication Protocol
The Trusted Inter-Module Communication Protocol (TIMC) is a protocol similar in purpose to Cosmos’ IBC and Polkadot’s XCMP. It is used for secure and trusted communication between modules within Axiomesh (settlement layer, execution layer, data custody layer) to transfer data and value. In addition, it provides additional powerful capabilities such as unified liquidity of AXC tokens among various modules within Axiomesh.
Trusted Inter-Module Communication Protocol
Learn about Trusted Inter-Module Communication Protocol