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
{{ message }}
This repository has been archived by the owner on Jan 6, 2025. It is now read-only.
Currently, some protocols allow validators to make (random) decisions when creating a new estimate. For example, see here or here.
This limits how well we can test these protocols, as we can't assert very specific things as non-deterministic choices are made. Ideally, there would be deterministic versions of all of these rules.
Proposed Implementation
Add necessary functions so all estimate functions can be deterministic if we want. For example, we should be able to specify what outputs validators build off of in the concurrent schedule in a testing language (e.g. pick the greatest one), or which shards to build on (e.g. always just build on this one shard).
Organizing these rules in some file other than the view may make sense as well.
The text was updated successfully, but these errors were encountered:
Fixing the seed might be useful for testing the random implementation, but
we want validators to be able to make more interesting decisions than build
on random shard(s) and want to be able to test potential decisions
explicitly.
We also might want to guide the state to an interesting corner case and
hoping that a seed on random gets us there won't cut it.
Issue
Currently, some protocols allow validators to make (random) decisions when creating a new estimate. For example, see here or here.
This limits how well we can test these protocols, as we can't assert very specific things as non-deterministic choices are made. Ideally, there would be deterministic versions of all of these rules.
Proposed Implementation
Add necessary functions so all estimate functions can be deterministic if we want. For example, we should be able to specify what outputs validators build off of in the concurrent schedule in a testing language (e.g. pick the greatest one), or which shards to build on (e.g. always just build on this one shard).
Organizing these rules in some file other than the view may make sense as well.
The text was updated successfully, but these errors were encountered: