http://testing.mainnet.beacon-api.nimbus.team/" rel="nofollow">http://testing.mainnet.beacon-api.nimbus.team/ \ --backfill=false ./nimbus ``` The consensus chain will start from a checkpoint while the execution chain will still be synced via P2P. You need about 500GB of space in total, but if you're buying a drive today, get 2 or 4 TB anyway. Testnets like `hoodi` can reasonably be synced from P2P all the way (takes a bit more than a day at the time of writing), without the checkpoint sync: ```nim ./nimbus --network:hoodi ``` That's it! The node can now be used both for validators and as a web3 provider. `--rpc` gives you the web3 backend which allows connecting wallets while `--rest` gives the beacon api that validator clients use. Of course, you can run your validators [in the node](https://nimbus.guide/run-a-validator.html#2-import-your-validator-keys) as well. Here's a true maxi configuration that turns on (almost) everything: ```nim ./nimbus --rpc --rest --metrics ``` The execution chain can also be imported from era files, downloading the history from https://mainnet.era.nimbus.team/ and https://mainnet.era1.nimbus.team/ and placing them in `era` and `era1` in the data directory as the [manual](https://nimbus.guide/execution-client.html#syncing-using-era-files) suggests, then running an `import` - it takes a few days: ```sh ./nimbus import ``` If you were already running nimbus, you can reuse your existing data directory - use `--data-dir:/some/path` as usual with all the commands to specify where you want your data stored - if you had both eth1 and eth2 directories, just merge their contents. To get up and running more quickly, snapshots of the mainnet execution database are maintained here: https://eth1-db.nimbus.team/ Together with checkpoint sync, you'll have a fully synced node in no time! In future versions, this will be replaced by snap sync or an equivalent state sync mechanism. To build the protoype: ```sh make update make -j8 nimbus ``` In a single process binary, the beacon and execution chain are each running in their own thread, sharing data directory and common services, similar to running the two pieces separately with the same data dir. One way to think about it is that the execution client and beacon nodes are stand-alone libraries that are being used together - this is not far from the truth and in fact, you can use either (or both!) as a library. The binary supports the union of all functionality that `nimbus_execution_client` and `nimbus_beacon_node` offers, including all the subcommands like [checkpoint sync](https://nimbus.guide/trusted-node-sync.html) and [execution history import](https://nimbus.guide/execution-client.html#import-era-files), simply using the `nimbus` command instead. Prototype notes: * cross-thread communication is done using a local instance of web3 / JSON - this is nuts of course: it should simply pass objects around and convert to directly to RLP on demand without going via JSON * the thread pool is not shared but should be - nim-taskpools needs to learn to accept tasks from threads other than the one that created it * discovery is not shared - instead, each of eth1/2 runs its own discovery protocols and consequently the node has two "identities" * there are many efficiency opportunities to exploit, in particular on the memory usage front * next up is light client and portal to be added as options, to support a wide range of feature vs performance tradeoffs

Unified Nimbus node#3646arnetheduck wants to merge 1 commit intofc-halfstatus-im/nimbus-eth1:fc-halffrom wip-nimbusstatus-im/nimbus-eth1:wip-nimbusCopy head branch name to clipboard

Commits

Commits on Sep 15, 2025

Unified Nimbus node

Unified Nimbus node#3646
arnetheduck wants to merge 1 commit intofc-halffrom
wip-nimbus