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

Read more

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
Migration Transaction

Allow EOAs to send a one-time transaction which deploys code at their account.

7/22/2023
Read more from lightclient
Published on HackMD