HackMD
    • Options
    • Versions and GitHub Sync
    • Transfer ownership
    • Delete this note
    • Template
    • Save as template
    • Insert from template
    • Export
    • Dropbox
    • Google Drive
    • Gist
    • Import
    • Dropbox
    • Google Drive
    • Gist
    • Clipboard
    • Download
    • Markdown
    • HTML
    • Raw HTML
    • ODF (Beta)
    • PDF (Beta)
    • Sharing Link copied
    • /edit
    • View mode
      • Edit mode
      • View mode
      • Book mode
      • Slide mode
      Edit mode View mode Book mode Slide mode
    • Note Permission
    • Read
      • Owners
      • Signed-in users
      • Everyone
      Owners Signed-in users Everyone
    • Write
      • Owners
      • Signed-in users
      • Everyone
      Owners Signed-in users Everyone
    • More (Comment, Invitee)
    • Publishing
      Everyone on the web can find and read all notes of this public team.
      After the note is published, everyone on the web can find and read this note.
      See all published notes on profile page.
    • Commenting Enable
      Disabled Forbidden Owners Signed-in users Everyone
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
      • Everyone
    • Invitee
    • No invitee
Menu Sharing Help
Menu
Options
Versions and GitHub Sync Transfer ownership Delete this note
Export
Dropbox Google Drive Gist
Import
Dropbox Google Drive Gist Clipboard
Download
Markdown HTML Raw HTML ODF (Beta) PDF (Beta)
Back
Sharing
Sharing Link copied
/edit
View mode
  • Edit mode
  • View mode
  • Book mode
  • Slide mode
Edit mode View mode Book mode Slide mode
Note Permission
Read
Owners
  • Owners
  • Signed-in users
  • Everyone
Owners Signed-in users Everyone
Write
Owners
  • Owners
  • Signed-in users
  • Everyone
Owners Signed-in users Everyone
More (Comment, Invitee)
Publishing
Everyone on the web can find and read all notes of this public team.
After the note is published, everyone on the web can find and read this note.
See all published notes on profile page.
More (Comment, Invitee)
Commenting Enable
Disabled Forbidden Owners Signed-in users Everyone
Permission
Owners
  • Forbidden
  • Owners
  • Signed-in users
  • Everyone
Invitee
No invitee
   owned this note    owned this note      
Published Linked with GitHub
Like BookmarkBookmarked
Subscribed
  • Any changes
    Be notified of any changes
  • Mention me
    Be notified of mention me
  • Unsubscribe
Subscribe
# HF1 Proposal HF1 is the tentative code name for the first hard fork of the beacon chain (see [here](https://github.com/ethereum/eth2.0-pm/issues/202) for longer-term naming ideas). The key goals of HF1 are: 1. Add light client support 2. Fix some weaknesses in the beacon chain that were discovered too late to be fixed at genesis 3. Test the hard forking mechanism with a relatively small change, before larger changes (sharding, merge) need to be done ## Proposed consensus changes in HF1 ### Sync committees We add a randomly sampled "sync committee" to the beacon chain. The purpose of this is to allow light clients to determine the head of the chain with a low amount of overhead (~20 kB per day minimum to keep up, and ~500 bytes to verify a single block). This would allow light clients to actually be viable for mobile devices, in-browser use cases in the like for the beacon chain (and post-merge Ethereum as a whole), paving the way for a much more trust-minimized wallet ecosystem. For each period (~27 hours), 1024 validators are randomly selected to be part of the sync committee during that period. Validators in the sync committee would publish signatures attesting to the current head. These signatures would be broadcasted as part of a `LightClientUpdate` object that could help light clients find the head, and would be included in the beacon chain to be rewarded. Key PR: * https://github.com/ethereum/eth2.0-specs/pull/2130 ### Accounting reform (tier 1) We replace the way that rewards for attesters are computed. Instead of storing `PendingAttestation` objects and then processing them at the end, we add a bitfield that stores the status of each validator, allowing the data about who participated to be accumulated in real time. The bitfield is ordered "in shuffled order", ensuring that records for validators in the same committee appear together. The goal of this change is to simplify client implementations and to make updating the Merkle tree much cheaper. Key PR: * https://github.com/ethereum/eth2.0-specs/pull/2176 ### Accounting reform (tier 2) We make validator set changes and penalty accounting only happen once every 64 epochs, instead of every single epoch. The goal of this is to greatly reduce the complexity of processing "empty epoch transitions" - for example, a chain with very low participation where two successive blocks are a thousand slots apart with only empty space between them. To process such a chain, currently clients would need to recompute each validator's balance once per epoch to apply inactivity penalties; with this proposal, they would only need to do so once per 64 epochs. Additionally, we add two changes to how inactivity leaks work: * **The inactivity leak becomes quadratic per validator**. That is, if there is an inactivity leak during which a fully offline validator loses ~10% of their balance, a validator that is online 90% of the time during that period would lose only ~0.1% of their balance (as opposed to ~1%). This attempts to focus penalties on truly misbehaving nodes and reduce penalties to honest nodes that merely have an imperfect connection to the network. See [here](https://github.com/ethereum/eth2.0-specs/issues/2125) for further discussion. * **The inactivity leak slows down gradually upon finality instead of stopping**. This ensures that once finality is reached, offline nodes continue to lose balance for some time further, ensuring that the percentage online is significantly above 2/3 instead of being only a little bit above that threshold. See [here](https://github.com/ethereum/eth2.0-specs/issues/2098) for further discussion (though note that the proposal there is slightly different). Key PRs: * https://github.com/ethereum/eth2.0-specs/pull/2192 * https://github.com/ethereum/eth2.0-specs/pull/2194 ### Adjustment to penalty constants We celebrate the fact that we are somewhat, though not yet completely, out of the woods by weakening the training wheels on validator penalties. We change the constants: * `INACTIVITY_PENALTY_QUOTIENT`: reduced from `2**26` (= 67,108,864) to `3 * 2**24` (= 50,331,648) * `PROPORTIONAL_SLASHING_MULTIPLIER`: increased from `1` to `2` * `MIN_SLASHING_PENALTY_QUOTIENT`: reduced from `2**7` (= 128) to `2**6` (= 64) ## Proposed fork choice changes for (approximately) simultaneous deployment with HF1 ### Fork choice by (block, slot) pair Currently, if there is no block published in the most recent slot, then for the purposes of LMD GHOST attestations during that slot count as supporting the most recent block in the chain that the attester is supporting. For example, in this diagram below, attestations on BLANK count as attestations on A: ![](https://storage.googleapis.com/ethereum-hackmd/upload_e101ffcfd4c2c81ac86d8d0283b8d007.jpg) However, this opens the door to 34% attacks. Suppose that there are `m` validators assigned to each slot, of which a malicious attacker controls `0.34 * m`. The attacker also has the right to publish B for slot `n+1`. The attack proceeds as follows: the attacker DOES NOT publish B, and does not publish any of their attestations. All honest attesters would vote for the claim that they saw A in slot `n` and nothing in slot `n+1`, which currently counts as votes for A. During slot `n+2`, an honest proposer would build a block `C` on top of `A`, and the honest validators would support C. At this point, the malicious proposer reveals B and their attestations for B for _both slots `n+1` and `n+2`_. The bottom fork has `0.68 * m` validators supporting it, but the top fork only has `0.66 * m` support, so the bottom fork wins. This attack is described in more detail in section 3.1 of this paper here: https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf The proposed fix is to change the way fork choice works, so that instead of operating on the tree of blocks, it operates on the tree of (block, slot) pairs. Hence, the honest votes during slot `n+1` would count as votes for `(BLANK, n+1)` in the diagram above, and so they would correctly count as supporting the top fork, and so the top fork's support would be `1.32 * m` and it would defeat the attack. Key PR: * https://github.com/ethereum/eth2.0-specs/pull/2197 ### Fork choice balance attack fix There is a ["balance attack" on the fork choice](https://arxiv.org/pdf/2009.04987.pdf), where an attacker with 2% of validators publishes a small amount of attestations at the right time just before the end of a slot, convincing >49% of the network that some block A is winning and >49% that block B is winning. If they time their broadcast correctly, each group sees the messages aimed at them on time, but does not have time to rebroadcast the messages to the other group before the slot boundary ends. They can then repeat potentially indefinitely, if network circumstances are optimal for the attacker. The proposed fix "breaks the symmetry" by empowering the proposer of the next slot to have a temporary, but significant, impact on the fork choice, decisively shifting all validators' position to one side or the other. Key doc: * https://notes.ethereum.org/@vbuterin/lmd_ghost_mitigation

Import from clipboard

Advanced permission required

Your current role can only read. Ask the system administrator to acquire write and comment permission.

This team is disabled

Sorry, this team is disabled. You can't edit this note.

This note is locked

Sorry, only owner can edit this note.

Reach the limit

Sorry, you've reached the max length this note can be.
Please reduce the content or divide it to more notes, thank you!

Import from Gist

Import from Snippet

or

Export to Snippet

Are you sure?

Do you really want to delete this note?
All users will lost their connection.

Create a note from template

Create a note from template

Oops...
This template is not available.


Upgrade

All
  • All
  • Team
No template found.

Create custom template


Upgrade

Delete template

Do you really want to delete this template?

This page need refresh

You have an incompatible client version.
Refresh to update.
New version available!
See releases notes here
Refresh to enjoy new features.
Your user state has changed.
Refresh to load new user state.

Sign in

Sign in via SAML

or

Sign in via GitHub

Help

  • English
  • 中文
  • Français
  • Deutsch
  • 日本語
  • Español
  • Català
  • Ελληνικά
  • Português
  • italiano
  • Türkçe
  • Русский
  • Nederlands
  • hrvatski jezik
  • język polski
  • Українська
  • हिन्दी
  • svenska
  • Esperanto
  • dansk

Documents

Tutorials

Book Mode Tutorial

Slide Mode Tutorial

YAML Metadata

Resources

Releases

Blog

Policy

Terms

Privacy

Cheatsheet

Syntax Example Reference
# Header Header 基本排版
- Unordered List
  • Unordered List
1. Ordered List
  1. Ordered List
- [ ] Todo List
  • Todo List
> Blockquote
Blockquote
**Bold font** Bold font
*Italics font* Italics font
~~Strikethrough~~ Strikethrough
19^th^ 19th
H~2~O H2O
++Inserted text++ Inserted text
==Marked text== Marked text
[link text](https:// "title") Link
![image alt](https:// "title") Image
`Code` Code 在筆記中貼入程式碼
```javascript
var i = 0;
```
var i = 0;
:smile: :smile: Emoji list
{%youtube youtube_id %} Externals
$L^aT_eX$ LaTeX
:::info
This is a alert area.
:::

This is a alert area.

Versions

Versions and GitHub Sync

Sign in to link this note to GitHub Learn more
This note is not linked with GitHub Learn more
 
Add badge Pull Push GitHub Link Settings
Upgrade now

Version named by    

More Less
  • Edit
  • Delete

Note content is identical to the latest version.
Compare with
    Choose a version
    No search result
    Version not found

Feedback

Submission failed, please try again

Thanks for your support.

On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

Please give us some advice and help us improve HackMD.

 

Thanks for your feedback

Remove version name

Do you want to remove this version name and description?

Transfer ownership

Transfer to
    Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

      Link with GitHub

      Please authorize HackMD on GitHub

      Please sign in to GitHub and install the HackMD app on your GitHub repo. Learn more

       Sign in to GitHub

      HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.

      Push the note to GitHub Push to GitHub Pull a file from GitHub

        Authorize again
       

      Choose which file to push to

      Select repo
      Refresh Authorize more repos
      Select branch
      Select file
      Select branch
      Choose version(s) to push
      • Save a new version and push
      • Choose from existing versions
      Available push count

      Upgrade

      Pull from GitHub

       
      File from GitHub
      File from HackMD

      GitHub Link Settings

      File linked

      Linked by
      File path
      Last synced branch
      Available push count

      Upgrade

      Danger Zone

      Unlink
      You will no longer receive notification when GitHub file changes after unlink.

      Syncing

      Push failed

      Push successfully