Enhance the SmtLib to support configurable hashing algorithm

[jimthematrix]

This is useful in situations when the SMT construct is used without needing ZKPs, for instance when used by the notary based privacy token implementation in LFDT's Paladin project.

The goal is first of all making the current Poseidon hash the default, such that existing clients using the SmtLib.sol library does not need to change the source code at all after the dependency upgrade.

Via a standard interface IHasher, a new pluggable implementation can be added and configured on the SmtLib library.

An implementation of the IHasher interface for the keccak256 algorithm is also provided.

The unit tests are cross-checked with unit tests in this PR: iden3/js-merkletree#53

Discussion

Due to the need for backward compatibility, we need to make the Poseidon hashing the default. In practice, this means the SmtLib.sol preserves the dependencies on the Poseidon libraries. When I use the keccak hasher, even though I wouldn't have any use for the Poseidon libraries, I would still have to deploy them in order to use the SmtLib library.

This seems to be a rather big annoyance. So the question for discussion is whether it's worth building it a bit differently so that the Poseidon capabilities are NOT available by default. Such that when I use keccak, I don't need to bother with deploying the Poseidon libraries. On the other hand, this means the existing usage of the SmtLib library needs to be updated to explicitly configure the hashing to be Poseidon. But it's only one call to set the hasher:

  smtData.setHasher(new PoseidonHasher());

[Copilot]

Pull request overview

This PR enhances the SmtLib library to support configurable hashing algorithms while maintaining backward compatibility with the existing Poseidon hash implementation. The primary motivation is to enable use cases where ZKPs are not required, such as the notary-based privacy token implementation in LFDT's Paladin project.

Key Changes:

• Introduces an IHasher interface to enable pluggable hash implementations
• Implements a Keccak256-based hasher as an alternative to Poseidon
• Maintains Poseidon as the default hasher for backward compatibility
• Adds comprehensive test coverage for Keccak256 hasher with cross-verification against js-merkletree

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
contracts/interfaces/IHasher.sol	Defines the pluggable hasher interface with hash2 and hash3 functions
contracts/lib/hash/KeccakHasher.sol	Implements IHasher using Keccak256 for non-ZKP use cases
contracts/lib/SmtLib.sol	Adds hasher configurability with storage fields and conditional hashing logic
contracts/test-helpers/SmtLibKeccakTestWrapper.sol	Test wrapper that initializes SMT with Keccak256 hasher
helpers/DeployHelper.ts	Adds useKeccakHashing parameter to deploy the appropriate test wrapper
test/smtLib/smtLib.keccak.test.ts	Comprehensive test suite validating Keccak256 hasher behavior
package.json	Updates postinstall script to use npx for patch-package

Comments suppressed due to low confidence (1)

helpers/DeployHelper.ts:427

• When deploying the Keccak hasher variant (useKeccakHashing=true), the deployment still requires deploying the Poseidon libraries (lines 421-427) and linking them to SmtLib. This creates unnecessary deployment overhead and gas costs for users who only want to use Keccak hashing. The PR description acknowledges this as "a rather big annoyance" but this implementation preserves the problem rather than solving it. Consider creating a separate SmtLib variant without Poseidon dependencies for Keccak-only use cases.

    this.log("deploying poseidons...");
    const [poseidon2Elements, poseidon3Elements] = await deployPoseidons([2, 3]);

    const smtLib = await this.deploySmtLib(
      await poseidon2Elements.getAddress(),
      await poseidon3Elements.getAddress(),
    );

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.