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.

Sign up for GitHub

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

Clarify restricted access on UserOp validation... #35

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Clarify restricted access on UserOp validation... #35

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8cfff61
Clarify restricted access on UserOp validation...
NiloCK Oct 23, 2024
b3c837e
Clarify restricted access on UserOp validation...
NiloCK Oct 23, 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
4 changes: 2 additions & 2 deletions pages/docs/bundlers/running-a-bundler.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,9 +13,9 @@ If the UserOperation object passes these sanity checks, the bundler must next ru

## Simulation

In order to add a `UserOperation` into the UserOp mempool (and later to add it into a bundle) we need to "simulate" its validation to make sure it is valid, and that it is capable of paying for its own execution. In addition, we need to verify that the same will hold true when executed on-chain. For this purpose, a `UserOperation` is not allowed to access any information that might change between simulation and execution, such as current block time, number, hash etc.
In order to add a `UserOperation` into the UserOp mempool (and later to add it into a bundle) we need to "simulate" its validation to make sure it is valid, and that it is capable of paying for its own execution. In addition, we need to verify that the same will hold true when executed on-chain. For this purpose, the `validateUserOp()` function of a `UserOperation`'s `sender` contract is not allowed to access any information that might change between simulation and execution, such as current block time, number, hash etc.

In addition, a `UserOperation` is only allowed to access data related to this `sender` address: Multiple `UserOperations` should not access the same storage, so that it is impossible to invalidate a large number of `UserOperations` with a single state change.
In addition, validation of a `UserOperation` is only allowed to access data related to this `sender` address: Multiple `UserOperations` should not access the same storage, so that it is impossible to invalidate a large number of `UserOperations` with a single state change.

There are 3 special contracts that interact with the account: the factory (`initCode`) that deploys the contract, the paymaster that can pay for the gas, and signature aggregator. Each of these contracts is also restricted in its storage access, to make sure `UserOperation` validations are isolated.

Expand Down