-
Notifications
You must be signed in to change notification settings - Fork 32
[WIP] Optimize Peras weight calculation #1613
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
Draft
amesgen
wants to merge
42
commits into
peras-staging
Choose a base branch
from
amesgen/opt-weight-snapshot
base: peras-staging
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For the largest fragment, we have a reduction from 1.25 ms to 2.13 μs. |
c13b020
to
9544349
Compare
9544349
to
4f232eb
Compare
This is preparing for Peras, which will introduce a refined immutability criterion. Due to this change, we defer the immutability criterion to the implementation of `getCurrentChain`, reducing the impact of Peras.
This is a preparatory change for Peras, which uses a different immutability criterion (based on weight of chains, instead of (just) length). The only remaining use of the `SecurityParam` is for the snapshot policy 🙃
This requires some knot tying as we initialize the LedgerDB before the ChainDB is fully initialized. This is preparing for Peras, which will introduce a refined immutability criterion. Due to this change, the LedgerDB will automatically use the same criterion as the ChainDB (via `getCurrentChain`).
In case of data loss in the VolatileDB and a node restart, this condition can be violated until we received `k` headers again. Additionally, Ouroboros Peras will use a different immutability criterion where it is perfectly fine to have less than `k` headers on our chain (as long as they have sufficient weight).
- Avoid orphans - We actually can't check that the open states are consistent directly as we would need to statefully get that info from the SUT.
It makes sense to use this without using an entire PerasCertDB, so decouple these. It might be nice to rename PerasCertDB-bench, but doesn't seem like a priority.
using cabal-docspec (not yet nixified)
This is purely for concise QuickCheck counterexample output.
This is in preparation for weighted chain comparisons.
Also remove the version for `ValidatedChainDiff` as it is unused.
4f232eb
to
18c93d4
Compare
5ba50d1
to
36d8f01
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Not a priority for now, but opening a PR to have a reference
Relies on the fact that boosted points all lie on the same chain (which is not true across cooldowns, so this requires special care)