The chain stops verifying — it only checks that a proof exists
EIP-8288 (recursive STARK mempools, Vitalik's "Proof Singularity," aimed at the I-star fork) makes one move: Ethereum's execution stops verifying signatures and proofs and instead only checks that a proof exists that a statement holds — all the real verification is pushed into the mempool, where nodes aggregate every tick into one recursive STARK. A tx carries a dependency frame (claims like "hash M was signed by SPHINCS+ pubkey P"); the envelope carries the actual signature/STARK; mempool nodes recursively prove all of them and broadcast one STARK. On-chain you pay for one STARK (~100–300 kB) + 96 bytes per statement — not the signatures, not the verification. That single relocation unlocks quantum-safe signatures, cheap privacy, any new scheme without EVM changes, and private account abstraction.
Not a build — a read plus one two-sided rewrite. Read EIP-8288, then take a single concrete statement — e.g. "[tx sighash] verifies against the pubkey at sload(0)" — and write both halves it splits into: (1) the frame side, where the actual signature/STARK lives in a dependency frame off the execution path; and (2) the contract side, where today's require(verify(sig, pubkey, hash)) becomes require(frameAsserts(statement)) — the contract now does bookkeeping only. Then, to feel the bandwidth bound, sketch the mempool aggregation loop on paper: each tick (~500ms) gather new envelopes, drop expired, recursively STARK all dependencies, broadcast one STARK; note that outbound is one STARK per tick regardless of tx count. Source: eips.ethereum.org/EIPS/eip-8288 and the 'Proof Singularity' talk. It is an early draft targeting a future fork — confirm the numbers (STARK ~100–300 kB, 96 bytes/statement, gas figures) and the fork status against the EIP before citing.
Why
The whole idea is a relocation: move every cost that is not ledger bookkeeping off the core execution path and shard it through the mempool. Today, when a contract checks a signature or a ZK proof, three costs land on-chain: the gas to run the verification, the data (a SPHINCS+ post-quantum signature is ~3 kB, on-chain forever), and the politics — the EVM must natively support each scheme, so adding a new signature or proof algorithm is a governance fight. EIP-8288 removes all three by making execution check only "does a proof exist that statement X holds," while the actual signature/proof is verified in the mempool and aggregated into one recursive STARK.
The mechanism is a dependency frame plus tick-based aggregation. A transaction lists its claims in a frame; the envelope carries the real signature or STARK for each; mempool nodes run a loop — every ~500 ms, gather new envelopes, drop expired ones, recursively prove all dependencies into a single STARK, and broadcast it. The block builder is just another mempool node: it STARKs the subset it includes and puts that in the block. Bandwidth is bounded — one STARK (~100–300 kB) per node per tick, plus each tx broadcast once — which is the property that makes the whole thing scale.
Four unlocks fall out of the relocation, and one architectural decision hides inside it. (1) Quantum-safe signatures get cheap because the ~3 kB never goes on-chain. (2) Quantum-safe privacy drops from ~300k gas (or ~10M done quantum-safe) to low tens of thousands. (3) Any scheme — Falcon, ML-DSA, lattice/code/isogeny-based — is supported by wrapping it client-side in a STARK, no EVM change, ending the 'please support my algo' politics. (4) Private account abstraction: keep account logic private and in a private on-chain location, then change ownership of all your state — accounts, DeFi positions, privacy notes — in one transaction without revealing which objects. The hidden decision: recursive STARKs need a shared language (an ISA) to express statements, and the leading candidate is RISC-V — so adopting this de-facto makes Ethereum bless RISC-V as a canonical ISA, arguably a bigger long-term commitment than the mempool change itself.
Where it sits against the rest of the catalogue. It is the opposite-reason twin of the encrypted mempool: both make the mempool do more than relay, but encryption hides content (anti-MEV, and it leaks metadata — what-encryption-does-not-hide) while EIP-8288 moves verification off-path (cost + quantum-safety) and aggregates. The one honest question to carry away: this shifts trust and cost, it does not delete them — who runs the aggregating nodes, what is the liveness assumption if STARKs are late, and does 'a proof exists' downstream ever get trusted without also checking which statement it proved?
How it works
The relocation, in one table
Cost today (on-chain)
Under EIP-8288
Gas to verify a sig/proof
gone — execution checks only that a proof exists
The sig/proof data (~3 kB SPHINCS+)
not on-chain — inside the mempool STARK
EVM must natively support the scheme
no — wrap it client-side in a STARK
—
one STARK (~100–300 kB) + 96 bytes per statement
The flow
Tx carries a dependency frame: a list of claims ("hash M signed by SPHINCS+ pubkey P", "data D satisfies verification key V").
Envelope carries the real signature/STARK for each claim.
Mempool node loop (~500 ms tick): gather new envelopes → drop expired → recursively STARK all dependencies → broadcast one multi-tx envelope with that STARK.
Block builder = just another mempool node: STARKs the txs it includes, puts it in the block.
Contract flips: verify(sig, …) → check a frame asserts the statement. Bookkeeping only.
The four unlocks
Unlock
Why
Cheap quantum-safe signatures
the ~3 kB SPHINCS+ sig never touches the chain
Cheap quantum-safe privacy
~300k (or QS ~10M) gas → low tens of thousands
Any scheme, no EVM change
Falcon / ML-DSA / lattice / code / isogeny — wrap in a STARK
Private account abstraction
change ownership of all state in one tx, hiding which objects
The buried decision
Recursive STARKs need a shared ISA to express statements in — leading candidate RISC-V. Adopting EIP-8288 de-facto adopts RISC-V (or its chosen replacement) as a canonical Ethereum ISA.
Cross-refs: encrypted-mempool and what-encryption-does-not-hide (the other 'mempool does more than relay' redesign — hides content vs. moves verification off-path), pbs (the builder as 'just another mempool node' extends proposer-builder separation), merkle-vs-verkle (same 'The Verge / proofs replace on-chain work' lineage), l1-zkevm-optional-proofs (proofs as the settlement primitive), receipt-is-not-settlement and liquid-issuance-not-authorization (a proof that a statement holds is not a check of which statement — trust what it actually proved).
EIP-8288(재귀 STARK 멤풀, 비탈릭의 "증명 특이점", I-star 포크 겨냥)은 한 가지를 바꿉니다: 이더리움 실행이 서명·증명을 검증하지 않고, 어떤 주장이 성립한다는 증명이 존재하는지만 확인합니다 — 실제 검증은 전부 멤풀로 밀어 넣고, 노드가 매 틱마다 하나의 재귀 STARK로 집계합니다. tx는 의존성 프레임("해시 M이 SPHINCS+ 공개키 P로 서명됨" 같은 주장)을 싣고, 봉투가 실제 서명/STARK를 싣고, 멤풀 노드가 그것들을 재귀적으로 증명해 STARK 하나를 방송합니다. 온체인 비용은 STARK 하나(~100–300 kB) + 주장당 96바이트 — 서명도, 검증도 아닙니다. 이 한 번의 재배치가 양자내성 서명, 값싼 프라이버시, EVM 변경 없는 새 방식, 프라이빗 계정 추상화를 해금합니다.
구현이 아니라 정독 + 한 문장의 양면 재작성입니다. EIP-8288을 읽고, 구체적 주장 하나 — 예: "[tx sighash]가 sload(0)의 공개키로 검증됨" — 를 잡아 갈라지는 두 반쪽을 쓰세요: (1) 프레임 쪽 — 실제 서명/STARK가 실행 경로 밖 의존성 프레임에 존재; (2) 컨트랙트 쪽 — 오늘의 require(verify(sig, pubkey, hash))가 require(frameAsserts(statement))가 되고, 컨트랙트는 이제 장부 기록만. 그다음 대역폭 유계를 체감하려면 멤풀 집계 루프를 종이에 스케치: 매 틱(~500ms) 새 봉투 모으기, 만료 버리기, 모든 의존성을 재귀 STARK로, STARK 하나 방송; 아웃바운드는 tx 수와 무관하게 틱당 STARK 하나. 출처: eips.ethereum.org/EIPS/eip-8288 및 '증명 특이점' 강연. 미래 포크를 겨냥한 초기 초안 — 수치(STARK ~100–300 kB, 주장당 96바이트, 가스)와 포크 상태는 인용 전 EIP로 확인.
왜
전체 아이디어는 재배치입니다: 장부 기록이 아닌 모든 비용을 핵심 실행 경로 밖으로 옮겨 멤풀로 분할한다. 오늘 컨트랙트가 서명이나 ZK 증명을 검사하면 세 비용이 온체인에 떨어집니다: 검증 실행 가스, 데이터(SPHINCS+ 양자내성 서명은 ~3 kB, 영원히 온체인), 그리고 정치 — EVM이 각 방식을 네이티브 지원해야 해서 새 알고리즘 추가가 거버넌스 싸움. EIP-8288은 실행이 *"주장 X가 성립한다는 증명이 존재하나"*만 확인하게 해 셋을 다 없앱니다. 실제 서명/증명은 멤풀에서 검증되고 하나의 재귀 STARK로 집계됩니다.
메커니즘은 의존성 프레임 + 틱 기반 집계. 트랜잭션은 주장을 프레임에 나열하고, 봉투가 각각의 실제 서명/STARK를 싣고, 멤풀 노드가 루프를 돕니다 — ~500ms마다 새 봉투 모으기, 만료 버리기, 모든 의존성을 하나의 STARK로 재귀 증명, 방송. 블록 빌더는 그냥 또 하나의 멤풀 노드: 포함할 부분집합을 STARK로 만들어 블록에 넣음. 대역폭이 유계 — 노드당 틱당 STARK 하나 + 각 tx 한 번 방송 — 이 성질이 전체를 확장 가능하게 합니다.
재배치에서 네 해금이 떨어지고, 그 안에 건축적 결정 하나가 숨습니다. (1) 양자내성 서명이 싸짐 — ~3 kB가 온체인에 안 감. (2) 양자내성 프라이버시가 ~30만 가스(양자내성으론 ~1000만)에서 수만 대로. (3) 모든 방식 — Falcon, ML-DSA, 격자/코드/아이소제니 — 을 클라이언트에서 STARK로 감싸 지원, EVM 변경 없음, '내 알고리즘 지원해줘' 정치 종료. (4) 프라이빗 계정 추상화: 계정 로직을 비공개 온체인 위치에 유지하고, 모든 상태 — 계정·DeFi 포지션·프라이버시 노트 — 의 소유권을 어느 객체인지 안 드러내고 한 tx로 변경. 숨은 결정: 재귀 STARK는 주장을 표현할 공유 언어(ISA)가 필요하고 유력 후보가 RISC-V — 그래서 이걸 채택하면 사실상 이더리움이 RISC-V를 표준 ISA로 축복하는 것, 멤풀 변경보다 어쩌면 더 큰 장기 약속.
카탈로그 안에서의 자리. 암호화 멤풀의 '반대 이유' 쌍둥이입니다: 둘 다 멤풀을 중계 이상으로 만들지만, 암호화는 내용을 숨기고(안티-MEV, 메타데이터를 흘림 — what-encryption-does-not-hide), EIP-8288은 검증을 경로 밖으로(비용+양자내성) 옮겨 집계합니다. 가져갈 정직한 질문 하나: 이건 신뢰와 비용을 옮기지 없애지 않는다 — 집계 노드는 누가 돌리나, STARK가 늦으면 liveness 가정은 무엇인가, 하류에서 '증명이 존재한다'가 어느 주장을 증명했는지 확인 없이 신뢰되는 일은 없나?
재귀 STARK는 주장을 표현할 공유 ISA가 필요 — 유력 후보 RISC-V. EIP-8288 채택은 사실상 RISC-V(또는 선택된 대체)를 표준 이더리움 ISA로 채택하는 것.
교차: encrypted-mempool·what-encryption-does-not-hide(다른 '멤풀이 중계 이상' 재설계 — 내용 숨김 vs 검증 경로 밖으로), pbs(빌더가 '그냥 또 하나의 멤풀 노드'로 제안자-빌더 분리 확장), merkle-vs-verkle(같은 'The Verge / 증명이 온체인 작업 대체' 계보), l1-zkevm-optional-proofs(정산 프리미티브로서의 증명), receipt-is-not-settlement·liquid-issuance-not-authorization(주장이 성립한다는 증명은 어느 주장인지의 검사가 아님 — 실제로 증명한 것을 신뢰하라).