Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update EIP-2982: fix table displaying error #8607

Merged
merged 2 commits into from
Jun 19, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions EIPS/eip-2982.md
Original file line number Diff line number Diff line change
Expand Up @@ -34,7 +34,7 @@
### Decentralization and economic finality through proof-of-stake

Since the early days of Ethereum, proof-of-stake has been a long-awaited desideratum for the following:
* Increased decentralization of the core consensus by lowering the barrier to entry and technical requirements of participation

Check failure on line 37 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Lists should be surrounded by blank lines [Context: "* Increased decentralization o..."]

EIPS/eip-2982.md:37 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "* Increased decentralization o..."]

Check failure on line 37 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Lists should be surrounded by blank lines [Context: "* Increased decentralization o..."]

EIPS/eip-2982.md:37 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "* Increased decentralization o..."]

Check failure on line 37 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Lists should be surrounded by blank lines [Context: "* Increased decentralization o..."]

EIPS/eip-2982.md:37 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "* Increased decentralization o..."]
* Increased cryptoeconomic security via in-protocol penalties for misbehaviour and the addition of economic finality
* Elimination of the energy hungry mining of the current PoW consensus mechanism

Expand Down Expand Up @@ -107,7 +107,7 @@
For PoS protocols to be crypto-economically secure, in-protocol penalties are required. Small offline penalties incentivize validator liveness, whereas (potentially) much larger penalties provide protocol security in the event of tail-risk scenarios.

Specifically, the following significant penalties exist:
* **Inactivity Leak**: an offline penalty that increases each epoch is applied to validators during extended times of no finality (e.g. if one-third or more are offline or not on the canonical chain). This ensures the chain can eventually regain finality even under catastrophic conditions.

Check failure on line 110 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Lists should be surrounded by blank lines [Context: "* **Inactivity Leak**: an offl..."]

EIPS/eip-2982.md:110 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "* **Inactivity Leak**: an offl..."]

Check failure on line 110 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Lists should be surrounded by blank lines [Context: "* **Inactivity Leak**: an offl..."]

EIPS/eip-2982.md:110 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "* **Inactivity Leak**: an offl..."]

Check failure on line 110 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Lists should be surrounded by blank lines [Context: "* **Inactivity Leak**: an offl..."]

EIPS/eip-2982.md:110 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "* **Inactivity Leak**: an offl..."]
* **Slashing**: a penalty applied to validators that sign _explicitly malicious_ messages that could lead to the construction and finalization of two conflicting chains (e.g. two blocks or attestations in the same slot). This penalty is designed to scale up in proportion to the number of slashable validators in the same time period such that if a critical number (wrt chain safety) of slashings have occurred, validators are _maximally_ punished.

For the initial launch of Phase 0, the parameters defining the magnitude of these penalties -- `INACTIVITY_PENALTY_QUOTIENT`, `PROPORTIONAL_SLASHING_MULTIPLIER`, and `MIN_SLASHING_PENALTY_QUOTIENT` -- have been tuned to be less punitive than their final intended values. This provides a more forgiving environment for early validators and client software in an effort to encourage validation in this early, higher technical-risk stage.
Expand Down Expand Up @@ -212,8 +212,8 @@

Here is the current expected security properties expressed in a table:

|| Network delay <3s |Network delay 3s - 6 min|Network delay > 6 min|
|---|---|---|---|---|
| | Network delay <3s |Network delay 3s - 6 min|Network delay > 6 min|
|---|---|---|---|
|>2/3 validators honest|Perfect operation|Imperfect but acceptable operation. No rigorous proof of liveness, but liveness expected in practice.|Likely intermittent liveness failures, no safety failures|
|>2/3 validators rational, <1/3 coordinated|Perfect operation|Imperfect but acceptable operation, heightened centralization risk|Likely intermittent liveness failures, no safety failures, very high centralization risk|
|51% attacker|Can revert finality or censor, but at high cost; cannot force through invalid or unavailable chains|Can revert finality or censor, but at high cost; cannot force through invalid or unavailable chains|Can revert finality or censor; cannot force through invalid or unavailable chains|
Expand Down Expand Up @@ -376,7 +376,7 @@

#### Generalized indices

See https://github.com/ethereum/eth2.0-specs/blob/dev/ssz/merkle-proofs.md for a description of generalized indices, and how they allow for very easy verification of Merkle proofs "poking into" arbitrary positions in an object by representing paths as an integer or bitfield.

Check failure on line 379 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image

error[markdown-rel-links]: non-relative link or image --> EIPS/eip-2982.md | 379 | See https://github.com/ethereum/eth2.0-specs/blob/dev/ssz/merkle-proofs.md for a description of generalized indices, and how they allow for very easy verification of Merkle proofs "poking into" arbitrary positions in an object by representing paths as an integer or bitfield. | = help: see https://ethereum.github.io/eipw/markdown-rel-links/

Check failure on line 379 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image

error[markdown-rel-links]: non-relative link or image --> EIPS/eip-2982.md | 379 | See https://github.com/ethereum/eth2.0-specs/blob/dev/ssz/merkle-proofs.md for a description of generalized indices, and how they allow for very easy verification of Merkle proofs "poking into" arbitrary positions in an object by representing paths as an integer or bitfield. | = help: see https://ethereum.github.io/eipw/markdown-rel-links/

Check failure on line 379 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image

error[markdown-rel-links]: non-relative link or image --> EIPS/eip-2982.md | 379 | See https://github.com/ethereum/eth2.0-specs/blob/dev/ssz/merkle-proofs.md for a description of generalized indices, and how they allow for very easy verification of Merkle proofs "poking into" arbitrary positions in an object by representing paths as an integer or bitfield. | = help: see https://ethereum.github.io/eipw/markdown-rel-links/

### The validator lifecycle

Expand All @@ -400,7 +400,7 @@

When a validator exits (whether by publishing a voluntary exit message or being slashed), they are similarly put into an exit queue with the same maximum throughput.

The reason for the entrance/exit queue limits is to ensure that the validator set cannot change too quickly between any two points in time, which ensures that finality guarantees still remain between two chains as long as a validator logs on often enough (once every ~1-2 months if $|V| \ge 262144$). See here https://ethresear.ch/t/rate-limiting-entry-exits-not-withdrawals/4942 for rationale (and specifically why to use a rate limit instead of a fixed waiting time) and https://ethresear.ch/t/weak-subjectivity-under-the-exit-queue-model/5187 for how to calculate safety margin for a client that has been offline for some amount of time.

Check failure on line 403 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image

error[markdown-rel-links]: non-relative link or image --> EIPS/eip-2982.md | 403 | The reason for the entrance/exit queue limits is to ensure that the validator set cannot change too quickly between any two points in time, which ensures that finality guarantees still remain between two chains as long as a validator logs on often enough (once every ~1-2 months if $|V| \ge 262144$). See here https://ethresear.ch/t/rate-limiting-entry-exits-not-withdrawals/4942 for rationale (and specifically why to use a rate limit instead of a fixed waiting time) and https://ethresear.ch/t/weak-subjectivity-under-the-exit-queue-model/5187 for how to calculate safety margin for a client that has been offline for some amount of time. |

Check failure on line 403 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image

error[markdown-rel-links]: non-relative link or image --> EIPS/eip-2982.md | 403 | The reason for the entrance/exit queue limits is to ensure that the validator set cannot change too quickly between any two points in time, which ensures that finality guarantees still remain between two chains as long as a validator logs on often enough (once every ~1-2 months if $|V| \ge 262144$). See here https://ethresear.ch/t/rate-limiting-entry-exits-not-withdrawals/4942 for rationale (and specifically why to use a rate limit instead of a fixed waiting time) and https://ethresear.ch/t/weak-subjectivity-under-the-exit-queue-model/5187 for how to calculate safety margin for a client that has been offline for some amount of time. |

Check failure on line 403 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image

error[markdown-rel-links]: non-relative link or image --> EIPS/eip-2982.md | 403 | The reason for the entrance/exit queue limits is to ensure that the validator set cannot change too quickly between any two points in time, which ensures that finality guarantees still remain between two chains as long as a validator logs on often enough (once every ~1-2 months if $|V| \ge 262144$). See here https://ethresear.ch/t/rate-limiting-entry-exits-not-withdrawals/4942 for rationale (and specifically why to use a rate limit instead of a fixed waiting time) and https://ethresear.ch/t/weak-subjectivity-under-the-exit-queue-model/5187 for how to calculate safety margin for a client that has been offline for some amount of time. |

Check failure on line 403 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image

error[markdown-rel-links]: non-relative link or image --> EIPS/eip-2982.md | 403 | The reason for the entrance/exit queue limits is to ensure that the validator set cannot change too quickly between any two points in time, which ensures that finality guarantees still remain between two chains as long as a validator logs on often enough (once every ~1-2 months if $|V| \ge 262144$). See here https://ethresear.ch/t/rate-limiting-entry-exits-not-withdrawals/4942 for rationale (and specifically why to use a rate limit instead of a fixed waiting time) and https://ethresear.ch/t/weak-subjectivity-under-the-exit-queue-model/5187 for how to calculate safety margin for a client that has been offline for some amount of time. |

Check failure on line 403 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image

error[markdown-rel-links]: non-relative link or image --> EIPS/eip-2982.md | 403 | The reason for the entrance/exit queue limits is to ensure that the validator set cannot change too quickly between any two points in time, which ensures that finality guarantees still remain between two chains as long as a validator logs on often enough (once every ~1-2 months if $|V| \ge 262144$). See here https://ethresear.ch/t/rate-limiting-entry-exits-not-withdrawals/4942 for rationale (and specifically why to use a rate limit instead of a fixed waiting time) and https://ethresear.ch/t/weak-subjectivity-under-the-exit-queue-model/5187 for how to calculate safety margin for a client that has been offline for some amount of time. |

Check failure on line 403 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image

error[markdown-rel-links]: non-relative link or image --> EIPS/eip-2982.md | 403 | The reason for the entrance/exit queue limits is to ensure that the validator set cannot change too quickly between any two points in time, which ensures that finality guarantees still remain between two chains as long as a validator logs on often enough (once every ~1-2 months if $|V| \ge 262144$). See here https://ethresear.ch/t/rate-limiting-entry-exits-not-withdrawals/4942 for rationale (and specifically why to use a rate limit instead of a fixed waiting time) and https://ethresear.ch/t/weak-subjectivity-under-the-exit-queue-model/5187 for how to calculate safety margin for a client that has been offline for some amount of time. |

#### Withdrawal

Expand Down Expand Up @@ -439,5 +439,5 @@

In addition to the research supporting this path, a number of audits and formal verification of specs, cryptography, and client implementations have been performed. _Many client and utility library audits are currently in progress and will be appended here upon completion._

## Copyright

Check failure on line 442 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Copyright"]

EIPS/eip-2982.md:442 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Copyright"]

Check failure on line 442 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Copyright"]

EIPS/eip-2982.md:442 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Copyright"]

Check failure on line 442 in EIPS/eip-2982.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Copyright"]

EIPS/eip-2982.md:442 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Copyright"]
Copyright and related rights waived via [CC0](../LICENSE.md).
Loading