# Node

The **Node** component is the central nervous system of `pETHit`. It is the entry point binary that initializes, wires together, and starts all the other components (Storage, Execution, RPC, TxPool, Consensus).

## Current Architecture (v0.3.0)

In this iteration, the Node acts as the orchestrator of the Shared State pattern. It ensures that the **RPC** (which writes transactions) and the **Miner** (which reads/executes transactions) are both operating on the exact same memory.

### 1. The Startup Sequence

When you run `cargo run -p pethit-node`, the following happens:

1. **Initialize Storage:** Creates the `SharedStorage` (Database).
2. **Initialize TxPool:** Creates the `SharedTxPool` (Mempool).
3. **Initialize Chain:** Creates the `SharedChain` (Blockchain History) and ensures the Genesis Block exists.
4. **Wire RPC:** Passes references of `Storage`, `TxPool`, and `Chain` to the web server.
5. **Wire Miner:** Passes references of `Storage`, `TxPool`, and `Chain` to the consensus worker.
6. **Launch:** Spawns the Miner in a background thread and starts the RPC server on the main thread.

### 2. Concurrency Model

The Node leverages Rust's `tokio` runtime for asynchronous tasks (RPC) and `std::thread` for blocking tasks (Miner).

* **RPC Server:** Runs on the main Tokio event loop.
* **Miner:** Runs on a dedicated OS thread (since it simulates "work" via sleep).

## API / Usage

The Node is an executable binary, not a library.

### Commands

#### Start the Node

Running the binary starts the full node with default settings.

cargo run -p pethit-node

* **Default Port:** `127.0.0.1:8000`
* **Default Mining Interval:** 5 seconds

## Evolution Log

### v0.1.0: The Skeleton

* **Function:** Simply initialized the components and started the web server.
* **Wiring:** Connected the RPC directly to the Storage.

### v0.2.0: The Orchestrator

* **Additions:** Added the `SharedChain` and `Miner` to the initialization process.
* **Concurrency:** Introduced threading to run the Miner and RPC simultaneously.

### v0.3.0: The Identity Host

* **Configuration:** No major architectural changes, but the wiring was updated to support the new `SignedTransaction` flow.
* **Compatibility:** Ensured that the shared components (Storage/TxPool) passed to the sub-systems were the updated, thread-safe versions capable of handling RLP data.