add note about distributing bootnode ENRs prior to genesis

ethereum · Apr 22, 2020 · 3d4122a · 3d4122a
1 parent 018713b
commit 3d4122a
Show file tree

Hide file tree

Showing 2 changed files with 12 additions and 12 deletions.
diff --git a/.circleci/config.yml b/.circleci/config.yml
@@ -79,16 +79,16 @@ jobs:
       # Restore git repo at point close to target branch/revision, to speed up checkout
       - restore_cache:
           keys:
-            - v2-specs-repo-{{ .Branch }}-{{ .Revision }}
-            - v2-specs-repo-{{ .Branch }}-
-            - v2-specs-repo-
+            - v3-specs-repo-{{ .Branch }}-{{ .Revision }}
+            - v3-specs-repo-{{ .Branch }}-
+            - v3-specs-repo-
       - checkout
       - run:
           name: Clean up git repo to reduce cache size
           command: git gc
       # Save the git checkout as a cache, to make cloning next time faster.
       - save_cache:
-          key: v2-specs-repo-{{ .Branch }}-{{ .Revision }}
+          key: v3-specs-repo-{{ .Branch }}-{{ .Revision }}
           paths:
             - ~/specs-repo
   install_pyspec_test:
@@ -97,7 +97,7 @@ jobs:
     working_directory: ~/specs-repo
     steps:
       - restore_cache:
-          key: v2-specs-repo-{{ .Branch }}-{{ .Revision }}
+          key: v3-specs-repo-{{ .Branch }}-{{ .Revision }}
       - restore_pyspec_cached_venv
       - run:
           name: Install pyspec requirements
@@ -109,7 +109,7 @@ jobs:
     working_directory: ~/specs-repo
     steps:
       - restore_cache:
-          key: v2-specs-repo-{{ .Branch }}-{{ .Revision }}
+          key: v3-specs-repo-{{ .Branch }}-{{ .Revision }}
       - restore_pyspec_cached_venv
       - run:
           name: Run py-tests
@@ -140,7 +140,7 @@ jobs:
     working_directory: ~/specs-repo
     steps:
       - restore_cache:
-          key: v2-specs-repo-{{ .Branch }}-{{ .Revision }}
+          key: v3-specs-repo-{{ .Branch }}-{{ .Revision }}
       - restore_pyspec_cached_venv
       - run:
           name: Run linter
@@ -152,7 +152,7 @@ jobs:
     working_directory: ~/specs-repo
     steps:
       - restore_cache:
-          key: v2-specs-repo-{{ .Branch }}-{{ .Revision }}
+          key: v3-specs-repo-{{ .Branch }}-{{ .Revision }}
       - restore_deposit_contract_compiler_cached_venv
       - run:
           name: Install deposit contract compiler requirements
@@ -164,7 +164,7 @@ jobs:
     working_directory: ~/specs-repo
     steps:
       - restore_cache:
-          key: v2-specs-repo-{{ .Branch }}-{{ .Revision }}
+          key: v3-specs-repo-{{ .Branch }}-{{ .Revision }}
       - restore_deposit_contract_tester_cached_venv
       - run:
           name: Install deposit contract tester requirements
@@ -176,7 +176,7 @@ jobs:
     working_directory: ~/specs-repo
     steps:
       - restore_cache:
-          key: v2-specs-repo-{{ .Branch }}-{{ .Revision }}
+          key: v3-specs-repo-{{ .Branch }}-{{ .Revision }}
       - restore_deposit_contract_compiler_cached_venv
       - run:
           name: Run deposit contract compile test
@@ -187,7 +187,7 @@ jobs:
     working_directory: ~/specs-repo
     steps:
       - restore_cache:
-          key: v2-specs-repo-{{ .Branch }}-{{ .Revision }}
+          key: v3-specs-repo-{{ .Branch }}-{{ .Revision }}
       - restore_deposit_contract_tester_cached_venv
       - run:
           name: Run deposit contract test

diff --git a/specs/phase0/p2p-interface.md b/specs/phase0/p2p-interface.md
@@ -755,7 +755,7 @@ where the fields of `ENRForkID` are defined as
 * `next_fork_version` is the fork version corresponding to the next planned hard fork at a future epoch. If no future fork is planned, set `next_fork_version = current_fork_version` to signal this fact
 * `next_fork_epoch` is the epoch at which the next fork is planned and the `current_fork_version` will be updated. If no future fork is planned, set `next_fork_epoch = FAR_FUTURE_EPOCH` to signal this fact
 
-*Note*: `fork_digest` is composed of values that are not not known until the genesis block/state are available. Due to this, clients SHOULD NOT form ENRs and begin peer discovery until genesis values are known.
+*Note*: `fork_digest` is composed of values that are not not known until the genesis block/state are available. Due to this, clients SHOULD NOT form ENRs and begin peer discovery until genesis values are known. One notable exception to this rule is the distribution of bootnode ENRs prior to genesis. In this case, bootnode ENRs SHOULD be initially distributed with `eth2` field set as `ENRForkID(fork_digest=compute_fork_digest(GENESIS_FORK_VERSION, b'\x00'*32), next_fork_version=GENESIS_FORK_VERSION, next_fork_epoch=FAR_FUTURE_EPOCH)`. After genesis values are known, the bootnodes SHOULD update ENRs to participate in normal discovery operations.
 
 Clients SHOULD connect to peers with `fork_digest`, `next_fork_version`, and `next_fork_epoch` that match local values.