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

add ForkDigest type, clarify how genesis_validators_root is mixed into domains for chain isolation in p2p faq

This commit is contained in:
Danny Ryan 2020-03-10 11:59:34 -06:00
parent b119f5ff14
commit 1818f349ad
No known key found for this signature in database
GPG Key ID: 2765A792E42CE07A
2 changed files with 7 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
specs/phase0/beacon-chain.md
View File

@ -149,6 +149,7 @@ We define the following Python custom types for type hinting and readability:
| `Root` | `Bytes32` | a Merkle root |
| `Version` | `Bytes4` | a fork version number |
| `DomainType` | `Bytes4` | a domain type |
| `ForkDigest` | `Bytes4` | a digest of the current fork data |
| `Domain` | `Bytes32` | a signature domain |
| `BLSPubkey` | `Bytes48` | a BLS12-381 public key |
| `BLSSignature` | `Bytes96` | a BLS12-381 signature |
@ -803,7 +804,7 @@ def compute_domain(domain_type: DomainType, fork_version: Optional[Version]=None
if fork_version is None:
fork_version = GENESIS_FORK_VERSION
if genesis_root is None:
genesis_root = Root()
genesis_root = Root() # all bytes zero by default
return Domain(domain_type + fork_version + genesis_root[:24])
```

10
specs/phase0/p2p-interface.md
View File

@ -615,7 +615,7 @@ ENRs MUST carry a generic `eth2` key with an 16-byte value of the node's current
|:-------------|:--------------------|
| `eth2` | SSZ `ENRForkID` |
First we define `current_fork` as the following SSZ encoded object
First we define `current_fork_data` as the following SSZ encoded object
```
(
@ -633,7 +633,7 @@ Specifically, the value of the `eth2` key MUST be the following SSZ encoded obje
```
(
current_fork_digest: Bytes4
current_fork_digest: ForkDigest
next_fork_version: Version
next_fork_epoch: Epoch
)
@ -641,7 +641,7 @@ Specifically, the value of the `eth2` key MUST be the following SSZ encoded obje
where the fields of `ENRForkID` are defined as
* `current_fork_digest` is `hash_tree_root(current_fork)[:4]`
* `current_fork_digest` is `ForkDigest(hash_tree_root(current_fork_data)[:4])`
* `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
@ -872,9 +872,9 @@ Although this method will be sufficient for early phases of Eth2, we aim to use
### How should fork version be used in practice?
Fork versions are to be manually updated (likely via incrementing or using the less collision-prone git spec hash) at each hard fork. This is to provide native domain separation for signatures as well as to aid in usefulness for identitying peers (via ENRs) and versioning network protocols (e.g. using fork version to naturally version gossipsub topics).
Fork versions are to be manually updated (likely via incrementing) at each hard fork. This is to provide native domain separation for signatures as well as to aid in usefulness for identitying peers (via ENRs) and versioning network protocols (e.g. using fork version to naturally version gossipsub topics).
To reap the full benefit of the native versioning scheme, networks SHOULD avoid collisions. For example, a testnet might us mainnet versioning but use a unique higher order byte to signal the testnet.
`BeaconState.genesis_validators_root` is mixed into signature and ENR fork domains to aid in the ease of domain separation between chains. This allows fork versions to safely be reused across chains except for the case of contentious forks using the same genesis. In these cases, extra care should be taken to isolate fork versions (e.g. flip a high order bit in all future versions of one of the chains).
A node locally stores all previous and future planned fork versions along with the each fork epoch. This allows for handling sync starting from past forks/epochs and for connections to safely be made with peers syncing from past forks/epochs.