# 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
174

Read more

EL R&D

Mandate curate a list of open problems in execution domain most people don't even know what the problems are, and those who do hord the information privately example problems: pricing for EVM operations, improving usability of bloom filter, safe gas limit for clients, address space extension, improved EVM arithmetic, multi-dimm fee market, increasing contract size, protocol proxy, etc deep technical expertise of the EVM, willingness to share knowledge often have the question, how does X change affect Y? or, what is the proper way achieve X goal in the EVM?

10/17/2024
3074 ideas

Here's an assortment of ideas Sam, Ansgar and I have had rumbling around for some time. EOA 2.0 A nice place to start would be an invoker that just improves the status quo for EOA users. It should add only the most basic functionality: self-relayed each authorization only valid once multiple ops in a single tx

4/14/2024
EF DAS Workshop Agenda

doubts about requirements of the das networking layer adversary supermajority malicious network actors 90%+ validators sample across validators? row / col dissemination gives good reconstruction properties

9/1/2023
Crested Butte Area Objectives

[toc] Hiking Treasury and Treasure Combo Elevation: 13,462 and 13,528 respectively TH: Yule Pass TH Mileage: 10.9 miles, 17.5 kilometers Gain: 5,118 feet, 1,559 meters GPX: Gaia

8/13/2023
Read more from lightclient
Published on HackMD