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))4/19/2023
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 Chain2/14/2023
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:1/23/2023
Releases EL client Client Merge ready release Status Nethermind v1.14.6 ✅ Available https://github.com/NethermindEth/nethermind/releases/tag/1.14.611/24/2022
By clicking below, you agree to our terms of service.
New to HackMD? Sign up