[EIP-8148]: Implement https://github.com/ethereum/EIPs/pull/12146.

[nalepae]

What type of PR is this?
Feature

What does this PR do? Why is it needed?
This pull requests only focused on implementing:

• Update EIP-8148: Allow setting the sweep threshold at deposit time. ethereum/EIPs#12146

related to EIP-8148.

It allows a validator to set a custom sweep threshold directly at deposit time.

How to test it:

Use the following kurtosis configuration file:

participants:
  - cl_type: prysm
    cl_image: prysm-bn-custom-image:latest
    vc_type: prysm
    vc_image: prysm-vc-custom-image:latest
    count: 3

network_params:
  gloas_fork_epoch: 1
  seconds_per_slot: 4

  withdrawal_type: "0x02"
  withdrawal_address: "0x8943545177806ED17B9F23F0a21ee5948eCaa776"
  validator_balance: 32 

additional_services:
  - dora
  - spamoor
  - assertoor

spamoor_params:
  image: ethpandaops/spamoor:master
  spammers:
    - scenario: eoatx
      config:
        throughput: 10
    - scenario: blobs
      config:
        throughput: 6

dora_params:
  image: dora-custom-image:latest

global_log_level: debug

The Dora docker image must be built from https://github.com/nalepae/dora.

docker build -t dora-custom-image:latest . 

Once the Gloas fork Epoch is reached, you can check the validator_sweep_thresholds values in the beacon state.

curl <beacon-url>/eth/v2/debug/beacon/states/head | jq '.data.validator_sweep_thresholds'
[
  ...
  "2048000000000",
  "2048000000000",
  "2048000000000",
  "2048000000000",
  "2048000000000",
  ...
]

Everything should be set at 2048 ETH.

Save the following assertoor test file in your system:

  id: sweep-threshold-deposit-test
  name: "EIP-8148: deposit-time sweep threshold"
  timeout: 1h
  config:
    walletPrivkey: ""
    validatorMnemonic: "trial jeans seat abstract runway cupboard please elevator club file arrow lounge crash sun thumb clock duty priority key fence funny trick diary album"
  tasks:
  - name: check_clients_are_healthy
    title: "Check if at least one client is ready"
    timeout: 5m
    config:
      minClientCount: 1

  - name: generate_deposits
    title: "Deposit a 0x02 validator with a 100 ETH sweep threshold"
    config:
      indexCount: 1
      startIndex: 400           # past the lifecycle test's 300, so keys don't collide
      depositAmount: 32         # must be <= the 100 ETH threshold, else it falls back to 2048
      depositContract: "0x00000000219ab540356cBB839Cbe05303d7705Fa"
      withdrawalCredentials: "0x0200000000000000000000648943545177806ED17B9F23F0a21ee5948eCaa776" # 0064 = 100 ETH threshold
      awaitReceipt: true
      awaitInclusion: true
      failOnReject: true 
    configVars:
      walletPrivkey: "walletPrivkey"
      mnemonic: "validatorMnemonic"

The important part is:

withdrawalCredentials: "0x0200000000000000000000648943545177806ED17B9F23F0a21ee5948eCaa776" # 0064 = 100 ETH threshold

containing the 100 ETH threshold data (0x0064) just before the withdrawal address.
and register it to Assertoor with:

curl -s -X POST <assertoor-url>/api/v1/tests/register -H "Content-Type: application/yaml" --data-binary @<path-to-the-test-yaml-file>| jq

Important

Don't forget the @ before the file path.

Once done, trigger the corresponding new validator deposit with:

curl -s -X POST <assertoor-url>/api/v1/test_runs/schedule -H "Content-Type: application/json" -d '{"test_id":"sweep-threshold-deposit-test","allow_duplicate":true,"queue":{"mode":"immediate"}}'

Once the validator is effectively deposited, you can check the validator_sweep_thresholds values in the beacon state.

curl <beacon-url>/eth/v2/debug/beacon/states/head | jq '.data.validator_sweep_thresholds'
[
  ...
  "2048000000000",
  "2048000000000",
  "2048000000000",
  "2048000000000",
  "100000000000",
]

The new (latest) validator should have the 100 ETH threshold.

Acknowledgements

• I have read CONTRIBUTING.md.
• I have included a uniquely named changelog fragment file.
• I have added a description with sufficient context for reviewers to understand this PR.
• I have tested that my changes work as expected and I added a testing plan to the PR description (if applicable).