Merge branch 'master' into patch-1

ERCS/erc-3668.md

@@ -1,6 +1,6 @@
 ---
 eip: 3668
-title: "CCIP Read: Secure offchain data retrieval"
+title: CCIP Read—Secure offchain data retrieval
 description: CCIP Read provides a mechanism to allow a contract to fetch external data.
 author: Nick Johnson (@arachnid)
 discussions-to: https://ethereum-magicians.org/t/durin-secure-offchain-data-retrieval/6728
@@ -295,8 +295,8 @@ A client that supports CCIP read MUST make contract calls using the following pr
  5. If the `sender` field does not match the address of the contract that was called, return an error to the caller and stop.
  6. Construct a request URL by replacing `sender` with the lowercase 0x-prefixed hexadecimal formatted `sender` parameter, and replacing `data` with the 0x-prefixed hexadecimal formatted `callData` parameter. The client may choose which URLs to try in which order, but SHOULD prioritise URLs earlier in the list over those later in the list.
  7. Make an HTTP GET request to the request URL.
- 8. If the response code from step (5) is in the range 400-499, return an error to the caller and stop.
- 9. If the response code from step (5) is in the range 500-599, go back to step (5) and pick a different URL, or stop if there are no further URLs to try.
+ 8. If the response code from step (7) is in the range 400-499, return an error to the caller and stop.
+ 9. If the response code from step (7) is in the range 500-599, go back to step (5) and pick a different URL, or stop if there are no further URLs to try.
  10. Otherwise, replace `data` with an ABI-encoded call to the contract function specified by the 4-byte selector `callbackFunction`, supplying the data returned from step (7) and `extraData` from step (4), and return to step (1).
 
 Clients MUST handle HTTP status codes appropriately, employing best practices for error reporting and retries.

ERCS/erc-6900.md

@@ -463,17 +463,10 @@ interface IExecutionHookModule is IModule {
 }
 ```
 
-### Validation Functions and Their Installation/Uninstallation
-
-- An account can have more than one validation module/function installed.
-- An account can have the same validation module installed more than once.
-- The entity ID of a validation function installed on an account MUST be unique.
-- Validation installation MAY be deferred until a later time, such as upon first use.
+### Validation Functions
 
 #### Installation
 
-During validation installation, the account MUST correctly set flags and other fields based on the incoming data provided by the user.
-
 - The account MUST install all validation hooks specified by the user and SHOULD call `onInstall` with the user-provided data on the hook module to initialize state if specified by the user.
 - The account MUST install all execution hooks specified by the user and SHOULD call `onInstall` with the user-provided data on the hook module to initialize state if specified by the user.
 - The account MUST configure the validation function to validate all of the selectors specified by the user.
@@ -492,17 +485,13 @@ During validation uninstallation, the account MUST correctly clear flags and oth
 - The account SHOULD call `onUninstall` on the validation module to clean up state if specified by the user.
 - The account MUST emit `ValidationUninstalled` as defined in the interface for all uninstalled validation functions.
 
-### Execution Functions and Their Installation/Uninstallation
-
-- An account can install any number of execution functions.
-- An execution function selector MUST be unique in the account.
-- An execution function selector MUST not conflict with native ERC-4337 and ERC-6900 functions.
+### Execution Functions
 
 #### Installation
 
-During execution installation, the account MUST correctly set flags and other fields based on the incoming data and module manifest provided by the user.
-
 - The account MUST install all execution functions and set flags and fields as specified in the manifest.
+    - An execution function selector MUST be unique in the account.
+    - An execution function selector MUST not conflict with native ERC-4337 and ERC-6900 functions.
 - The account MUST add all execution hooks as specified in the manifest.
 - The account SHOULD add all supported interfaces as specified in the manifest.
 - The account SHOULD call `onInstall` on the execution module to initialize state if specified by the user.
@@ -524,10 +513,10 @@ During execution uninstallation, the account MUST correctly clear flags and othe
 
 For accounts that implement execution hooks, accounts MUST conform to these execution hook formats:
 
-1. For `executeUserOp` calls, for execution hooks associated with a validation function, accounts MUST send the full `msg.data`, including the `executeUserOp` selector.
+1. For `executeUserOp` calls, for execution hooks associated with a validation function, accounts MUST send the full calldata (`msg.data` in solidity), including the `executeUserOp` selector.
 2. For `executeUserOp` calls, for execution hooks associated with a selector, accounts MUST send `PackedUserOperation.callData` for `executeUserOp` calls, excluding `executeUserOp.selector` and the rest of the `PackedUserOperation`.
-3. For `executeWithRuntimeValidation` calls, for all execution hooks, accounts MUST send the inner `data`.
-4. For all other calls, for execution hooks associated with a selector, accounts MUST send over `msg.data`.
+3. For `executeWithRuntimeValidation` calls, for all execution hooks, accounts MUST send the inner `data` field.
+4. For all other calls, for execution hooks associated with a selector, accounts MUST send over the full calldata (`msg.data` in solidity).
 
 #### Hook Execution Order
 
@@ -541,9 +530,9 @@ For each of these validation types, an account implementation MAY specify its ow
 
 Within the implementation of each type of validation function, the modular account MUST check that the provided validation function applies to the given function selector intended to be run (See [Checking Validation Applicability](#checking-validation-applicability)). Then, the account MUST execute all validation hooks of the corresponding type associated with the validation function in use. After the execution of validation hooks, the account MUST invoke the validation function of the corresponding type. If any of the validation hooks or the validation function reverts, the account MUST revert. It SHOULD include the module's revert data within its revert data.
 
-The account MUST define a way to pass data separately for each validation hook and the validation function itself. This data MUST be sent as the `userOp.signature` field for user op validation, the `authorization` field for runtime validation, and the `signature` field for signature validation.
+The account MUST define a way to pass data separately for each validation hook and the validation function itself. This data SHOULD be sent as the `userOp.signature` field for user op validation, the `authorization` field for runtime validation, and the `signature` field for signature validation.
 
-The result of user op validation SHOULD be the intersection of time bounds returned by the validation hooks and the validation function. If any validation hooks or the validation functions returns a value of `1` for the authorizer field, indicating a signature verification failure by the ERC-4337 standard, the account MUST return a value of `1` for the authorizer portion of the validation data.
+The result of user op validation MUST be the intersection of time bounds returned by the validation hooks and the validation function. If any validation hooks or the validation functions returns a value of `1` for the authorizer field, indicating a signature verification failure by the ERC-4337 standard, the account MUST return a value of `1` for the authorizer portion of the validation data.
 
 The set of validation hooks run MUST be the hooks specified by account state at the start of validation. In other words, if the set of applicable hooks changes during validation, the original set of hooks MUST still run, and only future invocations of the same validation should reflect the changed set of hooks.
 
@@ -628,11 +617,11 @@ From the wallet side, there are certain checks that the wallet/SDK should perfor
 
 The standard introduces a concept of the execution manifest, which describes the execution functions, interface IDs, and hooks that should be installed on the account from an execution manifest. As part of constructing parameters to `installExecution()`, the SDK creates an `executionManifest` parameter that will specify the actions of the execution module being installed. SDKs will process the provided `executionManifest()` function of the underlying module, but the finished parameter will not necessarily be identical to the module’s return value of `executionManifest()`. Furthermore, this parameter is only going through very limited checks on-chain as part of the installation process. Therefore, the `executionManifest` parameter needs to be carefully constructed and verified before being used for installations. Furthermore, the `executionManifest` parameter of uninstallation should ideally be the same used in installation to not leave residual data.
 
-The standard supports a `isGlobalValidation` flag for validation functions, which means that this function is added to a global validation pool and can validate any of the execution functions that expose themselves to global validation via `allowGlobalValidation` flag. By default all native execution functions are allowed to be globally validated. Therefore, the wallets should be careful on what validation functions they allow to be installed that have global validation allowed, as that would allow these functions to validate all native functions by default and hence bypass any restrictions that have been added to protect these native/execution functions. In a sense these global validation functions gain root access to the account.
+The standard supports a `isGlobalValidation` flag for validation functions, which means that this function is added to a global validation pool and can validate any of the execution functions that expose themselves to global validation via `allowGlobalValidation` flag. Depending on the implementation, some, all or none of the native execution functions could be globally validated. Therefore, the wallets should be careful about what validation functions they allow to be installed with global validation enabled, as that would allow these functions to validate the exposed native functions and hence bypass any restrictions that may have been added to protect these native/execution functions. In a sense, these global validation functions could gain root access to the exposed native execution functions and potentially the whole account.
 
 ### Module Developers
 
-The standard does not enforce any rules surrounding what data needs to be installed or uninstalled when a module is added/deleted from the account. Hence the `onUninstall()` function in various modules may leave behind residual state data, especially since the external call is only performed if `onInstallData` is specified. Furthermore, execution hooks linked to an uninstalled function may remain configured. This could pose security risks or lead to unexpected behavior in the case where the module is reinstalled with the same `entityId`. The danger is that previously set permissions or data may be unintentionally reused. Hence it is a good idea to fully uninstall all data linked to the smart module account including execution hooks.
+The standard does not enforce any rules surrounding what data needs to be installed or uninstalled when a module is added/deleted from the account. Hence the `onUninstall()` function in various modules may leave behind residual state data, especially since the external call may not be performed all. Furthermore, execution hooks linked to an uninstalled function may remain configured. This could pose security risks or lead to unexpected behavior in the case where the module is reinstalled with the same `entityId`. The danger is that previously set permissions or data may be unintentionally reused. Hence it is a good idea to fully uninstall all data linked to the smart module account including execution hooks.
 
 ### Users