From faf36e056f223927564d2fbf327926ddc455ce59 Mon Sep 17 00:00:00 2001 From: Alex Stokes Date: Wed, 1 May 2019 16:10:01 -0700 Subject: [PATCH 1/2] Add notes to compute fork choice at genesis --- specs/core/0_fork-choice.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/specs/core/0_fork-choice.md b/specs/core/0_fork-choice.md index 0b19f1559..cb11ea860 100644 --- a/specs/core/0_fork-choice.md +++ b/specs/core/0_fork-choice.md @@ -13,6 +13,8 @@ - [Time parameters](#time-parameters) - [Beacon chain processing](#beacon-chain-processing) - [Beacon chain fork choice rule](#beacon-chain-fork-choice-rule) + - [Implementation notes](#implementation-notes) + - [Justification and finality at genesis](#justification-and-finality-at-genesis) @@ -99,3 +101,9 @@ def lmd_ghost(store: Store, start_state: BeaconState, start_block: BeaconBlock) # Ties broken by favoring block with lexicographically higher root head = max(children, key=lambda x: (get_vote_count(x), hash_tree_root(x))) ``` + +## Implementation notes + +### Justification and finality at genesis + +Clients may choose to refer to the justification and finality data in a given `BeaconState` to determine the finalized/justified head. During the early epochs right after genesis, the justification and finality data are not stored in the `BeaconState`. In their place are "empty" values; for example, the 32-byte zero value as the `finalized_root`. Clients wishing to compute the fork choice in these early epochs should work around this fact of the `BeaconState` to recognize that the genesis epoch and root of the genesis block are _both_ the finalized and justified heads until updated via the state transition function defined in [Phase 0 -- The Beacon Chain](./0_beacon-chain.md). Solutions will be language-specific but one possibility is to treat the zero-value hash as an exceptional case that references the genesis block/epoch. From 7d0a6191edade473053cec49ce560ea253a220fd Mon Sep 17 00:00:00 2001 From: Danny Ryan Date: Mon, 6 May 2019 09:09:37 -0600 Subject: [PATCH 2/2] simplify justificatio/finality notes at genesis --- specs/core/0_fork-choice.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/core/0_fork-choice.md b/specs/core/0_fork-choice.md index cb11ea860..8ec0a604c 100644 --- a/specs/core/0_fork-choice.md +++ b/specs/core/0_fork-choice.md @@ -106,4 +106,4 @@ def lmd_ghost(store: Store, start_state: BeaconState, start_block: BeaconBlock) ### Justification and finality at genesis -Clients may choose to refer to the justification and finality data in a given `BeaconState` to determine the finalized/justified head. During the early epochs right after genesis, the justification and finality data are not stored in the `BeaconState`. In their place are "empty" values; for example, the 32-byte zero value as the `finalized_root`. Clients wishing to compute the fork choice in these early epochs should work around this fact of the `BeaconState` to recognize that the genesis epoch and root of the genesis block are _both_ the finalized and justified heads until updated via the state transition function defined in [Phase 0 -- The Beacon Chain](./0_beacon-chain.md). Solutions will be language-specific but one possibility is to treat the zero-value hash as an exceptional case that references the genesis block/epoch. +During genesis, justification and finality root fields within the `BeaconState` reference `ZERO_HASH` rather than a known block. `ZERO_HASH` in `previous_justified_root`, `current_justified_root`, and `finalized_root` should be considered as an alias to the root of the genesis block.