docs(common): updates FHEVM and other suggestions

Author: PacificYield

docs/solidity-guides/acl/README.md

@@ -8,7 +8,7 @@ The ACL is a permission management system designed to control who can access, co
 
 ## Why is the ACL important?
 
-Encrypted data in fhevm is entirely confidential, meaning that without proper access control, even the contract holding the ciphertext cannot interact with it. The ACL enables:
+Encrypted data in FHEVM is entirely confidential, meaning that without proper access control, even the contract holding the ciphertext cannot interact with it. The ACL enables:
 
 - **Granular permissions**: Define specific access rules for individual accounts or contracts.
 - **Secure computations**: Ensure that only authorized entities can manipulate or decrypt encrypted data.

docs/solidity-guides/acl/acl_examples.md

@@ -19,6 +19,7 @@ The ACL system allows you to define two types of permissions for accessing ciphe
 You can also use method-chaining syntax for granting allowances:
 
 ```solidity
+use FHE for *;
 ciphertext.allow(address1).allow(address2);
 ```
 
@@ -36,6 +37,7 @@ This is equivalent to calling `FHE.allow(ciphertext, address1)` followed by `FHE
 Method chaining is also available for transient allowances:
 
 ```solidity
+use FHE for *;
 ciphertext.allowTransient(address1).allowTransient(address2);
 ```
 
@@ -48,6 +50,7 @@ ciphertext.allowTransient(address1).allowTransient(address2);
 #### Alternative Solidity syntax
 
 ```solidity
+use FHE for *;
 ciphertext.allowThis();
 ```
 
@@ -145,4 +148,4 @@ function transfer(address to, euint64 encryptedAmount) public {
 
 ---
 
-By understanding how to grant and verify permissions, you can effectively manage access to encrypted data in your fhevm smart contracts. For additional context, see the [ACL overview](./).
+By understanding how to grant and verify permissions, you can effectively manage access to encrypted data in your FHEVM smart contracts. For additional context, see the [ACL overview](./).

docs/solidity-guides/asEXXoperators.md

@@ -1,6 +1,6 @@
 # asEbool, asEuintXX, and asEaddress operations
 
-This documentation covers the `asEbool`, `asEuintXX`, and `asEaddress` operations provided by the FHE library for working with encrypted data in the fhevm. These operations are essential for converting between plaintext and encrypted types, as well as handling encrypted inputs.
+This documentation covers the `asEbool`, `asEuintXX`, and `asEaddress` operations provided by the FHE library for working with encrypted data in the FHEVM. These operations are essential for converting between plaintext and encrypted types, as well as handling encrypted inputs.
 
 The operations can be categorized into three main use cases:
 

docs/solidity-guides/conditions.md

@@ -1,12 +1,12 @@
 # Branching in FHE
 
-This document explains how to implement conditional logic (if/else branching) when working with encrypted values in fhevm. Unlike typical Solidity programming, working with Fully Homomorphic Encryption (FHE) requires specialized methods to handle conditions on encrypted data.
+This document explains how to implement conditional logic (if/else branching) when working with encrypted values in FHEVM. Unlike typical Solidity programming, working with Fully Homomorphic Encryption (FHE) requires specialized methods to handle conditions on encrypted data.
 
 ## **Overview**
 
-In fhevm, when you perform [comparison operations](../references/functions.md#comparison-operation-eq-ne-ge-gt-le-lt), the result is an encrypted boolean (`ebool`). Since encrypted booleans do not support standard boolean operations like `if` statements or logical operators, conditional logic must be implemented using specialized methods.
+In FHEVM, when you perform [comparison operations](../references/functions.md#comparison-operation-eq-ne-ge-gt-le-lt), the result is an encrypted boolean (`ebool`). Since encrypted booleans do not support standard boolean operations like `if` statements or logical operators, conditional logic must be implemented using specialized methods.
 
-To facilitate conditional assignments, fhevm provides the `FHE.select` function, which acts as a ternary operator for encrypted values.
+To facilitate conditional assignments, FHEVM provides the `FHE.select` function, which acts as a ternary operator for encrypted values.
 
 ## **Using `FHE.select` for conditional logic**
 

docs/solidity-guides/configure.md

@@ -28,7 +28,7 @@ import { SepoliaZamaFHEVMConfig } from "fhevm/config/ZamaFHEVMConfig.sol";
 **Purpose:**
 
 - Sets encryption parameters such as cryptographic keys and supported ciphertext types.
-- Ensures proper initialization of the fhevm environment.
+- Ensures proper initialization of the FHEVM environment.
 
 **Example: using Sepolia configuration**
 
@@ -71,7 +71,7 @@ import "fhevm/gateway/GatewayCaller.sol";
 
 contract Test is SepoliaZamaFHEVMConfig, SepoliaZamaGatewayConfig, GatewayCaller {
   constructor() {
-    // Gateway and fhevm environment initialized automatically
+    // Gateway and FHEVM environment initialized automatically
   }
 }
 ```

docs/solidity-guides/contracts.md

@@ -1,6 +1,6 @@
 # fhevm-contracts
 
-This guide explains how to use the [fhevm Contracts standard library](https://github.com/zama-ai/fhevm-contracts/tree/main). This library provides secure, extensible, and pre-tested Solidity templates designed for developing smart contracts on fhevm using the FHE library.
+This guide explains how to use the [fhevm Contracts standard library](https://github.com/zama-ai/fhevm-contracts/tree/main). This library provides secure, extensible, and pre-tested Solidity templates designed for developing smart contracts on FHEVM using the FHE library.
 
 ## Overview
 

docs/solidity-guides/decryption/decrypt.md

@@ -15,7 +15,7 @@ To learn how decryption works see [Encryption, Decryption, Re-encryption, and Co
 
 ## Overview
 
-Decryption in fhevm is an asynchronous process that involves the Gateway and Key Management System (KMS). Contracts requiring decryption must extend the GatewayCaller contract, which imports the necessary libraries and provides access to the Gateway.
+Decryption in FHEVM is an asynchronous process that involves the Gateway and Key Management System (KMS). Contracts requiring decryption must extend the GatewayCaller contract, which imports the necessary libraries and provides access to the Gateway.
 
 Here’s an example of how to request decryption in a contract:
 
@@ -52,7 +52,7 @@ contract TestAsyncDecrypt is SepoliaZamaFHEVMConfig, SepoliaZamaGatewayConfig, G
 
 #### Key additions to the code
 
-1.  **Configuration imports**: The configuration contracts are imported to set up the fhevm environment and Gateway.
+1.  **Configuration imports**: The configuration contracts are imported to set up the FHEVM environment and Gateway.
 
     ```solidity
     import { SepoliaZamaFHEVMConfig } from "fhevm/config/ZamaFHEVMConfig.sol";

docs/solidity-guides/decryption/decrypt_details.md

@@ -1,16 +1,16 @@
 # Decryption in depth
 
-This document provides a detailed guide on implementing decryption in your smart contracts using the `GatewayContract` in fhevm. It covers the setup, usage of the `Gateway.requestDecryption` function, and testing with Hardhat.
+This document provides a detailed guide on implementing decryption in your smart contracts using the `DecryptionOracle` in fhevm. It covers the setup, usage of the `FHE.requestDecryption` function, and testing with Hardhat.
 
-## `GatewayContract` set up
+## `DecryptionOracle` set up
 
-The `GatewayContract` is pre-deployed on the fhevm testnet. It uses a default relayer account specified in the `PRIVATE_KEY_GATEWAY_RELAYER` or `ADDRESS_GATEWAY_RELAYER` environment variable in the `.env` file.
+The `DecryptionOracle` is pre-deployed on the FHEVM testnet. It uses a default relayer account specified in the `PRIVATE_KEY_GATEWAY_RELAYER` or `ADDRESS_GATEWAY_RELAYER` environment variable in the `.env` file.
 
 Relayers are the only accounts authorized to fulfill decryption requests. The role of the `DecryptionORacle`, however, is to independently verify the KMS signature during execution. This ensures that the relayers cannot manipulate or send fraudulent decryption results, even if compromised. However, the relayers are still trusted to forward decryption requests on time.
 
-## `IDecryptionOracle.requestDecryption` function
+## `FHE.requestDecryption` function
 
-The interface of the `IDecryptionOracle.requestDecryption` function from previous snippet is the following:
+You can call the function `FHE.requestDecryption` as such:
 
 ```solidity
     function requestDecryption(uint256 requestID, bytes32[] calldata ctsHandles, bytes4 callbackSelector) external payable;
@@ -144,7 +144,7 @@ event ResultCallback(uint256 indexed requestID, bool success, bytes result);
 
 The first argument is the `requestID` of the corresponding decryption request, `success` is a boolean assessing if the call to the callback succeeded, and `result` is the bytes array corresponding to the return data from the callback.
 
-In your hardhat tests, if you sent some transactions which are requesting one or several decryptions and you wish to await the fulfillment of those decryptions, you should import the two helper methods `initGateway` and `awaitAllDecryptionResults` from the `asyncDecrypt.ts` utility file. This would work both when testing on a fhevm node or in mocked mode. Here is a simple hardhat test for the previous `TestAsyncDecrypt` contract (more examples can be seen [here](https://github.com/zama-ai/fhevm-solidity/tree/v0.6.2/test/gatewayDecrypt/testAsyncDecrypt.ts)):
+In your hardhat tests, if you sent some transactions which are requesting one or several decryptions and you wish to await the fulfillment of those decryptions, you should import the two helper methods `initGateway` and `awaitAllDecryptionResults` from the `asyncDecrypt.ts` utility file. This would work both when testing on a FHEVM node or in mocked mode. Here is a simple hardhat test for the previous `TestAsyncDecrypt` contract (more examples can be seen [here](https://github.com/zama-ai/fhevm-solidity/tree/v0.6.2/test/gatewayDecrypt/testAsyncDecrypt.ts)):
 
 ```js
 import { initGateway, awaitAllDecryptionResults } from "../asyncDecrypt";
@@ -165,7 +165,7 @@ describe("TestAsyncDecrypt", function () {
   });
 
   it("test async decrypt uint32", async function () {
-    const tx2 = await this.contract.connect(this.signers.carol).requestUint32(5, 15, { gasLimit: 500_000 }); // custom gasLimit to avoid gas estimation error in fhevm mode
+    const tx2 = await this.contract.connect(this.signers.carol).requestUint32(5, 15, { gasLimit: 500_000 }); // custom gasLimit to avoid gas estimation error in FHEVM mode
     await tx2.wait();
     await awaitAllDecryptionResults();
     const y = await this.contract.yUint32();

docs/solidity-guides/decryption/reencryption.md

@@ -2,7 +2,7 @@
 
 This document explains how to perform user decryption. User decryption required when you want a user to access their private data without it being exposed to the blockchain.
 
-Re-encryption in fhevm enables the secure sharing or reuse of encrypted data under a new public key without exposing the plaintext. This feature is essential for scenarios where encrypted data must be transferred between contracts, dApps, or users while maintaining its confidentiality.
+Re-encryption in FHEVM enables the secure sharing or reuse of encrypted data under a new public key without exposing the plaintext. This feature is essential for scenarios where encrypted data must be transferred between contracts, dApps, or users while maintaining its confidentiality.
 
 {% hint style="info" %}
 Before implementing re-encryption, ensure you are familiar with the foundational concepts of encryption, re-encryption and computation. Refer to [Encryption, Decryption, Re-encryption, and Computation](../d_re_ecrypt_compute.md).

docs/solidity-guides/error_handling.md

@@ -1,6 +1,6 @@
 # Error handling
 
-This document explains how to handle errors effectively in fhevm smart contracts. Since transactions involving encrypted data do not automatically revert when conditions are not met, developers need alternative mechanisms to communicate errors to users.
+This document explains how to handle errors effectively in FHEVM smart contracts. Since transactions involving encrypted data do not automatically revert when conditions are not met, developers need alternative mechanisms to communicate errors to users.
 
 ## **Challenges in error handling**