# How to create a shadowfork ## Introduction: ![shadowfork](https://storage.googleapis.com/ethereum-hackmd/upload_218accdf38cf256ef05f50d64d4a3ba0.png) ### Theory: #### General info: - A chain consists of an Execution layer(EL) and a Consensus layer(CL) - The EL is responsible for state (transactions, history, etc) and the CL is responsible for consensus (agreement on chain head) at a high level - The EL is driven by the CL. i.e, The CL decides what the head of the chain is and the EL must accept that decision (mostly) - The CL asks the EL to produce blocks, these blocks are placed in the EL chain as well as `execution_payloads` in the CL slot. This links the CL slot to the EL chain (leaving out caveats here) - When the CL sends the request to produce a block, it also sends information about the block to build on top of #### Shadowfork: - Sync a known chain to the head of the chain. E.g, we sync Holesky till both the EL and CL are fully synced - Stop the CL beacon node. This means the EL will get no new messages about the chain and will forever stall at its current head. Ensure all the ELs on your planned shadowfork are stalled at the same head (helps to use a script to achieve this) - Get the latest block by using the `eth_getBlockByNumber` from any EL (since they are all on the same head) - Now generate a new CL genesis state, with a genesis timestamp in the future, pre-populated validators in the genesis state and the latest EL block from the earlier step as the `execution_payload` - Copy the EL genesis config for that network, i.e Holesky - In case a non-mainline fork is needed, e.g Holesky hasn't gone through Cancun but the shadowfork should go through it. Then define the cancun fork in the CL config.yaml as well as the EL genesis files - Clear the CL data on all the nodes, this includes removing their data directories. Leave the EL nodes as they are - Start the nodes again, but this time using the custom testnet flags instead of the named testnet flag, e.g: use `--testnet-dir=/network-config` (and its variations) instead of `--holesky`. The custom testnet files should be the ones from earlier - Ensure that the pre-populated validators are up and configured to use the new chain - Once the genesis time is hit, the CL will start sending requests to build blocks on top of the latest canonical EL block. This new block however will not be found in the canonical chain. i.e, If the block had stalled at block 1000, then the CL will request block 1001 to be built and this block 1001 will be different from canonical Holesky At this point, we have created a forked chain (i.e, Holesky). This forked chain will inherit the entire state of the canonical Holesky chain (i.e, the past contracts, transactions) but the blocks will diverge at one point. We will have the canonical chain and the shadowfork. They will continue to stay peered on the gossip layer, so the canonical transactions will still be included in the shadowfork for a few days (Caution while executing transactions, they make leak to the canonical chain!). ### Practical steps: - We'll be talking about shadowforking Holesky in this guide - Setup 10 instances on a cloud provider of your choice - Sync the EL and CL (checkpoint sync CL) to Holesky, use whichever client you prefer (note: Erigon sync takes longer)(You can use snap or whatever sync mode is default on the client) - Once the EL and CL are fully synced, stop the CL on all the 10 instances at the same slot height/time (preferably with a simple script). All ELs will automatically stall at the same height - Check that all the EL are at the same height by calling the `eth_getBlockByNumber` API call (retry the process if some EL is on a different height, or use the setHead feature) - Clone [this](https://github.com/ethpandaops/ethereum-genesis-generator/blob/master/config-example/values.env) repository and edit the `values.env` file - Set the values required for your shadowfork (Usually you want to change the mnemonic, # of validators, genesis timestamp and fork epoch) - Don't forget to enable the value `SHADOW_FORK_RPC`, set this to the JSON-RPC of one of your stalled ELs (this will fetch the latest block and embed it as the `execution_payload`) - Run the genesis tool with docker: ``` mkdir output && docker run --rm -it -u $UID -v $PWD/output:/data \ -v $PWD/config-example:/config \ ethpandaops/ethereum-genesis-generator:latest all ``` - This will create a folder called `output` with the genesis files for your shadowfork - Now clear everything related to the CL on all of your 10 instances (Leave the EL alone). The CL data directory and process must be completely removed - Copy over the genesis files found in the `output` directory - Start the CL and EL in custom testnet mode, using the generated `output` files as the configs - At the specific genesis timestamp, the CL will send a request to build a block on top of the latest head of the EL, If this block is proposed and propagated - then your shadowfork is successful! ### Practical steps (from PK): - Setup 10 instances on a cloud provider of your choice - Prepare the EL and CL data directories bzx loading the latest finalized holeskz snapshot from snapshots.ethpandaops.io - Prepare shadow fork genesis configs - Start with current holeskz config.yaml - Update MIN_GENESIS_TIME to a timestamp in future (start time of the shadow fork) - Load the latest finalized Validator Set from Holesky (from dora / from a beacon node running on the broken holesky) - convert the validator set to a list of pubkezs/withdrawalcreds/balances eg. https://github.com/ephemery-testnet/ephemery-genesis/blob/master/validators/pk910-node1.txt - replace the first 1.2M (TODO: Update number) keys with pubkezs controlled by ethPandaOps all deposits posts genesis will be retained with their pubkey and current withdrawal creds / balance - #### Helpers: - Script to stop beacon node at a certain slot ```bash= #!/bin/bash # Define the URL from a Jinja2 variable URL="{{ beacon_url }}" # Poll the URL in a loop while true; do # Fetch the slot value SLOT_VALUE=$(curl -s $URL | jq -r '.data[].header.message.slot') # Check if the slot value has reached "{{ slot_to_stop_at }}" if [[ $SLOT_VALUE == "{{ slot_to_stop_at }}" ]]; then echo "Slot value has reached $SLOT_VALUE !" echo "Stopping beacon node..." sleep 2 docker stop beacon # Exit the loop break else echo "Current slot value: $SLOT_VALUE" fi # Wait for a while before polling again sleep 10 done ```
Last changed by  
 
[email protected]
873

Read more

Mekong deprecation Announcement

The Mekong devnet was meant to be a playground for wallet developers to experiment with UX changes and for stakers to gain confidence in the upcoming Pectra changes. The Pectra network upgrade has been activated on the Ethereum Sepolia and Holesky testnets. These networks can now be used to test the Pectra upgrade features. In light of this, we'd like to announce the deprecation of the Mekong testnet on 7th March, 2025. Application and tooling developers are encouraged to use Sepolia to test applications, smart contracts, and other EVM functionality. Its permissioned validator set provides a stable test environment. Alternatively, many local development environments allow for testing against copies of the Ethereum mainnet state. Stakers and infrastructure providers concerned with protocol-level testing are encouraged to wait for the Holesky testnet to finalize, or to await an announcement on the Ethereum R&D discord for an alternate testing location. For validator setup testing, stakers should also consider the Ephemery testnet. This network resets weekly and enables lightweight end-to-end testing of the validator lifecycle.

3/6/2025
Untitled

(78.94%) Target correct: 1149956/1386000 (82.97%) Target timely: 1149956/1386000 (82.97%) Head correct: 1111231/1386000 (80.18%) Head timely: 918835/1386000 (66.29%) Sync committees: 12927/14336 (90.17%) Overall Network Report: ![overview-resource-use]**(https://storage.googleapis.com/ethereum-hackmd/upload_f0c32807e29183674d9b13b823de6817.pn

11/29/2024
Verkle transition

Considerations Resource use: CPU, Disk, Cost, I/O Syncing and Sync complexity increase Complexity of Implimentation and Testing Time for conversion to take place Ideological Methods Overview

1/18/2024
Gas limit increase

Thanks to Barnabé, Andrew, Sam and Marius for the review and discussions Introduction As the topic of Gas limit increase has surfaced recently, I thought I'd spend some time compiling thoughts from various places and try to enumerate a path forward to increase the limit safely. In its current form, Ethereum consists of 2 layers, the Execution Layer (EL) that is responsible for handling transactions, state, history, building blocks and the Consensus Layer (CL) that is responsible for consensus. The CL consensus engine is currently a combination of Casper the Friendly Finality Gadget (Casper FFG) and the LMD-GHOST fork choice algorithm. This consensus engine is strictly time dependent and introduces a concept of Slots and Epochs, there are tasks that need to be completed at certain periodic intervals by the validators. Two such tasks that we will consider are called Block proposals and Attestations. A block proposal specifies what the assigned validator thinks the canonical slot needs to be and the attestation specifies the vote of each validator for said proposed slot. Each interval (slot) is 12 seconds long and the specification says that the validator must attest as soon as they see a valid block or at the 4s mark into the slot. This introduces the concept of a deadline for the attestation task, i.e, under ideal conditions we'd want every validator on the network to attest to the canonical slot with a valid block before the 4s mark. On receiving information about the proposed block, the CL triggers a engineAPI call called forkchoiceUpdated(fcu). If the EL has all the data it requires, then it verifies the block and responds with VALID. Until this verification is complete, the CL cannot proceed with its duties, implying that the verification needs to ideally be complete within the 4s mark. There are a couple of variables at play with regards to this verification time: It depends on when the CL sends it the fcu, how big the block being verified is and if the EL already has all the data required for verification. A higher gas limit would be one factor that affects this verification time. The presence of Blobs also adds some complexity to this systems as a slot isn't valid until all the blobs proposed in it are fetched from the network and verified. The CLs do this in parallel, i.e once the block is received the fcu is issued, the block is then imported into forkchoice once the blobs have been deemed valid and available. The trigger for both tasks are handled by the CL, since they are done in parallel we would need to analyze which aspect takes the longest. If the blob fetch and verification takes longer, then the assumption is that on this one metric we can potentially afford to increase the EL gas limit. If the block verification takes longer, then on this one metric alone we can potentially increase the blob count. However, we do need to ensure that in any case the tasks are complete (ideally) in under 4s across the network.

1/18/2024
Read more from [email protected]
Published on HackMD