who want to help me to try my custom blockchain?
i need more people for testing my custom blockchain
i need more people for testing my custom 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.
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.