HackMD
  • Prime
    Prime  Full-text search on all paid plans
    Search anywhere and reach everything in a Workspace with Prime plan.
    Got it
      • Create new note
      • Create a note from template
    • Prime  Full-text search on all paid plans
      Prime  Full-text search on all paid plans
      Search anywhere and reach everything in a Workspace with Prime plan.
      Got it
      • 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
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Write
        • Only me
        • Signed-in users
        • Everyone
        Only me 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
      • 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
    Menu Sharing Create Help
    Create Create new note Create a note from template
    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
    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
    Only me
    • Only me
    • Signed-in users
    • Everyone
    Only me Signed-in users Everyone
    Write
    Only me
    • Only me
    • Signed-in users
    • Everyone
    Only me 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
    # Detecting slashing conditions An efficient and optimized slashing condition detector is an [open engineering challenge](https://github.com/ethereum/eth2.0-pm/issues/63). This describes one engineering effort with some new ideas. A compilation of various thoughts around this topic is also discussed. This is an open engineering challenge, and if you have ideas, please share at https://github.com/ethereum/eth2.0-pm/issues/63 ## Background reading - Casper FFG paper https://arxiv.org/pdf/1710.09437.pdf - Weak subjectivity evaluation https://ethresear.ch/t/weak-subjectivity-under-the-exit-queue-model/5187 - Sharding attestation policing https://github.com/ethereum/eth2.0-pm/issues/63 - eth2-surround by Diederik (**@protolambda**) https://github.com/protolambda/eth2-surround#min-max-surround ## Problem Description ### Prerequisites Casper FFG paper mandates two slashing conditions which provides _accountable safety_: - **Double vote** -- two conflicting votes for the same _target_ checkpoint (votes with different _source_) - **Surround vote** -- a vote with _source_ and _target_ surrounding or surrounded by previously made vote In order to prevent a scenario with finalizing two conflicting checkpoints (checkpoints having same _target_), the system needs to punish validators for their malicious behaviour. Validators can be punished if they are caught within a _weak subjectivity_ period. The weak subjectivity period is a bit tricky. It could be simplified. Assuming _2/3_ of validator registry are malicious, they could retroactively finalize a checkpoint after they had all withdrawn their stake. Thus, the number of epochs allowing _2/3_ of validators to withdraw, is used as the size of the weak subjectivity period. ### Solution Naive solution for slashing detection has _O(N) = O(E*C)_ storage and algorithmic complexity, where: - _N_ -- number of distinct attestation messages in a week subjectivity period - _E_ -- number of epochs in the weak subjectivity period - _C_ -- number of committees per epoch The whistleblower's attestation slashing message must include the original attestations that are slashable. So you must keep a history of attestations. This requires storing gigabytes of data that can't fit in the memory of a regular computer. This means storage complexity can't be reduced and stays at _O(N)_. A reasonable solution here would be to use cheap storage (disk) to cover this amount of data. However, this limits the speed of queries over attestation data, by the speed of disk accesses. We're looking for an algorithm that can be broken down into two tracks: - _Fast_ -- memory based filter over the epochs with _O(E)_ complexity - _Slow_ -- disk based lookup over committees of epochs found by fast track, should have _O(C )_ complexity The fast track could probably be improved by the cost of a few gigabytes stored in memory which could significantly reduce its complexity e.g. to _O(1)_ or near that margin. In that case we would have _O(C )_ scan over slow disk storage which could run in a background. Bear in mind update complexity as well. Index of a fast track should have relatively small complexity of updates to handle _A_ attestation messages per slot. ### Numbers A good margin for slashing condition detection is: - _E = 54,000_ -- epochs in a weak subjectivity period - _V = 300,000_ -- active validators - _C = 2,048_ -- Phase 1 spec with shards and _V = 300,000_ - _N = 110,970,000_ -- distinct attestation messages in the best case, which is _~84G_ worth of data; bear in mind amplification factor caused by forks, thus, size of data could be 2X larger - _A = ~10_000_ -- attestation messages per slot ## Design Overview ![](https://i.imgur.com/eidLNBt.png) - **On attestation** - check for double vote - map vote on a node in the index - check if there is an intersection between validator indices of the attestation and indices from validator bitfield - get hashes for all distances of the node if intersection exists - within retrieved hashes run a disk lookup to find proper `IndexedAttestation` and fire a slashing message - check for surrounding vote - scan index starting from _source + 1_ til _target - 1_ to look for votes _surrounded by_ received attestation - scan index starting from _target + 1_ til _current_epoch_ to look for votes _surrounding_ received attestation - for each node being scanned use validator bitfield to filter out validators that has no votes for a target of this particular node - find distances satisfying to surrounded or surrounding conditions - get hashes for matched distances - run a disk lookup with these hashes to find proper `IndexedAttestation` and fire a slashing message - update index - convert _(source, target)_ into _(target_idx, d)_ - if _d_ is unique for the node add it to the list of distances - update attestation data hashes with a new hash - update validators bitfield with new indices - update disk storage; it is required only if hash does not exist in the list and there are new validator indices wrt validator bitfield - **On new epoch** - update _current_epoch_ - set _current_epoch_idx = (current_epoch_idx + 1) % N_ - clear node corresponding to updated _current_epoch_idx_ - erase outdated _IndexedAttestation_ objects from disk ## Parameters Beacon chain spec version [v0.9.1](https://github.com/ethereum/eth2.0-specs/blob/v0.9.1/specs/core/0_beacon-chain.md) |Parameter |Value | |----------|---------| |shards | 64 | |slots | 32 | |validators| 300,000 | |epochs | 54,000 | All calculations are done for Phase 1. In most cases Phase 0 sizes should be less by a factor of _64_ which is the expected number of "crosslinks". ## Surrounding votes ### Problem Upon receiving an attestation we want to know whether its FFG vote surrounds or is surrounded by the vote of other attestations that were received previously. If _surrounding_ is found we want to get _IndexedAttestation_ objects of both conflicting attestations and fire a slashing condition. A period of time during which it makes sense to check attestation for slashing condition is called _weak subjectivity period_. According to Casper FFG paper this period equals to a number of epochs during which 2/3 validators from current validator dynasty are able to withdraw. It is _54K_ epochs in the worst case. It means that we have to do fast lookups accross _~110M_ aggregated attestations in the best case (for _300K_ validators in Phase 1). In bytes it would be _~84G_ of (uncompressed) data. ### Votes Cache An alternative to the index suggested by **@protolambda** (https://github.com/protolambda/eth2-surround#min-max-surround) which is _O(1)_ on lookup and _O(N)_ on update. New approach has _O(1)_ update time and _O(N)_ search time, where _N_ is a number of epochs. Due to relatively low _MAX_N=54K_ scan time of entier index is negligible (~0.01 millis on core i7 laptop, [details](#Benchmark)). Hence, these two approaches are pretty similar in terms of performance. Votes cache is a tiny structure in terms of memory (_~0.1Mb_ in best case) which is used for basic lookups in order to get votes surrounding or surrounded by received attestation. According to a figure in [Design Overview](#Design-Overview) a cache is represented as circular linked list consisting of _N_ nodes. Where _N_ is a number of epochs in the weak subjectivity period. A node stores a list of 2-byte numbers. Each number is a distance between _source_ and _target_ epochs of the vote. #### Update index with new vote To add a new vote _(s, t)_ to a votes cache, first, we need to calculate a node index in a circular linked list and then add `d = t - s` to the list of distances stored in the node. Calculating node's index: ```python idx = (current_epoch_idx - (current_epoch - t)) % N ``` Complexity of update is _O(1)_. #### Scanning for surrounding votes To get votes _surrounded by_ received attestation _(s, t)_ you need to scan cache nodes starting from `start_idx = (current_epoch_idx - (current_epoch - s) + 1) % N` til `end_idx = (current_epoch_idx - (current_epoch - t) - 1) % N`. In _surrounding_ case you need a scan starting from `start_idx = (current_epoch_idx - (current_epoch - t) + 1) % N` til `end_idx = current_epoch_idx`. Cost of this scanning is _O(N)_ where _N_ a number of epochs in weak subjectivity period. #### Size evaluation The size of this cache depends on a number of distinct votes made to same _target_. In the best there is one distinct vote per epoch, it happens when all attestations look like _(source, source + 1)_. In this best case cache size would be _106Kb_. If say there are _10_ distinct votes per epoch then size grows up to _1Mb_. In a normal case a number of distinct votes should be close to _1_. Therefore, we may round the size up to _1Mb_ for simplicity. #### Benchmark Full scan of cache with _10_ distances in each node takes _~0.01_ millis on core i7 which is negligible and disregards its linear complexity. #### Optimization A list of distances could be sorted to utilize binary search for even faster scans. But it doesn't seem a valuable improvement. ### Indexed attestations Accessing _IndexedAttestation_ objects requires a couple of structures more. First structure binds distinct votes with a list of attestation data hashes that are referred to this vote. Size of this structure is relatively small and it could be placed in memory. Second structure is a map of attestation data hash to the list of _IndexedAttestation_ carrying attestation data with corresponding hash. This structure is potentially big and should be stored on disk. #### Size evaluation A number of distinct _AttestationData_ per epoch depends on a number of slots, shards, beacon chain forks and distinct FFG votes. In the best case (one fork, one distinct vote) a number of distinct _AttestationData_ per epoch is _64 * 32 = 2048_. Having two forks and two distinct votes increases this number by a factor of _4_. Let's denote this factor with _I_ (instability). Taking in account two degrees of freedom (forks and distinct votes) _I=4_ is considered as a sane evaluation for instability factor. For _54K_ epochs we have _3Gb_ and _12Gb_ worth of hashes for _I=1_ and _I=4_ respectively. If memory requirements are high it might make sense to offload hashes to disk for old epochs. For example, for the first bunch of _1024_ epochs with _I=4_ it would take only _256Mb_. Size evaluation of disk part of _IndexedAttestation_ cache is a bit more tricky. To make it less complex let's assume that there is no aggregation overlaps and each distinct attestation data always corresponds to one _IndexedAttestation_ object. With a new proposal for Phase 1 size of signed _AttestationData_ should be _230b_. With _I=4_ we get _230 * 64 * 32 * 4 = 1.8Mb_ signed attestation data per epoch plus _300000 * 4 = 2.3Mb_ occupied by validator indices. And finally we get _155Gb_ for entire weak subjectivity period. ## Landing double votes detection As mentioned in [eth2.0-pm#63](https://github.com/ethereum/eth2.0-pm/issues/63) it's enough to maintain a bitfield with bits corresponding to epochs of weak subjectivity period for each validator to detect double votes. This approach requires an update of each validator's bitfield since current epoch changes. To avoid this complexity we may revert validator <-> epoch relation and store a bitfield of validators voted for particular epoch. It's worth noting that bitfield index aids surrounding votes check as well by a second round of in-memory filtering with validator indices voted for a particular _target_. Size of this index linearly dependends on a number of validators and equals _300000 / 8 * 54000 ~ 2Gb_ for _300K_. ### Compressing bitfields It might make sense to compress those bitfields to reduce their effective storage size. Compression with Snappy: |inactive validators per epoch|compression ratio|compressed size| |-|-|-| |1/16|1.55|1.3Gb| |1/8|1.11|1.8Gb| |1/4|1|2Gb| **Note:** compression of original bitfield index with epoch bitfields per each validator might be more efficient since they have lower entropy. ## Credits - Danny Ryan (**@djrtwo**) for initial efforts in https://github.com/ethereum/eth2.0-pm/issues/63 - Diederik Loerakker (**@protolambda**) for this great work https://github.com/protolambda/eth2-surround#min-max-surround - Alex Vlasov (**@ericsson49**) for discussions around this topic

    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

    Forgot password

    or

    By clicking below, you agree to our terms of service.

    Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox

    New to HackMD? Sign up

    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

    Contacts

    Facebook

    Twitter

    Feedback

    Send us email

    Resources

    Releases

    Pricing

    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