HIP38: Validator Oracles

[jamiew]

Info

• Author(s): @cvolkernick
• Start Date: 2021-09-06
• Category: Economic, Technical
• Original HIP PR: HIP draft – Validator Oracles #272
• Tracking Issue: HIP38: Validator Oracles #282
• Discord channel: #hip-38-validator-oracles on https://discord.gg/helium

Rendered view

https://github.com/helium/HIP/blob/master/0038-validator-oracles.md

Summary

From Helium Docs:

HNT converts to Data Credits at a rate pegged to $.00001 , and so the blockchain requires a canonical HNT/$USD price for this conversion. Beginning in June 2020, the Helium blockchain started using a system of decentralized price oracles to supply the $USD to HNT price used for on-chain for burn transactions. (This system is inspired by the Maker Foundation's Oracle usage.)

To find this price, nine oracles (this number may change in the future) periodically submit HNT/$USD prices. Once the blockchain has enough new price data, it will calculate a new HNT/$USD price that will remain valid until enough new, valid oracle inputs are submitted, triggering a new price revision.

This HIP proposes not only changing this number, but also expanding the pool of those who are able to make submissions. It proposes empowering any staked validators with the existing price_oracle_submission & allowing them to commit price oracle submissions as chain-blessed Oracles.

[jamiew]

@cvolkernick would you be willing to quick present & field questions about your HIP on this week's community call? Weds @ noon ET

[cvolkernick]

@cvolkernick would you be willing to quick present & field questions about your HIP on this week's community call? Weds @ noon ET

Sure thing.

[aJetHorn]

I am curious as to how the conversation above went. I'm currently writing an overview of this HIP and my immediate thought is that this proposal cannot move forward. Whether there is a fixed number of validators added as oracles (either by election or something else) or an everyone-can-opt-in oracle pool, this would put way too much power in the hands of large validator pools. According to the current algo for determining price, large validator pools could easily manipulate the oracle price by submitting inaccurate prices.

My understanding is that this proposal does not deal with the speed at which these price changes are calculated (every 10 blocks) but rather the accuracy of the median price that ends up getting set. It's understood that if we had, say, 1000 oracles that we'd probably end up with a more precise number when taking the median but I can't intuit how far off you currently think we might be or why this is important. Running such a simulation to prove your case would probably require implementing multiple different price discovery methods so as to not bias your results.

I could actually see a case for increasing the update frequency or slowly expanding the # of anonymous oracles but it's not clear to me what that case currently is or the disadvantages of the existing approach.

[cvolkernick]

@aJetHorn https://docs.google.com/document/d/1bMm2alBigBj3detA775Dn0Gz9UM5XczAeK9vnjBB3l0/edit

[cvolkernick]

I also don't disagree with you that there is a more root problem of the validator pool being too much of a walled garden. I've written previous HIPs on this but basically got a general response of "life isn't fair" non-rebuttal.

https://github.com/helium/HIP/blob/dd0cf067f04a70fe2df1730cda9ee1a2544d220f/0023-decouple-consensus-from-gateways.md

[jamiew]

@cvolkernick any updates on this proposal? Have heard some fun ideas for things we could do in this vein, although I don't know if they'd fit into the current proposal

[cvolkernick]

@cvolkernick any updates on this proposal? Have heard some fun ideas for things we could do in this vein, although I don't know if they'd fit into the current proposal

From the sound of it the community felt like this was not something that was a high-priority for the time being, and I don't necessarily disagree with that -- so might be best to put on ice until more pressing issues are resolved.

Thank you @jamiew