Skip to content

Conversation

@zilm13
Copy link
Contributor

@zilm13 zilm13 commented Mar 3, 2025

Implementation of incident intervals in Teku

  • Dirty hack is made to use incident intervals only after client restart, because I didn't find a better way to use different flags/config in Kurtosis only after restart in the middle.
  • 2 changes are not yet added to the spec and should be clarified
    • exception when trying to produce Attestation in incident interval in getGenericAttestationData
    • failed broadcast validation in BlockManager for blocks inside incident interval, so local block produced during incident interval is not published (otherwise it will be published even with failed block import)

recover.yaml for Kurtosis

participants:
  - el_type: geth
    cl_type: teku
    cl_extra_params: [
        --validators-keystore-locking-enabled=false,
	--Xincident-intervals=1-2
    ]
    cl_image: consensys/teku:develop
    cl_min_cpu: 2000
    cl_min_mem: 2000
    count: 5
network_params:
  electra_fork_epoch: 1
global_log_level: info
additional_services:
  - dora
  - spamoor_blob
  - prometheus_grafana

Steps to reproduce expected scenario:

# build Teku and save in local Docker repository
% ./gradlew distDocker 
# start Kurtosis with the provided config
% ./kurtosis run --enclave my-testnet github.com/ethpandaops/ethereum-package --args-file recover.yaml

On the start of epoch 1 stop 2-5 nodes and start them again (so incident intervals will be applied after restart):

% kurtosis service stop my-testnet cl-2-teku-geth                                                  
% kurtosis service stop my-testnet cl-3-teku-geth
% kurtosis service stop my-testnet cl-4-teku-geth
% kurtosis service stop my-testnet cl-5-teku-geth


% kurtosis service start my-testnet cl-2-teku-geth
% kurtosis service start my-testnet cl-3-teku-geth
% kurtosis service start my-testnet cl-4-teku-geth
% kurtosis service start my-testnet cl-5-teku-geth

@zilm13 zilm13 marked this pull request as draft March 3, 2025 23:30
@zilm13
Copy link
Contributor Author

zilm13 commented Mar 3, 2025

Expected behavior:

chain created by node-1 during epochs 1-2 is orphaned
imagen

chain derived on the side from epoch 3 is finalized
imagen

There are some issues with prototype so we don't see 100% at this moment, but I will not focus on this issue at the current stage (need to abandon already imported blocks during incident intervals probably)

@zilm13 zilm13 added the DO NOT MERGE Not ready to merge label Mar 4, 2025
Comment on lines +277 to +279
"Sets the interval where network is considered to be in incident. "
+ "All the slots in these epochs should be empty. Any chain with blocks "
+ "inside interval is considered invalid.",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hrm so thats interesting, im not sure any epochs were completely empty...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's expected that it must fork so all the slots inside incident intervals are completely empty

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

DO NOT MERGE Not ready to merge

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants