How would you safely reduce the size of ML-DSA-87 public keys and signatures in a blockchain?

I'm currently experimenting with a blockchain that uses ML-DSA-87 as its default signature scheme instead of ECDSA.

One of the biggest trade-offs is transaction size.

A single transaction includes an ML-DSA-87 public key and signature, making each transaction several KiB larger than a traditional ECDSA-based blockchain.

I don't want to weaken security, and I'd prefer to avoid protocol changes that add significant complexity (such as maintaining a public key registry in the blockchain state).

So I'm curious:

- Are there any safe ways to reduce the effective size of ML-DSA-87 public keys or signatures?

- Are there any compression techniques that preserve security?

- Is transport-level compression (e.g. P2P message compression) generally preferred over compressing the cryptographic objects themselves?

- If you were designing a post-quantum blockchain today, how would you handle this trade-off?

From what I've read, ML-DSA signatures are already highly structured, so I suspect there isn't much room for lossless compression without changing the scheme itself.

I'd love to hear how others would approach this problem.

reddit.com
u/Ok_Alfalfa_7767 — 3 days ago

How would you safely reduce the size of ML-DSA-87 public keys and signatures in a blockchain?

I'm currently experimenting with a blockchain that uses ML-DSA-87 as its default signature scheme instead of ECDSA.

One of the biggest trade-offs is transaction size.

A single transaction includes an ML-DSA-87 public key and signature, making each transaction several KiB larger than a traditional ECDSA-based blockchain.

I don't want to weaken security, and I'd prefer to avoid protocol changes that add significant complexity (such as maintaining a public key registry in the blockchain state).

So I'm curious:

- Are there any safe ways to reduce the effective size of ML-DSA-87 public keys or signatures?

- Are there any compression techniques that preserve security?

- Is transport-level compression (e.g. P2P message compression) generally preferred over compressing the cryptographic objects themselves?

- If you were designing a post-quantum blockchain today, how would you handle this trade-off?

From what I've read, ML-DSA signatures are already highly structured, so I suspect there isn't much room for lossless compression without changing the scheme itself.

I'd love to hear how others would approach this problem.

reddit.com
u/Ok_Alfalfa_7767 — 4 days ago