Adds a frame type for quantum-resistant Signature and STARK Aggregation
This supports signatures and STARKs (for privacy or for eg. L2s) in a post-quantum world in a highly gas-efficient way, by providing a way for transactions to declare them as “dependencies”, in a way that allows the mempool and the block builder to replace them with a recursive STARK proving that they all exist.
This is exactly the direction where a receipt/dependency layer becomes important.
Post-quantum signatures and STARKs are too heavy to treat as isolated per-transaction checks. The interesting layer is the verifiable record of what each transaction depends on, and how those dependencies can be aggregated, replay-protected, and audited later.
A concrete question about omission accountability:
If a builder receives a valid signature or STARK dependency but does not include it in the recursive aggregate, does the proposed frame provide any durable evidence that the dependency was received?
The aggregate can prove validity of the included dependencies, but it may not prove that all valid dependencies submitted to the builder were included.
Is this intentionally left to the mempool/builder protocol, or could the frame commit to a dependency identifier or receipt that enables later inclusion or omission checks?
I see the EIP is drafted around the SPHINCS signature scheme. Are lattice-based signatures being considered, and if not why is that?
We want to be minimalistic with dependencies, and have a strong preference to keep the base layer purely hash-based for that reason.
It also means we have to maintain less total infrastructure.
That makes sense.
So the clean boundary seems to be:
- the base frame stays minimal and hash-based;
- the aggregate proves validity of included dependencies;
- omission accountability, if needed, belongs to a surrounding mempool / builder / receipt layer.
A minimal approach would be a hash-only dependency receipt: commit to the submitted dependency identifier, submission context, timestamp/slot, and builder endpoint/session, without adding new signature dependencies to the base layer.
That would keep the EIP minimal while still allowing later inclusion / omission checks outside the core frame.
There’s a broader design principle here beyond the specific cryptography, and Vitalik’s reply gets at it directly: keep the base layer minimal, prefer hash-based dependencies, and avoid carrying more permanent infrastructure than necessary.
That looks a lot like classic narrow-waist architecture: keep one small, stable interface in the middle, and allow the systems around it to evolve independently.
commitment → specialised mechanism → proof → verification
Authentication will change. Privacy tech will change. Execution environments will change. The stable layer only needs enough information to bind those pieces together safely.
The important point is that complexity doesn’t disappear. It moves to layers where it can continue to be upgraded, replaced, audited, and improved without forcing every change into consensus-critical infrastructure.
I think the same discipline applies to coordination protocols. They should capture the durable facts what was proposed, who agreed, and under what conditions without absorbing every authentication or execution mechanism into the core.
ERC-8001 happens to follow that pattern by committing to payloads and conditions while leaving execution outside the core. But that’s really just one instance of the broader idea.
Keep the narrow waist small. Let everything around it keep evolving.
One boundary I would keep explicit in that narrow waist: a commitment to the set that was included is not automatically evidence that nothing valid was omitted.
The reusable pattern we just ran into elsewhere is that completeness is always relative to an enumerable admission domain. Without a committed admission set or sequence, a recursive proof can prove every included dependency is valid while saying nothing about dependencies the builder received and silently left out.
So I’d separate two claims:
inclusion validity — every dependency represented by the frame/proof is valid;
admission-relative completeness — every dependency that entered a committed, enumerable admission domain is accounted for.
The first fits naturally in the narrow waist. The second needs an explicit admission commitment outside or alongside it; otherwise “nothing was omitted” becomes a stronger claim than the frame can support.
That seems consistent with keeping the base layer hash-only: the core need not know why a dependency was admitted, only what committed domain later completeness claims are relative to.