Architecture Diagrams
1. Network Architecture
Blockmaze Network is designed to support interoperability across multiple blockchain networks. The architecture enables cross-chain asset transfers and data exchange while supporting the specific features of the Blockmaze protocol.
The network architecture focuses on compatibility, resilience, and adaptability. It allows different chains and applications to interact while maintaining predictable behavior and stable operation across environments.
2. State Machine
Blockmaze Network is built on a replicated deterministic state machine model. In this model, the system exists in a single state at any given time. Transactions cause state transitions, moving the system from one state to another.
In a blockchain environment, transactions are grouped into blocks for efficiency. Given an initial state (S) and a block of transactions (B), the state machine processes each transaction in sequence and produces a new state (S').
Blockmaze Network uses the Cosmos SDK to define application state, transaction types, and state transition logic. This ensures deterministic execution, meaning all nodes processing the same transactions reach the same final state.
3. CometBFT
CometBFT provides the networking and consensus layers for the Blockmaze Network. It is application-agnostic and is responsible for propagating transactions and ordering them into blocks.
CometBFT uses a Byzantine Fault Tolerant consensus algorithm. At any block height, a validator set (V) participates in consensus. A block is considered valid once more than two-thirds of the validator set signs it.
Validators are responsible for proposing and validating blocks and ensuring correct block ordering across the network.
4. ABCI (Application Blockchain Interface)
The Blockmaze application communicates with CometBFT through the Application Blockchain Interface (ABCI). This interface defines how transactions and block-related events are passed between the consensus engine and the application.
CometBFT sends transactions to the application for execution, and the application returns execution results that indicate success or failure.
Key ABCI methods include:
- CheckTx: Validates transactions before they are included in blocks. This helps prevent spam and ensures transactions meet basic requirements.
- DeliverTx: Executes transactions included in finalized blocks and applies state changes.
- BeginBlock / EndBlock: Called at the start and end of each block to run additional application-specific logic.
Developers building on Blockmaze implement the ABCI interface to connect their application logic with CometBFT, while relying on CometBFT for networking and consensus.
ABCI Message Flow and Execution
The DeliverTx message is the core execution path of the application. Every transaction included in the blockchain is processed through DeliverTx. When a DeliverTx message is received, the application must validate the transaction against the current state, application rules, and cryptographic credentials. Once validated, the transaction updates the application state. This may involve writing values to a key-value store or updating other state representations, such as a UTXO database, depending on the application design.
The CheckTx message serves a validation-only role. It is used by Tendermint Core's mempool to verify transactions before they are included in a block. Only transactions that pass CheckTx are propagated to peers. During CheckTx, the application may perform checks such as validating sequence numbers to prevent replay attacks or enforcing capability-based permissions that must be refreshed with each transaction. Transactions that fail these checks are rejected early.
The Commit message is used to generate a cryptographic commitment to the current application state. This commitment is included in the next block header. Any inconsistency in state updates results in detectable blockchain forks, which helps surface programming errors. The commit mechanism also supports secure light client verification. Merkle proofs can be checked against the block hash, which is signed by a validator quorum.
Tendermint Core establishes multiple ABCI connections to the application:
- One connection for transaction validation in the mempool
- One connection for consensus-related block execution
- One connection for querying application state
Because multiple execution paths exist, application developers must design ABCI message handlers carefully to ensure consistent state transitions. This architecture provides a clear execution model while allowing flexibility in application logic. The overall message flow through ABCI defines how transactions move from validation to execution and final state commitment.
5. EVM Compatibility
Blockmaze Network supports EVM compatibility by implementing a set of components that reproduce Ethereum Virtual Machine state transitions while preserving the Ethereum developer experience.
EVM compatibility is achieved through the following components:
- Ethereum transaction format implemented as a Cosmos SDK Tx and Msg interface
- Ethereum secp256k1 cryptographic curve for key management
- StateDB interface for state queries and updates
- JSON-RPC interface for interacting with EVM-compatible applications
Most EVM-related components are implemented within the EVM module. Some supporting components are implemented outside the module to maintain compatibility and consistency across the system.
6. Accounts
Accounts on Blockmaze Network are designed to be compatible with Ethereum-style addresses. This allows developers to integrate wallets and applications without changes to existing Ethereum tooling. From an application perspective, Blockmaze accounts behave like Ethereum accounts.
Creating Accounts
Accounts can be created using one of the following methods:
- A private key
- A keystore file, which stores a private key protected by a password
- A mnemonic phrase
A private key or keystore file creates a single account. A mnemonic phrase allows access to multiple accounts using the same phrase.
Blockmaze supports hierarchical deterministic key generation using mnemonic phrases. This enables users to manage multiple accounts and access accounts across different blockchains without managing multiple secrets.
HD keys generate addresses using a mnemonic phrase combined with a derivation path. Each blockchain supports specific derivation paths, and the correct path must be used to access all accounts associated with a mnemonic.
Blockmaze Accounts
Blockmaze defines a custom account type that supports Ethereum-compatible addresses using hierarchical deterministic wallets. Key properties include:
- Use of Ethereum ECDSA secp256k1 cryptographic curve (eth_secp256k1)
- Support for Ethereum-compatible addresses
- Compliance with EIP-84 for full BIP-44 paths
The root HD derivation path for Blockmaze accounts is: m/44'/60'/0'/0
Blockmaze uses coin type 60 to maintain compatibility with Ethereum accounts.
The custom Blockmaze EthAccount implements the AccountI interface from the authentication module and includes additional fields required for Ethereum-style accounts, including support for externally owned accounts and contract accounts.
// EthAccountI represents the interface of an EVM-compatible account
type EthAccountI interface {
authtypes.AccountI
// EthAddress returns the Ethereum address representation of the AccAddress
EthAddress() common.Address
// CodeHash is the keccak256 hash of the contract code (if any)
GetCodeHash() common.Hash
// SetCodeHash sets the code hash to the account fields
SetCodeHash(code common.Hash) error
// Type returns the type of Ethereum Account (EOA or Contract)
Type() int8
}
7. Gas and Fees
Transactions on the Blockmaze network require fees. The fee mechanism follows an Ethereum-style gas model while being implemented within the Blockmaze protocol. This section explains gas usage, fee calculation, and the Ethereum-style fee market based on EIP-1559.
Why Transactions Require Fees
Without fees, a network can be overwhelmed by large volumes of invalid or malicious transactions. Fees act as an economic control mechanism that limits abuse and ensures fair access to network resources.
Gas represents the resource cost of transaction execution. Each operation consumes gas, which directly translates to cost for the transaction sender.
Gas and Fee Calculation
Fees are calculated using the following formula:
Total Fee = Gas Used × Gas Price
Gas measures execution effort, while gas price defines the cost per unit of gas. Gas prices can vary depending on network demand. Blockmaze uses an Ethereum-style fee market based on EIP-1559 to prioritize transactions.
8. Transaction Receipts
Transaction receipts provide execution results for completed transactions. A receipt is returned by an Ethereum-compatible client and includes execution metadata.
A receipt contains the following fields:
- transactionHash: Hash of the transaction
- transactionIndex: Position of the transaction in the block
- blockHash: Hash of the block containing the transaction
- blockNumber: Block number
- from: Sender address
- to: Receiver address, or null for contract creation
- cumulativeGasUsed: Total gas used in the block up to this transaction
- effectiveGasPrice: Base fee plus tip per unit of gas
- gasUsed: Gas consumed by this transaction
- contractAddress: Address of the created contract, if applicable
- logs: Events emitted during execution
- logsBloom: Bloom filter for log queries
- type: Transaction type (legacy, access list, or dynamic fee)
- root: Transaction state root (pre-Byzantium)
- status: Execution result, where 1 indicates success and 0 indicates failure
9. Interconnected Ecosystem
Blockmaze Network supports cross-chain interaction with the Ethereum ecosystem and other blockchain networks. This enables cross-chain transactions, asset transfers, and data exchange.
Interoperability is achieved through the Inter-Blockchain Communication protocol (IBC). IBC enables authenticated, ordered, and state-aware communication between independent blockchains.
Through IBC, Blockmaze participates in a connected blockchain environment while maintaining chain-level independence and security.
