-
Notifications
You must be signed in to change notification settings - Fork 970
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 slashing condition for equivocations #1387
Comments
Not 100% sure I see the value here. Seems like it complicates the scheme.
Do you mean
Do you mean an efficiency gain for the slashing proofs? still chewing on it |
^ unsure of my assessment. Thinking on it some more :) |
Fixed, thank you :)
Yes. Smaller (less data) slashing proofs. |
The simplifity benefit comes from the fact that we can use one slashing condition to cover (i) beacon block proposer slashings, (ii) shard block proposer slashings, (iii) shard block attester slashings, and that slashing condition doesn't need to understand any data structures, it can just see a hash and a signature and a validator index.
Why two different domains? It seems to me that in any case where we have different domains of the latter type we can make domains of the former type different too. If we go down to one domain, a lot of complexity goes down (specifically, no need for a container type). |
We may want to introduce a container to handle domains as part of the BLS refactor. Right now we are mixing layers with
What about class Wrapper(Container):
message_root: Hash
domain: Domain
slot: Slot where the equivocation slashing condition checks w_1.message_root != w_2.message_root and
w_1.domain == w_2.domain and
w_1.domain in (DOMAIN_BEACON_PROPOSER, DOMAIN_SHARD_PROPOSER, DOMAIN_SHARD_ATTESTER) and
w_1.slot == w_2.slot |
We are going to need domains for things that aren't subject to equivocation slashing and things that don't have slots attached to them (eg. even shard blocks would be class Wrapper(Container):
message_root: Hash
domain: Domain
unique: bool
uniqueness_tag: Hash |
We can use class Wrapper(Container):
message_root: Hash
domain: Domain
uniqueness_root: Hash |
Sure, sounds good to me. Another possible approach to avoid hardcoding domain checking is to set |
@JustinDrake has this issue been solved by #1532? |
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
Closing in favour of #1758 |
In phase 1 we want three equivocation slashing conditions for 1) beacon blocks, 2) shard blocks, and 3) shard attestations. To reduce complexity those can be rolled into a single slashing condition. The idea (from @vbuterin) is to introduce a "uniqueness root" at the signature level.
For example, given a message
m
, the signature could be overH(H(m), domain, uniqueness_root)
. Messages without equivocation protection would by default setuniqueness_root = Bytes()
. Messages with equivocation protection would setuniqueness_root = hash_tree_root(uniqueness_data))
.For beacon blocks, shard blocks and shard attestations we can have
uniqueness_data
be of typeContainer(Domain: domain, Slot: slot)
. This substantive change to phase 0 can be part of the upcoming BLS signature revamp.Beyond the complexity reductions, this also bring efficiency gains. Indeed, only the message hashes
H(m)
(as opposed to the fullm
) need to be included on-chain.The text was updated successfully, but these errors were encountered: