Podcast Summary
Ethereum's Series of Hard Forks: Dankshrine, Petra, and Beyond: Ethereum is undergoing a series of hard forks, starting with Dankshrine, which introduces 'stone age blobs' and allows for independent evolution. Following Dankshrine, there are other EIPs coming in Petra and future updates.
Ethereum is undergoing a series of hard forks, starting with Dankun 4844, which brings "stone age blobs" but allows for independent evolution. Following Dankun, there are other EIPs coming in Petra and further ones in the future. Tim Beiko, the Ethereum Foundation coordinator, explains these technical advancements in detail on this episode of Bankless. For those interested in the 300-400 level technicalities of Ethereum, this episode is a must-listen. Sponsors like Kraken and Celo, which aim to make crypto trading and transactions more accessible, support the show.
Ethereum's Hard Forks: Star Names for Consensus, City Names for Execution: Ethereum's hard forks have unique naming conventions for consensus and execution layers, with star names for consensus and city names for execution. They usually fork together but can technically do so independently.
Ethereum's hard forks, denoted by names like Denkun, Cancun, and the upcoming Petra, have unique naming conventions for the consensus and execution layers. The consensus layer uses star names, while the execution layer uses city names. These layers can technically fork independently, but in practice, they usually fork together. The name of a hard fork is a portmanteau of the names of the consensus and execution layer upgrades, such as Denkun being a combination of the Deneb and Cancun upgrades. Dankun, also known as the "blob hard fork," introduced Ethereum's data availability layer through EIP4844. The next hard fork, Petra, is expected to follow the naming trend, derived from the merging of Prague and Electra. Understanding these naming conventions and the independent but interconnected nature of the consensus and execution layers is essential for following Ethereum's development.
Ethereum's Dankshrine Upgrade Introduces Blobs for Scaling Solutions: Ethereum's Dankshrine upgrade introduces Blobs, large data structures that can be used off-chain, reducing network load. Future improvements allow for more data without affecting Layer 2 transactions, moving towards efficient data handling. Ethereum also introduces EIP 7514 for controlled validator entry to prevent network congestion.
The Ethereum network's upcoming Dankshrine upgrade, which includes the implementation of Blobs, sets the stage for future scaling solutions like full bank sharding. Blobs are essentially data structures that can be used to store large amounts of information off-chain, reducing the load on the main Ethereum network. The upgrade allows Layer 2 solutions to utilize these new transaction types and access more blob space in the future, without needing to undergo additional upgrades. The current implementation of Blobs, referred to as "stone age blobs," may require a hard fork, but the future evolution of these blobs, which can fit more data without affecting Layer 2 transactions, is a significant step towards more efficient data handling on the Ethereum network. Additionally, Ethereum is implementing EIP 7514, which introduces a max epoch churn limit, allowing a more controlled rate of validator entry to prevent potential network congestion. These upgrades mark important progress towards Ethereum's goal of increasing scalability and accommodating a growing validator set.
Proposing a limit of 8 validators per Ethereum block: Ethereum community aims to slow down growth, discuss ideal number of validators, and move towards stateless clients by limiting validators per block and changing how self destruct operates.
The Ethereum community is proposing a cap of 8 validators per block to slow down the rate of growth and give the community time to discuss and determine the ideal number of validators for the network. This cap will be implemented at the hard fork, and self destruct, an opcode used to delete contracts, will no longer destroy the contract but instead send the funds back to the specified address. The main issue with self destruct is that it's the only opcode where the amount of computation required is unknown, making it difficult to accurately estimate gas costs. This change is a step towards Ethereum's long-term goal of moving towards stateless clients, which requires changing how data is stored on Ethereum and makes self destruct increasingly expensive to run.
Exploring Ethereum's Technical Development through EIPs: EIPs like EIP-2929 for self destruct, EIP-7044 for perpetually valid signed voluntary exits, and EIP-7045 for increasing the max attestation inclusion slot, highlight Ethereum's ongoing technical advancements, ensuring network security and functionality.
The Ethereum Improvement Proposals (EIPs) discussed, including EIP-2929 for self destruct, EIP-7044 for perpetually valid signed voluntary exits, and EIP-7045 for increasing the max attestation inclusion slot, demonstrate the depth and complexity of Ethereum's technical development. Self destruct, while deactivated in most cases, is still important to preserve for edge cases and critical flows. Perpetually valid signed voluntary exits, as outlined in EIP-7044, allow users to sign exit messages that are valid forever, enabling trustless staking constructs. Lastly, EIP-7045 increases the max attestation inclusion slot, allowing validators to collect attestations farther, resulting in a longer valid period for the first attestation of an epoch. These EIPs showcase the continuous evolution of Ethereum's infrastructure and the importance of addressing both edge cases and technical improvements to ensure the network remains secure and functional.
Connecting Ethereum's consensus and application layers with EIP 4845: EIP 4845 creates a contract on Ethereum that stores the latest block hash for beacon chain blocks, reducing complexity and strengthening the bridge between consensus and execution layers, and includes minor EIPs for gas reimbursement and data storage.
Ethereum Improvement Proposal (EIP) 4845, also known as the Beacon Chain data availability, connects the Ethereum consensus proof-of-stake (PoS) layer with the Ethereum Virtual Machine (EVM) and the application layer, specifically DeFi. This connection allows for trustless proofs about the state of the beacon chain, reducing the need for external oracles. This is significant because projects like Rocket Pool, ODAO, Eigenlayer, and AVS rely on the state of the Ethereum consensus layer and ETH, and they need to know this information to function effectively. By creating a contract on Ethereum that stores the latest block hash for beacon chain blocks, it reduces the complexity at the layer 2 and creates a stronger bridge between the consensus and execution layers. Additionally, there are three minor EIPs: 1153 Transient Storage Opcode, 5656 m copy, and 7516 Blob Base Fee Opcode. The Blob Base Fee Opcode is the simplest, allowing for trustless reimbursement of gas when submitting fraud proofs in Layer 2 solutions.
New opcodes and Ethereum advancements: Ethereum community introduces new opcodes, cheaper data storage, grants for projects, and scalability solutions to enhance web 3 development.
The Ethereum community is continuously innovating to improve the network's functionality, scalability, and affordability. Two new opcodes, t store and t load, have been introduced as part of EIP-1153, enabling transient storage that disappears at the end of a transaction, making data storage and retrieval cheaper. Mantle, a DAO-led web 3 ecosystem, is offering grants to promising projects to expand and decentralize their network. Arbitrum, a leading Ethereum scaling solution, allows users to interact with Ethereum at scale with low fees and faster transactions. Uniswap, a DeFi platform, has introduced a sidebar browser extension, limit orders, and data insights pages to enhance user experience. These advancements aim to make web 3 development more secure, fast, cheap, and friction-free. The Ethereum community is working on the next hard fork, named Pektra (formerly known as Prog and Elektra), which will merge selected Ethereum Improvement Proposals (EIPs) into the Ethereum network.
Ethereum's Latest Upgrade: Petra, Includes Four EIPs: Ethereum is undergoing significant upgrades through a series of forks, the latest being Petra, which includes improvements for efficient signature aggregation, execution layer triggerable exits, and prepares the way for larger initiatives like vertical trees and full sharding.
Ethereum is currently undergoing significant upgrades through a series of forks, with the latest being Petra. Petra is a smaller fork that includes four Ethereum Improvement Proposals (EIPs), including the implementation of BLS 12381 precompiles for efficient signature aggregation and verification, and execution layer triggerable exits that allow smart contracts to initiate withdrawals on the Beacon chain. Ethereum developers are also working on larger initiatives in parallel, such as transitioning to vertical trees on the execution layer and implementing full sharding on the consensus layer. These initiatives are expected to take some time, allowing for smaller forks to be implemented in the meantime. The upcoming forks are likely to be more independent from each other, and there may be an EIP to ensure they are compatible. Ethereum is moving towards a regime of having multiple large initiatives happening in parallel, while also shipping smaller but useful improvements.
Ethereum's Upcoming Upgrades: Strengthening the Connection Between DeFi and Consensus Layer: Ethereum's upcoming upgrades aim to remove delays in on-chain actions, allow for more efficient storage solutions, and enable full bank sharding for increased scalability and efficiency.
Ethereum's upcoming upgrades, such as Pectra, Elektra, and The Verge, aim to strengthen the connection between the DeFi layer and the consensus layer, increase scalability, and bring in statelessness. One of the ways this is achieved is by removing delays in on-chain actions, like deposits, and allowing for more efficient storage solutions, such as BLOBs. Additionally, proposals like PureDAS aim to enable full bank sharding, allowing nodes to store only a part of the data on the network. The Ethereum community is working on several EIPs, including Inclusionless, Max Effective Balance, and Puredas, which are expected to be implemented in upcoming forks. The goal is to make these upgrades relevant and not spend several years on each fork. With the implementation of these upgrades, Ethereum aims to become more scalable, efficient, and prolific, enabling more devices and transactions relevant to Ethereum all over the Internet.
Ethereum's proposed scaling solution Puredas increases data availability through sharding and reduces validator compute requirements: Ethereum researchers propose Puredas, a scalability solution that shards data, allowing validators to store less data and rely on others for confirmations, potentially reducing requirements and enabling the network to handle more data without increasing bandwidth significantly.
Ethereum researchers are proposing a scaling solution called Puredas (Practical Updatable Data Availability Sampling), which aims to increase the network's data availability by sharding data across multiple nodes. This approach allows validators to only store a part of the data for a limited time, while relying on other nodes' confirmations to ensure data completeness. This method can help reduce the validator compute requirements and enable the network to handle more data without increasing bandwidth requirements significantly. Puredas is a promising step towards scalability, even though its final implementation might differ from the current proposal. It's part of the evolution of blobs in Ethereum, with more blobs (smaller individual data units) forming larger aggregates. The current Ethereum validator system has limitations, such as the 32 ETH cap and high bandwidth requirements. Puredas addresses these issues by enabling more efficient data handling and potentially reducing the number of messages validators need to send.
Exploring ways to reduce Ethereum validator bandwidth and enable any size staking through MaxEV and Inclusion List: Ethereum researchers are investigating MaxEV and Inclusion List to lower bandwidth requirements, enable any size validator staking, potentially eliminate unused ETH, and improve censorship resistance.
Ethereum researchers are exploring ways to reduce bandwidth requirements and allow for any size of validator staking through Maximum Effective Balance (MaxEV). MaxEV could potentially enable validators to aggregate their signatures, lowering bandwidth needs and making it easier to run a validator. It could also eliminate the issue of unused ETH when staking in increments. Additionally, MaxEV could enable solo validators to compound their rewards. Another area of research is Inclusion List, which aims to improve censorship resistance by allowing validators to specify transactions they believe should be included in the network, potentially addressing validator censorship and a validator forcing an external block builder to include transactions. However, these features come with complexity and trade-offs, and their inclusion in Ethereum's next fork is not guaranteed.
Ethereum's Censorship Resistance vs Profit Maximization: Ethereum validators face a trade-off between censorship resistance and profit maximization, with potential solutions including an inclusion list or a validator-to-validator setup. The community debates the balance between quick fixes and complex solutions.
The Ethereum network is currently facing a trade-off between censorship resistance and profit maximization, particularly in the context of MEV Boost and the TBS infrastructure. Validators must choose between building their blocks themselves or delegating to external builders, which could potentially lead to censorship if the builder chooses profit over censorship resistance. MEV Boost currently uses a min bid flag to mitigate this issue, but a more robust solution could be an inclusion list that forces builders to include specific transactions in the block. This validator-to-validator setup would provide full censorship resistance at the validator set and improve base rollups, but it's more complex to implement. A simpler solution would be to make this change within MEV Boost without a hard fork. Another EIP worth mentioning is EIP 4444 or EIP 4 Fours, which proposes stopping the serving of historical data from Ethereum as the main peer-to-peer network for all premerge stuff. This is just one of the many proposals being discussed in the Ethereum community. Overall, the Ethereum community is debating the balance between implementing quick fixes and more complex, powerful solutions, and the long-term value of robust protocol-layer changes.
Exploring alternatives for obtaining Ethereum data: Ethereum devs seek to reduce network burden by importing data from external sources, ensuring security and matching current chain head, with ongoing discussions for EVM upgrades, account abstraction, and transaction encoding improvements, but with potential risks.
Ethereum developers are working on improving the network's efficiency by exploring ways to obtain historical data from sources other than the Ethereum network itself. This is being done to reduce the burden on the peer-to-peer network and make the syncing process more secure. This involves exporting data in a good format, having trusted servers to serve this data, and verifying that the imported history matches the current head of the chain. Additionally, there are ongoing discussions and proposals around upgrading the Ethereum Virtual Machine (EVM), improving account abstraction, and encoding transactions in different formats. These are just a few of the many Ethereum Improvement Proposals (EIPs) being considered. It's important to remember that while these upgrades and improvements can bring benefits, they also come with risks, as with any innovation in the crypto space. Stay informed and stay safe, Bankless nation. For more details, check out the resources mentioned in the show notes.
