EIP-7251: Increase the MAX_EFFECTIVE_BALANCE Topics Motivation Features Will pools consolidate? Pros / cons Motivation Today, an entity with X stake controls X / 32 individual keys voting the same

Current status: Mitigated. Stakers running Nethermind are strongly recommended to update to Nethermind v1.21.1 Summary On Oct 19th, 2023 around 02:24:25 UTC Gnosis chain block producers suffered a network-wide block production issue that caused nodes to produce blocks with an invalid state root. Every node in the network (including the producer itself) rejected the blocks. As a consequence, the network did not see any new blocks for a period of multiple epochs until the error self-corrected. A total of 4 incidents happened on the same day. The incident resulted in a temporary loss of liveness. There was no loss of funds, nor slashings, nor long re-orgs to full nodes. Grafana dashboard displaying metrics of participation rates of the first incident Screen capture of gnosischa.in for the last incident epoch range Impact

Whisk (ethresearch post) is a single secret leader election protocol, providing proposers privacy at the protocol level. In simple terms, for proposers to remain private, the chain must know a point P for each validator such that P = k * G where k is only known by the validator. That may not sound complicated, but for a live network with hundreds of thousands of indexes, it adds some practical problems. For the chain to have access to this set of points P, it can either: Compute points P from existing on-chain data Require each validator to submit point P This post explores the problems with each bootstrapping strategy and proposes an extended strategy that solves them.

Whisk is a single secret leader election protocol, providing proposers privacy at the protocol level. Checkout the ethresearch post for background This post arises from discusing with George (@asn-d6) the solution from https://hackmd.io/@dapplion/whisk_induced_missed_slots, so it's recommended as additional background to readers After Whisk each validator must independently perform a test to discover if it has to propose at each slot. Specifically, it has to check: def should_k_propose_at_slot(slot, k): state = get_head_state_at_slot(slot) tracker = state.whisk_proposer_trackers[slot % WHISK_PROPOSER_TRACKERS_COUNT] return tracker.r_G * k == tracker.r_k_G

Whisk is a single secret leader election protocol, providing proposers privacy at the protocol level. Checkout the ethresearch post for background Whisk on its current spec will induce ~2% missed slot rate on the initial epochs after the fork, and over 12,000 cumulative missed slots during the first year post-fork. This doc explains the cause of the issue, its likelihood, and a spec patch to solve it. Why Whisk induces missed slots Any secret shuffling protocol requires all participants to submit entropy. Whisk collects the entropy from each validator's first proposal post-fork. In Whisk, this entropy is a tracker created with a secret value k. To bootstrap the system all validators are initialized with a public deterministic k_initial value. Then, progressively, each validator submits a tracker created with a secret k on their first proposal post-fork. These trackers are shuffled and a subset of them are elected as a sorted list of whisk_proposer_trackers. For a proposer to claim its proposer slot, it must submit a valid opening proof against:

EIP-7044 Perpetually Valid Signed Voluntary Exits -- PEEP an EIP @dapplion Goal Improve staking operations on splitted credentials, with minimal protocol changes

Background Best guess to automatically debug why validators do not achieve expected rewards. Tries to answer common questions such as: Did the validator submit the attestation to this block? Was the attestation seen in an aggregate? Was the attestation seen in a block? First, know that the beacon state tracks participation in three bits: timely_source = is_correct_source and inclusion_delay <= 6:

Rationale Current CHURN_LIMIT_QUOTIENT in Gnosis is low such that the network's validator set can change significantly in short periods of time posing unnecessary risks to the network. The original value was chosen without a great deal of care to facilitate staker onboarding UX. Even that argument will no longer apply with eip6110 (in-protocol deposits). CHURN_LIMIT_QUOTIENT dictates the validator_churn_limit which is constant through an epoch variable only to active validator count. def get_validator_churn_limit(state: BeaconState) -> uint64: """ Return the validator churn limit for the current epoch. """ active_validator_indices = get_active_validator_indices(state, get_current_epoch(state))

Background From Spec Gnosis Chain withdrawals #1 During block processing, state transition must call WITHDRAWAL_CONTRACT function function withdrawals(uint64[] amounts, address[] addresses) If transaction reverts, the block is invalid. So if a specific state (i.e. not enough funds) causes a revert in all cases, the network halts Deposit flow Bridge GNO from mainnet to Gnosis Chain

Get repo and build it (requires Go lang) git clone https://github.com/ethereum/hive go build . Checkout branch depending on current progress. For capella Mario's working on eth2-withdrawals-interop. Check with Mario Vega on current branch if working on new forks. master should reflect configurations that are somewhat stable. To run a test do: ./hive --client go-ethereum,lodestar-bn,lodestar-vc --sim eth2/withdrawals --sim.limit "/test-capella-fork" --sim.loglevel 5 client: flag sets which combo to run. For the example above, if you don't provide EL, CL and VC the test breaks: client go-ethereum,lodestar-bn,lodestar-vc. To test an interaction between Lodestar and Teku, do: client go-ethereum,lodestar-bn,lodestar-vc,teku-bn,teku-vc.

Given the conditions: To ensure an upper-bounded disk size, consensus clients must only store blobs within the MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS time range Blobs from finalized blocks are considered available If the latest finalized checkpoint is before MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS, there exist a range of blocks which cannot be checked for is_data_available. More context on ethereum/consensus-specs/pull/3141 Range sync When performing a range sync the client cannot know the latest finalized checkpoint until it syncs to the head. There are two possible scenarios:

Releases EL client Client Merge ready release Status Nethermind v1.14.6 ✅ Available https://github.com/NethermindEth/nethermind/releases/tag/1.14.6

Lighthouse Full metrics list: https://github.com/sigp/lighthouse/blob/6d5a2b509fac7b6ffe693866f58ba49989f946d7/beacon_node/beacon_chain/src/metrics.rs#L452 To enable metrics prefixed validator_monitor refer to these docs: https://lighthouse-book.sigmaprime.io/validator-monitoring.html#how-to-enable-monitoring Validator monitoring is per-validator so if sentry nodes don't have a connected VC, you'll need to explicitly list a set of validator pubkeys with --validator-monitor-pubkeys. Otherwise --validator-monitor-auto will detect validators in a local VC. beacon_block_observed_slot_start_delay_time: Duration between the start of the block's slot and the time the block was observed. beacon_block_imported_observed_delay_time: Duration between the time the block was observed and the time when it was imported. beacon_block_head_slot_start_delay_time: Duration between the start of the block's slot and the time when it was set as head.

Consensus layer config differences to Ethereum Config value Ethereum Gnosis SLOTS_PER_EPOCH 32 16

On Gnosis core devs call it was agreed to target Bellatrix epoch for Wednesday Nov 30th 2022 noon. TTD for Monday Dec 5th 2022 noon. Gnosis chain (EL) per block difficulty is quasi-constant to 0xfffffffffffffffffffffffffffffffe. The TD increase per unit of time is only a function of validators not sealing blocks on their turn. There has been some instability with validator performance in the last two months resulting in effective block times, see gnosisscan.io/chart/blocktime. In contrast to Ethereum, the delta TD per unit of time can only be strictly less or equal than 0xfffffffffffffffffffffffffffffffe / 5 sec. So we'll pick a TTD assuming best case of effective block time of 5 sec. If the actual effective block time is less, the merge will happen latter but never before bellatrix.

How make POSDAO genesis Nethermind GA .github/workflows/run-posdao-tests.yml runs npm run all-nethermind-no-watcher all-nethermind-no-watcher runs CLIENT=nethermind npm run before-start && npm run start-test-setup-nethermind && npm run after-start-no-watcher before-start runs: npm run compile-posdao-contracts && npm run make-spec make-spec runs: . ./scripts/network-spec && cd ./posdao-contracts && npm i && node ./scripts/make_spec.js && node ../scripts/copy-spec.js . ./scripts/network-spec sets ENVs, INITIAL_VALIDATORS, STAKING_ADDRESSES, etc ./posdao-contracts/scripts/make_spec.js: Deploys governance and staking contracts with the set of INITIAL_VALIDATORS, and STAKING_ADDRESSES.

Nethermind's plugin system abstracts consensus engine in modular components. Each consensus must implement IRewardCalculator public interface IRewardCalculator { BlockReward[] CalculateRewards(Block block); } Where BlockReward

Gnosis chain (formerly xDAI) is doing a beacon chain merge, and.. ..I’ll be the merge coordinator! 🔥🔥 Super proud and excited! but, what’s next? 🧵 Thread below 👇 Quick refresher: Gnosis beacon chain (GBC) launched in Dec 8, 2021 and will merge with the EVM chain Gnosis (formerly xDAI) 🐼👉👈🐼

To increase client diversity among non-technical stakers it's key that all implementations can expose a UI to perform keymanager actions. For context on other explored options please check Road to eth2 multiclients in DAppNode ⧫ #329 Attaching a UI to a separate component (a remote signer) is the frictionless route for the current consensus client teams; since now they only need to implement EIP 3030 and get access to a keymanager UI at no extra development cost. Consensys web3signer is currently the only productionized, battle tested remote signer. Please reach out to @dapplion if you know of any other implementation with similar security guarantees. Project summary Extend Consensys web3signer to implement a minimal keymanager API as described in this proposed standard https://github.com/ethereum/beacon-APIs/pull/151 Implement a UI that interacts with a backend following https://github.com/ethereum/beacon-APIs/pull/151

Why? The main goal of this effort is to increase client diversity. UIs are very important to some users so this standard should ensure all clients have at least one. The secondary goal is to offload UI work from core dev teams to other parties that can prioritize this work over Altair, the merge, etc. :::warning WIP: This standard must be cheap to implement to be successful. Core devs are encouraged to voice concerns around complexity to ensure a timely implementation. ::: [TOC]