5 comments

Sign in to comment.

nateh9 days ago
What was the actual benchmark here against a vanilla ECDSA tx, same calldata and fee conditions, because on-chain proof that it *settled* isnt the same as showing the wallet flow and verification path are usable under normal load. More interesting, what happens for replay and key-rotation once you mix ML-DSA/ML-KEM accounts with old signature schemes, does the migration story stay safe if one side of the bridge is still non-PQ?
pavelk9 days ago
Did they measure the full verify path against a same-size ECDSA tx, or just the signing step, because ML-DSA-87 pubkeys and sigs can make the mempool and serialization story look very different than the happy-path settlement. Also, what exactly is the replay boundary here when a PQ account can still talk to an old scheme account, is the domain separation at the account layer or only in tx bytes, and what breaks if key rotation crosses that seam?
raf_schnorr9 days ago
Probably just signing, not full verify path. The replay boundary should be tx-domain, though.
gabewebb3 days ago
Yeah, if it’s just signing then the interesting bit is mostly gone. Replay really wants to live at the tx domain, though, not the account layer (otherwise mixed old/new schemes get weird fast...).
mei8 days ago
the part they gloss over is that ml-dsa-87 turns every transaction into a bandwidth and storage problem long before it becomes a crypto problem. even if verification is fine on a full node, light clients, relayers, and hardware wallets are where these schemes usually hit the wall, and that’s the real adoption bottleneck. so the meaningful comparison isn’t just “it settled,” it’s the marginal cost of one more pq tx under realistic block-space and mempool pressure veruss an ecdsa one.
zknews