📄️ Design Pattern
Developing large-scale projects poses challenges including complexity, maintainability, scalability, and high performance. Complexity arises from multiple interdependent submodules and components, making the overall architecture and logic intricate and difficult to develop, debug, and test. Maintaining such projects becomes critical as they expand, requiring ongoing maintenance, upgrades, and improvements. Proper decoupling of modules is essential to prevent changes in one module from affecting others, which can increase maintenance costs.
📄️ Mempool
Mempool (i.e., memory pool), or transaction pool, is the queue where unconfirmed transactions are temporarily stored for further verification in order to be included in a block.
📄️ Interoperability
Before proceeding, we recommend reading the following pieces to fully grasp this article, as they provide prerequisite knowledge:
📄️ Consensus
🛠 This page is a work in progress. 🚧
📄️ Network
🛠 This page is a work in progress. 🚧
📄️ Executor
Executor is a module under the core module which executes block transactions on the Axon chain. The Executor contains the implementation of Precompiled Contracts and System Contracts. It also stores the metadata, CKB headers, Image Cells etc. The Executor can execute transactions for axon system contracts or any EVM compatible contracts on Axon. The application binary interface (ABI) of Metadata, CKB Light Client and Image Cells is defined in Solidity inside another module called “Builtin Contracts”. For each system contract except Native Token, there is a corresponding precompiled contract. The overall architecture is shown below.
🗃️ System Contracts
3 items
📄️ Storage
Axon’s storage module works as a bridge between Axon and its database interface, handling the data I/O of other Axon modules.