Aptos Proposes AIP-137 To Introduce Post-Quantum Signatures For Enhanced Security
In Brief
Aptos proposed AIP-137 to add optional post-quantum SLH-DSA signatures at the account level, addressing long-term quantum computing risks without affecting existing accounts.
Layer 1 blockchain Aptos has introduced the post-quantum signature upgrade AIP-137, designed to optionally enable account-level support for post-quantum digital signatures, addressing potential future risks from quantum computing.
The proposal does not affect existing accounts and intends to implement the hash-based signature scheme SLH-DSA, which is standardized under FIPS 205. AIP-137 suggests SLH-DSA-SHA2-128s2 as the initial post-quantum signature option for Aptos accounts, a scheme recently recognized by NIST as post-quantum secure, relying solely on the SHA2-256 hash function for both classical and quantum security.
It takes a conservative approach to prepare for the emergence of cryptographically relevant quantum computers (CRQCs), which could appear within the next five to fifty years. Its focus prioritizes security over efficiency, while keeping integration complexity low. SLH-DSA is considered ideal because it depends exclusively on hash functions, already trusted in the Aptos ecosystem, in contrast to more complex post-quantum schemes that require additional classical safeguards and increase implementation complexity.
If adopted, this upgrade would require full nodes, validators, indexers, wallets, and Aptos SDKs and CLI tools to support creating, managing, and verifying these new signatures. Conversely, rejecting the proposal could leave the ecosystem vulnerable to unforeseen technological threats, while approval allows governance to activate post-quantum accounts as needed, enabling users to migrate at their discretion.
Aptos Evaluates Post-Quantum Signature Options, Prioritizing Security
While alternative post-quantum signature schemes may offer smaller signature sizes and faster verification times, the SLH-DSA family standardized in FIPS-2052 is considered the most conservative from a security perspective, as it depends solely on the already-established security of SHA2-256. This makes it a reliable choice to guard against potential classical attacks on schemes that are assumed to be post-quantum secure, as seen in the past when candidate schemes like Rainbow, based on multivariate cryptography, were broken on standard hardware despite being NIST finalists. SLH-DSA is therefore appealing to blockchain users who prioritize maximum caution and wish to avoid relying on untested assumptions or aggressive parameter settings of more efficient but less established post-quantum schemes.
Looking ahead, Aptos could also consider supporting a scheme from the ML-DSA family (FIPS-2045), which offers roughly half the combined public key and signature size of SLH-DSA and faster verification times, outperforming Ed25519. However, its security relies on the module learning with errors (MLWE) problem, which is less conservative. Another option, Falcon, features a combined public key and signature size of approximately 1.5 KiB with verification speeds comparable to or faster than Ed25519. Its drawbacks include reliance on floating-point arithmetic, which increases implementation complexity, and security assumptions based on the hardness of SIS over NTRU lattices, making it a less conservative alternative.
Outlining Post-Quantum Signature Timeline With Preliminary Devnet Deployment Planned For Early Next Year
One scenario is that a CRQC does not emerge within the next five years, yet a significant number of Aptos users adopt the SLH-DSA scheme. This could temporarily reduce network efficiency, though the impact is manageable: more efficient post-quantum schemes can be introduced and gas costs for SLH-DSA adjusted to encourage user migration. Alternatively, if a CRQC appears sooner than anticipated, users will either already be using the post-quantum scheme or can transition quickly once the threat becomes evident. Overall, the proposal offers the potential benefit of safeguarding the network against technological surprises, with a relatively low risk of negatively affecting performance if faster post-quantum options are introduced promptly.
The suggested implementation includes adding support in the aptos-crypto crate, integrating feature-gated signature verification logic in the Aptos VM, updating the TypeScript SDK to derive keys from mnemonics, adjusting gas pricing, enabling CLI key management, providing indexer support, and publishing developer documentation. While there is no immediate urgency to deploy on main networks within the next year, a preliminary devnet deployment is targeted for early next year to allow testing and gradual adoption.
Disclaimer
In line with the Trust Project guidelines, please note that the information provided on this page is not intended to be and should not be interpreted as legal, tax, investment, financial, or any other form of advice. It is important to only invest what you can afford to lose and to seek independent financial advice if you have any doubts. For further information, we suggest referring to the terms and conditions as well as the help and support pages provided by the issuer or advertiser. MetaversePost is committed to accurate, unbiased reporting, but market conditions are subject to change without notice.
About The Author
Alisa, a dedicated journalist at the MPost, specializes in cryptocurrency, zero-knowledge proofs, investments, and the expansive realm of Web3. With a keen eye for emerging trends and technologies, she delivers comprehensive coverage to inform and engage readers in the ever-evolving landscape of digital finance.
More articles
Alisa, a dedicated journalist at the MPost, specializes in cryptocurrency, zero-knowledge proofs, investments, and the expansive realm of Web3. With a keen eye for emerging trends and technologies, she delivers comprehensive coverage to inform and engage readers in the ever-evolving landscape of digital finance.
