> ## Documentation Index
> Fetch the complete documentation index at: https://docs.novacula.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Ethereum

> Two-role (EL + CL) nodes — Geth × Lighthouse

Ethereum is the only multi-process chain in Novacula. Every Ethereum node is two roles: an **execution-layer (EL)** client and a **consensus-layer (CL)** client, deployed and managed together. They talk over the JWT-authenticated Engine API, which Novacula sets up and secures for you; the node page shows them as two roles.

To deploy one, open **Deploy Node**, pick **Ethereum**, then choose a network, an EL client, and a CL client. The wizard offers exactly the networks, clients, and versions your target executor declares — if a client or version isn't listed, that executor can't run it.

## Networks

| Network   | Type       |
| --------- | ---------- |
| `mainnet` | Production |
| `sepolia` | Testnet    |

Ethereum nodes run as **Full** nodes.

## Clients

Ethereum runs one EL client and one CL client, deployed together. Today the offered pair is **Geth** (EL) and **Lighthouse** (CL):

| Role   | Client       |
| ------ | ------------ |
| **EL** | `geth`       |
| **CL** | `lighthouse` |

## Resources

Defaults are set per client and per network; total node footprint is the EL client plus the CL client. The wizard pre-fills these and lets you adjust CPU and memory before deploying.

| Role / client   | `mainnet` CPU / RAM | `mainnet` disk | `sepolia` CPU / RAM | `sepolia` disk |
| --------------- | ------------------- | -------------- | ------------------- | -------------- |
| EL `geth`       | 4 cores / 16 GiB    | 2000 GiB       | 2 cores / 16 GiB    | 700 GiB        |
| CL `lighthouse` | 2 cores / 8 GiB     | 500 GiB        | 1 core / 4 GiB      | 300 GiB        |

EL and CL each take a share of the node's data volume. The wizard pre-fills these defaults and shows the exact numbers for your selection. On `sepolia` the two roles together ask for about 1 TiB of disk.

## Ports

| Name               | Port   | Role |
| ------------------ | ------ | ---- |
| EL RPC (HTTP)      | `8545` | EL   |
| EL RPC (WebSocket) | `8546` | EL   |
| CL beacon API      | `5052` | CL   |

These are the endpoints you consume: JSON-RPC on `:8545` / `:8546` from the EL, and the CL beacon API on `:5052`. The Engine API the two roles use to talk to each other is internal and managed by Novacula.

## Sync

* **Checkpoint sync (CL)** — always on, managed automatically. The CL fetches a recent finalized state from a trusted checkpoint provider, then the EL completes a snap sync. Novacula supplies a trusted checkpoint URL for `mainnet` and `sepolia`, so a new node syncs in hours rather than days.
* **Use your own checkpoint provider** — set the CL's checkpoint sync URL override (see below) to point at a provider you trust instead of the one Novacula picks. This swaps the provider; it does not turn checkpoint sync off.

## Configuration overrides

Ethereum clients are configured through **command-line arguments** — each role has its own argument list when you deploy or [edit a node's configuration](/docs/nodes/edit-configuration). Novacula manages the data-dir, ports, Engine API, JWT, and metrics flags; try to set one and the form rejects it as "managed by Novacula". Any other flag passes straight through to the client.

The one CL flag the UI knows about by name is the checkpoint sync URL:

* Lighthouse: `--checkpoint-sync-url`

## What you can build

* **RPC provider** (the common case) — the Geth EL paired with the Lighthouse CL, serving JSON-RPC on `:8545` / `:8546`.
* **Beacon endpoint for an external validator** — run the EL + CL pair, then point a separately-operated validator client at the CL beacon API on `:5052`. Novacula runs the node beneath your validator; it does not manage the validator client itself.

## Monitoring

The node page shows per-role status, sync progress, peers, CPU, memory, and disk for both the EL and CL. See [Node monitoring](/docs/nodes/monitoring).