Alchemy Light Account

Before a bundler submits the set of bundled user operations as a transaction to the entry point, they (again) simulate the validation to reduce the likelihood of performing on-chain, failing operation validations. The integration with `ERC-1271` signature-validating smart contracts creates an (optional) dependency on an external smart contract that can theoretically be shared between many accounts. During the simulation, i.e. during the `validateOps()` function calls, certain opcodes are banned to make validation almost stateless, with the only exception being storage that is directly linked to the validated account's address. However, during experiments with a local setup including ethinfinitism's [bundler implementation](https://github.com/eth-infinitism/bundler), we found that the validation would not revert if these verifying smart contracts make use of the `SELFDESTRUCT` opcode outside of the `validateOp()` function flow. This is important as a self-destruct on such a shared verifying `ERC-1271` smart contract would invalidate the validations of potentially many accounts at once, without any form of on-chain storage manipulation directly related to the addresses of these accounts. So if an attacker would front-run the block inclusion of a bundle with a self destruct of a contract that is used in many of the bundled user operations as the verifying contract, the bundler could have many failing on-chain validations, causing a financial loss to the bundler. Following the possibility of the `SELFDESTRUCT` opcode, the issues could be made worse in the following scenario. If the contract registered as the `owner` in many accounts was deployed via `CREATE` by an intermediary contract that was instantiated via `CREATE2`, a metamorphic contract attack would be possible, similar to the recent Tornado Cash exploit, where the verifying smart contract is replaced with a contract with arbitrary code. A possible attack vector here would be to replace the `validateSignature()` function with a gas-consuming function that performs a series of costly memory operations, causing all functions to consume the maximum designated `verificationGasLimit` without enabling validation to pass, causing a financial loss in un-reimbursed gas costs to the bundler. Furthermore, such a metamorphic verifier could also call/re-enter all `onlyOwner()` protected functions of the contract. If `_authorizeUpgrade()` would ever be overwritten to enable upgrades, this would become a concern. Note that this is a general issue that can occur when interacting with metamorphic contracts, and the associated risk is not limited to the use of `ERC-4337`. This attack also requires the bundler to include a user operation in a bundle despite the presence of the `SELFDESTRUCT` opcode outside of the validation trace in the simulation. This is a point that was also raised in a [blog post by Vitalik Buterin](https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a) and is more of an issue in the bundler simulation than in these contracts. We, however, still want to raise awareness that the set of contracts enables a possible function flow that can cause the bundler some losses.

During the validation process of a user operation, the `LightAccount` wallet initially verifies whether the wallet's `owner` has signed the provided signature. If this verification succeeds, the `_validateSignature()` function returns a result of 0, indicating the signature is correct and valid, without imposing any time-based restrictions. However, this approach results in the user operation's signature remaining valid indefinitely once the EOA owner has signed it. This indefinite validity could expose users to specific attack vectors. For example, if a bundler behaves maliciously, they could withhold a user operation after receiving it from the user and submit the bundling transaction when there is a favorable profit opportunity. Delays in the bundling transaction, possibly caused by congestion in the bundler's alternate mempool, could create similar issues for users. It's worth noting that there exists a method for the EOA owner to manually invalidate a signature - by signing another user operation with the same nonce and executing it before the previous one.

Every Solidity file specifies in the header a version number of the format `pragma solidity (^)0.8.*`. The caret (`^`) before the version number implies an unlocked pragma, meaning that the compiler will use the specified version _and above_, hence the term "unlocked".