fix(validator): do not process proposals from self#20314
Merged
spalladino merged 1 commit intomerge-train/spartanfrom Feb 9, 2026
Merged
fix(validator): do not process proposals from self#20314spalladino merged 1 commit intomerge-train/spartanfrom
spalladino merged 1 commit intomerge-train/spartanfrom
Conversation
PhilWindle
approved these changes
Feb 9, 2026
| } | ||
|
|
||
| // Ignore proposals from ourselves (may happen in HA setups) | ||
| if (this.getValidatorAddresses().some(addr => addr.equals(proposer))) { |
Collaborator
There was a problem hiding this comment.
Presumably this isn't going to prohibit propagation?
Contributor
Author
There was a problem hiding this comment.
No, this kicks in after the inivial validations run in the libp2p service that gate propagation
In a HA setup, if we receive a block or checkpoint proposal from an address we control, there's no point in processing it. We should just add it to the attestation pool to track equivocations (which is handled by the libp2p service), and that's it.
spalladino
force-pushed
the
palla/ignore-self-proposals
branch
from
9f06fe5 to
688edfd
Compare
Collaborator
Flakey Tests🤖 says: This CI run detected 1 tests that failed, but were tolerated due to a .test_patterns.yml entry. |
github-merge-queue bot
pushed a commit
that referenced
this pull request
Feb 10, 2026
BEGIN_COMMIT_OVERRIDE chore: add new retention policy to cloudflare R2 (#20276) fix: k8s enricher opt-in (#20279) feat(slasher): add duplicate attestation slashing (#20218) chore: improve HA e2e (#20280) chore(test): fix p2p integration test (#20283) chore(claude): minor changes to claude md and rules (#20284) chore(test): fix p2p message propagation test build error (#20289) chore(claude): add actor info to analyze-logs (#20290) feat: tx file store source for tx collector (#20165) chore(test): fix validator integration test (#20288) chore(e2e): remove setup with remote env in e2e tests (#20294) chore: fix test flakes (#20295) chore: user-perceived latency explorer (#20298) fix(p2p): fix flaky file store tx collection tests (#20318) chore(spartan): add mbps-net env definition (#20308) fix(validator): do not process proposals from self (#20314) chore(ci): track history in merge-trains (#20321) fix(e2e): enable broadcastEquivocatedProposals in duplicate proposal slash test (#20320) chore: use respective get endpoints for rollup test instead of only port-forward (#20327) END_COMMIT_OVERRIDE
spalladino
added a commit
that referenced
this pull request
Feb 10, 2026
With the fix from #20314, nodes now reject proposals that come from a validator key they themselves control. In the epochs mbps test suite, we were sending txs from a wallet created against the original node created, which is defined _with all validator keys_ so it can create the initial block with the initial tx. So, when this node's sequencer was later stopped and the validator keys were assigned to individual nodes, this original node never accepted any block proposal, since it considered it to be its own. So it failed to advance its own proposed chain, so the test failed. This PR fixes it so we just update the reference to the node in the wallet. The proper fix should be killing the initial node altogether and removing it from setup, and dealing with the initial timestamp issue somehow else.
spalladino
added a commit
that referenced
this pull request
Feb 10, 2026
With the fix from #20314, nodes now reject proposals that come from a validator key they themselves control. In the epochs mbps test suite, we were sending txs from a wallet created against the original node created, which is defined _with all validator keys_ so it can create the initial block with the initial tx. So, when this node's sequencer was later stopped and the validator keys were assigned to individual nodes, this original node never accepted any block proposal, since it considered it to be its own. So it failed to advance its own proposed chain, so the test failed. This PR fixes it so we just update the reference to the node in the wallet. The proper fix should be killing the initial node altogether and removing it from setup, and dealing with the initial timestamp issue somehow else.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Feb 10, 2026
With the fix from #20314, nodes now reject proposals that come from a validator key they themselves control. In the epochs mbps test suite, we were sending txs from a wallet created against the original node created, which is defined _with all validator keys_ so it can create the initial block with the initial tx. So, when this node's sequencer was later stopped and the validator keys were assigned to individual nodes, this original node never accepted any block proposal, since it considered it to be its own. So it failed to advance its own proposed chain, so the test failed. This PR fixes it so we just update the reference to the node in the wallet. The proper fix should be killing the initial node altogether and removing it from setup, and dealing with the initial timestamp issue somehow else.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
In a HA setup, if we receive a block or checkpoint proposal from an address we control, there's no point in processing it. We should just add it to the attestation pool to track equivocations (which is handled by the libp2p service), and that's it.