Toni Wahrstätter ⟠

AI agents need privacy, and Ethereum can provide it. Here’s a clip of two autonomous agents discovering each other, generating stealth addresses, and interacting privately on Ethereum. More details in the 🧵👇

New EIP! Quick Slots 🔗 github.com/ethereum/EIPs/… Highlights: - Core change: move `SLOT_DURATION_MS` from a compile-time constant to a fork-activated runtime configuration, so future slot-time changes become parameter updates rather than large client refactors. - Proposed initial reduction is 12s → 8s slots, aiming for noticeably better UX (faster confirmations, deposits, payments) and also improvements to on-chain market dynamics (reduced arbitrage loss/MEV and less incentive for empty blocks under proposer/builder separation). - Throughput is kept approximately constant per unit time by scaling per-block capacity with slot duration: the fork block forces a one-time gas limit adjustment to `parent_gas_limit * new/old`, and the blob schedule appends a new `MAX_BLOBS_PER_BLOCK` scaled by `new/old`. - Several consensus/economic constants are adjusted to preserve wall-clock properties when epochs arrive more frequently: issuance (`BASE_REWARD_FACTOR`), inactivity leak parameters, data availability request windows (to match real-world rollup challenge periods), and validator churn limits (to preserve weak subjectivity safety in wall-clock time). - Risk is primarily feasibility under tighter timing (propagation, validation, attestation aggregation, validator hardware). The EIP explicitly proposes performance characterization (devnets/benchmarks) before committing to the minimum safe slot duration; if shorter slots aren’t viable, the infrastructure work still delivers cleaner clients and readiness for later. ELI5: Ethereum makes new blocks in repeating “time boxes” called slots (currently 12 seconds). This EIP proposes (1) changing clients so the slot length isn’t hardcoded but can be set at runtime after a fork, and then (2) shortening slots (example target: 8 seconds) to make transactions feel faster. To keep the network’s overall throughput about the same per second, it also scales down how much can fit in each block (gas limit) and how many data blobs can be included per block, because blocks would come more often. It lays out a phased plan: first build the flexible timing infrastructure, then measure real bottlenecks on test networks, then safely reduce slot time step-by-step.

@_julianma @binji_x @ethereumfndn @grok what is the boundary to count as gen Z?

@_julianma @binji_x @ethereumfndn I'm so close...

The @ethereumfndn gen Z mafia keeps growing.

@binji_x @ethereumfndn push

@binji_x @ethereumfndn What year is the cut-off?

@trent_vanepps Hmm, haven't noticed it yet.

been seeing extra spaces " " in longer form articles/posts here, and if i were to guess it's bc people are copying out of a terminal from writing with claude. nothing wrong with that per se, but it's a tell and annoying to see

Not every major protocol update requires a hard fork. Confirmed blocks cover most use cases. More than half of CL clients have already implemented a prototype or previous version of FCR. Buckle up for >60x faster pace.

Confirming blocks in just one slot, Ethereum’s got you.

EF’s new Platform team sets a clear direction for Ethereum as a unified L1–L2 platform. -> Strengthen Ethereum as a unified L1 + L2 platform -> Align protocol development with ecosystem needs -> Improve ecosystem coordination, integration, and metrics More in the quoted tweet.

Yeah I agree and see that. I would love to bump it too, just to make the existing devs happy, and have new devs that are yet to join not to think about such limits. On the other hand, we also want to keep the node requirements low, guaranteeing decentralization, while not making opcodes like CALL or EXT* more expensive, breaking backwards compatibility. Today, if it meant less scale, I wonder if app devs prefer larger code over their users interacting with their app cheaper. I wouldn't think so. But what i'm trying to say is, it's not free until we can appropriatly charge for calling/using larger contracts, making it more expensive relative to the actual resource consumption, and until then we may get to 32KiB in glamsterdam and hopefully larger afterwards with proposals like EIP-7907. But many things are still to be figured out, waiting to be solved. Quite optimistic we'll get there though.

even a meager increase would be appreciated. maybe assumed it was easy incorrectly, but it’s been a headache for smart contract devs for a long time and was slated for fusaka until being cut. i hear it will make its way to glamsterdam and I hope it doesnt get cut again. please do know that this is a pretty much universal want from those wishing to build dapps on ethereum and that we have to add complexity to get around it, and imo if you want to make devs happy and to encourage more sc development, this would be universally appreciated among sc devs.

hey @ethereumfndn the highest impact and easiest thing you can do for smart contract developers right now is to increase the contract size limit.

@GiulioRebuffo @functi0nZer0 Right, EIP-7907 charges 2 gas/word beyond 24KB, which is linear.

@nero_eth @functi0nZer0 yeah, but those increases are linear to page faults? ofc 8, 10kb are the same, they literally touch the same amount of pages. the trend is linear not exponential. linear gas increase should be enough?

I genuinely couldn’t give a shit what the Ethereum Foundation puts out or prioritises so long as the contract code size limit is raised in Glamsterdam I am an incredibly simple man

I agree, lots of scaling since Spurious Dragon (2016), but back then the gas limit was 5.5M (EIP-150) and broad adoption was more a dream than practically feasible. I'm all for pushing code size if we can, but it's not just changing a constant. You didn't say that, tbf, but it's a take I keep seeing on CT. The same people that chase devs for higher contract sizes would go nuts if it meant CALL costs had to go up for _every_ contract to maintain today's worst-case execution times. There are ideas involving new trie structures (binary tries) or pricing CALLs to large contracts higher than small ones (EIP-7907), which would help, but we don't have that today, and those proposals are challenging to ship on their own. For example, at 150M gas limit with 2600 gas for a cold CALL, you can force nodes to load 57k+ contracts in a single block. Based on @CPerezz19's analysis (ethresear.ch/t/data-driven-…), that takes 3.2s and 3.6 GiB of memory for 64 KiB contracts, or 2.2s for 32 KiB. Today we only have 1–2s for execution. Glamsterdam will help bc IO, execution, and state root computation can then be parallelized (EIP-7928), and we may get more execution time (EIP-7732). But higher gas limits might also mean longer block propagation, eating into that budget. With glamsterdam it will become possible and EIP-7954 (32 KiB) is already slated to be shipped. Even bigger contracts may be nice for some use cases, def agree, but at least for now they're not free. It's directly less room for scaling elsewhere because we always need to consider worst-cases that could be exploited by attackers to dos the network. So, it's a trade-off: cheaper gas/more users/uglier code vs. larger contracts. Devs are working on this and I wish more people acknowledged the complexity instead of treating it as a trivial constant bump. Not saying you did that but I've seen it a lot and I'm now just using your tweet a bit as a brain dump for myself.

Honestly, yes: I’m not particularly seeking out a double or tripling off the bat here, but 24kB has been in place since Spurious Dragon and we’ve done plenty on scaling since, it’s time to loosen the choker incrementally - disregard 7907 for now, I’d be happy with even 32kB to start, let’s see! Having to load logic into proxies to subvert the limit complicates documentation and developer comprehension and reeks of bad code smell every time I’m forced into it I don’t want to implement Conway’s Game of Life onchain, I just want to see signalling of the recognition that the things we want to bring to Ethereum are becoming more complicated after what is coming up on a decade of stasis on this front

@griffgreen Thinner fingers, now!

100%... We need more guardrails.

"No one listens. If it takes 50 million for people to finally listen, so be it."

Devcon Mumbai! Loading... ███████▒▒▒

Privacy + self custody, all the way.

@0x9212ce55 How would you trust a diff that is not committed to in the block, while also not having a proof against the state root for every item?

@nero_eth Sounds similar to BSC's diff sync they have implemented a long time ago but then deprecated for some reason.

New post introducing Snap v2 for Ethereum sync. TL;DR: replace trie healing entirely by applying Block-Level Access Lists (BALs). Instead of iteratively discovering what changed one trie node at a time, nodes can just download the state diffs from BALs and apply them. Simpler protocol, way fewer round trips, and a sync design that's ready for higher gas limits and continued state growth. 🔗 ethresear.ch/t/snap-v2-repl…

@scalpsxbt @0xmikedee @ethresearchbot No, @ethresearchbot is the great work of @destroyr_

@0xmikedee @nero_eth @ethresearchbot He even did a post today on it.

check the follows, loaded with good muts + eth foundation peeps ~240k mc now