From e640f13e9c0520c39f60858ae3a663022bd407c0 Mon Sep 17 00:00:00 2001 From: Vitalik Buterin Date: Wed, 3 Oct 2018 12:11:53 -0400 Subject: [PATCH 01/16] Added versioning --- specs/casper_sharding_v2.1.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/specs/casper_sharding_v2.1.md b/specs/casper_sharding_v2.1.md index c0d2c231c..b9d6ff586 100644 --- a/specs/casper_sharding_v2.1.md +++ b/specs/casper_sharding_v2.1.md @@ -170,7 +170,12 @@ fields = { # Start of the current dynasty 'dynasty_start': 'int64', # Total deposits penalized in the given withdrawal period - 'deposits_penalized_in_period': ['int32'] + 'deposits_penalized_in_period': ['int32'], + # Parameters relevant to hard forks / versioning. + # Should be updated only by hard forks. + 'pre_fork_version': 'int32', + 'post_fork_version': 'int32', + 'fork_slot_number': 'int64', } ``` @@ -455,7 +460,7 @@ For each one of these attestations: * Let `attestation_indices` be `get_shards_and_committees_for_slot(crystallized_state, slot)[x]`, choosing `x` so that `attestation_indices.shard_id` equals the `shard_id` value provided to find the set of validators that is creating this attestation record. * Verify that `len(attester_bitfield) == ceil_div8(len(attestation_indices))`, where `ceil_div8 = (x + 7) // 8`. Verify that bits `len(attestation_indices)....` and higher, if present (i.e. `len(attestation_indices)` is not a multiple of 8), are all zero * Derive a group public key by adding the public keys of all of the attesters in `attestation_indices` for whom the corresponding bit in `attester_bitfield` (the ith bit is `(attester_bitfield[i // 8] >> (7 - (i %8))) % 2`) equals 1 -* Verify that `aggregate_sig` verifies using the group pubkey generated and `hash(slot.to_bytes(8, 'big') + parent_hashes + shard_id + shard_block_hash + justified_slot.to_bytes(8, 'big'))` as the message. +* Let `version = pre_fork_version if slot < fork_slot_number else post_fork_version`. Verify that `aggregate_sig` verifies using the group pubkey generated and `hash(slot.to_bytes(8, 'big') + parent_hashes + shard_id + shard_block_hash + justified_slot.to_bytes(8, 'big'))` as the message. Extend the list of `AttestationRecord` objects in the `active_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 `SpecialObject` objects in the `active_state` with those included in the block. From 8b0bbad29f046acfdeaa97f5dfdeb6884923e330 Mon Sep 17 00:00:00 2001 From: vbuterin Date: Wed, 3 Oct 2018 15:09:16 -0400 Subject: [PATCH 02/16] Update casper_sharding_v2.1.md --- specs/casper_sharding_v2.1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/casper_sharding_v2.1.md b/specs/casper_sharding_v2.1.md index b9d6ff586..d1ee4a8d1 100644 --- a/specs/casper_sharding_v2.1.md +++ b/specs/casper_sharding_v2.1.md @@ -460,7 +460,7 @@ For each one of these attestations: * Let `attestation_indices` be `get_shards_and_committees_for_slot(crystallized_state, slot)[x]`, choosing `x` so that `attestation_indices.shard_id` equals the `shard_id` value provided to find the set of validators that is creating this attestation record. * Verify that `len(attester_bitfield) == ceil_div8(len(attestation_indices))`, where `ceil_div8 = (x + 7) // 8`. Verify that bits `len(attestation_indices)....` and higher, if present (i.e. `len(attestation_indices)` is not a multiple of 8), are all zero * Derive a group public key by adding the public keys of all of the attesters in `attestation_indices` for whom the corresponding bit in `attester_bitfield` (the ith bit is `(attester_bitfield[i // 8] >> (7 - (i %8))) % 2`) equals 1 -* Let `version = pre_fork_version if slot < fork_slot_number else post_fork_version`. Verify that `aggregate_sig` verifies using the group pubkey generated and `hash(slot.to_bytes(8, 'big') + parent_hashes + shard_id + shard_block_hash + justified_slot.to_bytes(8, 'big'))` as the message. +* Let `version = pre_fork_version if slot < fork_slot_number else post_fork_version`. Verify that `aggregate_sig` verifies using the group pubkey generated and `hash(bytes4(version) + bytes8(slot) + parent_hashes + bytes2(shard_id) + shard_block_hash + bytes8(justified_slot))` as the message. Extend the list of `AttestationRecord` objects in the `active_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 `SpecialObject` objects in the `active_state` with those included in the block. From 6568bc1b6d39fe670755f64cff822d7b55d1eb82 Mon Sep 17 00:00:00 2001 From: vbuterin Date: Wed, 3 Oct 2018 22:02:04 -0400 Subject: [PATCH 03/16] Update casper_sharding_v2.1.md --- specs/casper_sharding_v2.1.md | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/specs/casper_sharding_v2.1.md b/specs/casper_sharding_v2.1.md index d1ee4a8d1..1359b8153 100644 --- a/specs/casper_sharding_v2.1.md +++ b/specs/casper_sharding_v2.1.md @@ -126,6 +126,20 @@ fields = { } ``` +Here's the data signed (`AttestationSignedData`): + +```python +fields = { + # Version of the chain + 'version': 'int64', + 'slot': 'int64', + 'parent_hashes': ['hash32'], + 'shard_id': 'int16', + 'shard_block_hash': 'hash32', + 'justified_slot': 'int64' +} +``` + #### Beacon chain state The beacon chain state is split into two parts, _active state_ and _crystallized state_. @@ -460,7 +474,8 @@ For each one of these attestations: * Let `attestation_indices` be `get_shards_and_committees_for_slot(crystallized_state, slot)[x]`, choosing `x` so that `attestation_indices.shard_id` equals the `shard_id` value provided to find the set of validators that is creating this attestation record. * Verify that `len(attester_bitfield) == ceil_div8(len(attestation_indices))`, where `ceil_div8 = (x + 7) // 8`. Verify that bits `len(attestation_indices)....` and higher, if present (i.e. `len(attestation_indices)` is not a multiple of 8), are all zero * Derive a group public key by adding the public keys of all of the attesters in `attestation_indices` for whom the corresponding bit in `attester_bitfield` (the ith bit is `(attester_bitfield[i // 8] >> (7 - (i %8))) % 2`) equals 1 -* Let `version = pre_fork_version if slot < fork_slot_number else post_fork_version`. Verify that `aggregate_sig` verifies using the group pubkey generated and `hash(bytes4(version) + bytes8(slot) + parent_hashes + bytes2(shard_id) + shard_block_hash + bytes8(justified_slot))` as the message. +* Let `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(version, slot, parent_hashes, shard_id, shard_block_hash, crystallized_state.last_justified_slot)` as the message. Extend the list of `AttestationRecord` objects in the `active_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 `SpecialObject` objects in the `active_state` with those included in the block. From a85f59779a7c44d4456fcee7ed7cf3280b106235 Mon Sep 17 00:00:00 2001 From: Justin Date: Thu, 4 Oct 2018 11:09:39 +0100 Subject: [PATCH 04/16] Clean up data structures This includes: * Giving every data structure a name (e.g. `BeaconChainBlock`) * Making data structure names consistent (e.g. `SpecialObject` => `SpecialRecord`) * Arranging the fields within the data structures in a more logical/consistent manner * Reworking the comments to be more concise and to the point * Rename some fields for consistency: * `shard_id` => `shard` (for consistency with `withdrawal_shard`) * `last_state_recalculation` => `last_state_recalculation_slot` (for consistency with `last_finalized_slot`, `last_justified_slot`, etc.) * `current_dynasty` => `dynasty` (for consistency with `slot`, `shard`) * `pow_chain_ref` => `pow_chain_reference` (abbreviations are avoided throughout) * Various other cleanups --- specs/beacon-chain.md | 236 +++++++++++++++++++++--------------------- 1 file changed, 117 insertions(+), 119 deletions(-) diff --git a/specs/beacon-chain.md b/specs/beacon-chain.md index 5437e32ad..16233c8dd 100644 --- a/specs/beacon-chain.md +++ b/specs/beacon-chain.md @@ -70,162 +70,160 @@ The initial deployment phases of Ethereum 2.0 are implemented without consensus The registration contract emits a log with the various arguments for consumption by the beacon chain. It does not do validation, pushing the registration logic to the beacon chain. In particular, the proof of possession (based on the BLS12-381 curve) is not verified by the registration contract. -## Data Structures +## Data structures +### Beacon chain blocks -#### Beacon chain blocks - -Beacon chain block structure: +A `BeaconChainBlock` has the following fields: ```python -fields = { - # Skip list of ancestor block hashes. The i'th item is 2**i'th ancestor (or zero bytes) for i = 0, ..., 31 - 'ancestor_hashes': ['hash32'], +{ # Slot number 'slot': 'int64', - # RANDAO commitment reveal + # Proposer RANDAO reveal 'randao_reveal': 'hash32', + # Recent PoW chain reference (block hash) + 'pow_chain_reference': 'hash32', + # Skip list of ancestor block hashes (i'th item is 2**i'th ancestor (or zero) for i = 0, ..., 31) + 'ancestor_hashes': ['hash32'], + # Active state root + 'active_state_root': 'hash32', + # Crystallized state root + 'crystallized_state_root': 'hash32', # Attestations 'attestations': [AttestationRecord], - # Reference to PoW chain block - 'pow_chain_ref': 'hash32', - # Hash of the active state - 'active_state_root': 'hash32', - # Hash of the crystallized state - 'crystallized_state_root': 'hash32', - # Logouts, penalties, etc etc - 'specials': [SpecialObject] + # Specials (e.g. logouts, penalties) + 'specials': [SpecialRecord] } ``` -A `SpecialObject` looks as follows: +An `AttestationRecord` has the following fields: ```python -fields = { - 'type': 'int8', - 'data': ['bytes'] -} -``` - -An `AttestationRecord` looks as follows: - -```python -fields = { +{ # Slot number 'slot': 'int64', - # Shard ID - 'shard_id': 'int16', - # List of block hashes that this signature is signing over that - # are NOT part of the current chain, in order of oldest to newest + # Shard number + 'shard': 'int16', + # Block hashes not part of the current chain, oldest to newest 'oblique_parent_hashes': ['hash32'], - # Block hash in the shard that we are attesting to + # Shard block hash being attested to 'shard_block_hash': 'hash32', - # Who is participating + # Attester participation bitfield (1 bit per attester) 'attester_bitfield': 'bytes', - # Last justified block + # Slot of last justified block 'justified_slot': 'int64', + # Hash of last justified block 'justified_block_hash': 'hash32', - # The actual signature + # BLS aggregate signature 'aggregate_sig': ['int256'] } ``` -#### Beacon chain state - -The beacon chain state is split into two parts, _active state_ and _crystallized state_. - -Here's the `ActiveState`: +A `SpecialRecord` has the following fields: ```python fields = { - # Attestations that have not yet been processed - 'pending_attestations': [AttestationRecord], - # Special objects that have not yet been processed - 'pending_specials': [SpecialObject], - # Most recent 2 * CYCLE_LENGTH block hashes, older to newer - 'recent_block_hashes': ['hash32'] + # Type + 'type': 'int8', + # Data + 'data': ['bytes'] } ``` -Here's the `CrystallizedState`: +### Beacon chain state + +For convenience we define the beacon chain state in two parts: "active state" and "crystallized state". + +The `ActiveState` has the following fields: ```python -fields = { +{ + # Most recent 2 * CYCLE_LENGTH block hashes, oldest to newest + 'recent_block_hashes': ['hash32'], + # Attestations not yet processed + 'pending_attestations': [AttestationRecord], + # Specials not yet been processed + 'pending_specials': [SpecialRecord] +} +``` + +The `CrystallizedState` has the following fields: + +```python +{ + # Dynasty number + 'dynasty': 'int64', + # Dynasty seed (from randomness beacon) + 'dynasty_seed': 'hash32', + # Dynasty start + 'dynasty_start_slot': 'int64', # List of validators 'validators': [ValidatorRecord], - # Last CrystallizedState recalculation - 'last_state_recalculation': 'int64', - # What active validators are part of the attester set - # at what slot, and in what shard. Starts at slot - # last_state_recalculation - CYCLE_LENGTH - 'shard_and_committee_for_slots': [[ShardAndCommittee]], - # The last justified slot - 'last_justified_slot': 'int64', - # Number of consecutive justified slots ending at this one - 'justified_streak': 'int64', - # The last finalized slot + # Most recent crosslink for each shard + 'crosslinks': [CrosslinkRecord], + # Last crystallized state recalculation + 'last_state_recalculation_slot': 'int64', + # Last finalized slot 'last_finalized_slot': 'int64', - # The current dynasty - 'current_dynasty': 'int64', - # Records about the most recent crosslink for each shard - 'crosslink_records': [CrosslinkRecord], - # Used to select the committees for each shard - 'dynasty_seed': 'hash32', - # Start of the current dynasty - 'dynasty_start': 'int64', + # Last justified slot + 'last_justified_slot': 'int64', + # Number of consecutive justified slots + 'justified_streak': 'int64', + # Committee members and their assigned shard, per slot + 'shard_and_committee_for_slots': [[ShardAndCommittee]], # Total deposits penalized in the given withdrawal period 'deposits_penalized_in_period': ['int32'], - # Hash chain of validator set changes, allows light clients to track deltas more easily + # Hash chain of validator set changes (for light clients to easily track deltas) 'validator_set_delta_hash_chain': 'hash32' } ``` -Each `ValidatorRecord` is an object containing information about a validator: +A `ValidatorRecord` has the following fields: ```python -fields = { - # The validator's public key +{ + # BLS public key 'pubkey': 'int256', - # What shard the validator's balance will be sent to - # after withdrawal + # Withdrawal shard number 'withdrawal_shard': 'int16', - # And what address + # Withdrawal address 'withdrawal_address': 'address', - # The validator's current RANDAO beacon commitment + # RANDAO commitment 'randao_commitment': 'hash32', - # Current balance + # Balance 'balance': 'int128', - # Status (see status codes in constants above) + # Status code 'status': 'int8', - # Slot where this validator leaves + # Slot when validator exited (or 0) 'exit_slot': 'int64' } ``` -A `ShardAndCommittee` object is of the form: +A `ShardAndCommittee` object has the following fields: ```python -fields = { - # The shard ID - 'shard_id': 'int16', +{ + # Shard number + 'shard': 'int16', # Validator indices 'committee': ['int24'] } ``` -And a `CrosslinkRecord` contains information about the last fully formed crosslink to be submitted into the chain: +A `CrosslinkRecord` has the following fields: ```python -fields = { - # What dynasty the crosslink was submitted in +{ + # Dynasty number 'dynasty': 'int64', - # What slot + # Slot number 'slot': 'int64', - # The block hash + # Beacon chain block hash 'hash': 'hash32' } ``` -### Beacon chain processing +## Beacon chain processing The beacon chain is the "main chain" of the PoS system. The beacon chain's main responsibilities are: @@ -239,7 +237,7 @@ For a block on the beacon chain to be processed by a node, four conditions have * The parent pointed to by the `ancestor_hashes[0]` has already been processed and accepted * An attestation from the _proposer_ of the block (see later for definition) is included along with the block in the network message object -* The PoW chain block pointed to by the `pow_chain_ref` has already been processed and accepted +* The PoW chain block pointed to by the `pow_chain_reference` has already been processed and accepted * The node's local clock time is greater than or equal to the minimum timestamp as computed by `GENESIS_TIME + block.slot * SLOT_DURATION` If these conditions are not met, the client should delay processing the block until the conditions are all satisfied. @@ -263,7 +261,7 @@ Here's an example of its working (green is finalized blocks, yellow is justified We now define the state transition function. At the high level, the state transition is made up of two parts: 1. The per-block processing, which happens every block, and affects the `ActiveState` only -2. The crystallized state recalculation, which happens only if `block.slot >= last_state_recalculation + CYCLE_LENGTH`, and affects the `CrystallizedState` and `ActiveState` +2. The crystallized state recalculation, which happens only if `block.slot >= last_state_recalculation_slot + CYCLE_LENGTH`, and affects the `CrystallizedState` and `ActiveState` The crystallized state recalculation generally focuses on changes to the validator set, including adjusting balances and adding and removing validators, as well as processing crosslinks and managing block justification, and the per-block processing generally focuses on verifying aggregate signatures and saving temporary records relating to the in-block activity in the `ActiveState`. @@ -328,10 +326,10 @@ def get_new_shuffling(seed, validators, crosslinking_start_shard): o = [] for i, slot_indices in enumerate(split(shuffle(active_validators, seed), CYCLE_LENGTH)): shard_indices = split(slot_indices, committees_per_slot) - shard_id_start = crosslinking_start_shard + \ + shard_start = crosslinking_start_shard + \ i * committees_per_slot // slots_per_committee o.append([ShardAndCommittee( - shard_id = (shard_id_start + j) % SHARD_COUNT, + shard = (shard_start + j) % SHARD_COUNT, committee = indices ) for j, indices in enumerate(shard_indices)]) return o @@ -345,7 +343,7 @@ We also define two functions for retrieving data from the state: ```python def get_shards_and_committees_for_slot(crystallized_state, slot): - earliest_slot_in_array = crystallized_state.last_state_recalculation - CYCLE_LENGTH + earliest_slot_in_array = crystallized_state.last_state_recalculation_slot - CYCLE_LENGTH assert earliest_slot_in_array <= slot < earliest_slot_in_array + CYCLE_LENGTH * 2 return crystallized_state.shard_and_committee_for_slots[slot - earliest_slot_in_array] @@ -395,15 +393,15 @@ def on_startup(initial_validator_entries): cs = CrystallizedState() x = get_new_shuffling(bytes([0] * 32), validators, 0) cs.shard_and_committee_for_slots = x + x - cs.current_dynasty = 1 - cs.crosslink_records = [CrosslinkRecord(dynasty=0, slot=0, hash=bytes([0] * 32)) + cs.dynasty = 1 + cs.crosslinks = [CrosslinkRecord(dynasty=0, slot=0, hash=bytes([0] * 32)) for i in range(SHARD_COUNT)] # Setup active state as = ActiveState() as.recent_block_hashes = [bytes([0] * 32) for _ in range(CYCLE_LENGTH * 2)] ``` -The `CrystallizedState()` and `ActiveState()` constructors should initialize all values to zero byes, an empty value or an empty array depending on context. The `add_validator` routine is defined below. +The `CrystallizedState()` and `ActiveState()` constructors should initialize all values to zero bytes, an empty value or an empty array depending on context. The `add_validator` routine is defined below. ### Routine for adding a validator @@ -466,38 +464,38 @@ For each one of these attestations: * Verify that `slot <= parent.slot` and `slot >= max(parent.slot - CYCLE_LENGTH + 1, 0)` * Verify that the `justified_slot` and `justified_block_hash` given are in the chain and are equal to or earlier than the `last_justified_slot` in the crystallized state. * Compute `parent_hashes` = `[get_block_hash(active_state, block, slot - CYCLE_LENGTH + i) for i in range(1, CYCLE_LENGTH - len(oblique_parent_hashes) + 1)] + oblique_parent_hashes` (eg, if `CYCLE_LENGTH = 4`, `slot = 5`, the actual block hashes starting from slot 0 are `Z A B C D E F G H I J`, and `oblique_parent_hashes = [D', E']` then `parent_hashes = [B, C, D' E']`). Note that when *creating* an attestation for a block, the hash of that block itself won't yet be in the `active_state`, so you would need to add it explicitly. -* Let `attestation_indices` be `get_shards_and_committees_for_slot(crystallized_state, slot)[x]`, choosing `x` so that `attestation_indices.shard_id` equals the `shard_id` value provided to find the set of validators that is creating this attestation record. +* Let `attestation_indices` be `get_shards_and_committees_for_slot(crystallized_state, slot)[x]`, choosing `x` so that `attestation_indices.shard` equals the `shard` value provided to find the set of validators that is creating this attestation record. * Verify that `len(attester_bitfield) == ceil_div8(len(attestation_indices))`, where `ceil_div8 = (x + 7) // 8`. Verify that bits `len(attestation_indices)....` and higher, if present (i.e. `len(attestation_indices)` is not a multiple of 8), are all zero * Derive a group public key by adding the public keys of all of the attesters in `attestation_indices` for whom the corresponding bit in `attester_bitfield` (the ith bit is `(attester_bitfield[i // 8] >> (7 - (i %8))) % 2`) equals 1 -* Verify that `aggregate_sig` verifies using the group pubkey generated and `hash(slot.to_bytes(8, 'big') + parent_hashes + shard_id + shard_block_hash + justified_slot.to_bytes(8, 'big'))` as the message. +* Verify that `aggregate_sig` verifies using the group pubkey generated and `hash(slot.to_bytes(8, 'big') + parent_hashes + shard + shard_block_hash + justified_slot.to_bytes(8, 'big'))` as the message. -Extend the list of `AttestationRecord` objects in the `active_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 `SpecialObject` objects in the `active_state` with those included in the block. +Extend the list of `AttestationRecord` objects in the `active_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 `active_state` with those included in the block. Verify that the `parent.slot % len(get_shards_and_committees_for_slot(crystallized_state, parent.slot)[0].committee)`'th attester in `get_shards_and_committees_for_slot(crystallized_state, parent.slot)[0]` 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 block is produced, it is broadcasted at the network layer along with the attestation from its proposer. ### State recalculations (every `CYCLE_LENGTH` slots) -Repeat while `slot - last_state_recalculation >= CYCLE_LENGTH`: +Repeat while `slot - last_state_recalculation_slot >= CYCLE_LENGTH`: #### Adjust justified slots and crosslink status -For all slots `s` in `last_state_recalculation - CYCLE_LENGTH ... last_state_recalculation - 1`: +For all slots `s` in `last_state_recalculation_slot - CYCLE_LENGTH ... last_state_recalculation_slot - 1`: * Determine the total set of validators that attested to that block at least once * Determine the total balance of these validators. If this value times three equals or exceeds the total balance of all active validators times two, set `last_justified_slot = max(last_justified_slot, s)` and `justified_streak += 1`. Otherwise, set `justified_streak = 0` * If `justified_streak >= CYCLE_LENGTH + 1`, set `last_finalized_slot = max(last_finalized_slot, s - CYCLE_LENGTH - 1)` -For all (`shard_id`, `shard_block_hash`) tuples, compute the total deposit size of validators that attested to that block hash for that shard. If this value times three equals or exceeds the total balance of all validators in the committee times two, and the current dynasty exceeds `crosslink_records[shard_id].dynasty`, set `crosslink_records[shard_id] = CrosslinkRecord(dynasty=current_dynasty, slot=block.last_state_recalculation + CYCLE_LENGTH, hash=shard_block_hash)`. +For all (`shard`, `shard_block_hash`) tuples, compute the total deposit size of validators that attested to that block hash for that shard. If this value times three equals or exceeds the total balance of all validators in the committee times two, and the current dynasty exceeds `crosslinks[shard].dynasty`, set `crosslinks[shard] = CrosslinkRecord(dynasty=dynasty, slot=block.last_state_recalculation_slot + CYCLE_LENGTH, hash=shard_block_hash)`. #### Balance recalculations related to FFG rewards Let `time_since_finality = block.slot - last_finalized_slot`, and let `B` be the balance of any given validator whose balance we are adjusting, not including any balance changes from this round of state recalculation. Let: -* `total_deposits = sum([v.balance for i, v in enumerate(validators) if i in get_active_validator_indices(validators, current_dynasty)])` and `total_deposits_in_ETH = total_deposits // 10**18` +* `total_deposits = sum([v.balance for i, v in enumerate(validators) if i in get_active_validator_indices(validators, dynasty)])` and `total_deposits_in_ETH = total_deposits // 10**18` * `reward_quotient = BASE_REWARD_QUOTIENT * int_sqrt(total_deposits_in_ETH)` (`1/reward_quotient` is the per-slot max interest rate) * `quadratic_penalty_quotient = SQRT_E_DROP_TIME**2` (after `D` slots about `D*D/2/quadratic_penalty_quotient` is the portion lost by offline validators) -For each slot `S` in the range `last_state_recalculation - CYCLE_LENGTH ... last_state_recalculation - 1`: +For each slot `S` in the range `last_state_recalculation_slot - CYCLE_LENGTH ... last_state_recalculation_slot - 1`: * Let `total_participated_deposits` be the total balance of validators that voted for the correct hash in slot `S` (ie. the hash that actually is the hash of the block at that slot in the current chain); note that in the normal case, every validator will be in one of the `CYCLE_LENGTH` slots following the slot and so can vote for a hash in slot `S`. If `time_since_finality <= 3 * CYCLE_LENGTH`, then adjust participating and non-participating validators' balances as follows: * Participating validators gain `B // reward_quotient * (2 * total_participated_deposits - total_deposits) // total_deposits` (note: this may be negative) @@ -510,20 +508,20 @@ Validators with `status == PENALIZED` also lose `B // reward_quotient + B * time #### Balance recalculations related to crosslink rewards -For each shard `S` for which a crosslink committee exists in the cycle prior to the most recent cycle (`last_state_recalculation - CYCLE_LENGTH ... last_state_recalculation - 1`), let `V` be the corresponding validator set. Let `B` be the balance of any given validator whose balance we are adjusting, not including any balance changes from this round of state recalculation. For each `S`, `V`: +For each shard `S` for which a crosslink committee exists in the cycle prior to the most recent cycle (`last_state_recalculation_slot - CYCLE_LENGTH ... last_state_recalculation_slot - 1`), let `V` be the corresponding validator set. Let `B` be the balance of any given validator whose balance we are adjusting, not including any balance changes from this round of state recalculation. For each `S`, `V`: * Let `total_v_deposits` be the total balance of `V` * Let `total_participated_v_deposits` be the total balance of the subset of `V` that participated (note that `total_participated_v_deposits <= total_v_deposits`) -* Let `time_since_last_confirmation` be `block.slot - crosslink_records[S].slot` +* Let `time_since_last_confirmation` be `block.slot - crosslinks[S].slot` * Adjust balances as follows: - * If `crosslink_records[S].dynasty == current_dynasty`, no reward adjustments + * If `crosslinks[S].dynasty == dynasty`, no reward adjustments * Otherwise, participating validators' balances are increased by `B // reward_quotient * (2 * total_participated_v_deposits - total_v_deposits) // total_v_deposits`, and the balances of non-participating validators are decreased by `B // reward_quotient + B * time_since_last_confirmation // quadratic_penalty_quotient` Let `committees` be the set of committees processed and `time_since_last_confirmation(c)` be the value of `time_since_last_confirmation` in that committee. Validators with `status == PENALIZED` lose `B // reward_quotient + B * sum([time_since_last_confirmation(c) for c in committees]) // len(committees) // quadratic_penalty_quotient`. #### Process penalties, logouts and other special objects -For each `SpecialObject` `obj` in `active_state.pending_specials`: +For each `SpecialRecord` `obj` in `active_state.pending_specials`: * **[covers logouts]**: If `obj.type == 0`, interpret `data[0]` as a validator index as an `int32` and `data[1]` as a signature. If `BLSVerify(pubkey=validators[data[0]].pubkey, msg=hash("bye bye"), sig=data[1])`, and `validators[i].status == LOGGED_IN`, set `validators[i].status = PENDING_EXIT` and `validators[i].exit_slot = current_slot` * **[covers `NO_DBL_VOTE`, `NO_SURROUND`, `NO_DBL_PROPOSE` slashing conditions]:** If `obj.type == 1`, interpret `data[0]` as a list of concatenated `int32` 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 `inds` be the list of indices in both signatures; verify that its length is at least 1. For each validator index `v` in `inds`, set their end dynasty to equal the current dynasty plus 1, and if its `status` does not equal `PENALIZED`, then: @@ -535,8 +533,8 @@ For each `SpecialObject` `obj` in `active_state.pending_specials`: #### Finally... -* Set `crystallized_state.last_state_recalculation += CYCLE_LENGTH` -* Remove all attestation records older than slot `crystallized_state.last_state_recalculation` +* Set `crystallized_state.last_state_recalculation_slot += CYCLE_LENGTH` +* Remove all attestation records older than slot `crystallized_state.last_state_recalculation_slot` * Empty the `active_state.pending_specials` list * Set `shard_and_committee_for_slots[:CYCLE_LENGTH] = shard_and_committee_for_slots[CYCLE_LENGTH:]` @@ -544,16 +542,16 @@ For each `SpecialObject` `obj` in `active_state.pending_specials`: A dynasty transition can happen after a state recalculation if all of the following criteria are satisfied: -* `block.slot - crystallized_state.dynasty_start >= MIN_DYNASTY_LENGTH` -* `last_finalized_slot > dynasty_start` -* For every shard `S` in `shard_and_committee_for_slots`, `crosslink_records[S].slot > dynasty_start` +* `block.slot - crystallized_state.dynasty_start_slot >= MIN_DYNASTY_LENGTH` +* `last_finalized_slot > dynasty_start_slot` +* For every shard `S` in `shard_and_committee_for_slots`, `crosslinks[S].slot > dynasty_start_slot` Then, run the following algorithm to update the validator set: ```python def change_validators(validators): # The active validator set - active_validators = get_active_validator_indices(validators, current_dynasty) + active_validators = get_active_validator_indices(validators, dynasty) # The total size of active deposits total_deposits = sum([v.balance for i, v in enumerate(validators) if i in active_validators]) # The maximum total wei that can deposit+withdraw @@ -598,9 +596,9 @@ def change_validators(validators): Finally: -* Set `last_dynasty_start = crystallized_state.last_state_recalculation` -* Set `crystallized_state.current_dynasty += 1` -* Let `next_start_shard = (shard_and_committee_for_slots[-1][-1].shard_id + 1) % SHARD_COUNT` +* Set `last_dynasty_start_slot = crystallized_state.last_state_recalculation_slot` +* Set `crystallized_state.dynasty += 1` +* Let `next_start_shard = (shard_and_committee_for_slots[-1][-1].shard + 1) % SHARD_COUNT` * Set `shard_and_committee_for_slots[CYCLE_LENGTH:] = get_new_shuffling(block.ancestor_hashes[0], validators, next_start_shard)` ### TODO @@ -610,7 +608,7 @@ Note: This spec is ~60% complete. **Missing** * [ ] Specify how `crystallized_state_root` and `active_state_root` are constructed, including Merklelisation logic for light clients -* [ ] Specify the rules around acceptable values for `pow_chain_ref` +* [ ] Specify the rules around acceptable values for `pow_chain_reference` * [ ] Specify the shard chain blocks, blobs, proposers, etc. * [ ] Specify the rules for forced deregistrations * [ ] Specify the various assumptions (global clock, networking latency, validator honesty, validator liveness, etc.) @@ -638,7 +636,7 @@ Note: This spec is ~60% complete. * [ ] Add a double-batched Merkle accumulator for historical beacon chain blocks * [ ] Allow for deposits larger than 32 ETH, as well as deposit top-ups * [ ] Add penalties for a deposit below 32 ETH (or some other threshold) -* [ ] Add a `SpecialObject` to (re)register +* [ ] Add a `SpecialRecord` to (re)register * [ ] Rework the document for readability * [ ] Clearly document the various edge cases, e.g. with committee sizing From 16928c85bb32ccaff020fd5389f956c63baa7388 Mon Sep 17 00:00:00 2001 From: Justin Date: Thu, 4 Oct 2018 11:21:33 +0100 Subject: [PATCH 05/16] Clean up codes, flags, types This includes: * Optimised values (e.g. `PENALIZED` now fits in a single byte) * More consistent values (e.g. the flags start at 0) * Added types for specials --- specs/beacon-chain.md | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/specs/beacon-chain.md b/specs/beacon-chain.md index 5437e32ad..26c7bd4a5 100644 --- a/specs/beacon-chain.md +++ b/specs/beacon-chain.md @@ -51,18 +51,20 @@ The primary source of load on the beacon chain are "attestations". Attestations * The `BASE_REWARD_QUOTIENT` constant is the per-slot interest rate assuming all validators are participating, assuming total deposits of 1 ETH. It corresponds to ~3.88% annual interest assuming 10 million participating ETH. * At most `1/MAX_VALIDATOR_CHURN_QUOTIENT` of the validators can change during each dynasty. -**Status codes** +**Codes, flags, types** -| Status code | Value | -| - | :-: | -| `PENDING_LOG_IN` | `0` | -| `LOGGED_IN` | `1` | -| `PENDING_EXIT` | `2` | -| `PENDING_WITHDRAW` | `3` | -| `WITHDRAWN` | `4` | -| `PENALIZED` | `128` | -| `ENTRY` | `1` | -| `EXIT` | `2` | +| Name | Value | Category | +| - | :-: | :-: | +| `PENDING_LOG_IN` | `0` | code | +| `LOGGED_IN` | `1` | code | +| `PENDING_EXIT` | `2` | code | +| `PENDING_WITHDRAW` | `3` | code | +| `WITHDRAWN` | `4` | code | +| `PENALIZED` | `127` | code | +| `ENTRY` | `0` | flag | +| `EXIT` | `1` | flag | +| `LOGOUT` | `0` | type | +| `CASPER_SLASHING` | `1` | type | ### PoW chain registration contract @@ -525,8 +527,8 @@ Let `committees` be the set of committees processed and `time_since_last_confirm For each `SpecialObject` `obj` in `active_state.pending_specials`: -* **[covers logouts]**: If `obj.type == 0`, interpret `data[0]` as a validator index as an `int32` and `data[1]` as a signature. If `BLSVerify(pubkey=validators[data[0]].pubkey, msg=hash("bye bye"), sig=data[1])`, and `validators[i].status == LOGGED_IN`, set `validators[i].status = PENDING_EXIT` and `validators[i].exit_slot = current_slot` -* **[covers `NO_DBL_VOTE`, `NO_SURROUND`, `NO_DBL_PROPOSE` slashing conditions]:** If `obj.type == 1`, interpret `data[0]` as a list of concatenated `int32` 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 `inds` be the list of indices in both signatures; verify that its length is at least 1. For each validator index `v` in `inds`, set their end dynasty to equal the current dynasty plus 1, and if its `status` does not equal `PENALIZED`, then: +* **[covers logouts]**: If `obj.type == LOGOUT`, interpret `data[0]` as a validator index as an `int32` and `data[1]` as a signature. If `BLSVerify(pubkey=validators[data[0]].pubkey, msg=hash("bye bye"), sig=data[1])`, and `validators[i].status == LOGGED_IN`, set `validators[i].status = PENDING_EXIT` and `validators[i].exit_slot = current_slot` +* **[covers `NO_DBL_VOTE`, `NO_SURROUND`, `NO_DBL_PROPOSE` slashing conditions]:** If `obj.type == CASPER_SLASHING`, interpret `data[0]` as a list of concatenated `int32` 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 `inds` be the list of indices in both signatures; verify that its length is at least 1. For each validator index `v` in `inds`, set their end dynasty to equal the current dynasty plus 1, and if its `status` does not equal `PENALIZED`, then: 1. Set its `exit_slot` to equal the current `slot` 2. Set its `status` to `PENALIZED` From 7749c28bd92231c3da8237c9f811b2bf44822e15 Mon Sep 17 00:00:00 2001 From: Justin Date: Thu, 4 Oct 2018 11:22:50 +0100 Subject: [PATCH 06/16] Update beacon-chain.md --- specs/beacon-chain.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/beacon-chain.md b/specs/beacon-chain.md index 16233c8dd..f27a8e6a8 100644 --- a/specs/beacon-chain.md +++ b/specs/beacon-chain.md @@ -73,7 +73,7 @@ The registration contract emits a log with the various arguments for consumption ## Data structures ### Beacon chain blocks -A `BeaconChainBlock` has the following fields: +A `BeaconBlock` has the following fields: ```python { @@ -122,7 +122,7 @@ An `AttestationRecord` has the following fields: A `SpecialRecord` has the following fields: ```python -fields = { +{ # Type 'type': 'int8', # Data From 5306c1e728db72fb819b6d6a19ad987e714594c0 Mon Sep 17 00:00:00 2001 From: Justin Date: Thu, 4 Oct 2018 14:16:31 +0100 Subject: [PATCH 07/16] Update beacon-chain.md --- specs/beacon-chain.md | 42 ++++++++++++++++++++++++++---------------- 1 file changed, 26 insertions(+), 16 deletions(-) diff --git a/specs/beacon-chain.md b/specs/beacon-chain.md index 26c7bd4a5..57d992c16 100644 --- a/specs/beacon-chain.md +++ b/specs/beacon-chain.md @@ -1,7 +1,6 @@ # Ethereum 2.0 spec—Casper and sharding ###### tags: `spec`, `eth2.0`, `casper`, `sharding` -###### spec version: 2.2 (October 2018) **NOTICE**: This document is a work-in-progress for researchers and implementers. It reflects recent spec changes and takes precedence over the [Python proof-of-concept implementation](https://github.com/ethereum/beacon_chain). @@ -44,6 +43,7 @@ The primary source of load on the beacon chain are "attestations". Attestations | `WITHDRAWAL_PERIOD` | 2**19 (= 524,288) | slots | ~97 days | | `BASE_REWARD_QUOTIENT` | 2**15 (= 32,768) | — | | `MAX_VALIDATOR_CHURN_QUOTIENT` | 2**5 (= 32) | — | +| `LOGOUT_MESSAGE` | `"LOGOUT"` | — | **Notes** @@ -51,20 +51,30 @@ The primary source of load on the beacon chain are "attestations". Attestations * The `BASE_REWARD_QUOTIENT` constant is the per-slot interest rate assuming all validators are participating, assuming total deposits of 1 ETH. It corresponds to ~3.88% annual interest assuming 10 million participating ETH. * At most `1/MAX_VALIDATOR_CHURN_QUOTIENT` of the validators can change during each dynasty. -**Codes, flags, types** +**Validator status codes** -| Name | Value | Category | -| - | :-: | :-: | -| `PENDING_LOG_IN` | `0` | code | -| `LOGGED_IN` | `1` | code | -| `PENDING_EXIT` | `2` | code | -| `PENDING_WITHDRAW` | `3` | code | -| `WITHDRAWN` | `4` | code | -| `PENALIZED` | `127` | code | -| `ENTRY` | `0` | flag | -| `EXIT` | `1` | flag | -| `LOGOUT` | `0` | type | -| `CASPER_SLASHING` | `1` | type | +| Name | Value | +| - | :-: | +| `PENDING_LOG_IN` | `0` | +| `LOGGED_IN` | `1` | +| `PENDING_EXIT` | `2` | +| `PENDING_WITHDRAW` | `3` | +| `WITHDRAWN` | `4` | +| `PENALIZED` | `127` | + +**Special record types** + +| Name | Value | +| - | :-: | +| `LOGOUT` | `0` | +| `CASPER_SLASHING` | `1` | + +**Validator set delta flags** + +| Name | Value | +| - | :-: | +| `ENTRY` | `0` | +| `EXIT` | `1` | ### PoW chain registration contract @@ -527,8 +537,8 @@ Let `committees` be the set of committees processed and `time_since_last_confirm For each `SpecialObject` `obj` in `active_state.pending_specials`: -* **[covers logouts]**: If `obj.type == LOGOUT`, interpret `data[0]` as a validator index as an `int32` and `data[1]` as a signature. If `BLSVerify(pubkey=validators[data[0]].pubkey, msg=hash("bye bye"), sig=data[1])`, and `validators[i].status == LOGGED_IN`, set `validators[i].status = PENDING_EXIT` and `validators[i].exit_slot = current_slot` -* **[covers `NO_DBL_VOTE`, `NO_SURROUND`, `NO_DBL_PROPOSE` slashing conditions]:** If `obj.type == CASPER_SLASHING`, interpret `data[0]` as a list of concatenated `int32` 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 `inds` be the list of indices in both signatures; verify that its length is at least 1. For each validator index `v` in `inds`, set their end dynasty to equal the current dynasty plus 1, and if its `status` does not equal `PENALIZED`, then: +* **[covers logouts]**: If `obj.type == LOGOUT`, interpret `data[0]` as a validator index as an `int32` and `data[1]` as a signature. If `BLSVerify(pubkey=validators[data[0]].pubkey, msg=hash(LOGOUT_MESSAGE), sig=data[1])`, and `validators[i].status == LOGGED_IN`, set `validators[i].status = PENDING_EXIT` and `validators[i].exit_slot = current_slot` +* **[covers `NO_DBL_VOTE`, `NO_SURROUND`, `NO_DBL_PROPOSE` slashing conditions]:** If `obj.type == CASPER_SLASHING`, interpret `data[0]` as a list of concatenated `int32` 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`, set their end dynasty to equal the current dynasty plus 1, and if its `status` does not equal `PENALIZED`, then: 1. Set its `exit_slot` to equal the current `slot` 2. Set its `status` to `PENALIZED` From b60cbd9c339eead7552cc9c0f4b92918268ecad3 Mon Sep 17 00:00:00 2001 From: Justin Date: Thu, 4 Oct 2018 14:26:13 +0100 Subject: [PATCH 08/16] Update beacon-chain.md --- specs/beacon-chain.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/specs/beacon-chain.md b/specs/beacon-chain.md index f27a8e6a8..fb34848dd 100644 --- a/specs/beacon-chain.md +++ b/specs/beacon-chain.md @@ -199,17 +199,6 @@ A `ValidatorRecord` has the following fields: } ``` -A `ShardAndCommittee` object has the following fields: - -```python -{ - # Shard number - 'shard': 'int16', - # Validator indices - 'committee': ['int24'] -} -``` - A `CrosslinkRecord` has the following fields: ```python @@ -223,6 +212,17 @@ A `CrosslinkRecord` has the following fields: } ``` +A `ShardAndCommittee` object has the following fields: + +```python +{ + # Shard number + 'shard': 'int16', + # Validator indices + 'committee': ['int24'] +} +``` + ## Beacon chain processing The beacon chain is the "main chain" of the PoS system. The beacon chain's main responsibilities are: From 5f40856606a748b699a8d2f496f9c62c9dca358d Mon Sep 17 00:00:00 2001 From: Justin Date: Thu, 4 Oct 2018 14:39:56 +0100 Subject: [PATCH 09/16] Update beacon-chain.md --- specs/beacon-chain.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/beacon-chain.md b/specs/beacon-chain.md index fb34848dd..37314e5f0 100644 --- a/specs/beacon-chain.md +++ b/specs/beacon-chain.md @@ -208,7 +208,7 @@ A `CrosslinkRecord` has the following fields: # Slot number 'slot': 'int64', # Beacon chain block hash - 'hash': 'hash32' + 'shard_block_hash': 'hash32' } ``` From b4f2317692a6c8c13e1ec71d9323159c14ce0289 Mon Sep 17 00:00:00 2001 From: Justin Date: Thu, 4 Oct 2018 21:59:36 +0100 Subject: [PATCH 10/16] Update beacon-chain.md --- specs/beacon-chain.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/specs/beacon-chain.md b/specs/beacon-chain.md index 37314e5f0..6ceb74bb8 100644 --- a/specs/beacon-chain.md +++ b/specs/beacon-chain.md @@ -123,8 +123,8 @@ A `SpecialRecord` has the following fields: ```python { - # Type - 'type': 'int8', + # Kind + 'kind': 'int8', # Data 'data': ['bytes'] } @@ -523,8 +523,8 @@ Let `committees` be the set of committees processed and `time_since_last_confirm For each `SpecialRecord` `obj` in `active_state.pending_specials`: -* **[covers logouts]**: If `obj.type == 0`, interpret `data[0]` as a validator index as an `int32` and `data[1]` as a signature. If `BLSVerify(pubkey=validators[data[0]].pubkey, msg=hash("bye bye"), sig=data[1])`, and `validators[i].status == LOGGED_IN`, set `validators[i].status = PENDING_EXIT` and `validators[i].exit_slot = current_slot` -* **[covers `NO_DBL_VOTE`, `NO_SURROUND`, `NO_DBL_PROPOSE` slashing conditions]:** If `obj.type == 1`, interpret `data[0]` as a list of concatenated `int32` 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 `inds` be the list of indices in both signatures; verify that its length is at least 1. For each validator index `v` in `inds`, set their end dynasty to equal the current dynasty plus 1, and if its `status` does not equal `PENALIZED`, then: +* **[covers logouts]**: If `obj.kind == 0`, interpret `data[0]` as a validator index as an `int32` and `data[1]` as a signature. If `BLSVerify(pubkey=validators[data[0]].pubkey, msg=hash("bye bye"), sig=data[1])`, and `validators[i].status == LOGGED_IN`, set `validators[i].status = PENDING_EXIT` and `validators[i].exit_slot = current_slot` +* **[covers `NO_DBL_VOTE`, `NO_SURROUND`, `NO_DBL_PROPOSE` slashing conditions]:** If `obj.kind == 1`, interpret `data[0]` as a list of concatenated `int32` 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 `inds` be the list of indices in both signatures; verify that its length is at least 1. For each validator index `v` in `inds`, set their end dynasty to equal the current dynasty plus 1, and if its `status` does not equal `PENALIZED`, then: 1. Set its `exit_slot` to equal the current `slot` 2. Set its `status` to `PENALIZED` From bf3fe932a26b2d1a09196060e8caf2dceb18a6e7 Mon Sep 17 00:00:00 2001 From: vbuterin Date: Thu, 4 Oct 2018 17:05:38 -0400 Subject: [PATCH 11/16] Update casper_sharding_v2.1.md --- specs/casper_sharding_v2.1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/casper_sharding_v2.1.md b/specs/casper_sharding_v2.1.md index 1359b8153..3254050ac 100644 --- a/specs/casper_sharding_v2.1.md +++ b/specs/casper_sharding_v2.1.md @@ -475,7 +475,7 @@ For each one of these attestations: * Verify that `len(attester_bitfield) == ceil_div8(len(attestation_indices))`, where `ceil_div8 = (x + 7) // 8`. Verify that bits `len(attestation_indices)....` and higher, if present (i.e. `len(attestation_indices)` is not a multiple of 8), are all zero * Derive a group public key by adding the public keys of all of the attesters in `attestation_indices` for whom the corresponding bit in `attester_bitfield` (the ith bit is `(attester_bitfield[i // 8] >> (7 - (i %8))) % 2`) equals 1 * Let `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(version, slot, parent_hashes, shard_id, shard_block_hash, crystallized_state.last_justified_slot)` as the message. +* Verify that `aggregate_sig` verifies using the group pubkey generated and the serialized form of `AttestationSignedData(version, slot, parent_hashes, shard_id, shard_block_hash, attestation.last_justified_slot)` as the message. Extend the list of `AttestationRecord` objects in the `active_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 `SpecialObject` objects in the `active_state` with those included in the block. From 9ee17787d217740eb528fa062afa9a75e95cf81e Mon Sep 17 00:00:00 2001 From: Justin Date: Fri, 5 Oct 2018 11:20:02 +0100 Subject: [PATCH 12/16] Homogenise AttestationSignedData data structure --- specs/beacon-chain.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/specs/beacon-chain.md b/specs/beacon-chain.md index 04664e114..16be55464 100644 --- a/specs/beacon-chain.md +++ b/specs/beacon-chain.md @@ -119,16 +119,21 @@ An `AttestationRecord` has the following fields: } ``` -Here's the data signed (`AttestationSignedData`): +An `AttestationSignedData` has the following fields: ```python -fields = { - # Version of the chain +{ + # Chain version 'version': 'int64', + # Slot number 'slot': 'int64', + # Shard number + 'shard': 'int16', + # 31 parent hashes 'parent_hashes': ['hash32'], - 'shard_id': 'int16', + # Shard block hash 'shard_block_hash': 'hash32', + # Slot of last justified block 'justified_slot': 'int64' } ``` @@ -491,7 +496,7 @@ For each one of these attestations: * Verify that `len(attester_bitfield) == ceil_div8(len(attestation_indices))`, where `ceil_div8 = (x + 7) // 8`. Verify that bits `len(attestation_indices)....` and higher, if present (i.e. `len(attestation_indices)` is not a multiple of 8), are all zero * Derive a group public key by adding the public keys of all of the attesters in `attestation_indices` for whom the corresponding bit in `attester_bitfield` (the ith bit is `(attester_bitfield[i // 8] >> (7 - (i %8))) % 2`) equals 1 * Let `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(version, slot, parent_hashes, shard_id, shard_block_hash, justified_slot)` as the message. +* Verify that `aggregate_sig` verifies using the group pubkey generated and the serialized form of `AttestationSignedData(version, slot, parent_hashes, shard, shard_block_hash, justified_slot)` as the message. Extend the list of `AttestationRecord` objects in the `active_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 `active_state` with those included in the block. From d6395fa67831de6af042b3ac10c7bad396482c45 Mon Sep 17 00:00:00 2001 From: Justin Date: Fri, 5 Oct 2018 11:25:52 +0100 Subject: [PATCH 13/16] Fix typo calling AttestationSignedData --- specs/beacon-chain.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/beacon-chain.md b/specs/beacon-chain.md index 16be55464..644a9b06b 100644 --- a/specs/beacon-chain.md +++ b/specs/beacon-chain.md @@ -496,7 +496,7 @@ For each one of these attestations: * Verify that `len(attester_bitfield) == ceil_div8(len(attestation_indices))`, where `ceil_div8 = (x + 7) // 8`. Verify that bits `len(attestation_indices)....` and higher, if present (i.e. `len(attestation_indices)` is not a multiple of 8), are all zero * Derive a group public key by adding the public keys of all of the attesters in `attestation_indices` for whom the corresponding bit in `attester_bitfield` (the ith bit is `(attester_bitfield[i // 8] >> (7 - (i %8))) % 2`) equals 1 * Let `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(version, slot, parent_hashes, shard, shard_block_hash, justified_slot)` as the message. +* Verify that `aggregate_sig` verifies using the group pubkey generated and the serialized form of `AttestationSignedData(version, slot, shard, parent_hashes, shard_block_hash, justified_slot)` as the message. Extend the list of `AttestationRecord` objects in the `active_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 `active_state` with those included in the block. From cb6e94a115169527e0ec75bdee958fd6b7af135d Mon Sep 17 00:00:00 2001 From: Justin Date: Fri, 5 Oct 2018 11:38:30 +0100 Subject: [PATCH 14/16] Make status codes consistent with "active" validators --- specs/beacon-chain.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/specs/beacon-chain.md b/specs/beacon-chain.md index 16be55464..cf1d303b5 100644 --- a/specs/beacon-chain.md +++ b/specs/beacon-chain.md @@ -55,8 +55,8 @@ The primary source of load on the beacon chain are "attestations". Attestations | Status code | Value | | - | :-: | -| `PENDING_LOG_IN` | `0` | -| `LOGGED_IN` | `1` | +| `PENDING_ACTIVATION` | `0` | +| `ACTIVE` | `1` | | `PENDING_EXIT` | `2` | | `PENDING_WITHDRAW` | `3` | | `WITHDRAWN` | `4` | @@ -300,7 +300,7 @@ We start off by defining some helper algorithms. First, the function that select ```python def get_active_validator_indices(validators): - return [i for i, v in enumerate(validators) if v.status == LOGGED_IN] + return [i for i, v in enumerate(validators) if v.status == ACTIVE] ``` Now, a function that shuffles this list: @@ -449,7 +449,7 @@ def add_validator(validators, pubkey, proof_of_possession, withdrawal_shard, withdrawal_address=withdrawal_address, randao_commitment=randao_commitment, balance=DEPOSIT_SIZE, # in WEI - status=PENDING_LOG_IN, + status=PENDING_ACTIVATION, exit_slot=0 ) index = min_empty_validator(validators) @@ -554,7 +554,7 @@ Let `committees` be the set of committees processed and `time_since_last_confirm For each `SpecialRecord` `obj` in `active_state.pending_specials`: -* **[covers logouts]**: If `obj.kind == 0`, interpret `data[0]` as a validator index as an `int32` and `data[1]` as a signature. If `BLSVerify(pubkey=validators[data[0]].pubkey, msg=hash("bye bye"), sig=data[1])`, and `validators[i].status == LOGGED_IN`, set `validators[i].status = PENDING_EXIT` and `validators[i].exit_slot = current_slot` +* **[covers logouts]**: If `obj.kind == 0`, interpret `data[0]` as a validator index as an `int32` and `data[1]` as a signature. If `BLSVerify(pubkey=validators[data[0]].pubkey, msg=hash("bye bye"), sig=data[1])`, and `validators[i].status == ACTIVE`, set `validators[i].status = PENDING_EXIT` and `validators[i].exit_slot = current_slot` * **[covers `NO_DBL_VOTE`, `NO_SURROUND`, `NO_DBL_PROPOSE` slashing conditions]:** If `obj.kind == 1`, interpret `data[0]` as a list of concatenated `int32` 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 `inds` be the list of indices in both signatures; verify that its length is at least 1. For each validator index `v` in `inds`, set their end dynasty to equal the current dynasty plus 1, and if its `status` does not equal `PENALIZED`, then: 1. Set its `exit_slot` to equal the current `slot` @@ -593,8 +593,8 @@ def change_validators(validators): # Go through the list start to end depositing+withdrawing as many as possible total_changed = 0 for i in range(len(validators)): - if validators[i].status == PENDING_LOG_IN: - validators[i].status = LOGGED_IN + if validators[i].status == PENDING_ACTIVATION: + validators[i].status = ACTIVE total_changed += DEPOSIT_SIZE add_validator_set_change_record(crystallized_state, i, validators[i].pubkey, ENTRY) if validators[i].status == PENDING_EXIT: From 64ba1aa931578d312703c3bb07e35a8801a27522 Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Fri, 5 Oct 2018 21:16:02 +0600 Subject: [PATCH 15/16] Get rid of redundant recent_block_hashes entry --- specs/beacon-chain.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/specs/beacon-chain.md b/specs/beacon-chain.md index 16be55464..f98d8dd56 100644 --- a/specs/beacon-chain.md +++ b/specs/beacon-chain.md @@ -157,8 +157,6 @@ The `ActiveState` has the following fields: ```python { - # Most recent 2 * CYCLE_LENGTH block hashes, oldest to newest - 'recent_block_hashes': ['hash32'], # Attestations not yet processed 'pending_attestations': [AttestationRecord], # Specials not yet been processed From d495b0ec4f297eb7221789ed543ad0f46b02cc49 Mon Sep 17 00:00:00 2001 From: Danny Ryan Date: Fri, 5 Oct 2018 12:05:09 -0400 Subject: [PATCH 16/16] clear up a comment in AttestationSignedData --- specs/beacon-chain.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/beacon-chain.md b/specs/beacon-chain.md index 644a9b06b..56555792f 100644 --- a/specs/beacon-chain.md +++ b/specs/beacon-chain.md @@ -133,7 +133,7 @@ An `AttestationSignedData` has the following fields: 'parent_hashes': ['hash32'], # Shard block hash 'shard_block_hash': 'hash32', - # Slot of last justified block + # Slot of last justified block referenced in the attestation 'justified_slot': 'int64' } ```