Skip to content

Commit

Permalink
f6a7434 (#1)
Browse files Browse the repository at this point in the history 
* update validation rules

* spellings

* merge changes from davidinsuomi:update-eip-4337-description-paymater

from external PR
eth-infinitism#378

* AA-222 add delegateAndRevert helper, to simulate code execution from entryPoint. (eth-infinitism#365)

Minimal "static" call from EntryPoint to simulate special cases. Equivalent to the EntryPointSimulations in purpose, but doesn't require stateOverride.
Executes code on behalf of entryPoint using delegateCall, and revert with the result

* TokenPaymaster "gas-calc" test (eth-infinitism#300)

* Initial commit for TokenPaymaster "gas-calc" test
* Deploy all TokenPaymaster contracts with Create2Factory for "gas-calc"
* Make TestPaymaster use postOp
* Storage-Optimization for TokenPaymaster
   - change gas and timestamps to 48 bits
   - change blanaces and multipliers to 128 bit
   - saves 10kgas (and since 10-op batch uses the same TokenPaymaster, the
* add initial balance to paymaster

* editorial changes by yoav

Co-authored-by: Yoav Weiss <[email protected]>

* review changes

* merge fixes

* more review fix

* Apply suggestions from code review

Co-authored-by: Yoav Weiss <[email protected]>

* make sure innerHandleOp gets enough gas. (eth-infinitism#401)

* make sure innerHandleOps gets enough gas.

UserOperation's call must receive at least callGasLimit.
If there isn't enough provided to handleOps, the bundle should revert.

* address yoav PR comments

* added EREP-015: paymaster opsSeen if failure caused by other entity

* Fixing reputation rules

* update ERCs (eth-infinitism#404)

* update ERCs

* Update erc/ERCS/erc-7562.md

Co-authored-by: Yoav Weiss <[email protected]>

* Fixing pr

* Update erc-7562.md

* Update erc-7562.md

* Fixing merge

* Update erc/ERCS/erc-7562.md

Co-authored-by: Yoav Weiss <[email protected]>

* Update erc-7562.md: fixed typo

* Update erc-7562.md (eth-infinitism#405)

---------

Co-authored-by: Dror Tirosh <[email protected]>
Co-authored-by: Alex Forshtat <[email protected]>
Co-authored-by: Yoav Weiss <[email protected]>
Co-authored-by: shahafn <[email protected]>
  • Loading branch information
@DemonBarber1020 @drortirosh
@forshtat @yoavw @shahafn
5 people authored Aug 23, 2024
1 parent 5a01d0b commit efff7a6
Show file tree
Hide file tree
Showing 2 changed files with 214 additions and 153 deletions.
41 changes: 27 additions & 14 deletions erc/ERCS/erc-4337.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ status: Draft
type: Standards Track
category: ERC
created: 2021-09-29
requires: eip-aa-rules
requires: 7562
---

## Abstract
Expand All @@ -29,8 +29,8 @@ This proposal takes a different approach, avoiding any adjustments to the consen
* **Do not require any Ethereum consensus changes**: Ethereum consensus layer development is focusing on the merge and later on scalability-oriented features, and there may not be any opportunity for further protocol changes for a long time. Hence, to increase the chance of faster adoption, this proposal avoids Ethereum consensus changes.
* **Try to support other use cases**
* Privacy-preserving applications
* Atomic multi-operations (similar goal to [EIP-3074](./eip-3074.md))
* Pay tx fees with [ERC-20](./eip-20.md) tokens, allow developers to pay fees for their users, and [EIP-3074](./eip-3074.md)-like **sponsored transaction** use cases more generally
* Atomic multi-operations (similar goal to [EIP-3074])
* Pay tx fees with [ERC-20](./erc-20.md) tokens, allow developers to pay fees for their users, and [EIP-3074]-like **sponsored transaction** use cases more generally
* Support aggregated signature (e.g. BLS)

## Specification
Expand Down Expand Up @@ -245,13 +245,13 @@ A node/bundler SHOULD drop (not add to the mempool) a `UserOperation` that fails

### Extension: paymasters

We extend the entry point logic to support **paymasters** that can sponsor transactions for other users. This feature can be used to allow application developers to subsidize fees for their users, allow users to pay fees with [ERC-20](./eip-20.md) tokens and many other use cases. When the paymasterAndData field in the UserOp is not empty, the entry point implements a different flow for that UserOperation:
We extend the entry point logic to support **paymasters** that can sponsor transactions for other users. This feature can be used to allow application developers to subsidize fees for their users, allow users to pay fees with [ERC-20](./erc-20.md) tokens and many other use cases. When the paymasterAndData field in the UserOp is not empty, the entry point implements a different flow for that UserOperation:

![](../assets/erc-4337/bundle-seq-pm.svg)

During the verification loop, in addition to calling `validateUserOp`, the `handleOps` execution also must check that the paymaster has enough ETH deposited with the entry point to pay for the operation, and then call `validatePaymasterUserOp` on the paymaster to verify that the paymaster is willing to pay for the operation. Note that in this case, the `validateUserOp` is called with a `missingAccountFunds` of 0 to reflect that the account's deposit is not used for payment for this userOp.

If the paymaster's validatePaymasterUserOp returns a "context", then `handleOps` must call `postOp` on the paymaster after making the main execution call. It must guarantee the execution of `postOp`, by making the main execution inside an inner call context, and if the inner call context reverts attempting to call `postOp` again in an outer call context.
If the paymaster's validatePaymasterUserOp returns a "context", then `handleOps` must call `postOp` on the paymaster after making the main execution call.

Maliciously crafted paymasters _can_ DoS the system. To prevent this, we use a reputation system. paymaster must either limit its storage usage, or have a stake. see the [reputation, throttling and banning section](#reputation-scoring-and-throttlingbanning-for-global-entities) for details.

Expand Down Expand Up @@ -385,7 +385,7 @@ A node MAY drop a UserOperation if it expires too soon (e.g. wouldn't make it to
If the `ValidationResult` includes `sigFail`, the client SHOULD drop the `UserOperation`.

In order to prevent DoS attack on bundlers, they must make sure the validation methods above pass the validation rules, which constraint their usage of opcodes and storage.
For the complete procedure see [eip-aa-validation-rules](./eip-aa-rules.md)
For the complete procedure see [ERC-7562](./erc-7562.md)

#### Alternative Mempools

Expand All @@ -396,7 +396,7 @@ A bundler cannot simply "whitelist" request from a specific paymaster: if that p
bundlers, then its support will be sporadic at best.
Instead, we introduce the term "alternate mempool": a modified validation rules, and procedure of propagating them to other bundlers.

The procedure of using alternate mempools is defined in ../eip-aa-rules.md#Alt-mempools-rules
The procedure of using alternate mempools is defined in [ERC-7562](./erc-7562.md#Alt-mempools-rules)

### Bundling

Expand Down Expand Up @@ -434,6 +434,21 @@ Otherwise, attackers may be able to use the banned opcodes to detect running on-

When a bundler includes a bundle in a block it must ensure that earlier transactions in the block don't make any UserOperation fail. It should either use access lists to prevent conflicts, or place the bundle as the first transaction in the block.


## Rationale

The main challenge with a purely smart contract wallet based account abstraction system is DoS safety: how can a block builder including an operation make sure that it will actually pay fees, without having to first execute the entire operation? Requiring the block builder to execute the entire operation opens a DoS attack vector, as an attacker could easily send many operations that pretend to pay a fee but then revert at the last moment after a long execution. Similarly, to prevent attackers from cheaply clogging the mempool, nodes in the P2P network need to check if an operation will pay a fee before they are willing to forward it.

The first step is clean separation between validation (acceptance of UserOperation, and acceptance to pay) and execution.
In this proposal, we expect accounts to have a `validateUserOp` method that takes as input a `UserOperation`, and verify the signature and pay the fee.
Only if this method returns successfully, the execution will happen.

The entry point-based approach allows for a clean separation between verification and execution, and keeps accounts' logic simple. It enforces the simple rule that only after validation is successful (and the UserOp can pay), the execution is done, and also guarantees the fee payment.

The last step is protecting the bundlers from denial-of-service attacks by a mass number of UserOperation that appear to be valid (and pay) but that eventually revert, and thus block the bundler from processing valid UserOperations.
For this purpose, the bundler requires a set of [restrictions on the validation function](./erc-7526.md), to prevent such denial-of-service attacks.


### Reputation scoring and throttling/banning for global entities

#### Reputation Rationale.
Expand All @@ -453,12 +468,10 @@ The stake value is not enforced on-chain, but specifically by each node while si

### Paymasters

Paymasters facilitate transaction sponsorship, allowing third-party-designed mechanisms to pay for transactions. Many of these mechanisms _could_ be done by having the paymaster wrap a `UserOperation` with their own, but there are some important fundamental limitations to that approach:

* No possibility for "passive" paymasters (eg. that accept fees in some ERC-20 token at an exchange rate pulled from an on-chain DEX)
* Paymasters run the risk of getting griefed, as users could send ops that appear to pay the paymaster but then change their behavior after a block
Paymaster contracts allow abstraction of gas: having a contract, that is not the sender of the transaction, pay for the transaction fees.

The paymaster scheme allows a contract to passively pay on users' behalf under arbitrary conditions. It even allows ERC-20 token paymasters to secure a guarantee that they would only need to pay if the user pays them: the paymaster contract can check that there is sufficient approved ERC-20 balance in the `validatePaymasterUserOp` method, and then extract it with `transferFrom` in the `postOp` call; if the op itself transfers out or de-approves too much of the ERC-20s, the inner `postOp` will fail and revert the execution and the outer `postOp` can extract payment (note that because of storage access restrictions the ERC-20 would need to be a wrapper defined within the paymaster itself).
Paymaster architecture allows them to follow the model of "pre-charge, and later refund".
E.g. a token-paymaster may pre-charge the user with the max possible price of the transaction, and refund the user with the excess afterwards.

### First-time account creation

Expand Down Expand Up @@ -939,15 +952,15 @@ Assume the given UserOperations all pass validation (without actually validating

## Backwards Compatibility

This EIP does not change the consensus layer, so there are no backwards compatibility issues for Ethereum as a whole. Unfortunately it is not easily compatible with pre-[ERC-4337](./eip-4337.md) accounts, because those accounts do not have a `validateUserOp` function. If the account has a function for authorizing a trusted op submitter, then this could be fixed by creating an [ERC-4337](./eip-4337.md) compatible account that re-implements the verification logic as a wrapper and setting it to be the original account's trusted op submitter.
This ERC does not change the consensus layer, so there are no backwards compatibility issues for Ethereum as a whole. Unfortunately it is not easily compatible with pre-[ERC-4337](./eip-4337.md) accounts, because those accounts do not have a `validateUserOp` function. If the account has a function for authorizing a trusted op submitter, then this could be fixed by creating an [ERC-4337](./eip-4337.md) compatible account that re-implements the verification logic as a wrapper and setting it to be the original account's trusted op submitter.

## Reference Implementation

See `https://github.com/eth-infinitism/account-abstraction/tree/main/contracts`

## Security Considerations

The entry point contract will need to be very heavily audited and formally verified, because it will serve as a central trust point for _all_ [ERC-4337](./eip-4337.md). In total, this architecture reduces auditing and formal verification load for the ecosystem, because the amount of work that individual _accounts_ have to do becomes much smaller (they need only verify the `validateUserOp` function and its "check signature and pay fees" logic) and check that other functions are `msg.sender == ENTRY_POINT` gated (perhaps also allowing `msg.sender == self`), but it is nevertheless the case that this is done precisely by concentrating security risk in the entry point contract that needs to be verified to be very robust.
The entry point contract will need to be very heavily audited and formally verified, because it will serve as a central trust point for _all_ [ERC-4337]. In total, this architecture reduces auditing and formal verification load for the ecosystem, because the amount of work that individual _accounts_ have to do becomes much smaller (they need only verify the `validateUserOp` function and its "check signature and pay fees" logic) and check that other functions are `msg.sender == ENTRY_POINT` gated (perhaps also allowing `msg.sender == self`), but it is nevertheless the case that this is done precisely by concentrating security risk in the entry point contract that needs to be verified to be very robust.

Verification would need to cover two primary claims (not including claims needed to protect paymasters, and claims needed to establish p2p-level DoS resistance):

Expand Down
Loading

0 comments on commit efff7a6

Please sign in to comment.