# Nodes and Replication IronWeave's node operation and data replication represent a fundamental departure from traditional monolithic blockchains, designed to achieve massive horizontal scalability and unprecedented privacy, and globally scalable on-chain storage. ## How IronWeave Nodes Operate IronWeave operates with multiple node types that collaboratively manage the network, distributing work horizontally and enabling parallel processing. The node types in IronWeave are the following: * **Manager Nodes:** These nodes oversee chain management, ensuring the ongoing operation of the IronWeave fabric. They keep track of the locations of the *heads* of chains. Manager node slots are managed by the IronWeave Foundation and expand based on demand, performance, and regional requirements. * **Validator Nodes:** These nodes are responsible for validating deterministic data types, such as value transfers, and confirming sufficient balances to prevent double-spending. Validator leaders are randomly elected from among the validators in a given IronWeave Zone for each frame (similar to an epoch in other chains). An IronWeave chain that is transferring value is considered a spend chain (for that interaction) and is locked during the transaction to ensure integrity and prevent double-spend. Combined with the known hash of the immediately previous block on the spend chain, and the Manager node lock, the transaction of a spend completes or is rolled back in its entirety and the locked chain remains locked until the process completes. Validator nodes also validate transactions when not elected as leader, to confirm and co-sign spend blocks, to ensure multiple validators confirm each transaction. IronWeave uses Proof-of-Stake (PoS) consensus mechanism for validator nodes, ensuring proper deployment, registration, and incentivizing correct behavior while penalizing bad actors. Validators operate on a per-Zone basis, further decentralizing access to chains. * **Storage Nodes:** These nodes store encrypted blocks and are responsible for retrieving and replicating them from other storage nodes and other Zones. For any interaction that includes chains from multiple Zones, the shared block is stored in storage nodes for each Zone. Storage nodes use a Proof of Storage (PoS) mechanism to ensure proper storage of blocks, and to confirm continued storage of blocks upon random challenges issued by the IronWeave fabric. * **Compute Nodes:** These nodes create shared blocks, replicate blocks from other nodes, and run Iron Contracts, a more secure version of smart contracts that will be available as part of the IronWeave Mainnet release. {% hint style="info" %} NOTE: During the IronWeave Testnet phase, various options for Proof of Storage (PoS) are being evaluated for efficiency, performance and scale. The implementation for IronWeave Mainnet release will likely be based on, but different from the PoS described in the previous paragraphs. {% endhint %} The division of labor among these node types allows IronWeave to divide the workload horizontally. IronWeave's unique architecture supports thousands of separate Zones, preventing unintended centralization. Node operators are incentivized with transaction fees when operating as leaders for their Zone, and are incentivized with IronWeave tokens (ISE), distributed proportionately to nodes based on their contribution to the fabric's ongoing and streamlined operation, including performance, uptime, latency, and competitive fees. This combination of front-end fees and back-end token rewards incentivizes new nodes to come online and provides a mechanism for curated decentralization, where IronWeave-run nodes provide a robust baseline, but decentralized nodes are encouraged to compete for traffic by offering better performance and lower fees. IronWeave nodes do not require significant investment in hardware, and can run on commodity servers without specialized ASICs or GPUs. This is intentional, as is the vast number of Zones in IronWeave, to enable and ensure broad implementation and participantion of node providers. Rather than a few organizations winning fees and incentives with disproportionate capital spends, IronWeave's architecture intentionally disseminates and decentralizes node operation, avoiding and intentionally subverting capitalistic aggregation of nodes among a few wealthy node operators or organizations. {% hint style="info" %} NOTE: During Testnet, work on condensing all node types into a single container is being pursued, enabling node providers to deploy a single container, and then upon deployment, can choose the node type being placed into service. This is intended to reduce friction and complexity of deploying a node, managing nodes, and creating a robust yet nimble code base. {% endhint %} ## How Replication Occurs in IronWeave In IronWeave's Shared-Block Architecture, data is stored on-chain in encrypted blocks, each functioning like a separate vault or safe deposit box. Each interaction, such as a payment or message, creates a new, self-contained, encrypted block. This block is then placed only on the participating chains, not on a public central ledger, and is encrypted with a unique set of keys accessible only to the participants. For replication, multiple duplicates of each shared block are immediately dispersed across nodes operating in the Zone(s) of the participating chains. This is an intentional architectural design for compute and storage efficiency — since it means it's not necessary for every node to store every block across all of the IronWeave fabric. Instead, IronWeave architecture implements a "statistical assurance" that any given shared block is replicated on a sufficient number of nodes to ensure it can be reconstituted if needed. The number of nodes a block is replicated on is a function of the nodes in a given Zone, which may also be based on factors like geographical diversity (considering data sovereignty and local compliance requirements), logical proximity to common access, frequency of access, and storage costs. This design allows for flexible block sizes, capable of storing any type of data from small IoT updates to large medical images or contracts, all encrypted and immutable. --- # Agent Instructions: 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://docs.ironweave.io/scalability/nodes-and-replication.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.