Add ERC: Modular Accounts with Delegated Validation

ERCS/erc-7582.md

@@ -0,0 +1,100 @@
+---
+eip: 7582
+title: Modular Accounts with Delegated Validation
+description: Extends ERC-4337 interface with nonce-based plugins
+author: Shivanshi Tyagi (@nerderlyne), Ross Campbell (@z0r0z)
+discussions-to: https://ethereum-magicians.org/t/erc-7582-modular-accounts-with-delegated-validation/17640
+status: Draft
+type: Standards Track
+category: ERC
+created: 2023-12-25
+requires: 4337
+---
+
+## Abstract
+
+This proposal standardizes a method for adding plugins and composable logic to smart contract accounts built on existing interfaces like [ERC-4337](./eip-4337.md) (e.g., ERC-4337's `IAccount`). Specifically, by formalizing how applications can use the ERC-4337 Entry Point `NonceManager` and the emission of the `IEntryPoint` `UserOperationEvent` to account for plugin interactions, as well, as how to extract designated validators (in this case, by means of `IAccount`'s `validateUserOp`), accounts can specify how they call plugin contracts and grant special executory access for more advanced operations. Furthermore, this minimalist plugin approach is developer-friendly and complimentary to existing account abstraction standards by not requiring any additional functions for contracts that follow the `IAccount` interface (itself minimalist in only specifying one function, `validateUserOp`).
+
+## Motivation
+
+Smart contract accounts (contract accounts) are a powerful tool for managing digital assets and executing transactions by allowing users to program their interactions with blockchains. However, they are often limited in their functionality and flexibility without sufficient consensus around secure abstraction designs (albeit, the adoption of ERC-4337 is the preferred path of this proposal). For example, contract accounts are often unable to support social recovery, payment schedules, and other features that are common in traditional financial systems without efficient and predictable schemes to delegate execution and other access rights to approximate the UX of custodial and more specialized applications.
+
+Account abstraction standards like ERC-4337 have achieved simplification of many core contract account concerns such as transaction fee payments, but to fully leverage the expressive capability of these systems to accomplish user intents, simple methods to delegate contract account access and validation to other contracts would aid their UX and extend the benefits of centering operations around the Entry Point.
+
+While the `IAccount` interface from ERC-4337 does not specify a way to add custom validation logic to contract accounts to support plugins and similar extensions without upgrades or migrations, it nevertheless contains sufficient information to do so efficiently. This proposal therefore offers a method for adding plugins and other composable validation logic to smart contract accounts built on existing interfaces with singleton nonce-tracking like ERC-4337's `IAccount` and `NonceManager`.
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+![diagram showing basic 7582 flow](../assets/eip-7582/base-flow.svg)
+
+We leverage the key in ERC-4337 semi-abstracted nonce as the pointer to `validator` address. If a non-sequential key (`>type(uint64).max`) is used as an ERC-4337 Entry Point `UserOperation` (userOp) `nonce`, the `validateUserOp` function in the `sender` contract account MUST extract the validator contract address paired to this key from storage. If the validator contract address is found (i.e., no null return), the ERC7582 contract account MUST forward the userOp calldata to the validator. This calldata SHOULD be the entire userOp. In response to this delegated validation, the validator contract MUST return the ERC-4337 `validationData`, and the ERC7582 `sender` account MUST return this as the `validationData` to the Entry Point. 
+
+In all of the above validation steps, the validator contract MUST respect the ERC-4337 Entry Point conventions. Note, that while validator key data might be included elsewhere in a `UserOperation` to achieve similar contract account modularity, for example, by packing this data into the `signature` field, this proposal opts to repurpose `nonce` for this pointer to minimize calldata costs and to benefit from the EntryPoint's `getNonce` accounting, as well as the discoverability of user plugin interactions in the `UserOperationEvent` which exposes `nonce` but not other userOp data.
+
+ERC-4337 references:
+
+[UserOperation](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/interfaces/UserOperation.sol):
+
+```solidity
+    struct UserOperation {
+        address sender; /*contract account*/
+        uint256 nonce; /*validator data*/
+        bytes initCode;
+        bytes callData;
+        uint256 callGasLimit;
+        uint256 verificationGasLimit;
+        uint256 preVerificationGas;
+        uint256 maxFeePerGas;
+        uint256 maxPriorityFeePerGas;
+        bytes paymasterAndData;
+        bytes signature;
+    }
+```
+
+[`IAccount`](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/interfaces/IAccount.sol):
+
+```solidity
+    function validateUserOp(
+        UserOperation calldata userOp, /*userOp.nonce: validator data*/
+        bytes32 userOpHash,
+        uint256 missingAccountFunds
+    ) external returns (uint256 validationData);
+```
+
+[`IEntryPoint`](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/interfaces/IEntryPoint.sol):
+
+```solidity
+    event UserOperationEvent(
+        bytes32 indexed userOpHash,
+        address indexed sender,
+        address indexed paymaster,
+        uint256 nonce, /*validator data*/
+        bool success,
+        uint256 actualGasCost,
+        uint256 actualGasUsed
+    );
+```
+
+[NonceManager](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/core/NonceManager.sol)
+
+```solidity
+    function getNonce(address sender, uint192 key /*validator data*/) external view returns (uint256 nonce);
+```
+
+## Backwards Compatibility
+
+No backward compatibility issues found.
+
+## Reference Implementation
+
+See `https://github.com/NaniDAO/7582-account`
+
+## Security Considerations
+
+As this proposal introduces no new functions and leaves implementation of the validator extraction method and approval logic open to developers, the surface for security issues is intentionally kept small. Nevertheless, specific validator use cases require further discussion and consideration of the overall ERC-4337 verification flow and its underlying security.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).