Prefix ERC7579 interfaces names to avoid conflicts

ERCS/erc-7579.md

@@ -53,7 +53,7 @@ The smart account's validation function SHOULD return the return value of the va
 To comply with this standard, smart accounts MUST implement the execution interface below:
 
 ```solidity
-interface IExecution {
+interface IERC7579Execution {
     /**
      * @dev Executes a transaction on behalf of the account. MAY be payable.
      * @param mode The encoded execution mode of the transaction.
@@ -130,7 +130,7 @@ The account MUST encode the execution data the following ways:
 To comply with this standard, smart accounts MUST implement the account config interface below:
 
 ```solidity
-interface IAccountConfig {
+interface IERC7579AccountConfig {
     /**
      * @dev Returns the account id of the smart account
      * @return accountImplementationId the account id of the smart account
@@ -167,7 +167,7 @@ To comply with this standard, smart accounts MUST implement the module config in
 When storing an installed module, the smart account MUST ensure that there is a way to differentiate between module types. For example, the smart account should be able to implement access control that only allows installed executors, but not other installed modules, to call the `executeFromExecutor` function.
 
 ```solidity
-interface IModuleConfig {
+interface IERC7579ModuleConfig {
     event ModuleInstalled(uint256 moduleTypeId, address module);
     event ModuleUninstalled(uint256 moduleTypeId, address module);
 
@@ -258,7 +258,7 @@ Note: A single module can be of multiple types.
 Modules MUST implement the following interface:
 
 ```solidity
-interface IModule {
+interface IERC7579Module {
      /**
      * @dev This function is called by the smart account during installation of the module
      * @param data arbitrary data that may be required on the module during `onInstall` initialization
@@ -285,7 +285,7 @@ interface IModule {
 }
 ```
 
-Note: A single module that is of multiple types MAY decide to pass `moduleTypeId` inside `data` to `onInstall` and/or `onUninstall` methods, so those methods are able to properly handle installation/uninstallation for various types.  
+Note: A single module that is of multiple types MAY decide to pass `moduleTypeId` inside `data` to `onInstall` and/or `onUninstall` methods, so those methods are able to properly handle installation/uninstallation for various types.
 Example:
 
 ```solidity
@@ -299,10 +299,10 @@ function onInstall(bytes calldata data) external {
 
 #### Validators
 
-Validators MUST implement the `IModule` and the `IValidator` interface and have module type id: `1`.
+Validators MUST implement the `IERC7579Module` and the `IERC7579Validator` interface and have module type id: `1`.
 
 ```solidity
-interface IValidator is IModule {
+interface IERC7579Validator is IERC7579Module {
     /**
      * @dev Validates a UserOperation
      * @param userOp the ERC-4337 PackedUserOperation
@@ -328,20 +328,20 @@ interface IValidator is IModule {
 
 #### Executors
 
-Executors MUST implement the `IModule` interface and have module type id: `2`.
+Executors MUST implement the `IERC7579Module` interface and have module type id: `2`.
 
 #### Fallback Handlers
 
-Fallback handlers MUST implement the `IModule` interface and have module type id: `3`.
+Fallback handlers MUST implement the `IERC7579Module` interface and have module type id: `3`.
 
 Fallback handlers MAY implement authorization control. Fallback handlers that do implement authorization control, MUST NOT rely on `msg.sender` for authorization control but MUST use ERC-2771 `_msgSender()` instead.
 
 #### Hooks
 
-Hooks MUST implement the `IModule` and the `IHook` interface and have module type id: `4`.
+Hooks MUST implement the `IERC7579Module` and the `IERC7579Hook` interface and have module type id: `4`.
 
 ```solidity
-interface IHook is IModule {
+interface IERC7579Hook is IERC7579Module {
     /**
      * @dev Called by the smart account before execution
      * @param msgSender the address that called the smart account