# Preferences for Osaka The go-ethereum team has prepared a set of preferences for the next Ethereum fork, Osaka. ## Osaka and the future The Prague hardfork was unfocused and undisciplined with respect to scope. After the headlining features, PeerDAS and EOF, were dropped, the fork continued to grow with little to show. For Osaka we prefer a clear and restrained scope. If we maintain this, it is likely that the fork will be ready for mainnet later this year. If we undertake many additional projects for Osaka and beyond, it's likely we again slip into 2026. Beyond Osaka, we believe there are two main themes the execution layer should be working towards. 1) **stateless** -- this is the next important Execution Layer frontier. It supports many of our long term goals in Ethereum: scalability, accessibility, and reliability. 2) **zero knowledge vm** -- although further out, ZK is the endgame for many research streams on the EL. We should consider every proposal in the context of this. ## Preferences 1) **EVM Object format (EOF)** -- the team supports EOF with a preference for [allowing introspection](https://notes.ethereum.org/@ipsilon/eof_fusaka_options#D---Introspecting-EOF). * We should be cautious about using EOF to mask a multitude of underlying EIPs, however, to provide the best EOF platform we also generally support the following additions: [Separate Metadata Section for EOF](https://eips.ethereum.org/EIPS/eip-7834), [EXTCODETYPE instruction](https://eips.ethereum.org/EIPS/eip-7761), [EXTCODEADDRESS instruction](https://eips.ethereum.org/EIPS/eip-7880), and [PAY opcode](https://eips.ethereum.org/EIPS/eip-5920). 3) **secp256r1 Curve Support** -- [EIP-7212](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md) is relatively simple addition to the precompile suite that will allow many users to take advantage of HSM managed keys to interact on-chain. 4) **ModExp Gas Cost Increase** -- we believe `ModExp` is underpriced and should be adjusted with [EIP-7883](https://eips.ethereum.org/EIPS/eip-7883). 5) **Meter Contract Code Size And Increase Limit** -- the 24kb limit on code imposed by EIP-170 can be lifted if we make cost of loading code dynamic. This is the proposition [EIP-7907](https://eips.ethereum.org/EIPS/eip-7907) makes. Historically this has been thought to harm future efforts around stateless since the code size is not part of the state, rather it is maintained by each client independently. However, an important intuition recently is that statless will almost certainly need to chunk code anyways, so this is mostly a stop gap solution until then. Despite years of the 24kb limit, code size continues to be a major complaint of developers. Abstraction around this are not working so we should address it in the protocol. * Practically this means we will also need to bump the initcode size here too. See below why we believe [EIP-7903](https://eips.ethereum.org/EIPS/eip-7903) is incomplete. ## Declined Features Generally we decline all other EIPs proposed for inclusion. We specifically call out a few EIPs below. 1) **Add Controlled Gas Limit Increase Strategy** -- although the team is supportive of an in-protocol gas limit definition, we do not believe we have done the requisite work to consider further gas limit increases as proposed by [EIP-7783](https://eips.ethereum.org/EIPS/eip-7783). The fact of the matter is, the state continues to grow unbounded with no clear plan, and there is no clear solution in place. This has substantial downstream effects on I/O and sync. Until this is resolved, the team does not support further increases to the gas limit. 2) **Remove Initcode Size Limit** -- the 24kb limit was imposed on initcode in [EIP-3860](https://eips.ethereum.org/EIPS/eip-3860) to avoid attacks with cheap, programatically generated initcode. While we agree 24kb is rather limiting, we prefer a reasonable but explicit upper bound in [EIP-7903](https://eips.ethereum.org/EIPS/eip-7903) -- preferably 64kb as defined in [EIP-6800](https://eips.ethereum.org/EIPS/eip-7903).
Last changed by  
 
lightclient
965

Read more

H is for **Hardness**

Glamsterdam brings significant scaling to the chain that will continue to be realized months after the fork. Hegotá is a good opportunity to return to the topic of hardness after several forks focusing on throughput. Geth Headliner Pick EIP-8141: Frame transaction We believe EIP-8141 is the right choice for EL headliner. It is the ideal companion to FOCIL as it allows smart accounts to also benefit from the improved inclusion guarantees. While the EIP is new, it only brings minor changes to work pioneered by ERC-4337 over the last several years. It gives a definitive answer to how Ethereum's execution layer will migrate to post-quantum cryptographic schemes. Because the migration will take time, it's important to begin early. It also supports other core tenets like privacy and trustlessness. A common issue with privacy protocols today is that they require an EOA with funds to withdraw, which present a chicken-and-egg problem. Frame transactions allow the withdrawal to happen first, then gas payment is approved later. For trustlessness, we can begin to remove the paymaster intermediaries and rely on our public txpool for robust and decentralized transaction relaying.

2/26/2026
Frame Transaction

Add frame abstraction for transaction validation, execution, and gas payment

1/29/2026
Partial history expiry tweet thread

As of today, all Ethereum execution clients support history pruning for pre-merge data. For mainnet, this means 300-500 GB less disk space required to operate a node. Learn more about what this means and how to take advantage the new functionality: <insert link> If you're a full node operator or a validator, this change will not affect you beyond the space savings as history is not needed to validate the head of the chain. Archive node users and application developers who need the history to generate their custom indexes will need to begin migrating to external history providers as the history will become less available over the p2p with time. A list of providers can be found here: https://eth-clients.github.io/history-endpoints/ This is the first step towards full, rolling history expiry as defined in EIP-4444. Please see the EIP to learn more about the motivation for history expiry and the longer term plan history expiry: https://eips.ethereum.org/EIPS/eip-4444

7/7/2025
Partial history expiry announcement

As of today, all Ethereum execution clients support partial history expiry in accordance with EIP-4444. While work on full, rolling history expiry is ongoing, users can expect to reduce the disk space required for an Ethereum node by 300-500 GB by removing the block data prior to the merge. This will allow a node to fit comfortably on a 2 TB disk. See below for information on each specific client. Chain history By definition a blockchain is a chain of blocks starting at a specific genesis point. For Ethereum, that occurred on July 30, 2015. Each block includes information about the protocol itself, i.e. the current gas limit, a list of user transactions, and the result of those transactions encapsulated by a receipt. This data has many uses: Full validation of the chain requires executing every historical block to ensure that, not only is the current head state correct, but all historical states from genesis to today were correct. Constructing indexes over the chain history, e.g. tracking the balance changes of a certain account over time or how the state of a certain application changes. For L2s that have posted transactions using calldata, they would need the chain history to fully validate their chain or construct indexes. General proof-of-past operations such as proving a certain transaction was sent at some point. In rare cases, non-fungible token (NFT) data. But the prevailing method of hosting NFTs on-chain is to store the NFT data either in contract storage or reference external sources, such as IPFS.

7/7/2025
Read more from lightclient
Published on HackMD