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

Unified equivocation slashing #1737

Closed
wants to merge 4 commits into from
Closed

Unified equivocation slashing #1737

wants to merge 4 commits into from

Conversation

JustinDrake
Copy link
Collaborator

@JustinDrake JustinDrake commented Apr 21, 2020

See #1387. Special thanks to @hwwhww for pinging me :)

TLDR: Unify all forms of slashing from equivocation (in particular equivocation through beacon proposing in phase 0, or through shard proposing and shard attesting in phase 1) into a single equivocation slashing condition.

rationale: This is a significant simplification to the slashing logic for phase 1. Each slashing condition costs about 50 lines of consensus code and needs to be separately tested. All in all we save about 100 lines of consensus code for phase 1. Avoiding two slashing conditions in phase 1 correspondingly simplifies testing.

substantive changes:

  • Introduce equivocation_root in signing root
  • Replace process_proposer_slashing by process_equivocation

cosmetic changes:

  • Move BeaconBlockHeader aside BeaconBlockBody and BeaconBlock
  • Rename SigningRoot to SigningData
  • Remove a couple of unnecessary new lines

cc @vbuterin, @djrtwo

See https://github.com/ethereum/eth2.0-specs/issues/1387—thanks to @hwwhww for pinging me :)

**TLDR**: Significant simplification, especially for phase 1. The idea is that all forms of equivocation (beacon proposing, shard proposing, shard attesting) are unified in a single equivocation slashing condition using uniqueness roots.

**Substantive changes**:

* Introduce `uniqueness_root` in signing root
* Replace `process_proposer_slashing` by `process_equivocation`

**Cosmetic changes**:

* Move `BeaconBlockHeader` aside `BeaconBlockBody` and `BeaconBlock`
* Rename `SigningRoot` to `SigningData`
* Remove a couple of unnecessary new lines
@hwwhww hwwhww added general:enhancement New feature or request phase0 labels Apr 21, 2020
@rauljordan
Copy link
Contributor

Hi @JustinDrake is there a strong rationale why this absolutely needs to be included in phase 0? These changes, albeit small in text, entail a significant burden for client developers (i.e. we have to create and maintain another feature branch that breaks consensus, has thousands of lines of code / tests / generated protos). These changes end up distracting us for 1 or 2 more weeks from key improvements on what we thought was the last, consensus-breaking spec change before mainnet barring critical bugs. We are already quite busy in terms of improving our client's testnet resilience and user experience today. If there is no urgent need for this in phase 0, we kindly ask on behalf of @prylabs that we move this to phase 1.

@prestonvanloon
Copy link
Contributor

I reviewed this with other members of @prysmaticlabs and I share the opinion expressed above. However, I would like to add a bit more to our feedback.

Having a generic function for equivocation slashing is a great idea. Had this been 6 months ago then I don't think anyone would be debating this. The issue now is that we are already in a code freeze. When the spec was unfrozen the first time, we agreed these significant changes were worth it. We've spent months building with an evolving spec and now we're finally just weeks away from The Multiclient Testnet followed by The Mainnet Release.

Now, in the face of unfreezing another frozen spec, do you all think this is worth it?
How many different types of evocation slashing do we plan to exist?

@JustinDrake
Copy link
Collaborator Author

Had this been 6 months ago then I don't think anyone would be debating this.

Agreed—I kinda dropped the ball on this one 😢

How many different types of evocation slashing do we plan to exist?

As of now we know of 3 types:

  1. beacon proposer equivocation (phase 0)
  2. shard proposer equivocation (phase 1)
  3. shard attester equivocation (phase 1)

It's possible more types of equivocation will be required for phase 2.

JustinDrake added a commit that referenced this pull request Apr 21, 2020
@arnetheduck
Copy link
Contributor

The testing infrastructure we have in clients and in the spec today should allow us to make this change relatively pain-free - we're fine either way on the Nimbus side - worth considering that it's easier to introduce this now than in the phase1 HF for example.

@prestonvanloon
Copy link
Contributor

The testing infrastructure we have in clients and in the spec today should allow us to make this change relatively pain-free - we're fine either way on the Nimbus side - worth considering that it's easier to introduce this now than in the phase1 HF for example.

We agree that this is relatively easier than the previous unfreezing of the spec, however I estimate that this change will delay a mainnet release by 2 to 4 weeks, at least. As all things in software engineering, whether or not we move forward on this is a trade off that must be carefully calculated.

hwwhww pushed a commit that referenced this pull request Apr 22, 2020
djrtwo added a commit that referenced this pull request Apr 22, 2020
@JustinDrake
Copy link
Collaborator Author

Closing in favour of #1758 which is easier to review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
general:enhancement New feature or request phase0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants