The Hydra-S2 ZK proving scheme is the second proving scheme in the Hydra family:
The proving scheme expands on the Hydra-S1 proving scheme and introduces the notion of a Vault Identifier while offering a modular way of creating ZK proofs.

VaultId & Proof Identifiers

VaultId is a new notion introduced with Hydra-S2; it is an anonymous app-specific identifier that can be utilized as an in-app user ID.
This VaultId is deterministically generated from a vaultSecret and an application Identifier (appId) by taking the Poseidon hash of these two values.
A Proof Identifier can be seen as the nullifier used in Hydra-S1, as far as it is deterministically generated from the Poseidon hash of a hashed sourceSecret and a requestIdentifier. The request Identifier is made of an application id, a group ID, a group timestamp, and a namespace (learn more about it in the Sismo Connect package documentation).
VaultId and Proof Identifiers are two tools with different purposes. VaultId can help you to privately keep track of a user with an anonymous app-specific ID while a Proof Identifier can help you to prevent a user from using the same proof two times in your app.

Hydra Proof Of Ownership

Hydra Proof of Ownership also changes in Hydra-S2 as far as a new Commitment Mapper and a new variable when creating commitments. The secret used to generate the commitment for the trusted Commitment Mapper is now the hash of the Vault secret and the user secret instead of the user secret only.
Commitment=PoseidonHash(VaultSecret,AccountSecret);Commitment = PoseidonHash(VaultSecret, AccountSecret);
To allow this, we created a new commitment mapper, and we ensure that an account can only be added to one vault since the commitment is now based on the vault secret.

Optional verifications

Hydra-S2 also offers a modular way of generating ZK proofs. Therefore, while Hydra-S1 obliged users to prove that they own two accounts and that the source account was in a specific Account Tree (itself in a specific Registry Tree) with a specific value and checking a nullifier value, we can avoid checking specific constraints in the circuits.
It can be now optional to prove while using Hydra-S2 Proving Scheme:
  • any account ownership via Hydra Proof Of Ownership and the new commitment generation
  • any Registry Tree or Account Tree Merkle Proof of inclusion
  • any value held by a source of data (Ethereum address, web2 account, etc.)
  • any Vault Identifier generation
  • any Proof Identifier generation