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

Debug V1 algorightm and use more realistic values in gas price analysis #2129

Merged
merged 16 commits into from
Sep 2, 2024

Conversation

MitchTurner
Copy link
Member

@MitchTurner MitchTurner commented Aug 26, 2024

Linked Issues

#2148

Description

Tuning and improving the V1 gas price algorithm is still and ongoing process, but this has drastically improved the accuracy of the algorithm when trying to track the costs of the DA block posting.

Some terms I'll use here:

"exec gas price": The portion of the L2 gas price that goes toward executing transations on L2

"da gas price": The portion of the L2 gas price that goes toward paying for committing block to DA

"cost": The amount in base asset to commit a block to the DA

"reward": The amount in base asset received by block producer from the "da gas price"

"profit": The difference between "reward" and "cost". Negative "profit" means it has costed more in total to commit blocks than has been rewarded in total to the block producer

"accuracy": The sum of all profit errors over the sample (either positive or negative). The optimization is trying to minimize the error for the highest "accuracy"

As you can see, however, there is room to improve:
image

During a relatively stable period where the posting costs barely change, the profit is still oscillating. We can dampen this by increasing the D value, but this doesn't result in a better accuracy:
image

The max error is much higher in this case. i.e. the profit gets much higher/lower. Maybe this is okay?

We can continue to improve the algorithm and do more tuning. A followup issue to this is to use real values instead of simulated DA gas prices #2138. Perhaps that will have less noise :) Another possibility is that we choose more inaccuracy in favor of a smoother algorithm.

This PR includes some of the following changes:

  • Modify the way we generate DA costs to be in a more realistic range
  • Just use the previous two profits to calculate the slope for the D component (ignore bytes for now)
  • Introduce DA gas price factor so that we can deal with smaller values while still increasing/decreasing. i.e. (similar to what we do with Fuel gas price factor or instead of using a float)
  • Add bytes per block chart
  • ...

Checklist

  • Breaking changes are clearly marked as such in the PR description and changelog
  • New behavior is reflected in tests
  • The specification matches the implemented behavior (link update PR if changes are needed)

Before requesting review

  • I have reviewed the code myself
  • I have created follow-up issues caused by this PR and linked them here

After merging, notify other teams

[Add or remove entries as needed]

@MitchTurner MitchTurner self-assigned this Aug 30, 2024
@MitchTurner MitchTurner added the no changelog Skip the CI check of the changelog modification label Aug 30, 2024
@MitchTurner MitchTurner marked this pull request as ready for review August 30, 2024 09:07
@MitchTurner MitchTurner changed the title Use more realistic values in gas price analysis Debug V1 algorightm and use more realistic values in gas price analysis Aug 30, 2024
netrome
netrome previously approved these changes Aug 30, 2024
Copy link
Contributor

@netrome netrome left a comment

Choose a reason for hiding this comment

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

Some naming suggestions and a bunch of questions from me.

Unrelated to this particular PR I find it interesting that we're using integer arithmetic throughout the entire algorithm. I would have expected this type of algorithm to be computed using floats internally, and then discretize the resulting DA price change before returning it. This would give us more fine grained control over the dynamics if we want to further tune the P and D values (and a potential I value if we want to include that down the line).

actual_profit,
projected_profit,
pessimistic_costs,
} = best;

let plot_width = 640 * 2;
// let min_actual_profit = pretty(actual_profit.iter().min().unwrap());
Copy link
Contributor

Choose a reason for hiding this comment

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

Clean up?

gen_noisy_signal(input, COMPONENTS)
}

fn arb_cost_per_byte(size: usize, update_period: usize) -> Vec<u64> {
Copy link
Contributor

Choose a reason for hiding this comment

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

What is arb short for here? "arbitrary"?

Comment on lines 70 to 71
/// the previous profit
last_last_profit: i64,
Copy link
Contributor

Choose a reason for hiding this comment

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

I find the naming a bit confusing here. How about something like:

Suggested change
/// the previous profit
last_last_profit: i64,
/// The average profit over the second last `avg_window` blocks
second_last_profit: i64,

Comment on lines 167 to 169
pub last_profit: i64,
/// The profit before last
pub last_last_profit: i64,
Copy link
Contributor

Choose a reason for hiding this comment

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

Also I think we can improve the naming here:

Suggested change
pub last_profit: i64,
/// The profit before last
pub last_last_profit: i64,
pub last_profit: i64,
/// The second last profit
pub second_last_profit: i64,

@MitchTurner MitchTurner requested a review from netrome August 30, 2024 11:46
@netrome netrome requested a review from a team August 30, 2024 12:14
@MitchTurner MitchTurner requested a review from netrome August 30, 2024 12:20
netrome
netrome previously approved these changes Aug 30, 2024
@@ -180,7 +190,7 @@ fn fullness_and_bytes_per_block(size: usize, capacity: u64) -> Vec<(u64, u64)> {
let bytes_scale: Vec<_> = std::iter::repeat(())
.take(size)
.map(|_| rng.gen_range(0.5..1.0))
.map(|x| x * 4.0)
.map(|x| x * 0.01)
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
.map(|x| x * 0.01)
.map(|x| x * BYTES_SCALE_INC)

it would be nice to avoid use of magic numbers here

.map(noisy_eth_price)
.map(|x| x * 100. + 110.)
.map(|x| x * 5. + 5.)
Copy link
Member

Choose a reason for hiding this comment

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

same as prev comment

@MitchTurner
Copy link
Member Author

Unrelated to this particular PR I find it interesting that we're using integer arithmetic throughout the entire algorithm. I would have expected this type of algorithm to be computed using floats internally, and then discretize the resulting DA price change before returning it. This would give us more fine grained control over the dynamics if we want to further tune the P and D values (and a potential I value if we want to include that down the line).

You're right. We might have been able to get away with floats here and it would be a lot easier. Something I didn't realize when I started the algorithm, but I do now, Is that this algorithm will be completely off-chain. Meaning the PoA node can use whatever values she chooses and it won't be validated on-chain.

In the future, we will have gas price as part of the state transition function. This will allow it to be part of fraud proving and later, when/if we move to PoS, be verified by other nodes during consensus. Float arithmetic is not deterministic, and that is why I went with integer math because I assumed this need to be run deterministically as part of the state transition function.

So, technically, right now it is YAGNI. So we could move to floats. In the future, it needs to be fully deterministic, which floats are not. That's why it's integers.

@MitchTurner MitchTurner requested a review from rymnc September 2, 2024 14:56
@MitchTurner MitchTurner requested a review from netrome September 2, 2024 14:56
@MitchTurner MitchTurner merged commit dfa76d7 into master Sep 2, 2024
34 checks passed
@MitchTurner MitchTurner deleted the spike/sync-gas-price-data-with-real-da branch September 2, 2024 15:30
@xgreenx xgreenx mentioned this pull request Sep 17, 2024
xgreenx added a commit that referenced this pull request Sep 18, 2024
## Version v0.36.0

### Added
- [2135](#2135): Added metrics
logging for number of blocks served over the p2p req/res protocol.
- [2151](#2151): Added
limitations on gas used during dry_run in API.
- [2188](#2188): Added the new
variant `V2` for the `ConsensusParameters` which contains the new
`block_transaction_size_limit` parameter.
- [2163](#2163): Added
runnable task for fetching block committer data.
- [2204](#2204): Added
`dnsaddr` resolution for TLD without suffixes.

### Changed

#### Breaking
- [2199](#2199): Applying
several breaking changes to the WASM interface from backlog:
- Get the module to execute WASM byte code from the storage first, an
fallback to the built-in version in the case of the
`FUEL_ALWAYS_USE_WASM`.
- Added `host_v1` with a new `peek_next_txs_size` method, that accepts
`tx_number_limit` and `size_limit`.
- Added new variant of the return type to pass the validation result. It
removes block serialization and deserialization and should improve
performance.
- Added a V1 execution result type that uses `JSONError` instead of
postcard serialized error. It adds flexibility of how variants of the
error can be managed. More information about it in
FuelLabs/fuel-vm#797. The change also moves
`TooManyOutputs` error to the top. It shows that `JSONError` works as
expected.
- [2145](#2145): feat:
Introduce time port in PoA service.
- [2155](#2155): Added trait
declaration for block committer data
- [2142](#2142): Added
benchmarks for varied forms of db lookups to assist in optimizations.
- [2158](#2158): Log the
public address of the signing key, if it is specified
- [2188](#2188): Upgraded the
`fuel-vm` to `0.57.0`. More information in the
[release](https://github.com/FuelLabs/fuel-vm/releases/tag/v0.57.0).

## What's Changed
* chore(p2p_service): add metrics for number of blocks requested over
p2p req/res protocol by @rymnc in
#2135
* Weekly `cargo update` by @github-actions in
#2149
* Debug V1 algorightm and use more realistic values in gas price
analysis by @MitchTurner in
#2129
* feat(gas_price_service): include trait declaration for block committer
data by @rymnc in #2155
* Convert gas price analysis tool to CLI by @MitchTurner in
#2156
* chore: add benchmarks for varied forms of lookups by @rymnc in
#2142
* Add label nochangelog on weekly cargo update by @AurelienFT in
#2152
* Log consensus-key signer address if specified by @acerone85 in
#2158
* chore(rocks_db): move ShallowTempDir to benches crate by @rymnc in
#2168
* chore(benches): conditional dropping of databases in benchmarks by
@rymnc in #2170
* feat: Introduce time port in PoA service by @netrome in
#2145
* Get DA costs from predefined data by @MitchTurner in
#2157
* chore(shallow_temp_dir): panic if not panicking by @rymnc in
#2172
* chore: Add initial CODEOWNERS file by @netrome in
#2179
* Weekly `cargo update` by @github-actions in
#2177
* fix(db_lookup_times): rework core logic of benchmark by @rymnc in
#2159
* Add verification on transaction dry_run that they don't spend more
than block gas limit by @AurelienFT in
#2151
* bug: fix algorithm overflow issues by @MitchTurner in
#2173
* feat(gas_price_service): create runnable task for expensive background
polling for da metadata by @rymnc in
#2163
* Weekly `cargo update` by @github-actions in
#2197
* Fix bug with gas price factor in V1 algorithm by @MitchTurner in
#2201
* Applying several breaking changes to the WASM interface from backlog
by @xgreenx in #2199
* chore(p2p): dnsaddr recursive resolution by @rymnc in
#2204

## New Contributors
* @acerone85 made their first contribution in
#2158

**Full Changelog**:
v0.35.0...v0.36.0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no changelog Skip the CI check of the changelog modification
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants