Skip to content
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

Disablement: Dispute participation disabling #2225

Closed
eskimor opened this issue Nov 8, 2023 · 5 comments · Fixed by #2637
Closed

Disablement: Dispute participation disabling #2225

eskimor opened this issue Nov 8, 2023 · 5 comments · Fixed by #2637
Assignees

Comments

@eskimor
Copy link
Member

eskimor commented Nov 8, 2023

Some thoughts: #784 (comment)
More implementation hints (more concrete, should resolve the above): #784 (comment)

@eskimor eskimor converted this from a draft issue Nov 8, 2023
@eskimor eskimor moved this from Backlog to In Progress in parachains team board Nov 8, 2023
@eskimor eskimor changed the title Disable dispute participation Disablement: Dispute participation disabling Nov 8, 2023
@eskimor
Copy link
Member Author

eskimor commented Nov 22, 2023

@ordian please notes on era changes and handling.

@ordian ordian linked a pull request Dec 6, 2023 that will close this issue
7 tasks
@ordian ordian moved this from In Progress to Review in progress in parachains team board Dec 13, 2023
@Overkillus
Copy link
Contributor

Re: node side disablement

We added node side disablement to fight against cases where the offending validator is no longer in the active validator set but he commits an offence in the previous era. (Correct?)

If in era n+1 a bunch of honest validators got slashed for 0% and they occupy the 1/3 disablement limit then an offender in era n will not get node-side disabled since the runtime has a priority.

Is this an issue? How easy it is to exploit it? It seems to somewhat go against the property of re-enabling as across eras we have the safety as if we didn't have re-enabling.

@ordian
Copy link
Member

ordian commented Dec 15, 2023

If in era n+1 a bunch of honest validators got slashed for 0% and they occupy the 1/3 disablement limit then an offender in era n will not get node-side disabled since the runtime has a priority.

Yes, I was thinking about this scenario too. Although we take the runtime state at relay_parent. So it has to be like this: 1/3 honest nodes get slashed 0% in era n at relay X, in era n+1 an attacker disputes all blocks in era n starting from block X. We can't disable attacker nodes.

What we could do is to ignore the onchain state and just go with offchain one.

@eskimor
Copy link
Member Author

eskimor commented Dec 15, 2023

This is totally fine. The reason we want re-enablement is to prevent a flatrate for trying to back an invalid candidate. The node side disabled list is only needed for spammers.

@Overkillus
Copy link
Contributor

Overkillus commented Dec 15, 2023

flatrate for trying to back an invalid candidate

As in backing without further consequences since you're already slashed for max?

Previous era backing on that scale will indeed be no longer possible so that seems like a good argument. Glad to have that one cleared 😄 was worried for a second.

tdimitrov added a commit that referenced this issue Jan 9, 2024
Closes #2225.

- [x] tests
- [x] fix todos
- [x] fix duplicates
- [x] make the check part of `potential_spam` 
- [x] fix a bug with votes insertion
- [x] guide changes
- [x] docs

---------

Co-authored-by: Tsvetomir Dimitrov <tsvetomir@parity.io>
@github-project-automation github-project-automation bot moved this from Review in progress to Completed in parachains team board Jan 9, 2024
bkontur pushed a commit that referenced this issue May 15, 2024
bkontur pushed a commit that referenced this issue May 15, 2024
bkontur pushed a commit that referenced this issue May 16, 2024
bkontur pushed a commit that referenced this issue May 17, 2024
bkontur pushed a commit that referenced this issue May 17, 2024
bkontur pushed a commit that referenced this issue May 17, 2024
bkontur pushed a commit that referenced this issue May 20, 2024
bkontur pushed a commit that referenced this issue May 21, 2024
bkontur pushed a commit that referenced this issue May 22, 2024
bkontur pushed a commit that referenced this issue May 23, 2024
bkontur pushed a commit that referenced this issue May 30, 2024
bkontur pushed a commit that referenced this issue Jun 4, 2024
bkontur pushed a commit that referenced this issue Jun 5, 2024
bkontur pushed a commit that referenced this issue Jun 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Completed
Development

Successfully merging a pull request may close this issue.

3 participants