Update EIP-6900: Fix parameter types

Merged by EIP-Bot.

EIPS/eip-6900.md

@@ -50,7 +50,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 - A **modular account** (or **modular smart contract account, MSCA**) is an account that supports modular functions. There are three types of modular functions:
   - **Validation functions** validate the caller's authenticity and authority to the account.
   - **Execution functions** execute any custom logic allowed by the account.
-  - **Hooks** execute custom logic and checks before and/or after an execution function.
+  - **Hooks** execute custom logic and checks before and/or after an execution function or validation function.
 - A **validation function** is a function that validates authentication and authorization of a caller to the account. There are two types of validation functions:
   - **User Operation Validator** functions handle calls to `validateUserOp` and check the validity of an ERC-4337 user operation.
   - **Runtime Validator** functions run before an execution function when not called via a user operation, and enforce checks. Common checks include allowing execution only by an owner.
@@ -254,7 +254,7 @@ enum ManifestFunctionType {
 }
 
 // For functions of type `ManifestFunctionType.DEPENDENCY`, the MSCA MUST find the plugin address
-// of the function at `config.dependencies[dependencyIndex]` during the call to `installPlugin(config)`.
+// of the function at `dependencies[dependencyIndex]` during the call to `installPlugin(...)`.
 struct ManifestFunction {
     ManifestFunctionType functionType;
     uint8 functionId;
@@ -326,16 +326,16 @@ struct PluginManifest {
 
 #### Calls to `installPlugin`
 
-The function `installPlugin` accepts a parameter `PluginInstallConfig calldata config`, which contains the address of the plugin to install, the Keccak-256 hash of the plugin's manifest, ABI-encoded data to pass to the plugin's `onInstall` callback, and an array of addresses that represent the plugin's install dependencies.
+The function `installPlugin` accepts 4 parameters: the address of the plugin to install, the Keccak-256 hash of the plugin's manifest, ABI-encoded data to pass to the plugin's `onInstall` callback, and an array of addresses that represent the plugin's install dependencies.
 
 The function MUST retrieve the plugin's manifest by calling `pluginManifest()` using `staticcall`.
 
 The function MUST perform the following preliminary checks:
 
 - Revert if the plugin has already been installed on the modular account.
 - Revert if the plugin does not implement ERC-165 or does not support the `IPlugin` interface.
-- Revert if `config.manifestHash` does not match the computed Keccak-256 hash of the plugin's returned manifest. This prevents installation of plugins that attempt to install a different plugin configuration than the one that was approved by the client.
-- Revert if any address in `config.dependencies` does not support the interface at its matching index in the manifest's `dependencyInterfaceIds`, or if the two array lengths do not match, or if any of the dependencies are not already installed on the modular account.
+- Revert if `manifestHash` does not match the computed Keccak-256 hash of the plugin's returned manifest. This prevents installation of plugins that attempt to install a different plugin configuration than the one that was approved by the client.
+- Revert if any address in `dependencies` does not support the interface at its matching index in the manifest's `dependencyInterfaceIds`, or if the two array lengths do not match, or if any of the dependencies are not already installed on the modular account.
 
 The function SHOULD store a record of the manifest hash and dependencies that were used for the plugin's installation. Each dependency's record SHOULD also be updated to reflect that it has a new dependent. These records facilitate the uninstall process.
 
@@ -346,11 +346,11 @@ The function MUST parse through the execution functions, validation functions, a
 - Each execution selector MUST be added as a valid execution function on the modular account. If the execution selector has already been added or matches the selector of a native function, the function SHOULD revert.
 - If an associated function that is to be added already exists, execution SHOULD NOT revert but continue to the next operation.
 
-Finally, the function MUST call the plugin's `onInstall` callback with the data provided in `config.data`. This serves to initializes the plugin state for the modular account. If `onInstall` reverts, the `installPlugin` function MUST revert.
+Finally, the function MUST call the plugin's `onInstall` callback with the data provided in the `installData` parameter. This serves to initializes the plugin state for the modular account. If `onInstall` reverts, the `installPlugin` function MUST revert.
 
 #### Calls to `uninstallPlugin`
 
-The function `uninstallPlugin` accepts a parameter `PluginUninstallConfig calldata config`, which contains the address of the plugin to uninstall and ABI-encoded data to pass to the plugin's `onUninstall` callback.
+The function `uninstallPlugin` accepts 2 parameters: the address of the plugin to uninstall and ABI-encoded data to pass to the plugin's `onUninstall` callback.
 
 The function MUST revert if the plugin is not installed on the modular account.
 
@@ -365,7 +365,7 @@ The function MUST remove records for the plugin's previously permitted execution
 
 The function MUST parse through the execution functions, validation functions, and hooks in the manifest and remove them from the modular account after resolving each `ManifestFunction` type. If any resolved function to be removed no longer exists on the modular account, execution SHOULD NOT revert to allow the uninstall to complete.
 
-Finally, the function MUST call the plugin's `onUninstall` callback with the data provided in `config.data`. This serves to clear the plugin state for the modular account. If `onUninstall` reverts, execution SHOULD continue to allow the uninstall to complete.
+Finally, the function MUST call the plugin's `onUninstall` callback with the data provided in the `uninstallData` parameter. This serves to clear the plugin state for the modular account. If `onUninstall` reverts, execution SHOULD continue to allow the uninstall to complete.
 
 > **⚠️ The ability to install and uninstall plugins is very powerful. The security of these functions determines the security of the account. It is critical for modular account implementers to make sure the implementation of the functions in `IPluginManager` have the proper security consideration and access control in place.**