ACDE #217: Fusaka stable; 16.8M tx cap holds
FOCIL #16: IL bit list, two-step enforcement
Code chunking could cut node data
Summary:
Fusaka testnets are mostly stable. Two consensus clients had issues (one networking, one MEV-related) but fixes are in and participation is ~94%. More testing is underway.
Single-transaction size limit: Core devs debated capping how big one transaction can be (from today’s ~30M gas down to 16.8M). Some app teams say 16.8M breaks complex swaps and batch ops; others argue a lower cap improves safety and future parallelization. Tentative path: keep 16.8M for now, gather data this week, and revisit on the next testing call.
PeerDAS “super-node” load: A proposal to ease bandwidth/storage requirements for smaller/home stakers (by raising the threshold before a node must hold all samples) was discussed. General vibe: good topic, but too late for Fusaka—consider it later via a parameter update.
Release timeline: Teams are aiming for client releases around early September, followed by staged forks on public testnets (e.g., Holesky, Sepolia). If things go smoothly, mainnet could land late Oct/early Nov; dates will be firmed up next week.
Next upgrade “headliners”: On the Execution Layer (EL) side, Block Access Lists (BALs) has broad support. On the Consensus Layer (CL) side, there’s an ePBS vs. Delayed Execution discussion. Plan: CFI BAL now; decide ePBS vs. Delayed Execution next week. If ePBS is chosen, BAL ships alongside it.
Open items
Fresh data on how a 16.8M vs 20M/30M cap impacts real apps (e.g., DEX aggregators, batch use cases).
Final call on ePBS vs. Delayed Execution (then confirm EL pairing: BAL).
Whether/when to adjust PeerDAS custody thresholds (likely after Fusaka).
Lock the testnet/Mainnet dates once teams confirm readiness.
Why it matters
The per-transaction cap balances user needs with network safety and future speedups.
PeerDAS tuning affects how friendly Ethereum is to home and community stakers.
Clear timelines and headliners keep the next upgrade on track—and understandable for the broader ecosystem.
Summary:
Builders will publish a tiny checklist (the "Inclusion List (IL) Bit List") showing which community “must-include” transaction lists they used; proposers can favor blocks that respect them.
Validators add two guardrails: a quick early warning in the same step and a definitive check in the next—so problems get fixed without shaking chain stability.
6-second slots remain on the table, but message/data timing gets tight and needs benchmarking.
Open items
Who should issue the early warning (all validators vs. a smaller committee)?
Benchmarks for bid/inclusion-list/data propagation—especially if moving to 6-second slots.
Follow-ups on an edge case where temporary data withholding could hide a sensitive transaction.
Why it matters
Stronger censorship resistance, clearer accountability for builders, and a path to faster blocks—if the timing proves safe.
Summary. Stateless Consensus looked at how Ethereum contracts run and found that, in a typical block, contracts only touch a fraction of their total code. That means we don’t always need to ship or verify all the code—just the parts actually used. If we store contract code in small “chunks,” nodes can move less data around.
Why it matters. Smaller, smarter code handling = lighter nodes, faster syncing, and lower bandwidth needs, which supports decentralization of node operators.
Summary. If Ethereum eventually requires zero-knowledge proofs for blocks, we’ll need a dependable way to get those proofs every slot. This proposal by @_Julianma would create a Prover Market which would allow " block builders to connect with a permissionless set of provers" so that anyone who submits a proof may collect a part of the prize in the next slot.
Why it matters. More provers = fewer single points of failure, clearer economics, and better uptime for the network.
Summary. Fei Wu, Danning Sui, Thomas Thiery and Mallesh Pai shared their findings after tracking traders who profit by hopping between centralized exchanges (like Coinbase/Binance) and decentralized exchanges (like Uniswap) for 19 months. It estimates approximately $233 million was extracted by these arbitragers and shows that a small number of players earn most of it.
Why it matters. When profits concentrate, so does influence. This informs policy debates (e.g., PBS/ePBS) and helps the community understand who benefits and how to keep markets fair.
Summary. “Data Availability Sampling” (DAS) lets lots of regular users help check that big blocks of data really exist—without everyone downloading everything. The post contrasts today’s simpler one-dimensional approach (PeerDAS, slated for mainnet release in November) with a two-dimensional design that could later let users rebuild parts of missing data more flexibly.
Why it matters. Short term: ship the simple version to scale safely. Long term: explore 2D ideas to make verification even more accessible.
Code chunking: Only the used parts of contract code need to move around → less data, faster nodes.
Prover market: Pay any team that submits valid proofs → more competition, fewer bottlenecks.
CEX–DEX profits: A few traders capture most arbitrage gains → watch decentralization and fairness.
DAS path: Ship the simple approach now; explore 2D for future partial reconstruction on everyday devices.
ERC-TBD: ERC-20 Pre-initialization Function — Gas Savings for First-Time Receivers — Proposes a simple “setup” step in ERC-20s to cut gas the first time someone receives a token.
Soliciting stakeholder feedback on Glamsterdam headliners — Open thread to weigh in on next-upgrade priorities (e.g., EPBS on CL; Block Access Lists on EL).
Secure Intents: A Cryptographic Framework for Autonomous Agent Coordination (Draft EIP) — Draft standard for “intents,” letting users/bots express goals safely (not raw transactions).
EIP-7987: Transaction Gas Limit Cap at 2^24 — Discussion on capping single-tx gas to help safety and future parallelization.
The BIG ‘introduce yourself’ thread — Community roll call for newcomers and contributors.
ERC-TBD: Intent-Based State Transition — Explores moving from transactions to higher-level, goal-driven actions.
For more updates like these subscribe to Ethereum Daily and follow us on the social media platforms below.
Disclosures: Ethereum Daily is an independent publication and does not offer financial or investment advice. Content may include opinions, affiliate links, or references to projects in which contributors have a financial interest. Always do your own research.
Ethereum Daily
ERC-7996: Contract Feature Detection — Standardized way for apps to discover what a contract supports.
ERC-7943: Universal RWA Interface (uRWA) — Toward a common interface for tokenized real-world assets.
EIP-7825: Transaction Gas Limit Cap — Alternate thread on the per-transaction cap.
ERC-7977: Future-block oracleless randomness — Randomness without external oracles.
ERC-681: Representing transactions as URLs — Renewed interest in link-based transaction requests.
Support dialog
Excellent and comprehensive summary of the recent developments, especially surrounding the Pectra upgrade. Your ability to distill complex topics like the inclusion of EIP-3074 and the validator balance unification into such a clear and accessible format is truly valuable for the community. I found the point about increasing the Max Effective Balance from 32 to 2048 ETH particularly interesting. This is a significant quality-of-life improvement for stakers and node operators, reducing operational complexity. It’s a practical change that often gets overshadowed by the more theoretical EIP debates, so thank you for highlighting it. It will be fascinating to watch how the final scope of Pectra solidifies, particularly around the ongoing discussions on EIP-3074. Thanks again for this insightful roundup. Looking forward to the next one!