Skip to content

hash!: Unify all hash types, introduce "offchain" feature#236

Merged
joncinque merged 10 commits intoanza-xyz:masterfrom
joncinque:unify-hash
Jul 22, 2025
Merged

hash!: Unify all hash types, introduce "offchain" feature#236
joncinque merged 10 commits intoanza-xyz:masterfrom
joncinque:unify-hash

Conversation

@joncinque
Copy link
Copy Markdown
Collaborator

Problem

There are many repeated Hash types in all of the different hasher crates, which brings in unnecessary dependencies and copied code.

Summary of changes

Unify all hashes under solana_hash::Hash, by re-exporting that type from keccak and blake3.

While doing this work, I also cleaned up the dependencies, which were unnecessarily bringing in the crate for the offchain implementation.

When integrating the SDK with Pinocchio, we'll have many situations in which Pinocchio doesn't want to have an offchain fallback implementation available, but that fallback is still used by other downstream users.

To satisfy both uses, this PR also introduces a general "offchain" crate feature. For example, Pubkey::find_program_address could use the offchain feature for deriving the address without using the syscall, which is useful for most offchain applications.

I could also split off the offchain feature in a different PR if that's clearer.

cc @kevinheavey in case you want to weigh in on this too

@joncinque joncinque requested a review from febo July 17, 2025 14:06
@joncinque joncinque added the breaking PR contains breaking changes label Jul 17, 2025
Comment thread blake3-hasher/src/lib.rs
Comment thread keccak-hasher/src/lib.rs
Comment thread sha256-hasher/src/lib.rs
#### Problem

There are many repeated `Hash` types in all of the different hasher
crates, which brings in unnecessary dependencies and copied code.

#### Summary of changes

Unify all hashes under `solana_hash::Hash`, by re-exporting that type
from keccak and blake3.

While doing this work, I also cleaned up the dependencies, which were
unnecessarily bringing in the crate for the offchain implementation.

When integrating the SDK with Pinocchio, we'll have many situations in
which Pinocchio doesn't want to have an offchain fallback implementation
available, but that fallback is still used by other downstream users.

To satisfy both uses, this PR also introduces a general `"offchain"` crate
feature.  For example, `Pubkey::find_program_address` could use the
offchain feature for deriving the address without using the syscall,
which is useful for most offchain applications.

I could also split off the offchain feature in a different PR if that's
clearer.
Comment thread keccak-hasher/src/lib.rs Outdated
Comment thread keccak-hasher/src/lib.rs Outdated
Comment thread blake3-hasher/src/lib.rs Outdated
Comment thread blake3-hasher/src/lib.rs
Comment thread sha256-hasher/src/lib.rs
Copy link
Copy Markdown
Contributor

@febo febo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes look great! I am not entirely sure on the name of the feature "offchain". I wonder if we will have crates that offer multiple features for "offchain" things, which means that a single feature won't fit all cases. At the same time, I can't come up with an alternative name, apart from using a name related to the functionality/crate being enabled by the feature.

@joncinque
Copy link
Copy Markdown
Collaborator Author

At the same time, I can't come up with an alternative name, apart from using a name related to the functionality/crate being enabled by the feature.

We can go with that too, as the crates have been since the breakup. I was thinking a common name would be better for downstream users, so they don't need to read through our source code.

On the flip-side, maybe that's not a big deal, since the compiler will tell you if you're trying to use something and it's not available due to a feature-gate, or our panic messages will tell that too.

So if you don't like it, I'll revert. I don't feel that strongly about it.

@joncinque joncinque requested a review from febo July 22, 2025 10:24
Comment thread blake3-hasher/src/lib.rs
}

#[cfg(test)]
#[cfg(feature = "blake3")]
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that the feature is enabled on the dev-dependencies, so we probably don't need this. I might have missed that on my first review. Not sure if the idea is to have this pattern, but it can get a bit verbose for crates that have many features.

Copy link
Copy Markdown
Contributor

@febo febo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! I think having a "named" feature works well, so it is indicative of the functionality being enabled.

@febo
Copy link
Copy Markdown
Contributor

febo commented Jul 22, 2025

At the same time, I can't come up with an alternative name, apart from using a name related to the functionality/crate being enabled by the feature.

We can go with that too, as the crates have been since the breakup. I was thinking a common name would be better for downstream users, so they don't need to read through our source code.

On the flip-side, maybe that's not a big deal, since the compiler will tell you if you're trying to use something and it's not available due to a feature-gate, or our panic messages will tell that too.

So if you don't like it, I'll revert. I don't feel that strongly about it.

Yeah, I had the new address crate (PR #243) in mind, since that one there could be a few things that you might enable for "offchain".

@joncinque joncinque merged commit ec56d76 into anza-xyz:master Jul 22, 2025
25 checks passed
@joncinque joncinque deleted the unify-hash branch July 22, 2025 21:00
febo pushed a commit to febo/solana-sdk that referenced this pull request Sep 21, 2025
* hash!: Unify all hash types, introduce "offchain" feature

#### Problem

There are many repeated `Hash` types in all of the different hasher
crates, which brings in unnecessary dependencies and copied code.

#### Summary of changes

Unify all hashes under `solana_hash::Hash`, by re-exporting that type
from keccak and blake3.

While doing this work, I also cleaned up the dependencies, which were
unnecessarily bringing in the crate for the offchain implementation.

When integrating the SDK with Pinocchio, we'll have many situations in
which Pinocchio doesn't want to have an offchain fallback implementation
available, but that fallback is still used by other downstream users.

To satisfy both uses, this PR also introduces a general `"offchain"` crate
feature.  For example, `Pubkey::find_program_address` could use the
offchain feature for deriving the address without using the syscall,
which is useful for most offchain applications.

I could also split off the offchain feature in a different PR if that's
clearer.

* Guard Hasher re-export with not(target_os = "solana")

* Fixup CI

* Properly use offchain feature

* Oops, missing semi-colon

* Enable offchain feature in offchain-message

* Fix doctests

* Improve panic message

* Require offchain feature for tests

* Revert feature names
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

breaking PR contains breaking changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants