-
Notifications
You must be signed in to change notification settings - Fork 805
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
[Merged by Bors] - Remove equivocating validators from fork choice #3371
[Merged by Bors] - Remove equivocating validators from fork choice #3371
Conversation
181fd0f
to
960bfbd
Compare
This PR is ready for review! A few notes for reviewers:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Looks great, couldn't find any issues. Left one comment that I'm not sure even makes a functional difference so feel free to ignore it.
// anyway. If a validator is slashable at the head but not at justification then it means | ||
// their activation has occurred since justification, and we arguably shouldn't be counting | ||
// their attestations. | ||
let slashed_indices = get_slashable_indices(head_state, slashing)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be better to use get_slashable_indices modular
here and have the is_slashable
method do nothing? Seems like it's more in line with what's specified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think if we wanted to match the spec as closely as possible without actually loading the justified state then we could use get_slashable_indices_modular
and check validator.is_slashable_at(head_state.current_justified_checkpoint().epoch)
. But I suspect that the spec is only written like that because the justified state is easy to access without plumbing the head state through. I've asked about it on the spec PR here: ethereum/consensus-specs#2845 (comment). We can hold off on merging for a bit until we hear back
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wrong 😅
Fixed in this commit, which also enabled a few other simplifications ad0621e.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice the updates look good to me, I'll leave it open in case @paulhauner wants to have a look
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice stuff, looks good!
Only one comment about SSZ decode in growing Vec
s.
// | ||
// We assume that if a max length is provided then the application is able to handle an | ||
// allocation of this size. | ||
let mut values = if max_len.is_some() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'll be interesting to see the outcome of losing max-length pre-allocation for VariableLists
which contain variable-length items. As an example we'll no longer allocate a list of length 128 for attestations in a block, instead we'll grow it by 1 each attestation. It seems VariableList
is used a bit by the networking stack, too.
I'm not certain if this will be a regression or not. I'll keep an eye on the memory stats on our nodes and maybe even do a heaptrack.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ooh good point. I kind of hoped the magic of collect
and size hints would let us keep the pre-allocation, but it seems it only works if the iterator implements TrustedLen
: https://github.com/rust-lang/rust/blob/48316dfea1914d25189fa441e7310449ed76a446/library/alloc/src/vec/spec_extend.rs#L36. And the iterator from process_results
doesn't (because it can fail).
It would be quite straight-forward to add a new_with_capacity
function to TryFromIter
if it turns out we need it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or we could just change the TryFromIter
implementation for Vec
so that it always uses the size_hint
bors r+ |
## Issue Addressed Closes #3241 Closes #3242 ## Proposed Changes * [x] Implement logic to remove equivocating validators from fork choice per ethereum/consensus-specs#2845 * [x] Update tests to v1.2.0-rc.1. The new test which exercises `equivocating_indices` is passing. * [x] Pull in some SSZ abstractions from the `tree-states` branch that make implementing Vec-compatible encoding for types like `BTreeSet` and `BTreeMap`. * [x] Implement schema upgrades and downgrades for the database (new schema version is V11). * [x] Apply attester slashings from blocks to fork choice ## Additional Info * This PR doesn't need the `BTreeMap` impl, but `tree-states` does, and I don't think there's any harm in keeping it. But I could also be convinced to drop it. Blocked on #3322.
Build failed (retrying...): |
## Issue Addressed Closes #3241 Closes #3242 ## Proposed Changes * [x] Implement logic to remove equivocating validators from fork choice per ethereum/consensus-specs#2845 * [x] Update tests to v1.2.0-rc.1. The new test which exercises `equivocating_indices` is passing. * [x] Pull in some SSZ abstractions from the `tree-states` branch that make implementing Vec-compatible encoding for types like `BTreeSet` and `BTreeMap`. * [x] Implement schema upgrades and downgrades for the database (new schema version is V11). * [x] Apply attester slashings from blocks to fork choice ## Additional Info * This PR doesn't need the `BTreeMap` impl, but `tree-states` does, and I don't think there's any harm in keeping it. But I could also be convinced to drop it. Blocked on #3322.
bors r- |
Canceled. |
bors r+ |
## Issue Addressed Closes #3241 Closes #3242 ## Proposed Changes * [x] Implement logic to remove equivocating validators from fork choice per ethereum/consensus-specs#2845 * [x] Update tests to v1.2.0-rc.1. The new test which exercises `equivocating_indices` is passing. * [x] Pull in some SSZ abstractions from the `tree-states` branch that make implementing Vec-compatible encoding for types like `BTreeSet` and `BTreeMap`. * [x] Implement schema upgrades and downgrades for the database (new schema version is V11). * [x] Apply attester slashings from blocks to fork choice ## Additional Info * This PR doesn't need the `BTreeMap` impl, but `tree-states` does, and I don't think there's any harm in keeping it. But I could also be convinced to drop it. Blocked on #3322.
Build failed (retrying...): |
bors r- |
Canceled. |
bors r+ |
## Issue Addressed Closes #3241 Closes #3242 ## Proposed Changes * [x] Implement logic to remove equivocating validators from fork choice per ethereum/consensus-specs#2845 * [x] Update tests to v1.2.0-rc.1. The new test which exercises `equivocating_indices` is passing. * [x] Pull in some SSZ abstractions from the `tree-states` branch that make implementing Vec-compatible encoding for types like `BTreeSet` and `BTreeMap`. * [x] Implement schema upgrades and downgrades for the database (new schema version is V11). * [x] Apply attester slashings from blocks to fork choice ## Additional Info * This PR doesn't need the `BTreeMap` impl, but `tree-states` does, and I don't think there's any harm in keeping it. But I could also be convinced to drop it. Blocked on #3322.
Build failed (retrying...): |
## Issue Addressed Closes #3241 Closes #3242 ## Proposed Changes * [x] Implement logic to remove equivocating validators from fork choice per ethereum/consensus-specs#2845 * [x] Update tests to v1.2.0-rc.1. The new test which exercises `equivocating_indices` is passing. * [x] Pull in some SSZ abstractions from the `tree-states` branch that make implementing Vec-compatible encoding for types like `BTreeSet` and `BTreeMap`. * [x] Implement schema upgrades and downgrades for the database (new schema version is V11). * [x] Apply attester slashings from blocks to fork choice ## Additional Info * This PR doesn't need the `BTreeMap` impl, but `tree-states` does, and I don't think there's any harm in keeping it. But I could also be convinced to drop it. Blocked on #3322.
Build failed: |
I'll queue this so it runs after the current batch. bors r+ |
## Issue Addressed Closes #3241 Closes #3242 ## Proposed Changes * [x] Implement logic to remove equivocating validators from fork choice per ethereum/consensus-specs#2845 * [x] Update tests to v1.2.0-rc.1. The new test which exercises `equivocating_indices` is passing. * [x] Pull in some SSZ abstractions from the `tree-states` branch that make implementing Vec-compatible encoding for types like `BTreeSet` and `BTreeMap`. * [x] Implement schema upgrades and downgrades for the database (new schema version is V11). * [x] Apply attester slashings from blocks to fork choice ## Additional Info * This PR doesn't need the `BTreeMap` impl, but `tree-states` does, and I don't think there's any harm in keeping it. But I could also be convinced to drop it. Blocked on #3322.
## Issue Addressed Fixes a potential regression in memory fragmentation identified by @paulhauner here: #3371 (comment). ## Proposed Changes Immediately allocate a vector with sufficient size to hold all decoded elements in SSZ decoding. The `size_hint` is derived from the range iterator here: https://github.com/sigp/lighthouse/blob/2983235650811437b44199f9c94e517e948a1e9b/consensus/ssz/src/decode/impls.rs#L489 ## Additional Info I'd like to test this out on some infra for a substantial duration to see if it affects total fragmentation.
## Issue Addressed Fixes a potential regression in memory fragmentation identified by @paulhauner here: #3371 (comment). ## Proposed Changes Immediately allocate a vector with sufficient size to hold all decoded elements in SSZ decoding. The `size_hint` is derived from the range iterator here: https://github.com/sigp/lighthouse/blob/2983235650811437b44199f9c94e517e948a1e9b/consensus/ssz/src/decode/impls.rs#L489 ## Additional Info I'd like to test this out on some infra for a substantial duration to see if it affects total fragmentation.
## Issue Addressed Fixes a potential regression in memory fragmentation identified by @paulhauner here: #3371 (comment). ## Proposed Changes Immediately allocate a vector with sufficient size to hold all decoded elements in SSZ decoding. The `size_hint` is derived from the range iterator here: https://github.com/sigp/lighthouse/blob/2983235650811437b44199f9c94e517e948a1e9b/consensus/ssz/src/decode/impls.rs#L489 ## Additional Info I'd like to test this out on some infra for a substantial duration to see if it affects total fragmentation.
## Issue Addressed Fixes a potential regression in memory fragmentation identified by @paulhauner here: #3371 (comment). ## Proposed Changes Immediately allocate a vector with sufficient size to hold all decoded elements in SSZ decoding. The `size_hint` is derived from the range iterator here: https://github.com/sigp/lighthouse/blob/2983235650811437b44199f9c94e517e948a1e9b/consensus/ssz/src/decode/impls.rs#L489 ## Additional Info I'd like to test this out on some infra for a substantial duration to see if it affects total fragmentation.
## Issue Addressed Fixes a potential regression in memory fragmentation identified by @paulhauner here: #3371 (comment). ## Proposed Changes Immediately allocate a vector with sufficient size to hold all decoded elements in SSZ decoding. The `size_hint` is derived from the range iterator here: https://github.com/sigp/lighthouse/blob/2983235650811437b44199f9c94e517e948a1e9b/consensus/ssz/src/decode/impls.rs#L489 ## Additional Info I'd like to test this out on some infra for a substantial duration to see if it affects total fragmentation.
## Issue Addressed Fixes a potential regression in memory fragmentation identified by @paulhauner here: sigp#3371 (comment). ## Proposed Changes Immediately allocate a vector with sufficient size to hold all decoded elements in SSZ decoding. The `size_hint` is derived from the range iterator here: https://github.com/sigp/lighthouse/blob/2983235650811437b44199f9c94e517e948a1e9b/consensus/ssz/src/decode/impls.rs#L489 ## Additional Info I'd like to test this out on some infra for a substantial duration to see if it affects total fragmentation.
Issue Addressed
Closes #3241
Closes #3242
Proposed Changes
equivocating_indices
is passing.tree-states
branch that make implementing Vec-compatible encoding for types likeBTreeSet
andBTreeMap
.Additional Info
BTreeMap
impl, buttree-states
does, and I don't think there's any harm in keeping it. But I could also be convinced to drop it.Blocked on #3322.