It follows better the Nix conventions found in other projects.

Exactly as it says in the title.

We should add support for web3signer.

Hello!
I think it's a good idea to add vouch and dirk from Attestant to this repo: dirk is a key manager or signer and vouch is a multinode validator.

Should provide quick basic examples of how to use the packages, apps and modules we expose. They should target the common use cases, with links to more in depth and specific pages when they are available.

Adding support for foundry would be very nice! Especially if we package it adequately from sources.

I know foundry.nix effort exists; maybe we should talk with @shazow and try to merge it here?

Hello!
I want to add besu as an execution client, just saw that you wanted to backport it

I'm enjoying this repository, I'm asking that Nethermind be added to it.

I've been trying to create a Flake for it myself, but I don't enough experience with Nix to make it work.

We would like to be able to configure prysm within nixos easily.

Just as the title says, plugeth is a viable fork worth supporting.

Currently, we're only using nix-lint to check for potential issues. We should add support to treefmt check.

Add support to evmc

Disko produces automated documentation for the NixOS options within their modules like this.

I think we should follow a similar approach, but it will first require refactoring all of the types out of our modules so they can be isolated when running lib.evalModules otherwise you get complaints about options for networking and so on not being available.

Add support to consensus client nimbus

Currently, the Nethermind service is very simplistic in its form. We can add support to more Nethermind module options.

Background

We want to easily configure a geth instance within NixOS and support the different flavours.

Tasks

1. Port geth's service configuration from nixpkgs.
2. Improve/update the service to be generic and to support the different instances of geth.
3. Incorporate tests that configure a geth instance and check that some ports are running.

Acceptance Criteria

1. Test must pass, proving the configuration works for configuring geth.

We should provide some background on the project and what it is aiming to achieve. There will probably be some overlap with the README. Look at other nix-community projects for inspiration.

I'll try to implement that in the same way as other modules

Identify the patterns for bringing in backup and restore functionality, args generation, systemd service settings and so on.

We would like to configure the lighthouse client within nixos easily.

Same as #124 but for Teku.

Just as we have done with prysm we should namespace all related geth utilities described in apps to use geth-${utility} except proper geth.

Charon is a Proof of Stake Ethereum Distributed Validator Client. We should add support to the tool.

We're currently using a packaged version of Besu, but ideally, we should compile it from sources instead.

Let's evaluate the difficulty of packaging Besu with Nix and determine if it's worthwhile not to do it (mostly, it will depend on how gradle is configured on their end and what tricks we may perform).

Currently, running a mev-boost instance requires some configuration we can take care of by implementing a service.

There's another implementation of a relay written in Rust we should add support called mev-rs.

Hello!
While preparing #121 I realize that we use nix-update and statix from stable nixpkgs input in devShell instead of their specific inputs. I found it because nix-update from stable channel doesn't support --flake argument.

I see two ways to resolve that:

• we use these packages from related inputs with follows='nixpkgs-unstable', but we need to rebuild them cuz no caches
• we use these packages from nixpkgs-unstable (and remove nix-update and statix inputs) because it tracks the last app versions very well, and we don't need to rebuild them locally

I'd prefer the second way. What do you think about that?

Exactly as it says in the title.

Just as in nixpkgs we can find terraform supporting plugins, we should do the same with plugeth.

Manual updating is a little bit frustrating, nix-update is a huge step forward, but I suggest making a workflow similar to Updates nix flakes for updating packages (which I can update without setting specific version like in web3signer).
Do PR in next several days

Some aspect of how we are building the geth related packages with mkGeth is preventing it from working nicely with nix-update.

Migrate the repository to use and take advantage of flake.parts.

We would like to configure the nethermind client within nixos easily.

As an oversight, I defined mev-boost derivation by using mkGeth function instead of buildGoModule.

The readme is only getting bigger. We should have a more robust set of docs. I'm open to suggestions.

Whenever we want to run an Ethereum network, we usually need to execute a pair of EC (Execution Client) + Consensus client (CC).

systemd allows us to create custom targets like example below:

# named like ethereum-sepolia.target
[Unit]
Description=Ethereum Sepolia Service

# This collection of apps should be started at boot time.
[Install]
WantedBy=multi-user.target

With this, we can group related service units and control those as a group rather than per service instance:

# In a file name like [email protected]
[Unit]
Description=%I Instance of App Web Service
PartOf=ethereum-sepolia.target

[Service]
ExecStart=/Command
Restart=on-failure
StandardOutput=journal

# Service definition for i.e prysm 

# When systemctl enable is used, make this start when the App service starts
[Install]
WantedBy=ethereum-sepolia.target

With that, we can spin up the service like:

systemd start ethereum-sepolia

And systemd will start both services.

All of the above is pseudo-code that I've extracted from this StackOverflow thread and that I've modified freely as an example.

We should add support to mev-rs relay. Let's create a specific category for mev-related utilities, we can start with this one and move mev-boost as well.

Right now, we're doing the manual updates of the different packages we support, but it's cumbersome and requires manual intervention.

We can do a better job using GitHub Actions and nix-update (the first idea that comes to mind). Research is necessary be conducted to see what it's the best way of automating this.

Prysm offers a remote-signer utility for testing or running locally. We should add support for it.

This will be a more general feature eventually, but to begin with let's focus on the geth service and btrfs in particular.

The basic idea is to allow a user to specify that the datadir should be a btrfs subvolume.

Before starting the geth client, the volume should be created if it hasn't already, with default mount options of ["discard" "noatime" "nodatacow"]. If it already exists then ideally we validate the mount options match but that's not necessary for a first version.

I think we can leverage https://github.com/nix-community/disko.

@Mic92 @Lassulus any advice/recommended approaches for integrating the service in modules/geth.nix with disko to achieve the outcome above?

Secret-Shared-Validator(SSV) for ethereum staking from Blox App

Detail the overall design, how it is applied to a specific NixOS module and the various options available.

Summary

Sedge is a one-click setup tool for PoS network/chain validators and nodes written entirely in the Go programming language. Sedge takes care of the entire on-premise full node setup based on the chosen client, using generated docker-compose scripts based on the desired configuration.

Link: Sedge.

I'll try to implement that too in the same way as other modules

Solidity support can be taken from dapptools, and for foundry there is an existing nix integration maybe he can contribute it here idk