ethereum · djrtwo · Jun 30, 2019 · Jun 30, 2019
diff --git a/scripts/build_spec.py b/scripts/build_spec.py
@@ -6,7 +6,6 @@
 from argparse import ArgumentParser
 from typing import (
     Dict,
-    List,
     Optional,
 )
 
@@ -106,7 +105,7 @@ def apply_constants_preset(preset: Dict[str, Any]) -> None:
 
 
 def strip_comments(raw: str) -> str:
-    comment_line_regex = re.compile('^\s+# ')
+    comment_line_regex = re.compile(r'^\s+# ')
     lines = raw.split('\n')
     out = []
     for line in lines:

diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md
@@ -181,7 +181,7 @@ The following values are (non-configurable) constants used throughout the specif
 | `JUSTIFICATION_BITS_LENGTH` | `4` |
 | `ENDIANNESS` | `'little'` |
 
-* For the safety of crosslinks, `TARGET_COMMITTEE_SIZE` exceeds [the recommended minimum committee size of 111](https://vitalik.ca/files/Ithaca201807_Sharding.pdf); with sufficient active validators (at least `SLOTS_PER_EPOCH * TARGET_COMMITTEE_SIZE`), the shuffling algorithm ensures committee sizes of at least `TARGET_COMMITTEE_SIZE`. (Unbiasable randomness with a Verifiable Delay Function (VDF) will improve committee robustness and lower the safe minimum committee size.)
+- For the safety of crosslinks, `TARGET_COMMITTEE_SIZE` exceeds [the recommended minimum committee size of 111](https://vitalik.ca/files/Ithaca201807_Sharding.pdf); with sufficient active validators (at least `SLOTS_PER_EPOCH * TARGET_COMMITTEE_SIZE`), the shuffling algorithm ensures committee sizes of at least `TARGET_COMMITTEE_SIZE`. (Unbiasable randomness with a Verifiable Delay Function (VDF) will improve committee robustness and lower the safe minimum committee size.)
 
 ### Gwei values
 
@@ -215,7 +215,7 @@ The following values are (non-configurable) constants used throughout the specif
 | `MAX_EPOCHS_PER_CROSSLINK` | `2**6` (= 64) | epochs | ~7 hours |
 | `MIN_EPOCHS_TO_INACTIVITY_PENALTY` | `2**2` (= 4) | epochs | 25.6 minutes |
 
-* `MAX_EPOCHS_PER_CROSSLINK` should be a small constant times `SHARD_COUNT // SLOTS_PER_EPOCH`.
+- `MAX_EPOCHS_PER_CROSSLINK` should be a small constant times `SHARD_COUNT // SLOTS_PER_EPOCH`.
 
 ### State list lengths
 
@@ -236,7 +236,7 @@ The following values are (non-configurable) constants used throughout the specif
 | `INACTIVITY_PENALTY_QUOTIENT` | `2**25` (= 33,554,432) |
 | `MIN_SLASHING_PENALTY_QUOTIENT` | `2**5` (= 32) |
 
-* The `INACTIVITY_PENALTY_QUOTIENT` equals `INVERSE_SQRT_E_DROP_TIME**2` where `INVERSE_SQRT_E_DROP_TIME := 2**12 epochs` (about 18 days) is the time it takes the inactivity penalty to reduce the balance of non-participating validators to about `1/sqrt(e) ~= 60.6%`. Indeed, the balance retained by offline validators after `n` epochs is about `(1 - 1/INACTIVITY_PENALTY_QUOTIENT)**(n**2/2)`; so after `INVERSE_SQRT_E_DROP_TIME` epochs, it is roughly `(1 - 1/INACTIVITY_PENALTY_QUOTIENT)**(INACTIVITY_PENALTY_QUOTIENT/2) ~= 1/sqrt(e)`.
+- The `INACTIVITY_PENALTY_QUOTIENT` equals `INVERSE_SQRT_E_DROP_TIME**2` where `INVERSE_SQRT_E_DROP_TIME := 2**12 epochs` (about 18 days) is the time it takes the inactivity penalty to reduce the balance of non-participating validators to about `1/sqrt(e) ~= 60.6%`. Indeed, the balance retained by offline validators after `n` epochs is about `(1 - 1/INACTIVITY_PENALTY_QUOTIENT)**(n**2/2)`; so after `INVERSE_SQRT_E_DROP_TIME` epochs, it is roughly `(1 - 1/INACTIVITY_PENALTY_QUOTIENT)**(INACTIVITY_PENALTY_QUOTIENT/2) ~= 1/sqrt(e)`.
 
 ### Max operations per block
 
@@ -1116,9 +1116,9 @@ def slash_validator(state: BeaconState,
 
 Before the Ethereum 2.0 genesis has been triggered, and for every Ethereum 1.0 block, let `candidate_state = initialize_beacon_state_from_eth1(eth1_block_hash, eth1_timestamp, deposits)` where:
 
-* `eth1_block_hash` is the hash of the Ethereum 1.0 block
-* `eth1_timestamp` is the Unix timestamp corresponding to `eth1_block_hash`
-* `deposits` is the sequence of all deposits, ordered chronologically, up to the block with hash `eth1_block_hash`
+- `eth1_block_hash` is the hash of the Ethereum 1.0 block
+- `eth1_timestamp` is the Unix timestamp corresponding to `eth1_block_hash`
+- `deposits` is the sequence of all deposits, ordered chronologically, up to the block with hash `eth1_block_hash`
 
 ```python
 def initialize_beacon_state_from_eth1(eth1_block_hash: Hash,
@@ -1171,7 +1171,7 @@ Let `genesis_block = BeaconBlock(state_root=hash_tree_root(genesis_state))`.
 
 ## Beacon chain state transition function
 
-The post-state corresponding to a pre-state `state` and a block `block` is defined as `state_transition(state, block)`. State transitions that trigger an unhandled excpetion (e.g. a failed `assert` or an out-of-range list access) are considered invalid.
+The post-state corresponding to a pre-state `state` and a block `block` is defined as `state_transition(state, block)`. State transitions that trigger an unhandled exception (e.g. a failed `assert` or an out-of-range list access) are considered invalid.
 
 ```python
 def state_transition(state: BeaconState, block: BeaconBlock, validate_state_root: bool=False) -> BeaconState:

diff --git a/specs/core/0_deposit-contract.md b/specs/core/0_deposit-contract.md
@@ -48,8 +48,8 @@ The amount of ETH (rounded down to the closest Gwei) sent to the deposit contrac
 
 One of the `DepositData` fields is `withdrawal_credentials`. It is a commitment to credentials for withdrawing validator balance (e.g. to another validator, or to shards). The first byte of `withdrawal_credentials` is a version number. As of now, the only expected format is as follows:
 
-* `withdrawal_credentials[:1] == BLS_WITHDRAWAL_PREFIX_BYTE`
-* `withdrawal_credentials[1:] == hash(withdrawal_pubkey)[1:]` where `withdrawal_pubkey` is a BLS pubkey
+- `withdrawal_credentials[:1] == BLS_WITHDRAWAL_PREFIX_BYTE`
+- `withdrawal_credentials[1:] == hash(withdrawal_pubkey)[1:]` where `withdrawal_pubkey` is a BLS pubkey
 
 The private key corresponding to `withdrawal_pubkey` will be required to initiate a withdrawal. It can be stored separately until a withdrawal is required, e.g. in cold storage.
 

diff --git a/specs/core/0_fork-choice.md b/specs/core/0_fork-choice.md
@@ -41,9 +41,9 @@ This document is the beacon chain fork choice spec, part of Ethereum 2.0 Phase 0
 
 The head block root associated with a `store` is defined as `get_head(store)`. At genesis, let `store = get_genesis_store(genesis_state)` and update `store` by running:
 
-* `on_tick(time)` whenever `time > store.time` where `time` is the current Unix time
-* `on_block(block)` whenever a block `block` is received
-* `on_attestation(attestation)` whenever an attestation `attestation` is received
+- `on_tick(time)` whenever `time > store.time` where `time` is the current Unix time
+- `on_block(block)` whenever a block `block` is received
+- `on_attestation(attestation)` whenever an attestation `attestation` is received
 
 *Notes*:
 
@@ -188,7 +188,7 @@ def on_attestation(store: Store, attestation: Attestation) -> None:
     # Cannot calculate the current shuffling if have not seen the target
     assert target.root in store.blocks
 
-    # Attestations cannot be from future epochs. If they are, delay consideration until the epoch arrivesr
+    # Attestations cannot be from future epochs. If they are, delay consideration until the epoch arrives
     base_state = store.block_states[target.root].copy()
     assert store.time >= base_state.genesis_time + epoch_start_slot(target.epoch) * SECONDS_PER_SLOT
 

diff --git a/specs/core/1_custody-game.md b/specs/core/1_custody-game.md
@@ -56,18 +56,18 @@ This document details the beacon chain additions and changes in Phase 1 of Ether
 
 ## Terminology
 
-* **Custody game**—
-* **Custody period**—
-* **Custody chunk**—
-* **Custody chunk bit**—
-* **Custody chunk challenge**—
-* **Custody bit**—
-* **Custody bit challenge**—
-* **Custody key**—
-* **Custody key reveal**—
-* **Custody key mask**—
-* **Custody response**—
-* **Custody response deadline**—
+- **Custody game**—
+- **Custody period**—
+- **Custody chunk**—
+- **Custody chunk bit**—
+- **Custody chunk challenge**—
+- **Custody bit**—
+- **Custody bit challenge**—
+- **Custody key**—
+- **Custody key reveal**—
+- **Custody key mask**—
+- **Custody response**—
+- **Custody response deadline**—
 
 ## Constants
 
@@ -113,7 +113,6 @@ This document details the beacon chain additions and changes in Phase 1 of Ether
 | - | - |
 | `DOMAIN_CUSTODY_BIT_CHALLENGE` | `6` |
 
-
 ### TODO PLACEHOLDER
 
 | Name | Value |

diff --git a/specs/core/1_shard-data-chains.md b/specs/core/1_shard-data-chains.md
@@ -282,10 +282,10 @@ def compute_crosslink_data_root(blocks: Sequence[ShardBlock]) -> Bytes32:
 
 Let:
 
-* `beacon_blocks` be the `BeaconBlock` list such that `beacon_blocks[slot]` is the canonical `BeaconBlock` at slot `slot`
-* `beacon_state` be the canonical `BeaconState` after processing `beacon_blocks[-1]`
-* `valid_shard_blocks` be the list of valid `ShardBlock`, recursively defined
-* `candidate` be a candidate `ShardBlock` for which validity is to be determined by running `is_valid_shard_block`
+- `beacon_blocks` be the `BeaconBlock` list such that `beacon_blocks[slot]` is the canonical `BeaconBlock` at slot `slot`
+- `beacon_state` be the canonical `BeaconState` after processing `beacon_blocks[-1]`
+- `valid_shard_blocks` be the list of valid `ShardBlock`, recursively defined
+- `candidate` be a candidate `ShardBlock` for which validity is to be determined by running `is_valid_shard_block`
 
 ```python
 def is_valid_shard_block(beacon_blocks: Sequence[BeaconBlock],
@@ -349,9 +349,9 @@ def is_valid_shard_block(beacon_blocks: Sequence[BeaconBlock],
 
 Let:
 
-* `valid_shard_blocks` be the list of valid `ShardBlock`
-* `beacon_state` be the canonical `BeaconState`
-* `candidate` be a candidate `ShardAttestation` for which validity is to be determined by running `is_valid_shard_attestation`
+- `valid_shard_blocks` be the list of valid `ShardBlock`
+- `beacon_state` be the canonical `BeaconState`
+- `candidate` be a candidate `ShardAttestation` for which validity is to be determined by running `is_valid_shard_attestation`
 
 ```python
 def is_valid_shard_attestation(valid_shard_blocks: Sequence[ShardBlock],
@@ -376,11 +376,11 @@ def is_valid_shard_attestation(valid_shard_blocks: Sequence[ShardBlock],
 
 Let:
 
-* `shard` be a valid `Shard`
-* `shard_blocks` be the `ShardBlock` list such that `shard_blocks[slot]` is the canonical `ShardBlock` for shard `shard` at slot `slot`
-* `beacon_state` be the canonical `BeaconState`
-* `valid_attestations` be the set of valid `Attestation` objects, recursively defined
-* `candidate` be a candidate `Attestation` which is valid under Phase 0 rules, and for which validity is to be determined under Phase 1 rules by running `is_valid_beacon_attestation`
+- `shard` be a valid `Shard`
+- `shard_blocks` be the `ShardBlock` list such that `shard_blocks[slot]` is the canonical `ShardBlock` for shard `shard` at slot `slot`
+- `beacon_state` be the canonical `BeaconState`
+- `valid_attestations` be the set of valid `Attestation` objects, recursively defined
+- `candidate` be a candidate `Attestation` which is valid under Phase 0 rules, and for which validity is to be determined under Phase 1 rules by running `is_valid_beacon_attestation`
 
 ```python
 def is_valid_beacon_attestation(shard: Shard,

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
@@ -86,20 +86,21 @@ Validator public keys are [G1 points](../bls_signature.md#g1-points) on the [BLS
 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` via the following:
-* Set `withdrawal_credentials[:1] == BLS_WITHDRAWAL_PREFIX_BYTE`.
-* Set `withdrawal_credentials[1:] == hash(withdrawal_pubkey)[1:]`.
+
+- 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 proof-of-work chain. Deposits are made to the [deposit contract](../core/0_deposit-contract.md) located at `DEPOSIT_CONTRACT_ADDRESS`.
 
 To submit a deposit:
 
-* Pack the validator's [initialization parameters](#initialization) into `deposit_data`, a [`DepositData`](../core/0_beacon-chain.md#depositdata) SSZ object.
-* Let `amount` be the amount in Gwei to be deposited by the validator where `MIN_DEPOSIT_AMOUNT <= amount <= MAX_EFFECTIVE_BALANCE`.
-* Set `deposit_data.amount = amount`.
-* Let `signature` be the result of `bls_sign` of the `signing_root(deposit_data)` with `domain=bls_domain(DOMAIN_DEPOSIT)`. (Deposits are valid regardless of fork version, `bls_domain` will default to zeroes there).
-* Send a transaction on the Ethereum 1.0 chain to `DEPOSIT_CONTRACT_ADDRESS` executing `def deposit(pubkey: bytes[48], withdrawal_credentials: bytes[32], signature: bytes[96])` along with a deposit of `amount` Gwei.
+- Pack the validator's [initialization parameters](#initialization) into `deposit_data`, a [`DepositData`](../core/0_beacon-chain.md#depositdata) SSZ object.
+- Let `amount` be the amount in Gwei to be deposited by the validator where `MIN_DEPOSIT_AMOUNT <= amount <= MAX_EFFECTIVE_BALANCE`.
+- Set `deposit_data.amount = amount`.
+- Let `signature` be the result of `bls_sign` of the `signing_root(deposit_data)` with `domain=bls_domain(DOMAIN_DEPOSIT)`. (Deposits are valid regardless of fork version, `bls_domain` will default to zeroes there).
+- Send a transaction on the Ethereum 1.0 chain to `DEPOSIT_CONTRACT_ADDRESS` executing `def deposit(pubkey: bytes[48], withdrawal_credentials: bytes[32], signature: bytes[96])` along with a deposit of `amount` Gwei.
 
 *Note*: Deposits made for the same `pubkey` are treated as for the same validator. A singular `Validator` will be added to `state.validators` 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_EFFECTIVE_BALANCE`.
 
@@ -292,34 +293,35 @@ A validator should create and broadcast the attestation halfway through the `slo
 
 First, the validator should construct `attestation_data`, an [`AttestationData`](../core/0_beacon-chain.md#attestationdata) object based upon the state at the assigned slot.
 
-* Let `head_block` be the result of running the fork choice during the assigned slot.
-* Let `head_state` be the state of `head_block` processed through any empty slots up to the assigned slot using `process_slots(state, slot)`.
+- Let `head_block` be the result of running the fork choice during the assigned slot.
+- Let `head_state` be the state of `head_block` processed through any empty slots up to the assigned slot using `process_slots(state, slot)`.
 
 ##### LMD GHOST vote
 
 Set `attestation_data.beacon_block_root = signing_root(head_block)`.
 
 ##### FFG vote
 
-* Set `attestation_data.source_epoch = head_state.current_justified_epoch`.
-* Set `attestation_data.source_root = head_state.current_justified_root`.
-* Set `attestation_data.target_epoch = get_current_epoch(head_state)`
-* Set `attestation_data.target_root = epoch_boundary_block_root` where `epoch_boundary_block_root` is the root of block at the most recent epoch boundary.
+- Set `attestation_data.source_epoch = head_state.current_justified_epoch`.
+- Set `attestation_data.source_root = head_state.current_justified_root`.
+- Set `attestation_data.target_epoch = get_current_epoch(head_state)`
+- Set `attestation_data.target_root = epoch_boundary_block_root` where `epoch_boundary_block_root` is the root of block at the most recent epoch boundary.
 
 *Note*: `epoch_boundary_block_root` can be looked up in the state using:
-* Let `start_slot = epoch_start_slot(get_current_epoch(head_state))`.
-* Let `epoch_boundary_block_root = signing_root(head_block) if start_slot == head_state.slot else get_block_root(state, start_slot)`.
+
+- Let `start_slot = epoch_start_slot(get_current_epoch(head_state))`.
+- Let `epoch_boundary_block_root = signing_root(head_block) if start_slot == head_state.slot else get_block_root(state, start_slot)`.
 
 ##### Crosslink vote
 
 Construct `attestation_data.crosslink` via the following.
 
-* Set `attestation_data.crosslink.shard = shard` where `shard` is the shard associated with the validator's committee.
-* Let `parent_crosslink = head_state.current_crosslinks[shard]`.
-* Set `attestation_data.crosslink.start_epoch = parent_crosslink.end_epoch`.
-* Set `attestation_data.crosslink.end_epoch = min(attestation_data.target_epoch, parent_crosslink.end_epoch + MAX_EPOCHS_PER_CROSSLINK)`.
-* Set `attestation_data.crosslink.parent_root = hash_tree_root(head_state.current_crosslinks[shard])`.
-* Set `attestation_data.crosslink.data_root = ZERO_HASH`. *Note*: This is a stub for Phase 0.
+- Set `attestation_data.crosslink.shard = shard` where `shard` is the shard associated with the validator's committee.
+- Let `parent_crosslink = head_state.current_crosslinks[shard]`.
+- Set `attestation_data.crosslink.start_epoch = parent_crosslink.end_epoch`.
+- Set `attestation_data.crosslink.end_epoch = min(attestation_data.target_epoch, parent_crosslink.end_epoch + MAX_EPOCHS_PER_CROSSLINK)`.
+- Set `attestation_data.crosslink.parent_root = hash_tree_root(head_state.current_crosslinks[shard])`.
+- Set `attestation_data.crosslink.data_root = ZERO_HASH`. *Note*: This is a stub for Phase 0.
 
 #### Construct attestation
 
@@ -331,13 +333,13 @@ Set `attestation.data = attestation_data` where `attestation_data` is the `Attes
 
 ##### Aggregation bits
 
-* Let `attestation.aggregation_bits` be a `Bitlist[MAX_INDICES_PER_ATTESTATION]` where the bits at the index in the aggregated validator's `committee` is set to `0b1`.
+- Let `attestation.aggregation_bits` be a `Bitlist[MAX_INDICES_PER_ATTESTATION]` where the bits at the index in the aggregated validator's `committee` is set to `0b1`.
 
 *Note*: Calling `get_attesting_indices(state, attestation.data, attestation.aggregation_bits)` should return a list of length equal to 1, containing `validator_index`.
 
 ##### Custody bits
 
-* Let `attestation.custody_bits` be a `Bitlist[MAX_INDICES_PER_ATTESTATION]` filled with zeros of length `len(committee)`.
+- Let `attestation.custody_bits` be a `Bitlist[MAX_INDICES_PER_ATTESTATION]` filled with zeros of length `len(committee)`.
 
 *Note*: This is a stub for Phase 0.
 
@@ -376,6 +378,7 @@ To avoid "proposer slashings", a validator must not sign two conflicting [`Beaco
 *In Phase 0, as long as the validator does not sign two different beacon blocks for the same epoch, the validator is safe against proposer slashings.*
 
 Specifically, when signing a `BeaconBlock`, a validator should perform the following steps in the following order:
+
 1. Save a record to hard disk that a beacon block has been signed for the `epoch=slot_to_epoch(block.slot)`.
 2. Generate and broadcast the block.
 
@@ -386,6 +389,7 @@ If the software crashes at some point within this routine, then when the validat
 To avoid "attester slashings", a validator must not sign two conflicting [`AttestationData`](../core/0_beacon-chain.md#attestationdata) objects, i.e. two attestations that satisfy [`is_slashable_attestation_data`](../core/0_beacon-chain.md#is_slashable_attestation_data).
 
 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 (i.e. `attestation_data.source_epoch`) and target (i.e. `slot_to_epoch(attestation_data.slot)`).
 2. Generate and broadcast attestation.