Ignotus Nemo proposed exploring multiple proof sizes for EIP-8288, a draft that combines transaction dependencies into a recursive proof and weighs generation costs against the workload imposed on Ethereum nodes.
In an Oct. 22 post on Ethereum Research, Nemo reported that Parano1d’s public mainnet runs recursive state-transition proofs in both small and large configurations. He describes a finite, authenticated bank of verifier classes, with each class tied to its own proof relation and cryptographic parameters.
EIP-8288 would have transactions list proof or signature dependencies, then have block builders combine the supplied proofs into one recursive STARK that checks them. The draft currently assumes one protocol-level verification key. Nemo’s proposal would let smaller dependency groups use a smaller proving relation; he presented that as an option to explore, not an adopted change.
The proposal addresses a trade-off in the draft. EIP-8288 says larger proofs may cost less to generate, while smaller proofs reduce the work for nodes processing the mempool. It discusses variable gas costs based on proof size or another workload measure instead of a fixed verification charge.
Nemo says greater flexibility adds overhead: more supported verifier classes enlarge the public accumulator state and increase the work required for final verification. His current design recurses through one parent proof at a time. Adapting it to EIP-8288 would require reconciling child banks while applying the dependency list’s deduplication and discard rules.
Several parts of the draft remain open: AGGREGATED_VK and DEPS_HASH are marked TBD, and LEANSTARK_SCHEME is reserved until get_deps_hash is defined for it. EconoTimes previously covered the draft’s unfinished key-verification details.
Nemo asks readers to assess the merge invariant, the cost of a finite class bank across different workloads, and how verifier classes should map to program identity. The post gives no scheduled decision date.
