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.

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

Argument --max-gas-per-bundle doesn't affect anything #264

Open
MaxMoskalenko opened this issue Jul 9, 2024 · 4 comments
Open

Argument --max-gas-per-bundle doesn't affect anything #264

MaxMoskalenko opened this issue Jul 9, 2024 · 4 comments

Comments

@MaxMoskalenko
Copy link

Describe the bug
Hello there

Right now I'm working on a tool, that could activate a huge amount of smart accounts derived from one deployer address. Basically I'm sending all of them without waiting for the transaction to be minted and then waiting for the userOp statuses to become included into . But I faced an issue, where I have a lot of userOps in the state non_submited, which means that they are in mempool waiting to be included in the bundle. And they do but only like 4-5 userOps at a time.

So I started researching how to increase a bandwidth and found those flags: max-gas-per-bundle and mempool-max-parallel-ops. After increasing default values of it -- nothing happened. And I tried to reduce it to the ridiculously low value of 5 which I assumed will make bundler to not include any transaction to the bundle. But nothing happened again, I had the same 4-5 userOps at a time.

So is there any problem with this argument, or an issue with the bandwidth is in something else?

To Reproduce
Try to send a lot of transactions to the bundler and then wait for them to be mined.

The way I used to start bundler:

node src/lib/cli/alto.js run "--port" "3000" "--network-name" "mainnet" "--entrypoints" "0x" "--executor-private-keys" "0x" "--utility-private-key" "0x" "--min-executor-balance" "1000000000000000000" "--rpc-url" "http://eth_node:8545" "--log-level" "info" "--safe-mode" "false" "--max-gas-per-bundle" "5" "--mempool-max-parallel-ops" "50"

Expected behavior
With a increase of max-gas-per-bundle argument, amount of time for the processing of all userOps should be decreased

Environment:

  • Bundler Image: ghcr.io/pimlicolabs/alto:v1.2.0
  • Ethereum Node Image: ghcr.io/foundry-rs/foundry:nightly-156cb1396b7076c6f9cb56f3719f8c90f7f52064
@pavlovdog
Copy link
Contributor

Hey Max, thanks for reaching out!

  • max-gas-per-bundle limits the amount of gas a single bundle tx can consume. Take a look on maxGasLimit here
  • mempool-max-parallel-ops limits the amount of userops with the same sender and different nonce keys to be included in the same bundle tx. Take a look here

I guess I found the bug, can you try this branch? Let me know if it helps!

#265

@MaxMoskalenko
Copy link
Author

Yeap, it definitely helped. But something still limits amount of userops in a single bundle. After increasing max-gas-per-bundle to the certain amount it stops including more transactions to the bundle. Right now the highest amount I was able to achieve is 10-15 userops per bundle (for the reference, there is no difference between 50m and 500m value of that arg).

Is there something else that could affect such behaviour?

@pavlovdog
Copy link
Contributor

Oh, I see. What is the block gas limit of the network you're using? Eg Ethereum's is 30m, so there's a natural limitation to the amount of user operations in the single bundle :(

@MaxMoskalenko
Copy link
Author

Since I'm using custom development node, I could change the block gas limit. But even without it, used gas for the single bundle transaction is 1-3m (and there is one bundle tx per block), which is much less than default gas limit value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants