🚀 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.

New post on Eth Research! Secure Transaction Verification and Authorization (STVA) By: - MATOBOYCRYPTO65 🔗 ethresear.ch/t/26192 Highlights: - STVA proposes a canonical way to attach structured, human-readable metadata and semantic intent to any transaction or UserOperation so the meaning of a signature is clear. - It requires an independent simulation/verification interface that wallets, signers, and third-party verifiers can call to reproduce and check the transaction outcome before signing. - It introduces scoped, revocable, short-lived capability tokens for privileged actions (like upgrades, large transfers, module installs, or ownership changes) to avoid broad, long-lived approvals. - It defines stricter requirements for multisig and smart-account signing ceremonies to resist compromised frontends, UI spoofing, and supply-chain attacks. - The motivation is that many 2024–2026 major losses came from signing-flow weaknesses (blind signing, malicious UI/calldata mismatch), and existing standards (EIP-712, ERC-1271, EIP-4337, etc.) don’t fully standardize the end-to-end secure verification loop STVA targets. ELI5: STVA is a proposed rulebook for crypto transactions that makes wallets show a clear, standardized description of what a transaction will do, forces an independent “test run” (simulation) before signing, and uses short, limited permissions for risky actions—so you can’t be tricked into signing something different from what you see.

New EIP! EIP-8450: Post-Quantum Validator Key Registry (leanXMSS + VRF root) 🔗 github.com/ethereum/EIPs/pul… Highlights: - Each validator registers two post-quantum commitments in beacon state: a leanXMSS public key for future signing and a 32-byte VRF-tree root to commit to non-grindable random outputs. - Registration is a new consensus-layer operation (no execution-layer request path): it includes a proof-of-possession signed with leanXMSS at leaf index 0 and is authorized by a BLS signature from the validator’s current pubkey. - To prevent replay and throttle changes, each validator has a stored last-change epoch; the registration includes the previous_change_epoch and key changes are rate-limited by MIN_PQ_KEY_CHANGE_DELAY (default 256 epochs; smaller in minimal preset). - Uniqueness is enforced for the leanXMSS key across validators (so validators can’t share/copy signing keys), but VRF roots are allowed to collide (two validators may commit to identical VRF trees). - The registry is ‘dormant’ in this fork (duties still use BLS); its purpose is readiness measurement and early verification/testing of post-quantum primitives defined externally in EIP-CRYPTO. ELI5: Ethereum validators currently use BLS signatures, which quantum computers could break. This EIP adds a new “phonebook” in the beacon chain state where each validator can pre-register post-quantum cryptographic material ahead of a later upgrade. Each validator stores (1) a hash-based leanXMSS public key for future signatures, and (2) a Merkle-root commitment to a huge VRF tree that pre-fixes one random-looking output per index so validators can’t ‘game’ randomness-based selections later. Validators prove they really control the leanXMSS key (proof of possession) and authorize updates with their existing BLS key; the new keys are recorded now but not used for duties until a future fork.

New post on Eth Research! Ephemeral Rollup: The New "L1.5" of Ethereum By: - namnc 🔗 ethresear.ch/t/26187 Highlights: - Rollups scale verification but also custody user state inside a rollup contract, which is why users need an “exit”; the proposed “L1.5” pattern avoids this by not having the middle layer hold state at all. - L1.5 is defined as an architectural pattern: wallets hold users’ private/opened state, L1 holds shared/global state plus commitments and nullifiers, and an ephemeral compute layer produces (new state, proof) and then disappears. - For a job to count as L1.5 (not just an operator), it should be stateless between jobs, have its outputs verified by L1, allow payment without identity linking, and be able to land results on L1 without relying on a long-lived submitting operator. - Native account abstraction and related proposals (notably frame transactions, keyed nonces, and proof aggregation) are presented as the key enablers that make it practical for contracts to verify proofs and pay for their own transactions, while nodes can relay them and proofs can be aggregated. - The pattern could enable new app designs (e.g., gasless private payments via blind tickets, fair exchange for services using ZK contingent payments, and potentially stealthier privacy pools) and suggests a migration path from L2-centric designs toward “wallet + L1 verification + ephemeral provers.” ELI5: Instead of putting your stuff (your account’s detailed state) inside a rollup that can trap it unless you “exit,” this idea says: keep your personal details in your wallet, keep only shared records and check-results on Ethereum L1, and let temporary “helpers” do the heavy computation and produce proofs. These helpers don’t keep anything important after they finish, and Ethereum verifies everything directly, so if one helper disappears, another can take over without you being stuck.

New post on Eth Research! Inventory of PQ P2P Migrations in the Consensus Layer By: - adust09 🔗 ethresear.ch/t/26183 Highlights: - Consensus-layer PQ migration has three coupled targets: (1) Discovery (ENR signatures, identity proofs, and key exchange), (2) QUIC/TLS 1.3 key exchange, and (3) libp2p/TLS connection authentication (Peer ID binding and TLS CertificateVerify). - Discovery and libp2p identities are related but not interchangeable: the Discovery node ID is used for routing-table lookups, while the libp2p Peer ID authenticates the transport endpoint; any future decoupling requires an authenticated, standardized mapping to avoid substitution attacks. - Severe size constraints drive the design: ENRs are capped at 300 bytes and Discovery v5 packets at 1,280 bytes, which rules out many direct PQ signature/key substitutions (e.g., ML-DSA public keys/signatures are far too large) and implies new record/credential distribution approaches. - Hybrid PQ key exchange in TLS (e.g., X25519+ML-KEM via RFC 10024) can address “record now, decrypt later” threats for confidentiality, but it does not solve PQ authentication—signatures for discovery proofs, libp2p identity binding, and TLS CertificateVerify still need PQ or hybrid signature plans. - A complete migration needs coordinated, downgrade-safe profiles, encodings, tests, DoS mitigations, and cross-client interoperability work; relevant libp2p PQ identity/encoding proposals are still open, and no Ethereum CL networking PQ profile exists yet. ELI5: Ethereum nodes find each other (discovery) and then talk over encrypted connections (QUIC/TLS via libp2p). Today those steps rely on cryptography that a future quantum computer could break. This post explains that making validator signatures post-quantum isn’t enough—you also have to update discovery records, the discovery handshake, the QUIC/TLS key exchange, and the libp2p identity checks. The hard part is that the discovery “business card” (ENR) and discovery packets are very small, so many post-quantum signatures and keys don’t fit, meaning discovery likely needs a redesign rather than swapping algorithms.

New post on Eth Research! Proof of One: one-person-one-identity polling with encrypted ballots — design and reference code, requesting critical review By: - NemoUnus 🔗 ethresear.ch/t/26184 Highlights: - The system aims to combine proof-of-unique-human enrollment with end-to-end verifiable encrypted voting: unique participants, private ballots, voter self-verification, and public recountability. - Enrollment is based on reading ICAO 9303 e-passport chips via NFC and producing a zero-knowledge proof that the chip data is signed by a trusted document-signer certificate, without revealing the underlying document data. - A trusted/attested enclave performs live-face to chip-photo matching and duplicate detection (via an OPRF-based document fingerprint and 1:N face search), but is designed to only sign a hiding commitment so it cannot link real people to on-chain identity leaves; re-enrollment can revoke an old identity via a hidden revocation handle. - Voting uses one-hot exponential ElGamal ballots on Baby Jubjub with a per-poll threshold key; a Groth16 proof attests eligibility, membership, non-revocation, nullifier correctness, and ballot well-formedness, and re-voting is supported with the latest ballot per nullifier counting. - Tallying is publicly verifiable: ballots are homomorphically summed, keys are generated via a publicly-auditable DKG with complaint resolution, trustees provide partial decryptions with DLEQ proofs, the contract checks consistency (counts vs distinct voters), and there is an explicit stated limit that passport-issuing authorities could mint fraudulent but valid identities. ELI5: This project is trying to make an online poll where each real person can vote only once, but nobody (not even the people running it) can see how any individual voted. It uses passports to prove you’re a real, unique human (without revealing your passport details), then uses encryption and “math proofs” to prove your vote is valid and counted correctly while keeping it secret. Everyone can later check the public data to recount the results, and each voter can check their own ballot was recorded.

New post on Eth Research! Lean verification of EIP-7002: system-call success and FIFO requests By: - skbaek 🔗 ethresear.ch/t/26180 Highlights: - A 504-byte predeploy contract at 0x00000961Ef480Eb55e80D19ad83579A64c007002 is system-called each block post-Prague per EIP-7002, and a failed call is consensus-critical (the block must be invalid). - Lean/Jaune proofs establish totality: given the canonical deployed runtime code (maintained over valid histories), the checked system transaction returns .ok regardless of storage contents and uses at most 210,000 gas out of the 210,000/30,000,000 budgeted regime described. - Lean/Jaune proofs also establish FIFO across execution histories: committed submissions equal (emitted withdrawal requests in order) ++ (the remaining live queue read from final storage), implying no loss, duplication, reordering, or early emission relative to submission. - The FIFO theorem relies on explicit history/config premises, including canonical deployment/activation sequencing, restrictions preventing transactions/code at the system caller address (0xff…fe), balance-bounds to avoid 2^256 overflow, and a large but finite cap (≤2^254) on committed submissions to prevent 256-bit wrap in the proof model; a machine-checked counterexample shows some premises (notably “no code at system address”) are necessary for the earlier theorem form. - The bytecode’s fee computation can differ from the EIP’s unbounded-integer spec due to 256-bit overflow; the author proves the bytecode fee never exceeds the EIP fee and characterizes when they coincide, and provides a synthetic (non-mainnet) machine-checked history demonstrating an under-EIP payment is possible in principle, so later theorems phrase guarantees in terms of the bytecode-computed fee. ELI5: Ethereum uses a tiny special contract to collect validator exit/withdrawal requests, and every block must call it successfully or the block is invalid. The author used the Lean proof assistant to mathematically prove that (1) this special end-of-block call can’t fail and won’t use too much gas, and (2) the contract behaves like a fair line (FIFO): requests come out in the exact order they went in, with none lost or duplicated, under clearly stated assumptions about the chain history and system address.

New post on Eth Research! ゼロ知識証明における疑問点とこれからのこと By: - batako-k 🔗 ethresear.ch/t/26178 Highlights: - 記事本文が削除されていて内容を参照できないため要約不能です。 - タイトルと著者名以外の情報がなく、重要点を抽出できません。 - 本文があれば、疑問点（何が難しい/誤解されやすいか）と今後の展望を5点に整理できます。 - 必要なら「ゼロ知識証明とは何か」をELI5で一般説明として補足できますが、記事要約ではなくなります。 - 記事本文（またはスクリーンショット/アーカイブ）を共有してもらえれば再度要約します。 ELI5: 元の記事本文が「(topic deleted by author)」となっており内容が確認できないため、要約や要点抽出ができません。本文（テキスト）を貼り付けていただければ、ゼロ知識証明に関する疑問点と今後の話題をわかりやすく整理して要約します。

New EIP! Batched KZG Point Evaluation via EIP-2537 🔗 github.com/ethereum/EIPs/pul… Highlights: - It’s a contract-level batching technique (no protocol change) that replaces n calls to the EIP-4844 point-evaluation precompile with 2 calls to BLS12-381 G1 MSM and 1 pairing check using EIP-2537. - It folds many KZG opening claims into one pairing equation via a Fiat–Shamir random linear combination; an invalid batch passes only with negligible probability (~1/q). - It supports three practical shapes: (1) general case (distinct commitments and points), (2) many blobs opened at one shared point, and (3) one blob opened at many points; the shared-value shapes reduce MSM size and gas further. - Correctness requires strict input validation and binding: verify scalars < q, point byte lengths, and MUST recompute and check kzg_to_versioned_hash(commitment) == versioned hash (since bypassing 0x0A skips that internal check). - Gas savings kick in beyond small batch sizes; recommended fallback to the normal per-opening EIP-4844 precompile below crossover (≈5 openings for shared-point/one-blob shapes, ≈6 for general), with large-batch savings around ~50–70% in measurements. ELI5: Checking a blob proof usually means doing an expensive cryptographic “pairing” check for each proof. This EIP shows how a smart contract can mix many blob checks together using random weights, so it only needs one pairing check total (plus some cheaper math), making it much cheaper when you verify several blobs or several openings in one transaction.

New EIP! CALLSTATUS instruction 🔗 github.com/ethereum/EIPs/pul… Highlights: - Introduces a new opcode CALLSTATUS (tentatively 0xA5) costing 2 gas, which pushes a per-frame register describing the outcome of the most recent CALL/CALLCODE/DELEGATECALL/STATICCALL/CREATE/CREATE2 in that frame. - Status is a bit-coded value with practical outputs {0,1,2,4,5}: 0=success, 1=revert or not-started-with-gas-return, 2=exceptional halt or create collision (forwarded gas consumed), 4=success but a halt occurred somewhere below, 5=revert but a halt occurred somewhere below. - Tracks two per-frame pieces of state: call_status (last outcome) and halt_seen (whether any exceptional halt/collision has occurred in this frame’s call lineage); halt_seen propagates upward so proxies/wrappers can’t mask halts as clean reverts/successes. - Solves a common security/robustness problem: contracts can stop using fragile gas-arithmetic heuristics to distinguish “clean revert” from “out-of-gas/exceptional halt,” especially as gas schedules and multi-dimensional gas accounting change over time. - Backwards compatible: legacy call opcodes, their success flags, and returndatabuffer behavior are unchanged; CALLSTATUS reads a new register and previously-undefined opcode 0xA5 becomes defined (no stack pops, allowed in static context, normal stack-overflow behavior). ELI5: It adds a new EVM opcode, CALLSTATUS, that lets a contract ask “what happened to my most recent call/create?” Instead of guessing from leftover gas, it returns a small code saying whether the last call succeeded, reverted, or crashed (like out-of-gas/invalid opcode), and also whether a crash happened deeper down the call chain even if an intermediate contract hid it.

New post on Eth Research! A hash-only rollup: OP Stack L2 accounts as Lamport-style hash chains, no ECDSA inside the L2 By: - Hadamard 🔗 ethresear.ch/t/26172 Highlights: - This OP Stack L2 (chain ID 42069000, live since 2026-09-30) removes signatures from L2 transactions: ownership is proven by revealing successive preimages of a keccak-256 hash chain, making keccak preimage resistance the core cryptographic assumption inside L2. - Two custom EIP-2718 transaction types are introduced: a HashCommitTx (0x7C) and a HashRevealTx (0x7F); the reveal is authorized by checks that link the preimage to the last revealed hash, generate a per-tx nullifier, and require a matching prior commitment that binds the preimage to the transaction digest. - Commit–reveal is necessary to prevent front-running once a preimage becomes public; an initial design was vulnerable because unauthenticated commits could be overwritten, so the chain adopted a “first commit wins” rule with an expiry window and txpool/RPC measures to reduce exposure. - Accounts have finite “uses” (default depth 1000) and must renew the hash chain at the final step by including a new commitment in the last reveal; if renewal is missed the address becomes unusable, so wallets must manage state carefully and support resync. - The design is not fully trust-minimized: L1 boundaries still use ECDSA, there are no fault proofs (permissioned proposer/dispute game), the sequencer is centralized, 160-bit addresses reduce standalone address security, and stateful one-time secrets can cause user lockouts if wallet state desynchronizes. ELI5: Instead of signing transactions with a private key, each account has a secret “chain” of hashes, like a stack of one-time passwords. To spend, you reveal the next secret value in the chain, and the chain’s hash links prove you’re the owner. Because revealed secrets could be copied by others, the user first posts a hidden “commit” and then reveals the secret, so the reveal only works for that specific transaction. This makes the L2 rely mainly on the security of keccak-256 hashes rather than ECDSA signatures.

New EIP! RESERVOIR Opcode 🔗 github.com/ethereum/EIPs/pul… Highlights: - Adds a new EVM opcode RESERVOIR (0x4d) that pushes the remaining state-gas budget not included in GAS, costing 2 execution gas and usable even in STATIC contexts. - Under the EIP-8037 reservoir model, RESERVOIR returns the current frame’s state_gas_reservoir (the extra state-gas pool above TX_MAX_GAS_LIMIT) which is forwarded fully to child calls (not subject to 63/64). - Inside EIP-8141 frame transactions, RESERVOIR returns the frame’s state_gas_left (matching TXPARAM(TXPARAM_STATE_GAS_LEFT)), so the same contract/library code can work across both transaction models. - With GAS + RESERVOIR, contracts can measure true remaining budget and gas deltas across calls including state-gas charges/refills, fixing undercounting issues in metering systems like ERC-4337-style bundlers. - Backwards compatibility is limited to the usual new-opcode risk: 0x4d previously invalid would stop execution; after activation it becomes RESERVOIR, with no changes to existing gas accounting rules beyond adding this introspection tool. ELI5: Ethereum transactions can have two “gas wallets”: one for normal execution and another special one that pays for changing blockchain state (like writing storage). Today, contracts can only see the normal wallet using the GAS opcode, so they can’t tell how much state-changing budget is left or how much a sub-call spent from it. This EIP adds a new opcode, RESERVOIR, that lets contracts read that hidden state-gas wallet so they can measure total gas usage more accurately and detect when a callee burns state gas.

Weekly Roundup Paranoid EIP-8288: heterogeneous recursion with an authenticated class bank 🔗 ethresear.ch/t/26170 1 comment(s) this week Reveal optionality in encrypted mempools: how big is the sender’s free option, and a post-quantum way to remove it 🔗 ethresear.ch/t/26169 1 comment(s) this week SEACAST: fast, lean broadcast for Ethereum, with an executable spec and a formal model 🔗 ethresear.ch/t/26167 1 comment(s) this week Measuring priority fees, positions and transaction classification of Ethereum blocks, July 2025 to October 2026 🔗 ethresear.ch/t/26156 1 comment(s) this week BRO-AMM: A Bonded Reconciliation Oracle AMM as a Low-Risk DeFi Primitive 🔗 ethresear.ch/t/26138 1 comment(s) this week Faster, Aggregatable and Quantum Safe Privacy Pools 🔗 ethresear.ch/t/26163 1 comment(s) this week PQ anonymity for Stealth Address Protocol 🔗 ethresear.ch/t/26094 1 comment(s) this week

New post on Eth Research! Paranoid EIP-8288: heterogeneous recursion with an authenticated class bank By: - ignotusnemo 🔗 ethresear.ch/t/26170 Highlights: - EIP-8288’s recursive aggregation could benefit from “heterogeneous recursion,” where different approved proof sizes/relations are used depending on workload size instead of always using one biggest relation. - Parano1d implements heterogeneous recursion on mainnet using a finite, authenticated bank of verifier classes; each class fixes its own relation details (constraints, commitment parameters, transcript layout) but shares a common public accumulator layout. - The key challenge is deferred verification: replaying a parent proof creates a matrix-evaluation claim that must remain tracked even if later recursive steps use a different verifier class. - The solution maintains one accumulator “lane” per class; each step updates only the lane corresponding to the parent’s class by folding in the new deferred claim, while all other lanes are carried forward unchanged; terminal verification checks the tip claim plus all live lanes against authenticated matrices. - This approach adds overhead: accumulator state and terminal work grow with the number of supported classes, and each recursive relation must include capacity for the approved parent-verifier options; extending to EIP-8288-style merges would require a merge invariant for combining child banks and dependency sets, plus rules connecting program/ISA identity to permitted verifier classes. ELI5: Imagine stacking receipts to prove you did a bunch of steps correctly. Sometimes you want small receipts (cheap and quick) and sometimes big receipts (more detailed). This post describes a way to safely mix different receipt formats while stacking them, by keeping an authenticated “catalog” (bank) of allowed formats and a separate running tally for each format, so no check gets lost when you switch formats.

New post on Eth Research! Reveal optionality in encrypted mempools: how big is the sender’s free option, and a post-quantum way to remove it By: - arianaraghi 🔗 ethresear.ch/t/26169 Highlights: - The sender’s advantage from choosing whether/when to reveal in an encrypted mempool can be formalized as an ‘endogenous option’ (a Jensen-gap quantity), is strictly positive under a simple condition, and can be bounded; with example ETH volatility and an ~8s decision window it’s on the order of ~1 bp, and a modest fee can cap exercise probability. - “Forced opening” via time-lock decryption helps only if attackers don’t have much faster hardware than honest participants; the paper gives a constraint in terms of the attacker speedup factor γ, and with only one-slot waiting time the allowable γ is very low (below ~2), making hardware assumptions critical. - The LUCID/EIP-8184-style fee mechanism can fail to properly price the option when senders use many conditional commitments; with a simple selector+executor strategy, deterring abuse can require fees orders of magnitude higher (example: ~25 bp vs ~0.8 bp for a single commitment case). - Removing reveal optionality from senders can simply shift it to decryption/availability committees: a blocking or early-decrypt coalition (often as small as ≤⌈n/2⌉ depending on thresholds) can inherit the option unless penalties are high enough, and hybrid designs can still leave an ‘induced unavailability’ problem. - Blind Simultaneous Release (BSR) is proposed to eliminate the option pre-deadline by forcing early commitment to the executed set and using hash-chain time-lock masking (post-quantum): before the escrow deadline the endogenous option is provably zero; after the deadline, deviations are deterred when deposits/fees cover worst-case gains, though it relies on explicit assumptions about feasible hardware speedups and leaves several analyses (dispute game, equilibria, batching, etc.) open. ELI5: If you can send a transaction that stays hidden, you can wait a moment to see what happens (like price moves) and then decide whether to “open” (reveal) it or not. That’s like having a free ‘undo button’ that can make you money. This write-up measures how valuable that undo button is, shows why simple fee rules don’t always stop people from abusing it, explains that forcing reveal can just move the power to the decryption committee, and proposes a new method (BSR) where everyone must lock in their choices before any new useful information arrives—using only hash-based time-locks so it still works even if future quantum computers break today’s crypto assumptions.

New EIP! Decoupled Consensus 🔗 github.com/ethereum/EIPs/pul… Highlights: - Validators would send two different message types: head votes for the available chain and finality attestations for the finality gadget, with separate propagation and inclusion rules. - Fork choice for the available chain uses only recent head votes (with cutoffs) plus expiring lock mechanisms to protect recently confirmed blocks when participation drops or messages are missing. - Finality would move off epoch-coupled voting: the whole validator set participates in independently scheduled finality rounds, and blocks can be justified/finalized as soon as ≥2/3 stake attestations are included in blocks. - The two subsystems interact through a “frame” provided by the finality gadget that constrains which blocks the available chain may build on and vote for (viable tree/heads, fork-choice root, frontier height handling). - It requires a consensus-layer hard fork and leaves major parameters and analysis as TBD (committee selection/VRFs, timing/lock parameters, encoding/aggregation, incentives, slashing details, fork transition, and proving the targeted ~4× faster finality). ELI5: Today Ethereum uses the same kind of vote messages to both (1) pick which block is the “current head” and (2) decide when blocks are “final” and can’t be changed. This proposal splits those into two separate jobs: a smaller, fast group votes each slot to quickly pick and “confirm” the head (with safety locks if votes are missing), while the whole validator set votes in separate, independent rounds to finalize blocks much faster. Keeping these two voting systems separate is meant to make chain reorganizations harder and let finality happen sooner.

New post on Eth Research! SEACAST: fast, lean broadcast for Ethereum, with an executable spec and a formal model By: - cskiraly 🔗 ethresear.ch/t/26167 Highlights: - Ethereum’s broadcast problem is getting harder as objects grow (bigger execution payloads, DA data, possible future proofs and post-quantum signatures), and today’s gossip can be seconds late for home builders and wastes bandwidth with duplicates. - SEACAST combines segmented forwarding (send/forward chunks immediately), erasure coding (Reed–Solomon so no specific chunk is ‘the last one’), and availability sampling (nodes can request only required columns/rows/cells rather than full objects). - The protocol explicitly separates what a node wants (interest: full object vs custody columns vs samples) from what it must relay (duty) and from who it pushes vs merely announces to, avoiding ‘one topic per piece’ designs like many-column topics. - In simulations on identical network setups, SEACAST delivers faster and with fewer bytes than both today’s gossipsub and ECBroadcast’s RS mode; e.g., in an all-home 500-node network with 16 peers each, 99% reach for a 1 MiB payload is ~0.64s vs 0.97s (ECBroadcast) vs 4.5s (gossipsub), with much lower received bytes per node. - SEACAST is designed to be ‘elastic’ under thinner uplinks (delay tracks bandwidth without runaway duplication) and is unusually well-specified: it has an executable pseudocode spec plus a formal model (Quint/TLA+) that already found and helped fix multiple liveness gaps. ELI5: Ethereum nodes need to quickly share big “packages” of data with lots of other nodes. Today’s sharing is wasteful: nodes often wait until they have the whole package before forwarding it, and many nodes get multiple duplicate copies. SEACAST is a smarter way to share: it breaks data into small pieces, adds error-correcting coding so any enough pieces work, forwards pieces immediately, and lets nodes request only the pieces they actually need (sometimes just a sample). It also comes with a spec you can actually run like a program, plus a formal math model to find bugs in the rules.

New EIP! Jump and Call Tables for the EVM 🔗 github.com/ethereum/EIPs/pul… Highlights: - Introduces two new opcodes: JUMPV (0xBE) for multi-way jumps and CALLSUBV (0xBD) for multi-way subroutine calls, using a destination table embedded in code. - A table is encoded as 1 count byte followed by count+1 absolute 2-byte destinations; the popped “case” index selects an entry, and out-of-range cases select the last entry as the default. - Runtime safety checks: the table must be fully within code bounds; JUMPV destinations must be JUMPDEST or CALLDEST; CALLSUBV destinations must be CALLDEST and must also respect the 1024-item return stack limit. - For validated (“MAGIC”) code per EIP-8337, every reachable JUMPV/CALLSUBV must be immediately preceded by a PUSH of the table position; validation ensures all table destinations are valid and integrates them into the control-flow graph (no fallthrough for JUMPV). - Gas cost is proposed as HIGH (10) for both opcodes, intended to cover bounds checking plus a code read and destination validation, while keeping dispatch O(1) compared to chains of comparisons. ELI5: This proposal adds two new EVM instructions that let a contract pick one of many jump targets using a small “address list” (a table) stored inside the contract’s own bytecode. Instead of doing lots of comparisons and jumps (like a long if/else chain), the contract can look up the right destination in the table and jump or call it in one step, while still allowing “validated” EVM code to prove ahead of time that all possible destinations are safe.

New EIP! eth/73 - Recursive STARK Exchange 🔗 github.com/ethereum/EIPs/pul… Highlights: - Adds eth/73 networking support for exchanging block-level recursive STARK proofs required by EIP-8288 via two new messages: GetRecursiveStarks (0x14) and RecursiveStarks (0x15). - Extends post-activation block headers with two new 32-byte fields: recursive-stark-hash (keccak256 of the proof bytes) and block-deps-hash (hash of declared dependencies), which must be present after EIP-8288 activation and absent before. - Defines response semantics: each requested block hash maps to a returned proof byte string; RLP empty string (0x80) is used when proof data is unavailable, and also represents an intentionally empty proof for blocks without dependencies (disambiguated via the header hash). - Requires minimal wire-level validation: clients must keccak256 the received proof and compare to recursive-stark-hash in the corresponding header; full proof verification against block-deps-hash is left to EIP-8288 block validation rules. - Introduces operational safeguards: recommends a 2 MiB soft limit for RecursiveStarks responses and advises rate limiting to reduce amplification/DoS risks from large proof payloads and handling of legitimately pruned/unavailable data. ELI5: Some future Ethereum blocks will have a big “proof” file (a recursive STARK) that shows the block’s transactions are valid. The block header only contains a small fingerprint (hash) of that proof, not the proof itself. This proposal adds two new peer-to-peer network messages so nodes can ask other nodes for these proof files during syncing and then quickly check they got the right file by comparing its hash to the fingerprint in the header.

New EIP! Post-Quantum Validator Key Registry 🔗 github.com/ethereum/EIPs/pul… Highlights: - Adds a new on-chain registry in BeaconState (one entry per validator) to store dormant post-quantum public keys, keeping existing BLS-based duties unchanged in this fork. - Uses a specific hash-based signature scheme: two-layer leanXMSS over Keccak-256, with 2**32 total one-time leaf indices; signatures include the leaf index and must never reuse an index for different messages. - Introduces a new beacon-block operation (PQ key registration) that includes the public key, a mandatory leanXMSS proof of possession signed at leaf index 0, and an authorization that is either (a) the validator’s BLS signature (operator path, register-only) or (b) a withdrawal-address authorization (owner path, register or replace). - Adds an execution-layer request mechanism (EIP-7685 typed request + predeploy contract) allowing withdrawal addresses to authorize a specific PQPublicKeys root; authorizations are queued in state, can be replaced by newer ones, and expire after 256 epochs. - Provides a measurable readiness signal (sum of effective balances of active validators with registered keys) so the later fork that actually switches signatures can be scheduled based on observed adoption, and enables recovery if BLS becomes insecure before the switch. ELI5: Ethereum validators currently sign everything with BLS signatures, which a future powerful quantum computer could break. This proposal adds a new “address book” inside the beacon chain state where each validator can pre-register a quantum-resistant (hash-based) public key, along with proof they really own it. These keys aren’t used yet; they just sit there so Ethereum can later switch to them smoothly and safely once enough validators are ready.

New post on Eth Research! Faster, Aggregatable and Quantum Safe Privacy Pools By: - Pierre 🔗 ethresear.ch/t/26163 Highlights: - The work ports a Tornado Cash-like pool to Flock, a transparent hash-based binary-field SNARK intended to be plausibly post-quantum, using SHA-256 for both the Merkle tree and nullifier derivation. - A key performance trick is replacing one large circuit with 34 SHA-256 compressions by a single small “one-compression” circuit invoked 34 times and glued together, yielding large prover speedups (e.g., ~28× faster at Merkle depth 32: ~0.81 s down to ~28.6 ms). - Because Flock’s witness/commitment configuration has a large minimum size, prover time is nearly flat across a wide range of Merkle depths (depth increases don’t significantly increase proving time until very large depths). - Recursive aggregation is demonstrated: users locally prove withdrawals (~19.5 ms each, ~203.6 KiB proofs) while an aggregator folds many withdrawals into one proof with constant final size (~343.9 KiB) and roughly constant verification time (~46–64 ms), shifting cost to the aggregator (~0.68 s per withdrawal). - A “quantum recoverability” protocol is proposed: wallets derive note secrets (k,r) deterministically from a 256-bit seed (via truncated SHA-512), so after a future freeze (before a discrete-log break), users can withdraw through a post-quantum recovery verifier without enabling double-spends, while non-seed notes risk being stranded. ELI5: Tornado Cash-style privacy pools rely on math that a powerful future quantum computer could break. This article shows a version built with a different kind of proof system (Flock) that uses SHA-256 and can create withdrawal proofs very fast, and it also proposes a simple “backup plan”: if wallets create their secret note data from a single saved seed, then if quantum computers ever break the old math, users can still withdraw later using a new quantum-safe proof checker after the pool is frozen.