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

Apply suggestions from Danny's code review 

Co-authored-by: Danny Ryan <dannyjryan@gmail.com>
This commit is contained in:
Aditya Asgaonkar 2020-09-17 10:26:49 -07:00 committed by GitHub
parent 2023b24d72
commit 6b33c766f2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 14 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
specs/phase0/weak-subjectivity.md
View File

@ -3,6 +3,7 @@
**Notice**: This document is a work-in-progress for researchers and implementers. **Notice**: This document is a work-in-progress for researchers and implementers.
## Table of contents ## Table of contents
<!-- TOC --> <!-- TOC -->
<!-- START doctoc generated TOC please keep comment here to allow auto update --> <!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
@ -28,7 +29,7 @@ This document is a guide for implementing the Weak Subjectivity protections in P
- [Proof of Stake: How I Learned to Love Weak Subjectivity](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) - [Proof of Stake: How I Learned to Love Weak Subjectivity](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/)
## Prerequisites ## Prerequisites
This document uses data structures, constants, functions, and terminology from [Phase 0 -- The Beacon Chain](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md) and [Phase 0 -- Beacon Chain Fork Choice](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md). This document uses data structures, constants, functions, and terminology from [Phase 0 -- The Beacon Chain](./beacon-chain.md) and [Phase 0 -- Beacon Chain Fork Choice](./fork-choice.md).
## Constants ## Constants
| Name | Value | | Name | Value |
@ -40,16 +41,19 @@ This document uses data structures, constants, functions, and terminology from [
Any `Checkpoint` can used be a Weak Subjectivity Checkpoint. These Weak Subjectivity Checkpoints are distributed by providers, downloaded by users and/or distributed as a part of clients, and used as input while syncing a client. Any `Checkpoint` can used be a Weak Subjectivity Checkpoint. These Weak Subjectivity Checkpoints are distributed by providers, downloaded by users and/or distributed as a part of clients, and used as input while syncing a client.
## Weak Subjectivity Period ## Weak Subjectivity Period
The Weak Subjectivity Period is the number of recent epochs within which there must be a Weak Subjectivity Checkpoint so that an attacker who takes control of the validator set at the beginning of the period is slashed at least a threshold amount in case a conflicting `Checkpoint` is finalized. `SAFETY_DECAY` is defined as the maximum percentage tolerable loss in the 1/3rd safety margin of FFG finality, which makes our threshold amount of slashing to be 1/3 - `SAFETY_DECAY/100`. The Weak Subjectivity Period is the number of recent epochs within which there must be a Weak Subjectivity Checkpoint to ensure that an attacker who takes control of the validator set at the beginning of the period is slashed at least a minimum threshold in the event that a conflicting `Checkpoint` is finalized.
`SAFETY_DECAY` is defined as the maximum percentage tolerable loss in the one-third safety margin of FFG finality. Thus, any attack exploiting the Weak Subjectivity Period has a safety margin of at least `1/3 - SAFETY_DECAY/100`.
### Calculating the Weak Subjectivity Period ### Calculating the Weak Subjectivity Period
For more information about this calculation, refer to [Weak Subjectivity in Eth2.0](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2). For more information about this calculation, refer to [Weak Subjectivity in Eth2.0](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2).
Note: `compute_weak_subjectivity_period()` is planned to be updated when a more accurate calculation is made. *Note*: `compute_weak_subjectivity_period()` is planned to be updated when a more accurate calculation is made.
```python ```python
def compute_weak_subjectivity_period(state): def compute_weak_subjectivity_period(state: BeaconState) -> uint64:
weak_subjectivity_period = MIN_VALIDATOR_WITHDRAWABILITY_DELAY weak_subjectivity_period = MIN_VALIDATOR_WITHDRAWABILITY_DELAY
val_count = len(get_active_validator_indices(state, get_current_epoch(state))) validator_count = len(get_active_validator_indices(state, get_current_epoch(state)))
if val_count >= MIN_PER_EPOCH_CHURN_LIMIT * CHURN_LIMIT_QUOTIENT: if val_count >= MIN_PER_EPOCH_CHURN_LIMIT * CHURN_LIMIT_QUOTIENT:
weak_subjectivity_period += SAFETY_DECAY * CHURN_LIMIT_QUOTIENT / (2 * 100) weak_subjectivity_period += SAFETY_DECAY * CHURN_LIMIT_QUOTIENT / (2 * 100)
else: else:
@ -73,10 +77,10 @@ A brief reference for what these values look like in practice:
| 524288 | 3532 | | 524288 | 3532 |
## Weak Subjectivity Sync ## Weak Subjectivity Sync
Clients should allow users to input a Weak Subjectivity Checkpoint at startup, and guarantee that any successful sync leads to the given Weak Subjectivity Checkpoint being in the canonical chain. If such a sync is not possible, the client should treat this as a critical and irrecoverable failure. Clients should allow users to input a Weak Subjectivity Checkpoint at startup, and guarantee that any successful sync leads to the given Weak Subjectivity Checkpoint along the canonical chain. If such a sync is not possible, the client should treat this as a critical and irrecoverable failure.
### Weak Subjectivity Sync Procedure ### Weak Subjectivity Sync Procedure
1. Take a Weak Subjectivity Checkpoint as a CLI parameter input in `block_root:epoch_number` format, where `block_root` and `epoch_number` represent a valid `Checkpoint`. Example of the format: 1. Input a Weak Subjectivity Checkpoint as a CLI parameter in `block_root:epoch_number` format, where `block_root` (an "0x" prefixed 32-byte hex string) and `epoch_number` (an integer) represent a valid `Checkpoint`. Example of the format:
``` ```
0x8584188b86a9296932785cc2827b925f9deebacce6d72ad8d53171fa046b43d9:9544 0x8584188b86a9296932785cc2827b925f9deebacce6d72ad8d53171fa046b43d9:9544
``` ```
@ -86,7 +90,7 @@ Clients should allow users to input a Weak Subjectivity Checkpoint at startup, a
### Checking for Stale Weak Subjectivity Checkpoint ### Checking for Stale Weak Subjectivity Checkpoint
Clients may choose to validate that the input Weak Subjectivity Checkpoint is not stale at the time of startup. To support this mechanism, the client needs to take the state at the Weak Subjectivity Checkpoint as a CLI parameter input (or fetch the state associated with the input Weak Subjectivity Checkpoint from some source). The check can be implemented in the following way: Clients may choose to validate that the input Weak Subjectivity Checkpoint is not stale at the time of startup. To support this mechanism, the client needs to take the state at the Weak Subjectivity Checkpoint as a CLI parameter input (or fetch the state associated with the input Weak Subjectivity Checkpoint from some source). The check can be implemented in the following way:
```python ```python
def is_within_weak_subjectivity_period(store, ws_state, ws_checkpoint): def is_within_weak_subjectivity_period(store: Store, ws_state: BeaconState, ws_checkpoint: Checkpoint) -> bool:
# Clients may choose to validate the input state against the input Weak Subjectivity Checkpoint # Clients may choose to validate the input state against the input Weak Subjectivity Checkpoint
assert ws_state.latest_block_header.state_root == ws_checkpoint.root assert ws_state.latest_block_header.state_root == ws_checkpoint.root
assert compute_epoch_at_slot(ws_state.slot) == ws_checkpoint.epoch assert compute_epoch_at_slot(ws_state.slot) == ws_checkpoint.epoch