# 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? * bonus: demostrable expertise of zk EVM systems -- we are constantly asking how X will affect the inevitable zkification of the EVM. * analyze chain activity * periodically ask why are users doing certain things? are there inefficencies that can improved upon? * determine the effect of proposed changes based on current activity, e.g. increasing cost of storage, changing the behavior of SELFDESTRUCT, etc * L2 advocate * maybe reth and other clients are already sort of this, but a more neutral entity doing EL work while keeping L2s in mind could be useful ## Practical output Originally when I considered how an EL R&D team would look from scratch, I came up with the following plan. * the team would maintain a relatively minimal client, focused on housing prototypes * building / maintaining a client does the following * develops the team's expertise (originally didn't expect to land anyone who *actually* knows what they're doing) * gives the team legitimacy on ACD * creates a platform that the team can own. this allows them to organize code how they need / instrument what needs instrumentation w/o working about an upstream * brings the team closer to reality - sometimes hackmd warriors can be brash with their proposals * directly hook into testing pipeline that exists today * separately of the client, they could maintain several resources * aforementioned "open problems" * testbed for benchmarking clients (this kinda exists via evm lab, maybe other solutions) * relationship with other EL-related R&D work like stateless, improved p2p, AA, etc. which can act as a glue between the fairly disjoint efforts
Last changed by  
 
lightclient
132

Read more

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
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. stateless -- this is the next important Execution Layer frontier. It supports many of our long term goals in Ethereum: scalability, accessibility, and reliability.

4/9/2025
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
Read more from lightclient
Published on HackMD