Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ERC: Validation Module Extension for ERC-7579 #666

Open
wants to merge 23 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
Show all changes
23 commits
Select commit Hold shift + click to select a range
4881e0c
feat: hook postCheck simplification
kopy-kat May 1, 2024
b44b676
Merge branch 'master' into master
kopy-kat Jun 14, 2024
9cda4d8
feat: add missing encoding specs
kopy-kat Jun 26, 2024
984f773
Merge branch 'ethereum:master' into master
kopy-kat Jun 26, 2024
f49fd3c
Merge branch 'ethereum:master' into master
kopy-kat Jul 5, 2024
102cf21
chore: remove unused reference
kopy-kat Jul 5, 2024
8c03d7d
updates regarding falback
livingrockrises Aug 10, 2024
cd1b0fe
respind to PR comments
livingrockrises Aug 13, 2024
96b9f22
Update ERCS/erc-7579.md
livingrockrises Aug 13, 2024
f8f618a
Update ERCS/erc-7579.md
livingrockrises Aug 13, 2024
9b79f3e
Update ERCS/erc-7579.md
livingrockrises Aug 13, 2024
9d34a08
Merge pull request #1 from livingrockrises/feat/erc7579-proposed-changes
kopy-kat Aug 13, 2024
1e2474d
add calltype for staticcall
livingrockrises Aug 16, 2024
e4656ea
Merge pull request #2 from livingrockrises/feat/erc7579-proposed-changes
kopy-kat Aug 16, 2024
7a06656
fix: typo
kopy-kat Aug 24, 2024
53ecd60
Merge branch 'master' into master
kopy-kat Aug 24, 2024
a2d1ad6
Merge pull request #3 from ethereum/master
kopy-kat Sep 2, 2024
ea926a9
Merge branch 'ethereum:master' into master
kopy-kat Sep 30, 2024
b709c4e
feat: first draft
kopy-kat Oct 4, 2024
55c941a
Merge branch 'master' into feat/module-types-extension
kopy-kat Oct 4, 2024
7483c2c
feat: add eip number and discussions to
kopy-kat Oct 5, 2024
3a5df64
Merge branch 'master' into feat/module-types-extension
kopy-kat Oct 5, 2024
0caea73
fix: discussions link and erc link
kopy-kat Oct 5, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
178 changes: 178 additions & 0 deletions ERCS/erc-7780.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,178 @@
---
eip: 7780
title: Validation Module Extension for ERC-7579
description: Introduces three new module types for signature validation and permissioning
author: zeroknots (@zeroknots), Konrad Kopp (@kopy-kat), Taek Lee (@leekt), Fil Makarov (@filmakarov)
discussions-to: https://ethereum-magicians.org/t/erc-7780-validation-module-extension-for-erc-7579/21273
status: Draft
type: Standards Track
category: ERC
created: 2024-10-01
requires: 7579
---

## Abstract

This proposal introduces three new module types on top of the existing modules described in [ERC-7579](./eip-7579). The modules are policy, signer and stateless validator. None of these modules are required to be implemented by accounts, but accounts can choose to implement them or other modules can choose to make use of them for additional composability.

Policy modules can be used to check what a UserOperation or action is trying to achieve and determine if this is allowed. Signer modules can be used to validate signatures on provided hashes. Stateless validators are modules that are used to both validate signatures and compare them to a calldata-provided data blob which could, for example, include owners to check signatures against.

## Motivation

The modules introduced by this proposal aim to create more composability around signature and permission verification.

Policy and signer modules allow an account to make direct use of such a permissioning logic rather than relying on external modules to handle this. This has the upside of lower gas cost but the downside of less flexibility for users and developers that use the account.

Stateless validators enable further composability around signature validation logic. In many cases, it does not make sense to re-write signature validation for new validators, but instead to use the existing ones. However, this is usually not possible since the validators rely on a stored configuration indexed by the `msg.sender`, which is expected to be an account. Stateless validators solve this problem by not relying on state to compare signature verficiation against, but instead to compare it against a calldata-provided argument.

## 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.

This standard introduces three new module types on top of the existing modules introduced by ERC-7579:

- Policy (type id: 5)
- Signer (type id: 6)
- Stateless Validator (type id: 7)

Note: A single module can be of multiple types.

### Policy

Policies MUST implement the `IModule` and the `IPolicy` interface and have module type id: `5`.

```solidity
interface IPolicy is IModule {

/**
* Checks a userOp to determine if it should be executed
* @param id The id of the policy
* @param userOp The user operation to check
* @return The validation data to return to the EntryPoint
*/
function checkUserOpPolicy(
bytes32 id,
PackedUserOperation calldata userOp
)
external
payable
virtual
returns (uint256);

/**
* Checks a signature to determine if it should be executed
* @param id The id of the policy
* @param sender The sender of the transaction
* @param hash The hash of the transaction
* @param sig The signature of the transaction
* @return The validation data to return to the EntryPoint
*/
function checkSignaturePolicy(
bytes32 id,
address sender,
bytes32 hash,
bytes calldata sig
)
external
view
virtual
returns (uint256);
}
```

### Signer

Signers MUST implement the `IModule` and the `ISigner` interface and have module type id: `6`.

```solidity
interface ISigner is IModule {

/**
* @dev Check the signature of a user operation
* @param id The id of the signer config
* @param userOp The user operation
* @param userOpHash The hash of the user operation
* @return The status of the signature check to return to the EntryPoint
*/
function checkUserOpSignature(
bytes32 id,
PackedUserOperation calldata userOp,
bytes32 userOpHash
)
external
payable
virtual
returns (uint256);

/**
* @dev Check an ERC-1271 signature
* @param id The id of the signer config
* @param sender The sender of the signature
* @param hash The hash to check against
* @param sig The signature to validate
* @return The ERC-1271 magic value if the signature is valid
*/
function checkSignature(
bytes32 id,
address sender,
bytes32 hash,
bytes calldata sig
)
external
view
virtual
returns (bytes4);
}
```

### Stateless Validator

Validators MUST implement the `IStatelessValidator` interface and have module type id: `7`. It is RECOMMENDED that all Validators (module type id `1`) also implement the Stateless Validator interface for additional composabillity.

```solidity
interface IStatelessValidator {

/**
* @dev Validates a signature given some data
* @param hash The data that was signed over
* @param signature The signature to verify
* @param data The data to validate the verified signature agains
*
* MUST validate that the signature is a valid signature of the hash
* MUST compare the validated signature against the data provided
* MUST return true if the signature is valid and false otherwise
*/
function validateSignatureWithData(
bytes32 hash,
bytes calldata signature,
bytes calldata data
)
external
view
returns (bool);

/**
* @dev Returns boolean value if module is a certain type
* @param moduleTypeId the module type ID according the ERC-7579 spec
*
* MUST return true if the module is of the given type and false otherwise
*/
function isModuleType(uint256 moduleTypeId) external view returns (bool);
}
```

## Rationale

TBD

## Backwards Compatibility

No backward compatibility issues found.

## Security Considerations

No security considerations found.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).
Loading