status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

simplify slashing instructions in vlaidator guide

This commit is contained in:
Danny Ryan 2019-01-24 23:11:40 -07:00
parent a182fdaa6f
commit 1614f2a9d7
No known key found for this signature in database
GPG Key ID: 2765A792E42CE07A
1 changed files with 4 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
specs/validator/0_beacon-chain-validator.md
View File

@ -331,27 +331,16 @@ signed_attestation_data = bls_sign(
"Slashing" is the burning of some amount of validator funds and immediate ejection from the active validator set. In Phase 0, there are two ways in which funds can be slashed -- [proposal slashing](#proposal-slashing) and [attestation slashing](#casper-slashing). Although being slashed has serious repercussions, it is simple enough to avoid being slashed all together by remaining _consistent_ with respect to the messages you have previously signed. "Slashing" is the burning of some amount of validator funds and immediate ejection from the active validator set. In Phase 0, there are two ways in which funds can be slashed -- [proposal slashing](#proposal-slashing) and [attestation slashing](#casper-slashing). Although being slashed has serious repercussions, it is simple enough to avoid being slashed all together by remaining _consistent_ with respect to the messages you have previously signed.
_Note_: Signed data must be within the same `Fork` context to conflict. Messages cannot be slashed across forks. _Note_: Signed data must be within a sequential `Fork` context to conflict. Messages cannot be slashed across diverging forks. If the previous fork version is 1 and the chain splits into fork 2 and 102, messages from 1 can slashable against messages in forks 1, 2, and 102. Messages in 2 cannot be slashable against messages in 102 and vice versa.
### Proposal slashing ### Proposal slashing
To avoid "proposal slashings", a validator must not sign two conflicting [`ProposalSignedData`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#proposalsigneddata) (suggest renaming `ProposalData`) where conflicting is defined as having the same `slot` and `shard` but a different `block_root`. To avoid "proposal slashings", a validator must not sign two conflicting [`ProposalSignedData`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#proposalsigneddata) where conflicting is defined as having the same `slot` and `shard` but a different `block_root`. In phase 0, proposals are only made for the beacon chain (`shard == BEACON_CHAIN_SHARD_NUMBER`).
The following helper can be run to check if two proposal messages conflict: In phase 0, as long as the validator does not sign two different beacon chain proposals for the same slot, the validator is safe against proposal slashings.
```python
def proposal_data_is_slashable(proposal_data_1: ProposalSignedData,
proposal_data_2: ProposalSignedData) -> bool:
if (proposal_data_1.slot != proposal_data_2.slot):
return False
if (proposal_data_1.shard != proposal_data_2.shard):
return False
return proposal_data_1.block_root != proposal_data_2.block_root
```
Specifically, when signing an `BeaconBlock`, a validator should perform the following steps in the following order: Specifically, when signing an `BeaconBlock`, a validator should perform the following steps in the following order:
1. Save a record to hard disk that an beacon block has been signed for the `slot` and `shard`. 1. Save a record to hard disk that an beacon block has been signed for the `slot=slot` and `shard=BEACON_CHAIN_SHARD_NUMBER`.
2. Generate and broadcast the block. 2. Generate and broadcast the block.
If the software crashes at some point within this routine, then when the validator comes back online the hard disk has the record of the _potentially_ signed/broadcast block and can effectively avoid slashing. If the software crashes at some point within this routine, then when the validator comes back online the hard disk has the record of the _potentially_ signed/broadcast block and can effectively avoid slashing.