EIPsInsight 🔜 Devcon 8

New EIP! Engine API proposal lookahead 🔗 github.com/ethereum/EIPs/pul… Highlights: - Adds a new optional Engine API method: engine_proposalLookaheadUpdatedV1, sent from consensus layer (CL) to execution layer (EL) with upcoming proposal slots plus timestamp, suggestedFeeRecipient, and targetGasLimit. - The call is advisory only: it must not start block building and does not affect fork choice; engine_forkchoiceUpdated with payload attributes remains the only authoritative build trigger and source of final attributes. - ELs may use the lookahead to do parent-independent preparation such as fetching blob data, warming state caches, pre-executing transactions using announced context, scheduling maintenance away from the slot, and managing bandwidth. - Request semantics: the provided list replaces the EL’s stored set (empty list clears); max 256 entries; entries must have all fields and strictly increasing slot and timestamp; defined error codes -38004 (too many) and -32602 (invalid params). - Privacy/DoS considerations: revealing proposer timing earlier can enable targeting if preparations are externally observable; ELs should randomize observable prep timing, bound resource usage, avoid exposing proposals via public RPC/metrics/logs, and the method is gated by engine_exchangeCapabilities so non-supporting clients are unaffected. ELI5: Today the execution client only finds out it must build a block right when the consensus client starts the build, leaving little time. This proposal adds a new “heads-up” message where the consensus client tells the execution client, minutes ahead, which future slots it will need a block for and what basic settings (time, fee recipient, gas limit) will be used. The execution client can then quietly prepare (like preloading data) so it can build faster when the real build request arrives.

New post on Eth Research! How Much Screening Buys a Second? Speed, Selection, and the Maker's Spread By: - @nuconstruct 🔗 ethresear.ch/t/26158 Highlights: - A competitive break-even spread can be derived with minimal assumptions—only that the price innovation over the quote-exposure horizon has finite expected absolute value—so the results apply even with jumps, point masses (atoms), and infinite variance. - Empirically, 1-second ETH-USDT midpoint innovations are highly non-Gaussian: about 73% of seconds have zero price change and the distribution has extreme excess kurtosis (154), meaning many calm seconds and occasional large jumps. - Because of this non-Gaussian shape, reducing quote exposure from 12 seconds to 1 second cuts expected absolute price shock by 84.5% (much more than the 71.1% predicted by a Gaussian diffusion), so Gaussian rules materially understate the value of speed. - To match a 1-second unscreened venue while quoting at 12-second cadence, a maker must screen out roughly 84.5% of informed flow (about “six in seven” informed orders), and this threshold remains ~84.5–85.2% over plausible toxicity levels, so the conclusion is robust to uncertain toxicity. - In trending periods, staleness shows up one-sidedly at execution: with-trend fills achieve an effective spread about 11.1 bps better than against-trend fills across all four pools, and discrepancies grow with elapsed staleness with elasticity ~0.45 (near the diffusion benchmark of 0.5). ELI5: When a liquidity provider (LP) posts a buy and sell price, they can lose money if someone who knows the price just moved trades against their now-outdated (stale) quote. LPs can protect themselves in two main ways: (1) update their price more often (be faster), or (2) reject trades that look “too informed” (screening). This article measures how much screening a slow LP would need to do to be as safe as a fast LP. Using crypto data, it finds that because real 1‑second price changes are very ‘lumpy’ (usually zero, sometimes big jumps), speed is extremely valuable: to make up for being stuck with 12‑second staleness, you’d need to reject about 85% of informed trades.

New post on Eth Research! Rapidblocks, take two: a pipelined consensus for independent blocks By: - cskiraly 🔗 ethresear.ch/t/26152 Highlights: - Blocks are made mostly independent by separating dependencies into two edge types: “Hist” (state executed on) and “refs” (filters respected). A block must avoid touching keys modified by concurrent blocks it doesn’t build on (compatibility via access/modify sets and Bloom-like filters). - Consensus is reframed to decide one value per slot (a block header hash or ⊥), not to pick a single chain head; the canonical set is derived deterministically from these per-slot decisions plus feasibility/compatibility rules, letting blocks be skipped without reorgs and enabling very short slots. - The voting protocol is a pipelined, multi-round window vote (Round 0 header timeliness, Round A body availability/validity/feasibility, then follow rounds with view-merge and a thin-view fallback), plus two key anti-attack rules: “own values” (don’t chase tallies still in progress) and “closure” (don’t fast-confirm blocks that depend on not-yet-locked decisions). - Safety and liveness hinge primarily on networking latency for aggregated votes: safety requires vote latency ℓ ≤ mτ − 2Δ (e.g., ~1.0s when τ=2s, Δ=0.5s, m=1; ~3.0s at m=2). With good latency, confirmations arrive in ~3s and the pipeline behaves like ‘build on the block two slots back, reference the previous one’. - Empirical mainnet measurement (sample of 501 blocks sliced into 2s chunks) suggests most traffic could use the “fast path” (≈87% of txs / 69% of gas), but details matter: fee credits must be treated as read-free, conflicts must be tracked per storage slot (not per contract), and filter sizing/false positives become important, especially with multiple concurrent slots. ELI5: Imagine making a line of Lego towers where each new tower usually has to sit directly on the last one—so if one tower is missing, everything after it falls. This proposal changes the rules so a new tower can usually sit on the tower from two steps ago, as long as it promises not to touch the same Lego pieces that the skipped tower changed. Then, if one tower is missing or late, you can skip it without knocking down later towers. The paper also designs a voting system so everyone can quickly agree, slot by slot, which towers count, while keeping only a small recent “window” flexible and treating everything older as safely fixed.