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

Create a stop in the case that DA gas price should go up but there are no txs to pay for it. #2347

Open
MitchTurner opened this issue Oct 14, 2024 · 1 comment
Assignees

Comments

@MitchTurner
Copy link
Member

MitchTurner commented Oct 14, 2024

The way the gas price algorithm is designed, we increase the DA gas price when the cost of posting L2 blocks to DA exceeds the reward received from charging L2 users the DA gas price.

In conjunction with this, as the DA gas price increases, there is a negative incentive for new txs to be submitted on L2, and this will lower the reward received, thus increasing the DA gas price further. This forms a negative feedback loop. If no txs are submitted, then the DA gas price could increase indefinitely, essentially bricking the network.

We need to introduce some kind of stop into the algorithm to prevent this negative feedback loop. Perhaps taking into account somehow the fullness of each L2 block before increasing the DA gas price.

This alone will only solve the symptom of the problem: DA gas price is high; and neglect the cause of the problem: a low profit (reward - cost). We need to also accommodate gradually working paying off the cost if there isn't an appetite from the market to pay the extra fee.

@MitchTurner MitchTurner self-assigned this Oct 14, 2024
xgreenx added a commit that referenced this issue Oct 14, 2024
## Version v0.40.0

### Added
- [2347](#2347): Add GraphQL
complexity histogram to metrics.
- [2350](#2350): Added a new
CLI flag `graphql-number-of-threads` to limit the number of threads used
by the GraphQL service. The default value is `2`, `0` enables the old
behavior.
- [2335](#2335): Added CLI
arguments for configuring GraphQL query costs.

### Fixed
- [2345](#2345): In PoA
increase priority of block creation timer trigger compare to txpool
event management

### Changed
- [2334](#2334): Prepare the
GraphQL service for the switching to `async` methods.
- [2310](#2310): New metrics:
"The gas prices used in a block" (`importer_gas_price_for_block`), "The
total gas used in a block" (`importer_gas_per_block`), "The total fee
(gwei) paid by transactions in a block" (`importer_fee_per_block_gwei`),
"The total number of transactions in a block"
(`importer_transactions_per_block`), P2P metrics for swarm and protocol.
- [2340](#2340): Avoid long
heavy tasks in the GraphQL service by splitting work into batches.
- [2341](#2341): Updated all
pagination queries to work with the async stream instead of the sync
iterator.
- [2350](#2350): Limited the
number of threads used by the GraphQL service.

#### Breaking
- [2310](#2310): The `metrics`
command-line parameter has been replaced with `disable-metrics`. Metrics
are now enabled by default, with the option to disable them entirely or
on a per-module basis.
- [2341](#2341): The maximum
number of processed coins from the `coins_to_spend` query is limited to
`max_inputs`.

## What's Changed
* fix(gas_price_service): service name and unused trait impl by @rymnc
in #2317
* Do not require build of docker images to pass CI by @xgreenx in
#2342
* Prepare the GraphQL service for the switching to `async` methods by
@xgreenx in #2334
* Limited the number of threads used by the GraphQL service by @xgreenx
in #2350
* Increase priority of timer over txpool event by @xgreenx in
#2345
* Disable flaky `test_poa_multiple_producers` test by @rafal-ch in
#2353
* feat: CLI arguments for configuring GraphQL query costs. by @netrome
in #2335
* Add graphql query complexity histogram metric by @AurelienFT in
#2349
* Updated all pagination queries to work with the `Stream` instead of
`Iterator` by @xgreenx in
#2341
* Avoid long heavy tasks in the GraphQL service by @xgreenx in
#2340
* Add more metrics by @rafal-ch in
#2310


**Full Changelog**:
v0.39.0...v0.40.0

---------

Co-authored-by: Rafał Chabowski <[email protected]>
Co-authored-by: acerone85 <[email protected]>
Co-authored-by: rymnc <[email protected]>
Co-authored-by: Rafał Chabowski <[email protected]>
@MitchTurner
Copy link
Member Author

MitchTurner commented Oct 15, 2024

One possible solution:
We already have the max_da_gas_price_change_percent as part of the updater. What if we also include an activity parameter and a activity_fullness_threshold_percent parameter. Let's say the activity parameter is a value between 1 and 100 as is the activity_fullness_threshold_percent. Each time an L2 block fullness exceeds the activity_fullness_threshold_percent, the updater increases the activity by 1.

The activity parameter is then used in conjunction with the max_da_gas_price_change_percent when increasing the gas price (not when decreasing). It would be an additional fraction of the max_da_gas_price_change_percent, so if activity is 0, the max_da_gas_price_change_percent would be multiplied by 0 and the DA gas price wouldn't change.

This would have the effect of, as the network gets less and less used, the price will get increased less and less, even if the profit is negative and decreasing. hopefully this will prevent the network from ever getting into a state where the prices prevent activity from lowering the prices.

I don't think this enough though. I think there needs to be some threshold where it starts decreasing the price, despite the profit being really low. That's the only real way of preventing some kind of bricking of the network.

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