Ethereum developers

Ethereum developers activate the Pectra upgrade, which includes 11 improvements such as enhanced staking efficiency and improved Layer 2 scalability

ChainCatcher news, according to The Block, the Ethereum mainnet successfully activated the Pectra upgrade at 6:05 AM Eastern Time, marking the most significant network update since the Merge in 2022.This hard fork includes 11 EIP improvement proposals, primarily focusing on three major areas: enhancing staking efficiency, optimizing user experience, and improving Layer2 scalability. The successful deployment of the testnet Hoodi in March laid the foundation for this upgrade. Pectra sets the stage for the Fusaka upgrade, which will introduce key technologies such as Verkle Trees and PeerDAS.Among the highlights of this upgrade is the EIP-7702 account abstraction scheme, which allows regular wallets to temporarily execute smart contract functions. In the future, users will be able to experience innovative features such as third-party payment of Gas fees, batch transaction packaging, and even recovery of lost private keys through social contacts. In terms of the staking mechanism, the ETH staking limit for a single validator node has been significantly increased from 32 to 2048, allowing institutional stakers to reduce operational complexity through node merging.For Layer2 scalability, the Blob data capacity per block has doubled to 6 (peaking at 9), and the proto-danksharding technology based on last year's Dencun upgrade continues to deepen, which is expected to reduce transaction costs on Rollup chains like Arbitrum by over 90%. The technical team has also addressed several long-standing pain points: the activation time for validator nodes has been reduced from 12 hours to 13 minutes, the execution layer can directly control node exits to enhance key security, and the on-chain storage of historical block hash data has improved the reliability of decentralized oracles.

The Base protocol leader and several Ethereum developers and L2 leaders support based rollups

ChainCatcher news, according to Cointelegraph, Jesse Pollak, head of the Base protocol, recently stated in a conference call with Ethereum founders and developers that based rollups are "a flexible and powerful tool that will allow us to use them for Base, bringing it closer to Ethereum and increasing the security guarantees it provides."Ben Jones, a director at the Optimism Foundation, added that based rollups will improve collaboration between the Ethereum base layer and L2.Ethereum L2 networks (such as Arbitrum, Optimism, and Base) have charged hefty fees by deploying high-speed, centralized sorters (i.e., the order of transaction processing and addition to blockchain blocks), but this comes at the cost of unification.Based rollups, proposed by Ethereum core developer Justin Drake in March 2023, return this process to the base layer, improving the decentralization of the network, as the block building process will be executed by all Ethereum validators rather than a single centralized sorter.At the same time, native rollups will enhance the way transactions are executed on the base layer, making the network more composable.However, these L2s will forfeit a significant portion of their revenue gained through maximum extractable value. Data from Dune Analytics shows that Arbitrum, which supports the transition to based rollups, has generated $210 million in revenue from its centralized sorter, while Base's revenue stands at $96.2 million.It is worth noting that based rollups or native rollups may bring more revenue to Ethereum's base layer and positively impact the price of ETH. However, the decentralized sorting of the Ethereum base layer means that transactions will be confirmed within 12 seconds, rather than the approximately 1 second typical of many Ethereum L2s. Several Ethereum L2 leaders also support the deployment of "FABRIC," an infrastructure that supports based rollups.Daniel Wang, CEO of Ethereum L2 Taiko, stated that the protocol is willing to adopt the FABRIC standard to "address" Ethereum's interoperability issues, saying, "We have been waiting for the FABRIC standard so that we can work together and provide a complete solution."

Latest content from the Ethereum core developer meeting: Devnet update progress, EIP-7514 confirmed as part of the Dencun upgrade, etc

ChainCatcher message, Ethereum core developer Tim Beiko summarized the latest Ethereum core developer execution meeting (ACDE), which introduced Devnet updates, new content for Dencun, and provided a comprehensive overview of Reth:Devnet-8 Status Update: The network is being finalized, and many clients have begun pushing new updates to it. Meanwhile, testing of the MEV/block building process has started using the developer tool system Kurtosis. Nethermind shared that their blob transaction pool is ready, and after a few days of testing on a single node, they have deployed it to all Dencun test nodes. Geth's blob transaction pool is also nearing completion. Besu is conducting broader maintenance on its transaction pool (to limit the size of Blob + non-Blob transactions), which is expected to be released in the next version. Erigon is still developing its pool, aiming to be ready for devnet-9.The meeting continued the discussion from last week's ACDC call regarding whether to add a constant cap to the validator activation queue. Subsequently, the proposal was officially named EIP-7514 (Add Maximum Epoch Loss Limit). In short, this would slow down the growth rate of the ETH staking percentage in the worst-case scenario.The meeting discussed another last-minute proposal: adding an opcode to the EVM to reveal the base fee of blobs. We have a similar opcode that can reveal the BASEFEE of EIP-1559, which was introduced simultaneously with the activation of the EIP. This allows L2 to more easily determine the correct gas price to charge users based on L1 data costs.The meeting discussed some updates to EIP-4788, which stores the beacon root in contracts on the EL. Over the past few weeks, we have conducted multiple audits and fuzz tests on the contracts, leading to some subtle changes described in this PR. The first is to explicitly handle a 0 timestamp, rolling it back (like other invalid timestamps) instead of returning 0. The second change is the buffer size. Assuming the slot time has changed, considering how modulo works, the original contract would lead to storage waste. By using a prime number (8191), it should utilize 100% of the buffer regardless of the slot time. Finally, gas optimizations were made to reduce the number of times CALLDATA needs to be loaded. Auditors will review these changes, and the final report is expected before the next ACDE. To ensure the smooth progress of fuzz testing and implementation, developers agreed to merge the proposed changes now.The meeting discussed how clients should handle cases where the system contract address is part of the state but is empty at the end of execution. Although this is practically impossible on the mainnet, it is an edge case that arises in testing by setting the address at genesis. Given the uniqueness of this edge case and the lack of explicit normative behavior, developers agreed to spend more time thinking about this issue and continue the discussion in Monday's testing call. This is a specification change.All of the above content is planned to be included in devnet-9. The client teams unanimously agreed that everything should be implementable and testable before next week's ACDC. The release date for devnet-9 will be agreed upon in that call.
ChainCatcher Building the Web3 world with innovators