umbracle/eth2-validator

Eth2-validator is an easy to use, performant and flexible Ethereum validator client.

eth2-validator's Issues

Enable fork transitions in e2e framework

The e2e framework should be parametrizable to transition forks.

Use state of duties

The Duty object has a state field (Pending, Queued, Confirmed...) which is not being used right now.

Run `beacon-clients` with genesis state

Right now, it is necessary to deploy an eth1 client, deploy the deposit contract and make a deposit transaction before starting the eth2 beacon clients. Though this workflow is required for some types of tests (i.e. validator waiting to be validated), most of the tests would benefit from a genesis state with the validators.

Import EIP-3076 data

Introduce a new CLI command to load an EIP-3076 file.

Add Keymanager API

https://ethereum.github.io/keymanager-APIs/

Note that this API is a complement of the internal Grpc server.

Add unit testing for the Beacon http library

Initially, the idea was to follow the same pattern as ethgo in order to test the HTTP client library, this is, to run a real client and make queries to the endpoints. However, it happens to be a bit more complicated in this setting, since some endpoints require building complex logic (outside the scope of the HTTP package itself) to have access to the data. Thus, we need to think about a different strategy.

Subscribe to sync committee subnets

The validator must notify the beacon node to subscribe to subnets if it is validator for a committee.

Fix scheduling of future duties

Right now, all the duties are scheduled for the current starting epoch. However, there are some duties that are available beforehand.

Fix `Prysm` simple e2e test

Add `Attestation aggregate` duty

Add the Attestation aggregate duty of the phase0 fork.

Add `SyncCommitteeAggregator` duty

Add the sync committee aggregator duty from the Altair hard fork.

Handle beacon chain reorgs

Add `Altair` structs and spec tests

Introduce the Altair spec structs for BeaconBlock and update the spec tests accordingly.

Multi-node e2e cluster

As of now, the testutil framework only deploys single node (1 beacon, 1 validator) devnets. The framework should be able to provision and configure multi-node devnets both with the same client and multi-client.

Add `nimbus` client

Add nimbus client to the e2e framework.

Export EIP-3076 data from a validator

The client should be able to export the EIP-3076 slashing protection data for a given validator.

Enable EIP-3076 slashing protection

The client should comply with the EIP-3076 slashing conditions.

• Block proposal.
• Attest proposal.

Add integration test for phase0

Add an integration test that deploys a devnet (with Teku) and runs the validator.

Embed `bls` types in `consensus` structs

Right now, the consensus types have many instances of the type:

type DepositData struct {
	Pubkey                []byte   `json:"pubkey" ssz-size:"48"`
	WithdrawalCredentials []byte   `json:"withdrawal_credentials" ssz-size:"32"`
	Amount                uint64   `json:"amount"`
	Signature             []byte   `json:"signature" ssz-size:"96"`
	Root                  [32]byte `ssz:"-"`
}

where Signature and PubKey are fixed-size arrays that represent BLS signature and public key. In order to use this structure eventually, those fields have to be converted to golang objects for the blst library.

Thus, it would be straightforward if we could use the bls objects directly as a wrapper like:

type DepositData struct {
      PubKey     bls.PubKey     `json:"pubkey"`
      ...
      Signature  bls.Signature  `json:"signature"`
}

Note that this does not cause any problems to the fastssz hashing since it already support aliases like this.

Fix `Lighthouse` simple e2e test

Add metrics

Add bitlist library

In order to aggregate attestation, the validator has to support and manage bitlists. The mock of the library is already there under internal/lib/bitlist.

Update `go-web3` to `ethgo`

Replace the old go-web3 version with the new ethgo.

Support Phase0

This is a tracking issue to follow the development to support the phase0 fork.

• Submit attestation.
• Submit propose block.

Reload beacon config during forks

The config spec changes after a fork, the client must be able to reload it. The main concern is how to protect the config for the concurrent read/write.

Run `e2e framework` test with low `slotPerEpoch` and `secondsPerEpoch` values

Right now, running the simple set of tests for the beacon chain clients takes a long time since it uses a default config with 12 secondsPerEpoch and 32 slotPerEpoch. Those fields should be configurable.

Add `e2e` command to deploy a development network

Add a new e2e deploy command that deploys an end-to-end devnet.

Add validator lifecycle manager

The validator client should be able to handle the lifecycle of new validators being tracked: adding, waiting to be ready, exiting...

Calculate domain should account for forks

Right now the calculation of the domain is hardcoded to either phase0 or altair. Once the validator has the config.yaml available #41 it should be possible to calculate the domain depending on the fork.

Add validator store

Add a store to save the validators.

Store produced blocks and attestations

The client needs to store the jobs produced by the client, in the case of phase0 this is block productions and attestations.

Add spec tests to `consensus` types

This repo contains a set of spec tests to test encoding/decoding/hashing of the consensus objects (i.e. BeaconBlock, BeaconBodyBlock...).

Load `config.yaml` spec from beacon node

On a fresh start, the validator should query the beacon node to download the config.yaml spec and store it internally. Then, on future interactions it should query the beacon node to check if the spec matches and to refresh it if necessary.

Add `SyncCommittee` duty

Integrate SyncCommittee duty from the Altair fork.

Add CI

Add a CI step to run the unit tests in the repo.

Fix Blst invalid instruction on CI

CI fails randomly on blst invalid instruction.