Documentation on --netkey-file and --direct-peer

[J-A-M-E-5]

I'm not doing any staking or anything, this is just to drive geth, erigon, neth etc...

For mainnet I'd like to run a "master" nimbus with 100 connections, 8 threads or whatever connecting using web3 to geth.

Then I'd like to run 2 additional mainnet nimbus with 0 connections to the outside world (max-peers 1, max-hard-peers 1, no discovery). Each of these would connect via web3 to erigon and neth and idea is they would directly peer using 127.0.0.1 to my master nimbus to hopefully receive new slots with little latency.

I understand when nimbus starts random keys/peer-ids are generated which is preventing me from using the --direct-peers option as key always changes and needs to be set in all peers.

This led me to find the --netkey-file option which I think has to be JSON but can find no example.

I am presuming I can generate this like I do my jwt.secret files at system boot in /tmp/secrets. Does anyone have an example of such a file or how to generate it?

I'm happy to spend time documenting how to do it (similar to docs at https://nimbus.guide/ ) if someone gives me a quick how-to.

Thanks in advance

UPDATE: So looking at code I've seen if you run it using --netkey-file option specifying a non-existing file it creates that file after you input a password.

e.g. this is file it made for me with password "aYdr45KxyQx4".

{ "crypto": { "kdf": { "function": "scrypt", "params": { "dklen": 32, "n": 262144, "p": 1, "r": 8, "salt": "34f0df7740423917adad1e8ff91c1a4a00c25d5d2ed51b24b8d52fa0a4a23176" }, "message": "" }, "checksum": { "function": "sha256", "params": {}, "message": "85fce993336102f2a74a43ceec5ee6be54256046f69b372f2154f42766581047" }, "cipher": { "function": "aes-128-ctr", "params": { "iv": "3cb135adbf9705c9a61544c479cfc330" }, "message": "eb9ec9469a2e7473c2a62bb200b12d7421c1c79acd28a1eac0c8388102ab08c82868bb9a" } }, "pubkey": "080212210326fee4b0e9dea32499c1dadc0064cbc8d44e73dc3258ad43b1e5435d91d5f144", "uuid": "c16de81e-55f6-4fad-a5e8-ca249cec2909", "version": 1 }

Gonna delete now and make another, then see if I can run and get nodes connected. Would rather not use passwords as I am not staking or anything but I think there is a way of passing them as they do in testing anyhow. Will update. If anyone knows of a better way of doing all this please let me know.

UPDATE2:

OK so if you specify --netkey-file=/home/me/mykey.json --insecure-netkey-password=true when running nimbus, first time it will create the file. Using insecure password means it will never prompt you for the password when creating or reading, which is literally the password "INSECUREPASSWORD".

I think this will be fine for my use and will test if I can get direct peers working. If I can perhaps I'll make some Python or something (a language I understand) to generate mykey.json on every boot so even though it has "INSECUREPASSWORD" at least I get benefit of changing node id's etc.. every reboot, as nimbus does for now every restart (which for me is essentially same as every reboot).

[J-A-M-E-5]

I'm gonna close this as I've just stumbled across #4465 which appears to be something in development to do exactly what I want to do, drive N EL's with just 1 nimbus running.

[arnetheduck]

The other option for driving an EL in a light-weight manner is https://nimbus.guide/el-light-client.html - you can use your "regular" nimbus instance to feed the light client its initial root via rest.

[J-A-M-E-5]

Thanks @arnetheduck I had seen that, but this part put me off:-

...light clients are typically behind by ~4/3 slots (~15 seconds on Ethereum mainnet).

I can handle being a few ms behind, but not seconds.