[ad_1]
Well, we have all heard about how the Dencun upgrade will help to lower calldata costs from L2 to L1, but is that all? Beyond that, Dencun upgrade introduces several important features to enhance developer experience and make Ethereum more suited for future improvements.
These 2 EIPs serve to enhance the execution layer on Ethereum. EIP-6780 will disempower the use of opcode SELFDESTRUCT. This is helpful as the upcoming implementation of Verkle tree which will make the pre-EIP-6780 SELFDESTRUCT opcode impossible to execute. This could be a blessing in disguise, as the opcode SELFDESTRUCT can be dangerous, often being part of metamorphic smart contracts that end up as rug pulls. The self-deterministic nature of SELFDESTRUCT also makes it difficult for developers to use, often leading to incomplete states where data was not fully deleted as intended. With this upgrade, the negative consequences of future references of SELFDESTRUCT will be eradicated! Existing contracts that currently use SELFDESTRUCT will not be affected.
EIP-5656 serves to enhance the efficiency of how memory copying within EVM which is an important function for various tasks such as building data structures and copying objects. The introduction of MCOPY opcode in EIP-5656 is essentially a combination of MLOAD and MSTORE, allowing data to be more efficiently transferred from one location to another. Currently, copying 256 bytes of data using MLOAD and MSTORE costs at least 96 gas while the MCOPY costs 27 gas. This reduces the gas fees for smart contracts that use memory copying and improves the readability and maintainability of smart contracts. Post implementation, developers will not be forced to use MCOPY though, and existing references of MSTORE or MLOAD will not be affected.
These two upgrades are staking and validator-focused.
EIP-7044 will allow for perpetually valid pre-signed voluntary exits. This means that pre-signed voluntary exits will be valid indefinitely instead of holding validity only for the current and previous fork versions as is the case now. This is an important upgrade for stakers of delegated staking solutions as they leave their signing keys in the hands of the validator operators who perform their responsibility of attesting and proposing blocks. In the scenario that the validator operator refuses to respect the decision of the staker to voluntary exit (unstake), this would then become an issue under the current model. This upgrade will ensure that stakers can unilaterally submit their voluntary exit to an Ethereum consensus client and independently exit their validator.
EIP-7045 will increase the limit for max attestation inclusion slots. Attestations can be thought of as votes on a given block to approve its ‘correctness’. An epoch, which is a unit of time in Ethereum, consists of 32 slots, with each slot having a time limit of 12s in which blocks can be proposed and validated. Currently, validators have 32 slots to broadcast their attestation for inclusion in a given slot. However, with the new upgrade, this will extend the maximum limit to 64 slots. This upgrade sees the benefit of easier identification of the canonical block, enabling nodes to easily resolve conflicts when 2 or more competing forks appear, thus resulting in faster transaction finality.
Since the merge, communication between the execution client and consensus client is intermediated by a component called the Engine API. EIP-4788 aims to incorporate the beacon block root within a smart contract in the EVM allowing dApps to get trust-minimized access to the consensus layer through pulling in data natively from the execution layer. This would support use cases that improve trust assumptions of staking pools, restaking pools, smart contract bridges, MEV mitigations, and more.
This upgrade is especially important for ETH liquid staking protocols as these protocols currently rely on oracles to pull data such as the balance on validators from the consensus layer that is needed for execution (distribution of rewards). With the introduction of EIP-4788, a new design mechanism built on a ‘trustless oracle’ configuration can be implemented. This reduces a point of risk and enhances the efficiency of liquid staking protocols, as well as other protocols like bridges and restaking solutions.
EIP-7514 will alter the validator churn limit whereas EIP-1153 will introduce transient storage opcode in the EVM.
With the rollout of EIP-7514, there will be a cap on the maximum number of validators per epoch at 8, thereby transitioning the maximum growth rate from exponential to linear. The rationale for this is that an uncapped, exponential growth in the size of the active set of validators will lead to state-size bloat, placing additional strain on each node since they have to keep track of their peers. Testnet simulation indicated that client software struggled to perform past 2 million validators. Although having a large number of validators is beneficial in decentralizing the network, too much can cause state-size bloat.
EIP-1153 will introduce two transient opcodes: TLOAD and TSTORE. Transient storage is a welcoming solution as data can be temporarily stored and deleted after each transaction without the need for costly writes to EVM’s permanent storage. EIP-1153 complements the current existing storage types, providing a gas-efficient solution for inter-frame communications during Ethereum transactions.
Last but not least, we have EIP-4844, which is also known as “proto-danksharding”. This implementation will reduce the rollup costs of posting data to Ethereum via “blobs”. Currently, the cost of posting data on Ethereum remains exorbitant. As these scalability solutions aim to become the platform for mainstream adoption, the cost of posting rollup data will also rise significantly. By introducing a “blob-carrying’ transaction type, rollup sequencers will be able to post transaction data up to 100x more cheaply than is currently possible. Imagine the massive cost savings for these L2s aside from preserving scalability and decentralization!
But what are blobs exactly? A blob can be thought of as a ‘compressed’ data structure like a zip file that contains up to 128KB of data. Currently, a block on Ethereum contains all the bundled transactions to be validated and recorded on the blockchain. After the Cancun-Deneb fork, blocks will consist of these typical Ethereum transactions as well as blob-carrying transactions.
It is important to note that blob-carrying blocks do not include all the blob data but just a hash of a KZG commitment to the blob. As a result, L2 blob data cannot be executed by the execution layer of Ethereum (aka EVM). The actual data that constitutes the blob is stored on Ethereum’s consensus layer and only for a limited time of ~18 days. After that, the blob will no longer exist and evidence of its existence will be in the form of a KZG commitment that proves that the blob data existed and was included on Ethereum mainnet.
After EIP-4844 goes live, each block can accommodate up to 6 blobs although 3 is recommended due to the blob dynamic pricing structure that gets increasingly expensive to post data to Ethereum when more than 3 blobs are attached. However, this limitation will be temporary since the eventual danksharding upgrade could potentially increase the maximum number of blobs up to 16! Nonetheless, the upgrade would bring Ethereum capability to a new milestone, allowing it to support data posting of up to 5400MB/day, leading to a significant reduction in transaction fees.
That’s all for today, hope you guys like it~
[ad_2]
Source link