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

Merge branch 'master' into ssz-var-length-list

This commit is contained in:
jannikluhn 2019-01-28 10:53:04 +01:00 committed by GitHub
parent f8670e8069 1a41078768
commit 4bedb16e21
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 506 additions and 126 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -18,7 +18,6 @@
- [Reward and penalty quotients](#reward-and-penalty-quotients)
- [Status flags](#status-flags)
- [Max operations per block](#max-operations-per-block)
- [Validator registry delta flags](#validator-registry-delta-flags)
- [Signature domains](#signature-domains)
- [Data structures](#data-structures)
- [Beacon chain operations](#beacon-chain-operations)
@ -47,9 +46,9 @@
- [`Crosslink`](#crosslink)
- [`PendingAttestation`](#pendingattestation)
- [`Fork`](#fork)
- [`ValidatorRegistryDeltaBlock`](#validatorregistrydeltablock)
- [`Eth1Data`](#eth1data)
- [`Eth1DataVote`](#eth1datavote)
- [Custom Types](#custom-types)
- [Ethereum 1.0 deposit contract](#ethereum-10-deposit-contract)
- [Deposit arguments](#deposit-arguments)
- [Withdrawal credentials](#withdrawal-credentials)
@ -73,6 +72,7 @@
- [`get_crosslink_committees_at_slot`](#get_crosslink_committees_at_slot)
- [`get_block_root`](#get_block_root)
- [`get_randao_mix`](#get_randao_mix)
- [`get_active_index_root`](#get_active_index_root)
- [`get_beacon_proposer_index`](#get_beacon_proposer_index)
- [`merkle_root`](#merkle_root)
- [`get_attestation_participants`](#get_attestation_participants)
@ -84,6 +84,7 @@
- [`is_double_vote`](#is_double_vote)
- [`is_surround_vote`](#is_surround_vote)
- [`integer_squareroot`](#integer_squareroot)
- [`entry_exit_effect_slot`](#entry_exit_effect_slot)
- [`bls_verify`](#bls_verify)
- [`bls_verify_multiple`](#bls_verify_multiple)
- [`bls_aggregate_pubkeys`](#bls_aggregate_pubkeys)
@ -115,7 +116,7 @@
- [Attestation inclusion](#attestation-inclusion)
- [Crosslinks](#crosslinks-1)
- [Ejections](#ejections)
- [Validator registry](#validator-registry)
- [Validator registry and shuffling seed data](#validator-registry-and-shuffling-seed-data)
- [Final updates](#final-updates)
- [State root processing](#state-root-processing)
- [References](#references)
@ -168,6 +169,7 @@ Code snippets appearing in `this style` are to be interpreted as Python code. Be
| `MAX_CASPER_VOTES` | `2**10` (= 1,024) | votes |
| `LATEST_BLOCK_ROOTS_LENGTH` | `2**13` (= 8,192) | block roots |
| `LATEST_RANDAO_MIXES_LENGTH` | `2**13` (= 8,192) | randao mixes |
| `LATEST_INDEX_ROOTS_LENGTH` | `2**13` (= 8,192) | index roots |
| `LATEST_PENALIZED_EXIT_LENGTH` | `2**13` (= 8,192) | epochs | ~36 days |
| `MAX_WITHDRAWALS_PER_EPOCH` | `2**2` (= 4) | withdrawals |
@ -235,13 +237,6 @@ Code snippets appearing in `this style` are to be interpreted as Python code. Be
| `MAX_DEPOSITS` | `2**4` (= 16) |
| `MAX_EXITS` | `2**4` (= 16) |
### Validator registry delta flags
| Name | Value |
| - | - |
| `ACTIVATION` | `0` |
| `EXIT` | `1` |
### Signature domains
| Name | Value |
@ -254,6 +249,8 @@ Code snippets appearing in `this style` are to be interpreted as Python code. Be
## Data structures
The following data structures are defined as [SimpleSerialize (SSZ)](https://github.com/ethereum/eth2.0-specs/blob/master/specs/simple-serialize.md) objects.
### Beacon chain operations
#### Proposer slashings
@ -475,7 +472,6 @@ Code snippets appearing in `this style` are to be interpreted as Python code. Be
'validator_balances': ['uint64'],
'validator_registry_update_slot': 'uint64',
'validator_registry_exit_count': 'uint64',
'validator_registry_delta_chain_tip': 'bytes32', # For light clients to track deltas
# Randomness and committees
'latest_randao_mixes': ['bytes32'],
@ -484,8 +480,8 @@ Code snippets appearing in `this style` are to be interpreted as Python code. Be
'current_epoch_start_shard': 'uint64',
'previous_epoch_calculation_slot': 'uint64',
'current_epoch_calculation_slot': 'uint64',
'previous_epoch_randao_mix': 'bytes32',
'current_epoch_randao_mix': 'bytes32',
'previous_epoch_seed': 'bytes32',
'current_epoch_seed': 'bytes32',
# Custody challenges
'custody_challenges': [CustodyChallenge],
@ -499,6 +495,7 @@ Code snippets appearing in `this style` are to be interpreted as Python code. Be
# Recent state
'latest_crosslinks': [Crosslink],
'latest_block_roots': ['bytes32'], # Needed to process attestations, older to newer
'latest_index_roots': ['bytes32'],
'latest_penalized_balances': ['uint64'], # Balances penalized at every withdrawal period
'latest_attestations': [PendingAttestation],
'batched_block_roots': ['bytes32'],
@ -517,8 +514,6 @@ Code snippets appearing in `this style` are to be interpreted as Python code. Be
'pubkey': 'bytes48',
# Withdrawal credentials
'withdrawal_credentials': 'bytes32',
# Number of proposer slots since genesis
'proposer_slots': 'uint64',
# Slot when validator activated
'activation_slot': 'uint64',
# Slot when validator exited
@ -577,26 +572,14 @@ Code snippets appearing in `this style` are to be interpreted as Python code. Be
}
```
#### `ValidatorRegistryDeltaBlock`
```python
{
'latest_registry_delta_root': 'bytes32',
'validator_index': 'uint24',
'pubkey': 'bytes48',
'slot': 'uint64',
'flag': 'uint64',
}
```
#### `Eth1Data`
```python
{
# Root of the deposit tree
'deposit_root': 'hash32',
'deposit_root': 'bytes32',
# Block hash
'block_hash': 'hash32',
'block_hash': 'bytes32',
}
```
@ -611,6 +594,20 @@ Code snippets appearing in `this style` are to be interpreted as Python code. Be
}
```
## Custom Types
We define the following Python custom types for type hinting and readability:
| Name | Type | Description |
| - | - | - |
| `SlotNumber` | unsigned 64-bit integer | the number of a slot |
| `ShardNumber` | unsigned 64-bit integer | the number of a shard |
| `ValidatorIndex` | unsigned 24-bit integer | the index number of a validator in the registry |
| `Gwei` | unsigned 64-bit integer | an amount in Gwei |
| `Bytes32` | 32-byte data | binary data with 32-byte length |
| `BLSPubkey` | 48-byte data | a public key in BLS signature scheme |
| `BLSSignature` | 96-byte data | a signature in BLS signature scheme |
## Ethereum 1.0 deposit contract
The initial deployment phases of Ethereum 2.0 are implemented without consensus changes to Ethereum 1.0. A deposit contract at address `DEPOSIT_CONTRACT_ADDRESS` is added to Ethereum 1.0 for deposits of ETH to the beacon chain. Validator balances will be withdrawable to the shards in phase 2, i.e. when the EVM2.0 is deployed and the shards have state.
@ -729,28 +726,38 @@ Beacon block production is significantly different because of the proof of stake
The beacon chain fork choice rule is a hybrid that combines justification and finality with Latest Message Driven (LMD) Greediest Heaviest Observed SubTree (GHOST). At any point in time a [validator](#dfn-validator) `v` subjectively calculates the beacon chain head as follows.
* Let `store` be the set of attestations and blocks that the [validator](#dfn-validator) `v` has observed and verified (in particular, block ancestors must be recursively verified). Attestations not part of any chain are still included in `store`.
* Abstractly define `Store` as the type of storage object for the chain data and `store` be the set of attestations and blocks that the [validator](#dfn-validator) `v` has observed and verified (in particular, block ancestors must be recursively verified). Attestations not yet included in any chain are still included in `store`.
* Let `finalized_head` be the finalized block with the highest slot number. (A block `B` is finalized if there is a descendant of `B` in `store` the processing of which sets `B` as finalized.)
* Let `justified_head` be the descendant of `finalized_head` with the highest slot number that has been justified for at least `EPOCH_LENGTH` slots. (A block `B` is justified if there is a descendant of `B` in `store` the processing of which sets `B` as justified.) If no such descendant exists set `justified_head` to `finalized_head`.
* Let `get_ancestor(store, block, slot)` be the ancestor of `block` with slot number `slot`. The `get_ancestor` function can be defined recursively as `def get_ancestor(store, block, slot): return block if block.slot == slot else get_ancestor(store, store.get_parent(block), slot)`.
* Let `get_latest_attestation(store, validator)` be the attestation with the highest slot number in `store` from `validator`. If several such attestations exist, use the one the [validator](#dfn-validator) `v` observed first.
* Let `get_latest_attestation_target(store, validator)` be the target block in the attestation `get_latest_attestation(store, validator)`.
* The head is `lmd_ghost(store, justified_head)` where the function `lmd_ghost` is defined below. Note that the implementation below is suboptimal; there are implementations that compute the head in time logarithmic in slot count.
* Let `get_ancestor(store: Store, block: BeaconBlock, slot: SlotNumber) -> BeaconBlock` be the ancestor of `block` with slot number `slot`. The `get_ancestor` function can be defined recursively as `def get_ancestor(store: Store, block: BeaconBlock, slot: SlotNumber) -> BeaconBlock: return block if block.slot == slot else get_ancestor(store, store.get_parent(block), slot)`.
* Let `get_latest_attestation(store: Store, validator: Validator) -> Attestation` be the attestation with the highest slot number in `store` from `validator`. If several such attestations exist, use the one the [validator](#dfn-validator) `v` observed first.
* Let `get_latest_attestation_target(store: Store, validator: Validator) -> BeaconBlock` be the target block in the attestation `get_latest_attestation(store, validator)`.
* Let `get_children(store: Store, block: BeaconBlock) -> List[BeaconBlock]` returns the child blocks of the given `block`.
* Let `justified_head_state` be the resulting `BeaconState` object from processing the chain up to the `justified_head`.
* The `head` is `lmd_ghost(store, justified_head_state, justified_head)` where the function `lmd_ghost` is defined below. Note that the implementation below is suboptimal; there are implementations that compute the head in time logarithmic in slot count.
```python
def lmd_ghost(store, start):
validators = start.state.validator_registry
active_validators = [validators[i] for i in
get_active_validator_indices(validators, start.state.slot)]
attestation_targets = [get_latest_attestation_target(store, validator)
for validator in active_validators]
def get_vote_count(block):
return len([target for target in attestation_targets if
get_ancestor(store, target, block.slot) == block])
def lmd_ghost(store: Store, start_state: BeaconState, start_block: BeaconBlock) -> BeaconBlock:
validators = start_state.validator_registry
active_validators = [
validators[i]
for i in get_active_validator_indices(validators, start_state.slot)
]
attestation_targets = [
get_latest_attestation_target(store, validator)
for validator in active_validators
]
head = start
def get_vote_count(block: BeaconBlock) -> int:
return len([
target
for target in attestation_targets
if get_ancestor(store, target, block.slot) == block
])
head = start_block
while 1:
children = get_children(head)
children = get_children(store, head)
if len(children) == 0:
return head
head = max(children, key=get_vote_count)
@ -777,11 +784,11 @@ Note: We aim to migrate to a S[T/N]ARK-friendly hash function in a future Ethere
#### `hash_tree_root`
`hash_tree_root` is a function for hashing objects into a single root utilizing a hash tree structure. `hash_tree_root` is defined in the [SimpleSerialize spec](https://github.com/ethereum/eth2.0-specs/blob/master/specs/simple-serialize.md#tree-hash).
`def hash_tree_root(object: SSZSerializable) -> Bytes32` is a function for hashing objects into a single root utilizing a hash tree structure. `hash_tree_root` is defined in the [SimpleSerialize spec](https://github.com/ethereum/eth2.0-specs/blob/master/specs/simple-serialize.md#tree-hash).
#### `is_active_validator`
```python
def is_active_validator(validator: Validator, slot: int) -> bool:
def is_active_validator(validator: Validator, slot: SlotNumber) -> bool:
"""
Checks if ``validator`` is active.
"""
@ -791,7 +798,7 @@ def is_active_validator(validator: Validator, slot: int) -> bool:
#### `get_active_validator_indices`
```python
def get_active_validator_indices(validators: [Validator], slot: int) -> List[int]:
def get_active_validator_indices(validators: List[Validator], slot: SlotNumber) -> List[ValidatorIndex]:
"""
Gets indices of active validators from ``validators``.
"""
@ -883,7 +890,7 @@ def get_committee_count_per_slot(active_validator_count: int) -> int:
```python
def get_shuffling(seed: Bytes32,
validators: List[Validator],
slot: int) -> List[List[int]]
slot: SlotNumber) -> List[List[ValidatorIndex]]
"""
Shuffles ``validators`` into crosslink committees seeded by ``seed`` and ``slot``.
Returns a list of ``EPOCH_LENGTH * committees_per_slot`` committees where each
@ -905,7 +912,7 @@ def get_shuffling(seed: Bytes32,
return split(shuffled_active_validator_indices, committees_per_slot * EPOCH_LENGTH)
```
**Invariant**: if `get_shuffling(seed, validators, slot)` returns some value `x`, it should return the same value `x` for the same `seed` and `slot` and possible future modifications of `validators` forever in phase 0, and until the ~1 year deletion delay in phase 2 and in the future.
**Invariant**: if `get_shuffling(seed, validators, slot)` returns some value `x` for some `slot <= state.slot + ENTRY_EXIT_DELAY`, it should return the same value `x` for the same `seed` and `slot` and possible future modifications of `validators` forever in phase 0, and until the ~1 year deletion delay in phase 2 and in the future.
**Note**: this definition and the next few definitions make heavy use of repetitive computing. Production implementations are expected to appropriately use caching/memoization to avoid redoing work.
@ -935,7 +942,7 @@ def get_current_epoch_committee_count_per_slot(state: BeaconState) -> int:
```python
def get_crosslink_committees_at_slot(state: BeaconState,
slot: int) -> List[Tuple[List[int], int]]:
slot: SlotNumber) -> List[Tuple[List[ValidatorIndex], ShardNumber]]:
"""
Returns the list of ``(committee, shard)`` tuples for the ``slot``.
"""
@ -947,7 +954,7 @@ def get_crosslink_committees_at_slot(state: BeaconState,
if slot < state_epoch_slot:
committees_per_slot = get_previous_epoch_committee_count_per_slot(state)
shuffling = get_shuffling(
state.previous_epoch_randao_mix,
state.previous_epoch_seed,
state.validator_registry,
state.previous_epoch_calculation_slot,
)
@ -955,7 +962,7 @@ def get_crosslink_committees_at_slot(state: BeaconState,
else:
committees_per_slot = get_current_epoch_committee_count_per_slot(state)
shuffling = get_shuffling(
state.current_epoch_randao_mix,
state.current_epoch_seed,
state.validator_registry,
state.current_epoch_calculation_slot,
)
@ -976,7 +983,7 @@ def get_crosslink_committees_at_slot(state: BeaconState,
```python
def get_block_root(state: BeaconState,
slot: int) -> Bytes32:
slot: SlotNumber) -> Bytes32:
"""
Returns the block root at a recent ``slot``.
"""
@ -991,7 +998,7 @@ def get_block_root(state: BeaconState,
```python
def get_randao_mix(state: BeaconState,
slot: int) -> Bytes32:
slot: SlotNumber) -> Bytes32:
"""
Returns the randao mix at a recent ``slot``.
"""
@ -1000,11 +1007,26 @@ def get_randao_mix(state: BeaconState,
return state.latest_randao_mixes[slot % LATEST_RANDAO_MIXES_LENGTH]
```
#### `get_active_index_root`
```python
def get_active_index_root(state: BeaconState,
slot: SlotNumber) -> Bytes32:
"""
Returns the index root at a recent ``slot``.
"""
state_epoch = state.slot // EPOCH_LENGTH
given_epoch = slot // EPOCH_LENGTH
assert state_epoch < given_epoch + LATEST_INDEX_ROOTS_LENGTH
assert given_epoch <= state_epoch
return state.latest_index_roots[given_epoch % LATEST_INDEX_ROOTS_LENGTH]
```
#### `get_beacon_proposer_index`
```python
def get_beacon_proposer_index(state: BeaconState,
slot: int) -> int:
slot: SlotNumber) -> ValidatorIndex:
"""
Returns the beacon proposer index for the ``slot``.
"""
@ -1030,7 +1052,7 @@ def merkle_root(values: List[Bytes32]) -> Bytes32:
```python
def get_attestation_participants(state: BeaconState,
attestation_data: AttestationData,
aggregation_bitfield: bytes) -> List[int]:
aggregation_bitfield: bytes) -> List[ValidatorIndex]:
"""
Returns the participant indices at for the ``attestation_data`` and ``aggregation_bitfield``.
"""
@ -1040,7 +1062,7 @@ def get_attestation_participants(state: BeaconState,
assert attestation_data.shard in [shard for _, shard in crosslink_committees]
crosslink_committee = [committee for committee, shard in crosslink_committees if shard == attestation_data.shard][0]
assert len(aggregation_bitfield) == (len(committee) + 7) // 8
assert len(aggregation_bitfield) == (len(crosslink_committee) + 7) // 8
# Find the participating attesters in the committee
participants = []
@ -1058,7 +1080,7 @@ def get_attestation_participants(state: BeaconState,
#### `get_effective_balance`
```python
def get_effective_balance(state: State, index: int) -> int:
def get_effective_balance(state: State, index: ValidatorIndex) -> Gwei:
"""
Returns the effective balance (also known as "balance at stake") for a ``validator`` with the given ``index``.
"""
@ -1069,7 +1091,7 @@ def get_effective_balance(state: State, index: int) -> int:
```python
def get_fork_version(fork: Fork,
slot: int) -> int:
slot: SlotNumber) -> int:
if slot < fork.slot:
return fork.previous_version
else:
@ -1080,7 +1102,7 @@ def get_fork_version(fork: Fork,
```python
def get_domain(fork: Fork,
slot: int,
slot: SlotNumber,
domain_type: int) -> int:
return get_fork_version(
fork,
@ -1156,7 +1178,7 @@ def is_surround_vote(attestation_data_1: AttestationData,
```python
def integer_squareroot(n: int) -> int:
"""
The largest integer ``x`` such that ``x**2`` is less than ``n``.
The largest integer ``x`` such that ``x**2`` is less than or equal to ``n``.
"""
assert n >= 0
x = n
@ -1167,6 +1189,17 @@ def integer_squareroot(n: int) -> int:
return x
```
#### `entry_exit_effect_slot`
```python
def entry_exit_effect_slot(n: int) -> int:
"""
An entry or exit triggered in the slot given by the input takes effect at
the slot given by the output.
"""
return (n - n % EPOCH_LENGTH) + EPOCH_LENGTH + ENTRY_EXIT_DELAY
```
#### `bls_verify`
`bls_verify` is a function for verifying a BLS signature, defined in the [BLS Signature spec](https://github.com/ethereum/eth2.0-specs/blob/master/specs/bls_signature.md#bls_verify).
@ -1228,7 +1261,6 @@ def get_initial_beacon_state(initial_validator_deposits: List[Deposit],
validator_balances=[],
validator_registry_update_slot=GENESIS_SLOT,
validator_registry_exit_count=0,
validator_registry_delta_chain_tip=ZERO_HASH,
# Randomness and committees
latest_randao_mixes=[ZERO_HASH for _ in range(LATEST_RANDAO_MIXES_LENGTH)],
@ -1237,8 +1269,8 @@ def get_initial_beacon_state(initial_validator_deposits: List[Deposit],
current_epoch_start_shard=GENESIS_START_SHARD,
previous_epoch_calculation_slot=GENESIS_SLOT,
current_epoch_calculation_slot=GENESIS_SLOT,
previous_epoch_randao_mix=ZERO_HASH,
current_epoch_randao_mix=ZERO_HASH,
previous_epoch_seed=ZERO_HASH,
current_epoch_seed=ZERO_HASH,
# Custody challenges
custody_challenges=[],
@ -1252,6 +1284,7 @@ def get_initial_beacon_state(initial_validator_deposits: List[Deposit],
# Recent state
latest_crosslinks=[Crosslink(slot=GENESIS_SLOT, shard_block_root=ZERO_HASH) for _ in range(SHARD_COUNT)],
latest_block_roots=[ZERO_HASH for _ in range(LATEST_BLOCK_ROOTS_LENGTH)],
latest_index_roots=[ZERO_HASH for _ in range(LATEST_INDEX_ROOTS_LENGTH)],
latest_penalized_balances=[0 for _ in range(LATEST_PENALIZED_EXIT_LENGTH)],
latest_attestations=[],
batched_block_roots=[],
@ -1285,8 +1318,8 @@ First, a helper function:
```python
def validate_proof_of_possession(state: BeaconState,
pubkey: Bytes48,
proof_of_possession: Bytes96,
pubkey: BLSPubkey,
proof_of_possession: BLSSignature,
withdrawal_credentials: Bytes32) -> bool:
proof_of_possession_data = DepositInput(
pubkey=pubkey,
@ -1310,9 +1343,9 @@ Now, to add a [validator](#dfn-validator) or top up an existing [validator](#dfn
```python
def process_deposit(state: BeaconState,
pubkey: Bytes48,
amount: int,
proof_of_possession: Bytes96,
pubkey: BLSPubkey,
amount: Gwei,
proof_of_possession: BLSSignature,
withdrawal_credentials: Bytes32) -> None:
"""
Process a deposit from Ethereum 1.0.
@ -1333,7 +1366,6 @@ def process_deposit(state: BeaconState,
validator = Validator(
pubkey=pubkey,
withdrawal_credentials=withdrawal_credentials,
proposer_slots=0,
activation_slot=FAR_FUTURE_SLOT,
exit_slot=FAR_FUTURE_SLOT,
withdrawal_slot=FAR_FUTURE_SLOT,
@ -1360,52 +1392,34 @@ def process_deposit(state: BeaconState,
Note: All functions in this section mutate `state`.
```python
def activate_validator(state: BeaconState, index: int, genesis: bool) -> None:
def activate_validator(state: BeaconState, index: ValidatorIndex, genesis: bool) -> None:
validator = state.validator_registry[index]
validator.activation_slot = GENESIS_SLOT if genesis else (state.slot + ENTRY_EXIT_DELAY)
state.validator_registry_delta_chain_tip = hash_tree_root(
ValidatorRegistryDeltaBlock(
latest_registry_delta_root=state.validator_registry_delta_chain_tip,
validator_index=index,
pubkey=validator.pubkey,
slot=validator.activation_slot,
flag=ACTIVATION,
)
)
validator.activation_slot = GENESIS_SLOT if genesis else entry_exit_effect_slot(state.slot)
```
```python
def initiate_validator_exit(state: BeaconState, index: int) -> None:
def initiate_validator_exit(state: BeaconState, index: ValidatorIndex) -> None:
validator = state.validator_registry[index]
validator.status_flags |= INITIATED_EXIT
```
```python
def exit_validator(state: BeaconState, index: int) -> None:
def exit_validator(state: BeaconState, index: ValidatorIndex) -> None:
validator = state.validator_registry[index]
# The following updates only occur if not previous exited
if validator.exit_slot <= state.slot + ENTRY_EXIT_DELAY:
if validator.exit_slot <= entry_exit_effect_slot(state.slot):
return
validator.exit_slot = state.slot + ENTRY_EXIT_DELAY
validator.exit_slot = entry_exit_effect_slot(state.slot)
state.validator_registry_exit_count += 1
validator.exit_count = state.validator_registry_exit_count
state.validator_registry_delta_chain_tip = hash_tree_root(
ValidatorRegistryDeltaBlock(
latest_registry_delta_root=state.validator_registry_delta_chain_tip,
validator_index=index,
pubkey=validator.pubkey,
slot=validator.exit_slot,
flag=EXIT,
)
)
```
```python
def penalize_validator(state: BeaconState, index: int) -> None:
def penalize_validator(state: BeaconState, index: ValidatorIndex) -> None:
exit_validator(state, index)
validator = state.validator_registry[index]
state.latest_penalized_balances[(state.slot // EPOCH_LENGTH) % LATEST_PENALIZED_EXIT_LENGTH] += get_effective_balance(state, index)
@ -1418,7 +1432,7 @@ def penalize_validator(state: BeaconState, index: int) -> None:
```
```python
def prepare_validator_for_withdrawal(state: BeaconState, index: int) -> None:
def prepare_validator_for_withdrawal(state: BeaconState, index: ValidatorIndex) -> None:
validator = state.validator_registry[index]
validator.status_flags |= WITHDRAWABLE
```
@ -1430,7 +1444,6 @@ Below are the processing steps that happen at every slot.
### Misc counters
* Set `state.slot += 1`.
* Set `state.validator_registry[get_beacon_proposer_index(state, state.slot)].proposer_slots += 1`.
* Set `state.latest_randao_mixes[state.slot % LATEST_RANDAO_MIXES_LENGTH] = state.latest_randao_mixes[(state.slot - 1) % LATEST_RANDAO_MIXES_LENGTH]`
### Block roots
@ -1456,8 +1469,8 @@ Below are the processing steps that happen at every `block`.
### RANDAO
* Let `proposer = state.validator_registry[get_beacon_proposer_index(state, state.slot)]`.
* Verify that `bls_verify(pubkey=proposer.pubkey, message=int_to_bytes32(proposer.proposer_slots), signature=block.randao_reveal, domain=get_domain(state.fork, state.slot, DOMAIN_RANDAO))`.
* Set `state.latest_randao_mixes[state.slot % LATEST_RANDAO_MIXES_LENGTH] = hash(state.latest_randao_mixes[state.slot % LATEST_RANDAO_MIXES_LENGTH] + block.randao_reveal)`.
* Verify that `bls_verify(pubkey=proposer.pubkey, message=int_to_bytes32(state.slot // EPOCH_LENGTH), signature=block.randao_reveal, domain=get_domain(state.fork, state.slot, DOMAIN_RANDAO))`.
* Set `state.latest_randao_mixes[state.slot % LATEST_RANDAO_MIXES_LENGTH] = xor(state.latest_randao_mixes[state.slot % LATEST_RANDAO_MIXES_LENGTH], hash(block.randao_reveal))`.
### Eth1 data
@ -1529,7 +1542,7 @@ For each `deposit` in `block.body.deposits`:
* Verify that `verify_merkle_branch(hash(serialized_deposit_data), deposit.branch, DEPOSIT_CONTRACT_TREE_DEPTH, deposit.index, state.latest_eth1_data.deposit_root)` is `True`.
```python
def verify_merkle_branch(leaf: Bytes32, branch: [Bytes32], depth: int, index: int, root: Bytes32) -> bool:
def verify_merkle_branch(leaf: Bytes32, branch: List[Bytes32], depth: int, index: int, root: Bytes32) -> bool:
value = leaf
for i in range(depth):
if index // (2**i) % 2:
@ -1558,7 +1571,7 @@ Verify that `len(block.body.exits) <= MAX_EXITS`.
For each `exit` in `block.body.exits`:
* Let `validator = state.validator_registry[exit.validator_index]`.
* Verify that `validator.exit_slot > state.slot + ENTRY_EXIT_DELAY`.
* Verify that `validator.exit_slot > entry_exit_effect_slot(state.slot)`.
* Verify that `state.slot >= exit.slot`.
* Let `exit_message = hash_tree_root(Exit(slot=exit.slot, validator_index=exit.validator_index, signature=EMPTY_SIGNATURE))`.
* Verify that `bls_verify(pubkey=validator.pubkey, message=exit_message, signature=exit.signature, domain=get_domain(state.fork, exit.slot, DOMAIN_EXIT))`.
@ -1709,12 +1722,14 @@ def process_ejections(state: BeaconState) -> None:
exit_validator(state, index)
```
### Validator registry
### Validator registry and shuffling seed data
First, update `previous_epoch_calculation_slot` and `previous_epoch_start_shard`:
First, update the following:
* Set `state.previous_epoch_calculation_slot = state.current_epoch_calculation_slot`
* Set `state.previous_epoch_start_shard = state.current_epoch_start_shard`
* Set `state.previous_epoch_seed = state.current_epoch_seed`
* Set `state.latest_index_roots[epoch % LATEST_INDEX_ROOTS_LENGTH] = hash_tree_root(get_active_validator_indices(state, state.slot))`
If the following are satisfied:
@ -1743,7 +1758,7 @@ def update_validator_registry(state: BeaconState) -> None:
# Activate validators within the allowable balance churn
balance_churn = 0
for index, validator in enumerate(state.validator_registry):
if validator.activation_slot > state.slot + ENTRY_EXIT_DELAY and state.validator_balances[index] >= MAX_DEPOSIT_AMOUNT:
if validator.activation_slot > entry_exit_effect_slot(state.slot) and state.validator_balances[index] >= MAX_DEPOSIT_AMOUNT:
# Check the balance churn would be within the allowance
balance_churn += get_effective_balance(state, index)
if balance_churn > max_balance_churn:
@ -1755,7 +1770,7 @@ def update_validator_registry(state: BeaconState) -> None:
# Exit validators within the allowable balance churn
balance_churn = 0
for index, validator in enumerate(state.validator_registry):
if validator.exit_slot > state.slot + ENTRY_EXIT_DELAY and validator.status_flags & INITIATED_EXIT:
if validator.exit_slot > entry_exit_effect_slot(state.slot) and validator.status_flags & INITIATED_EXIT:
# Check the balance churn would be within the allowance
balance_churn += get_effective_balance(state, index)
if balance_churn > max_balance_churn:
@ -1769,15 +1784,19 @@ def update_validator_registry(state: BeaconState) -> None:
and perform the following updates:
* Set `state.previous_epoch_randao_mix = state.current_epoch_randao_mix`
* Set `state.current_epoch_calculation_slot = state.slot`
* Set `state.current_epoch_start_shard = (state.current_epoch_start_shard + get_current_epoch_committee_count_per_slot(state) * EPOCH_LENGTH) % SHARD_COUNT`
* Set `state.current_epoch_randao_mix = get_randao_mix(state, state.current_epoch_calculation_slot - SEED_LOOKAHEAD)`
* Set `state.current_epoch_seed = hash(get_randao_mix(state, state.current_epoch_calculation_slot - SEED_LOOKAHEAD) + get_active_index_root(state, state.current_epoch_calculation_slot))`
If a validator registry update does _not_ happen do the following:
* Let `epochs_since_last_registry_change = (state.slot - state.validator_registry_update_slot) // EPOCH_LENGTH`.
* If `epochs_since_last_registry_change` is an exact power of 2, set `state.current_epoch_calculation_slot = state.slot` and `state.current_epoch_randao_mix = state.latest_randao_mixes[(state.current_epoch_calculation_slot - SEED_LOOKAHEAD) % LATEST_RANDAO_MIXES_LENGTH]`. Note that `state.current_epoch_start_shard` is left unchanged.
* If `epochs_since_last_registry_change` is an exact power of 2:
* Set `state.current_epoch_calculation_slot = state.slot`.
* Set `state.current_epoch_seed = hash(get_randao_mix(state, state.current_epoch_calculation_slot - SEED_LOOKAHEAD) + get_active_index_root(state, state.current_epoch_calculation_slot))`.
* _Note_ that `state.current_epoch_start_shard` is left unchanged.
**Invariant**: the active index root that is hashed into the shuffling seed actually is the `hash_tree_root` of the validator set that is used for that epoch.
Regardless of whether or not a validator set change happens, run the following:
@ -1800,8 +1819,8 @@ def process_penalties_and_exits(state: BeaconState) -> None:
def eligible(index):
validator = state.validator_registry[index]
if validator.penalized_slot <= state.slot:
PENALIZED_WITHDRAWAL_TIME = LATEST_PENALIZED_EXIT_LENGTH * EPOCH_LENGTH // 2
return state.slot >= validator.penalized_slot + PENALIZED_WITHDRAWAL_TIME
penalized_withdrawal_time = LATEST_PENALIZED_EXIT_LENGTH * EPOCH_LENGTH // 2
return state.slot >= validator.penalized_slot + penalized_withdrawal_time
else:
return state.slot >= validator.exit_slot + MIN_VALIDATOR_WITHDRAWAL_TIME
@ -1818,7 +1837,8 @@ def process_penalties_and_exits(state: BeaconState) -> None:
### Final updates
* Let `e = state.slot // EPOCH_LENGTH`. Set `state.latest_penalized_balances[(e+1) % LATEST_PENALIZED_EXIT_LENGTH] = state.latest_penalized_balances[e % LATEST_PENALIZED_EXIT_LENGTH]`
* Let `epoch = state.slot // EPOCH_LENGTH`.
* Set `state.latest_penalized_balances[(epoch+1) % LATEST_PENALIZED_EXIT_LENGTH] = state.latest_penalized_balances[epoch % LATEST_PENALIZED_EXIT_LENGTH]`.
* Remove any `attestation` in `state.latest_attestations` such that `attestation.data.slot < state.slot - EPOCH_LENGTH`.
## State root processing

32
specs/simple-serialize.md
View File

@ -43,17 +43,19 @@ protocol for use in the Ethereum 2.0 Beacon Chain.
The core feature of `ssz` is the simplicity of the serialization with low
overhead.
## Terminology
## Variables and Functions
| Term | Definition |
|:-------------|:-----------------------------------------------------------------------------------------------|
| `little` | Little endian. |
| `byte_order` | Specifies [endianness](https://en.wikipedia.org/wiki/Endianness): big endian or little endian. |
| `byteorder` | Specifies [endianness](https://en.wikipedia.org/wiki/Endianness): big endian or little endian. |
| `len` | Length/number of bytes. |
| `to_bytes` | Convert to bytes. Should take parameters ``size`` and ``byte_order``. |
| `from_bytes` | Convert from bytes to object. Should take ``bytes`` and ``byte_order``. |
| `to_bytes` | Convert to bytes. Should take parameters ``size`` and ``byteorder``. |
| `from_bytes` | Convert from bytes to object. Should take ``bytes`` and ``byteorder``. |
| `value` | The value to serialize. |
| `rawbytes` | Raw serialized bytes. |
| `deserialized_object` | The deserialized data in the data structure of your programming language. |
| `new_index` | An index to keep track the latest position where the `rawbytes` have been deserialized. |
## Constants
@ -72,7 +74,6 @@ overhead.
|:---------:|:-----------------------------------------------------------|
| `uintN` | Type of `N` bits unsigned integer, where ``N % 8 == 0``. |
Convert directly to bytes the size of the int. (e.g. ``uint16 = 2 bytes``)
All integers are serialized as **little endian**.
@ -142,9 +143,7 @@ Lists are a collection of elements of the same homogeneous type.
|:--------------------------------------------|:----------------------------|
| Length of serialized list fits into 4 bytes | ``len(serialized) < 2**32`` |
1. Serialize all list elements individually and concatenate them.
2. Prefix the concatenation with its length encoded as a `4-byte` **little-endian** unsigned integer.
**Example in Python**
@ -169,7 +168,6 @@ A container represents a heterogenous, associative collection of key-value pairs
To serialize a container, obtain the list of its field's names in the specified order. For each field name in this list, obtain the corresponding value and serialize it. Tightly pack the complete set of serialized values in the same order as the field names into a buffer. Calculate the size of this buffer of serialized bytes and encode as a `4-byte` **little endian** `uint32`. Prepend the encoded length to the buffer. The result of this concatenation is the final serialized value of the container.
| Check to perform | Code |
|:--------------------------------------------|:----------------------------|
| Length of serialized fields fits into 4 bytes | ``len(serialized) < 2**32`` |
@ -217,14 +215,21 @@ The decoding requires knowledge of the type of the item to be decoded. When
performing decoding on an entire serialized string, it also requires knowledge
of the order in which the objects have been serialized.
Note: Each return will provide ``deserialized_object, new_index`` keeping track
of the new index.
Note: Each return will provide:
- `deserialized_object`
- `new_index`
At each step, the following checks should be made:
| Check to perform | Check |
|:-------------------------|:-----------------------------------------------------------|
| Ensure sufficient length | ``length(rawbytes) >= current_index + deserialize_length`` |
| Ensure sufficient length | ``len(rawbytes) >= current_index + deserialize_length`` |
At the final step, the following checks should be made:
| Check to perform | Check |
|:-------------------------|:-------------------------------------|
| Ensure no extra length | `new_index == len(rawbytes)` |
#### uint
@ -293,7 +298,7 @@ entire length of the list.
| Check to perform | code |
|:------------------------------------------|:----------------------------------------------------------------|
| rawbytes has enough left for length | ``len(rawbytes) > current_index + LENGTH_BYTES`` |
| ``rawbytes`` has enough left for length | ``len(rawbytes) > current_index + LENGTH_BYTES`` |
| list is not greater than serialized bytes | ``len(rawbytes) > current_index + LENGTH_BYTES + total_length`` |
```python
@ -321,7 +326,7 @@ Instantiate a container with the full set of deserialized data, matching each me
| Check to perform | code |
|:------------------------------------------|:----------------------------------------------------------------|
| rawbytes has enough left for length | ``len(rawbytes) > current_index + LENGTH_BYTES`` |
| ``rawbytes`` has enough left for length | ``len(rawbytes) > current_index + LENGTH_BYTES`` |
| list is not greater than serialized bytes | ``len(rawbytes) > current_index + LENGTH_BYTES + total_length`` |
To deserialize:
@ -440,6 +445,5 @@ return hash(b''.join([hash_tree_root(getattr(x, field)) for field in value.field
| Go | [ https://github.com/prysmaticlabs/prysm/tree/master/shared/ssz ](https://github.com/prysmaticlabs/prysm/tree/master/shared/ssz) | Go implementation of SSZ mantained by Prysmatic Labs |
| Swift | [ https://github.com/yeeth/SimpleSerialize.swift ](https://github.com/yeeth/SimpleSerialize.swift) | Swift implementation maintained SSZ |
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

356
specs/validator/0_beacon-chain-validator.md Normal file
View File

@ -0,0 +1,356 @@
# Ethereum 2.0 Phase 0 -- Honest Validator
__NOTICE__: This document is a work-in-progress for researchers and implementers. This is an accompanying document to [Ethereum 2.0 Phase 0 -- The Beacon Chain](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md) that describes the expected actions of a "validator" participating in the Ethereum 2.0 protocol.
## Table of Contents
<!-- TOC -->
- [Ethereum 2.0 Phase 0 -- Honest Validator](#ethereum-20-phase-0----honest-validator)
- [Table of Contents](#table-of-contents)
- [Introduction](#introduction)
- [Prerequisites](#prerequisites)
- [Constants](#constants)
- [Misc](#misc)
- [Becoming a validator](#becoming-a-validator)
- [Initialization](#initialization)
- [BLS public key](#bls-public-key)
- [BLS withdrawal key](#bls-withdrawal-key)
- [Submit deposit](#submit-deposit)
- [Process deposit](#process-deposit)
- [Validator index](#validator-index)
- [Activation](#activation)
- [Beacon chain responsibilities](#beacon-chain-responsibilities)
- [Block proposal](#block-proposal)
- [Block header](#block-header)
- [Slot](#slot)
- [Parent root](#parent-root)
- [State root](#state-root)
- [Randao reveal](#randao-reveal)
- [Eth1 Data](#eth1-data)
- [Signature](#signature)
- [Block body](#block-body)
- [Proposer slashings](#proposer-slashings)
- [Casper slashings](#casper-slashings)
- [Attestations](#attestations)
- [Deposits](#deposits)
- [Exits](#exits)
- [Attestations](#attestations-1)
- [Attestation data](#attestation-data)
- [Slot](#slot-1)
- [Shard](#shard)
- [Beacon block root](#beacon-block-root)
- [Epoch boundary root](#epoch-boundary-root)
- [Shard block root](#shard-block-root)
- [Latest crosslink root](#latest-crosslink-root)
- [Justified slot](#justified-slot)
- [Justified block root](#justified-block-root)
- [Construct attestation](#construct-attestation)
- [Data](#data)
- [Participation bitfield](#participation-bitfield)
- [Custody bitfield](#custody-bitfield)
- [Aggregate signature](#aggregate-signature)
- [How to avoid slashing](#how-to-avoid-slashing)
- [Proposal slashing](#proposal-slashing)
- [Casper slashing](#casper-slashing)
<!-- /TOC -->
## Introduction
This document represents the expected behavior of an "honest validator" with respect to Phase 0 of the Ethereum 2.0 protocol. This document does not distinguish between a "node" (ie. the functionality of following and reading the beacon chain) and a "validator client" (ie. the functionality of actively participating in consensus). The separation of concerns between these (potentially) two pieces of software is left as a design decision that is out of scope.
A validator is an entity that participates in the consensus of the Ethereum 2.0 protocol. This is an optional role for users in which they can post ETH as collateral and verify and attest to the validity of blocks to seek financial returns in exchange for building and securing the protocol. This is similar to proof of work networks in which a miner provides collateral in the form of hardware/hash-power to seek returns in exchange for building and securing the protocol.
## Prerequisites
All terminology, constants, functions, and protocol mechanics defined in the [Phase 0 -- The Beacon Chain](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md) doc are requisite for this document and used throughout. Please see the Phase 0 doc before continuing and use as a reference throughout.
## Constants
### Misc
| Name | Value | Unit | Duration |
| - | - | :-: | :-: |
| `ETH1_FOLLOW_DISTANCE` | `2**10` (= 1,024) | blocks | ~4 hours |
## Becoming a validator
### Initialization
A validator must initialize many parameters locally before submitting a deposit and joining the validator registry.
#### BLS public key
Validator public keys are [G1 points](https://github.com/ethereum/eth2.0-specs/blob/master/specs/bls_signature.md#g1-points) on the [BLS12-381 curve](https://z.cash/blog/new-snark-curve). A private key, `privkey`, must be securely generated along with the resultant `pubkey`. This `privkey` must be "hot", that is, constantly available to sign data throughout the lifetime of the validator.
#### BLS withdrawal key
A secondary withdrawal private key, `withdrawal_privkey`, must also be securely generated along with the resultant `withdrawal_pubkey`. This `withdrawal_privkey` does not have to be available for signing during the normal lifetime of a validator and can live in "cold storage".
The validator constructs their `withdrawal_credentials` through the following:
* Set `withdrawal_credentials[:1] == BLS_WITHDRAWAL_PREFIX_BYTE`.
* Set `withdrawal_credentials[1:] == hash(withdrawal_pubkey)[1:]`.
### Submit deposit
In phase 0, all incoming validator deposits originate from the Ethereum 1.0 PoW chain. Deposits are made to the [deposit contract](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#ethereum-10-deposit-contract) located at `DEPOSIT_CONTRACT_ADDRESS`.
To submit a deposit:
* Pack the validator's [initialization parameters](#initialization) into `deposit_input`, a [`DepositInput`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#depositinput) object.
* Set `deposit_input.proof_of_possession = EMPTY_SIGNATURE`.
* Let `proof_of_possession` be the result of `bls_sign` of the `hash_tree_root(deposit_input)` with `domain=DOMAIN_DEPOSIT`.
* Set `deposit_input.proof_of_possession = proof_of_possession`.
* Let `amount` be the amount in Gwei to be deposited by the validator where `MIN_DEPOSIT_AMOUNT <= amount <= MAX_DEPOSIT_AMOUNT`.
* Send a transaction on the Ethereum 1.0 chain to `DEPOSIT_CONTRACT_ADDRESS` executing `deposit` along with `deposit_input` as the singular `bytes` input along with a deposit `amount` in Gwei.
_Note_: Deposits made for the same `pubkey` are treated as for the same validator. A singular `Validator` will be added to `state.validator_registry` with each additional deposit amount added to the validator's balance. A validator can only be activated when total deposits for the validator pubkey meet or exceed `MAX_DEPOSIT_AMOUNT`.
### Process deposit
Deposits cannot be processed into the beacon chain until the eth1.0 block in which they were deposited or any of its ancestors is added to the beacon chain `state.eth1_data`. This takes _a minimum_ of `ETH1_FOLLOW_DISTANCE` eth1.0 blocks (~4 hours) plus `ETH1_DATA_VOTING_PERIOD` slots (~1.7 hours). Once the necessary eth1.0 data is added, the deposit will normally be added to a beacon chain block and processed into the `state.validator_registry` within an epoch or two. The validator is then in a queue to be activated.
### Validator index
Once a validator has been processed and added to the state's `validator_registry`, the validator's `validator_index` is defined by the index into the registry at which the [`ValidatorRecord`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#validatorrecord) contains the `pubkey` specified in the validator's deposit. A validator's `validator_index` is guaranteed to not change from the time of initial deposit until the validator exists and fully withdraws. This `validator_index` is used throughout the specification to dictate validator roles and responsibilities at any point and should be stored locally.
### Activation
In normal operation, the validator is quickly activated at which point the validator is added to the shuffling and begins validation after an additional `ENTRY_EXIT_DELAY` slots.
The function [`is_active_validator`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#is_active_validator) can be used to check if a validator is active at a given slot. Usage is as follows:
```python
validator = state.validator_registry[validator_index]
is_active = is_active_validator(validator, slot)
```
Once a validator is active, the validator is assigned [responsibilities](#beacon-chain-responsibilities) until exited.
_Note_: There is a maximum validator churn per finalized epoch so the delay until activation is variable depending upon finality, total active validator balance, and the number of validators in the queue to be activated.
## Beacon chain responsibilities
A validator has two primary responsibilities to the beacon chain -- [proposing blocks](block-proposal) and [creating attestations](attestations-1). Proposals happen infrequently, whereas attestations should be created once per epoch.
### Block proposal
A validator is expected to propose a [`BeaconBlock`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#beaconblock) at the beginning of any slot during which `get_beacon_proposer_index(state, slot)` returns the validator's `validator_index`. To propose, the validator selects the `BeaconBlock`, `parent`, that in their view of the fork choice is the head of the chain during `slot`. The validator is to create, sign, and broadcast a `block` that is a child of `parent` that creates a valid [beacon chain state transition](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#beacon-chain-state-transition-function).
#### Block header
##### Slot
Set `block.slot = slot` where `slot` is the current slot at which the validator has been selected to propose. The `parent` selected must satisfy that `parent.slot < block.slot`.
_Note:_ there might be "skipped" slots between the `parent` and `block`. These skipped slots are processed in the state transition function without per-block processing.
##### Parent root
Set `block.parent_root = hash_tree_root(parent)`.
##### State root
Set `block.state_root = hash_tree_root(state)` of the resulting `state` of the `parent -> block` state transition.
_Note_: To calculate `state_root`, the validator should first run the state transition function on an unsigned `block` containing a stub for the `state_root`. It is useful to be able to run a state transition function that does _not_ validate signatures for this purpose.
##### Randao reveal
Set `block.randao_reveal = epoch_signature` where `epoch_signature` is defined as:
```python
epoch_signature = bls_sign(
privkey=validator.privkey, # privkey store locally, not in state
message=int_to_bytes32(block.slot // EPOCH_LENGTH),
domain=get_domain(
fork_data, # `fork_data` is the fork_data at the slot `block.slot`
block.slot,
DOMAIN_RANDAO,
)
)
```
##### Eth1 Data
`block.eth1_data` is a mechanism used by block proposers vote on a recent Ethereum 1.0 block hash and an associated deposit root found in the Ethereum 1.0 deposit contract. When consensus is formed, `state.latest_eth1_data` is updated, and validator deposits up to this root can be processed.
* Let `D` be the set of `Eth1DataVote` objects `vote` in `state.eth1_data_votes` where:
* `vote.eth1_data.block_hash` is the hash of an eth1.0 block that is (i) part of the canonical chain, (ii) >= `ETH1_FOLLOW_DISTANCE` blocks behind the head, and (iii) newer than `state.latest_eth1_data.block_data`.
* `vote.eth1_data.deposit_root` is the deposit root of the eth1.0 deposit contract at the block defined by `vote.eth1_data.block_hash`.
* If `D` is empty:
* Let `block_hash` be the block hash of the `ETH1_FOLLOW_DISTANCE`th ancestor of the head of the canonical eth1.0 chain.
* Let `deposit_root` be the deposit root of the eth1.0 deposit contract at the block defined by `block_hash`.
* If `D` is nonempty:
* Let `best_vote` be the member of `D` that has the highest `vote.eth1_data.vote_count`, breaking ties by favoring block hashes with higher associated block height.
* Let `block_hash = best_vote.eth1_data.block_hash`.
* Let `deposit_root = best_vote.eth1_data.deposit_root`.
* Set `block.eth1_data = Eth1Data(deposit_root=deposit_root, block_hash=block_hash)`.
##### Signature
Set `block.signature = signed_proposal_data` where `signed_proposal_data` is defined as:
```python
proposal_data = ProposalSignedData(
slot=slot,
shard=BEACON_CHAIN_SHARD_NUMBER,
block_root=hash_tree_root(block), # where `block.sigature == EMPTY_SIGNATURE
)
proposal_root = hash_tree_root(proposal_data)
signed_proposal_data = bls_sign(
privkey=validator.privkey, # privkey store locally, not in state
message=proposal_root,
domain=get_domain(
fork_data, # `fork_data` is the fork_data at the slot `block.slot`
block.slot,
DOMAIN_PROPOSAL,
)
)
```
#### Block body
##### Proposer slashings
Up to `MAX_PROPOSER_SLASHINGS` [`ProposerSlashing`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#proposerslashing) objects can be included in the `block`. The proposer slashings must satisfy the verification conditions found in [proposer slashings processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#proposer-slashings-1). The validator receives a small "whistleblower" reward for each proposer slashing found and included.
##### Casper slashings
Up to `MAX_CASPER_SLASHINGS` [`CasperSlashing`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#casperslashing) objects can be included in the `block`. The Casper slashings must satisfy the verification conditions found in [Casper slashings processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#casper-slashings-1). The validator receives a small "whistleblower" reward for each Casper slashing found and included.
##### Attestations
Up to `MAX_ATTESTATIONS` aggregate attestations can be included in the `block`. The attestations added must satisfy the verification conditions found in [attestation processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#attestations-1). To maximize profit, the validator should attempt to create aggregate attestations that include singular attestations from the largest number of validators whose signatures from the same epoch have not previously been added on chain.
##### Deposits
Up to `MAX_DEPOSITS` [`Deposit`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#deposit) objects can be included in the `block`. These deposits are constructed from the `Deposit` logs from the [Eth1.0 deposit contract](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#ethereum-10-deposit-contract) and must be processed in sequential order. The deposits included in the `block` must satisfy the verification conditions found in [deposits processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#deposits-1).
##### Exits
Up to `MAX_EXITS` [`Exit`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#exit) objects can be included in the `block`. The exits must satisfy the verification conditions found in [exits processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#exits-1).
### Attestations
A validator is expected to create, sign, and broadcast an attestation during each epoch. The slot during which the validator performs this role is any slot at which `get_shard_committees_at_slot(state, slot)` contains a committee that contains `validator_index`.
A validator should create and broadcast the attestation halfway through the `slot` during which the validator is assigned -- that is `SLOT_DURATION * 0.5` seconds after the start of `slot`.
#### Attestation data
First the validator should construct `attestation_data`, an [`AttestationData`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#attestationdata) object based upon the state at the assigned slot.
##### Slot
Set `attestation_data.slot = slot` where `slot` is the current slot of which the validator is a member of a committee.
##### Shard
Set `attestation_data.shard = shard` where `shard` is the shard associated with the validator's committee defined by `get_shard_committees_at_slot`.
##### Beacon block root
Set `attestation_data.beacon_block_root = hash_tree_root(head)` where `head` is the validator's view of the `head` block of the beacon chain during `slot`.
##### Epoch boundary root
Set `attestation_data.epoch_boundary_root = hash_tree_root(epoch_boundary)` where `epoch_boundary` is the block at the most recent epoch boundary in the chain defined by `head` -- i.e. the `BeaconBlock` with `slot == head.slot - head.slot % EPOCH_LENGTH`.
_Note:_ This can be looked up in the state using `get_block_root(state, head.slot - head.slot % EPOCH_LENGTH)`.
##### Shard block root
Set `attestation_data.shard_block_root = ZERO_HASH`.
_Note:_ This is a stub for phase 0.
##### Latest crosslink root
Set `attestation_data.latest_crosslink_root = state.latest_crosslinks[shard].shard_block_root` where `state` is the beacon state at `head` and `shard` is the validator's assigned shard.
##### Justified slot
Set `attestation_data.justified_slot = state.justified_slot` where `state` is the beacon state at `head`.
##### Justified block root
Set `attestation_data.justified_block_root = hash_tree_root(justified_block)` where `justified_block` is the block at `state.justified_slot` in the chain defined by `head`.
_Note:_ This can be looked up in the state using `get_block_root(state, justified_slot)`.
#### Construct attestation
Next the validator creates `attestation`, an [`Attestation`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#attestation) object.
##### Data
Set `attestation.data = attestation_data` where `attestation_data` is the `AttestationData` object defined in the previous section, [attestation data](#attestation-data).
##### Participation bitfield
* Let `aggregation_bitfield` be a byte array filled with zeros of length `(len(committee) + 7) // 8`.
* Let `index_into_committee` be the index into the validator's `committee` at which `validator_index` is located.
* Set `aggregation_bitfield[index_into_committee // 8] |= 2 ** (index_into_committee % 8)`.
* Set `attestation.aggregation_bitfield = aggregation_bitfield`.
_Note_: Calling `get_attestation_participants(state, attestation.data, attestation.aggregation_bitfield)` should return a list of length equal to 1, containing `validator_index`.
##### Custody bitfield
* Let `custody_bitfield` be a byte array filled with zeros of length `(len(committee) + 7) // 8`.
* Set `attestation.custody_bitfield = custody_bitfield`.
_Note:_ This is a stub for phase 0.
##### Aggregate signature
Set `attestation.aggregate_signature = signed_attestation_data` where `signed_attestation_data` is defined as:
```python
attestation_data_and_custody_bit = AttestationDataAndCustodyBit(
attestation.data,
False,
)
attestation_message_to_sign = hash_tree_root(attestation_data_and_custody_bit)
signed_attestation_data = bls_sign(
privkey=validator.privkey, # privkey store locally, not in state
message=attestation_message_to_sign,
domain=get_domain(
state.fork_data, # `state` is the state at `head`
state.slot,
DOMAIN_ATTESTATION,
)
)
```
## How to avoid slashing
"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 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
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`).
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.
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=slot` and `shard=BEACON_CHAIN_SHARD_NUMBER`.
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.
### Casper slashing
To avoid "Casper slashings", a validator must not sign two conflicting [`AttestationData`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#attestationdata) objects where conflicting is defined as a set of two attestations that satisfy either [`is_double_vote`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#is_double_vote) or [`is_surround_vote`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#is_surround_vote).
Specifically, when signing an `Attestation`, a validator should perform the following steps in the following order:
1. Save a record to hard disk that an attestation has been signed for source -- `attestation_data.justified_slot // EPOCH_LENGTH` -- and target -- `attestation_data.slot // EPOCH_LENGTH`.
2. Generate and broadcast attestation.
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 attestation and can effectively avoid slashing.