smartprogrammer.eth 🦇🔊

@koeppelmann I thought cl clients enabled it. But the website only mentioned lighthouse. @potuz_eth do you know if prysm has it? Whats the flag for that if it does?

would love to use it for Gnosis Chain bridges to have bridge time down to <1min (as an intermediate step towards EEZ). All it needs is a little bit more "love" of the feature from CL teams.

fastconfirm.it Did you know that under normal networks conditions CEXs and bridges could already safely accept deposits after 13sec? Those are the kind of improvements that matter so much and deserve more attention.

Is posting state diffs somehow preferred over posting transactions? Is there any other advantage to posting state diffs than potentially having smaller footprints in blobs thus better utilization of them? Am i the only one who prefers transactions being posted for history preservation and ease of reexecution?

@nero_eth do you think evm L2s could use BALs to publish state diffs for DA instead of txs out of the box?

Ethereum is about to fundamentally change how blocks are executed. With the upcoming Glamsterdam hardfork, it's shipping EIP-7928: Block-level Access Lists, a proposal that brings parallelization to the EVM. Here's a short explainer of what it is, how it works, and why it's a big deal for scaling. Let's start from the top. Alongside EIP-7732 (ePBS), EIP-7928 is the execution-layer (EL) headliner for Glamsterdam. Like ePBS, the main focus has been scaling Ethereum, though both proposals come with a bunch of other, equally important properties on the side e.g. removing trust requirements from the PBS pipeline or improving sync. EIP-7928 adds a Block Access List (BAL) to every Ethereum block. A BAL is a list of accounts and storage slots that the block touches, but that's not all: it also contains post-transaction state diffs (this part is critical!). Post-transaction state diffs tell you what the state looks like after each transaction. Quick example: user A swaps 1 ETH for DAI on DEX B. The BAL tells you that user A's ETH balance decreased by 1 ETH + tx fees and their nonce went up by 1; that DEX B's ETH balance went up by 1 ETH; and that inside the DAI contract, user A's DAI balance increased while DEX B's decreased. In other words, all of that info becomes statically available, something that previously required tracing the transaction. Client software (Geth, Nethermind, Besu, Erigon, Reth, Ethrex, Nimbus) can use this to do a few very powerful things: 1. Parallelize transaction execution. Knowing the post-state of each tx resolves the dependencies between them. No transaction has to wait on the previous one anymore, so execution can be perfectly parallelized. Instead of large parts of block validation sitting idle waiting on sequential execution, clients can finally make much better use of modern hardware. 2. Batch prefetch. One of the most cumbersome jobs for a node has been fetching the state needed for execution from disk. Because state locations (e.g. the exact storage slot in the DAI contract where user A's balance lives) are only discovered along the way, while executing, state-fetching has been a real drag on scaling: it blocks execution, takes time, and eventually slows everything down. With BALs, everything a node needs for execution is known upfront and can be loaded into cache in one go, in parallel. This speeds things up even further. 3. Parallelize post-state root calculation. Another expensive task is walking the updated state tree to compute the post-state root, which is needed so that everyone agrees on what's on disk after executing the block. With the post-tx state already in the BAL, nodes can do this in parallel while executing. A heavy task that used to wait until all transactions had finished can now run alongside prefetching and execution. 4. Snap sync (v2). An often overlooked, less sexy aspect of blockchains is syncing. Nodes need to catch up with the chain, and they need to catch up faster than the chain progresses. Today, most nodes do snap sync: downloading blocks, headers, and state in parallel while chasing the tip, and then "healing" the database once they're close to the head. Healing means asking peers for trie nodes, receiving them, validating them, and updating the local DB. It's iterative, networking-heavy, can take a while, and especially higher throughput pushes that phase to its limits. BALs help here too: with snap v2, nodes can catch up to the tip and skip the healing phase entirely. Syncing at higher throughput becomes more robust and reliable. So, to summarize, a BAL contains two things: -> The state locations the block accesses -> The state changes after each tx (incl. the new values) We're already seeing big performance gains today: on 6-core machines, EL clients validate blocks up to 5x faster, making block gas limits of 300M a very realistic outcome. ePBS will add to that by decoupling the block from the payload, giving validators 2-4x more time for execution. To not overshoot (security stays priority #1), the fork will likely ship with a 200M gas limit, but we shouldn't be stuck there for long before pushing to 300M and beyond. That's a 10x in scaling since we started taking the topic seriously, without touching hardware requirements. None of this would have happened without people going all-in, heads down, shipping: so many hours spent in calls debating the right design, so many iterations refining the specs, and tons of test cases written (and still being worked on). The road from whiteboard to production-ready code has been a journey, and we're not at the finish line yet, but from what I can tell, things look super bullish for Ethereum. Glamsterdam will be a fork that shows what's possible when a distributed, decentralized community works on a shared goal, laser-focused on providing enough block space to onboard the next wave of users.

1/ We're thrilled to welcome @AztecFND as the latest project to take the 1% Pledge 🎉 1% of the AZTEC token supply has been deposited into Protocol Guild's 4-year vesting contract to support 187 Ethereum core contributors across client teams, research, and coordination

Watch our partners explain why they're doubling down on synchronous composability. @OctantApp 🤝 @Nethermind 🤝 @blockscout 🤝 @growthepie_eth 🤝 @LineaBuild 🤝 @centrifuge

.@CoWSwap protects its users! Even though the hack was caused by something outside CoWSwap’s control - the domain registrar - CoW DAO decided to reimburse affected users. If you were affected, reach out!

And we just made another breakthrough! This is the first in-production system enabling instant swaps on an L2 using L1 liquidity, directly through the native bridge.

No third-party bridge. No custodial risk. A user on an L2 swaps xDAI to USDC using a Sushiswap liquidity pool on Gnosis L1. The rollup accesses L1 liquidity natively and settles the result back to L2 in a single transaction. 15 seconds.

@bnjmn_marie Please try the soft taper approach, found great results with this one x.com/i/status/20502…

Done. I have evaluated the structured CoT, with BNF grammars, to shorten the reasoning of Qwen3.6 27B. Conclusion: It's better to just disable reasoning😅 It works very well at shortening the reasoning when it's enabled, but it costs accuracy and still generates more tokens than with thinking disabled. I'm writing a full article to explain how I ran this.

We’re thrilled to unveil our new Interactive Interop page - a visual map of how value moves across the ecosystem. The ecosystem is no longer a list of silos. Our interactive hub lets you visualize the connections between 15 chains and 33 supported protocols. 👇

From the LZ hack, there is only one thing that is clear, we need synchronous composability and we need today. That's what surge.wtf offers, a first of its kind, realtime proven, synchronously composable L2 framework. Lets build the @etheconomiczone together. #ethereum

@nixorokish @ethStaker Would be very cool if we can get vouch built in @dappnode configurator to easily mitigate super majority risks

you have no idea how cool this is, anon

@fede_intern @leanEthereum No auction, i mean, you can have it truly based if you want. Or you can go with a centralized sequencer set that rotates every specific number of slots. Surge has been made way simpler than taiko stack now. The variance between the two is only increasing.

@Smartprogrammer @leanEthereum the last time i checked if my memory doesn't fail me there was also an auction to select the next sequencer right? also the taiko stack is a mess of complexity.

raise the gas limit to a stupid amount in the L1 move to @leanEthereum in the near future have multiple ZK implementations to prove the L1 add privacy if we really need rollups please please let's get based rollups and native rollups done as soon as possible and let's have multiple one click solutions like @ethrex_client to launch a rollup.

@trent_vanepps @ProtocolGuild Really appreciate all you have done and continue to do for the core devs and ethereum as a whole 🌷

as of last friday, I no longer work at the EF nothing but respect for the brilliant people i worked with over the last 5 years on network upgrades + funding efforts I intend to continue working on @ProtocolGuild and Ethereum political economy as long as funding is available

We absolutely poured our hearts out developing this end-to-end in record time (less than a month)! Give it a shot on @gnosischain mainnet: dex.realtime.surge.wtf

"The L2 Fee Vault: Pricing L1 Costs with Feedback Control", new post co-authored with @upavloff. Most L2 fee mechs today (e.g. OP Stack) price L1 costs using the L1 fee at sequencing time, not the realized cost at posting time, with no mechanism to correct when they diverge. 🧵👇

Yes and it is surge.wtf

What you're watching: a swap on Gnosis mainnet routed through L2 liquidity on Surge. Bridge, swap, settlement, all in a single L1 transaction. ZK proven by @ziskvm surge.wtf