Multiple Instances

One process per chain. Two things need distinct values so they don't collide.

Why one per chain

Sieve indexes exactly one chain per process, because the pipeline is built for the chain in chain =. To cover Ethereum and Base, run two instances: one config, one database, and one set of ports each. Put every protocol you want on that chain into that instance, splitting them with config fragments if the file gets long.

Ports

Each instance binds RLPx (TCP) and discovery (UDP) on its P2P port, plus its API port. OP Mainnet, Unichain, and World Chain also bind discv5 on UDP port + 1. Base runs basev0 discv5 on the same UDP port.

Give each instance a distinct --p2p-port spaced by 2, and a distinct --api-port, or run one container per instance so each gets its own network namespace.

sieve --config mainnet/sieve.toml --p2p-port 30303 --api-port 4000
sieve --config base/sieve.toml    --p2p-port 30305 --api-port 4001

The port number itself has no effect on sync speed. Discovery advertises whatever port you pick.

Workers

Each instance spawns one block-processing worker per CPU core by default. Packing several instances onto one box oversubscribes the cores, so cap the count per instance.

[sync]
workers = 4      # default: CPU count. Also settable via --workers.

Rule of thumb: keep the sum of workers across co-located instances at or below the host's core count. The remaining shared resource is egress bandwidth. Sync speed depends on peer count and how many peers serve receipts, not on the port.

Databases

Every instance needs its own database. A database is pinned to its chain on the first run and reusing it for another chain is refused. See Chains.