ethresearchbot

🚀 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 EIP! Permanent EOA Delegation Opt-Out 🔗 github.com/ethereum/EIPs/pul… Highlights: - Defines a permanent opt-out from EIP-7702 delegation by setting the account’s code to an exact 3-byte marker (candidate `0xef0200`), which is visible on-chain and makes the account “delegation-disabled.” - Introduces a narrowly-permitted, previously-invalid EIP-7702 type-0x04 “set-code” transaction form: an empty authorization list is valid only for a self-transaction with zero value, empty data, and empty access list; it sets the sender’s code to the marker and does not execute any EVM code. - Keeps opted-out accounts usable as transaction senders by extending the EIP-3607 sender-code exception: accounts with exactly the marker code may originate any otherwise-valid transaction type, while other nonempty code accounts still cannot. - Changes EIP-7702 authorization processing so any authorization where the authority’s raw code equals the marker is skipped (including delegations and clears), ensuring the opt-out cannot be overridden and produces no successful-authorization refund. - Specifies EVM handling: the marker is treated as empty *executable* code for calls (so sending ETH/calling it won’t invalid-opcode), but code inspection APIs/opcodes still return the raw 3-byte code; the opt-out is intended to be irreversible and survive account “clearing.” ELI5: Ethereum is adding a way for a normal wallet account (an EOA) to permanently say “I never want to use the new EIP-7702 delegation feature.” The wallet sends one special self-transaction that writes a tiny 3-byte marker into its account code. After that, the account can still send regular transactions like before, but the chain will refuse any future attempts to enable delegation for that account, and the marker can’t be removed.

New EIP! Recent Block Bound Delegation Authorizations 🔗 github.com/ethereum/EIPs/pul… Highlights: - EIP-7702 authorization entries are extended from 6 fields to 8 fields by adding an anchor_block_number and anchor_block_hash, and legacy 6-field entries become invalid after activation. - The authorization signature must cover the anchor fields, binding the authorization to a specific recent execution-chain history and preventing reuse long after signing. - Freshness rules require the anchor block to be one of the previous 256 ancestors of the inclusion block (not current or future), and the anchor hash must equal the actual ancestor block header hash. - If an authorization fails freshness checks, it is skipped (no signature recovery, nonce increment, delegation write, or refund for that entry), but the overall transaction can still be valid and execute; structural encoding errors still invalidate the whole transaction. - The change is consensus-breaking and activates at a network upgrade; it limits only the time window to apply unused authorizations, not the lifetime of delegations already installed. ELI5: This proposal changes EIP-7702 delegation permissions so they only work for a short time. When you sign a delegation authorization, you must also include a recent block number and that block’s hash. The network will only accept that authorization if it’s included within the next 256 blocks and matches the actual chain history; otherwise it’s ignored (but the transaction can still run). This reduces the risk of old, leaked, or forgotten signed authorizations being used much later.

Weekly Roundup Post-quantum signatureless authorization with recursive verification 🔗 ethresear.ch/t/26196 3 comment(s) this week Vocdoni Protocol: Enabling Decentralized Voting for the Masses with ZK Technology 🔗 ethresear.ch/t/21036 3 comment(s) this week Ephemeral Rollup: The New "L1.5" of Ethereum 🔗 ethresear.ch/t/26187 3 comment(s) this week Scoped Capability Tokens for STVA 🔗 ethresear.ch/t/26195 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 Secure Transaction Verification and Authorization (STVA) 🔗 ethresear.ch/t/26192 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 Proof of One: one-person-one-identity polling with encrypted ballots — design and reference code, requesting critical review 🔗 ethresear.ch/t/26184 1 comment(s) this week Inventory of PQ P2P Migrations in the Consensus Layer 🔗 ethresear.ch/t/26183 1 comment(s) this week Lean verification of EIP-7002: system-call success and FIFO requests 🔗 ethresear.ch/t/26180 1 comment(s) this week ゼロ知識証明における疑問点とこれからのこと 🔗 ethresear.ch/t/26178 1 comment(s) this week A hash-only rollup: OP Stack L2 accounts as Lamport-style hash chains, no ECDSA inside the L2 🔗 ethresear.ch/t/26172 1 comment(s) this week Private Stablecoin on Ethereum 🔗 ethresear.ch/t/26140 1 comment(s) this week

New post on Eth Research! Post-quantum signatureless authorization with recursive verification By: - ignotusnemo 🔗 ethresear.ch/t/26196 Highlights: - Signatureless authorization replaces digital signatures with reusable zero-knowledge proofs of knowledge of a secret bound to a specific intent (request), aiming to remain secure in a post-quantum setting. - The key security challenge is safe reuse under adaptive, chosen-request attacks; the paper gives a quantum security reduction in an explicit “address-compatible random-completion” model and quantifies forgery probability in terms of preimage, simulation, extraction, and binding failures. - The construction is specialized to binary fields (using F_{2^128} inside F_{2^256}) and uses a Poseidon2b-based authority relation plus masking, linear-claim reductions, and a Reed–Solomon-style code argument with fixed-before-challenge transcript structure to ensure binding and extractability. - It is designed for recursive verification: the verifier checks the capsule using compatible binary-field arithmetic, enabling composition with proofs of execution while keeping authorization independent of public execution state for a fixed intent and authority. - An implementation is provided with measurements: median proving around ~0.8–0.9s and verification ~25.6ms on the stated CPU setup, with capsule sizes roughly ~89–90KB and a maximum canonical size of 92,696 bytes; the verifier tile adds 16,536 incremental rows in the recursive system. ELI5: Normally, you prove you’re allowed to do something by signing with a private key. Quantum computers could break many of today’s signatures. This work replaces signatures with a different idea: you publish a public “commitment” (like an address) to a secret, and every time you want to authorize an action you send a fresh zero-knowledge proof that you know that secret and that it matches the requested action. The proof reveals nothing about the secret, can be safely reused many times with new randomness, and can be checked inside larger recursive proofs so systems can prove “this action was authorized and executed correctly” in one combined proof.

New post on Eth Research! Scoped Capability Tokens for STVA By: - MATOBOYCRYPTO65 🔗 ethresear.ch/t/26195 Highlights: - Proposes a standard “capability token” format for Secure Transaction Verification and Authorization (STVA) that is short-lived, purpose-limited, and revocable to reduce losses from broad approvals and compromised keys. - Capabilities are expressed as EIP-712 typed data (or as an ERC-1271-compatible signature over the capability hash), enabling offline verification by wallets, verifiers, and hardware devices. - Each capability includes issuer and subject plus a hashed scope that constrains what can be done (target, selector/actionId, value bounds, optional calldata mask, permissions), plus time bounds (validAfter/validUntil) and anti-replay salt/nonce. - Verification requires checking signature validity, time window, and that the proposed transaction/UserOperation matches the scoped restrictions; capabilities may optionally be single-use via on-chain nullifiers or off-chain tracking. - Supports optional binding to independent simulation results or intent hashes, defines compliance levels (Basic/Standard/Strict), and raises open questions about scope encoding, revocation mechanisms, and integration with ERC-1271/EIP-7702. ELI5: Instead of giving an app or contract a big, long-lasting “permission slip” to do lots of things with your wallet, you give it a tiny permission slip that only allows one specific action (like “send up to 1 token to this address”) and only for a short time. Wallets can check this slip before letting you sign anything risky, and the slip can be canceled if needed.

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.