# 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 * do validators randomly sample? * maybe, row / col is usually sufficient * row / col assume honest majority * attest after receiving rows / cols * no deadline for random sampling * forkchoice for next block with samples * is it necessary for anonymity for validator * let's try to not degrade system if possible * hardware requirements * builder - high powered, 5gbps+ bandwidth * validators * institutional nodes 1gbps+ * home staker 50mbps uplink * full node * 50mbps * is it okay to ahead of time know what nodes will host which parcel? * times to mount specific attacks, but unsure if it problematic * issue if we use gossipsub due to churn * partitioning attacks * targeted attack on samplers (full node) * can convince a small number of nodes, but not enough to corrupt the overall set * do you have to choose locally which samples? * ~~unclear~~ local * where will global randomness come from? need to be secure from supermajority malicious validator set * overview of approaches * dissemination * generally need "the list" of all nodes in network - so does DHT make sense? * how to know exactly which node in DHT should get certain value * honest minority is uniformly distributed across the DHT * datahop * didn't use gossipsub because channels are pretty small, often direct connections to everyone on channel * codex * dissemination * gossipsub on validators, channel per row and col * non-validators could listen on topic for region they need to serve on DHT * 200 samples per node * saw more like 800-900 per gossip channel * sample providers * relax assumption around supernode? * whole thing or subset ? * expensive to run * way forward? * need to remember to think of scaling in terms of network participants * need more engineers * specs -> CL specs * multiple options to explore * support from client teams mid next year 6-9 months - light prototyping / designs 6-9 months - serious prototyping -> try testnets / start more widely circulated specs make codex x datahop chat x pop * mapping samples to node ids * proof of validator dht * networking operations * dissemination * seeding * sampling * reconstruction * way forward?
Last changed by  
 
lightclient
63

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