# Capella interop, Prysm - Nethermind ## Build Nethermind ```bash git clone --recursive -b feature/shanghai-eip-4895-withdrawals https://github.com/NethermindEth/nethermind.git cd nethermind/src/Nethermind dotnet build Nethermind.sln -c release export NETHERMIND=$(pwd)/Nethermind.Runner/bin/Release/net6.0 ``` ## Build prysm ```bash git clone --recursive -b capella https://github.com/prysmaticlabs/prym.git cd prysm bazel build //cmd/beacon-chain bazel build //cmd/validator export PRYSM=$(pwd) ``` ## Prepare the beacon configuration - Make the devnet directory ```bash mkdir devnet export DEVNET=$(pwd)/devnet ``` - Create the beacon config ```bash $ cat config.yml CONFIG_NAME: interop PRESET_BASE: interop # Genesis GENESIS_FORK_VERSION: 0x20000089 # Altair ALTAIR_FORK_EPOCH: 2 ALTAIR_FORK_VERSION: 0x20000090 # Merge BELLATRIX_FORK_EPOCH: 4 BELLATRIX_FORK_VERSION: 0x20000091 TERMINAL_TOTAL_DIFFICULTY: 16 # Capella CAPELLA_FORK_EPOCH: 6 CAPELLA_FORK_VERSION: 0x20000092 MAX_WITHDRAWALS_PER_PAYLOAD: 4 # Time parameters SECONDS_PER_SLOT: 6 SLOTS_PER_EPOCH: 4 ``` - Create nethermind's config file ```bash $ cat nethermind.json { "name": "TheMerge_Devnet", "engine": { "clique": { "params": { "period": 5, "epoch": 30000 } } }, "params": { "gasLimitBoundDivisor": "0x400", "accountStartNonce": "0x0", "maximumExtraDataSize": "0x20", "minGasLimit": "0x1388", "chainID": 32382, "networkID": 32382, "eip150Transition": "0x0", "eip155Transition": "0x0", "eip158Transition": "0x0", "eip160Transition": "0x0", "eip161abcTransition": "0x0", "eip161dTransition": "0x0", "eip140Transition": "0x0", "eip211Transition": "0x0", "eip214Transition": "0x0", "eip658Transition": "0x0", "eip145Transition": "0x0", "eip1014Transition": "0x0", "eip1052Transition": "0x0", "eip1283Transition": "0x0", "eip1283DisableTransition": "0x0", "eip152Transition": "0x0", "eip1108Transition": "0x0", "eip1344Transition": "0x0", "eip1884Transition": "0x0", "eip2028Transition": "0x0", "eip2200Transition": "0x0", "eip2565Transition": "0x0", "eip2929Transition": "0x0", "eip2930Transition": "0x0", "eip1559Transition": "0x0", "eip3198Transition": "0x0", "eip3529Transition": "0x0", "eip3541Transition": "0x0", "eip4895TransitionTimestamp": "0xTIMESTAMP", "terminalTotalDifficulty": "0x10" }, "genesis": { "seal": { "ethereum": { "nonce": "0x42", "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000" } }, "difficulty": "0x1", "author": "0x0000000000000000000000000000000000000000", "timestamp": "0x0", "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000", "extradata": "0x0000000000000000000000000000000000000000000000000000000000000000123463a4B065722E99115D6c222f267d9cABb5240000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", "gasLimit":"0x1C9C380", "baseFeePerGas":"0x7" }, "accounts": { "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b": { "balance":"0x6d6172697573766477000000" } } } ``` - put this keystore in nethermind's directory ```bash $cat $NETHERMIND/keystore/key-123463a4b065722e99115d6c222f267d9cabb524 {"address":"123463a4b065722e99115d6c222f267d9cabb524","crypto":{"cipher":"aes-128-ctr","ciphertext":"93b90389b855889b9f91c89fd15b9bd2ae95b06fe8e2314009fc88859fc6fde9","cipherparams":{"iv":"9dc2eff7967505f0e6a40264d1511742"},"kdf":"scrypt","kdfparams":{"dklen":32,"n":262144,"p":1,"r":8,"salt":"c07503bb1b66083c37527cd8f06f8c7c1443d4c724767f625743bd47ae6179a4"},"mac":"6d359be5d6c432d5bbb859484009a4bf1bd71b76e89420c380bd0593ce25a817"},"id":"622df904-0bb1-4236-b254-f1b8dfdff1ec","version":3} ``` - create the secrets ```bash openssl rand -hex 32 | tr -d "\n" > "$DEVNET/jwt.hex" touch $DEVNET/keystore_password.txt ``` - Put the following scripts in your devnet directory ```bash cat nethermind.sh #!/bin/bash rm -rf $NETHERMIND/nethermind_db/* $NETHERMIND/Nethermind.Runner --Init.ChainSpecPath ./nethermind.json --JsonRpc.JwtSecretFile $DEVNET/jwt.hex --Init.IsMining true --KeyStore.PasswordFiles $DEVNET/keystore_password.txt --KeyStore.UnlockAccounts 0x123463a4b065722e99115d6c222f267d9cabb524 --KeyStore.BlockAuthorAccount 0x123463a4b065722e99115d6c222f267d9cabb524 --Network.MaxActivePeers 0 --Init.GenesisHash 0x19286b9ba93edd49b64266c1df5e8303ecb3c504528b010b56f5b237aa0896c2 -c withdrawals_test ``` ```bash $cat beacon.sh #!/bin/bash GENESIS=$(($(date +%s) + 10)) SHANGHAI=$(($GENESIS + 144)) printf -v SHANGHAI_NETHERMIND "%x" "$SHANGHAI" sed -i 's/TIMESTAMP/'$SHANGHAI_NETHERMIND'/' $DEVNET/nethermind.json rm -rf $DEVNET/beaconchaindata rm $DEVNET/genesis.ssz cd $PRYSM bazel run //cmd/prysmctl -- testnet generate-genesis --num-validators=512 --output-ssz=$DEVNET/genesis.ssz --chain-config-file=$DEVNET/config.yml --genesis-time=$GENESIS bazel run //cmd/beacon-chain -- --datadir=$DEVNET \ --min-sync-peers=0 \ --interop-genesis-state=$DEVNET/genesis.ssz \ --interop-eth1data-votes \ --bootstrap-node= \ --chain-config-file=$DEVNET/config.yml \ --chain-id=32382 \ --accept-terms-of-use \ --jwt-secret=$DEVNET/jwt.hex \ --suggested-fee-recipient=0x123463a4b065722e99115d6c222f267d9cabb524 \ --verbosity debug ``` ```bash cat validator.sh #!/bin/bash rm $DEVNET/validator.db cd $PRYSM bazel run //cmd/validator -- --datadir=$DEVNET \ --accept-terms-of-use \ --interop-num-validators=512 \ --interop-start-index=0 \ --chain-config-file=$DEVNET/config.yml ``` ## Run the clients In three different terminals run these commands ```bash $DEVNET/beacon.sh $DEVNET/validator.sh $DEVNET/nethermind.sh ``` in this order
Last changed by  
 
potuz
868

Read more

Validator performance tracking

We explain in detail the different components that make up an Ethereum validator's reward. We describe common situations that make stakers miss some of these rewards and show how to diagnose the -- typically uncommon-- scenarios in which there are actual problems with the software and action is required. 1. Introduction A common concern of node operators is --Is my node performing well?--, or -- Is my node performing at least as the average?--. The essence of the question is in fact --Should I be changing anything in my setup or not?--. It turns out that these questions do not really have an easy answer. There have been many attempts to trying to create a single score that would measure a validator's performance, but they all fail because of different reasons to answer the very basic questions mentioned above. Instead of trying to track a single indicator (or a ton of useless ones and be worried about some small variance on any of those), validators should analyze why their performance took a hit: did I miss an attestation due to a late block, a reorg, something else out of my control?, did I miss a proposal due to my EL being stressed or was my block reorged because it was received late by the network?. In this document, we will try to help node operators to identify warnings, their cause, and make informed decisions on when to tweak their setup. In order to do this we first start by describing, in some level of technical detail, the different components of a validator's reward. We then move to analyze each one of them separately as they are susceptible to different external factors. We finally describe how to exploit existing monitoring tools (grafana, logs, beacon explorers, etc) to diagnose causes for drops in rewards. The organization of this post is as follows. In section 2 we describe the statistical expected variance in income amongst perfectly working validators. In section 3 we describe all the components that make attestation rewards, how much to expect in different scenarios of attestation inclusion and how to diagnose a missing attestation. In section 4 we describe the analogous situation for proposals. In section [5](# 5-Sync-committee-messages) we describe quickly sync committee rewards. In section 6 we cover transaction tips. In section 7 we mention some tools to monitor performance that are available in Prysm, and finally in section 8 we mention how to get support from the Prysm team. 2. Reward variance is evil

4/4/2023
Safe Head: happy case

Basic definitions and notation We will use $S$ for slots, $B$ for blocks, $E$ for epochs. Often times we will use $S$ for the block at slot $S$ abusing notation when no confusion could arise. For example, a forkchoice diagram of the form digraph{ rankdir=RL 10 -> 9; 11 -> 10; 12 -> 11; 13 -> 11; 13 -> 12 [style=invis];

3/23/2023
Validators vs Builders, trust assumptions

Often times we want to make statements of the form, if x% of validators are honest, property P holds, or equivalently, under the supposition that an attacker holds less than y% of the total stake, statement Q is true. Examples of these are of the form: "With a proposer boost of 40% then an attacker with more than 60% of the stake can reorg arbitrarily the block right before he's assigned to propose". "If 90% of the validators are honest, and we have seen all attestations and all blocks in the last two epochs, then the head of the chain cannot be reorged", etc. These statements become much harder to make in the context of PBS, where trust assumptions on validators may become trust assumptions on builders, which is a much more reduced set. CL data vs EL data In a context where most validators defer their execution payload, data blobs, or any future non-pure consensus part of the block to an external builder. The builder may have a final decision on certain aspects of blocks, thus whatever trust assumptions we are making on honesty of validators may cease to be true. In other cases, the builder has zero or very little impact. For example, a trust assumption of the form: "x% of validators are not willing to arbitrarily fork blocks". The validity of this statement is the same under PBS or not, builders have very little bearing on the LMD weight of a given chain, validators alone decide their attestation targets.

3/4/2023
Report on another bad reorg on Goerli

The following reorg was seen on Goerli Unfortunately this graph iss ordered by slot number (left to right) and not by timestamps. The lightblue epoch on the left is 155221, the other lightblue epoch on the right is 155223, the white one in the middle is (you guessed it) 155222. When epoch 155221 ends, the last block that the chain has seen is 4967101 (slot 29 in that epoch, the top branch is based on that block). This block has not enough votes to justify epoch 155221, so the chain advances keeping the justified epoch to be 155220 The chain advances on the top branch, everything is normal, all clients participating, until right after slot 4967121 After that block is imported, block 4967102 appears (4 minutes late). This is the last block in epoch 155221, in slot 30, since the block in the next slot was never proposed (or seen). The block 4967102 has enough votes to justify 155221, this splits the view of the chain: those that have deployed the witholding fix (only prysm) will not see this block as head and continue to build on top of the canonical chain. Those that didn't deploy it yet will immediately reorg to this block. Lodestar proposes block 155224 on top of that block (the first block in the bottom branch) and from there on, Lighthouse, Teku and Nimbus follow.

2/11/2023
Read more from potuz
Published on HackMD