🚀 Introducing @EthResearchBot: Your Gateway to the Latest Ethereum Research! 📚 💡 What is EthResearchBot? It's a Twitter bot powered by GPT-4, designed to keep you updated with concise summaries of the newest and most exciting research posts on the Ethereum Research Forum.

Weekly Roundup Formal Verification of Execution and Consensus Clients 🔗 ethresear.ch/t/25894 3 comment(s) this week Designs for EVM gas accounting in EIP-7999 🔗 ethresear.ch/t/25696 3 comment(s) this week Proprietary AMMs and Ethereum 🔗 ethresear.ch/t/25543 3 comment(s) this week Snappy with a memory: ~40% less gossip traffic 🔗 ethresear.ch/t/26078 2 comment(s) this week Capacity oracles 🔗 ethresear.ch/t/24716 2 comment(s) this week CHAMP: Hardening the Mempool with CHain-Anchored, Multi-dimensional Peer Protection 🔗 ethresear.ch/t/26074 2 comment(s) this week EIP-8411 payload segmentation under the Shadow simulator 🔗 ethresear.ch/t/26070 2 comment(s) this week Mempool Account Transaction Capacity from Historical Activity (MATCHA) 🔗 ethresear.ch/t/25949 2 comment(s) this week Post-Quantum Lattice or Hash-Based: One Question, Two Right Answers 🔗 ethresear.ch/t/26003 2 comment(s) this week Post-Glamsterdam One-dimensional Fee Market and Comparison with EIP-7999 🔗 ethresear.ch/t/26062 2 comment(s) this week Towards Encrypted Mempools from Threshold IBE without Batching 🔗 ethresear.ch/t/26040 2 comment(s) this week Ethereum's TCB, Part 1: The client 🔗 ethresear.ch/t/26086 1 comment(s) this week Lattice-based signature aggregation 🔗 ethresear.ch/t/22282 1 comment(s) this week Post-Poseidon: Hash Function Variants for Ethereum 🔗 ethresear.ch/t/26071 1 comment(s) this week EIP-8411: what segmented payload diffusion is made of 🔗 ethresear.ch/t/26025 1 comment(s) this week Etheorem update: the complete executable consensus specs written in Lean 4 🔗 ethresear.ch/t/26063 1 comment(s) this week EIL: Trust minimized cross-L2 interop 🔗 ethresear.ch/t/23437 1 comment(s) this week Strict role alternation: reciprocal broadcast without relayers for EVM shielded pools (spec + population simulation, no code yet) 🔗 ethresear.ch/t/26051 1 comment(s) this week Evidence Review Framework for Project Applications in Decentralized Guilds/Agent Systems 🔗 ethresear.ch/t/26048 1 comment(s) this week

New post on Eth Research! Ethereum's TCB, Part 1: The client By: - George (asn) - Kev 🔗 ethresear.ch/t/26086 Highlights: - Formal verification can’t remove trust entirely; the key metric is the size of the Trusted Computing Base (TCB)—the specs, tools, components, and assumptions we still have to trust rather than prove. - A practical verification strategy is to modularize the client and separate “pure” modules (mathy, minimal side effects, easy to verify—e.g., crypto, SSZ, fork choice rules) from “dirty” modules (I/O heavy, messy state—e.g., networking). - Dirty modules should initially be modeled as untrusted-by-design so that verified modules prove correctness for all possible inputs—meaning bugs in dirty code are handled like adversarial behavior rather than invalidating proofs. - What ultimately matters to users is end-to-end verification: not just proving theorems about a Lean4 model/spec, but also proving that the shipped implementation and its compilation pipeline correspond to that spec as closely as possible. - There are multiple end-to-end FV paths with different TCB and practicality tradeoffs: (1) translate Rust→Lean (translator + compiler stay in TCB and only a subset of Rust works), (2) implement verified modules in Lean and extract to C (extractor/C compiler/FFI in TCB), (3) write more of the client in Lean to verify glue code too, (4) write verified RISC-V assembly to remove the compiler from TCB (but trust the ISA model and need translation/emulation), and (5) use an FV-friendly language plus a verified compiler (e.g., Pancake) to push proofs down to machine code while departing more from today’s engineering norms. ELI5: Imagine Ethereum client software as a big robot made of many parts. Some parts are “clean math parts” (easy to prove correct), like checking signatures or encoding/decoding data. Other parts are “messy real-world parts” (hard to prove), like networking where messages can arrive late, out of order, or be malicious. Formal verification is like writing rock-solid math proofs that certain parts (or even the whole robot) cannot misbehave. The big idea is to shrink what we must blindly trust (the Trusted Computing Base, or TCB) by (1) splitting the client into modules with clear interfaces, (2) treating messy modules as untrusted inputs at first, and (3) pushing proofs closer and closer to the actual binary users run, using approaches like translating code to proofs, writing code in a proof language, writing low-level verified code, or compiling with a verified compiler.

New post on Eth Research! Snappy with a memory: ~40% less gossip traffic By: - Nashatyrev 🔗 ethresear.ch/t/26078 Highlights: - Compressing the entire gossip stream with shared context (instead of per-message Snappy) significantly reduces inbound bytes: ~73% of today’s bytes for a default node and ~63% for an all-subnets node using LZ77-in-Snappy-format with a 64 KiB history. - Most of the gain comes from cross-message redundancy: the repeated topic string and repeated AttestationData across a slot effectively become short back-references, leaving an attestation largely as signature + indices (~117 bytes). - A 64 KiB-history, Snappy-format LZ77 stream compressor gets big wins on consensus gossip: attestations compress to ~42% and aggregates to ~63% of current wire size in both default and all-subnets scenarios. - The approach is practical to integrate: it can be added as an optional negotiated protocol (e.g., /snappy-stream/meshsub/1.2.0) that decompresses back into the existing gossipsub RPC stream with today’s ssz_snappy payloads—no changes to message IDs, validation, or the rest of the gossip stack required. - Performance and safety look acceptable: decoding is essentially as fast as current Snappy plus a history buffer (same decompression-bomb bound); live tests showed large reductions on attestation-heavy streams (~43–44% wire bytes in a hub-and-spoke setup), while CPU and memory costs are predictable (64 KiB history per peer direction plus tables; compression is costlier than decompression but still a few percent of a core across several peers in rough estimates). ELI5: Normally, each gossip message gets squeezed (compressed) by itself, like packing each toy into its own small box. This research asks: what if we pack a whole stream of messages together, so we can reuse patterns we’ve already seen? Because many gossip messages repeat the same pieces (like the same topic name and the same attestation details), keeping a short “memory” of the recent past lets the compressor say “same as before” instead of sending the full data again. That can cut a lot of network traffic, especially for nodes that listen to many attestation subnets.

New post on Eth Research! CHAMP: Hardening the Mempool with CHain-Anchored, Multi-dimensional Peer Protection By: - cskiraly 🔗 ethresear.ch/t/26074 Highlights: - Random peer churn is important for openness and eclipse-attack resistance, but it is quality-blind and can repeatedly evict the most useful transaction-relay peers. - CHAMP adds an overlay of protected peer pools: per pool (inbound vs dialed), it shields roughly the top 10% of peers per quality dimension, then takes the union—so a peer is protected if it excels on any one axis. - Two key protection signals are chain-anchored and objective: peers are credited only when transactions they delivered first are (1) included at the chain head and (2) later finalized, tying reputation to on-chain outcomes rather than gameable off-chain behavior. - The churn rate is unchanged: at most ~30% of a pool is protected across three dimensions, leaving ≥70% still eligible for random dropping, preserving the random-graph properties while preferentially retaining high-value peers. - Protection is temporary and self-correcting via exponential moving averages (fast included EMA ~minutes, slow finalized EMA ~day, latency EMA ~many samples); peers that stop being useful decay out of protection, and the design is on-by-default and extensible (shipped inclusion protection in geth v1.17.5; latency protection is in progress). ELI5: Ethereum nodes can only talk to a limited number of other nodes (peers). To keep the network open and safe, they regularly drop a random peer so new peers can join and attackers can’t “surround” a node with only malicious connections. The problem is that random dropping can kick out the most helpful peers too. CHAMP fixes this by keeping a few “champion” peers protected from random dropping, based on several different kinds of helpfulness (like delivering transactions that actually get into the blockchain, or answering requests quickly). It doesn’t stop the random dropping—it just makes sure the drops mostly happen among the less-proven peers, while still allowing new peers to join.

New EIP! Deferred Payload Verification 🔗 github.com/ethereum/EIPs/pul… Highlights: - Adds a new BeaconState field, `payload_request_chain_root`, a chained accumulator that commits to the entire history of execution payloads (as commitments) up to the current block. - Enables deferred cross-layer verification during range sync: the consensus client can sync without downloading historical `ExecutionPayloadEnvelope`s and instead verify the whole range via a single equality check at the chain tip through `engine_newPayload`. - Introduces SSZ-based commitment containers (`ExecutionPayloadCommitment` and `NewPayloadRequestCommitment`) that include only the fields the consensus layer must directly “police”, while relying on `block_hash` to bind the rest of the execution payload contents. - Extends the Engine API: `engine_newPayload` gains a `payloadRequestChainRoot` parameter; execution returns `VALID` only if both the payload is valid and the provided chain root matches (or `SYNCING` if it cannot yet check). If the execution client has no prior accumulator, it must adopt the provided anchored value. - Reduces consensus-layer networking load by removing `ExecutionPayloadEnvelopesByRange v1` (historical payload envelope serving), leaving historical execution payload backfill to the execution layer’s existing block sync pipelines; tip/near-tip envelope-by-root and gossip remain unchanged. ELI5: When your node is catching up (syncing), it normally has to download lots of execution payload data just to double-check that the execution layer ran the exact payload the consensus layer agreed on. This EIP adds a running “fingerprint” (a chained hash) in the consensus state that commits to all past payloads. The consensus client can update this fingerprint using info it already has, without downloading old payload envelopes. Later, when the execution client has the blocks, both sides compare fingerprints once at the tip—if they match, it proves the whole synced history’s payloads match what was committed to.

New post on Eth Research! Post-Poseidon: Hash Function Variants for Ethereum By: - khovratovich 🔗 ethresear.ch/t/26071 Highlights: - Ethereum’s hash choice impacts multiple high-volume workloads (CL/EL post-quantum signatures, signature aggregation proofs, execution/state Merkle trees, and zkVM-style full block proving), and these workloads involve both short fixed-size inputs (e.g., 32→16 byte inner nodes) and very long leaf inputs—so padding/chunking behavior matters as much as raw throughput. - Security is two-layered: (1) how strong the internal primitive is (compression/permutation/blockcipher) based on cryptanalytic history, and (2) whether the overall hash construction has a proof of “random-oracle-like” behavior (indifferentiability); this disqualifies plain SHA-256 for random-oracle use due to length extension, despite its strong practical track record. - Performance requirements are driven heavily by proof systems like Flock, where XOR is free and cost scales with AND-gates: reported proving throughput is ~660K BLAKE3 compressions/sec, ~340K SHA-256 compressions/sec, and ~250K Keccak-f[1600] permutations/sec on a 10-core laptop—making circuit performance a key differentiator. - Tradeoffs by candidate: SHA-3/Keccak is the most scrutinized and standardized with strong sponge-mode proofs and big security margins, but is slow both natively and in circuits; BLAKE2s is fast, widely implemented (RFC 7693), and has a provable-security story, but has far fewer cryptanalysis papers; BLAKE3 is fastest (native and in Flock) but lacks standardization and indifferentiability proofs and has less dedicated cryptanalysis. - Overall recommended rankings depend on risk tolerance: a conservative, minimize-risk ranking puts SHA-3 first, then BLAKE2s and a SHA-2-based RO-patched variant; a more performance-leaning but still cautious view elevates BLAKE2s close to SHA-3, while viewing BLAKE3 and KangarooTwelve as promising but with adoption/analysis gaps. ELI5: Ethereum needs to pick “the best blender” (a hash function) for lots of jobs: making Merkle trees for the state, helping post-quantum signatures work, and helping proof systems verify big computations. Different blenders are good at different things: some are very trusted but slower, some are super fast but newer and less studied, and some are standard but have quirks that make them behave differently than an ideal “magic black box” hash. The article compares a few realistic choices (SHA-2, a patched SHA-2, SHA-3/Keccak, KangarooTwelve, BLAKE2s, BLAKE3) across security confidence, formal guarantees, speed on normal computers, speed inside proof circuits, and how standardized/adopted they are.

New post on Eth Research! EIP-8411 payload segmentation under the Shadow simulator By: - cskiraly 🔗 ethresear.ch/t/26070 Highlights: - Cross-checking the earlier EIP-8411 segmented-diffusion results in a second simulator (Shadow), across QUIC and TCP, shows the core benefit is robust: every segmented approach tested is faster than sending the whole message in all configurations. - The recommended design (A-tuned) reproduces earlier harness results within a few percent at both median (p50) and tail (p99) completion times, increasing confidence that the earlier findings weren’t just an artifact of the original in-process simulation harness. - Disagreements between simulators (notably whole-message latency and variant C’s ranking) largely trace to uplink queue modeling: the harness uses fair queueing (fq_codel-like sharing) while Shadow defaults to FIFO, and these policies change how competing copies/flows finish and how quickly nodes can start the next hop. - Transport matters in subtle ways: variant B shows a longer completion-time tail only under Shadow+QUIC (likely related to buffering/service effects), and Shadow’s TCP appears to give variant C extra benefit under FIFO that is probably a simulation artifact compared to paced TCP behavior on Linux. - A Linux “real stack” check (100-node cells) shows segmented QUIC results (A-tuned and C) land within roughly the simulators’ own variability (about −1% to +18% difference when paired with matching queue assumptions), while the whole-message approach both completes slower and drives substantially higher host CPU usage (about 2–4× busier) on the shared machine—though the study still does not model full client CPU/hashing costs or validate the bandwidth model. ELI5: Imagine you need to share a big book with 500 friends. If you wait until you have the whole book before you start sharing, everyone gets it late. If you tear the book into small chapters and start sharing chapters as soon as you get them, your friends can also start sharing chapters right away, so everyone finishes sooner. This article checks (1) whether that “share in pieces” idea still works when tested in a different, more realistic network simulator (Shadow), (2) whether it depends on using QUIC vs TCP to send data, and (3) whether results look similar on a real Linux networking stack. The main message: sending in segments is consistently faster than sending the whole message at once, but exact timings and which segmenting variant looks best can change depending on how network queues are modeled.

New post on Eth Research! Etheorem update: the complete executable consensus specs written in Lean 4 By: - leolara 🔗 ethresear.ch/t/26063 Highlights: - The Lean 4 consensus specs for three forks (Fulu, Gloas, Heze) now pass upstream conformance vectors for state transition, fork choice, and modeled SSZ containers, for both mainnet and minimal presets (pinned to consensus-spec-tests v1.7.0-alpha.11). - Etheorem is structured as a stack: cryptographic/hazmat primitives (LeanSha256/LeanHazmat) → formally-verified SSZ library (SizzLean) → spec authoring framework (EthCLLib) → per-fork specs and proofs (EthCLSpecs). - EthCLLib provides an inheritance system across forks (inherit/override) with late binding, so inherited functions re-elaborate in the child fork and automatically pick up the child’s constants/types/overrides—reducing duplication while keeping forks explicit and typechecked. - Spec code is written once but instantiated in two modes: a fast test-runner configuration (FFI SHA-256, blst BLS, caches, hashmaps) and a pure proof configuration (kernel-reducible SHA-256, symbolic BLS, simpler data structures), enabling both conformance testing and proof-friendly reasoning from the same source. - Formal verification progress is early but concrete: 8 spec functions are fully characterized by theorems (with more appearing in statements), proofs are kernel-checked with an auditable axiom footprint (only standard Lean axioms), and the project tracks proof coverage via a public proof ledger inviting contributions. ELI5: This post is about rewriting Ethereum’s consensus “rulebook” in a math-proof-friendly programming language (Lean 4) so it can both (1) run like real code and (2) have machine-checked proofs about what it does. The project is built in layers: a verified SSZ serialization/hashing layer (SizzLean), a spec framework that makes it easy to define types/functions/constants and reuse code across forks (EthCLLib), and then the actual fork implementations and proofs (Fulu → Gloas → Heze). The Lean code is tested against the official consensus-spec test vectors (like unit tests for Ethereum clients), and some key functions already have formal theorems proving their behavior. The framework also separates a fast runtime configuration (with real crypto via FFI) from a pure configuration suitable for proofs (with kernel-reducible hashing and symbolic crypto assumptions), keeping the proof trust base small.

New post on Eth Research! Post-Glamsterdam One-dimensional Fee Market and Comparison with EIP-7999 By: - M1kuW1ll - Fei Wu 🔗 ethresear.ch/t/26062 Highlights: - Baseline one-dimensional design (64 gas/byte floor, CPSB=1530) makes state the bottleneck in >90% of blocks, allowing high state growth (~288–403 GiB/year) while delivering relatively low execution (~82.0M–92.6M gas/block). - EIP-8368-style recalibration (adjust CPSB with the higher gas limit to preserve a ~120 GiB/year state budget) fixes the state-growth budget (~121–122 GiB/year) but worsens execution throughput because the shared base fee rises, reducing execution to ~67.5M–70.2M gas/block. - EIP-8372-style calibration (scale state pricing and normalize state accounting before fee updates) recovers a lot of execution (~151.9M–177.9M gas/block), but the single shared fee still cannot keep both regular and state utilization at target under demand shocks; normalized state utilization averages only ~72–73%, yielding lower realized state growth (~86–88 GiB/year) than the 120 GiB/year target. - EIP-7999 (separate base fees for execution/data/state) delivers substantially more execution while holding state growth near its separate target: ~173.6M–223.0M gas/block for historically anchored configs and ~252.9M–272.6M for maximum-throughput configs, with ~120 GiB/year state growth in these simulations. - Sensitivity checks show EIP-7999’s execution advantage persists across multiple elasticity estimates (execution gains remain positive vs the best one-dimensional benchmark), while one-dimensional outcomes—especially baseline and EIP-8368—depend strongly on assumptions about how far state demand expands at lower prices (the “state-demand tail”). ELI5: Ethereum blocks have limited “space” for different kinds of work: (1) computation (execution), (2) transaction bytes (data), and (3) new stored information (state growth). A one-dimensional fee market uses one shared base fee for all of these, so if one type (like state growth) gets popular, it pushes the shared fee up and can crowd out the others (like execution). This article simulates several ways to tune a shared-fee design (baseline, and two calibrations inspired by EIP-8368 and EIP-8372) and compares them to EIP-7999, which uses separate base fees for execution, data, and state so each resource can be priced and controlled more independently.

New post on Eth Research! Evidence Review Framework for Project Applications in Decentralized Guilds/Agent Systems By: - MATOBOYCRYPTO65 🔗 ethresear.ch/t/26048 Highlights: - Decentralized guilds and agent/coordination systems need a standardized way for applicants to submit structured “evidence packages” before receiving membership, authority, or funding. - Current review processes are often ad-hoc and off-chain, which creates friction and makes outcomes hard to verify or compose with on-chain standards and workflows. - The proposed framework centers on structured evidence submission (e.g., code, audits, performance metrics, compliance proofs) plus reviewer workflows that produce verifiable or attestable outcomes. - Recording review results in a reusable format could feed into downstream systems like reputation, access control, account authority lifecycles, and confidential policy verdict mechanisms. - Key open questions identified for community feedback include cryptoeconomic incentives (honest review, anti-collusion, sybil resistance), integration with agent trust/account abstraction standards, relevant prior art, and whether the work should evolve into an ERC discussion. ELI5: Imagine a club where projects (or robot helpers called “agents”) want to join and get special powers like access, funding, or permissions. Right now, people often decide based on messy notes and chat messages. This article suggests a more organized way for projects to submit a “proof folder” (like audits, code, and results), have reviewers check it using a clear process, and then record the decision in a way that others can trust and reuse—possibly even on-chain—so other systems can automatically understand who’s approved and why.

New post on Eth Research! Towards Encrypted Mempools from Threshold IBE without Batching By: - GottfriedHerold 🔗 ethresear.ch/t/26040 Highlights: - Design sketch for an Ethereum encrypted mempool that relies on threshold Identity-Based Encryption (TIBE) but explicitly drops the usual ‘batch decryption’ requirement, expanding the set of potentially usable threshold schemes. - Core mechanism: users first post a small on-chain ‘ticket’ (with a hiding commitment to the real transaction) that pins execution to a known future block; only after the ticket is included do they publish the encrypted transaction, using the ticket blockhash as the IBE identity to bind it to a specific fork and mitigate reorg replay issues. - A three-block pipeline enforces builder non-optionality: B[n] includes tickets; PTC votes on whether each encrypted tx was seen by a deadline; B[n+1] commits an `etx_seen` bitfield constrained by PTC votes; only then are decryption key shares released, and B[n+2] includes the reconstructed key and executes decrypted transactions top-of-block in ticket order (fixed two-block delay). - The extra consensus round (the `etx_seen` commitment) is intentional: it prevents any builder from making include/exclude decisions after learning decrypted contents, at the cost of latency and added protocol complexity. - The post emphasizes pragmatic failure handling (missed slots, reorgs, committee refusing/offline) and proposes a circuit breaker to preserve Ethereum’s dynamic availability by disabling the encrypted mempool and refunding reserved gas during prolonged decryption/key-release failure; major open problem remains finding a threshold IBE meeting all requirements, especially post-quantum security. ELI5: Imagine you want to send a secret message (a transaction) so nobody can peek at it and copy/cheat before it happens. This post suggests a way to do that on Ethereum by using: (1) a “ticket” you put on-chain first that reserves a future spot for your secret message, (2) a committee that later helps unlock the secret, but only after everyone agrees the secret message was actually shared with the network, and (3) a rule that the secret message is tied to a specific block’s fingerprint (blockhash), so if the chain rewinds (reorg), the secret message becomes invalid. The key trick is to avoid needing ‘batch decryption’ cryptography by making each transaction’s decryption identity depend on the already-known blockhash where the ticket landed, so the committee doesn’t need to agree on a whole set of ciphertexts at decryption time.

Weekly Roundup From 60M to 200M: simulating Glamsterdam’s fee market 🔗 ethresear.ch/t/25957 3 comment(s) this week Mempool Account Transaction Capacity from Historical Activity (MATCHA) 🔗 ethresear.ch/t/25949 3 comment(s) this week Wen fast payload broadcast? Segment, code, push, pull, and everything in between 🔗 ethresear.ch/t/25913 2 comment(s) this week Atomic ZK-Proof-Gated Settlement for x402 Agent Payments: A Measured Reference Design 🔗 ethresear.ch/t/25660 2 comment(s) this week Cryptographic canaries and backups 🔗 ethresear.ch/t/1235 1 comment(s) this week Same instruction count, 23x the wall clock: working-set effects in a deterministic RISC-V interpreter 🔗 ethresear.ch/t/25856 1 comment(s) this week Staking rewards as venture capital, governed by futarchy 🔗 ethresear.ch/t/26030 1 comment(s) this week Bounding Collusion in Capital Allocation DAOs via Subjective Human Oracles 🔗 ethresear.ch/t/25459 1 comment(s) this week How Hegotá can influence the state roadmap 🔗 ethresear.ch/t/25895 1 comment(s) this week EIP-8411: what segmented payload diffusion is made of 🔗 ethresear.ch/t/26025 1 comment(s) this week When Data Binds Execution: Dynamic Simulation of EIP-7999’s Multidimensional Fee Market 🔗 ethresear.ch/t/26018 1 comment(s) this week Post-Quantum Lattice or Hash-Based: One Question, Two Right Answers 🔗 ethresear.ch/t/26003 1 comment(s) this week Scaling Ethereum with recursive STARKs and the Trustless Log Index 🔗 ethresear.ch/t/26002 1 comment(s) this week Public-mempool gas sponsorship needs escrow, a bond, or trust 🔗 ethresear.ch/t/25995 1 comment(s) this week The Future of State, Part 1: OOPSIE - A new type of Snap Sync-based wallet/lightclient 🔗 ethresear.ch/t/23395 1 comment(s) this week Lean4 SSZ library: formally verified and easy to use 🔗 ethresear.ch/t/25988 1 comment(s) this week

New post on Eth Research! Staking rewards as venture capital, governed by futarchy By: - K1-R1 🔗 ethresear.ch/t/26030 Highlights: - The proposal (RawVentures) converts a voluntary portion of ETH staking rewards into recurring venture investment capital while leaving the staked principal untouched. - Rewards routed into the venture vault buy illiquid portfolio shares (no on-demand redemption), changing the risk profile of that portion of staking income from low-risk yield to high-variance venture exposure. - Investment decisions are made via “Reputational Futarchy”: shareholders stake (lock) their existing vault shares in prediction markets; the funded option is selected based on these market positions rather than 1-share-1-vote governance. - Markets are settled against pre-declared, verifiable outcome milestones after funding (e.g., customer adoption targets); incorrect forecasters lose committed shares to correct forecasters, creating a public track record of judgment without minting new shares or diluting passive holders. - Key open challenges include market/selection-rule design, pricing new contributions into an illiquid portfolio, incentive compatibility and manipulation resistance, and independent verification of outcomes—plus proving the system can outperform conventional VC on risk-adjusted, ETH-denominated returns after costs. ELI5: Imagine you earn extra ETH for helping keep Ethereum secure (staking rewards). Instead of keeping all those rewards, you can choose to send some of them into a shared piggy bank that invests in new Ethereum-related startups. People who own pieces of that piggy bank bet (using prediction markets) on which startup ideas will do well, and if they bet wrong they lose some of their pieces to people who bet right. Later, real-world results (like “did the startup get real customers?”) decide who was right, and everyone can see who makes good predictions over time.

New post on Eth Research! EIP-8411: what segmented payload diffusion is made of By: - cskiraly 🔗 ethresear.ch/t/26025 Highlights: - Mainnet payload propagation is “fast enough” largely due to small blocks and the presence of datacenter builders/high-bandwidth nodes; segmentation reduces reliance on those actors and improves decentralization. - EIP-8411’s core mechanism is segmented payload diffusion: split the payload into fixed-size pieces and include a Merkle root commitment in the bid so peers can verify and relay pieces immediately, eliminating per-hop store-and-forward delay via pipelining. - In simulations using real Prysm + go-libp2p-pubsub logic on a modeled network, segmentation plus batch publishing reduces median delivery for a 1 MiB payload from ~5 s (whole-message gossip) to under 1 s and improves tail latency to just over ~1 s, even in a “home builder, no datacenter nodes” baseline. - Duplicate traffic can be dramatically reduced without additional wire-format/spec changes beyond the commitment by using: announce-instead-of-push (limited eager forwarding), a diffusion-aware ‘phase shift’ using IDONTWANT signals, and disciplined pulls (bounded IWANTs with timeouts/peer parking), reaching ~1.5 payload-copies of total bytes per node at 1 MiB. - A tiered implementation path is proposed: Tier 1 (commitment + segmentation + batch publishing) for big latency wins; Tier 2 (adaptive push + disciplined pulls) for major bandwidth savings; Tier 3 (compress-first, rate-1/2 erasure coding + stop-pull with commitment) for the best tail latency and strong robustness to withholding, at the cost of higher source/receiver bandwidth. ELI5: Ethereum needs to quickly share a big “package” (the execution payload/block data) with lots of computers. Today it works mostly because some very fast, well-connected computers help carry the load. This research suggests splitting the package into many small pieces so computers can start forwarding pieces immediately (like passing pages of a book as soon as you get them), instead of waiting to receive the whole book first. A small cryptographic “seal” (a Merkle root) in the builder’s bid lets everyone check each piece is real before forwarding it. The post then adds extra techniques to reduce wasted duplicate sending, and optionally uses erasure coding (adding recovery pieces) so you don’t need every original piece to finish—helping when some peers are slow or malicious.

New post on Eth Research! Scaling Ethereum with recursive STARKs and the Trustless Log Index By: - zsfelfoldi 🔗 ethresear.ch/t/26002 Highlights: - Post-quantum (PQ) cryptography will likely increase signature sizes, making “recursive STARK transaction pre-authorization” (EIP-8288) an attractive path because it can dramatically reduce effective on-chain verification costs for signatures and other witness data. - If EIP-8288-style cheap ZK verification becomes available, statelessly verifiable witness data gets much cheaper on-chain—including proofs for log queries built on the Trustless Log Index (EIP-8304)—making log-index-based designs far more viable. - The Trustless Log Index can serve as shared infrastructure for trustless chain indexing and cross-chain/cross-shard message filtering; application-specific indexers can become cheaper by proving only relevant logs since a checkpoint instead of processing full block receipts. - EIP-8304 uses a hybrid model: small, recent index tables are maintained in-protocol for low-latency access to the chain head, while larger historical merges can be proven/updated asynchronously with ZKPs—balancing freshness guarantees with incentive alignment. - Log index tables have lower write cost than the state tree (per-block sorting + hashing, with efficient asynchronous merges), and logs can act as an alternative storage model (time-series tuples) that can represent sets/lists without key-collision issues—potentially helping statelessness, state expiry, and simplifying sharded execution patterns. ELI5: Ethereum needs to handle more activity without making the blockchain too expensive. This article suggests using very efficient cryptographic proofs (recursive STARKs) so transactions can prove they’re valid with less on-chain cost—especially important if future post-quantum signatures get big. It also proposes an on-chain “phone book” for event logs (the Trustless Log Index) so you can quickly and trustlessly find past events/messages. That makes it easier to build trustless indexers, do cross-chain/shard messaging, and even store some kinds of contract data as an append-only history (logs) instead of constantly rewriting a big key/value database (the state tree).

New post on Eth Research! Lean4 SSZ library: formally verified and easy to use By: - leolara 🔗 ethresear.ch/t/25988 Highlights: - SizzLean implements the full SSZ stack in Lean 4 (serialization/deserialization plus Merkleization) and provides machine-checked proofs of core correctness properties across essentially all SSZ types used by the Ethereum consensus spec (excluding only zero-width shapes). - The byte-codec is formally verified for three central guarantees: roundtrip correctness (decode(encode(x)) = x for well-formed values), non-malleability/injectivity (distinct values cannot share an encoding), and static size bounds (encodings never exceed schema-computed limits). - Merkleization is verified end-to-end: the library’s cached Merkle-tree backend is proved to match the spec’s hashTreeRoot for covered types, and both single and batched updates are proved to preserve correct roots; generalized indices/openings used by light clients and data availability are derived from a proved index model. - It passes upstream Ethereum consensus SSZ test corpora comprehensively (ssz_generic and ssz_static across mainnet/minimal presets and forks from Phase 0 through Fulu, including ePBS containers), and it is additionally exercised by a Lean 4 implementation of consensus specs built on top of SizzLean that passes consensus vector tests. - The trust base is deliberately small: reliance on native SHA-256 is isolated to three explicit axioms asserting equivalence to a pure Lean SHA-256; that pure implementation is itself proved against FIPS 180-4 and validated with NIST CAVP vectors, and the library design supports swapping hash functions without changing container definitions or proofs. ELI5: Ethereum consensus clients need a very strict way to (1) turn data structures into bytes (so everyone sends/reads the same messages) and (2) hash those structures into Merkle roots (so everyone agrees on the same commitments/proofs). SizzLean is a Lean 4 library that implements this SSZ “encode/decode + Merkleize” pipeline and then uses Lean’s proof checker to mathematically guarantee key safety properties (like “decode(encode(x)) = x” and “two different things can’t serialize to the same bytes”). It also provides an easy ‘derive’ feature so you can define a type once and automatically get serialization, hashing, and the proofs for that type.

Weekly Roundup Mempool Account Transaction Capacity from Historical Activity (MATCHA) 🔗 ethresear.ch/t/25949 5 comment(s) this week Wen fast payload broadcast? Segment, code, push, pull, and everything in between 🔗 ethresear.ch/t/25913 3 comment(s) this week Formal Verification of Execution and Consensus Clients 🔗 ethresear.ch/t/25894 3 comment(s) this week Capacity oracles 🔗 ethresear.ch/t/24716 2 comment(s) this week Letting the base fee be a midpoint: a temporal liquidity authorization for EIP-1559 🔗 ethresear.ch/t/25958 1 comment(s) this week From 60M to 200M: simulating Glamsterdam’s fee market 🔗 ethresear.ch/t/25957 1 comment(s) this week Atomic ZK-Proof-Gated Settlement for x402 Agent Payments: A Measured Reference Design 🔗 ethresear.ch/t/25660 1 comment(s) this week Bloom Filters And Keyed Nonces 🔗 ethresear.ch/t/25950 1 comment(s) this week Designs for EVM gas accounting in EIP-7999 🔗 ethresear.ch/t/25696 1 comment(s) this week Proprietary AMMs and Ethereum 🔗 ethresear.ch/t/25543 1 comment(s) this week Exploring the Design Space for a Post-Quantum Public Key Registry for Ethereum Validators 🔗 ethresear.ch/t/25040 1 comment(s) this week How Hegotá should approach gas repricing 🔗 ethresear.ch/t/25935 1 comment(s) this week Order-dependence as the classifying dimension for frame-transaction mempool admission 🔗 ethresear.ch/t/25934 1 comment(s) this week Can We Verify an ERC, Not Just Its Code? 🔗 ethresear.ch/t/25926 1 comment(s) this week EIP-8141 and minimum required validation budget for privacy applications 🔗 ethresear.ch/t/25889 1 comment(s) this week Proposed PQ upgrade for ecrecover 🔗 ethresear.ch/t/25844 1 comment(s) this week

New post on Eth Research! From 60M to 200M: simulating Glamsterdam’s fee market By: - @misilva73 🔗 ethresear.ch/t/25957 Highlights: - Across 12 demand scenarios (4 demand levels × 3 price elasticities) simulated over 7,200 blocks (~1 day), the typical pattern is: an initial base-fee spike, then a decline as the gas limit ramps up and demand responds, then stabilization around the new 100M gas-per-block EIP-1559 target (50% of the 200M limit). - The early fee spike is driven by modeling choices: demand is applied immediately at block 0 while capacity increases gradually (60M → 200M over ~1,234 blocks / ~4 hours) and the demand response uses a smoothed price signal; the author cautions the spike magnitude is illustrative, not a forecast. - After the adjustment period (using blocks 3,000–7,199 as the “settled” window), 9 of 12 scenarios converge to median utilization near the 50% target, with settled-period median base fees spanning a wide range (~0.0002 to 0.3928 gwei). - The remaining 3 scenarios stay below target even when base fees become nearly zero: (1x demand, elasticity 0.1) ~28.3% utilization; (1x, 0.2) ~38.7%; (1.5x, 0.1) ~41.4%. In these low-demand cases, tips dominate what users pay and added capacity remains unused. - Similar utilization can correspond to very different fees because elasticity changes how much price needs to fall to attract enough demand: e.g., at 2x demand, all elasticities reach ~50% utilization, but settled median base fees range roughly from 0.0059 gwei (elasticity 0.1) to 0.1058 gwei (elasticity 0.3). ELI5: Ethereum blocks have a “size limit” (gas limit) and people pay fees to get their transactions included. Glamsterdam changes how much “gas” transactions cost and also slowly increases the block gas limit from 60M to 200M (so blocks can fit more work). The study simulates about one day after the change to see what happens to fees and how full blocks are. When blocks are too full, the built-in fee (EIP-1559 base fee) goes up; when blocks are emptier, it goes down. But lowering fees can also attract more transactions, so the final fee level depends on how much extra demand shows up and how strongly users react to price changes.

New EIP! Decouple Stake from Validator Registration 🔗 github.com/ethereum/EIPs/pul… Highlights: - Staking becomes a 2-step flow: (1) deposit ETH + withdrawal credentials + a versioned authorization commitment on the execution layer to get a StakeID immediately, then (2) register the validator on the consensus layer using that StakeID and proof data (e.g., BLS pubkey + proof of possession). - StakeID is the primary identifier for the position and is derived from the staking contract’s append-only stake-event tree: StakeID equals the event index of a CREATE_STAKE leaf (top-ups are separate events and do not create new StakeIDs). - Authorization is future-proofed via a versioned 32-byte authorization commitment stored at stake creation; the initial version commits to the BLS public key (VERSION_1 || SHA256(pubkey)[1:]), while later versions could support new credential schemes without changing the staking contract interface. - Validator registration verification moves to the consensus layer, which can enforce rules that require global validator state (e.g., preventing reused credentials, ensuring a stake isn’t already bound, and reserving credentials during pending registration). Bad registration data no longer implies funds are lost; the stake can remain unregistered. - Lifecycle operations (top-ups, withdrawals, and EIP-7251 consolidations) reference StakeID instead of validator pubkey; additionally, unregistered stakes can be fully recovered by the withdrawal authority via a CL-queued recovery mechanism (rate-limited per block and queue size-limited), but cannot be consolidated. ELI5: Today, when you stake on Ethereum, you have to give the system both (1) the money (ETH) and (2) the validator’s special “identity keys” at the same time. This proposal splits that into two steps. First, you lock ETH in a staking contract and immediately get a simple receipt number called a StakeID. Later, you (or an operator) use that StakeID to register the validator by proving you have the right validator key. This makes staking easier to track, safer if you mess up the registration data, and more future-proof if Ethereum changes how validator identities work.

New post on Eth Research! Order-dependence as the classifying dimension for frame-transaction mempool admission By: - AnkushinDaniil 🔗 ethresear.ch/t/25934 Highlights: - The unifying classifier behind multiple proposed mempool/admission mechanisms is whether validation reads order-dependent (contended) state, not how much state it reads. - The paper groups state reads into three contention classes: Class 0 (single-writer, e.g., sender nonce/balance debit), Class 1 (recent-root-bound where staleness is acceptable, enabled by recent roots), and Class 2 (live-contended shared state requiring the latest value, e.g., AMM price or first-come slots). - Order-independence within a block aligns with commutativity; via the CALM theorem, the “coordination-free” (order-free) validity fragment corresponds to monotone/commutative checks. - Existing proposals—MAX_VERIFY_GAS, VOPS profiles, recent roots, 2D gas, and validity proofs—are best understood as different thresholds/ways of handling these contention classes rather than unrelated rules. - There is an irreducible floor: exactly-once assertions like “this nullifier is unspent” or “this slot is free” are anti-monotone and inherently require coordination/ordering (supported by CALM and the Herlihy consensus hierarchy), so no proof-carrying admission scheme can eliminate sequencing for that core. ELI5: When a blockchain node decides whether to accept a transaction into its waiting room (the mempool), it often has to run the transaction’s “validity check.” With account abstraction, that validity check can be any code, so attackers could make nodes do lots of unpaid work. This article says the key question isn’t “how much state does the check read?” but “does the check’s answer depend on the order of transactions in the block?” If the answer does NOT depend on order (like checking only your own nonce), it can often be checked cheaply or even proven ahead of time. If it DOES depend on order (like checking a shared slot is still free), then someone must coordinate and decide an order—there’s no way around it.