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
Enabling PBTS in existing chains or via genesis is performed via consensus parameters (see #2197), as chains have to define safe and good values for the synchronous parameters.
However, in internal test units we should only run consensus with PBTS enabled, as it will become the de facto default for computing timestamps from v1.x.
Regading e2e tests, the default behavior will be defined by #2284.
The text was updated successfully, but these errors were encountered:
Addresses #2324.
PBTS is enabled by setting `ConsensusParams.Feature.PbtsEnableHeight` to
a height > 0. To be enabled from startup, this value should be set to
`1`.
The default values for consensus parameters have both the `Feature`
entries set `0`, meaning that both PBTS and vote extensions are
disabled. While this setup can be reasonable for in production networks,
it does not allow test units to explore these features that are expected
to be enabled in new versions.
This PR ensures that PBTS is enabled in all test units. As a side
effect, vote extensions are also enabled in all unit tests (except when
the test checks the behavior without these features).
---
#### PR checklist
- [x] Tests written/updated
- [ ] Changelog entry added in `.changelog` (we use
[unclog](https://github.com/informalsystems/unclog) to manage our
changelog)
- [ ] Updated relevant documentation (`docs/` or `spec/`) and code
comments
- [x] Title follows the [Conventional
Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec
Uh oh!
There was an error while loading. Please reload this page.
Enabling PBTS in existing chains or via genesis is performed via consensus parameters (see #2197), as chains have to define safe and good values for the synchronous parameters.
However, in internal test units we should only run consensus with PBTS enabled, as it will become the de facto default for computing timestamps from
v1.x
.Regading
e2e
tests, the default behavior will be defined by #2284.The text was updated successfully, but these errors were encountered: