# Blobs booby-trap :bomb: Given the conditions: 1. To ensure an upper-bounded disk size, consensus clients must only store blobs within the `MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS` time range 2. 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](https://github.com/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: _Finalized checkpoint >= MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS_ ![](https://i.imgur.com/3J1YkFv.png) _Finalized checkpoint < MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS_ ![](https://i.imgur.com/ASKDZLO.png) Given current mainnet values: - Weak subjectivity window: 3532 epochs ~ 15,7 days - `MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS`: 4096 epochs: 4096 epochs ~ 18 days So starting from a checkpoint older than MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS is already unsafe, as it's outside the weak subjectivity window. Clients may choose to shutdown or warn about it. ## Deep re-org On a reorg of depth > MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS, the node is not able to assert is data available for the range of blocks older than MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS. ![](https://i.imgur.com/zqH6mXq.png) 1. If the node's fork-choice already contains such branch in the fork-choice, that branch has been checked for is_data_available thus it can be re-orged to 2. If the node's fork-choice does not contain that branch it will have to perform a sync, so the first scenario applies.
Last changed by  
 
dapplion
111

Read more

Increase `CHURN_LIMIT_QUOTIENT`

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
GC withdrawal contract

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

2/14/2023
How to run Hive with Lodestar

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.

1/23/2023
Gnosis merge client releases

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

11/24/2022
Read more from dapplion
Published on HackMD