add support for SLH-DSA-SHA2-128s TXN authenticators

[alinush]

Description

Builds on top of #18293 and adds support for the SLH-DSA-SHA2-128s as a secure post-quantum signature scheme for Aptos accounts.

This PR was split up nicely into 7 commits:

1. Modify AccountAuthenticator to support SLH-DSA-SHA2-128s
2. Add API, protobuf and indexer GRPC support
3. auto-generate API and protobuf files
4. feature-gate this scheme in the Aptos VM with feature flag 107
5. add e2e smoke test for TXN signatures (not) verifying when the feature is (not) enabled
6. add feature-gated 5x higher gas cost for such TXNs
7. add API tests with golden files, as per @zjma's suggestion

...but, after some fixes, now totals 12 commits.

• use Box for the large SLH-DSA signature inside SingleKeyAuthenticator

To run the smoke tests:

ulimit -n unlimited # no limit on # of open files; otherwise, RocksDB errors
cd testsuite/smoke-test/
cargo test -- slh_dsa_feature_enabled
cargo test -- slh_dsa_feature_disabled

How Has This Been Tested?

• End-to-end smoke tests in testsuite/smoke-test/src/slh_dsa.rs.
• API tests in api/src/tests/slh_dsa_sha2_128s.rs

Key Areas to Review

Feature flags & feature gating logic

New feature flag added in types/src/on_chain_config/aptos_features.rs and mirrored in Move in aptos-move/framework/move-stdlib/sources/configs/features.move.

Feature gating is done in aptos-move/aptos-vm/src/aptos_vm.rs.

Gas charging logic

Should ensure that feature gating was done right.

Was initially unsure what the semantics of charge_slh_dsa_sha2_128s and charge_keyless should be in the AptosGasMeter implementation for the GasProfiler. But talking to @vgao1996 cleared things up.

TXN signature bureaucracy

It's been a while since we implemented a new TXN authenticator, so I do not recall all of the bureaucratic code changes that must be done.

Perhaps that should be reviewed?

Although, it looks like we are good & nothing is missing, since the e2e smoke test is succeeding which means serialized signatures are flowing through the network.

For transparency, here's the sequence of steps I took:

1. I had to manually modify several files, as instructed in https://github.com/aptos-labs/aptos-core/tree/main/testsuite/generate-format#example and in https://github.com/aptos-labs/aptos-core/tree/main/api:

• api/types/src/transaction.rs
• crates/aptos-transaction-filters/src/transaction_filter.rs
• ecosystem/indexer-grpc/indexer-grpc-fullnode/src/convert.rs
• protos/proto/aptos/transaction/v1/transaction.proto
• testsuite/generate-format/src/api.rs
• testsuite/generate-format/src/aptos.rs
• testsuite/generate-format/src/consensus.rs

2. Then, I went to protos and ran ./scripts/install_deps.sh.

3. Then, I ran ./scripts/authenticator_regenerate.sh, which failed in protos/scripts/build_protos.sh because poetry wasn't working due to a missing dependency

4. So, I did a pip install --break-system-packages --user certifi (yolo)

5. Then, I re-tried ./scripts/authenticator_regenerate.sh, which now worked & did a lot of work:

• it re-generated api/doc/spec.{yaml,json} files
• it regenerated testsuite/generate-format/tests/staged/*.yaml files
• it re-generated a lot of files in protos/

Type of Change

• New feature
• Bug fix
• Breaking change
• Performance improvement
• Refactoring
• Dependency update
• Documentation update
• Tests

Which Components or Systems Does This Change Impact?

• Validator Node
• Full Node (API, Indexer, etc.)
• Move/Aptos Virtual Machine
• Aptos Framework
• Aptos CLI/SDK
• Developer Infrastructure
• Move Compiler
• Other (specify)

Checklist

• I have read and followed the CONTRIBUTING doc
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I identified and added all stakeholders and component owners affected by this change as reviewers
• I tested both happy and unhappy path of the functionality
• I have made corresponding changes to the documentation

---

Note

Enables a new post-quantum signature scheme across the stack, behind a feature flag, with dedicated gas charging and full API/Indexer support.

• Introduces slh_dsa__sha2_128s PublicKey/Signature variants and SlhDsa_Sha2_128s type; updates OpenAPI (spec.json/yaml) and protobufs (Rust/Python) and indexer gRPC conversions
• VM: adds feature flag SLH_DSA_SHA2_128S_SIGNATURE (107) gating; validates signatures, detects is_slh_dsa_sha2_128s in metadata; charges new gas via charge_slh_dsa_sha2_128s and includes it in intrinsic gas checks
• Gas: adds schedule param slh_dsa_sha2_128s.base, bumps gas feature version to V1_41; plumbs through meter traits, profiler, logs, flamegraph, and reports
• API/types: extends enums and conversions to/from AnyPublicKey/AnySignature, adds length checks; transaction filter updated
• Tests: new API tests and goldens for single/multi-key SLH-DSA, plus E2E paths; minor doc additions in Move stdlib features

^{Written by Cursor Bugbot for commit 8b09ec9. This will update automatically on new commits. Configure here.}

[zjma]

looks cool! (but I skipped folders ecosystem and protos...)

can we also have some API tests (though i'm not sure if there's a UT pattern to follow), or you have verified manually with a localnet?

[alinush]

looks cool! (but I skipped folders ecosystem and protos...)

can we also have some API tests (though i'm not sure if there's a UT pattern to follow), or you have verified manually with a localnet?

Not sure what an API test is... can you point me to one?

Also, don't the smoke tests act like an implicit API test?

[zjma]

looks cool! (but I skipped folders ecosystem and protos...)
can we also have some API tests (though i'm not sure if there's a UT pattern to follow), or you have verified manually with a localnet?

Not sure what an API test is... can you point me to one?

Also, don't the smoke tests act like an implicit API test?

the current smoke test verified it works but you probably want more (e.g., when some serialization format changes, something should fail)?

Something like the existing test case test_secp256k1_ecdsa in api/src/tests/secp256k1_ecdsa.rs (+ a golden file api/goldens/aptos_api__tests__secp256k1_ecdsa__test_secp256k1_ecdsa.json) would be enough, i think.

[zjma]

stamping for everything except changes in folders protos and ecosystem (which i'm not familiar with) :P

[JoshLind]

Looks great! 😄 Still needs expert eyes on the VM side (i.e., gas logic and feature gating). Likewise, on the ecosystem side (e.g., protos and indexer).

But, otherwise, LGTM.

[github-actions]

✅ Forge suite compat success on d49896be27f4c071cdaeb4a2e6ddc0ddd97a93c5 ==> 8b09ec9792389c717dd3643a8e8b7b7649361756

Compatibility test results for d49896be27f4c071cdaeb4a2e6ddc0ddd97a93c5 ==> 8b09ec9792389c717dd3643a8e8b7b7649361756 (PR)
1. Check liveness of validators at old version: d49896be27f4c071cdaeb4a2e6ddc0ddd97a93c5
compatibility::simple-validator-upgrade::liveness-check : committed: 13217.16 txn/s, latency: 2620.85 ms, (p50: 2700 ms, p70: 3000, p90: 3100 ms, p99: 3600 ms), latency samples: 435300
2. Upgrading first Validator to new version: 8b09ec9792389c717dd3643a8e8b7b7649361756
compatibility::simple-validator-upgrade::single-validator-upgrade : committed: 5859.61 txn/s, latency: 5731.62 ms, (p50: 6300 ms, p70: 6500, p90: 6600 ms, p99: 7100 ms), latency samples: 201360
3. Upgrading rest of first batch to new version: 8b09ec9792389c717dd3643a8e8b7b7649361756
compatibility::simple-validator-upgrade::half-validator-upgrade : committed: 5913.53 txn/s, latency: 5694.64 ms, (p50: 6300 ms, p70: 6400, p90: 6500 ms, p99: 6700 ms), latency samples: 203640
4. upgrading second batch to new version: 8b09ec9792389c717dd3643a8e8b7b7649361756
compatibility::simple-validator-upgrade::rest-validator-upgrade : committed: 9756.35 txn/s, latency: 3309.58 ms, (p50: 3300 ms, p70: 3800, p90: 4400 ms, p99: 5000 ms), latency samples: 326640
5. check swarm health
Compatibility test for d49896be27f4c071cdaeb4a2e6ddc0ddd97a93c5 ==> 8b09ec9792389c717dd3643a8e8b7b7649361756 passed
Test Ok

• Grafana dashboard
• Humio Logs
• Axiom Logs
• Validator CPU Profile
• Fullnode CPU Profile
• Test runner output
• Test run is land-blocking

[github-actions]

✅ Forge suite realistic_env_max_load success on 8b09ec9792389c717dd3643a8e8b7b7649361756

two traffics test: inner traffic : committed: 13620.15 txn/s, latency: 2766.01 ms, (p50: 2700 ms, p70: 2900, p90: 3000 ms, p99: 3600 ms), latency samples: 5067740
two traffics test : committed: 99.99 txn/s, latency: 816.92 ms, (p50: 800 ms, p70: 800, p90: 900 ms, p99: 2700 ms), latency samples: 1740
Latency breakdown for phase 0: ["MempoolToBlockCreation: max: 2.266, avg: 2.170", "ConsensusProposalToOrdered: max: 0.169, avg: 0.166", "ConsensusOrderedToCommit: max: 0.046, avg: 0.042", "ConsensusProposalToCommit: max: 0.214, avg: 0.208"]
Max non-epoch-change gap was: 1 rounds at version 33760 (avg 0.00) [limit 4], 1.17s no progress at version 40682 (avg 0.07s) [limit 15].
Max epoch-change gap was: 0 rounds at version 0 (avg 0.00) [limit 4], 0.73s no progress at version 2344447 (avg 0.73s) [limit 16].
Test Ok

• Grafana dashboard
• Humio Logs
• Axiom Logs
• Validator CPU Profile
• Fullnode CPU Profile
• Test runner output
• Test run is land-blocking

[github-actions]

✅ Forge suite framework_upgrade success on d49896be27f4c071cdaeb4a2e6ddc0ddd97a93c5 ==> 8b09ec9792389c717dd3643a8e8b7b7649361756

Compatibility test results for d49896be27f4c071cdaeb4a2e6ddc0ddd97a93c5 ==> 8b09ec9792389c717dd3643a8e8b7b7649361756 (PR)
Upgrade the nodes to version: 8b09ec9792389c717dd3643a8e8b7b7649361756
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 2179.46 txn/s, submitted: 2186.29 txn/s, failed submission: 6.83 txn/s, expired: 6.83 txn/s, latency: 1329.92 ms, (p50: 1200 ms, p70: 1500, p90: 1800 ms, p99: 2700 ms), latency samples: 197740
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 2231.54 txn/s, submitted: 2238.18 txn/s, failed submission: 6.63 txn/s, expired: 6.63 txn/s, latency: 1328.86 ms, (p50: 1200 ms, p70: 1500, p90: 1800 ms, p99: 2700 ms), latency samples: 201940
5. check swarm health
Compatibility test for d49896be27f4c071cdaeb4a2e6ddc0ddd97a93c5 ==> 8b09ec9792389c717dd3643a8e8b7b7649361756 passed
Upgrade the remaining nodes to version: 8b09ec9792389c717dd3643a8e8b7b7649361756
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1544.99 txn/s, submitted: 1550.03 txn/s, failed submission: 5.04 txn/s, expired: 5.04 txn/s, latency: 1901.52 ms, (p50: 1200 ms, p70: 1300, p90: 1500 ms, p99: 11800 ms), latency samples: 141040
Test Ok

• Grafana dashboard
• Humio Logs
• Axiom Logs
• Validator CPU Profile
• Fullnode CPU Profile
• Test runner output
• Test run is land-blocking