Joined September 2023
- Tweets 1,129
- Following 2
- Followers 6,252
- Likes 2
Photos and videos
Pinned Tweet
4 Oct 2023
š 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.
23
33
182
59,574
Jun 12
Weekly Roundup
Building index-tracking assets on top of options instead of debt
š ethresear.ch/t/25036
4 comment(s) this week
Trustless payments and relays
š ethresear.ch/t/25125
3 comment(s) this week
Deterministic Governance Verification for Ethereum
š ethresear.ch/t/25116
3 comment(s) this week
The Origins of MEV: Systematic Attribution of Arbitrage Opportunity Creation at Scale
š ethresear.ch/t/25124
2 comment(s) this week
Extraction Is Conserved: From MEV to GEV
š ethresear.ch/t/24953
2 comment(s) this week
Governance Reconstruction as a Verification Primitive
š ethresear.ch/t/25149
2 comment(s) this week
Cooperative Capitalism Is the Last Coherent Economic Path Crypto Has Left
š ethresear.ch/t/25109
2 comment(s) this week
SPHINCS minus : Efficient Stateless Post-Quantum Signature Verification on the EVM
š ethresear.ch/t/25165
1 comment(s) this week
Three fixes, three new attacks: decaying vote weight in a weighted consensus
š ethresear.ch/t/25164
1 comment(s) this week
Ethereum Privacy: The Road to Self-Sovereignty
š ethresear.ch/t/22115
1 comment(s) this week
Closing the first precondition: batch auctions remove the ordering surface, they do not relocate it
š ethresear.ch/t/25160
1 comment(s) this week
Beyond AGI Control: Sovereign Collective Intelligence as Complementary Infrastructure
š ethresear.ch/t/25142
1 comment(s) this week
Hot-Cold Storage Separation in Practice
š ethresear.ch/t/25119
1 comment(s) this week
1
5
386
Jun 12
New post on EthResear.ch!
SPHINCS minus : Efficient Stateless Post-Quantum Signature Verification on the EVM
By:
- nicocsgy
š ethresear.ch/t/25165
Highlights:
- On-chain post-quantum signature verification can already be practical on Ethereum: the author reports Solidity verifiers around ~150K gas for a NIST-style limited-signature SLH-DSA parameter set, and as low as ~127K gas for an aggressively optimized non-standard variant (C13).
- The central optimization is aligning SPHINCS-style hashing with the EVM: swapping standard SPHINCS hash components (e.g., SHAKE256) for keccak256 enables efficient āpure EVMā verification without a precompile or protocol change (but sacrifices strict FIPS 205 compliance).
- Verifier cost is dominated by the number of hash evaluations, not just signature byte size; a calibrated model (ExecGas ā 36,118 194 * hash_ops) matched measured traces and showed that modeling real execution changes which parameters are best.
- Key parameter insights for minimizing EVM verification gas include choosing n=16 bytes (128-bit target), minimizing hypertree layers (d=2), and preferring w=8 (more chains but much shorter), plus using WOTS C/FORS C āgrindingā knobs (e.g., target digit sum S_wn) to shift work from verifiers to signers without reducing cryptographic security.
- There is an explicit trade-off triangle between on-chain gas, signature size, and signer burden/signature budget: the most gas-efficient variants can require heavy signing work (millions to billions of hash calls) and intentionally reduce per-key signature capacity (e.g., 2^14ā2^20) to match realistic wallet usage rather than SPHINCS ās 2^64 budget.
ELI5:
Todayās Ethereum accounts use a kind of āmath lockā (ECDSA) that a future quantum computer could pick. This article explores a new kind of āhash lockā signature (based on SPHINCS /SLH-DSA) that quantum computers shouldnāt break. The trick is making the check (verification) cheap enough to run inside Ethereum smart contracts: the EVM already has a fast built-in hash (keccak256), so the author designs SPHINCS variants that use EVM-native hashing and carefully chosen parameters so verifying a post-quantum signature costs a practical amount of gasāwithout needing new protocol features or special precompiled contracts.
10
403
Jun 12
New post on EthResear.ch!
Closing the first precondition: batch auctions remove the ordering surface, they do not relocate it
By:
- WGlynn
š ethresear.ch/t/25160
Highlights:
- Extraction is argued to be conserved across *preconditions* (root causes like ordering privilege), not merely across *channels/surfaces* (places it shows up like transaction ordering MEV or liquidation ordering).
- Seven observed extraction channels can be reduced to four underlying preconditions: ordering discretion, parameter discretion, mandatory intermediation, and allocation asymmetry.
- Common MEV mitigations (encrypted mempools, builder/solver auctions, private relays) may reduce visible MEV but do not remove ordering discretion; they tend to relocate value into builder profit, relay exclusivity, or other ordering-dependent surfaces.
- A commit-reveal batch auction with (1) deterministic intra-batch shuffling seeded by the XOR of all revealed secrets and (2) a uniform clearing price is presented as a way to *remove* ordering discretion rather than reassign/sell it.
- Even if ordering discretion is closed, total extraction (GEV) can persist by shifting to the other open preconditions; uniform clearing is necessary for closing ordering-based extraction but is explicitly insufficient to āclose the airgapā by itself.
ELI5:
Some crypto systems let someone choose the order that trades happen, and that person can profit by putting certain trades first (like cutting in line). Many āMEV fixesā just hide the line or sell the cutting-rights, but someone still controls the order, so the profit shows up somewhere else. The article says to stop the profit you must remove the underlying reason it exists (āpreconditionsā), not just patch the visible place it appears (āchannels/surfacesā). For ordering-based profit, the proposed fix is to bundle trades into batches, reveal them at the same time, shuffle execution with a seed no one controls, and give everyone the same clearing priceāso thereās no advantage to being first.
2
1
7
556
Jun 11
New EIP!
SETCODEFROM Code Reuse Instruction
š github.com/ethereum/EIPs/pulā¦
Highlights:
- Introduces a new opcode `SETCODEFROM(source)` that copies the *code hash* from an existing on-chain source account into the *current execution-environment account*, returning `1` on success and `0` if no change is made.
- Supports efficient āclone-likeā deployments: initcode can set per-instance storage, then adopt shared runtime code without paying code-deposit gas for identical bytecode; if initcode both adopts and returns nonempty code, creation fails.
- During normal (deployed) execution, the opcode can only change the executing accountās own code hash (not arbitrary other accounts), and the current frame keeps running old already-loaded code while later calls in the same transaction see the updated code (subject to reverts).
- Includes safety/validity constraints on the source: it must not be a precompile, must have non-empty code, and must be valid regular deployed code under the fork rules (e.g., cannot start with 0xEF, preventing use of EIP-3541/EIP-7702-style indicators).
- Defines gas as `3000 warm/cold account access` (ā5600 cold, 3100 warm under current EIP-2929 constants) and highlights a key security implication: after installing regular deployed code, ECDSA transaction origination from that address becomes invalid under EIP-3607 and EIP-7702 redelegation is blocked, enabling an account-migration path away from ECDSA-based authority.
ELI5:
This proposal adds a new EVM instruction, SETCODEFROM, that lets a contract set its own āprogramā (its code) to match the code of another already-deployed contract. That means you can create many contracts that share the same code without paying to store the same code over and over, while still letting each contract keep its own unique stored data. It can also help migrate accounts away from being controlled by normal ECDSA-signed transactions by installing wallet code so the account is controlled by its code instead.
1
6
825
Jun 11
New EIP!
Partitioned Binary Tree
š github.com/ethereum/EIPs/pulā¦
Highlights:
- Replaces Ethereumās hexary Merkle Patricia Trie structure with a unified binary state tree that stores account data, storage, and contract code in one 32-byte key/value space (no more ātree of triesā and no RLP encoding).
- Introduces āzonesā via the top 4 bits of each stem to create fixed structural boundaries: account headers (0x0), content-addressed overflow code (0x1), reserved future zones (0x2ā0x7), and storage (0x8ā0xF, i.e., high bit set). This makes subtrees for categories identifiable at known depths (e.g., storage split at depth 1).
- Co-locates frequently accessed per-account data in a single stem subtree of 256 leaves: packed basic account fields code hash the first 64 storage slots the first 128 code chunks, reducing the number of Merkle branch openings (and witness size) for common access patterns.
- Adds content-addressed deduplication for large contract code: code chunks ā„128 are keyed by (zone=0x1, code_hash, tree_index) rather than by account, so many contracts with identical bytecode share the same stored leaves and witnesses (with corresponding changes required to access-event accounting).
- Optimizes proof size and proving friendliness: binary arity minimizes witness/branch size, removes extension nodes and complex encodings, and leaves the hash function open (reference uses BLAKE3 for experimentation; candidates include Keccak and Poseidon2) with an eye toward efficient validity proofs and post-quantum-resilient assumptions.
ELI5:
Ethereum keeps a huge ābookā (the state) of who owns what, contract storage, and contract code. Today that book is organized in a complicated tree thatās hard to make short, efficient proofs for. This EIP proposes reorganizing the book into a simpler binary (two-branch) tree and splitting it into labeled sections (āzonesā) so everyone knows where accounts, storage, and code live. It also stores contract code in fixed-size pieces and lets identical code be shared so it isnāt duplicated thousands of times. The goal is smaller proofs, easier zero-knowledge/validity proof generation, and cleaner foundations for future features like state expiry and partial stateless clients.
1
13
673
Jun 11
New EIP!
WYRIWE ā What You Read Is What You Execute
š github.com/ethereum/EIPs/pulā¦
Highlights:
- Closes a key trust gap for on-chain AI: existing agent/model/output attestations donāt prove the userās intended input is what the model actually received; WYRIWE standardizes input provenance commitments.
- Defines a triple-hash chain of custody: raw_input_hash (original bytes), sanitization_pipeline_hash (binds a content-addressed sanitization spec CID to that raw input), and input_hash (the sanitized bytes fed to the model). Two hashes are not enough because they donāt commit to which transformation was applied.
- Uses IPFS CIDs for sanitization specs to prevent post-hoc swapping of transformation rules; verifiers can independently fetch the spec and reproduce the sanitization to confirm input_hash, assuming the CID remains retrievable/pinned.
- Standardizes an EIP-712 signed WyriweAttestation (agentId/registry, modelHash, the three input hashes, outputHash, timestamp) with a fixed type string and domain (name "ERC8004AttestationGateway", version "1", chainId=block.chainid) to enable on-chain verification and cross-chain replay protection.
- Makes the āno sanitizationā case explicit and verifiable via an identity sentinel CID: even when nothing changes, implementations must commit a sanitization_pipeline_hash derived from the sentinel CID and prove input_hash == raw_input_hash, avoiding ambiguous null/omitted fields.
ELI5:
When you ask an AI agent to do something, it might āclean upā (sanitize) what you wrote before sending it to the model. That can be helpful (remove dangerous parts) or harmful (silently change your request). This EIP makes the agent leave a tamper-evident breadcrumb trail using three fingerprints (hashes): one for what you originally wrote, one that points to the public ācleanup rulebookā used, and one for the final cleaned text actually fed to the model. The agent then signs an official receipt (EIP-712 attestation) that includes these fingerprints plus the model and output fingerprints, so anyone can later verify the AI ran on the intended input and applied the declared cleanup rulesāwithout having to trust the agent or its server.
4
17
972
Jun 11
New post on EthResear.ch!
Governance Reconstruction as a Verification Primitive
By:
- chegecjay-rgb
š ethresear.ch/t/25149
Highlights:
- Transparency (public execution data) is not sufficient for understanding: there is an āobservability gap,ā plus specific gaps from event-only visibility and hard-to-see authority/permission structures.
- Governance conclusions sit above raw artifacts (transactions/events/traces) and therefore require a structured reconstruction process that preserves traceability from evidence to conclusion.
- The Ethereum Transparency Layer (ETL) is presented as a reconstruction architecture with a dependency chain: Declared Structure ā Observed Execution ā Normalized Execution ā Relationship Reconstruction ā Execution Meaning ā Consistency Evaluation.
- Verification is framed as a parallel chain of evidence transformations: Declaration-to-Execution (does behavior reflect the declared system?) ā Execution-to-Meaning (derive behavior from evidence) ā Meaning-to-Verification (answer governance questions) ā Replay Equivalence (independent reproducibility).
- If reconstruction is deterministic and replay-equivalent, governance reconstruction becomes a āverification primitiveā: a foundational, reproducible method for externally auditable governance evaluation using only public information (not privileged access).
ELI5:
Ethereum shows everyone lots of receipts (transactions, events, state changes), but receipts alone donāt explain the full story of what happened or who had power to do what. This paper proposes a step-by-step ārecipeā to turn public blockchain data plus publicly declared system info (like contracts and docs) into the same understandable story every time. The steps: (1) write down what the system claims it is (declared structure), (2) collect what actually happened on-chain (observed execution), (3) clean/standardize it (normalized execution), (4) connect the dots between actions (relationship reconstruction), (5) interpret what it means (execution meaning), and (6) check if it matches what was declared (consistency). If two people follow the same recipe on the same data, they should get the same governance conclusionāthis repeatability is called replay equivalence.
3
17
964
Jun 10
New post on EthResear.ch!
Beyond AGI Control: Sovereign Collective Intelligence as Complementary Infrastructure
By:
- Dede-Qorqud
š ethresear.ch/t/25142
Highlights:
- Russellās preference-learning approach and Aschenbrennerās state-control approach both share a key gap: they assume human preferences can be reliably observed and managed from the top down.
- BeTrueCore proposes a new layer of infrastructure for āsovereign collective intelligence,ā where citizens can continuously and verifiably express collective will rather than relying on AI labs, corporations, or states to interpret it.
- The design emphasizes low energy and decentralization by doing biometrics locally on-device, generating zero-knowledge proofs client-side, and storing proofs cheaply via data-availability layers (e.g., Celestia).
- It targets āpreference authenticityā by using MACI plus ZK-SNARKs to reduce preference falsification (people lying about what they believe due to social pressure), which undermines both AI alignment schemes and democratic legitimacy.
- It reframes AIās role from decision-maker to verifier: AI should act as a notary that records and checks collectively expressed human intent, enabling bottom-up sovereignty rather than top-down control.
ELI5:
People worry that super-smart AI could do things humans donāt want. Some experts say we should make AI follow human preferences, and others say governments will have to control AI for safety. This article says both miss something important: we need a trustworthy way for regular people to clearly and safely show what they want. BeTrueCore is a proposed system that lets people vote/express preferences privately (so no one can bully them), prove theyāre real humans, and combine everyoneās input into a shared ācollective willā that AI can readāso AI acts more like a record-keeper of what people decided, not the boss.
9
670
Jun 10
New EIP!
Fixed-Cutoff State Tiering
š github.com/ethereum/EIPs/pulā¦
Highlights:
- Defines a one-time, socially chosen `CUTOFF_BLOCK`: any account or storage slot with EIP-8188 `last_written_block < CUTOFF_BLOCK` is Inactive; otherwise it is Active.
- Writes (mutations) to existing Inactive accounts/slots pay extra gas (`INACTIVE_ACCOUNT_WRITE_SURCHARGE` / `INACTIVE_STORAGE_WRITE_SURCHARGE`) on top of todayās normal write costs; reads are unaffected.
- The surcharge is assessed based on the tier at the start of the operation (before EIP-8188 updates `last_written_block`), so the first successful write āreactivatesā the item and future writes no longer pay the surcharge (unless a revert undoes the write).
- Clients must pre-check that enough gas exists to pay the normal write cost plus the maximum relevant surcharge before loading potentially Inactive state, preventing attackers from forcing unpaid expensive loads that would OOG anyway.
- Inactive state remains in the state root (no eviction/expiry), enabling a recommended interoperable, self-verifying file format for the fixed Inactive setāmaking it practical for nodes to move cold state out of their hot DB, while acknowledging the key weakness: the Active set can only grow until a future fork advances `CUTOFF_BLOCK`.
ELI5:
Ethereumās āstateā is like a huge notebook of accounts and smart-contract storage. Most pages were written long ago and rarely changed, but every node still has to keep them around. This EIP draws one agreed-upon line in time (a specific block number). Pages last written before that line are marked āInactive.ā If you try to change an Inactive page, you must pay an extra fee (a gas surcharge) because itās more work for nodes to dig it up and update it. Pages written after the line are āActiveā and cost the normal amount to change. Nothing is deleted; the old pages still exist and are still provable, but nodes can store the old, rarely-changed part in cheaper āarchive filesā instead of their fast database.
1
13
1,004
Jun 10
New EIP!
State Tiering by Periods
š github.com/ethereum/EIPs/pulā¦
Highlights:
- Introduces consensus-enforced ārenewal-ageā pricing: state writes cost more when the target account/storage slot hasnāt been written for a configured number of periods, using EIP-8188ās per-item `last_written_block` metadata.
- Defines a coarse āperiodā (bucketed block ranges) so tier changes happen only at period boundaries, making gas estimation more predictable than per-block aging while still reflecting long-term write inactivity.
- Only mutations of existing state are tiered (Active vs Inactive); reads are unchanged, and state creation is explicitly not tiered (creation pricing comes from EIP-8037 and must not be cheaper than the Inactive write tier).
- Tier is evaluated before the write occurs: writing an Inactive item pays the Inactive cost even though that same write updates `last_written_block` and makes subsequent writes cheaper (Active).
- Warm/cold access (EIP-2929) and access lists (EIP-2930) do not override renewal-age tiers: pre-warming can reduce transaction-local access overhead, but writes still pay the Active/Inactive write cost based on `last_written_block`.
ELI5:
Ethereum keeps a big shared database called āstate.ā Changing (writing) old, untouched parts of that database is usually harder for computers than changing parts that were changed recently, but today the network charges the same fee either way. This EIP says: split state into two bucketsārecently-written (Active) and not-written-for-a-long-time (Inactive)āusing a simple āperiodā counter based on block numbers. If you try to update something in the Inactive bucket, you pay more gas; if itās Active, you pay about what you pay today. Reading data stays the same price, and creating brand-new state is handled separately (and shouldnāt be cheaper than writing to Inactive state). The goal is to encourage people to āmaintainā the state they rely on, instead of leaving long-abandoned data that all node operators must keep forever.
3
7
612
New EIP!
Historical Ownership Extension for ERC-721
š github.com/ethereum/EIPs/pulā¦
Highlights:
- Introduces a 3-layer ownership model for ERC-721 NFTs: immutable original creator (Layer 1), append-only full ownership history (Layer 2), and standard current owner semantics (Layer 3).
- Makes ownership history composable on-chain: adds O(1) `hasEverOwned(tokenId, account)` and O(log n) `getOwnerAtBlock(tokenId, blockNumber)` so other contracts can natively use provenance for governance, airdrops, access control, and analytics.
- Requires history to be append-only and queryable with pagination helpers to avoid griefing/oversized responses; also deduplicates per-address āever ownedā token lists so they donāt grow repeatedly from back-and-forth transfers.
- Adds anti-history-pollution and manipulation guards: forbids self-transfers, recommends blocking multi-transfer-in-one-transaction chains (via EIP-1153 transient storage where available), and can enforce at most one ownership record per token per block to keep block-based owner resolution reliable.
- Preserves provenance through burns (recommended): burning clears only the current owner layer while keeping the original creator and historical trail available, trading higher storage persistence for permanent, trustless chain-of-custody data; comes with significant write-gas overhead vs vanilla ERC-721 (especially on mint/transfer).
ELI5:
Normally, an NFT only remembers who owns it right now. This proposal makes the NFT also remember (1) who created it, and (2) everyone who has ever owned it, in order, directly on-chain. That way, other smart contracts can ask questions like āDid this address ever own this NFT?ā or āWho owned it at block 1,234,567?ā without needing off-chain log indexers.
2
14
762
New EIP!
Counterfactual Rejection Event Log (CREL) Standard
š github.com/ethereum/EIPs/pulā¦
Highlights:
- Defines a canonical on-chain logging standard for rejected DEX trading candidates, enabling transparent measurement of filter performance that is currently hard or impossible with only accepted-trade logs.
- Introduces two required events: `RejectionLogged` at decision time (with candidateId, token, timestamp, rejectReason, and optional market cap/liquidity/metadata) and `OutcomeSampled` later to capture post-rejection market outcomes.
- Standardizes a minimal post-rejection outcome taxonomy (`gone`, `alive_dormant`, `alive_active`) to support counterfactual analysis and precision/save-to-miss style metrics from the PRFS methodology.
- Reserves reject reason codes 0ā15 for common observed filter rules (e.g., liquidity fail, downtrends, rug/anti-bot checks, concentration, sniper/bundle patterns) while allowing protocols to extend with codes 16ā255.
- Recommends emitting at least one outcome sample within 24 hours (with suggested cadences like 5m, 15m, 1h, 4h, 24h), and notes the tradeoff that public logs reveal some filter informationāprotocols can limit disclosure by using categorical codes and avoiding sensitive metadata.
ELI5:
DEX trading bots and protocols look at lots of tokens and say ānoā to most of them, but they usually only record the āyesā trades. This proposal says: when a token is rejected, write a standard on-chain note explaining (in a coded way) why it was rejected, and then come back later a few times to record what happened to that token afterward (did it disappear, stay but be inactive, or stay active, and what were price/liquidity). That way, anyone can check if the rejection filters are actually good and compare filter quality across different protocols without special private data tools.
2
14
904
New post on EthResear.ch!
The Origins of MEV: Systematic Attribution of Arbitrage Opportunity Creation at Scale
By:
- Andrei Seoev
- Dmitry Belousov
- Anastasiia Smirnova
- Ksenia Kurinova
- Aleksei Smirnov
- Denis Fedyanin
- Yury Yanovich
š ethresear.ch/t/25124
Highlights:
- The paper formalizes the āMEV opportunity attributionā problem: for an executed atomic arbitrage transaction with profit Ī , compute how much of Ī is causally attributable to each prior candidate transaction (plus any profit attributable to the pre-block state).
- Deterministic EVM execution makes exact counterfactuals feasible: you can replay the chain and re-run an arbitrage after removing (or truncating before) specific candidate transactions to measure their marginal impact, rather than relying on statistical inference.
- Empirically, the āsingle-sourceā hypothesis holds strongly: 96.7% of atomic arbitrage opportunities are dominated by one source transaction (one transaction accounts for >70% of total positive Shapley value), with only 3.3% showing genuinely tied multi-source creation.
- Four attribution methods present clear speed/accuracy trade-offs at scale: simulation is the recommended primary method (high coverage, ~12.3 ms/event); coefficient-based attribution is a very fast screening heuristic (~0.8 ms/event) but less accurate; Shapley (often via Monte Carlo) serves as ground truth but is far slower (~2.1 s/event); bot-data provides partial, real-time external validation but limited coverage.
- MEV creation is highly concentrated and protocol-dependent: a small fraction of transactions create most opportunities; concentrated-liquidity AMMs dominate opportunity creation (e.g., Uniswap V3 58.0%, Algebra 29.6%, Uniswap V4 28.9% participation) despite Uniswap V2 having higher overall volume, and a new measurable efficiency metric shows ~1.6 successfully executed arbitrages per opportunity-creating transaction on average.
ELI5:
MEV (Maximal Extractable Value) is the money bots can make by quickly trading when prices on different exchanges/pools on the blockchain get out of sync. This paper asks a simple question: when a bot makes profit from an arbitrage trade, which earlier transaction caused the price mismatch that made the profit possible? Because blockchains are deterministic, the authors can āreplayā history and also replay it with certain transactions removed to see what would have happened. They test several ways to assign credit/blame for creating arbitrage opportunities (fast heuristics, full simulations, and a āfair splitā method called Shapley values). They find that almost always, one earlier transaction is mainly responsible for creating the opportunity, and that opportunity creation is concentrated in a small set of protocolsāespecially concentrated-liquidity AMMs like Uniswap V3.
5
25
1,000
New EIP!
Lean Consensus Aggregators
š github.com/ethereum/EIPs/pulā¦
Highlights:
- Lean consensus replaces BLS with post-quantum hash-based (XMSS-like) signatures that are ~1.17 KiB each and do not support cheap native aggregation, making naĆÆve per-signature inclusion infeasible at scale.
- Because lean consensus targets fast finality with short (e.g., 4-second) slots, the per-slot volume of attestations rises dramatically; aggregation must stay roughly constant-size and fast to propagate.
- Aggregation is achieved by producing a succinct proof (via leanVM) that many signatures are valid; measured aggregate proof sizes are roughly 127ā344 KiB with a target of ~256 KiB propagated in under ~1 second, largely independent of the number of attestations proven.
- Proof generation is computationally expensive, so the `L*` hard fork introduces an opt-in, permissionless aggregator role (separate from block production) to keep ordinary validators/proposers lightweight by making verification cheap while concentrating proving on capable hardware.
- Key open risks and unresolved design points include incentives (no explicit rewards/penalties yet), prover hardware centralization (potential GPUs/prover networks), and proof-system security margin (reported ~124-bit classical / ~62-bit quantum, slightly below NIST Level 1 targets), with mitigations centered on redundancy and keeping verification broadly decentralized.
ELI5:
Ethereum today can bundle lots of validator āvotesā together cheaply because their signatures can be merged into one small signature (BLS). In Lean Ethereum, validators use post-quantum hash-based signatures that are much bigger and canāt be merged that way. So instead, special computers called āaggregatorsā collect many votes and create one compact cryptographic proof that says āall these big signatures are valid.ā Everyone else can then check that one proof quickly, which helps Ethereum keep moving fast even with short slots and lots of votes every few seconds.
8
33
1,944
New EIP!
Multi-block access list warming
š github.com/ethereum/EIPs/pulā¦
Highlights:
- Introduces a new chain-derived structure, the Warm-Access Multiset (WAM), that keeps refcounts for accounts and (address, storage_key) pairs seen in Block Access Lists (BALs) over a sliding 256-block window; an item is warm if its count > 0.
- Meaningfully reduces repeated cold-access charges across blocks: empirical analysis cited shows ~14.1% median per-block gas savings at a 256-block horizon (vs ~18.4% estimated upper bound), with 256 blocks capturing ~76% of the recoverable savings.
- Efficient maintenance: per-block updates are O(|BAL_in| |BAL_out|) by incrementing items from the newest BAL and decrementing items aging out of the window, avoiding recomputing unions across many blocks.
- Adds a verifiable commitment: WAM is committed via a fixed-depth (256) binary Sparse Merkle Tree using SHA-256, and the resulting 32-byte `wam_root` is added to the block header; this enables uniform inclusion/non-inclusion proofs and is positioned as zkEVM-friendly (SHA-256 cheaper than Keccak in typical circuits).
- Backwards-compatible and forward-only: existing transactions become cheaper or unchanged (no new gas constants, no invalidations), at the cost of additional node state (~10 MB typical at W=256, worst-case bounded but much larger) and one extra header field; WAM is updated per-block and is unaffected by transaction reverts.
ELI5:
Ethereum charges extra ācoldā gas the first time a transaction touches an address or a storage slot, then itās āwarmā (cheaper) for the rest of that transaction. This EIP makes recently-used addresses/slots stay warm not just within one transaction, but across many blocks: if something was used in any of the last 256 blocks, it starts out warm in the next blockās transactions. To track that efficiently, the chain keeps a rolling counter set (a multiset) of recently-accessed items and commits it to the block header so others can verify whatās warm without downloading lots of history.
2
7
37
2,136
Weekly Roundup
Exploring the Design Space for a Post-Quantum Public Key Registry for Ethereum Validators
š ethresear.ch/t/25040
11 comment(s) this week
Building index-tracking assets on top of options instead of debt
š ethresear.ch/t/25036
11 comment(s) this week
EIP8287: Privacy-Native Fungible Token Standard (Draft)
š ethresear.ch/t/25089
8 comment(s) this week
Evidential Survivability: OCP and Ethereum's CROPS Direction
š ethresear.ch/t/25012
4 comment(s) this week
Ethereum Cryptography and AI slop
š ethresear.ch/t/25067
3 comment(s) this week
MACI and group bribe attacks
š ethresear.ch/t/12939
3 comment(s) this week
Physical integrity, attestation, and the state of permissionless TEEs
š ethresear.ch/t/24964
2 comment(s) this week
Trust minimized transaction simulation using state proofs
š ethresear.ch/t/23857
1 comment(s) this week
Vocdoni Protocol: Enabling Decentralized Voting for the Masses with ZK Technology
š ethresear.ch/t/21036
1 comment(s) this week
Maintaining Effective Blob Fee Markets During Network Scaling: Dual-Variable EIP-1559
š ethresear.ch/t/22846
1 comment(s) this week
Building towards Multi-Party Block Construction
š ethresear.ch/t/24975
1 comment(s) this week
Vitalik Buterin proposes that AI votes for us. We propose a cryptographic space where we vote ā and no one is watching
š ethresear.ch/t/25077
1 comment(s) this week
Mechanized Proofs for Atomic Cross-Domain State Synchronization
š ethresear.ch/t/25065
1 comment(s) this week
SI-RVP: off-chain bisection a single-instruction Groth16 proof for optimistic-rollup dispute resolution
š ethresear.ch/t/25005
1 comment(s) this week
Composition Note: ERC-8004 ERC-8263 OCP ā A reference guide for implementers building on the AI agent verification stack
š ethresear.ch/t/24995
1 comment(s) this week
6
3
22
2,077
New EIP!
AI Agent Identity and Threat Registry
š github.com/ethereum/EIPs/pulā¦
Highlights:
- Defines three composable ERC-style interfacesāIAgentIdentity (DID registry), IAgentReputation (authorized reputation/tier updates trust-score calculation), and IThreatRegistry (on-chain threat intel attack records)āso protocols can integrate only what they need.
- Standardizes an on-chain DID format (did:erc8259:<chainId>:<address>) and a portable reputation score in the range 0ā1000, designed to map cleanly to DeFi-style basis-point thresholds (e.g., require ā„700).
- Introduces verification tiers (NoneāPlatinum) with suggested requirements (social proof, KYC, staking, audits) and a reference trust-score formula that multiplies reputation by a tier-based multiplier (e.g., Platinum up to 3Ć).
- Enables cross-protocol threat intelligence via a deterministic bytes32 āthreat patternā hash (action type destination amount bucket), plus events/records for blocked attacksāoptimized for gas efficiency and interoperability.
- Highlights key security needs: strict oracle/verifier authorization (ideally multi-oracle consensus), sybil-resistance measures (stake/SBT/cooldowns), appeal mechanisms for false positives, and mitigations for mempool front-running (atomic pause record or commit-reveal).
ELI5:
This EIP proposes a shared āID card trust score bad-actor listā for AI bots (agents) that use Ethereum. Agents can register a standard decentralized ID, earn or lose a reputation score that other apps can read, and share fingerprints of suspicious behaviors so that if one app detects an attack, other apps can block similar attacks soonerāall using on-chain interfaces that can be queried quickly.
18
2
36
1,545
New EIP!
pERC20 - Privacy-Native Fungible Tokens
š github.com/ethereum/EIPs/pulā¦
Highlights:
- Not ERC-20 compatible by design: pERC20 removes public balance/allowance concepts (no balanceOf/approve/allowance/transferFrom) and replaces transfers with a ZK note-based interface (transfer(PrivacyCall)), because public balances would defeat the privacy goal.
- Privacy-native from issuance: tokens are always represented as encrypted ZK-UTXO notes (Orchard-style actions with Groth16 proofs); there is no āpublic-to-private shieldingā stepātransfers are noteānote and amounts/participants are private by default.
- Public, on-chain verifiable supply: totalSupply remains public and is updated only through controlled mint(amount, ...) and burn(amount, ...); transfers must conserve value (valueBalance == 0), enabling āno invisible inflationā while keeping balances private.
- Built-in compliance via frozen-root binding: every action commits to the contractās cmxFrozenRoot, and the ZK circuit must prove the spent note commitment is NOT in the blacklist SMT. Admin can update the root (setFrozenRoot) to freeze/unfreeze specific notes without revealing normal usersā balances.
- Security-critical invariants and checks: implementations must prevent double-spends with nullifiers and must range-check each public field (< Fr) to avoid nf Fr-style bypasses; the core bundle execution must not be publicly callable to prevent unaccounted supply changes; signature points must be curve/field validated and replay protection must bind chainId contract note data.
ELI5:
This EIP proposes a new kind of token standard for Ethereum where peopleās token amounts and who they pay are hidden by default. Instead of keeping a public ābalanceā per account like ERC-20, the token exists as many encrypted ānotesā (like digital cash bills) that can be spent with zero-knowledge proofs. Everyone can still see the total number of tokens that exist (totalSupply) so the issuer canāt secretly create extra tokens. It also adds an optional-but-built-in āfreeze listā mechanism: the token contract keeps a public fingerprint (root) of a blacklist, and the zero-knowledge proof must show you are not spending a frozen note.
31
65
335
113,430
New post on EthResear.ch!
pERC20: Privacy-Native Fungible Token Standard (Draft)
By:
- JiangXb-son
- _pERC20Labs
š ethresear.ch/t/25089
Highlights:
- Defines a new EVM token interface (IPERC20) for privacy-native fungible tokens that is intentionally not ERC-20 compatible: no public balanceOf, no approve/allowance, and no Transfer/Approval events.
- Implements privacy via an Orchard-style encrypted ZK-UTXO note model using Groth16 proofs: transfers are noteānote, reveal nullifiers to prevent double-spends, and use anchors (historical Merkle roots) for membership proofs.
- Maintains a public, on-chain verifiable totalSupply to prevent āinvisible inflation,ā while keeping holders, recipients, and transfer amounts private (mint/burn amounts are public).
- Builds compliance into the standard through a contract-maintained cmxFrozenRoot (a blacklist SMT root) that each action must bind to; the ZK circuit proves the spent note commitment is not blacklisted (non-membership).
- Specifies key safety invariants and implementation requirements: strict field-range checks for public inputs (< Fr) to avoid nullifier-set bypass, a non-public core bundle execution path to preserve supply accounting, capped bundle sizes for predictable gas, and signature/circuit consistency checks (binding sig spend-auth sig pub-hash compression).
ELI5:
This draft proposes a new kind of token for Ethereum where peopleās balances and transfers are hidden by default. Instead of keeping a public āhow many tokens does Alice have?ā number, tokens are stored as secret ānotesā (like sealed envelopes) that can be spent once. When you pay someone, you prove (with special math proofs) that you had enough and didnāt cheat, without revealing who paid whom or how much. Everyone can still see the total number of tokens that exist, and thereās also an optional āfreeze listā so certain identified notes can be blocked from being spent.
3
4
24
1,564
New EIP!
Builder Execution Requests
š github.com/ethereum/EIPs/pulā¦
Highlights:
- This EIP introduces two new predeployed EIP-7685 request contracts specifically for builders: one for builder deposits/top-ups (request type placeholder 0x03) and one for builder exits (placeholder 0x04), using the same ārequest busā pattern as EIP-7002 and EIP-7251.
- Separating builder requests from validator deposit/exit flows removes cross-actor coupling: the consensus layer can distinguish builder vs validator actions by request type rather than by inspecting withdrawal credential prefixes, and the same BLS pubkey can be both a validator and a builder.
- Builder deposits are rate-limited and spam-metered: each contract dequeues at most MAX_REQUESTS_PER_BLOCK (16) per block, and each request also pays an EIP-1559-style dynamic fee based on demand (excess/target), bounding consensus-layer proof-of-possession verification work and making spam costly.
- Builder exits gain a cold-key path: exits are authorized by the builderās execution_address (msg.sender recorded as source_address) rather than requiring a BLS-signed voluntary exit by the builderās hot key; accordingly, EIP-7732 is changed so builder exits no longer use the voluntary-exit operation.
- The fork transition is carefully handled: builders needed at fork time are still onboarded from builder-credentialed pending deposits during the upgrade, but after the fork, builder-credentialed deposits sent to the validator deposit route are intentionally inert/forfeited and new builder onboarding/top-ups must go through the new builder deposit request type.
ELI5:
Ethereum wants ābuildersā (special block-building participants from EIP-7732) to have their own simple inboxes on-chain for joining and leaving.
- Deposit inbox: You send at least 1 ETH plus a small fee, along with your builder public key and a signature proving you own it. The chain records this as a request for the consensus layer to process.
- Exit inbox: You pay a small fee and request to leave using your normal Ethereum address (a colder, safer key) instead of the builderās hot signing key.
- Every block, a special system action empties a limited number of requests from each inbox and commits them into the block so the consensus layer can process them.
- Fees rise when too many requests are made, like EIP-1559, to discourage spam.
3
8
757