Introduction I will try to demonstrate what rogue key attack is by ZK HACK IV puzzle Supervillain. see the repo Puzzle Legend: Bob has been designing a new optimized signature scheme for his L1 based on BLS signatures. Specifically, he wanted to be able to use the most efficient form of BLS signature aggregation, where you just add the signatures together rather than having to delinearize them. In order to do that, he designed a proof-of-possession scheme based on the B-KEA assumption he found in the the Sapling security analysis paper by Mary Maller. Based the reasoning in the Power of Proofs-of-Possession paper, he concluded that his scheme would be secure. After he deployed the protocol, he found it was attacked and there was a malicious block entered the system, fooling all the light nodes... If you want to have a try yourself(I really suggest that) visit the puzzle page.

The Ethereum Improvement Proposal EIP-7514 introduces a significant specification parameter: MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT. This parameter plays a crucial role in shaping the activation cue, directly impacting the activation churn. It's important to note that this parameter specifically affects the activation cue and does not fall under the considerations of weak subjectivity. Understanding Activation Churn The activation churn equation is a fundamental aspect of EIP-7514. The churn limit for validator activation in the current epoch is determined by the following function: def get_validator_activation_churn_limit(state: BeaconState) -> uint64: """ Return the validator activation churn limit for the current epoch. """ return min(MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT, get_validator_churn_limit(state))

In this exploration, we analyze the correlation between block size and chain performance, focusing on its implications for the Gnosis Chain. We aim to leverage these insights to optimize parameters for the Gnosis Chain, especially considering the introduction of EIP-4844 in the Ethereum Dancun upgrade. EIP-4844 proposes a new transaction format, accommodating 'blob-carrying transactions' with a significant data load, aligning with future sharding goals and necessitating an increase in block size for enhanced network efficiency. TOC Big Blocks ExperimentFormal DescriptionExperiment Steps Analysis Time Range Analysis PrefaceLatencies Participation

Problem Gnosis withdrawals mechanism differs from the Ethereum one because ERC20 GNO token used for staking. => Withdrawals are implemented by internal contract execution on EC side: e.g. Erigon: // See https://github.com/gnosischain/specs/blob/master/execution/withdrawals.md func (c *AuRa) ExecuteSystemWithdrawals(withdrawals []*types.Withdrawal, syscall consensus.SystemCall) error { if c.cfg.WithdrawalContractAddress == nil { return nil

Visit reference list for more detailed problem explanation and context. Problem The Gnosis chain CHURN_LIMIT_QUOTIENT parameter is currently considered too low. This has a significant impact on increasing the chain churn speed, and this effect is further exacerbated by the faster block time. This situation results in reduced network security and renders a chain more susceptible to long-range attacks. Current Gnosis chain params: According to the chain spec the equation employed to determine the extent of validator churn during an epoch is as follows:

Collecting profiles from testing environment ( prepared testing repo branch with fixed v10-rc3-mempool-v0 as devnet1 and buggy v10-rc3 as devnet2: https://github.com/evmos/testing/tree/pprof ) To profile evmos node with evmos/testing tool, It's necessary to change cmd/evmosd/main.go as here: package main