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

Add endpoint to get recent gas prices #4277

Merged
merged 13 commits into from Mar 7, 2024
Merged

Conversation

hanssv
Copy link
Member

@hanssv hanssv commented Feb 26, 2024

Replaces #4191 - with a branch in this repo for easier collaboration.

There are a few things to consider here.

  • A minimum gas price is only relevant when chain is congested
  • When a micro-block is full isn't entirely obvious
  • Min gas fee can also be somewhat miner specific (miner min gas fee configuration).

This PR is supported by Æternity Foundation and Æternity Crypto Foundation

MinGasPrices ->
MinPriceN = fun(N) ->
case lists:min(lists:sublist(MinGasPrices, N)) of
undefined -> 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In OTP25 lists:min([]) throws an exception, but never undefined?
Oh, I see the hack now:
7> lists:min([undefined, 1,3]).
1
😃

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moreover, minimum should then possibly be the consensus defined minimum?

Copy link
Member

@davidyuk davidyuk Feb 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Returning 0 works for me as a way to distinguish

  • is there empty space in blocks (then SDK should use minimum gas price)
  • all blocks full, but transactions using minimum gas price (then SDK should increase the gas price a bit to ensure tx would be mined)

Otherwise I would ask for a flag indicating that.

ThomasArts
ThomasArts previously approved these changes Feb 26, 2024
Copy link
Contributor

@ThomasArts ThomasArts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure you should use 0 as minimum instead of consensus minimum, but that would not be a problem in practise

#{ <<"blocks">> := 120, <<"min_gas_price">> := MinGasPrice120 },
#{ <<"blocks">> := 480, <<"min_gas_price">> := MinGasPrice480 }
]} = http_request(Host, get, "recent-gas-prices", []),
MinGasPrice = 1000000000,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not very convincing test :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, no... Didn't look at it, just updated it to pass 😅

dincho
dincho previously approved these changes Feb 26, 2024
Copy link
Member

@dincho dincho left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same concern as @ThomasArts about protocol minimums

@dincho
Copy link
Member

dincho commented Feb 26, 2024

but that would not be a problem in practise

Why not, if the client solely relies on this result and the last X blocks are empty? 🤔

@hanssv hanssv dismissed stale reviews from dincho and ThomasArts via 6f20ade February 26, 2024 13:55
@hanssv
Copy link
Member Author

hanssv commented Feb 26, 2024

but that would not be a problem in practise

Why not, if the client solely relies on this result and the last X blocks are empty? 🤔

I think 0 would signal quite well that we don't have any data - the alternative would be protocol minimum, but there is no miner accepting that so that would be equally broken.

@hanssv hanssv marked this pull request as ready for review February 26, 2024 14:19
dincho
dincho previously approved these changes Feb 26, 2024
dincho
dincho previously approved these changes Feb 26, 2024
ThomasArts
ThomasArts previously approved these changes Feb 26, 2024
Copy link
Member

@davidyuk davidyuk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hanssv In the latest version, I can't distinguish if blocks are full and I should use min gas price + 1 or if there is space in blocks and I can use 1e9 (default min gas price). If sdk would always do min gas price + 1 then multiple sdk instances can increase the gas price without reason.

@davidyuk
Copy link
Member

Another issue:

  • I've build this branch, run it with configuration for sdk tests
  • recent-gas-prices shows "min_gas_price": 0 everywhere
  • changed min gas price in sdk to 1e9 + 1
  • executed some sdk tests
  • recent-gas-prices shows "min_gas_price": 1000000001 everywhere
  • I'd waited for a minute
  • changed min gas price in sdk to 1e9 + 2
  • executed some sdk tests
  • recent-gas-prices shows "min_gas_price": 1000000001 everywhere, but I expected to get 1000000002 in 1-minute because all transactions made have gas price 1e9 + 2

@hanssv
Copy link
Member Author

hanssv commented Feb 27, 2024

@hanssv In the latest version, I can't distinguish if blocks are full and I should use min gas price + 1 or if there is space in blocks and I can use 1e9 (default min gas price). If sdk would always do min gas price + 1 then multiple sdk instances can increase the gas price without reason.

As Dincho explained somewhere - 1e9 is not a fixed value, it can be set by the miner, so wether there is space or not is actually not relevant. If there are Txs in an interval you'll get the min gas price found, otherwise 0.

@hanssv hanssv dismissed stale reviews from ThomasArts and dincho via fef8d99 February 27, 2024 21:34
@hanssv
Copy link
Member Author

hanssv commented Feb 27, 2024

Another issue:

* I've build this branch, run it with configuration for sdk tests

* `recent-gas-prices` shows "min_gas_price": 0 everywhere

* changed min gas price in sdk to 1e9 + 1

* executed some sdk tests

* `recent-gas-prices` shows "min_gas_price": 1000000001 everywhere

* I'd waited for a minute

* changed min gas price in sdk to 1e9 + 2

* executed some sdk tests

* `recent-gas-prices` shows "min_gas_price": 1000000001 everywhere, but I expected to get 1000000002 in 1-minute because all transactions made have gas price 1e9 + 2

Microseconds and milliseconds were mixed-up, so you'd have to wait for 1000 minutes to see the effect 🙈

Fixed now.

ThomasArts
ThomasArts previously approved these changes Feb 28, 2024
Copy link
Contributor

@ThomasArts ThomasArts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missed that in review before, but indeed, times 1000

@hanssv
Copy link
Member Author

hanssv commented Mar 6, 2024

So we decided on sticking to this approach (reporting minimum gas price that made it on chain in the last X, Y and Z minutes) - but we'll also add a congestions metric (basically how many percent of of the available gas that was used in the the given time).

I will also sort out the caching properly - probably by an actual caching lib 😅

Cache ->
case kache:get(Cache, Hash) of
{ok, _} ->
lager:info("ZZZ: ~p in cache", [Hash]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

possibly real log message or debug message that the cache was hit?

@hanssv hanssv merged commit abc961d into master Mar 7, 2024
38 checks passed
@hanssv hanssv deleted the davidyuk-recent-gas-prices branch March 7, 2024 14:02
@hanssv hanssv added kind/feature Issues or PRs related to a new feature area/api Issues or PRs related to the public API labels Mar 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api Issues or PRs related to the public API kind/feature Issues or PRs related to a new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants