Untitled - HackMD

2021/07/28 01:36:54

Yes. It would be useful to simulate the op by wrapping it in a singleton transaction containing just this op, then perform eth_call on that transaction and return that. (Edited)

Dror Tirosh

2021/08/11 14:49:30

if initCode exists, then create the wallet (and fail if it already exists) (Edited)

Dror Tirosh

2021/08/11 14:50:18

validator's API is `simulateOp`. The _validatePrepayment is an internal function. (Edited)

Dror Tirosh

2021/08/11 14:51:40

using zero-address as sender (so no-one can call it to actually execute anything. _validatePrepayment is called by handleOps to perform actual prepayment.) (Edited)

Dror Tirosh

2021/08/11 14:53:11

by calling the simulateOp, the bundler checks that .. (Edited)

Dror Tirosh

2021/08/12 10:09:41

maxPriorityFeePerGas is the maximum priority fee the wallet is williing to pay for (Edited)

Dror Tirosh

2021/08/12 10:18:27

its zero prefund, not zero gasprice. the struct itself is passed unmodified (since the wallet has to check the signature) the wallet has to look at the "paymaster" field, and not pay in case it is nonzero. The validation would fail if the wallet doesn't pay if it shouldn't. (Edited)

Dror Tirosh

2021/08/12 10:18:59

paymaster (Edited)

Dror Tirosh

2021/08/12 10:21:16

1. the miner probably can see the TX would revert before including it on chain, and can re-build the block without it. 2. to prevent this DoS, the miner throttle down this paymaster for 1 hour. Since the paymaster needs a stake, even this attack is very expensive. (Edited)

Dror Tirosh

2021/08/12 10:31:10

verificationAccessList is a complex structure, not a simple array more like: List<Tuple<address,List<bytes32>> (Edited)

Dror Tirosh

2021/08/12 10:33:54

AFAIK, it will be added only after running the simulation the first time (and validating the access list too) (Edited)

Namra Patel

2021/08/12 22:44:16

@dror That's right! If you look at the section just above this one, "Simulating UserOperations" I just added a sentence that should make it more clear that the process is as follows: Op received -> simulated -> added to SimulatedUserOperationPool if success, deleted if failure -> SimulatedUserOperation is validated -> if success, added to UserOperationPool, deleted if failure (Edited)

Nicolas Laurent

2021/08/16 16:27:49

This feels rather limiting. Does the access list also apply to the paymaster's verification function? Wouldn't, for instance, checking the DAI or USDC balance for two users prevent the inclusion of both transactions in the same block? Maybe it doesn't apply to paymasters, but the paymaster reputation system incentivizes paymasters to make sure the transaction is included anyhow? (Edited)

Yoav Weiss

2021/08/30 00:37:10

Not just forbidden opcodes. For v1 we're also enforcing a client policy where no storage should be accessed outside of the wallet contract itself (in the simulateWalletValidation call) and no storage access outside of the paymaster contract (in the simulatePaymasterValidation call). This can be enforced by inspecting the created access-list and ensuring that all SLOAD/SSTORE opcodes were in the context of the contract itself. (Edited)

Yoav Weiss

2021/08/30 00:38:40

I think this only happens on mining nodes, not for every node. A non-miner will only forward the op and save some metadata for preventing re-forwarding. It never resimulates and therefore has no use for the access-list after it was verified not to contain illegal accesses. (Edited)

Yoav Weiss

2021/08/30 00:40:34

Only in mining nodes, where bundling takes place (or non-mining nodes that act as bundlers, such as the Flashbots-based bundler we're starting with) (Edited)

Dror Tirosh

2021/08/31 08:22:20

Note that this is an optimization: a miner MAY always re-simulate userOp before inclusion in a block, and doesn't have to maintain these access-lists. At most, this doubles the total # of simulation. (Edited)

Guest Haynes2021/09/21 07:24:47

My gut says that this should be a discriminated union of types both for future compatibility (e.g., cancellation transactions) and to separate contract deployments from exeuctions. (Edited)

Micah

2021/09/21 07:52:41

Consider renaming `paymaster` to `payer` or `sponsor` for a bit more clarity on the role. Also, might be good to rename `signature` to `payerSignature` or `sponsorSignature` or whatever as appropriate to make it clear who is signing the transcation. (Edited)

Dror Tirosh

2021/09/22 19:48:09

it is important that this function verifies the caller to be the singleton (that is, payForSelfOp succeeded) (Edited)

Deprecated. The content now lives at https://github.com/ethereum/EIPs/pull/4337