feat: add incremental computation for STX:BTC ratio#6965
feat: add incremental computation for STX:BTC ratio#6965brice-stacks wants to merge 50 commits intostacks-network:pox-5-integrationfrom
Conversation
Uses the miner spending (in BTC) and miner earning (in STX) to compute a reasonable price ratio. Then, to smooth this price, to prevent miner actions from causing disruptions, we compute a weighted geometric mean over the last 5 cycles. This computation is currently available via `stacks-inspect` with the `get-stx-btc-ratio` command, and via RPC at the `/v3/stx_btc_ratio/` endpoint.
We'll need this for the STX/BTC pricing ratio calculation.
The median can't easily be computed, so retrieve it from the Bitcoin node with a new RPC interface.
This is an "expected" or estimated fee, not the actual fee. For our STX:BTC pricing, we only care about this expected fee.
In order to ensure nodes are all collecting the same data, gate the inclusion of the missed commit "burn" and the "expected" BTC fees for all commits. This can be enabled once we are sure that the changes to record these values in the DB have been guaranteed by a hard fork (likely 3.5).
Later, when we cache these ratios, this auth can be removed.
For STX:BTC ratio calculation
It is no longer expensive with the changes to compute it incrementally.
353bfd7 to
3a30bf9
Compare
|
Doing some testing on a live mainnet node and it is looking pretty good: I did notice an issue with the cycle in which we update the node -- it needs some logic to know that it does not have all of the information for that cycle instead of thinking that it is up-to-date, because the I think it either needs to calculate the current cycle on startup, or not cache anything until the first run of the complete check... I'll work on this. |
|
with the latest fix, I'm running this on a live mainnet node and it is looking good. |
These are too easily manipulated by Stacks miners.
Leftover from earlier attempts.
Coverage Report for CI Build 24478307557Coverage increased (+39.0%) to 85.679%Details
Uncovered Changes
Coverage Regressions1244 previously-covered lines in 40 files lost coverage.
Coverage Stats
💛 - Coveralls |
| if totals.tenure_count == 0 || totals.btc_spent_sats == 0 { | ||
| return None; | ||
| } | ||
| Some(totals.stx_earned_ustx / u128::from(totals.btc_spent_sats)) |
There was a problem hiding this comment.
Note that this integer floor division becomes a problem if the STX price is >1% of the BTC price. That would be a great problem to have.
| let smoothed_ratio = low >> FIXED_POINT_SHIFT; | ||
| Some(uint256_to_u128_saturating(&smoothed_ratio)) |
There was a problem hiding this comment.
Is it feasible to just hold on to the fractional bits? When this gets consumed by the reward set calculation, it can handle scaling the fixed point appropriately, then we won't lose much precision when the ratio declines.
|
I'll come back to this later as it will not be necessary in the first iteration of the design. |
Description
Build on #6950, adding a cache and incremental computation for the STX:BTC ratio computation.
Applicable issues
Additional info (benefits, drawbacks, caveats)
Checklist
docs/property-testing.md)rpc/openapi.yamlfor RPC endpoints,event-dispatcher.mdfor new events)clarity-benchmarkingrepo