Skip to content
Merged
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
1 change: 1 addition & 0 deletions docs.json
Original file line number Diff line number Diff line change
Expand Up @@ -111,6 +111,7 @@
"fhe-library/core-concepts/data-evaluation",
"fhe-library/core-concepts/encrypted-operations",
"fhe-library/core-concepts/conditions",
"fhe-library/core-concepts/require",
"fhe-library/core-concepts/access-control",
"fhe-library/core-concepts/decryption-operations",
"fhe-library/core-concepts/randomness",
Expand Down
2 changes: 1 addition & 1 deletion fhe-library/core-concepts/conditions.mdx
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
---
title: "Conditions"
title: "Conditions (if .. else)"
description: "Understanding why if..else isn't possible with FHE and exploring the alternatives"
---

Expand Down
54 changes: 54 additions & 0 deletions fhe-library/core-concepts/require.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
---
title: "Require"
description: "Understanding require statements with encrypted data in FHE"
---

## Overview

The `require` statement in FHE contracts works similarly to [Conditions (if .. else)](/fhe-library/core-concepts/conditions) because both involve conditional logic on encrypted data. Just like you can't use traditional `if...else` statements with encrypted values, you also can't use standard `require` statements that depend on encrypted conditions.

<Warning>
Traditional `require` statements that check encrypted conditions will leak information about your encrypted values through execution paths.
</Warning>

---

## Why Require is Like Conditions

Both `require` and conditional statements face the same fundamental challenge in FHE:

<CardGroup cols={2}>
<Card title="Encrypted Evaluation" icon="lock">
The condition being checked is encrypted, so the contract can't directly evaluate it to decide whether to revert.
</Card>

<Card title="Information Leakage" icon="shield-exclamation">
If a transaction reverts based on an encrypted condition, observers can infer information about the encrypted data.
</Card>
</CardGroup>

---

## The Solution

Instead of using `require` with encrypted conditions, you should:

1. **Use `FHE.select`** to handle the conditional logic (see [Conditions (if .. else)](/fhe-library/core-concepts/conditions))
2. **Only use `require` for non-encrypted conditions** like access control checks, address validation, or other plaintext values

```solidity
// Good - require on plaintext condition
require(msg.sender == owner, "Not authorized");

// Good - use select for encrypted logic
euint32 result = FHE.select(encryptedCondition, valueA, valueB);

// Bad - require on encrypted condition leaks information!
require(FHE.decrypt(encryptedValue.gt(threshold)), "Value too low");
```

---

## Learn More

For detailed guidance on handling conditional logic with encrypted data, see the [Conditions (if .. else)](/fhe-library/core-concepts/conditions) page.