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

Sequencer DA limit throttling #1357

Open
Tracked by #1281
eyusufatik opened this issue Oct 18, 2024 · 3 comments · May be fixed by #1528
Open
Tracked by #1281

Sequencer DA limit throttling #1357

eyusufatik opened this issue Oct 18, 2024 · 3 comments · May be fixed by #1528
Assignees
Milestone

Comments

@eyusufatik
Copy link
Member

No description provided.

@eyusufatik
Copy link
Member Author

the DA bandwith of bitcoin is 4MB / 10 mins.
so it can handle 4 MBs every 10 minutes.
we right now keep adding transactions without ever checking our DA usage. on the sequencer side we only use the ongoing diff size for to make sequencer commitments.

Ideally, we'd like to have a fee mechanism that increases L1 fee rates on soft confirmations as we reach the 4MB/10 mins mark. The L1 fee is an arbitrary fee rate selected by the sequencer and only the sequencer. We have no rules at the moment regarding the verification of this fee rate.

So the sequencer can increase the fee rate independently of the fee rate on bitcoin arbitrarily.

A simple solution to this would be for example,

let mut l1_fee_rate = get_l1_fee_rate()

l1_fee_rate *= current_cumulative_diff_da_usage / BITCOIN_MAX_DA_BANDWITH

thought this is not really smart at all. :)

the idea here is that, as we reach the limit, we economically discourage transactions from happening.

Not having a maxL1FeeRate field on our transactions along with this update would mean some users would pay unexpected amounts of fees, however, we can look for a solution for this later on.

@jfldde
Copy link
Contributor

jfldde commented Nov 18, 2024

Do we want to consider a 4MB/10mins or have a moving target depending on current mempool usage ?

the idea here is that, as we reach the limit, we economically discourage transactions from happening.
Understand this but this will affect the TX distribution across blocks where we have our first l2 blocks filled and progressively empty.

What is the end goal of fee ?
Do we want to disincentivize TXs as we get closer to the limit ? Do we want to distribute the TXs across our blocks ? Fairness/predictability for users ?

What should happen if we hit the limit but don't make it to the l1 block in time of high congestion, as in early 2024 ?

We need to be mindful of re-orgs that might throw off calculations as well.

@eyusufatik
Copy link
Member Author

Do we want to consider a 4MB/10mins or have a moving target depending on current mempool usage ?

4MB/10mins.

What is the end goal of fee ?
Do we want to disincentivize TXs as we get closer to the limit ?

Yes. But the later the disincentivization starts, the better. Don't know how to set it up though :)

What should happen if we hit the limit but don't make it to the l1 block in time of high congestion, as in early 2024 ?

Things will get delayed. There's nothing we can do unfortunately. We can leave this as a later issue.

@eyusufatik eyusufatik added this to the Mainnet Must milestone Nov 18, 2024
@jfldde jfldde linked a pull request Nov 27, 2024 that will close this issue
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

Successfully merging a pull request may close this issue.

2 participants