You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When updating costs, we currently pick numbers out of the estimator, adjust them based on our enlightened guesses, make some back-of-the-envelope computations to check everything won't break, update and hope for the best. This also forces us to always keep a large safety margin, because we're pretty hand-wavy in how we check numbers against our real-world use case.
In order to improve on that, we should at least check that the compute costs do match the wall clock time for our prospective gas costs.
One way to do that is spoofed compute costs. A patched node can report compute costs metrics that are not the protocol-defined compute costs, but the prospective compute costs. Based on this, we can then look at grafana the compute cost vs. wall clock time ratio, and confirm that we do not enter the danger zone in our live use cases.
This is not perfect, but it should be enough to give a significant boost in confidence that our prospective gas cost changes are correct.
This issue tracks setting up some minimal infrastructure, so that these patches become as easy to make as possible.
The text was updated successfully, but these errors were encountered:
Spoofed compute costs metrics
Context: this discussion
When updating costs, we currently pick numbers out of the estimator, adjust them based on our enlightened guesses, make some back-of-the-envelope computations to check everything won't break, update and hope for the best. This also forces us to always keep a large safety margin, because we're pretty hand-wavy in how we check numbers against our real-world use case.
In order to improve on that, we should at least check that the compute costs do match the wall clock time for our prospective gas costs.
One way to do that is spoofed compute costs. A patched node can report compute costs metrics that are not the protocol-defined compute costs, but the prospective compute costs. Based on this, we can then look at grafana the compute cost vs. wall clock time ratio, and confirm that we do not enter the danger zone in our live use cases.
This is not perfect, but it should be enough to give a significant boost in confidence that our prospective gas cost changes are correct.
This issue tracks setting up some minimal infrastructure, so that these patches become as easy to make as possible.
The text was updated successfully, but these errors were encountered: