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

HIP38: Validator Oracles #282

Closed
jamiew opened this issue Sep 28, 2021 · 7 comments
Closed

HIP38: Validator Oracles #282

jamiew opened this issue Sep 28, 2021 · 7 comments

Comments

@jamiew
Copy link
Contributor

jamiew commented Sep 28, 2021

Info

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
Copy link
Contributor Author

jamiew commented Sep 28, 2021

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

@cvolkernick
Copy link
Contributor

@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
Copy link

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
Copy link
Contributor

@cvolkernick
Copy link
Contributor

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
Copy link
Contributor Author

jamiew commented Oct 25, 2021

@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
Copy link
Contributor

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants