I understand that the bundled transaction opens up the opportunity for front-running in the normal transaction mempool, and that’s why it is important to have Proposer-Builder separation (through MEV-boost).
The question I have is why would bundlers participate in the UserOp mempool, where they would be sharing the UserOps they received with other bundlers who would frontrun them in bundling the UserOps.
Wouldn’t it make more sense for users to send their UserOps to multiple bundlers, and the bundlers do not need to communicate with each other because they are in direct competition with one another. Why would a bundler share the UserOps they received with other bundlers in the mempool?
UserOperation is a new type of transaction, and it shares the same incentive model as normal transactions.
Bundlers are essentially block-builders that support this new type of transaction.
Any question about a bundler is the same about a block-builder: Users are not expected to send transactions directly to block-builders, and just the same, they are not expected to send transactions directly to bundlers.
Do not limit add/replacing/remove functions to view/pure functions.
Handle security of facets by having a facet registry which is a list of audited and approved facets for smart contract wallet diamonds. Also upgrades could require the approval of a user. That way a user gets only what he/she approves.
You can make it so that only facets in the facet registry can be added to a diamond. That way a malicious user who somehow gains access to a diamond cannot add malicious facets.
I think there is a difference. In the normal transaction mempool there is limited competitive advantage for validators to withhold transactions from other validators:
In Proof of Work chains, even if a miner communicates transactions to another miner, the block has to be mined for the transaction to be included in the chain. So PoW mining is the competitive bottleneck.
In Proof of Stake chains, validators get chosen probabilistically so there is no competitive advantage to withholding transactions from other validators.
In the UserOp mempool however, if a bundler sends UserOps to another bundler, the other bundler could bundle the UserOps faster and you lose out on the fees you could have collected if you were the first to bundle these UserOps. This is why it seems logical to me that the bundlers would not communicate with each other.
Is the UserOp mempool just a network of normal nodes propagating UserOps in a P2P manner with each other, and certain willing block producers participate in this mempool by listening to a certain set of nodes for UserOps which they can bundle, without propagating these UserOps any further in the mempool?
If a bundler withholds transactions, soon enough users will notice they get included on-chain slower, and will stop using this RPC provider, and switch to another RPC provider.
A bundler (like any other block builder) earns from transaction fees but even more so from MEV opportunities.
As we see it, a logical bundler should look at each UserOperation and decide:
No high MEV value, so it is better to send it to the public mempool. The small gas fee will be earned by the bundler attached to the next block-builder, but at least the “quality of service” offered to the user is good.
High MEV value: better pay extra through PBS/MEVboost protocols to get this UserOperation included fast, before the opportunity disappears (and again, give the user a good quality of service)
Any other tactic will soon report this bundler is a bad service, and force the users to switch to another.
Hey, I was wondering what if the key contract storage (owner, selector mapping, etc.) can change its slot randomly to a new location after a transaction is executed? Imagine we make a copy of storage before executing calldata, and assign it to a new randomly generated location and we update the information about this random location post execution of calldata. This way, the calldata can execute anything, but key storage aspects will not change.
I have an idea to enhance its functionality by introducing multi-entrypoint support. This enhancement would allow an account to accept multiple entrypoints, enabling seamless integration with various wallet platforms.
The current EIP-4337 proposal focuses on providing a standardized approach for composing Ethereum accounts and abstracting their underlying signatures and key management. However, it assumes a single entrypoint for interacting with the account. By expanding the proposal to support multiple entrypoints, we can significantly enhance its flexibility and usability across different wallet implementations.
My proposal suggests introducing a mechanism within EIP-4337 that allows an account to register and manage multiple entrypoints. This way, users can interact with the account using different wallet platforms, each utilizing its own entrypoint, while still benefiting from the underlying features provided by account abstraction.
The benefits of this enhancement include:
Improved interoperability: Supporting multiple entrypoints would foster interoperability between different wallet platforms, empowering users to choose their preferred method of interacting with the account while maintaining a consistent user experience.
Enhanced user choice: Users could access and manage the account using a wide range of wallet implementations, including hardware wallets, mobile wallets, browser extensions, and more, without needing to modify or switch their account setup.
Developer-friendly integration: Wallet developers would have the flexibility to integrate their platforms with accounts utilizing EIP-4337 more easily, expanding the adoption and support for account abstraction in the Ethereum ecosystem
I don’t understand what you achieve with multiple EntryPoint contracts.
An account trusts the EntryPoint that its execute method is only called if validateUserOp is called first (and doesn’t fail).
While it is possible for an account to support multiple EntryPoint (e.g. using require(validEntryPoints[msg.sender])), I don’t see the merit of it: There should be a single EntryPoint on the network, and the only reason to replace is the unlikely case we find a security breach , in which case wallets would like to replace it.
When an application submits a UserOperation (by calling the eth_sendUserOperation rpc call), the bundler first validate this UserOp is valid.
It does so by calling the simulateValidation() helper function, to make sure that creation, account validation and paymaster validation all succeed.
In order to protect itself (the bundler, not account), from denial of service attacks, it has to make sure this UserOp can’t interfere (invalidate) any other UserOp already in the mempool.
To do so, it performs a set of checks by tracing the above validation simulation - e.g. to make sure that opcodes that can be used for such denial of service (block number, timestamp,etc) are not used, and also that it only uses its own storage.
It will only accept UserOps that pass these validations.
If a UserOp is validated, the bundler knows it will pay, so there is no longer a possible of denial of service attack.
The executed code of the UserOp can do whatever it pleases - the UserOp is already guaranteed to pay. Just like normal transaction, the user pays even if the UserOp (or transaction) reverts.
I don’t understand what you’re trying to do: during execution, you can do whatever you like. Moving storage to another randomly-allocated location is possible - but you still need to keep (in storage) this randomly allocated storage address.
The problem I am trying to tackle is what if user adds a plugin to their AA wallet, that has a malicious code that can change the diamond storage layout causing users to lose access to wallet.
Should we include logic to validate ERC20 gas payments in the bundler, such as checking prices to optimize gas usage?
The paymaster contract will solely validate gasPrice and return the ERC20 token to tx.origin. Users have the option to set maxPriorityFeePerGas and maxFeePerGas in the userOperation to zero.
When implementing ERC20 gas payments in the bundler, it is worth considering the inclusion of additional logic to validate these payments and optimize gas usage. One approach could involve performing price checks to ensure efficient gas consumption.
Furthermore, users are provided with the flexibility to set maxPriorityFeePerGas and maxFeePerGas to zero within the userOperation section.
The idea is leave the core entities (EntryPoint and bundlers) as un-opinionated as possible. Tokens involve exposure to price volatility, which the core network shouldn’t deal with.
Payment with token is done using a TokenPaymaster, which pays the gas price in native token (eth), and receive tokens from the user’s account.
I’m interested in learning whether Account Abstraction will be implemented in the consensus layer in the future. I observed that EIP-4337 was favored over EIP-2938 because it avoids AA on the consensus layer. The reason for my inquiry is that I am an early solo staker who lost my mnemonic and now can’t create a withdrawal address. I’m curious if there are any upcoming EIPs that might introduce social recovery options for ETH2 addresses.
Does this mean session key will have access to all functions of AA wallet by default. Or there would be some control needs to be in place which cross checks data from userOperation while validating transaction coming to smart contract via session key