Is your feature request related to a problem? Please describe.
The project does not have a Dockerfile, docker image, nor a CI/CD pipeline to build the docker image and publish it to Docker Hub.

Describe the solution you'd like
Create a Dockerfile, as light as possible, for this it should build the project in one stage, and copy the binary to another build stage so the image only contains the project's binary. I'm not sure if it would be good to have docker and docker-compose already installed in the image. Light Linux image. Also create a Github action to build the image manually or after every release and publish it in Docker Hub, nethermind/ repo.

Is your feature request related to a problem? Please describe.
Currently, the only supported execution client is Nethermind. We want to support client diversity so Geth needs to be integrated in 1Click.

Describe the solution you'd like
Create a docker-compose service template for geth, along with a .env template for required key:value fields on the service. Check the Nethermind template for inspiration on what things need to be configured in the docker-compose service.

Describe the bug
Both validator templates for Prysm and Lodestar are missing the depends_on property that allows the script to start the validator container only if the validator-import one ran successfully.

This can be solve adding the following to the validator service template:

depends_on: 
      validator-import:
        condition: service_completed_successfully

Is your feature request related to a problem? Please describe.
Validator keys management is one of the most complex steps in the validator setup. We must help the user to handle this step.

Describe the solution you'd like
Validator keys imports and generation can be handled using tools like eth2.0-deposit-cli. Docker-compose scripts can be used to run scripts in a controlled disconnected Linux environment. Docker-compose at this stage is a dependency so using it provokes no harm.

Is your feature request related to a problem? Please describe.
We need to offer Prometheus metrics and Grafana dashboards to the user.

Describe the solution you'd like
Grafana and Prometheus docker-compose services must be created along with updates to clients docker-compose services templates (as they must configure metrics)

Describe the bug
On my machine, mev-boost docker container can't start because of illegal instruction error.

To Reproduce

1. Run sedge cli and go thru instructions.
2. Run docker logs mev-boost
3. Observe the error. See "Additional context" for full logs.

Expected behavior
mev-boost should start.

Desktop (please complete the following information):

• OS: Ubuntu 20.04
• CPU: Intel i7-4770K

Additional context
Docker logs:

SIGILL: illegal instruction
PC=0x72a12e m=0 sigcode=2
signal arrived during cgo execution
instruction bytes: 0xf3 0x4c 0xf 0x38 0xf6 0xcf 0x66 0x4c 0xf 0x38 0xf6 0xd5 0xc4 0xe2 0xc3 0xf6

goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x70c860, 0xc000129ba8)
        runtime/cgocall.go:157 +0x5c fp=0xc000129b80 sp=0xc000129b48 pc=0x40a7bc
github.com/supranational/blst/bindings/go._Cfunc_blst_sk_to_pk2_in_g1(0x0, 0xc0001ca360, 0xc00018e320)
        _cgo_gotypes.go:1317 +0x45 fp=0xc000129ba8 sp=0xc000129b80 pc=0x67b605
github.com/supranational/blst/bindings/go.(*_Ctype_struct___4).From(...)
        github.com/supranational/[email protected]/bindings/go/blst.go:219
github.com/flashbots/go-boost-utils/bls.PublicKeyFromSecretKey(...)
        github.com/flashbots/[email protected]/bls/bls.go:40
github.com/flashbots/mev-boost/server.init()
        github.com/flashbots/mev-boost/server/mock_relay.go:25 +0xec fp=0xc000129bf0 sp=0xc000129ba8 pc=0
x709aec
runtime.doInit(0xa3d220)
        runtime/proc.go:6222 +0x126 fp=0xc000129d20 sp=0xc000129bf0 pc=0x44b9c6
runtime.doInit(0xa3ab20)
        runtime/proc.go:6199 +0x71 fp=0xc000129e50 sp=0xc000129d20 pc=0x44b911
runtime.doInit(0xa355a0)
        runtime/proc.go:6199 +0x71 fp=0xc000129f80 sp=0xc000129e50 pc=0x44b911
runtime.main()
        runtime/proc.go:233 +0x1d3 fp=0xc000129fe0 sp=0xc000129f80 pc=0x43eb53
runtime.goexit()
        runtime/asm_amd64.s:1571 +0x1 fp=0xc000129fe8 sp=0xc000129fe0 pc=0x46bb41

rax    0x0
rbx    0x8775c0
rcx    0x877040
rdx    0x7817fc679976fff5
rdi    0xc25f1572e1a87b0e
rsi    0x877540
rbp    0x2b7cd71362065849
rsp    0x7ffdd544ca88
r8     0x1f36a914d1d1ca54
r9     0xe3f09cc9f448ab2c
r10    0x53ae4ce3194e4adf
r11    0x988f6b1f351f9469
r12    0xf0030d9fa553ae92
r13    0x8e738258ad84f1f6
r14    0x685276af035ca2f
r15    0x0
rip    0x72a12e
rflags 0x10246
cs     0x33
fs     0x0
gs     0x0

/proc/cpuinfo (just first entry, the rest looks the same):

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 60
model name	: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
stepping	: 3
microcode	: 0x28
cpu MHz		: 3699.869
cache size	: 8192 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts md_clear flush_l1d
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds
bogomips	: 6999.76
clflush size	: 64
cache_alignment	: 64
address sizes	: 39 bits physical, 48 bits virtual
power management:

Using version 0.6.0, using 20.04LTS. fails at JWT secret generation, not found. Gnosischain and Ethereum

To Reproduce
sedge v0.6.0
sedge cli --network gnosis -c lighthouse -e nethermind
(sedge cli -c lighthouse -e nethermind) same result

Result
[ERRO] JWT secret generation failed. Error: open /home/glc/docker-compose-scripts/jwtsecret: no such file or directory.
No directory is created for docker-compose-scripts

Screenshots

Had dependencies installed previous already on this device,

docker-compose version
v2.2.3

attempted with fresh OS 20.04LTS and dependencies installed via sedge, same result

Additional Info:
Using Sedge Version: 0.5.0
This works still, must manually change the version for nethermind 1.14.6 > 1.15.0 to start syncing.

Is your feature request related to a problem? Please describe.
At the moment I only see 'download the latest binary' and 'build from source' installation options in the docs. This makes sedge a bit of a non-starter for me because it's going to be my job to look out for new releases and upgrade to them. If you had an Ubuntu PPA that would happen automatically.

Describe the solution you'd like
Publish a Debian package on a PPA somewhere. I hear Polkadot clients have this working, if you need an example.

Describe alternatives you've considered
Watching the GH repo and downloading the binary again on every release.

Additional context
Without this, Sedge will have legacy versions running in the field for anyone who's not super on top of looking out for new releases.

Describe the bug
Lodestar Validator client unable to find validator keys: No signers found with current args

Fixed by running validator import manually

To Reproduce
Sedge CLI
sedge cli --network gnosis -c lodestar -e nethermind

Keys Generated
sedge keys --network gnosis --eth1-withdrawal-address <my address>
Note: keys seem correct, deposit_data.json is accepted by the deposit UI, (with edit mentioned here #168)

EL and CL Synced and prompted to run the validator, but validator import service is skipped

Additional Info
Generated Scripts

  validator-import:
    container_name: validator-import-client
    image: ${VL_IMAGE_VERSION}
    networks:
    - sedge
    volumes:
    - ${KEYSTORE_DIR}:/keystore
    - ${VL_DATA_DIR}:/data
    command: |-
      validator import
      --network=${CL_NETWORK}
      --dataDir=/data
      --importKeystores=/keystore/validator_keys
      --importKeystoresPassword=/keystore/keystore_password.txt
  validator:
    container_name: validator-client
    image: ${VL_IMAGE_VERSION}
    networks:
    - sedge
    ports:
    - 5056:5056
    volumes:
    - ${VL_DATA_DIR}:/data/validator
    command:
    - validator
    - --network=${CL_NETWORK}
    - --dataDir=/data/validator
    - --logFile=/data/validator/logs/validator.log
    - --logFileLevel=${VL_LOG_LEVEL}
    - --server=${CC_API_URL}
    - --metrics=true
    - --metrics.address=0.0.0.0
    - --metrics.port=5056
    - --suggestedFeeRecipient=${CL_FEE_RECIPIENT}
    - --graffiti=${GRAFFITI}
    logging:
      driver: json-file
      options:
        max-size: 10m
        max-file: "10"
networks:
  sedge:
    name: sedge_network

.env vars

# --- Global configuration ---
EL_NETWORK=xdai
CL_NETWORK=gnosis
# --- Execution Layer - Execution Node - configuration ---
EC_IMAGE_VERSION=nethermind/nethermind:1.14.3
NETHERMIND_LOG_LEVEL=INFO
EC_ENABLED_MODULES=[Web3,Eth,Subscribe,Net,]
EC_METRICS_ENABLED=false
EC_NODENAME=Nethermind
NETHERMIND_METRICS_PUSH_GATEWAY_URL=http://localhost:9090/metrics
NETHERMIND_HEALTH_CHECKS_ENABLED=false
NETHERMIND_PRUNING_CACHEMB=2048
EC_DATA_DIR=./execution-data
EC_SNAP_SYNC_ENABLED=false
EC_JWT_SECRET_PATH=/home/glc/docker-compose-scripts/jwtsecret
# --- Consensus Layer - Beacon Node - configuration ---
CC_PEER_COUNT=50
CC_LOG_LEVEL=info
CC_LODESTAR_PRESET=gnosis
EC_API_URL=http://execution:8545
EC_AUTH_URL=http://execution:8551
CC_INSTANCE_NAME=Lodestar
CC_IMAGE_VERSION=chainsafe/lodestar:v1.1.1
CC_DATA_DIR=./consensus-data
CC_JWT_SECRET_PATH=/home/glc/docker-compose-scripts/jwtsecret
CL_FEE_RECIPIENT=< ..MY ADDRESS. >
CL_BOOTNODES="enr:-Iq4QMCTfIMXnow27baRUb35Q8iiFHSIDBJh6hQM5Axohhf4b6Kr_cOCu0htQ5WvVqKvFgY28893DHAg8gnBAXsAVqmGAX53x8JggmlkgnY0gmlwhLKAlv6Jc2VjcDI1NmsxoQK6S-Cii_KmfFdUJL2TANL3ksaKUnNXvTCv1tLwXs0QgIN1ZHCC>
CHECKPOINT_SYNC_URL=https://rpc-gbc.gnosischain.com
# --- Consensus Layer - Validator Node - configuration ---
CC_API_URL=http://consensus:4000
GRAFFITI=nethermind-lodestar
VL_LOG_LEVEL=info
VL_INSTANCE_NAME=LodestarValidator
VL_IMAGE_VERSION=chainsafe/lodestar:v1.1.1
KEYSTORE_DIR=./keystore
VL_DATA_DIR=./validator-data

Describe the bug
When using sedge as a normal user I was unable to generate keystore password file because keystore directory is owned by root.
2022-09-18 18:31:30 -- [FATA] failed to create keystore password file. Error: open /home/user/docker-compose-scripts/keystore/keystore_password.txt: permission denied

To Reproduce
Steps to reproduce the behavior:

1. Go thru sedge cli process.
2. Go thru sedge keys.
3. Observe the error message and lack of ./docker-compose-scripts/keystore/keystore_password.txt file

Expected behavior
The keystore password file should be generated and there should be no error message.

Desktop (please complete the following information):

• OS: Ubuntu 20.04

see print screen

Is your feature request related to a problem? Please describe.
The project have a README but it doesn't cover very good things like installations and usage guides. We need a proper documentation site where we can also put base knowledge and better contributing resources.

Describe the solution you'd like
Use Docusaurus as documentation engine and have it deployed to Github Pages. At least cover some quickstart guides and all the current installation methods.

Is your feature request related to a problem? Please describe.
Prysm uses a wallet in addition to the validator public key. Also has a UI for wallet creation and handling.

Describe the solution you'd like
Add a docker-compose service template for wallet creation.

Describe alternatives you've considered
We can also offer the user to opt using the Prysm UI running inside a container and exposing a port for the browser to use.

On this page:

https://docs.sedge.nethermind.io/docs/quickstart/install-guide

You use the following URL for the binary:

github.com/NethermindEth/sedge/releases/download/<VERSION>/sedge-v<VERSION>-<OS>-<ARCH>

Notice that in the first use of <VERSION>, there's no v in front but there is in the second <VERSION>. But we need v in both, actually.

I put 0.2.0 in place of both <VERSION>s and then ended up with a text file downloaded with the contents Not Found, which was confusing when I tried to run it.

Describe the bug
I have two SSDs: a small one for the OS and a big one for the chain data. The docs don't explain how to specify a path for all the chain data.

To Reproduce

1. Follow the docs to generate the config with sedge cli
2. Go into the docker-compose-scripts dir again and have a look at the files generated
3. Edit the .env file
4. Everywhere there's a *_DATA_DIR env var, and also the KEYSTORE_DIR, replace it with an absolute path that's on the larger SSD.
5. Run segde cli again, enter fee recipient address (why do I need to enter this again?)
6. When we get to Generating the environment file..., notice that my .env file changes are overwritten, or about to be.
7. Realise I should NOT have cd'ed into docker-compose-scripts! I now have another docker-compose-scripts dir underneath the first one.

Expected behavior
I thought sedge cli was going to preserve any config that already existed. When I realised it wouldn't, I also couldn't figure out how to run sedge with the config I already had on disk, rather than generating new config over the top.
Then I notice the output docker compose -f docker-compose-scripts/docker-compose.yml up -d execution consensus. So I tried running that and docker complained about the -f flag:

unknown shorthand flag: 'f' in -f

then I recalled seeing something elsewhere in the docs about running docker compose as root, so I did that and it worked.

Desktop (please complete the following information):

• OS: Ubuntu 22.04
• Version 0.2.0

https://github.com/NethermindEth/1click/blob/de0f6c4c9ce94f262e0760cc7fa40af9205e96fa/cmd/logs.go#L14

Describe the bug
When running sedge, the latest or 'stable' branch is always used. This is a mistake because clients can often change the required flags for running, configurations, and this can break the template system and therefore lead to errors

Expected behavior
Ideally, version numbers would be fixed in the templates by default, with the SHA hash given, so Sedge always tries to use images that are tested and known to work.

Describe the bug
The execution client shows

execution-client  | 2023-01-28 11:49:18.8819|Waiting for peers... 58s 
execution-client  | 2023-01-28 11:49:19.8805|Waiting for peers... 59s 
execution-client  | 2023-01-28 11:49:20.5728|Request starting HTTP/1.1 POST http://execution:8552/ application/json 1972 
execution-client  | 2023-01-28 11:49:20.5728|Received a new payload: 26190518 (0x7c64b79c530b37428ff25ef577d4c8a867ce9bc9ff18c0d0234e3b56e1f65a21) 
execution-client  | 2023-01-28 11:49:20.5728|Syncing... Parent wasn't processed. Inserting block 26190518 (0x7c64b7...f65a21). 
execution-client  | 2023-01-28 11:49:20.5728|Request finished HTTP/1.1 POST http://execution:8552/ application/json 1972 - 200 - application/json 1.0603ms 
execution-client  | 2023-01-28 11:49:20.5728|Request starting HTTP/1.1 POST http://execution:8552/ application/json 59 
execution-client  | 2023-01-28 11:49:20.5728|Executing JSON RPC call eth_syncing with params [] 
execution-client  | 2023-01-28 11:49:20.5728|Request finished HTTP/1.1 POST http://execution:8552/ application/json 59 - 200 - application/json 0.2847ms 
execution-client  | 2023-01-28 11:49:20.5942|Request starting HTTP/1.1 POST http://execution:8552/ application/json 340 
execution-client  | 2023-01-28 11:49:20.5942|Received: ForkchoiceState: (HeadBlockHash: 0x7c64b79c530b37428ff25ef577d4c8a867ce9bc9ff18c0d0234e3b56e1f65a21, SafeBlockHash: 0xa1a17b8bec26f83dad79afbd286884ffdd4e06624bd734cfdcb195fbb988855d, FinalizedBlockHash: 0xafbce30e2ef4af18451b65ad3b565d2affb807dd4cc6d7a12c38f7baa9b09390)  
execution-client  | 2023-01-28 11:49:20.5942|Syncing beacon headers... Request: ForkchoiceState: (HeadBlockHash: 0x7c64b79c530b37428ff25ef577d4c8a867ce9bc9ff18c0d0234e3b56e1f65a21, SafeBlockHash: 0xa1a17b8bec26f83dad79afbd286884ffdd4e06624bd734cfdcb195fbb988855d, FinalizedBlockHash: 0xafbce30e2ef4af18451b65ad3b565d2affb807dd4cc6d7a12c38f7baa9b09390) . 
execution-client  | 2023-01-28 11:49:20.5942|Request finished HTTP/1.1 POST http://execution:8552/ application/json 340 - 200 - application/json 0.7190ms 
execution-client  | 2023-01-28 11:49:20.5942|Request starting HTTP/1.1 POST http://execution:8552/ application/json 59 
execution-client  | 2023-01-28 11:49:20.5942|Executing JSON RPC call eth_syncing with params [] 
execution-client  | 2023-01-28 11:49:20.5942|Request finished HTTP/1.1 POST http://execution:8552/ application/json 59 - 200 - application/json 0.4291ms 
execution-client  | 2023-01-28 11:49:20.8820|Waiting for peers... 0s 
execution-client  | 2023-01-28 11:49:21.8821|Peers | with known best block: 0 | all: 0 | 
execution-client  | 2023-01-28 11:49:21.8821|Waiting for peers... 1s 
execution-client  | 2023-01-28 11:49:22.8806|Waiting for peers... 2s 

and it has not synced in a few days. The execution_data folder is around 200MB

To Reproduce
I have the following env configuration

# --- Global configuration ---
EL_NETWORK=xdai
CL_NETWORK=gnosis
# --- Execution Layer - Execution Node - configuration ---
EC_IMAGE_VERSION=nethermind/nethermind:1.14.7
NETHERMIND_LOG_LEVEL=INFO
EC_ENABLED_MODULES=[Web3,Eth,Subscribe,Net,]
EC_NODENAME=Nethermind
NETHERMIND_METRICS_PUSH_GATEWAY_URL=http://localhost:9090/metrics
NETHERMIND_PRUNING_CACHEMB=2048
EC_DATA_DIR=./execution-data
EC_SNAP_SYNC_ENABLED=true
EC_JWT_SECRET_PATH=/media/vault/siedge/jwtsecret
# --- Consensus Layer - Beacon Node - configuration ---
CC_PEER_COUNT=50
CC_LOG_LEVEL=info
EC_API_URL=http://execution:8546
EC_AUTH_URL=http://execution:8552
CC_INSTANCE_NAME=Lighthouse
CC_IMAGE_VERSION=sigp/lighthouse:v3.3.0
CC_DATA_DIR=./consensus-data
CC_JWT_SECRET_PATH=/media/vault/siedge/jwtsecret
CL_FEE_RECIPIENT=REDACTED
CHECKPOINT_SYNC_URL=https://checkpoint.gnosischain.com
CL_BOOTNODES="REDACTED"
# --- Consensus Layer - Validator Node - configuration ---
CC_API_URL=http://consensus:4000
GRAFFITI=nethermind-lighthouse
VL_LOG_LEVEL=info
VL_INSTANCE_NAME=LighthouseValidator
VL_IMAGE_VERSION=sigp/lighthouse:v3.3.0
KEYSTORE_DIR=./keystore
VL_DATA_DIR=./validator-data

Describe the bug
We are using network_mode: host in our docker-compose services. According to docker docs:

The host networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.

Solution
Bind or expose directly the ports used by the services.

Is your feature request related to a problem? Please describe.
Currently, test coverage is zero. This is a critical problem and must be solved soon.

Describe the solution you'd like
Unit test and integration test must be made. End-to-end test must be integrated to the CI\CD pipelines and should use docker environments.

Is your feature request related to a problem? Please describe.
Machines running a validator setup can be vulnerable to network attacks. State of the art security measures can be offered to the user especially in Linux VMs. One example of one security measure is a firewall setup.

Describe the solution you'd like
A firewall can be configured using ufw for the ports involved. Even the user IP address can be whitelisted and the rest blacklisted. All of this must be optional and fully described to the user.

Is your feature request related to a problem? Please describe.
It would be helpful for the users to know if their machines satisfy the hardware requirements for the validator on-premise setup. Giving the option in the TUI (when it is done) to show minimum hardware requirements can also be a good feature.

Describe the solution you'd like
Two things can be done:

• Display minimum hardware requirements
• Give the user the option to execute a hardware test

Is your feature request related to a problem? Please describe.
Currently, Linux is the only full supported OS. This can be enough for off-premise setup, but for off-premise setup we need to extend full support for Windows and Darwin systems at least.

Current issues than an be addressed:
1- Dependencies installation instructions and installation capabilities as well
2- Correct use of path delimiter (/) (OS wise)
3- Docker engine usability

Describe the solution you'd like
Issues 1 and 3 should be solved doing some research first. Windows and Darwin require Docker Desktop installed and running in order to use the application. Also it would be good to embed only installation scripts for the target OS build.

Issue 2 can be solved with some sort of logic that get first the current OS and then use the correct delimiter. Another solution is using GOOS and GOARCH build tags (https://www.digitalocean.com/community/tutorials/building-go-applications-for-different-operating-systems-and-architectures)

Is your feature request related to a problem? Please describe.
Some consensus clients allow configurable execution fallback nodes. We should allow the user to opt for this. The same for initial state endpoints/checkpoints sync for consensus nodes.

Describe the solution you'd like
Research which clients allow the respective feature and update the templates accordingly. User can add the fallback nodes/checkpoint syncs URLs using flags or from prompt input.

Describe the bug
I just tested the newest version 1.0.0! Great work so far! also a very nice interactive mode (cli).

I used a setup with nethermind & teku in the past (sedge 0.5 & 0.6 had now problems).
With the newest version(1.0.0) I get a restarting/crashing teku docker container.
Logs are saying: Cannot write to folder /var/lib/teku/validator/slashprotection even it is supposed to write to ./sedge-data (default).

I have not changed any locations, mount points or .env configs (default).
I only used the CLI.

I also tested it with other consensus clients, no problems so far!
Must be a specific teku problem.

Kind regards & keep up your great work!

To Reproduce
Steps to reproduce the behavior:

1. Go to 'sedge cli'
2. Chose Gnosis
3. Chose Nethermind
4. Chose TEku
   ...

Expected behavior
At least 2 running containers

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Ubu22.04
• Sedge 1.0.0

Run through setup with fully synced, EL+CL clients and imported validators awaiting activation.
However, seems that the deposit_data.json is the ‘wrong network’

To Reproduce
Run through set up normally to get working EL & CL, and validator client, awaiting activation
Keys Generated
sedge keys --network gnosis

Screenshots

Is your feature request related to a problem? Please describe.
Kiln is a testnet used for Ethereum The Merge development process. Much development and testing effort can be gained from supporting this testnet

Describe the solution you'd like
Rethink and redesign the docker-compose scripts generation. We can maintain templates for the services, client wise, and for the networks have a set of arguments/flags/options for the involved commands. This would need new embedded client wise templates and can be used to check which networks we support.

Describe alternatives you've considered
We might need new docker-compose services for this network. This is the least breaking solution.

It is a priority for sedge users, to run an updated node and an updated version of sedge.

When the app starts, we should check that we don't have a new release available on GitHub, and if that is the case, tell the user that they need to upgrade the app.

We need to embed on the app the version running at compilation time, and check that version against GitHub.

Is your feature request related to a problem? Please describe.
The tool currently launch execution and consensus clients and the user needs to wait for those clients to sync to register and run the validator node, or the user is vulnerable to downtimes.

Describe the solution you'd like
The monitoring tool referred in #31 Posmoni is now able to track sync progress for execution and consensus nodes. It offer an interface we can use to track the sync progress of those nodes and after they are synced start the validator node. Instructions to the user should be displayed to have prepared the validator keys and register the validator when the time comes.

Additional context
This issue is also related to #14. In the future, better details about the tracking progress should be made, like percentage or ETA.

Using sedge v0.5.1 because the newest version wouldn't let me create JWT Secret.

For the last 3 days I have been syncing my consensus nodes and execution nodes. This is the command that I ran to set it up

sedge cli --network mainnet -c prysm -e geth

After everything gets synced up, a few days later i get prompted Would you like to run validator service? When I hit Y then it runs the following docker compose

docker compose -f docker-compose-scripts/docker-compose.yml up -d validator

After this runs, I get the following error

[ERRO] command 'docker compose -f docker-compose-scripts/docker-compose.yml up -d validator' throws error: exit status 1

Any idea how to fix this? The error code isn't helpful as it doesn't say why it is throwing an error

Is your feature request related to a problem? Please describe.
Ropsten is a post-merge testnet used a lot recently for Ethereum The Merge development process. Much development and testing effort can be gained from supporting this testnet. Also support mev-boost.

Describe the solution you'd like
Create .env templates for Ropsten, along with any new change its required for merge services templates. Add a mev-boost service for the clients supporting it.

Is your feature request related to a problem? Please describe.
Right now commands are build and executed separately. Also the same command is build in different places making difficult to modify this process.

Describe the solution you'd like
A centralized structure that offer a unique API for building and executing commands with solve this problem. Also it must be extensible enough to allow different implementations of this API so it can be used to help in the problems described in #21 and #12.

Describe the bug
Running wget https://github.com/NethermindEth/sedge/releases/download/v0.5.0/sedge-v0.5.0-linux-arm64 -O sedge for an version above 0.3.0 returns the following when trying to run ./sedge.

~/gnosis-validator $ ./sedge 
bash: ./sedge: No such file or directory

To Reproduce
Steps to reproduce the behavior:

1. Go to https://docs.sedge.nethermind.io/docs/quickstart/complete-guide
2. Follow the install instructions, updating amd64 to arm64 for using a raspberry pi.
3. run chmod +x sedge
4. run ./sedge

Expected behavior
I expect the CLI tool to start up

Desktop (please complete the following information):

• OS: PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
  NAME="Raspbian GNU/Linux"
  VERSION_ID="10"
  VERSION="10 (buster)"

Additional context
Add any other context about the problem here.
running go version go1.19.4 linux/arm

Describe the bug
While generating the files, we print the resulting config. In this print, instead of the file directly, we are publishing it as a []byte.

To Reproduce
Steps to reproduce the behavior:

1. Compile sedge running make compile
2. run ./build/sedge cli
3. Introduce a fee address any
4. See the error, a full array of bytes as numbers are displayed instead of the generated string.

Expected behavior
Print the config in a readable way, not as a byte array.

Describe the bug
For the validator setup, Sedge first runs the execution and consensus clients. Then we track the sync progress of the EL and CL and after they are synced the validator can be executed automatically. In MacOS it seems that the track sync step is not working ok.

To Reproduce
Steps to reproduce the behavior:

1. Run sedge cli -y
2. Wait for the Track sync to happen
3. See the request failing:

Expected behavior
not fail

Screenshots

2022-09-30 15:44:32 -- [INFO] [ETH2 Monitor] [TrackSync] Tracking sync progress of consensus nodes...
2022-09-30 15:45:02 -- [ERRO] [GetRequest] request failed. Error: Get "http://172.19.0.3:4000/eth/v1/node/syncing": dial tcp 172.19.0.3:4000: i/o timeout
2022-09-30 15:45:02 -- [INFO] [GetRequest] Retrying request
2022-09-30 15:45:33 -- [ERRO] [GetRequest] request failed. Error: Get "http://172.19.0.3:4000/eth/v1/node/syncing": dial tcp 172.19.0.3:4000: i/o timeout
2022-09-30 15:45:33 -- [INFO] [GetRequest] Retrying request

Desktop (please complete the following information):

• OS: MacOS

Describe the bug

• Using a Macbook M1 chip, installed Docker's latest version and used Sedge V0.5.0. - this step is successful see below

• Second step asks for Run the script with the selected services execution, consensus: Y, at this step it shows following error and exit the process.

tried again using following
sedge cli --network gnosis -c lighthouse -e nethermind

and got the following error

Is your feature request related to a problem? Please describe.
The beacon nodes or consensus nodes offer a API with which you can check things such as validator and sync status. We would provide good access to such API so it would be great to use it to give the user useful information.

Describe the solution you'd like
A new cmd can be made to make requests given a network, because Ethereum API may be different from other PoS network to which we can add support. At least we should implement:

• Check sync status
• Check validator status and performance. This involves checking balance, missed attestations, etc.

Additional context
This can be used for alerting support

We should use the following image on Dark theme:

And the following one on Light themes:

Describe the bug
After the reboot validator container fails to start.

To Reproduce

1. Make sure all containers are running.
2. Reboot.
3. Run docker ps.
4. Observer the validator-client container is missing in the output.

Expected behavior
validator-client container should be running.

Screenshots

$ sudo docker compose up -d
[+] Running 5/5
 ⠿ Container validator-import-client  Exited                                                                                                                                                                    2.8s
 ⠿ Container execution-client         Running                                                                                                                                                                   0.0s
 ⠿ Container mev-boost                Running                                                                                                                                                                   0.0s
 ⠿ Container consensus-client         Running                                                                                                                                                                   0.0s
 ⠿ Container validator-client         Started                                                                                                                                                                   3.2s
$ sudo docker ps
CONTAINER ID   IMAGE                                 COMMAND                  CREATED          STATUS          PORTS                                                                                                                                                              NAMES
92332169e6b1   sigp/lighthouse:v3.1.0                "lighthouse bn --dis…"   26 minutes ago   Up 54 seconds   0.0.0.0:5054->5054/tcp, :::5054->5054/tcp, 4000/tcp, 0.0.0.0:9000->9000/tcp, :::9000->9000/tcp, 0.0.0.0:9000->9000/udp, :::9000->9000/udp                          consensus-client
a962817ccf5f   flashbots/mev-boost:latest-portable   "/app/mev-boost -add…"   26 minutes ago   Up 54 seconds   18550/tcp                                                                                                                                                          mev-boost
9b0d73f15e89   sigp/lighthouse:v3.1.0                "lighthouse vc --net…"   49 minutes ago   Up 8 seconds    0.0.0.0:5056->5056/tcp, :::5056->5056/tcp                                                                                                                          validator-client
ec60866c7291   ethereum/client-go:v1.10.23           "geth --override.ter…"   49 minutes ago   Up 54 seconds   8545-8546/tcp, 0.0.0.0:8008->8008/tcp, :::8008->8008/tcp, 0.0.0.0:30303->30303/tcp, :::30303->30303/tcp, 8551/tcp, 0.0.0.0:30303->30303/udp, :::30303->30303/udp   execution-client
$ sudo docker ps
CONTAINER ID   IMAGE                                 COMMAND                  CREATED          STATUS              PORTS                                                                                                                                                              NAMES
92332169e6b1   sigp/lighthouse:v3.1.0                "lighthouse bn --dis…"   26 minutes ago   Up About a minute   0.0.0.0:5054->5054/tcp, :::5054->5054/tcp, 4000/tcp, 0.0.0.0:9000->9000/tcp, :::9000->9000/tcp, 0.0.0.0:9000->9000/udp, :::9000->9000/udp                          consensus-client
a962817ccf5f   flashbots/mev-boost:latest-portable   "/app/mev-boost -add…"   26 minutes ago   Up About a minute   18550/tcp                                                                                                                                                          mev-boost
9b0d73f15e89   sigp/lighthouse:v3.1.0                "lighthouse vc --net…"   50 minutes ago   Up 48 seconds       0.0.0.0:5056->5056/tcp, :::5056->5056/tcp                                                                                                                          validator-client
ec60866c7291   ethereum/client-go:v1.10.23           "geth --override.ter…"   50 minutes ago   Up About a minute   8545-8546/tcp, 0.0.0.0:8008->8008/tcp, :::8008->8008/tcp, 0.0.0.0:30303->30303/tcp, :::30303->30303/tcp, 8551/tcp, 0.0.0.0:30303->30303/udp, :::30303->30303/udp   execution-client
$ sudo reboot

[...]

$ sudo docker ps
CONTAINER ID   IMAGE                                 COMMAND                  CREATED          STATUS          PORTS                                                                                                                                                              NAMES
92332169e6b1   sigp/lighthouse:v3.1.0                "lighthouse bn --dis…"   28 minutes ago   Up 55 seconds   0.0.0.0:5054->5054/tcp, :::5054->5054/tcp, 4000/tcp, 0.0.0.0:9000->9000/tcp, :::9000->9000/tcp, 0.0.0.0:9000->9000/udp, :::9000->9000/udp                          consensus-client
a962817ccf5f   flashbots/mev-boost:latest-portable   "/app/mev-boost -add…"   28 minutes ago   Up 55 seconds   18550/tcp                                                                                                                                                          mev-boost
ec60866c7291   ethereum/client-go:v1.10.23           "geth --override.ter…"   52 minutes ago   Up 55 seconds   8545-8546/tcp, 0.0.0.0:8008->8008/tcp, :::8008->8008/tcp, 0.0.0.0:30303->30303/tcp, :::30303->30303/tcp, 8551/tcp, 0.0.0.0:30303->30303/udp, :::30303->30303/udp   execution-client

Desktop (please complete the following information):

• OS: Ubuntu 20.04

Describe the bug
Hi! I can't compile the latest version with vendoring

go mod vendor
go: downloading github.com/stretchr/testify v1.8.2
go: downloading gotest.tools/v3 v3.4.0
go: downloading github.com/golang/mock v1.6.0
go: downloading github.com/jarcoal/httpmock v1.2.0
go: downloading github.com/Microsoft/go-winio v0.6.0
go: downloading golang.org/x/tools v0.6.0
go: downloading golang.org/x/mod v0.8.0
github.com/NethermindEth/sedge/cli tested by
        github.com/NethermindEth/sedge/cli.test imports
        github.com/NethermindEth/sedge/mocks: no required module provides package github.com/NethermindEth/sedge/mocks; to add it:
        go get github.com/NethermindEth/sedge/mocks

To Reproduce
I use NixOS and I'm trying to package the latest version, nix uses vendoring to store dependencies, but I can't do go mod vendor due to error

Expected behavior
I should be able to compile the app with vendoring

Describe the bug
Error fetching finalized block from remote using checkpoint.gnosischain.com.

execution-client  | 2022-12-27 16:44:10.9936|Waiting for peers... 43s 
execution-client  | 2022-12-27 16:44:11.9929|Waiting for peers... 44s 
consensus-client  | Dec 27 16:44:12.244 CRIT Failed to start beacon node             reason: Error fetching finalized block from remote: Reqwest(reqwest::Error { kind: Request, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("checkpoint.gnosischain.com")), port: None, path: "/eth/v2/beacon/blocks/finalized", query: None, fragment: None }, source: TimedOut })
consensus-client  | Dec 27 16:44:12.244 INFO Internal shutdown received              reason: Failed to start beacon node
consensus-client  | Dec 27 16:44:12.244 INFO Shutting down..                         reason: Failure("Failed to start beacon node")
consensus-client  | Failed to start beacon node
consensus-client exited with code 1
execution-client  | 2022-12-27 16:44:12.9938|Waiting for peers... 45s 
consensus-client  | Dec 27 16:42:12.195 INFO Logging to file                         path: "/var/lib/lighthouse/beacon/logs/beacon.log"
consensus-client  | Dec 27 16:42:12.195 INFO Lighthouse started                      version: Lighthouse/v3.3.0-bf533c8
consensus-client  | Dec 27 16:42:12.195 INFO Configured for network                  name: gnosis
consensus-client  | Dec 27 16:42:12.195 INFO Data directory initialised              datadir: /var/lib/lighthouse
consensus-client  | Dec 27 16:42:12.196 WARN Ignoring --eth1-endpoints flag          info: the value for --execution-endpoint will be used instead. --eth1-endpoints has been deprecated for post-merge configurations
consensus-client  | Dec 27 16:42:12.196 INFO Deposit contract                        address: 0x0b98057ea310f4d31f2a452b414647007d1645d9, deploy_block: 19469077
consensus-client  | Dec 27 16:42:12.225 INFO Starting checkpoint sync                remote_url: https://checkpoint.gnosischain.com/, service: beacon
consensus-client  | Dec 27 16:43:12.236 WARN Remote BN does not support EIP-4881 fast deposit sync, error: Error fetching deposit snapshot from remote: Reqwest(reqwest::Error { kind: Request, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("checkpoint.gnosischain.com")), port: None, path: "/eth/v1/beacon/deposit_snapshot", query: None, fragment: None }, source: TimedOut }), service: beacon
consensus-client  | Dec 27 16:44:12.244 CRIT Failed to start beacon node             reason: Error fetching finalized block from remote: Reqwest(reqwest::Error { kind: Request, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("checkpoint.gnosischain.com")), port: None, path: "/eth/v2/beacon/blocks/finalized", query: None, fragment: None }, source: TimedOut })
consensus-client  | Dec 27 16:44:12.244 INFO Internal shutdown received              reason: Failed to start beacon node
consensus-client  | Dec 27 16:44:12.244 INFO Shutting down..                         reason: Failure("Failed to start beacon node")
consensus-client  | Failed to start beacon node
consensus-client  | Dec 27 16:44:13.036 INFO Logging to file                         path: "/var/lib/lighthouse/beacon/logs/beacon.log"
consensus-client  | Dec 27 16:44:13.037 INFO Lighthouse started                      version: Lighthouse/v3.3.0-bf533c8
consensus-client  | Dec 27 16:44:13.037 INFO Configured for network                  name: gnosis
consensus-client  | Dec 27 16:44:13.037 INFO Data directory initialised              datadir: /var/lib/lighthouse
consensus-client  | Dec 27 16:44:13.037 WARN Ignoring --eth1-endpoints flag          info: the value for --execution-endpoint will be used instead. --eth1-endpoints has been deprecated for post-merge configurations
consensus-client  | Dec 27 16:44:13.038 INFO Deposit contract                        address: 0x0b98057ea310f4d31f2a452b414647007d1645d9, deploy_block: 19469077
consensus-client  | Dec 27 16:44:13.085 INFO Starting checkpoint sync                remote_url: https://checkpoint.gnosischain.com/, service: beacon
execution-client  | 2022-12-27 16:44:13.9938|Peers | with known best block: 0 | all: 0 | 

To Reproduce
Steps to reproduce the behavior:

1. setup sedge with the following .env

# --- Global configuration ---
EL_NETWORK=xdai
CL_NETWORK=gnosis
# --- Execution Layer - Execution Node - configuration ---
EC_IMAGE_VERSION=nethermind/nethermind:1.14.7
NETHERMIND_LOG_LEVEL=INFO
EC_ENABLED_MODULES=[Web3,Eth,Subscribe,Net,]
EC_NODENAME=Nethermind
NETHERMIND_METRICS_PUSH_GATEWAY_URL=http://localhost:9090/metrics
NETHERMIND_PRUNING_CACHEMB=2048
EC_DATA_DIR="/media/Extreme SSD/gnosis-data/execution-data"
EC_SNAP_SYNC_ENABLED=false
EC_JWT_SECRET_PATH=/home/user/gnosis-validator/docker-compose-scripts/jwtsecret
# --- Consensus Layer - Beacon Node - configuration ---
CC_PEER_COUNT=50
CC_LOG_LEVEL=info
EC_API_URL=http://execution:8545
EC_AUTH_URL=http://execution:8551
CC_INSTANCE_NAME=Lighthouse
CC_IMAGE_VERSION=sigp/lighthouse:v3.3.0
CC_DATA_DIR="/media/Extreme SSD/gnosis-data/consensus-data"
CC_JWT_SECRET_PATH=/home/user/gnosis-validator/docker-compose-scripts/jwtsecret
CL_FEE_RECIPIENT=0x7D678b9218aC289e0C9F18c82F546c988BfE3022
CHECKPOINT_SYNC_URL=https://checkpoint.gnosischain.com
CL_BOOTNODES="enr:-Iq4QMCTfIMXnow27baRUb35Q8iiFHSIDBJh6hQM5Axohhf4b6Kr_cOCu0htQ5WvVqKvFgY28893DHAg8gnBAXsAVqmGAX53x8JggmlkgnY0gmlwhLKAlv6Jc2VjcDI1NmsxoQK6S-Cii_KmfFdUJL2TANL3ksaKUnNXvTCv1tLwXs0QgIN1ZHCCIyk,enr:-Ly4QFoZTWR8ulxGVsWydTNGdwEESueIdj-wB6UmmjUcm-AOPxnQi7wprzwcdo7-1jBW_JxELlUKJdJES8TDsbl1EdNlh2F0dG5ldHOI__78_v2bsV-EZXRoMpA2-lATkAAAcf__________gmlkgnY0gmlwhBLYJjGJc2VjcDI1NmsxoQI0gujXac9rMAb48NtMqtSTyHIeNYlpjkbYpWJw46PmYYhzeW5jbmV0cw-DdGNwgiMog3VkcIIjKA,enr:-KG4QE5OIg5ThTjkzrlVF32WT_-XT14WeJtIz2zoTqLLjQhYAmJlnk4ItSoH41_2x0RX0wTFIe5GgjRzU2u7Q1fN4vADhGV0aDKQqP7o7pAAAHAyAAAAAAAAAIJpZIJ2NIJpcISlFsStiXNlY3AyNTZrMaEC-Rrd_bBZwhKpXzFCrStKp1q_HmGOewxY3KwM8ofAj_ODdGNwgiMog3VkcIIjKA,enr:-L64QC9Hhov4DhQ7mRukTOz4_jHm4DHlGL726NWH4ojH1wFgEwSin_6H95Gs6nW2fktTWbPachHJ6rUFu0iJNgA0SB2CARqHYXR0bmV0c4j__________4RldGgykDb6UBOQAABx__________-CaWSCdjSCaXCEA-2vzolzZWNwMjU2azGhA17lsUg60R776rauYMdrAz383UUgESoaHEzMkvm4K6k6iHN5bmNuZXRzD4N0Y3CCIyiDdWRwgiMo"
# --- Consensus Layer - Validator Node - configuration ---
CC_API_URL=http://consensus:4000
GRAFFITI=nethermind-lighthouse
VL_LOG_LEVEL=info
VL_INSTANCE_NAME=LighthouseValidator
VL_IMAGE_VERSION=sigp/lighthouse:v3.3.0
KEYSTORE_DIR=./keystore
VL_DATA_DIR="/media/Extereme SSD/gnosis-data/validator-data"

3. start nodes sudo docker compose -f docker-compose.yml up -d execution consensus
4. see errors

Expected behavior
consensus node should start syncing

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: ubuntu 22

Describe the bug
Download instructions in "Installation guide" doesn't include -o/--output options, therefore "sedge" binary is not being created.
"Complete quickstart guide" includes correct options. Therefore wget/curl line from "Complete quickstart guide" should be copied to "Installation guide".

To Reproduce
Steps to reproduce the behavior:

1. Open Installation guide
2. Perform steps 1-4.
3. Observe "command not found" error.

Expected behavior
Binary should be named sedge not sedge-v0.3.0-linux-amd64.

Is your feature request related to a problem? Please describe.
Prater network is beacon chain de facto testnet. We must support it.

Describe the solution you'd like
Get correct env values for the Prater network. Beacon chain docker-compose services should be fine, although we need to make sure that nothing additional is needed.

Additional context
This needs to be tested rigorously. It can be a good moment to add more clients.

Consider adding the ultra sound relay in addition to the FlashBots relay :)

Is your feature request related to a problem? Please describe.
Along with Prometheus and Grafana features provided for every single beacon client, we could provide a monitoring tool using the Beacon Chain API, for balance and attestation check.

Describe the solution you'd like
Subscribing to finalized checkpoints events, and tracking balances changes, might be enough for at least a first version of this tool. For alerting, it should be integrated for Slack, Email, Opsgenie and maybe Discord and Telegram. All of this using the Beacon Chain official API to allow integration with any consensus client.

Additional context
The solution follow the approach adopted here

Make it easy to deploy the Nethermind client on Google Cloud
Users could leverage the free tier to get started.

Overview
A simple deployment as a VM.

1. Create a GCE instance (Virtual Machine)
2. Generate default config files: sedge generate full-node
3. Start the ETH client: sedge run

Describe the bug
Teku Validator client unable to find validator keys

To Reproduce
Start Sedge with network Gnosis and Teku for CL client. once synced start the validator.

had sedge started up a day ago, EL and CL clients synced okay. prompted to start the validator (at this point did not generate keys yet)
Not able to access the 'validator-data' folder until I changed permissions

keys generated restart validator client
sedge keys --network gnosis
places keys in ./keystore/validator_keys and password.txt in ./keystore

Teku is looking for keys in --validator-keys=/data/keys:/data/passwords
I think Teku requires password file per validator with same name structure but .txt extension

Tried to Import validators
ran the container to import the keys, and restarted the validator client
same error and looks like the validators are imported to
./validator-data/validators

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

I would like to stop validating, and according to The Ethereum Launchpad's section on exiting I need to send a voluntary exit message via my validator node. However, there is no command in the CLI, nor can I find anything in the docs, pertaining to voluntary exits.

Describe the solution you'd like
A clear and concise description of what you want to happen.

I would like 2 things to happen, though one of them is optional:

1. Add a sedge validator-exit command that offers a similar interface as a consensus client's exit command so I can exit my validtor
2. Documentation on how to do this at https://docs.sedge.nethermind.io/docs/intro.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

I've considered manually exec'ing into my validator node's docker container and entering in the appropriate command to voluntarily exit. But this is error prone because it relies on me copy & pasting CLI arguments from my docker-compose and .env config files. Plus I'm not confident enough with Docker to know if this is how I should do it or if this is actually bad, and I should do it some other way.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.
Slashers are the police of the beacon chain. Why not add support for creating slashers nodes with Sedge?