Sha512 Syscall
- Idea
- Draft
- Review
- Accept
- Implement
- Active
Decision brief
Why this proposal matters
Introduce a sol_sha512 syscall with an identical interface to sol_sha256, producing SHA-512 hashes and outputting the 64-byte result.
Proposal at a glance
What changes
- Not all bytes in [bytes, bytes + bytes_len sizeof(SolBytes)) are readable.
- Not all bytes in each slice [bytes[i].addr, bytes[i].addr + bytes[i].len) are readable.
- Not all bytes in [result, result + 64) are writable.
Stakeholder map
Who is affected
Builders & client teams Medium impact
Programs gain access to SHA-512 hashing at syscall cost.
Action requirement unknownValidators & operators Impact unknown
No proposal-specific evidence was found for this group.
Action requirement unknownUsers & stakers Impact unknown
No proposal-specific evidence was found for this group.
Action requirement unknownGovernance & ecosystem Impact unknown
No proposal-specific evidence was found for this group.
Action requirement unknownExact source revision
Full proposal document
0616093b2952Summary
Introduce a sol_sha512 syscall with an identical interface to sol_sha256,
producing SHA-512 hashes and outputting the 64-byte result.
Motivation
SHA-512 is a core primitive of Ed25519 signature verification and is already present in both the Agave and Firedancer validator clients as an internal dependency. However, it is not currently exposed to on-chain programs as a syscall.
Exposing sol_sha512 directly enables programs to perform SHA-512 hashing
without resorting to an on-chain software implementation, which is both
expensive in compute units and unnecessary given the function already exists
in every validator.
New Terminology
N/A
Detailed Design
Syscall Signature
The syscall follows the same interface as sol_sha256, sol_keccak256,
and sol_blake3. See here for more details:
https://docs.rs/solana-sha256-hasher/3.1.0/src/solana_sha256_hasher/lib.rs.html#62-75
The syscall computes SHA-512 over the provided byte slices as if they were
a single contiguous input, writing the 64-byte digest to result.
The syscall aborts the virtual machine if any of these conditions are true:
- Not all bytes in
[bytes, bytes + bytes_len * sizeof(SolBytes))are readable. - Not all bytes in each slice
[bytes[i].addr, bytes[i].addr + bytes[i].len)are readable. - Not all bytes in
[result, result + 64)are writable. bytes_lenexceeds the configured maximum number of slices. The current default is 20,000, as perSVMTransactionExecutionBudget. See here: https://github.com/anza-xyz/agave/blob/289aa4ea46889a1535962b727c0656d4d25527dc/program-runtime/src/execution_budget.rs#L82
Compute Unit Usage
Compute costs follow the same model and parameters as sol_sha256.
See here for more details: https://github.com/anza-xyz/agave/blob/master/syscalls/src/lib.rs#L168-L169
Alternatives Considered
BPF Implementation
Programs can implement SHA-512 in BPF today, but at a higher CU cost. A single SHA-512 hash of a short message consumes thousands of CUs in software versus fewer than 100 via syscall.
Status Quo
Continue without exposing SHA-512. Programs requiring SHA-512 (e.g., for Ed25519-adjacent verification logic) remain unable to access a primitive that both validators already have linked.
Impact
Programs gain access to SHA-512 hashing at syscall cost.
Security Considerations
The security surface is identical to the existing hash syscalls. The same input validation and CU metering apply. SHA-512 itself is a well-studied, standardized hash function (FIPS 180-4).
Backwards Compatibility
This is an additive change gated behind a feature flag. Programs that do not
invoke sol_sha512 are unaffected. Existing syscalls are unchanged.
Evidence graph
Related proposals and rollout
One or more sources are unavailable.
Upstream review record
Upstream discussion & review
GitHub review is editorial context, not evidence of on-chain support, voting, or outcome.
PR #512 · merged SIMD-0512: Sha512 Syscall 21 comments and reviews · Apr 11, 2026Done
GitHub ↗Done
GitHub ↗✅ All approvals received! @deanmlittle, you can now merge this by commenting /merge. ✅ Status: Ready to merge
GitHub ↗/merge
GitHub ↗✅ Merge successful! deanmlittle(https://github.com/deanmlittle)'s PR has been merged.
GitHub ↗Would have priced this higher than SHA256 since it's more expensive on x86
GitHub ↗Would have priced this higher than SHA256 since it's more expensive on x86 If we're making this argument, it actually makes more sense to make SHA256 cheaper than the others rather than making SHA512 more expensive, as Sha256 is uniquely faster due to SHA extensions. Keccak and Blake are priced the same as SHA256 despite lacking intrinsic support, and SHA512 is faster than non-intrinsic SHA256 despite producing a larger hash.
GitHub ↗If we're making this argument, it actually makes more sense to make SHA256 cheaper than the others rather than making SHA512 more expensive, as Sha256 is uniquely faster due to SHA extensions. Keccak and Blake are priced the same as SHA256 despite lacking intrinsic support, and SHA512 is faster than non-intrinsic SHA256 despite producing a larger hash. Very good point, will look into this
GitHub ↗Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity. 1
Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity.SIMD
Deployment Status
Feature Gate not yet created
Exact source revision
Sources & integrity
- Proposal document pinned_commit_blob
0616093b2952ed6de52c4a27d66aadd11d48d4f9 - simd-document document · current · Sep 11, 2026
0616093b2952ed6de52c4a27d66aadd11d48d4f9
One or more sources are unavailable.
simd.watch community discussion · SIMD-0512
Powered by Giscus · Sign in with GitHub to comment
Community comments load when this section approaches the viewport.