Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
65 changes: 65 additions & 0 deletions apps/docs/versioned_docs/version-V4/faq.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,71 @@ You can find a complete list of applications that are using Semaphore on the [Se

There are three ways you can start using Semaphore in your project: using the [CLI](https://github.com/semaphore-protocol/semaphore/tree/main/packages/cli), using the [boilerplate](https://github.com/semaphore-protocol/boilerplate/tree/main) as a template or forking it, or installing the Semaphore [packages](/guides/identities) manually.

## What group size should I use for my application?

The group size you need depends on your privacy requirements. Here are some general guidelines:

- **10-20 members**: Minimal privacy, suitable for small team feedback where anonymity is not critical
- **50-100 members**: Adequate for most organizational use cases like internal voting or surveys
- **500+ members**: Recommended for high-stakes privacy applications like whistleblowing
- **1,000+ members**: Maximum privacy for public applications

Remember that larger groups provide stronger anonymity because it's harder to identify which specific member created a proof. For detailed guidance, see the [privacy considerations guide](/guides/privacy-considerations).

## How does Semaphore protect my privacy?

Semaphore uses zero-knowledge proofs to provide cryptographic privacy guarantees:

1. **Group membership privacy**: No one can determine which specific group member created a proof
2. **Message authenticity**: Only group members can create valid proofs
3. **Double-signaling prevention**: The nullifier system prevents the same identity from creating multiple proofs for the same scope
4. **Unlinkability across scopes**: Proofs from the same identity on different scopes cannot be linked together

However, Semaphore does NOT automatically protect against network-level metadata (like your IP address), transaction timing patterns, or message content that might reveal your identity. Use relays and follow best practices to maximize your privacy. See the [privacy considerations guide](/guides/privacy-considerations) for more details.

## What is an anonymity set and why does it matter?

An [anonymity set](/glossary#anonymity-set) is the group of users among whom you are hiding. In Semaphore, this is the [group](/glossary#group) your identity belongs to.

The anonymity set matters because it directly determines your privacy level:

- In a group of 10 members, you're one of 10 possibilities (10% chance of identification)
- In a group of 1,000 members, you're one of 1,000 possibilities (0.1% chance)

Larger anonymity sets make it exponentially harder for anyone to identify you. Always consider whether your group size provides adequate privacy for your use case.

## Should I use the same identity across multiple groups?

Generally, no. Using the same identity across multiple groups creates several risks:

1. **Security risk**: If an attacker compromises that identity, all groups it belongs to are affected
2. **Privacy risk - Membership linking**: With on-chain groups, anyone can see that the same commitment appears in multiple groups, linking your memberships
3. **Privacy risk - Activity linking**: If you use the same [scope](/glossary#scope) in different groups, your activities become linkable because nullifiers are computed as `Poseidon(scope, secret)` without the group ID

**Best practice**: Use different identities for different contexts or applications. If you must use the same identity, ensure each group uses unique scopes. If you're using deterministic identity generation (e.g., signing a message with MetaMask), ensure each application uses a unique message to generate different identities. See the [privacy considerations guide](/guides/privacy-considerations#risk-4-cross-group-identity-linking) for more information.

## Do I need to use a relay?

If privacy is important for your application, yes. A [relay](/glossary#relay) submits blockchain transactions on your behalf, preventing your Ethereum address from being publicly linked to your proofs.

**Without a relay**: Your wallet address is visible on-chain alongside your proof, allowing observers to link all your proofs together.

**With a relay**: The relay's address appears on-chain, not yours, preserving your anonymity.

Relays are essential for applications where users must remain anonymous, such as whistleblowing platforms or private voting systems. See the [privacy considerations guide](/guides/privacy-considerations#risk-1-transaction-linkability) for implementation guidance.

## Can someone identify me from my proof?

The zero-knowledge proof itself does not reveal your identity - it only proves you are a member of the group. However, you can be identified through:

1. **Message content**: If your message contains identifying information
2. **Transaction metadata**: If you submit proofs directly from your wallet without using a relay
3. **Timing patterns**: If you submit proofs immediately after specific events
4. **Small group size**: If the anonymity set is too small (e.g., fewer than 10 members)
5. **Cross-group linking**: If you use the same identity in multiple groups

To maximize privacy, use relays, large groups, avoid timing patterns, and never include identifying information in your messages. Read the [privacy considerations guide](/guides/privacy-considerations) for comprehensive guidance.

## How can I contribute to the protocol?

There are several ways you could contribute to the protocol, you can find more information about on [Github](https://github.com/semaphore-protocol#ways-to-contribute).
13 changes: 11 additions & 2 deletions apps/docs/versioned_docs/version-V4/glossary.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,12 @@ The public [Semaphore identity](#identity) value used in [Semaphore groups](#gro

A group is a [Merkle tree](#merkle-tree) in which each leaf is an [identity commitment](#identity-commitment) for a user. Semaphore uses the [LeanIMT](https://zkkit.pse.dev/classes/_zk_kit_lean_imt.LeanIMT.html) implementation, which is an optimized binary incremental Merkle tree. The tree nodes are calculated using [Poseidon](https://www.poseidon-hash.info).

Groups also serve as [anonymity sets](#anonymity-set) in Semaphore. When you generate a proof, you prove you are _one of the group members_ without revealing _which member_ you are. The size of the group directly affects your privacy - larger groups provide stronger anonymity.

## Anonymity set

The set of users among whom an individual is hiding. In Semaphore, the anonymity set is the [group](#group) to which your [identity](#identity) belongs. When you generate a proof, observers know the proof came from _someone in the group_, but cannot determine _which specific member_ created it. The larger the anonymity set (group size), the stronger your privacy protection. For example, in a group of 100 members, you are one of 100 possibilities (1% chance of identification), whereas in a group of 10 members, you are one of 10 possibilities (10% chance).

## Merkle tree

A [tree](https://en.wikipedia.org/wiki/Merkle_tree) in which every leaf (i.e., a node that doesn't have children) is labelled with the cryptographic hash of a data block,
Expand All @@ -37,8 +43,11 @@ The term "message" in Semaphore refers to the value the user broadcasts when vot

## Relay

A third-party who could receive a fee for including relayed transactions in the blockchain (McMenamin, Daza, and Fitz. https://eprint.iacr.org/2022/155.pdf, p.3).
To preserve the anonymity of the user broadcasting a message with Semaphore, an application may use a relayer to send the transaction to Ethereum on behalf of the user.
A third-party service that submits blockchain transactions on behalf of users. Relays are essential for privacy in Semaphore because they prevent your Ethereum address from being publicly linked to your proofs.

**Privacy role**: Without a relay, submitting a proof directly from your wallet creates a public connection between your Ethereum address and the proof. Even though the proof itself is anonymous, observers can link all proofs submitted from the same address. Relays break this link by submitting transactions from their own address.

Relays may receive a fee for their service. For more details, see McMenamin, Daza, and Fitz's research on relayers: https://eprint.iacr.org/2022/155.pdf

## Trusted setup

Expand Down
32 changes: 30 additions & 2 deletions apps/docs/versioned_docs/version-V4/guides/groups.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,26 @@ Merkle Tree) [Solidity](https://github.com/privacy-scaling-explorations/zk-kit/t
[JavaScript](https://github.com/privacy-scaling-explorations/zk-kit/tree/main/packages/imt) implementations for managing groups. Groups are Merkle trees, and the group members (i.e., identity commitments) are their leaves.
:::

## Groups as anonymity sets

In Semaphore, groups serve as [anonymity sets](https://en.wikipedia.org/wiki/Anonymity#Anonymity_and_pseudonymity) - the set of users among whom you are hiding when you generate a proof. The size of your group directly impacts the privacy protection you receive:

- **Larger groups** provide stronger anonymity because it's harder to identify which specific member created a proof
- **Smaller groups** provide weaker anonymity because there are fewer possible members to hide among

### Privacy and group size

When designing your application, consider the privacy requirements:

- **Groups with fewer than 10 members** provide minimal privacy protection
- **Groups with 50-100 members** are suitable for most organizational use cases (voting, feedback)
- **Groups with 500+ members** are recommended for high-stakes privacy applications (whistleblowing, sensitive signaling)
- **Groups with 1,000+ members** provide the strongest privacy for public applications

:::tip Privacy considerations
Group size is just one factor in maintaining privacy. For a comprehensive understanding of privacy in Semaphore, including timing attacks, metadata protection, and identity management, see the [privacy considerations guide](/guides/privacy-considerations).
:::

## Off-chain groups

Use the [`@semaphore-protocol/group`](https://github.com/semaphore-protocol/semaphore/blob/main/packages/group) package to manage off-chain groups.
Expand Down Expand Up @@ -99,8 +119,16 @@ To add a batch of members to a group, pass an array to the `addMembers` method.
group1.addMembers(members)
```

:::caution
When you use the same Semaphore identity across multiple groups, if an attacker takes control of that identity all the groups it is part of will be compromised. Consider using different identities for each group.
:::caution Identity reuse across groups
When you use the same Semaphore identity across multiple groups:

1. **Security risk**: If an attacker obtains your private key, they can generate valid proofs in ALL groups where your commitment exists

2. **Privacy risk - Membership linking**: With on-chain groups, anyone can see that the same commitment appears in multiple groups, linking your memberships together

3. **Privacy risk - Activity linking**: If you use the same [scope](/glossary#scope) in different groups, your activities can be linked via identical [nullifiers](/glossary#nullifier). Using different scopes in different groups prevents this cryptographic linking

**Best practice**: Use different identities for different groups or contexts to maintain both security and privacy. See the [privacy considerations guide](/guides/privacy-considerations#risk-4-cross-group-identity-linking) for more details.
:::

### Remove or update members
Expand Down
Loading
Loading