From 2267eaa92a837401379fd2debcf3113cc97b0716 Mon Sep 17 00:00:00 2001 From: adam Date: Wed, 21 Jun 2023 18:02:12 -0400 Subject: [PATCH 01/11] Spec updates --- EIPS/eip-6900.md | 100 +++++++++++++++++++---------------------------- 1 file changed, 41 insertions(+), 59 deletions(-) diff --git a/EIPS/eip-6900.md b/EIPS/eip-6900.md index 37dd66eef8fe0..4ab6f287ae044 100644 --- a/EIPS/eip-6900.md +++ b/EIPS/eip-6900.md @@ -52,7 +52,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S - **Execution functions** execute any custom logic allowed by the account. - **Hooks** execute custom logic and checks before and/or after an execution 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. The function may have any function name, and MUST take in the parameters `(UserOperation calldata, bytes32)`, representing the user operation and user operation hash. It MUST return `(uint256)`, representing packed validation data for `authorizer`, `validUntil`, and `validAfter`. + - **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. - An **execution function** is a smart contract function that defines the main execution step of a function for a **modular account**. - The **standard execute functions** are two specific execution functions that are implemented natively by the modular account, and not on a plugin. These allow for open-ended execution. @@ -64,6 +64,16 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S - **Associated function** refers to either a validation function or a hook. - A **plugin** is a deployed smart contract that hosts any amount of the above three kinds of modular functions: execution functions, validation functions, or hooks. +### Plugin Function Signatures + +The plugin function types specified above MUST have the following function signatures: + +- **User Operation Validator** and **Pre User Operation Validation** functions: `function(UserOperation calldata, bytes32) external returns (uint256)`. The parameters sent by the account MUST be the user operation and user operation hash. The return value MUST represent packed validation data for `authorizer`, `validUntil`, and `validAfter`. The packing order MUST be `validAfter` in the first 6 bytes, `validUntil` in the next 6 bytes, and `authorizer` in the last 20 bytes. +- **Runtime Validator** and **Pre Runtime Validation** functions: `function(address, uint256, bytes calldata) external returns (bool)`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. The return value MUST be `true` if the call should continue, and `false` if the call should terminate immediately after runtime validation. To indicate that the entire call should revert, the function MUST revert. +- **Pre Execution Hook** functions: `function(address, uint256, bytes calldata) external returns (bool, bytes memory)`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. The first return value MUST be `true` if the call should continue, and `false` if the call should terminate immediately after runtime validation. To indicate that the entire call should revert, the function MUST revert. The second return value MUST contain any context to pass to a post execution hook, if present. An empty bytes array MAY be returned. +- **Post Execution Hook** functions: `function(bytes calldata) external`. The parameter sent by the account MUST be the context returned by the associated pre execution hook. To indicate that the entire call should revert, the function MUST revert. +- **Execution** functions may have any function signature. + ### Overview A modular account handles two kinds of calls: either from the `Entrypoint` through ERC-4337, or through direct calls from externally owned accounts (EOAs) and other smart contracts. This standard supports both use cases. @@ -80,12 +90,18 @@ Modular Smart Contract Accounts MUST implement the `IAccount` interface from [ER #### Common types -The following types are used by both of the following interfaces. Implementors MAY use the elementary value type instead of the type alias. +The following types are common across the following interfaces. Implementors MAY use the elementary value type instead of the type alias. ```solidity type FunctionReference is bytes24; type HookGroupId is uint32; + +struct Execution { + address target; + uint256 value; + bytes data; +} ``` Variables of the type `FunctionReference` MUST be interpreted as an address in the first 20 bytes and a function selector in the remaining 4 bytes. @@ -146,8 +162,7 @@ interface IPluginUpdate { ExecutionUpdate[] calldata executionUpdates, HookUpdate[] calldata hookUpdates, HookGroupUpdate[] calldata hookGroupUpdates, - address init, - bytes calldata callData + Execution[] calldata initializationCalls ) external; } ``` @@ -192,20 +207,7 @@ Standard execution interface. Modular Smart Contract Accounts MUST implement thi ```solidity interface IStandardExecutor { - enum ExecutionMode { - CALL, - DELEGATECALL, - STATICCALL - } - - struct Execution { - address target; - uint256 value; - bytes data; - ExecutionMode mode; - } - - function execute(address dest, uint256 value, bytes calldata func, ExecutionMode mode, FunctionReference validator) + function execute(address target, uint256 value, bytes calldata data, FunctionReference validator) external payable; @@ -217,26 +219,32 @@ interface IStandardExecutor { #### Calls to `updatePlugins` -The function `updatePlugins` takes in arrays of execution updates, hook updates, and hook group updates to perform. It also takes in an optional initialization function. The function MUST perform the update operation sequentially, then, if the address provided in `init` is not `address(0)`, MUST execute `init` with the calldata `callData` through a `delegatecall`. +The function `updatePlugins` takes in arrays of execution updates, hook updates, and hook group updates to perform. It also takes in an optional array of initialization calls. The function MUST perform the update operation sequentially. Then, for each sequential member of the `initializationCalls` array, the MSCA MUST perform a `call` operation towards the specified `target` address with the specified `value` and `callData`. > **⚠️ The ability to update a plugin is very powerful. The security of the updatePlugins determines the security of the account. It is critical for modular account implementers to make sure updatePlugins has the proper security consideration and access control in place.** #### Calls to `validateUserOp` -When the function `validateUserOp` is called on modular account by the `EntryPoint`, it MUST find the user operation validator defined for the selector in `userOp.callData`, which is in the first four bytes. If there is no function defined for the selector, or if `userOp.callData.length < 4`, then execution MUST revert. Otherwise, the MSCA MUST execute the validator function with the user operation and its hash as parameters using the `call` opcode. The returned validation data from the user operation validator MUST be returned by `validateUserOp`. +When the function `validateUserOp` is called on modular account by the `EntryPoint`, it MUST find the user operation validator defined for the selector in `userOp.callData`, which is in the first four bytes. If there is no function defined for the selector, or if `userOp.callData.length < 4`, then execution MUST revert. + +If the execution selector has associated hook groups with pre user operation validation hooks, then those hooks MUST be run sequentially. If any revert, the outer call MUST revert. If any return an `authorizer` value other than 0 or 1, execution MUST revert. If any return an `authorizer` value of 1, indicating an invalid signature, the returned validation data of the outer call must also be 1. If any return time-bounded validation by specifying either a `validUntil` or `validBefore` value, the resulting validation data MUST be the intersection of all time bounds provided. -If the execution selector has associated hook groups with pre user operation validation hooks, then those hooks MUST be run sequentially. If any revert or return false, the outer call MUST revert. +If the call is to a standard execution function, then the modular account MUST verify that the provided `validator` in calldata has previously been associated with either of the standard execution functions. If it was previously added, the specified user operation validator MUST be run. -If the call is to a standard execution function, then the modular account must verify that the provided `validator` in calldata has previously been associated with either of the standard execution functions. If it was previously added, the specified user operation validator MUST be run. +Then, the MSCA MUST execute the validator function with the user operation and its hash as parameters using the `call` opcode. The returned validation data from the user operation validator MUST be updated, if necessary, by the return values of any pre user operation validation hooks, then returned by `validateUserOp`. #### Calls to execution functions -When a function other than a natively defined function is called on an MSCA, it MUST find the plugin configuration for the corresponding selector added via `updatePlugins`. If no corresponding plugin is found, the MSCA MUST revert. Otherwise, the MSCA MUST perform the following steps: +When a function other than a natively defined function is called on an MSCA, it MUST find the plugin configuration for the corresponding selector added via `updatePlugins`. If no corresponding plugin is found, the MSCA MUST revert. Otherwise, the following steps MUST be performed. -- If the call is not from the `EntryPoint`, then find an associated `runtimeValidator` function. If one does not exist, execution MUST revert. The modular account MUST execute all pre runtime validation hooks, then the runtime validator function, with the `call` opcode. All of these functions MUST receive the caller, value, and execution function’s calldata as parameters. If any of these functions revert, or return a boolean false, execution MUST revert. -- If there are pre execution hooks defined in the associated hook groups of the execution function, execute those hooks with the caller, value, and execution function’s calldata as parameters. If any of thee hooks returns data, it MUST be preserved until the call to the post execution hook. The operation must be done with the `call` opcode. +Alternatively, when the modular account natively implements functions in `IPluginUpdate` and `IStandardExecutor`, the same following steps MUST be performed. Other natively implemented functions MAY perform these steps. + +The steps to perform are: + +- If the call is not from the `EntryPoint`, then find an associated runtime validator function. If one does not exist, execution MUST revert. The modular account MUST execute all pre runtime validation hooks, then the runtime validator function, with the `call` opcode. All of these functions MUST receive the caller, value, and execution function’s calldata as parameters. If any of these functions revert, execution MUST revert. If any of these functions return a boolean false, execution MUST halt. +- If there are pre execution hooks defined in the associated hook groups of the execution function, execute those hooks with the caller, value, and execution function’s calldata as parameters. If any of thee hooks returns data, it MUST be preserved until the call to the post execution hook. The operation MUST be done with the `call` opcode. If any of these functions revert, execution MUST revert. If any of these functions return a boolean false, execution MUST halt. - Run the execution function. -- If any associated post execution hooks are defined, run the functions. If a pre execution hook in the same hook group returned data to the account, that data MUST be passed as a parameter to the post execution hook. The operation must be done with the `call` opcode. +- If any associated post execution hooks are defined, run the functions. If a pre execution hook in the same hook group returned data to the account, that data MUST be passed as a parameter to the post execution hook. The operation MUST be done with the `call` opcode. If any of these functions revert, execution MUST revert. > **⚠️ If the execution function does not have a definition for either pre runtime validation hooks, pre execution hooks or post execution hooks, the undefined functions will be skipped. The execution function will be run and it may change account state.** @@ -244,10 +252,10 @@ When a function other than a natively defined function is called on an MSCA, it When `updatePlugins` is called with `PluginAction.ADD`, the following MUST occur: -- Each execution selector must be added as a valid execution function, with the contract specified in `pluginAddress` as implementation contract to call to. -- Each validator function reference must be added to their parent execution function in the role specified by `validatorType`. -- Each hook update must add the hook type specified by `hookType` to the group specified by `hookGroupId`. If that hook type is already defined, the update MUST revert. -- Each hook group update must add that hook group to the execution selectors specified by `executionSelectors`. +- Each execution selector MUST be added as a valid execution function, with the contract specified in `pluginAddress` as implementation contract to call to. +- Each validator function reference MUST be added to their parent execution function in the role specified by `validatorType`. +- Each hook update MUST add the hook type specified by `hookType` to the group specified by `hookGroupId`. If that hook type is already defined, the update MUST revert. +- Each hook group update MUST add that hook group to the execution selectors specified by `executionSelectors`. Execution function selectors MUST be unique when added. @@ -255,41 +263,15 @@ When `updatePlugins` is called with `PluginAction.REPLACE`, each each execution When `updatePlugins` is called with `PluginAction.REMOVE`, execution function definitions and associated function definitions MUST be removed. -#### Plugin Functions - -Execution functions may have any function signature, but must be unique for the account. When added to an MSCA via `updatePlugins`, the function selector of the execution function will be mapped from the modular account to the plugin. - -User Operation Validation functions may have any function name, and MUST take in the parameters `(UserOperation calldata, bytes32)`, representing the user operation and the user operation hash. The functions MUST return `(uint256)`, representing packed validation data for `authorizer`, `validUntil`, and `validAfter`. - -Here is an example function signature of a conformant user operation validator function: - -```solidity -function validateSignature(UserOperation calldata userOp, bytes32 userOpHash) external returns (uint256 validationData); -``` - -Runtime Validation Functions may have any function name, and MUST take in the parameters `(address, uint256, bytes calldata)`. - -Here is an example function signature of a conformant runtime validator function: - -```solidity -function validateOwnership(address caller, uint256 value, bytes calldata) external; -``` - -Hooks MAY have any function name. -The pre user operation validation hook functions MUST take in the parameters `(bytes calldata callData, bytes calldata paymasterAndData)` and return `(bool)`. -The pre runtime validation hook functions MUST take in the parameters `(bytes calldata)` and return `(bool)`. -The pre execution hook functions MUST take in the parameters `(address, uint256, bytes calldata)` and return `(bytes calldata)`. -The post execution hook functions MUST take in the parameters `(bytes calldata)`. +When calling `updatePlugins`, the account MUST run the validators and hooks as they are specified before the operation is complete. Notably, the post execution hooks defined prior to the update must run after the update. ## Rationale ERC-4337 compatible accounts must implement the `IAccount` interface, which consists of only one method that bundles validation with execution: `validateUserOp`. A primary design rationale for this proposal is to extend the possible functions for a smart contract account beyond this single method by unbundling these and other functions, while retaining the benefits of account abstraction. -The diamond pattern of ERC-2535 is the logical starting point for achieving this extension into multiple functionality, given its suitability for implementing multiple execution calls to ERC-4337 compatible accounts from EntryPoint. It also meets our other primary design rationale of generalizability to calls to EOA/SC accounts. However, a strict diamond pattern is constrained by its inability to customize validation schemes and other logic linked to specific execution functions in the context of `validateUserOp`. - -This proposal includes several interfaces that build on ERC-4337 and is ispired by ERC-2535. First, we standardize a set of modular plugins that allow smart contract developers greater flexibility in bundling validation, execution and hook logic. We also propose interfaces like `IPluginUpdate` that take inspiration from the diamond standard, and provide methods for updating and querying execution functions, validation schemes, and hooks. +The function routing pattern of ERC-2535 is the logical starting point for achieving this extension into multi-functional accounts. It also meets our other primary design rationale of generalizing execution calls across multiple implementing contracts. However, a strict diamond pattern is constrained by its inability to customize validation schemes for specific execution functions in the context of `validateUserOp`, and its requirement of `delegatecall`. -The diamond standard's interfaces are not required or enforced by this standard. An MSCA implementation is considered compliant with this standard as long as it satisfies the interface requirements and expected behaviors. +This proposal includes several interfaces that build on ERC-4337 and are inspired by ERC-2535. First, we standardize a set of modular plugins that allow smart contract developers greater flexibility in bundling validation, execution and hook logic. We also propose interfaces like `IPluginUpdate` and `IPluginLoupe` that take inspiration from the diamond standard, and provide methods for updating and querying execution functions, validation functions, and hooks. ## Backwards Compatibility From 08b221d9065344ec016a1b0f723551f1c7376755 Mon Sep 17 00:00:00 2001 From: adam Date: Wed, 21 Jun 2023 21:12:39 -0400 Subject: [PATCH 02/11] update specification to prohibit pre user operation validation hooks from returning aggregators --- EIPS/eip-6900.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-6900.md b/EIPS/eip-6900.md index 4ab6f287ae044..53eb465c26adc 100644 --- a/EIPS/eip-6900.md +++ b/EIPS/eip-6900.md @@ -68,7 +68,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S The plugin function types specified above MUST have the following function signatures: -- **User Operation Validator** and **Pre User Operation Validation** functions: `function(UserOperation calldata, bytes32) external returns (uint256)`. The parameters sent by the account MUST be the user operation and user operation hash. The return value MUST represent packed validation data for `authorizer`, `validUntil`, and `validAfter`. The packing order MUST be `validAfter` in the first 6 bytes, `validUntil` in the next 6 bytes, and `authorizer` in the last 20 bytes. +- **User Operation Validator** and **Pre User Operation Validation** functions: `function(UserOperation calldata, bytes32) external returns (uint256)`. The parameters sent by the account MUST be the user operation and user operation hash. The return value MUST represent packed validation data for `authorizer`, `validUntil`, and `validAfter`. The packing order MUST be `validAfter` in the first 6 bytes, `validUntil` in the next 6 bytes, and `authorizer` in the last 20 bytes. **Pre User Operation Validation** MUST NOT send an `authorizer` value other than 0 or 1. - **Runtime Validator** and **Pre Runtime Validation** functions: `function(address, uint256, bytes calldata) external returns (bool)`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. The return value MUST be `true` if the call should continue, and `false` if the call should terminate immediately after runtime validation. To indicate that the entire call should revert, the function MUST revert. - **Pre Execution Hook** functions: `function(address, uint256, bytes calldata) external returns (bool, bytes memory)`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. The first return value MUST be `true` if the call should continue, and `false` if the call should terminate immediately after runtime validation. To indicate that the entire call should revert, the function MUST revert. The second return value MUST contain any context to pass to a post execution hook, if present. An empty bytes array MAY be returned. - **Post Execution Hook** functions: `function(bytes calldata) external`. The parameter sent by the account MUST be the context returned by the associated pre execution hook. To indicate that the entire call should revert, the function MUST revert. From 7a5f98f1d721c5085113b4779146972d7459d1c9 Mon Sep 17 00:00:00 2001 From: adam-alchemy <127769144+adam-alchemy@users.noreply.github.com> Date: Wed, 21 Jun 2023 18:55:30 -0700 Subject: [PATCH 03/11] Update EIPS/eip-6900.md Co-authored-by: Jay Paik --- EIPS/eip-6900.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-6900.md b/EIPS/eip-6900.md index 53eb465c26adc..72f8ead0ace8d 100644 --- a/EIPS/eip-6900.md +++ b/EIPS/eip-6900.md @@ -237,7 +237,7 @@ Then, the MSCA MUST execute the validator function with the user operation and i When a function other than a natively defined function is called on an MSCA, it MUST find the plugin configuration for the corresponding selector added via `updatePlugins`. If no corresponding plugin is found, the MSCA MUST revert. Otherwise, the following steps MUST be performed. -Alternatively, when the modular account natively implements functions in `IPluginUpdate` and `IStandardExecutor`, the same following steps MUST be performed. Other natively implemented functions MAY perform these steps. +Alternatively, when the modular account natively implements functions in `IPluginUpdate` and `IStandardExecutor`, the same following steps MUST be performed for those functions. Other natively implemented functions MAY perform these steps. The steps to perform are: From faa6d63e3678562c74d7e8c9692766430a29d284 Mon Sep 17 00:00:00 2001 From: adam Date: Thu, 22 Jun 2023 18:48:56 -0400 Subject: [PATCH 04/11] remove boolean halting --- EIPS/eip-6900.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-6900.md b/EIPS/eip-6900.md index 72f8ead0ace8d..02cf6221dfe42 100644 --- a/EIPS/eip-6900.md +++ b/EIPS/eip-6900.md @@ -69,8 +69,8 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S The plugin function types specified above MUST have the following function signatures: - **User Operation Validator** and **Pre User Operation Validation** functions: `function(UserOperation calldata, bytes32) external returns (uint256)`. The parameters sent by the account MUST be the user operation and user operation hash. The return value MUST represent packed validation data for `authorizer`, `validUntil`, and `validAfter`. The packing order MUST be `validAfter` in the first 6 bytes, `validUntil` in the next 6 bytes, and `authorizer` in the last 20 bytes. **Pre User Operation Validation** MUST NOT send an `authorizer` value other than 0 or 1. -- **Runtime Validator** and **Pre Runtime Validation** functions: `function(address, uint256, bytes calldata) external returns (bool)`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. The return value MUST be `true` if the call should continue, and `false` if the call should terminate immediately after runtime validation. To indicate that the entire call should revert, the function MUST revert. -- **Pre Execution Hook** functions: `function(address, uint256, bytes calldata) external returns (bool, bytes memory)`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. The first return value MUST be `true` if the call should continue, and `false` if the call should terminate immediately after runtime validation. To indicate that the entire call should revert, the function MUST revert. The second return value MUST contain any context to pass to a post execution hook, if present. An empty bytes array MAY be returned. +- **Runtime Validator** and **Pre Runtime Validation** functions: `function(address, uint256, bytes calldata) external`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. To indicate that the entire call should revert, the function MUST revert. +- **Pre Execution Hook** functions: `function(address, uint256, bytes calldata) external returns (bytes memory)`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. To indicate that the entire call should revert, the function MUST revert. The return value MUST contain any context to pass to a post execution hook, if present. An empty bytes array MAY be returned. - **Post Execution Hook** functions: `function(bytes calldata) external`. The parameter sent by the account MUST be the context returned by the associated pre execution hook. To indicate that the entire call should revert, the function MUST revert. - **Execution** functions may have any function signature. @@ -241,8 +241,8 @@ Alternatively, when the modular account natively implements functions in `IPlugi The steps to perform are: -- If the call is not from the `EntryPoint`, then find an associated runtime validator function. If one does not exist, execution MUST revert. The modular account MUST execute all pre runtime validation hooks, then the runtime validator function, with the `call` opcode. All of these functions MUST receive the caller, value, and execution function’s calldata as parameters. If any of these functions revert, execution MUST revert. If any of these functions return a boolean false, execution MUST halt. -- If there are pre execution hooks defined in the associated hook groups of the execution function, execute those hooks with the caller, value, and execution function’s calldata as parameters. If any of thee hooks returns data, it MUST be preserved until the call to the post execution hook. The operation MUST be done with the `call` opcode. If any of these functions revert, execution MUST revert. If any of these functions return a boolean false, execution MUST halt. +- If the call is not from the `EntryPoint`, then find an associated runtime validator function. If one does not exist, execution MUST revert. The modular account MUST execute all pre runtime validation hooks, then the runtime validator function, with the `call` opcode. All of these functions MUST receive the caller, value, and execution function’s calldata as parameters. If any of these functions revert, execution MUST revert. +- If there are pre execution hooks defined in the associated hook groups of the execution function, execute those hooks with the caller, value, and execution function’s calldata as parameters. If any of thee hooks returns data, it MUST be preserved until the call to the post execution hook. The operation MUST be done with the `call` opcode. If any of these functions revert, execution MUST revert. - Run the execution function. - If any associated post execution hooks are defined, run the functions. If a pre execution hook in the same hook group returned data to the account, that data MUST be passed as a parameter to the post execution hook. The operation MUST be done with the `call` opcode. If any of these functions revert, execution MUST revert. From 13d5c0195e30f89ea3f3d24ce3054a6802226069 Mon Sep 17 00:00:00 2001 From: adam Date: Thu, 22 Jun 2023 18:57:16 -0400 Subject: [PATCH 05/11] Adjust hook phrasing --- EIPS/eip-6900.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-6900.md b/EIPS/eip-6900.md index 02cf6221dfe42..7a2ae01a66197 100644 --- a/EIPS/eip-6900.md +++ b/EIPS/eip-6900.md @@ -68,10 +68,10 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S The plugin function types specified above MUST have the following function signatures: -- **User Operation Validator** and **Pre User Operation Validation** functions: `function(UserOperation calldata, bytes32) external returns (uint256)`. The parameters sent by the account MUST be the user operation and user operation hash. The return value MUST represent packed validation data for `authorizer`, `validUntil`, and `validAfter`. The packing order MUST be `validAfter` in the first 6 bytes, `validUntil` in the next 6 bytes, and `authorizer` in the last 20 bytes. **Pre User Operation Validation** MUST NOT send an `authorizer` value other than 0 or 1. -- **Runtime Validator** and **Pre Runtime Validation** functions: `function(address, uint256, bytes calldata) external`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. To indicate that the entire call should revert, the function MUST revert. -- **Pre Execution Hook** functions: `function(address, uint256, bytes calldata) external returns (bytes memory)`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. To indicate that the entire call should revert, the function MUST revert. The return value MUST contain any context to pass to a post execution hook, if present. An empty bytes array MAY be returned. -- **Post Execution Hook** functions: `function(bytes calldata) external`. The parameter sent by the account MUST be the context returned by the associated pre execution hook. To indicate that the entire call should revert, the function MUST revert. +- **User Operation Validator** functions and **Pre User Operation Validation Hooks**: `function(UserOperation calldata, bytes32) external returns (uint256)`. The parameters sent by the account MUST be the user operation and user operation hash. The return value MUST represent packed validation data for `authorizer`, `validUntil`, and `validAfter`. The packing order MUST be `validAfter` in the first 6 bytes, `validUntil` in the next 6 bytes, and `authorizer` in the last 20 bytes. **Pre User Operation Validation** MUST NOT send an `authorizer` value other than 0 or 1. +- **Runtime Validator** functions and **Pre Runtime Validation Hooks**: `function(address, uint256, bytes calldata) external`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. To indicate that the entire call should revert, the function MUST revert. +- **Pre Execution Hooks**: `function(address, uint256, bytes calldata) external returns (bytes memory)`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. To indicate that the entire call should revert, the function MUST revert. The return value MUST contain any context to pass to a post execution hook, if present. An empty bytes array MAY be returned. +- **Post Execution Hooks**: `function(bytes calldata) external`. The parameter sent by the account MUST be the context returned by the associated pre execution hook. To indicate that the entire call should revert, the function MUST revert. - **Execution** functions may have any function signature. ### Overview From b832df4657c21a8bed69fa6cef34e689f182bef4 Mon Sep 17 00:00:00 2001 From: adam Date: Fri, 23 Jun 2023 11:36:14 -0400 Subject: [PATCH 06/11] Updated diagram --- assets/eip-6900/MSCA_Two_Call_Paths_Diagram.svg | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/assets/eip-6900/MSCA_Two_Call_Paths_Diagram.svg b/assets/eip-6900/MSCA_Two_Call_Paths_Diagram.svg index 96d76a98747b0..e7ffec6210d58 100644 --- a/assets/eip-6900/MSCA_Two_Call_Paths_Diagram.svg +++ b/assets/eip-6900/MSCA_Two_Call_Paths_Diagram.svg @@ -1,4 +1,4 @@ - + @@ -12,5 +12,6 @@ src: url("https://excalidraw.com/Cascadia.woff2"); } + - SCAEntryPointEOA/SC callA.0B.1A.1A.2Step 1Step 2Step 3Step 4ACalls from Entrypoint (ERC-4337)BCalls from EOAs and other contractsB.2UserOpValidatorvalidateUserOpPre-UserOpValidate Hook(s)Execution FunctionPre-Execution Hook(s)Post-Execution Hook(s)A.3 B.3A.4 B.4fallback & standard executionfrom EntryPoint?RuntimeValidatorPre-RuntimeValidate Hook(s)noyesStep 5 \ No newline at end of file + SCAEntryPointA.1B.1A.2Step 1Step 2Step 3Step 4ACalls from Entrypoint (ERC-4337)BCalls from EOAs and other contractsUserOpValidatorvalidateUserOpPre-UserOpValidate Hook(s)Execution FunctionPre-Execution Hook(s)Post-Execution Hook(s)A.3 B.3A.4 B.4fallback & native functionsRuntimeValidatorPre-RuntimeValidate Hook(s)Step 5EOA / SCB.2 \ No newline at end of file From 9ea3f8dc29531a265fedeb557f62f661795e4a01 Mon Sep 17 00:00:00 2001 From: adam-alchemy <127769144+adam-alchemy@users.noreply.github.com> Date: Fri, 23 Jun 2023 08:37:39 -0700 Subject: [PATCH 07/11] Update EIPS/eip-6900.md Co-authored-by: Jay Paik --- EIPS/eip-6900.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-6900.md b/EIPS/eip-6900.md index 7a2ae01a66197..985d83ae5424f 100644 --- a/EIPS/eip-6900.md +++ b/EIPS/eip-6900.md @@ -68,7 +68,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S The plugin function types specified above MUST have the following function signatures: -- **User Operation Validator** functions and **Pre User Operation Validation Hooks**: `function(UserOperation calldata, bytes32) external returns (uint256)`. The parameters sent by the account MUST be the user operation and user operation hash. The return value MUST represent packed validation data for `authorizer`, `validUntil`, and `validAfter`. The packing order MUST be `validAfter` in the first 6 bytes, `validUntil` in the next 6 bytes, and `authorizer` in the last 20 bytes. **Pre User Operation Validation** MUST NOT send an `authorizer` value other than 0 or 1. +- **User Operation Validator** functions and **Pre User Operation Validation Hooks**: `function(UserOperation calldata, bytes32) external returns (uint256)`. The parameters sent by the account MUST be the user operation and user operation hash. The return value MUST represent packed validation data for `authorizer`, `validUntil`, and `validAfter`. The packing order MUST be `validAfter` in the first 6 bytes, `validUntil` in the next 6 bytes, and `authorizer` in the last 20 bytes. **Pre User Operation Validation Hooks** MUST NOT send an `authorizer` value other than 0 or 1. - **Runtime Validator** functions and **Pre Runtime Validation Hooks**: `function(address, uint256, bytes calldata) external`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. To indicate that the entire call should revert, the function MUST revert. - **Pre Execution Hooks**: `function(address, uint256, bytes calldata) external returns (bytes memory)`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. To indicate that the entire call should revert, the function MUST revert. The return value MUST contain any context to pass to a post execution hook, if present. An empty bytes array MAY be returned. - **Post Execution Hooks**: `function(bytes calldata) external`. The parameter sent by the account MUST be the context returned by the associated pre execution hook. To indicate that the entire call should revert, the function MUST revert. From c2015b4c87a5e3b2e3b98b04ed30afc3886eb183 Mon Sep 17 00:00:00 2001 From: adam-alchemy <127769144+adam-alchemy@users.noreply.github.com> Date: Fri, 23 Jun 2023 08:37:52 -0700 Subject: [PATCH 08/11] Update EIPS/eip-6900.md Co-authored-by: Jay Paik --- EIPS/eip-6900.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-6900.md b/EIPS/eip-6900.md index 985d83ae5424f..3450753729ceb 100644 --- a/EIPS/eip-6900.md +++ b/EIPS/eip-6900.md @@ -70,7 +70,7 @@ The plugin function types specified above MUST have the following function signa - **User Operation Validator** functions and **Pre User Operation Validation Hooks**: `function(UserOperation calldata, bytes32) external returns (uint256)`. The parameters sent by the account MUST be the user operation and user operation hash. The return value MUST represent packed validation data for `authorizer`, `validUntil`, and `validAfter`. The packing order MUST be `validAfter` in the first 6 bytes, `validUntil` in the next 6 bytes, and `authorizer` in the last 20 bytes. **Pre User Operation Validation Hooks** MUST NOT send an `authorizer` value other than 0 or 1. - **Runtime Validator** functions and **Pre Runtime Validation Hooks**: `function(address, uint256, bytes calldata) external`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. To indicate that the entire call should revert, the function MUST revert. -- **Pre Execution Hooks**: `function(address, uint256, bytes calldata) external returns (bytes memory)`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. To indicate that the entire call should revert, the function MUST revert. The return value MUST contain any context to pass to a post execution hook, if present. An empty bytes array MAY be returned. +- **Pre Execution Hooks**: `function(address, uint256, bytes calldata) external returns (bytes memory)`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. To indicate that the entire call should revert, the function MUST revert. The return value MUST contain any context to pass to a **Post Execution Hook**, if present. An empty bytes array MAY be returned. - **Post Execution Hooks**: `function(bytes calldata) external`. The parameter sent by the account MUST be the context returned by the associated pre execution hook. To indicate that the entire call should revert, the function MUST revert. - **Execution** functions may have any function signature. From 014c694e62a4931e2fb29cae209647696c624a10 Mon Sep 17 00:00:00 2001 From: adam-alchemy <127769144+adam-alchemy@users.noreply.github.com> Date: Fri, 23 Jun 2023 08:38:07 -0700 Subject: [PATCH 09/11] Update EIPS/eip-6900.md Co-authored-by: Jay Paik --- EIPS/eip-6900.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-6900.md b/EIPS/eip-6900.md index 3450753729ceb..8f93fb3c8496e 100644 --- a/EIPS/eip-6900.md +++ b/EIPS/eip-6900.md @@ -71,7 +71,7 @@ The plugin function types specified above MUST have the following function signa - **User Operation Validator** functions and **Pre User Operation Validation Hooks**: `function(UserOperation calldata, bytes32) external returns (uint256)`. The parameters sent by the account MUST be the user operation and user operation hash. The return value MUST represent packed validation data for `authorizer`, `validUntil`, and `validAfter`. The packing order MUST be `validAfter` in the first 6 bytes, `validUntil` in the next 6 bytes, and `authorizer` in the last 20 bytes. **Pre User Operation Validation Hooks** MUST NOT send an `authorizer` value other than 0 or 1. - **Runtime Validator** functions and **Pre Runtime Validation Hooks**: `function(address, uint256, bytes calldata) external`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. To indicate that the entire call should revert, the function MUST revert. - **Pre Execution Hooks**: `function(address, uint256, bytes calldata) external returns (bytes memory)`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. To indicate that the entire call should revert, the function MUST revert. The return value MUST contain any context to pass to a **Post Execution Hook**, if present. An empty bytes array MAY be returned. -- **Post Execution Hooks**: `function(bytes calldata) external`. The parameter sent by the account MUST be the context returned by the associated pre execution hook. To indicate that the entire call should revert, the function MUST revert. +- **Post Execution Hooks**: `function(bytes calldata) external`. The parameter sent by the account MUST be the context returned by the associated **Pre Execution Hook**. To indicate that the entire call should revert, the function MUST revert. - **Execution** functions may have any function signature. ### Overview From 0f711d3ea7d43446461838986df2cf8eb6de09c1 Mon Sep 17 00:00:00 2001 From: adam Date: Fri, 23 Jun 2023 11:38:46 -0400 Subject: [PATCH 10/11] Update send to return phrasing --- EIPS/eip-6900.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-6900.md b/EIPS/eip-6900.md index 8f93fb3c8496e..eaa42f56e403d 100644 --- a/EIPS/eip-6900.md +++ b/EIPS/eip-6900.md @@ -68,7 +68,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S The plugin function types specified above MUST have the following function signatures: -- **User Operation Validator** functions and **Pre User Operation Validation Hooks**: `function(UserOperation calldata, bytes32) external returns (uint256)`. The parameters sent by the account MUST be the user operation and user operation hash. The return value MUST represent packed validation data for `authorizer`, `validUntil`, and `validAfter`. The packing order MUST be `validAfter` in the first 6 bytes, `validUntil` in the next 6 bytes, and `authorizer` in the last 20 bytes. **Pre User Operation Validation Hooks** MUST NOT send an `authorizer` value other than 0 or 1. +- **User Operation Validator** functions and **Pre User Operation Validation Hooks**: `function(UserOperation calldata, bytes32) external returns (uint256)`. The parameters sent by the account MUST be the user operation and user operation hash. The return value MUST represent packed validation data for `authorizer`, `validUntil`, and `validAfter`. The packing order MUST be `validAfter` in the first 6 bytes, `validUntil` in the next 6 bytes, and `authorizer` in the last 20 bytes. **Pre User Operation Validation Hooks** MUST NOT return an `authorizer` value other than 0 or 1. - **Runtime Validator** functions and **Pre Runtime Validation Hooks**: `function(address, uint256, bytes calldata) external`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. To indicate that the entire call should revert, the function MUST revert. - **Pre Execution Hooks**: `function(address, uint256, bytes calldata) external returns (bytes memory)`. The parameters sent by the account MUST be the caller address, the call value, and the calldata sent. To indicate that the entire call should revert, the function MUST revert. The return value MUST contain any context to pass to a **Post Execution Hook**, if present. An empty bytes array MAY be returned. - **Post Execution Hooks**: `function(bytes calldata) external`. The parameter sent by the account MUST be the context returned by the associated **Pre Execution Hook**. To indicate that the entire call should revert, the function MUST revert. From b12284bf74a1042d37f9a8c794a83ca52ab6c7be Mon Sep 17 00:00:00 2001 From: adam Date: Fri, 23 Jun 2023 18:23:36 -0400 Subject: [PATCH 11/11] Diagram update --- assets/eip-6900/MSCA_Two_Call_Paths_Diagram.svg | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/assets/eip-6900/MSCA_Two_Call_Paths_Diagram.svg b/assets/eip-6900/MSCA_Two_Call_Paths_Diagram.svg index e7ffec6210d58..7b272a7f48a05 100644 --- a/assets/eip-6900/MSCA_Two_Call_Paths_Diagram.svg +++ b/assets/eip-6900/MSCA_Two_Call_Paths_Diagram.svg @@ -1,4 +1,4 @@ - + @@ -14,4 +14,4 @@ - SCAEntryPointA.1B.1A.2Step 1Step 2Step 3Step 4ACalls from Entrypoint (ERC-4337)BCalls from EOAs and other contractsUserOpValidatorvalidateUserOpPre-UserOpValidate Hook(s)Execution FunctionPre-Execution Hook(s)Post-Execution Hook(s)A.3 B.3A.4 B.4fallback & native functionsRuntimeValidatorPre-RuntimeValidate Hook(s)Step 5EOA / SCB.2 \ No newline at end of file + SCAEntryPointA.1B.1A.2Step 1Step 2Step 3Step 4ACalls from Entrypoint (ERC-4337)BCalls from EOAs and other contractsUser Operation ValidatorvalidateUserOpPre User Operation Validation Hook(s)Execution FunctionPre Execution Hook(s)Post Execution Hook(s)A.3 B.3A.4 B.4fallback & native functionsRuntime ValidatorPre Runtime Validation Hook(s)Step 5EOA / SCB.2 \ No newline at end of file