New post-quantum signatures like Dilithium-5, while crucial for future security, are significantly larger than current ones, causing compatibility issues between different versions and increasing blockchain data storage.
Ever heard about the new post-quantum digital signatures? They're super important for the future security of blockchains, but there's a side to them many don't talk about: they're huge, and even similar ones aren't always compatible. What this means for you is that how blockchains work and store data will change, and future upgrades might be more complex than we imagine.
Imagine a single transaction signature on a blockchain reaching 4,595 bytes using CRYSTALS-Dilithium-5. That's massive compared to traditional Ed25519 signatures, which are only 64 bytes – a 65x increase! This huge size isn't for nothing; it's the price we pay for upgrading to a high level of security that can withstand future quantum computer attacks. However, it also means every transaction and block will consume significantly more space.
It doesn't stop there. When a signature is verified, the public key and the verification result are stored permanently on the chain, continuously adding to the stored data. This state growth isn't a free lunch; it comes with a cost.
What's even more surprising is that compatibility isn't guaranteed even between similar technologies. For example, the FIPS 204 (ML-DSA) standard, finalized in August 2024, belongs to the Dilithium family. Yet, ML-DSA-87 signatures are 4,627 bytes, different from Round-3 Dilithium-5's 4,595 bytes. These small differences mean an implementation speaking Dilithium-5 won't understand ML-DSA-87 'on the wire'. This isn't a simple parameter change.
Today, we're shipping Round-3 Dilithium-5, and migrating to ML-DSA-87 is a real challenge, explicitly mentioned in our whitepaper. Changing the signature layer after a blockchain launches requires renegotiating many fundamental rules, making it crucial to freeze this layer at genesis to avoid future problems.
Private keys are another challenge. A private key of 4,864 bytes doesn't fit the common assumptions most signer infrastructure was built around, which typically expects sizes like 32 bytes. Solutions include using local signers (like KMS-style systems), remote signing APIs, or multi-party computation (MPC) signing paths, with a core rule that AI components never see plaintext private keys. This highlights the complexity of integrating these future-proof technologies.
Imagine a single transaction signature on a blockchain reaching 4,595 bytes using CRYSTALS-Dilithium-5. That's massive compared to traditional Ed25519 signatures, which are only 64 bytes – a 65x increase! This huge size isn't for nothing; it's the price we pay for upgrading to a high level of security that can withstand future quantum computer attacks. However, it also means every transaction and block will consume significantly more space.
It doesn't stop there. When a signature is verified, the public key and the verification result are stored permanently on the chain, continuously adding to the stored data. This state growth isn't a free lunch; it comes with a cost.
What's even more surprising is that compatibility isn't guaranteed even between similar technologies. For example, the FIPS 204 (ML-DSA) standard, finalized in August 2024, belongs to the Dilithium family. Yet, ML-DSA-87 signatures are 4,627 bytes, different from Round-3 Dilithium-5's 4,595 bytes. These small differences mean an implementation speaking Dilithium-5 won't understand ML-DSA-87 'on the wire'. This isn't a simple parameter change.
Today, we're shipping Round-3 Dilithium-5, and migrating to ML-DSA-87 is a real challenge, explicitly mentioned in our whitepaper. Changing the signature layer after a blockchain launches requires renegotiating many fundamental rules, making it crucial to freeze this layer at genesis to avoid future problems.
Private keys are another challenge. A private key of 4,864 bytes doesn't fit the common assumptions most signer infrastructure was built around, which typically expects sizes like 32 bytes. Solutions include using local signers (like KMS-style systems), remote signing APIs, or multi-party computation (MPC) signing paths, with a core rule that AI components never see plaintext private keys. This highlights the complexity of integrating these future-proof technologies.
