Multi-Pool Memory Architecture and Validator Roles

To achieve extreme throughput without resource contention, NCOG Earth Chain employs a multi-memory-pool architecture. This means the network maintains separate transaction mempools for different categories of transactions, and it leverages specialized validator roles for processing them in parallel. This design prevents heavy or complex transactions from slowing down simpler ones and makes optimal use of validator resources. 

The Problem with a Single Mempool: In many blockchains, all pending transactions sit in one mempool. If you introduce very complex operations (like large database updates or compute-heavy tasks) into that single queue, they could clog it up – miners/validators might spend time processing those and delay other transactions. Also, not every validator may be capable of validating every type of transaction (for example, if a transaction requires access to the DDB, a node without the database can’t execute it). A single mempool would cause inefficiencies where nodes pick up transactions they cannot process or everything waits behind the slowest tasks. 

NCOG’s Solution – Multiple Lanes: NCOG Earth Chain categorizes transactions and handles them in multiple parallel lanes: 

• The Main transaction pool handles standard blockchain transactions – token transfers, simple smart contract calls, staking operations, etc. All validators participate in processing these. 

• The DDB transaction pool handles transactions that invoke the Decentralized Database (stored procedure calls). Only DDB validator nodes (the ones running the database) actively execute these transactions. 

• (Potentially, other specialized pools can exist in the future for things like decentralized AI computations or other services in the NCOG ecosystem, handled by validators equipped for those tasks. But the primary pools at launch are the main pool and DDB pool.) 

Each pool has its own mempool data structure and propagation logic. For example, when a user submits a database transaction, it is routed directly to DDB validators and placed in the DDB mempool, rather than clogging the main mempool of every node. Conversely, a simple token transfer is gossiped to all and sits in the main mempool (and DDB nodes treat it just like any other validator would). 

Specialized Validator Roles: Corresponding to these pools, NCOG defines validator roles: 

• General Validators: These run the core consensus and handle the Main mempool. They validate and propose normal transactions and blocks. They do not necessarily run the PostgreSQL database or handle DDB transactions beyond checking endorsements. This makes it easier for many participants to join validation with modest hardware. 

• DDB Validators: These are validators that opt in to run the Decentralized Database component. They maintain the full database and handle the DDB mempool (in addition to also participating in the main pool). DDB validators execute SQL transactions and partake in the DDB’s local consensus. By doing extra work, they also earn the additional fees from database operations. Typically, these nodes will run on more powerful servers (more RAM, CPU, storage) since they carry the blockchain and the database state. 

• (In the future, there could be other specialized roles, e.g., an “AI Validator” role running GPU-intensive tasks, each with its own pool. The architecture is modular in this way.) 

Every validator publicly advertises which roles it performs (this could be part of its registration on-chain). For instance, the list of DDB validators is known to all nodes. This way, when a node receives a DDB transaction, it knows it should forward it to the DDB validators for processing, rather than to everyone. 

Parallel Processing: Thanks to the multi-pool system, the network can process different kinds of transactions simultaneously without interference. A DDB validator will be busy executing a database transaction from the DDB pool at the same time a general validator might be proposing a block of normal transactions from the main pool. Because the consensus is a DAG, these events all propagate and later get merged in finality. There’s no need to wait for one type to finish before handling another. This yields better CPU utilization and throughput. Effectively, NCOG Earth Chain processes multiple streams of transactions in parallel – one for each mempool – which then converge in the Forest consensus. 

Block Inclusion: Blocks (Atropos events) can contain transactions from multiple pools. For example, a validator creating a block might include mostly main transactions, and if there is an endorsed DDB result ready, include that as well (since the DDB result appears in the main pool as a commit transaction after endorsement). The block header might tag them by type, or they might be identified by the form of their content. The key point is that the scheduling of main transactions vs. DDB commit transactions in blocks is flexible and can be prioritized by fees. 

Prioritization and Fairness: Each pool can have its own transaction prioritization logic (usually fee-based). Within the DDB pool, transactions might be ordered by timestamp or by offered gas price for execution. Within the main pool, it’s by gas price as usual. When it comes to block assembly, validators will pick the highest-paying transactions across both pools. For instance, if a large DDB transaction has a high fee, it will incentivize validators to include the resulting commit tx promptly in blocks. This mechanism ensures that one class of activity cannot starve others — there’s always capacity reserved in each pool, and the economic incentives align to process all types efficiently. 

Resource Isolation: Because each pool is managed separately: 

• The memory and processing for, say, 1000 pending database TX is mostly confined to DDB nodes. Non-DDB nodes aren’t bothered by them until they’re finalized. This isolation means a surge of database activity doesn’t increase memory load on validators that can’t handle it. 

• Conversely, a flood of normal transactions (say, a DeFi craze) doesn’t overwhelm the DDB mempool; DDB validators can continue to promptly endorse database ops because their own queue is separate. 

• This design is akin to having multiple threads in a program – each pool is a thread handling tasks, and the consensus is the scheduler that commits them in an order. 

The table below outlines the two main validator roles in NCOG Earth Chain and how their responsibilities differ: 

Validator Role	Mempools Handled	Duties	Example Workload per Second
General Validator	Main pool only	– Gossip and validate standard transactions.- Propose and vote on blocks in DAG consensus (Forest Protocol).- Verify endorsements on special (e.g., DDB) transactions when they appear in blocks (without executing the DB logic).	e.g. verify 5,000 transfers or contract calls; sign/vote on blocks. Does 0 SQL executions (skips those).
DDB Validator (DB node)	Main pool and DDB pool	– All duties of a General Validator (participate in main chain consensus).- Maintain full PostgreSQL database state.- Receive and execute transactions from DDB mempool.- Run local BFT consensus with fellow DDB validators (endorse DB tx outcomes).- Package endorsed results and submit to main chain.	e.g. verify 5,000 normal tx + execute 50 SQL tx per sec (depending on complexity) + endorse results for those 50.

Table: Validator types in NCOG Earth Chain. Many validators may remain general-only (lower system requirements), while a subset take on the heavier role of DDB validators and earn extra fees for that service. Both types together run the network collectively. 

This division of labor means NCOG Earth Chain can scale out more gracefully. If demand for database operations grows, the network can add more DDB validators or increase their power without affecting the general validators. If general transaction volume grows, adding more general validators increases decentralization and stability without burdening the DDB ones (beyond normal consensus messaging). The architecture decouples the scaling of different workloads. 

Multi-Pool Network Communication: Under the hood, the network likely uses different gossip channels or topics for different mempools. For example, DDB validators might form a subnet to gossip database transactions among themselves (so general nodes aren’t flooded with raw SQL tx). General nodes, upon seeing a DB tx, forward it to DDB nodes (they know the list from on-chain info) and then ignore it until the committed result comes back. This targeted propagation reduces superfluous traffic. It’s somewhat like how in sharded blockchains, transactions are routed to the shard responsible. 

Comparing to Sharding: The multi-pool approach has a flavor of sharding by transaction type. Instead of random shards, it shards by function: one shard (pool) for monetary transfers and simple calls, another for high-data operations. However, unlike a true multi-shard system, NCOG ultimately anchors everything to one Main Chain. This avoids the complexity of cross-shard communication – here, a DDB transaction’s effects are available to the main chain in the same block. So it’s a hybrid approach giving many benefits of sharding (parallel processing, specialization) while keeping a unified state for finality. 

Benefits Recap: By using multi-pool architecture: 

• Throughput is increased, as the network can handle multiple categories of TX in parallel. 

• Latency is reduced for critical simple transactions, as they don’t sit behind bulky operations in a single queue. 

• The validator ecosystem can include a wide range of participants, from light nodes (general validators) to heavy-duty nodes (DDB validators), each contributing according to their capacity. 

• The design is future-proof: new transaction types (like containerized compute tasks or zero-knowledge proof transactions) can be added as new pools with their own validator committees, without disrupting existing ones. 

From a developer or user point of view, this complexity is mostly hidden – the network simply appears to handle things efficiently. Transactions of all types get confirmed quickly. For those running a validator node, it provides flexibility: one can choose to be an “archive node + DB node” and earn more, or just a standard node. This also adds decentralization, since not every validator needs to have the full heavy state (we might have hundreds of normal validators and, say, 20 DDB validators, rather than forcing all hundreds to maintain a huge database). 

In summary, the multi-mempool and multi-role architecture is a major factor enabling NCOG Earth Chain’s high performance. It is an elegant solution to deal with heterogeneous workloads on the blockchain, ensuring that specialized tasks are handled by the best-suited nodes and that the network can “multi-task” without tripping over itself. This innovation, combined with the Forest consensus and the DDB, positions NCOG Earth Chain as a highly scalable platform for diverse decentralized applications.