EIP-8288: Frame type for PQ sig and STARK aggregation

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.

1 Like

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.

2 Likes

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.