# Node Requirements

The validator–relayer setup is intentionally decoupled to minimize trust assumptions and reduce attack surface.\
Validators are isolated entities that observe events and produce signed state commitments, while the relayer aggregates these signatures and submits relay transactions to the destination chain.

This document specifies the **software architecture** and the **infrastructure requirements** for running validator and relayer nodes.

***

## 1. Software Architecture Overview

### 1.1 Validator Backend

Validators operate as isolated, non-interactive observers. They:

* listen to bridge smart contract events on the source chain,
* reconstruct the hash-chain state and confirm correctness,
* sign the resulting top root using a locally stored private key,
* forward the signed batch (root + payloads) to the relayer through an internal message broker.

**Validators MUST NOT:**

* broadcast transactions on any blockchain,
* expose signing keys or accept inbound external connections,
* coordinate with other validators.

Each validator acts independently and does not communicate with other validators.

***

### 1.2 Relayer Backend

The relayer aggregates validator signatures and constructs the relay transaction. It:

* listens for incoming signed batches from validators,
* collects enough signatures to satisfy the threshold enforced by BridgeManagement on the destination chain,
* assembles a relay transaction containing:
  * the signed top root,
  * all associated batch payloads,
  * the validator signatures,
* submits the transaction to the destination-chain bridge contract.

The relayer **does not verify correctness** of the batch. All verification is performed on-chain through:

* sequential nonce checks,
* hash-chain reconstruction,
* top-root comparison,
* and threshold signature verification via BridgeManagement.

A single relayer instance is sufficient, but redundant failover instances are recommended for availability.

***

## 2. Infrastructure Requirements

### 2.1 Compute Infrastructure

The recommended baseline infrastructure is:

#### Message Broker

* 1 internal message broker (e.g., RabbitMQ, ZeroMQ, Redis Streams)
* Runs on-premise or within a protected network segment
* Serves as the communication channel between validators and relayer

#### Relayer Nodes

* 1 active relayer backend
* 1 optional failover relayer backend
* Each with:
  * 4 GB RAM
  * 2 CPU cores
* Nodes must reside inside the protected VLAN

#### Validator Nodes

* 7 validator backends (or parameterized by governance)
* Each with:
  * minimum 1 GB RAM
  * 1 CPU core
* Each validator must run on an independently controlled machine or VM\
  (no shared IPs, providers, infrastructure)

Validators must be isolated from one another to prevent correlated failures.

***

### 2.2 Network Infrastructure

#### Internal Network

* 1 dedicated VLAN containing:
  * all validator nodes,
  * relayer nodes,
  * the message broker.

#### Security Constraints

* Private IP addresses across the VLAN
* **Deny-all inbound firewall rule** from external networks
* Only outbound access to blockchain RPC endpoints is permitted
* No inbound connectivity allowed to validator nodes
* Validator keys must never be exposed through RPC or remote signing services

This network design ensures validators cannot be externally reached or probed, while allowing only the relayer and message broker to communicate internally.

***

## 3. Summary of Requirements

### Validators

* Observe chain events
* Reconstruct hash-chain state
* Sign the top root only
* Never send transactions on-chain
* Must operate in isolated, secure environments

### Relayer

* Aggregates validator signatures
* Submits relay transactions
* Runs in a protected internal network
* May be deployed with failover redundancy

### Infrastructure

* Dedicated VLAN
* On-premise or protected message broker
* Strict firewall isolation
* Distributed validator nodes on separate machines/providers


---

# 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://xdocs.ngd.network/bridge/general/node-requirements.md?ask=<question>
```

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.