Skip to content
Closed
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
22 changes: 21 additions & 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 Expand Up @@ -135,6 +135,26 @@ euint32 feeRate = FHE.select(isPremiumUser, PREMIUM_FEE, STANDARD_FEE);
euint32 totalFee = FHE.mul(amount, feeRate);
```

### 6. Require

Simulate `require` statements by using encrypted zero when a condition fails:

```solidity
// Check if user has sufficient balance
ebool hasSufficientBalance = userBalance.gte(amount);

// If condition fails, use encrypted zero; otherwise use the actual amount
euint32 transferAmount = FHE.select(hasSufficientBalance, amount, FHE.asEuint32(0));

// Process the transfer (will be zero if condition wasn't met)
userBalance = userBalance.sub(transferAmount);
recipientBalance = recipientBalance.add(transferAmount);
```

<Note>
This pattern simulates transaction invalidation by using encrypted zero when conditions aren't met, effectively making the operation a no-op while maintaining constant-time execution. Learn more in the [Require](/fhe-library/core-concepts/require) guide.
</Note>

---

## Best Practices
Expand Down
58 changes: 58 additions & 0 deletions fhe-library/core-concepts/require.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
---
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 as you can't use traditional `if...else` statements with encrypted values, you also can't directly use `require` statements with encrypted booleans.

<Warning>
Traditional `require` statements cannot evaluate encrypted conditions directly. You must decrypt the condition first or use alternative patterns.
</Warning>

---

## Why Require is Similar to 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 cannot directly evaluate whether it's true or false.
</Card>

<Card title="No Direct Branching" icon="code-branch">
Both require branching logic that reveals information about encrypted data, which breaks FHE's privacy guarantees.
</Card>
</CardGroup>

---

## Working with Require in FHE

Since decryption is asynchronous, you cannot use traditional `require` statements with encrypted conditions in the same transaction. Instead, simulate the behavior by using encrypted zero when conditions fail:

```solidity
// Check if user has sufficient balance
ebool hasSufficientBalance = userBalance.gte(amount);

// If condition fails, use encrypted zero; otherwise use the actual amount
euint32 transferAmount = FHE.select(hasSufficientBalance, amount, FHE.asEuint32(0));

// Process the transfer (will be zero if condition wasn't met)
userBalance = userBalance.sub(transferAmount);
recipientBalance = recipientBalance.add(transferAmount);
```

<Note>
This pattern simulates transaction invalidation by using encrypted zero when conditions aren't met, effectively making the operation a no-op while maintaining constant-time execution and privacy.
</Note>

---

## Related Topics

- Learn more about conditional logic in [Conditions (if .. else)](/fhe-library/core-concepts/conditions)
- Understand decryption in [Decryption Operations](/fhe-library/core-concepts/decryption-operations)
- Explore access control in [Access Control](/fhe-library/core-concepts/access-control)