> For the complete documentation index, see [llms.txt](https://ethernal-2.gitbook.io/blade/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ethernal-2.gitbook.io/blade/architecture/high-level-architecture.md). # High-level Architecture To better understand the Blade system, the high-level architecture diagram of components is illustrated below. A node in the diagram is any instance of Blade software connected to other computers running Blade software, forming a network. We also refer to this node as the Blade client or client for short.

High-level Architecture Component Diagram

The client exposes predefined RPC methods through an API (JSON-RPC within the `RPC` component). Among other things, this enables the sending of transactions to the blockchain and the reading of current blockchain data. Sent transactions are submitted to the transaction pool (represented by `TxPool` component). For reading a block from the blockchain, a transaction from a block, or the current state of an account, a request is submitted to the `Storage` component. The `Storage` component is a general abstraction for different types of storage holding various data like the blockchain itself, the world state, bridge data, etc. The transaction pool prioritizes received transactions, usually by giving an advantage to transactions with higher gas prices, but the applied criteria may differ. Each received transaction from the transaction pool is sent to the rest of the nodes/peers in peer-to-peer network using the `libp2p` communication component. This component uses gossip mechanism (gossipsub) to spread received messages through the network. There are two types of Blade clients: full nodes and validators. Full nodes store the entire blockchain and they do not participate in block validation. Validators, as their name suggests, participate in block validation. If a client node is in the role of a validator, it takes part in the block creation process, and the consensus mechanism is an integral part of its operational behavior. The consensus mechanism, which is essentially an algorithm using state transitions based on the received confirmations, helps validators come to an agreement regarding the validity of a proposed block. The `Consensus` component (the algorithm) is supported by the `Consensus Backend` component. As the algorithm assumes that only one validator from all consensus participants/validators is a block proposer, the `Consensus Backend` also holds the logic to determine whether the validator is a proposer or not. For example, when the consensus algorithm starts, it checks the proposer status of the validator, and if the status is true, it calls the `Block Management` component, which takes transactions from the `TxPool` to form a proposed block. The consensus relies on a number of messages (such as PREPARE, COMMIT, etc.) during different stages of the block creation process. These messages are created by the `Consensus Backend` as well. As all validators equally participate in the consensus, the messages have to be distributed to all of them. The communication layer of the `Consensus Backend` ensures that all messages are sent to all peers through `libp2p`. Messages work in pub/sub manner meaning that only subscribed nodes receive messages for the given topic. Once all messages are exchanged through different consensus phases, and assuming that consensus is reached (meaning that the proposed block is valid and ready to be added to the blockchain), the next step is to apply all block transactions and add the block. The `Block Management` component takes the block and sends each transaction for execution. The `Executor` component determines whether it is a smart contract call or an external owned account (EOA) balance change, and applies them accordingly. In the case of a smart contract, the contract is retrieved from storage and sent to the `EVM` (Ethereum Virtual Machine) for execution. Consequently, the `World State` is updated by the `EVM`, adjusting the balance of the contract account and its storage. For EOAs, the `World State` is directly updated by adjusting the balance of the account. After all transactions are executed and the `World State` is updated, the block's header is also updated with the latest `World State` hash and the block is appended to the blockchain (saved in `Blocks` storage). The block is also sent to all peers using `Syncer` component. When a node is a validator, both the `Consensus` and `Syncer` components are up and running. On the other hand, for full nodes, only the `Syncer` is running. As mentioned, the `Consensus` serves to create blocks, while the `Syncer`'s purpose is to synchronize the node's blocks with the rest of the network. The `Syncer` connects to another node and fetches blockchain differences (i.e. blocks) by using an internal protocol that compares the indices of the latest blocks on the nodes. After a newer block is received, the `Syncer` sends it to `Block Management`, which in turn checks if the block already exists in the chain, because there is a chance that the `Consensus` created it. Otherwise, the newer block is applied by `Block Management` (the block is validated, its transactions are executed, and the updated block is appended to the blockchain). At the same time, currently running consensus execution is halted, as it is stale. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ethernal-2.gitbook.io/blade/architecture/high-level-architecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.