Ethereum’s Growing Pains

Ethereum switched from proof of work to proof of stake in 2022, after running for 7 years. There were multiple reasons for this such as proof of stake having higher energy consumption, it is not as scalable as PoS and has higher hardware requirements, and last but not least PoS is bad for the environment. Now, it requires validators to stake ETH.

Problem#01: Single slot finality and staking democratization

Ethereum currently requires 2-3 epochs which is about 15 minutes to finalize a block, and 32 ETH is needed for staking. These were initially compromises made to balance:

1. Maximizing Validator Participation: Lowering the entry barrier for staking increases the number of validators.
2. Reducing Finality Time: Faster block finalization enhances the user experience by speeding up transactions.
3. Minimizing Node Overhead: This refers to reducing the computational and data demands on nodes to process validator signatures.

The conflict arises because, for economic finality (ensuring an attack is costly), every validator must sign off on block finalization, which creates a trade-off between having more validators, faster finality, and manageable overhead.

VanEck report projects that Ethereum (ETH) could reach a price target of $22,000 in a base case scenario, $154,000 in a bull case, and $360 in a bear case by 2030. This forecast hinges on Ethereum’s expanding role in decentralized finance (DeFi), staking rewards, and overall network adoption. While a rising ETH price benefits holders, it complicates matters for solo stakers, as the 32 ETH required for staking becomes more expensive, potentially sidelining smaller participants and risking centralization. Lowering staking requirements is crucial to encourage broader participation and democratization.

Why Economic Finality Matters

Economic Finality ensures that even if a malicious actor tries to attack the network (e.g., reversing a finalized block), it comes at a significant cost, as they would need to sacrifice a substantial amount of staked ETH. Alternative approaches, like committee-based models, simplify the process by having only a subset of validators confirm transactions. However, this reduces the attack cost, as only a small fraction of validators are penalized if they misbehave, allowing repeated attacks with minimal financial loss.

Ethereum’s goal is to maintain economic finality while improving the current system to achieve two primary goals:

• Single-Slot Finality is reducing block finalization time to one slot (around 12 seconds), making the network faster and more user-friendly.

1. 1. Reducing finalization time ensures that all Ethereum users benefit from increased security without waiting for 15 minutes.
   2. Simplifies protocols by eliminating concerns over chain reversion, except during rare inactivity leak cases.

• Lower Staking Requirements mean reducing the minimum stake from 32 ETH to 1 ETH to encourage solo staking.

1. 1. Encourages more people to become validators, making the network more decentralized.
   2. Polls indicate that many users are deterred from staking due to the 32 ETH requirement, so reducing the minimum to 1 ETH could significantly increase participation.

Problem#02: Single secret leader election

Currently, in Ethereum, it is known in advance which validator will propose the next block and this creates a security loophole. Attackers can monitor the network, identify validator IPs, and execute denial-of-service (DoS) attacks when a validator is about to create a block.

• To mitigate this risk, one thing proposed is to obscure the identity of the upcoming block proposer until the block is actually produced. SSLE uses cryptographic methods to assign “blinded” IDs to validators. When a block proposal occurs, only the validator with the selected blinded ID can generate the necessary proof, ensuring their identity remains confidential.

Whisk SSLE protocol

• Another option being considered is using out-of-protocol mitigation methods.

Problem#03: Faster Transaction Confirmations

Ethereum currently has 12-16 transactions per second. Whereas PayPal handles around 193 TPS and Visa boasts a capacity of up to 1,700 TPS. This comparison is just to give an idea that blockchain ecosystems have yet to go a long way. So, for obvious reasons, transaction confirmation time needs to be reduced.

Based on the article, there are two primary approaches to achieve faster confirmations:

1. Reducing Slot Times: Shortening slot times to 8 or even 4 seconds could allow for preliminary confirmations to be made sooner, though true finality may still take longer due to the nature of consensus rounds.
2. Pre-confirmation by Proposers: Proposers could include transactions in real time and publish immediate pre-confirmation messages. This method allows users to see their transactions acknowledged before full confirmation, but it may require additional mechanisms to handle conflicting confirmations.

Problem#04: 51% Attack Recovery

The current reliance on social consensus to recover from a 51% attack is precarious. This dependence can lead to delays in recovery and an increased risk of network compromise. By implementing partial automation that automatically rejects chains that censor transactions, Ethereum can minimize the risk of attackers achieving a swift victory. For instance, historical data shows that community-driven recoveries can take days, risking further network instability.

Problem#05: Increasing the Quorum Threshold

Currently, Ethereum requires a 67% support threshold for block finalization, which has proven to be overly aggressive and can lead to instant victories for attackers. Raising this threshold to 80% could enhance overall security and promote a healthier consensus environment. Research indicates that increasing the threshold could reduce the likelihood of contentious situations by as much as 30%, thereby reinforcing the network’s resilience against attacks.

Problem#06: Quantum Resistance

As quantum computing advances, it poses a significant threat to the cryptographic methods used in Ethereum. Experts such as Scott Aaronson suggest that quantum computers could break existing cryptographic standards by the 2030s, jeopardizing the integrity of the Ethereum network. Developing quantum-resistant alternatives is imperative to safeguard the protocol’s future. This proactive approach not only mitigates risks but also ensures that Ethereum remains secure in the face of evolving technological threats.

Problem #07: Insufficient Data Availability Sampling Limits Scalability

Ethereum’s current data availability mechanisms allow for only approximately 173.6 TPS. Although the PeerDAS upgrade aims to increase throughput to 463-926 TPS, this is still far below the desired target of 58,000 TPS. The limitations hinder the network’s scalability and efficiency, affecting its capacity to support growing transaction demands in decentralized applications.

2D sampling. Source: a16z crypto

2D sampling enhances data availability by allowing random sampling not just within blobs but also between them. This method utilizes linear properties of KZG commitments, enabling nodes to create “virtual blobs” that replicate existing information without requiring the actual blobs. As a result, it streamlines distributed block construction, significantly boosting scalability while maintaining security and efficiency.

Implementing these advanced sampling techniques can substantially increase Ethereum’s throughput, better accommodating the demands of decentralized applications and improving overall network performance.

Problem #08: Data Compression to Enhance Rollup Scalability

Each transaction in a rollup occupies significant data space on-chain, limiting scalability. For instance, an ERC20 transfer consumes about 180 bytes, which restricts throughput to roughly 7,407 TPS under ideal data availability conditions. The challenge is to reduce the data size of each transaction, thus increasing scalability.

Several techniques can compress rollup transactions:

1. Zero-Byte Compression: Replace long sequences of zero bytes with two-byte representations.
2. Signature Aggregation: Switch from ECDSA to BLS signatures to aggregate multiple signatures into one, reducing data size. This method suits data-scarce Layer 2 environments, as the computational verification cost is justified.
3. Replacing Addresses with Pointers: Use smaller pointers instead of 20-byte addresses if they were previously recorded, integrating blockchain history with the state.
4. Custom Serialization for Transaction Values: Represent values in a more compact format, using custom decimal formats or dictionaries for common values.

By optimizing data space, these approaches aim to significantly enhance Ethereum’s Layer 2 scalability, enabling higher transaction throughput.

Problem #09: Generalized Plasma for High-Scalability Use Cases

Even with 16 MB blobs and data compression, reaching the target of 58,000 TPS may not be enough to support high-bandwidth sectors like consumer payments or decentralized social platforms, especially when privacy is taken into account, which could reduce scalability by 3-8x. Solutions like validium keep data off-chain but carry risks such as funds freezing if operators go offline. A more robust scaling method is needed.

Generalized Plasma scales by keeping blocks off-chain and publishing only Merkle roots on-chain. This structure allows users to withdraw assets using Merkle branches as proof, even if data availability fails. Unlike traditional rollups, Plasma doesn’t require the latest state for withdrawals, making it resilient against operator failures. Invalid withdrawals can be challenged on-chain.

Enhancing Plasma with SNARKs improves security, simplifies challenge processes, and extends support to a broader range of assets. Combining Plasma with rollup techniques, such as hybrid Plasma/rollup solutions, can further enhance scalability, supporting hundreds of thousands of TPS while offering privacy benefits.

Problem #10: Maturing Layer 2 (L2) Proof Systems

Current rollups, intended for scaling Ethereum, are not fully trustless. They often rely on a security council to override proof systems due to potential bugs, which prevents complete decentralization. We need rollups that are truly trustless.

Achieving “Stage 2” trustlessness involves:

1. Formal Verification: Using rigorous mathematical techniques to ensure that proof systems align with EVM standards.
2. Multi-Provers: Employing multiple proof systems to enhance security, with councils intervening only when provable bugs occur.

However,

• Completing a formally verified proof system for Ethereum is complex but essential.
• Multi-provers require balancing safety, gas costs, and consistency in decision-making.

Problem #11: Cross-Layer 2 (L2) Interoperability Improvements

Navigating the L2 ecosystem remains challenging for users. Current cross-L2 interactions often involve centralized bridges or RPC clients, undermining trustlessness. To make the L2 experience seamless, we need to unify the Ethereum ecosystem, making L2 interactions feel as straightforward as those on Layer 1 (L1).

So according to Vitalik’s article as per my understanding, approaches that can be taken are,

1. Chain-Specific Standards: Integrate chain-specific addresses and payment requests for smoother asset transfers.
2. Cross-Chain Operations: Standardize protocols for cross-chain swaps, gas payments, and asset transfers, like ERC-7683 and RIP-7755.
3. Light Clients: Extend trustless verification to L2s, allowing users to validate chains without relying on RPCs.
4. Keystore Wallets: Implement shared key management for smart contract wallets, reducing the need to update keys across multiple chains.
5. Shared Token Bridge Concepts: Develop a minimal rollup for managing cross-L2 token transfers efficiently, reducing gas costs.
6. Synchronous Composability: Enable seamless interactions between L2s and L1, enhancing DeFi protocols’ financial efficiency.

But, Standardization involves timing decisions: standardizing too early may entrench suboptimal solutions while waiting too long could cause fragmentation. The process requires collaboration across the Ethereum community, including L2 projects, wallet developers, and the L1 ecosystem.

Problem #12: Scaling Execution on L1

As L2s become more scalable, a low-capacity L1 could pose risks to Ethereum. Challenges include weakened ETH economics, diminished incentive for L2s to stay linked to Ethereum, delayed security parity between L1 and L2, and L1’s inability to handle complex asset recoveries if an L2 fails.

The solutions getting looked at are,

1. Gas Limit Adjustments: Increasing the gas limit cautiously, backed by optimizations like statelessness and history expiry, to enhance L1’s capacity without centralizing it.
2. Efficient Computation: Making certain EVM operations cheaper, like using EOF for optimized execution and multidimensional gas pricing for more granular resource allocation.
3. Advanced EVM Techniques: Incorporating EVM-MAX for modular arithmetic and SIMD for parallel data processing can optimize cryptographic operations, benefitting both L1 and L2 scaling.
4. Native Rollups: Integrating rollup-like functionality directly into Ethereum, enabling parallel EVM execution to scale natively.

Scaling techniques present different trade-offs; for instance, raising the gas limit might reduce node decentralization, while native rollups could limit composability. The strategy must balance L1 and L2 responsibilities, ensuring L1 retains its robustness while enabling a scalable ecosystem. Enhancements to L1 scalability will also impact other roadmap elements, such as MEV management and fast slot times in “The Verge” phase.

Problem #13: Block Construction Pipeline

Ethereum’s current block construction largely relies on MEVBoost’s proposer-builder separation (PBS), where builders create blocks by choosing transactions that maximize profit. However, this system can lead to centralization risks, as a few builders dominate block production, potentially censoring transactions or manipulating markets through delayed inclusions and MEV extraction.

Validators create transaction lists that builders must include in blocks, reducing builders’ censorship power. Variants like FOCIL involve committees to strengthen decentralization.

Distributes block production across several actors, making it less centralized than the current PBS system.

Prevent builders from exploiting transaction details before inclusion, using techniques like threshold decryption or delay encryption.

Approaches like inclusion lists reduce builder control but might increase MEV risks. BRAID offers decentralization benefits but depends on encrypted mempool designs for optimal function. Integration of these strategies is complex, with various solutions possibly complementing each other.

Problem #14 Staking Economics

Currently, about 30% of ETH is staked, more than enough to secure Ethereum. If staking continues to grow, risks arise:

1. Staking could shift from being a specialist activity to a widespread duty, with many delegating to large, centralized operators for convenience.
2. Slashing penalties lose credibility if almost all ETH is staked.
3. A dominant liquid staking token (LST) could capture network effects and issuance rewards, potentially overshadowing ETH.

Strategies to address these issues include:

1. Issuance Reduction: Adjusting issuance rates to decrease staking returns if the staked amount nears a cap. This discourages overstaking by reducing rewards as staking approaches the pre-determined threshold. For example, various proposals adjust the reward curve, making excessive staking economically unattractive.
2. Two-Tier Staking: This approach introduces “risk-bearing” (slashable) and “risk-free” (unslashable) staking. Only a fraction (e.g., 1/8) of total ETH would be risk-bearing. This tiered system aims to retain staking incentives while controlling risks associated with centralized staking through LSTs.
3. MEV Capture and Smoothing: Making MEV (Maximal Extractable Value) legible to the protocol allows capturing this revenue stream to distribute it more evenly. Mechanisms such as auctioning block proposer rights or MEV smoothing can help balance incentives across different staking roles (proposers vs. attestors).

Implementing these solutions involves weighing risks and benefits. Adjusting issuance might deter participation, while two-tier staking may introduce complexities in setting appropriate returns. MEV capture could reduce earnings variability but requires careful design to avoid unintended incentives.

Problem #15: Ethereum Node Scalability Challenge

As Ethereum grows, the storage requirements for fully verifying nodes continue to increase, posing a barrier to scalability and decentralization. For users to maintain a fully verifying node, they must handle immense data demands, limiting accessibility. This challenge risks concentrating network verification in the hands of those with higher resources, diminishing the decentralized ethos of Ethereum. Addressing this involves developing efficient data management solutions, such as stateless clients, which can significantly reduce storage burdens and ensure wider participation in network security and validation.

Problem #16: Validity Proofs of EVM Execution

The challenge in Ethereum is achieving efficient, secure block verification with minimal resource needs. This involves creating SNARK/STARK proofs for both the consensus (proof of stake) and execution layers (EVM). Ideally, users could validate blocks with light clients on mobile or browser wallets, enhancing decentralization.

Current issues include security and prover time, with advancements needed in multi-prover approaches, formal verification, parallelized proving, and EVM gas cost adjustments. Further, decentralized, accessible hardware is essential to avoid dependency on specialized equipment for block validation.

Problem #17: Validity Proofs of Consensus

Ethereum’s consensus layer requires proof to verify deposits, withdrawals, signatures, and validator balance updates in a decentralized manner. This involves verifying beacon chain transitions, which include numerous BLS12-381 ECADDs, SHA256 hashes, and validator state reads, making consensus proofs challenging. To scale, a switch to faster hashing (Poseidon), efficient validator data storage, recursive signature aggregation, or alternative signature schemes is being considered. Tradeoffs include the choice between incremental improvements and a complete redesign, factoring in SNARK-friendliness and Ethereum’s evolving architecture.

Problem #18: History Expiry

The growing historical data in Ethereum nodes (about 1.1 TB for execution clients) burdens node storage as it expands yearly, even without gas limit increases. By shifting to a distributed storage model, nodes only store recent data, while older data is maintained collectively by nodes, akin to torrent networks. EIP-4444 proposes a one-year storage limit, with options like the Portal network and erasure codes for added resilience. The tradeoffs include the extent to which historical data is stored, and how deeply storage is integrated into the network’s architecture.

Problem #19: State Expiry

Ethereum’s “state expiry” problem involves the continuous growth of state data (account balances, contract code, etc.), adding about 50 GB per year. Unlike historical data, state data is challenging to “expire” due to the Ethereum Virtual Machine’s (EVM) design that assumes persistent access to this information.

Proposed Solutions

1. Partial State Expiry: Divides the state into “chunks,” storing only recently accessed data, with mechanisms for data “resurrection.”
2. Address-Period-Based Expiry: Periodically creates new state trees, requiring proofs to access older, “expired” data.

Both approaches aim to reduce data demands while preserving user access and developer usability.

Problem # 20: Complexity Overload in Ethereum Protocol

The increasing complexity of Ethereum’s protocol makes it harder to maintain security, accessibility, and neutrality. Over time, adding features and adjustments introduces bugs, raises developer onboarding challenges, and opens avenues for exploitation. Simplification is essential to prevent Ethereum from becoming overly complex.

Feature cleanup entails removing outdated or redundant protocol elements. Recent changes include phasing out the SELFDESTRUCT opcode, transitioning RLP to SSZ serialization, reducing transaction types, and eliminating unnecessary mechanisms like sync committees. These changes simplify Ethereum’s codebase, easing upgrades and strengthening security.

The main challenge is balancing simplification with backward compatibility. A phased, multi-year feature-removal approach allows gradual deprecation with minimal disruption.

Conclusion

As Ethereum continues to grow and adapt, it’s crucial for stakeholders to stay informed and engaged. The future of this platform hinges not only on technological advancements but also on collaboration and community involvement.

Whether you’re looking to innovate within Ethereum’s evolving landscape or enhance your existing projects or work on some other blockchain, BlockApex is here to support your journey towards success in the decentralized world.

This article is heavily based on possible futures of the Ethereum protocol series by Vitalik.
Thank you for reading. Until Next time! Sayonara