# Committee-based single slot finality --- <img src="https://vitalik.ca/images/cbc-casper-files/Chain13.png" style="border:0px; width:600px" /><br><br> <div style="font-size:90%"> * **Idea**: proposed alternative long-term design for the beacon chain * **Timing**: after the merge, after sharding, after stateless clients * **Goal**: fix problems in status quo hybrid fork choice / finality mechanism by going straight to finality </div> --- #### Goal 1: make single-slot reorgs even harder | | | | - | - | | Nakamoto |  | | Gasper |  | | Tendermint |  | --- #### Goal 2: reduce harms from known flaws in LMD GHOST + FFG combination <img src="https://storage.googleapis.com/ethereum-hackmd/upload_e101ffcfd4c2c81ac86d8d0283b8d007.jpg" style="width:400px" /> --- #### Goal 3: fixed low beacon chain load, regardless of validator count  Reduced load -> lower min deposit sizes! --- #### Goal 4: preserve important properties of status quo * High level of economic finality * Continued function and ability to recover from >1/3 offline cases --- ## So how does the new idea work? --- * Consensus is done by **committees** (think: 8,192 randomly selected validators) * At any point, a particular committee is responsible for finalizing the next block. That committee does not change until either: * A block gets finalized, or * It gets inactivity-leaked away ---  --- Two options for consensus algorithm: <br> * Copy tendermint near-exactly (but with fork choice rule for the non-finalizing case) * Casper FFG but with single-slot epochs (and 1/4 validator set change per finalization) --- ## Why is this safe? * For two conflicting blocks to get finalized, need either 1/3 slashed on both sides or an equally large inactivity leak on the more recent side * Possibility of inactivity leak allows recovery from offline committees * Community UASF allows recovery from censoring committees --- ### Extension: multi-confirmations <br> * **Idea**: the _dynasty N_ committee is chosen based on data known in _dynasty N-50_ * **Goal**: to revert 50 confirmations, need to slash 1/3 on 50 consecutive committees that are guaranteed to be the same on both sides --- ## How does this affect cost of attack? --- <small> | `COMMITTEE_SIZE` (compare current mainnet: ~6,300) | `COMMITTEE_LOOKAHEAD` (= slots until max finality) | `DEPOSIT_SIZE` (in ETH) | ETH needed to break single confirmation | ETH needed to break finality | | - | - | - | - | - | | 4,096 | 128 | 32 | 43,690 | 5,592,405 | | 8,192 | 512 | 4 | 10,922 | 5,592,405 | | 16,384 | 1,024 | 1 | 5,461 | 5,592,405 | | 16,384 | 64 | 32 | 174,762 | 11,184,810 | | 8,192 | 512 | 1 | 2,730 | 1,398,101 | </small> --- ## How to read that table? <br> * If an attacker is willing to burn "ETH needed to break single confirmation", they can: * Revert a single finalized slot * Prevent finality for ~2 weeks * Censor until UASF stops attacker --- ## How to read that table? <br> * If an attacker is willing to burn "ETH needed to break finality", they can: * Confuse users about which blocks are finalized going arbitrarily far (depends on user latency) --- ## How to read that table? <br> Note : all attacks require attacker to control close to 50% of total validator set! <br> * **Budget** is still very high (millions of ETH) * **Cost** is lower (tens or hundreds of thousands of ETH for some attacks) --- ### Claim: this not worse than existing low-cost low-grade attacks <br> * Extreme / hostile MEV extraction * Griefing * Mild censorship These attacks are _already_ low cost and non-uniquely-attributable. --- ## Benefits for validators <br> * Constant node running load (instead of variable) * Can potentially enable very quick withdrawals in some cases * Simpler codebase = less software risk for you --- ### How to get there? <br> * For now, mostly wait. Merge and sharding are more pressing challenges. * Ongoing thinking and review on this path; does it really make sense, how does it compare to CBC (the status quo long-term roadmap), etc. * Eventually a more detailed spec and test implementation!