# Node Architecture

Lattice operates as a two-tier network with distinct responsibilities:

| Tier                | Node Type      | Role                                                |
| ------------------- | -------------- | --------------------------------------------------- |
| **Control Plane**   | Orchestrators  | Coordinate work, validate proofs, manage reputation |
| **Execution Plane** | Resource Nodes | Provide actual infrastructure services              |

This separation enables specialization and economic efficiency. Orchestrators don't process application data. They coordinate and validate. Resource Nodes handle the actual work.

<figure><img src="/files/C0FUQaVWP4zewXnjd4pL" alt=""><figcaption></figcaption></figure>

## How the Tiers Work Together

### Service Request Flow

1. **Application requests coordination** through Lattice
2. **Orchestrator receives request** and evaluates requirements
3. **Orchestrator selects Resource Nodes** based on reputation, location, capacity
4. **Resource Nodes provide services** (discovery, tunneling, relay)
5. **Orchestrator validates completion** through peer attestations
6. **Rewards distributed** based on verified contribution

### Validation Through Triangulation

When a Resource Node claims to have provided services (like tunneling traffic), Orchestrators don't take their word for it. Instead:

* Peers in the meshnet sign coordination events
* These signatures attest to Resource Node participation
* Orchestrators validate based on **peer perspectives**, not Resource Node telemetry

A tunnel cannot claim credit for traffic the peers didn't actually route through it.

## Network Services

Lattice provides services that individual meshnets cannot provide for themselves:

| Service           | Description                                                                     |
| ----------------- | ------------------------------------------------------------------------------- |
| **Discovery**     | Applications find available capacity without knowing node identities in advance |
| **NAT Traversal** | Hole punching and tunneling fallback for devices behind firewalls               |
| **Validation**    | Verify Proofs of Coordination against consensus rules                           |
| **Telemetry**     | Network-wide latency measurements for routing optimization                      |
| **Handshake**     | Key-value stores for exchanging connection details                              |
| **Proxy**         | Traffic relay when direct peer-to-peer fails (25-65% of traffic typically)      |

## Scale Design

Lattice is designed to scale to millions of nodes:

* **Geographic distribution** ensures low latency globally
* **Redundant Orchestrators** prevent single points of failure
* **Automatic failover** maintains availability when nodes fail
* **Reputation scoring** routes work to reliable infrastructure

{% hint style="warning" %}
The roles of Orchestration nodes and services of Resource nodes may change as demand is validated and optimized.
{% endhint %}


---

# 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.tashi.network/node-operators/nodes/node-architecture.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.