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

Move specials into block processing, and clean up specification 

Moves the procedure for handling specials into the per-block processing loop. Cleans up the specification for handling them to be more unambiguous, and changes the formats to be more readable and simpler to implement.
This commit is contained in:
vbuterin 2018-11-16 07:54:03 -05:00 committed by GitHub
parent ac207e4cc8
commit 65dc333549
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 106 additions and 81 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

187
specs/core/0_beacon-chain.md
View File

@ -171,7 +171,7 @@ A `SpecialRecord` has the following fields:
# Kind
'kind': 'uint8',
# Data
'data': ['bytes']
'data': 'bytes'
}
```
@ -213,8 +213,6 @@ The `BeaconState` has the following fields:
'fork_slot_number': 'uint64',
# Attestations not yet processed
'pending_attestations': [AttestationRecord],
# Specials not yet been processed
'pending_specials': [SpecialRecord]
# recent beacon block hashes needed to process attestations, older to newer
'recent_block_hashes': ['hash32'],
# RANDAO state
@ -503,7 +501,70 @@ def int_sqrt(n: int) -> int:
return x
```
### On startup
### Routine for adding a validator
This routine should be run for every validator that is inducted as part of a log created on the PoW chain [TODO: explain where to check for these logs]. The status of the validators added after genesis is `PENDING_ACTIVATION`. These logs should be processed in the order in which they are emitted by the PoW chain.
First, a helper function:
```python
def min_empty_validator(validators: List[ValidatorRecord]):
for i, v in enumerate(validators):
if v.status == WITHDRAWN:
return i
return None
```
Now, to add a validator:
```python
def add_validator(validators: List[ValidatorRecord],
pubkey: int,
proof_of_possession: bytes,
withdrawal_shard: int,
withdrawal_address: Address,
randao_commitment: Hash32,
status: int,
current_slot: int) -> int:
# if following assert fails, validator induction failed
# move on to next validator registration log
assert BLSVerify(pub=pubkey,
msg=hash(pubkey),
sig=proof_of_possession)
rec = ValidatorRecord(
pubkey=pubkey,
withdrawal_shard=withdrawal_shard,
withdrawal_address=withdrawal_address,
randao_commitment=randao_commitment,
randao_last_change=current_slot,
balance=DEPOSIT_SIZE * GWEI_PER_ETH,
status=status,
exit_slot=0
)
index = min_empty_validator(validators)
if index is None:
validators.append(rec)
return len(validators) - 1
else:
validators[index] = rec
return index
```
### Routine for removing a validator
```python
def exit_validator(index, state, penalize, current_slot):
validator = state.validators[index]
validator.exit_slot = current_slot
if penalize:
validator.status = PENALIZED
state.deposits_penalized_in_period[current_slot // WITHDRAWAL_PERIOD] += validator.balance
else:
validator.status = PENDING_EXIT
add_validator_set_change_record(state, index, validator.pubkey, EXIT)
```
## On startup
Run the following code:
@ -558,72 +619,7 @@ def on_startup(initial_validator_entries: List[Any]) -> BeaconState:
return state
```
The `add_validator` routine is defined below.
### Routine for adding a validator
This routine should be run for every validator that is inducted as part of a log created on the PoW chain [TODO: explain where to check for these logs]. The status of the validators added after genesis is `PENDING_ACTIVATION`. These logs should be processed in the order in which they are emitted by the PoW chain.
First, a helper function:
```python
def min_empty_validator(validators: List[ValidatorRecord]):
for i, v in enumerate(validators):
if v.status == WITHDRAWN:
return i
return None
```
Now, to add a validator:
```python
def add_validator(validators: List[ValidatorRecord],
pubkey: int,
proof_of_possession: bytes,
withdrawal_shard: int,
withdrawal_address: Address,
randao_commitment: Hash32,
status: int,
current_slot: int) -> int:
# if following assert fails, validator induction failed
# move on to next validator registration log
assert BLSVerify(pub=pubkey,
msg=hash(pubkey),
sig=proof_of_possession)
rec = ValidatorRecord(
pubkey=pubkey,
withdrawal_shard=withdrawal_shard,
withdrawal_address=withdrawal_address,
randao_commitment=randao_commitment,
randao_last_change=current_slot,
balance=DEPOSIT_SIZE * GWEI_PER_ETH,
status=status,
exit_slot=0
)
index = min_empty_validator(validators)
if index is None:
validators.append(rec)
return len(validators) - 1
else:
validators[index] = rec
return index
```
## Routine for removing a validator
```python
def exit_validator(index, state, penalize, current_slot):
validator = state.validators[index]
validator.exit_slot = current_slot
if penalize:
validator.status = PENALIZED
state.deposits_penalized_in_period[current_slot // WITHDRAWAL_PERIOD] += validator.balance
else:
validator.status = PENDING_EXIT
add_validator_set_change_record(state, index, validator.pubkey, EXIT)
```
### Per-block processing
## Per-block processing
This procedure should be carried out every beacon block.
@ -669,7 +665,7 @@ For each one of these attestations:
* Let `fork_version = pre_fork_version if slot < fork_slot_number else post_fork_version`.
* Verify that `aggregate_sig` verifies using the group pubkey generated and the serialized form of `AttestationSignedData(fork_version, slot, shard, parent_hashes, shard_block_hash, last_crosslinked_hash, shard_block_combined_data_root, justified_slot)` as the message.
Extend the list of `AttestationRecord` objects in the `state` with those included in the block, ordering the new additions in the same order as they came in the block. Similarly extend the list of `SpecialRecord` objects in the `state` with those included in the block.
Extend the list of `AttestationRecord` objects in the `state` with those included in the block, ordering the new additions in the same order as they came in the block.
Let `curblock_proposer_index` be the validator index of the `block.slot % len(get_shards_and_committees_for_slot(state, block.slot)[0].committee)`'th attester in `get_shards_and_committees_for_slot(state, block.slot)[0]`, and `parent_proposer_index` be the validator index of the parent block, calculated similarly. Verify that an attestation from the `parent_proposer_index`'th validator is part of the first (ie. item 0 in the array) `AttestationRecord` object; this attester can be considered to be the proposer of the parent block. In general, when a beacon block is produced, it is broadcasted at the network layer along with the attestation from its proposer.
@ -677,9 +673,46 @@ Additionally, verify and update the RANDAO reveal. This is done as follows:
* Let `repeat_hash(x, n) = x if n == 0 else repeat_hash(hash(x), n-1)`.
* Let `V = state.validators[curblock_proposer_index]`.
* Verify that `repeat_hash(block.randao_reveal, (block.slot - V.randao_last_change) // RANDAO_SLOTS_PER_LAYER + 1) == V.randao_commitment`, and set `state.randao_mix = xor(state.randao_mix, block.randao_reveal)` and append to `state.pending_specials` a `SpecialObject(kind=RANDAO_CHANGE, data=[bytes8(curblock_proposer_index), block.randao_reveal, bytes8(block.slot)])`.
* Verify that `repeat_hash(block.randao_reveal, (block.slot - V.randao_last_change) // RANDAO_SLOTS_PER_LAYER + 1) == V.randao_commitment`, and set `state.randao_mix = xor(state.randao_mix, block.randao_reveal)` and set `V.randao_commitment = block.randao_reveal`, and set `V.randao_last_change = block.slot`.
### State recalculations (every `CYCLE_LENGTH` slots)
### Process penalties, logouts and other special objects
For each `SpecialRecord` `obj` in `block.specials`, verify that its `kind` is one of the below values, and that `obj.data` deserializes according to the format for the given `kind`, then process it. The word "verify" when used below means that if the given verification check fails, the block containing that `SpecialRecord` is invalid.
#### LOGOUT
```python
{
'validator_index': 'uint64',
'signature': '[uint256]'
}
```
Verify that `BLSVerify(pubkey=validators[data.validator_index].pubkey, msg=hash(LOGOUT_MESSAGE + bytes8(fork_version)), sig=data.signature)`, where `fork_version = pre_fork_version if block.slot < fork_slot_number else post_fork_version`, and `validators[validator_index].status == ACTIVE`. Run `exit_validator(data.validator_index, state, penalize=False, current_slot=block.slot)`.
#### CASPER_SLASHING
```python
{
'vote1_aggsig_indices': '[uint24]',
'vote1_data': AttestationSignedData,
'vote1_aggsig': '[uint256]',
'vote2_aggsig_indices': '[uint24]',
'vote2_data': AttestationSignedData,
'vote2_aggsig': '[uint256]',
}
```
Verify that:
* For each `aggsig`, `BLSVerify(pubkey=aggregate_pubkey([validators[i].pubkey for i in aggsig_indices]), msg=vote_data, sig=aggsig)` passes.
* `vote1_data != vote2_data`
* Let `intersection = [x for x in vote1_aggsig_indices if x in vote2_aggsig_indices]`. Verify that `len(intersection) >= 1`.
* `vote1_data.justified_slot < vote2_data.justified_slot < vote2_data.slot <= vote1_data.slot`
For each validator index `v` in `intersection`, if `state.validators[v].status` does not equal `PENALIZED`, then run `exit_validator(v, state, penalize=True, current_slot=block.slot)`
## State recalculations (every `CYCLE_LENGTH` slots)
Repeat while `slot - last_state_recalculation_slot >= CYCLE_LENGTH`:
@ -734,14 +767,6 @@ For every shard number `shard` for which a crosslink committee exists in the cyc
* Participating validators gain `B // reward_quotient * (2 * total_balance_of_v_participating - total_balance_of_v) // total_balance_of_v`.
* Non-participating validators lose `B // reward_quotient`.
#### Process penalties, logouts and other special objects
For each `SpecialRecord` `obj` in `state.pending_specials`:
* **[covers `LOGOUT`]**: If `obj.kind == LOGOUT`, interpret `data[0]` as a `uint24` and `data[1]` as a `hash32`, where `validator_index = data[0]` and `signature = data[1]`. If `BLSVerify(pubkey=validators[validator_index].pubkey, msg=hash(LOGOUT_MESSAGE + bytes8(fork_version)), sig=signature)`, where `fork_version = pre_fork_version if slot < fork_slot_number else post_fork_version`, and `validators[validator_index].status == ACTIVE`, run `exit_validator(validator_index, state, penalize=False, current_slot=block.slot)`
* **[covers `NO_DBL_VOTE`, `NO_SURROUND`, `NO_DBL_PROPOSE` slashing conditions]:** If `obj.kind == CASPER_SLASHING`, interpret `data[0]` as a list of concatenated `uint32` values where each value represents an index into `validators`, `data[1]` as the data being signed and `data[2]` as an aggregate signature. Interpret `data[3:6]` similarly. Verify that both signatures are valid, that the two signatures are signing distinct data, and that they are either signing the same slot number, or that one surrounds the other (ie. `source1 < source2 < target2 < target1`). Let `indices` be the list of indices in both signatures; verify that its length is at least 1. For each validator index `v` in `indices`, if its `status` does not equal `PENALIZED`, then run `exit_validator(v, state, penalize=True, current_slot=block.slot)`
* **[covers `RANDAO_CHANGE`]**: If `obj.kind == RANDAO_CHANGE`, interpret `data[0]` as a `uint24`, `data[1]` as a `hash32`, and `data[2]` as a `uint64`, where `proposer_index = data[0]`, `randao_commitment = data[1]`, and `randao_last_change = data[2]`. Set `validators[proposer_index].randao_commitment = randao_commitment`, and set `validators[proposer_index].randao_last_change = randao_last_change`.
### Validator set change
A validator set change can happen after a state recalculation if all of the following criteria are satisfied: