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

improve chances of tx inclusion #180

Open
segfault-magnet opened this issue Jan 6, 2025 · 2 comments
Open

improve chances of tx inclusion #180

segfault-magnet opened this issue Jan 6, 2025 · 2 comments
Assignees

Comments

@segfault-magnet
Copy link
Contributor

Even with the addition of a blob fee horizon, it seems, at times, that the transaction is still not being promptly included.

The examples I've seen all have sufficient max fee per blob gas, so it could be either due to the max fee per gas or the priority fee.

Seeing as alloy multiplies max fee by 2 (giving it an effective horizon of 6-7 blocks), it is probably due to the priority fee being less appetizing to miners.

Analyze replacement transactions and compare them to the conditions of the network at the time the tx was sent. If it turns out that the priority fee was the reason, implement logic that will increase the fee (by increasing the reward perc. given to the historical fees query) depending on how many l2 blocks we're late at the moment.

@segfault-magnet segfault-magnet self-assigned this Jan 7, 2025
@segfault-magnet
Copy link
Contributor Author

On pause, need to handle this.

@segfault-magnet
Copy link
Contributor Author

segfault-magnet commented Jan 12, 2025

I've extracted from the db the top 10 transactions that took longest to finalize. The graphs below start at the first block that was mined after the tx was submitted and end at the block in which the transaction was included.

Sorted by time to finalization:

01663_transaction_0xe80b27b79e1dacc74738241a547f47a05491f60f0f95607503a69203944f9cae
01208_transaction_0xa5616a75559a6dac073c7ebeb1588196becb590acff0bb34dce6c59ff3522c94
00893_transaction_0xfde188ec7aef6f721a5c02f44c7e47faba426b96e3de928e78f3a1f1cfde7e6e
00642_transaction_0xfe4e6e51c32dcefe0bf97c3d561189834239f42e5c20dd3b2f0466c0c83840fc
00605_transaction_0xdc6c5d1ee565654ac4f7e3bbb4f167316cb9a471f456ec9ac60d1de85d3a6c4c
00594_transaction_0x3a029c0846e12e5dd6ab3b2abb733eabc597fc13ca94353f61e0879b74189739
00571_transaction_0xbb3fbce794e9dfacb7224c5e3b7abb0c6134fb3ad21f5a1854c1fbd96468900e
00441_transaction_0x30df57017860af59f6a80b1ba931834629d5328c5b89d5bb06c905b3e1340fcd
00401_transaction_0x97422a6b2c9f6922679a0c123b9a69971d9b18c6a9deb09960bd3216f8c5f5da
00400_transaction_0x22bbceb2149e4babc50c0e86e708a8a763aba56e02f19bd74fcf11ce5fd72f50

All of the above seem to fall into one of two scenarios:

  • A) The blob fee rises above our initial 2x max blob fee. We end up waiting until it drops back down. After waiting for a while, our transaction finally gets included.
  • B) Our transaction is ignored for a while but eventually gets included at some point.

Since our max fee and max blob fee start at roughly double the base fees and remain valid for at a minimum of 5 blocks (if the price just keeps rising) the key factor that influences when we actually get included is the priority fee.

The Geth blobpool docs explain that transactions are mainly picked based on their priority fee.

For transactions with the same priority fee, those with fees closer to the current network limits are chosen first, since lower-fee ones can wait.

We introduced a 5-block blob fee horizon to keep our transactions valid despite rapidly rising blob base fees. Without this horizon, if our transaction didn’t make it into the next block and fees kept going up, our transaction could become invalid regardless of how high we bumped the priority fee.

By extending our blob fee horizon, we've inadvertently made it more likely that our transaction gets postponed—because now there's a larger window where someone else with a higher priority fee or closer-to-limit fees might get chosen first.

But the trade-off here is necessary. The horizon ensures our transactions remain valid across multiple blocks during rapid fee increases, even if it means they might be pushed to later blocks under certain conditions.

Knowing this, if we want faster finalization, we should consider bumping the priority fee a bit more depending on how late we are.

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

1 participant