Low-cost attacks on Ethereum 2.0 by sub-1/3 stakeholders
Michael Neuder, Daniel J. Moroz, Rithvik Rao, David C. Parkes
LLow-cost attacks on Ethereum 2.0 bysub-1/3 stakeholders
Michael Neuder †‡ Daniel J. Moroz § Rithvik Rao ¶ David C. Parkes (cid:107)
School of Engineering and Applied SciencesHarvard University
Abstract
We outline two dishonest strategies that can be cheaply executed on the Ethereum 2.0 beaconchain, even by validators holding less than one-third of the total stake: malicious chain reorgani-zations (“reorgs”) and finality delays. In a malicious reorg, an attacker withholds their blocks andattestations before releasing them at an opportune time in order to force a chain reorganization,which they can take advantage of by double-spending or front-running transactions. To executea finality delay an attacker uses delayed block releases and withholding of attestations to increasethe mean and variance of the time it takes blocks to become finalized. This impacts the efficiencyand predictability of the system. We provide a probabilistic and cost analysis for each of theseattacks, considering a validator with 30% of the total stake.
Ethereum 2.0 represents the most substantial modification to the Ethereum protocol since its initialrelease. The first step of Ethereum 2.0, dubbed
Phase 0 , is the creation of the beacon chain , which willrun in parallel to the original Ethereum chain. The beacon chain fully implements a Proof-of-Stakeconsensus protocol, which is presented by Buterin et al. [2020] and defined in the Ethereum 2.0 Spec[2020]. The Proof-of-Stake protocol is a combination of Casper FFG “friendly finality gadget” fromButerin and Griffith [2017] and a modified version of the GHOST fork-choice rule of Sompolinsky andZohar [2015].The security of the beacon chain relies on no attacking party controlling more than / of the totalstake, where the / security threshold comes from Byzantine fault tolerance guarantees [Castro et al.,1999]. Further, the beacon chain is designed to penalize provably dishonest behavior (e.g., proposingtwo conflicting blocks at the same block height) through the use of “slashing conditions” (rules that leadto a loss of staked currency) [Buterin et al., 2020]. In this paper we nevertheless outline two dishoneststrategies that can be used by an adversary with 30% of the total stake. Neither strategy involvescryptographically signing conflicting pieces of information, and thus neither is punishable throughslashing conditions. The attacks are relatively cheap to execute. While the market capitalization ofEthereum is over 55 billion USD as of November 2020, the finality delay attack would cost on theorder of 500 USD and the chain reorganization attack would cost on the order of 5 USD.We first examine small-scale malicious chain reorganizations (“reorgs”). Reorgs are caused by afork-choice rule deeming a new branch to be dominant over an existing branch, effectively deletingblocks from the canonical chain (the fork which honest participants identify as the head based on afork-choice rule). Reorgs can occur naturally due to network latency. In Proof-of-Work, for example,if two miners create blocks A and B at nearly the same time, the network partitions, with some honestnodes mining on each block. If A (cid:48) is a subsequent block that is mined as a child of A before any blocksare mined as a child of B then the honest network will see A (cid:48) as the head of the chain. Block B willbe orphaned, and no longer considered part of the main chain. For an honest miner who previously † First published in the Game Theory in Blockchain (GTiB) workshop at the 2020 Conference on Web and InternetEconomics (WINE). ‡ [email protected] § [email protected] ¶ [email protected] (cid:107) [email protected] a r X i v : . [ c s . CR ] F e b aw B as the head of the chain, switching to A (cid:48) has the effect of deleting block B from the canonicalchain. Malicious reorgs are artificial reorgs that are caused by an attacker who seeks to exploit them byattempting to double-spend or front-run large transactions. A double-spend transaction is one wherecoins are sent to a counter-party in return for something of value, with the chain subsequentely reorgedto delete the original transaction. Minimizing the feasibility of double-spending is critical to the secu-rity of cryptoeconomic systems, and the original Bitcoin white paper presents a probabilistic analysisof the feasibility of malicious reorgs [Nakamoto, 2008]. A desirable property is that the probability ofa malicious reorg decreases as the length of the reorg grows. This provides that transactions includedin blocks that have many blocks built on top of them will remain on the chain with high probability.This also comes with a trade off, namely long wait times for transactions to be deemed valid, limitingthe utility of the economic system.Malicious reorgs also enable front-running [Daian et al., 2019], which is the process of using infor-mation about large transactions to create short-term arbitrage opportunities. Typically, front-runningin Ethereum happens in decentralized exchanges (DEXs). Attackers pay high gas fees to ensure theirtransactions are included first in a new block, in this way ensuring they come before large transactionsthat they want to front-run. Malicious reorgs can be used to gain fine-grained control on the orderof transactions. For example, consider an attacker who knows they can reorg an upcoming block, B ,with a block of their own, A . If a large buy order from another party to an exchange, t (cid:96) , is made andincluded in B , the attacker knows that the price on the exchange will increase, and thus A can usefullyinclude a transaction buying from that exchange, t b , followed by this large transaction t (cid:96) , followed by atransaction selling to that exchange, t s . If the attacker were playing honestly, they would have alreadyreleased block A by the time t (cid:96) is heard over the network.In addition to malicious reorgs, we demonstrate a strategy in which an attacker can delay the finality of the beacon chain. Finality is a property of blocks, and Buterin and Griffith [2017] showthat once a block is finalized, the block and the transactions it contains will only be removed from thecanonical chain if the network is “ / -slashable” (i.e., if validators controlling / of the total stake areprovably dishonest). In a healthy network, a block will become finalized within two epochs, where anepoch is a sequence of block creation opportunities with total duration of around 6.4 minutes (definedmore formally in Section 2.1). We demonstrate that an attacker with a 30% stake can delay finalitywith high frequency; e.g., delaying finality by three epochs on average every hour (a delay of around19 minutes). This is a denial-of-service (DoS) attack on any transaction that needs to be finalized, anddoing this with some regularity could severely damage the health and predictability of the network.Since this paper appeared in the Game Theory in Blockchain workshop of the 2020 Conferenceon Web and Internet Economics (WINE), the Ethereum Foundation has proposed a change to thefork-choice rule to be included as part of the first hard fork on the beacon chain, HF1 [Buterin, 2021],citing the reorg attack presented in this paper as motivating the change. The analysis in this paper is related to the Proof-of-Work selfish mining literature initiated by Eyaland Sirer [2018], and further expanded in Nayak et al. [2016], Kwon et al. [2017], Sapirshtein et al.[2016]. Selfish mining and double-spending were extended to Proof-of-Stake (PoS) by Brown-Cohenet al. [2019], who demonstrated that longest-chain PoS protocols with certain properties are vulnerableto reorgs. Neuder et al. [2019, 2020] demonstrate instantiations of these reorg attacks in the Tezosprotocol.A number of attacks on the Ethereum 2.0 beacon chain have also been presented. Neu et al.[2020] describe an attack in which the attacker exploits the expected time of release of attestations topartition the honest network, which is a different method of executing the finality delay than the onepresented here. Nakamura [2019a] presents an attack called the “decoy-flip-flop” where an attackeraccumulates and releases conflicting attestations to ensure that epochs do not become finalized. Thisdiffers from our finality delay attack in that the attacker that we describe does not accumulate oldepoch attestations or sign conflicting attestations. Pull Request 1466 [2019] seeks to mitigate the“decoy-flip-flop” by checking that an attestation’s target epoch is the current or previous epoch, thus2imiting the ability of the attacker to stockpile old attestations. Neither of our attacks rely on sendingattestations from old epochs and they are not resolved by this fix. Nakamura [2019b] presents a“bouncing attack” where an attacker uses the fact that the fork-choice rule only operates on blockssince the last justified epoch (see Section 2.2 for definition of justification) to take advantage of networklatency issues. Pull Request 1465 [2019] aims to prevent this attack by ensuring that the last justifiedepoch does not change after the first two slots of an epoch. Neither of the attacks we present rely onchanging the view of the last justified epoch, so this fix has no effect on them.
The Ethereum 2.0 consensus mechanism is best understood in two parts: the fork-choice rule (HLMD-GHOST ) and the finality gadget (Casper FFG ), as described by Buterin et al. [2020]. Thefork-choice rule defines which blocks are considered to be on the canonical chain, while the finalitygadget defines which of the produced blocks are justified or finalized (defined in Section 2.2). In the Ethereum 2.0 Spec [2020], time is partitioned into epochs , which are further subdivided into32 slots of 12 seconds each. Each slot will contain a committee with at least 128 validators. The first(randomly selected) validator in each committee takes the role of the proposer for that slot, and cancreate a block. Epoch boundary blocks (EBBs) are checkpoint blocks that represent the start of anepoch based on the current set of blocks that a validator has observed. Definition 1.
A validator determines the epoch boundary block (EBB) for epoch i as follows:1. Choose the block at the first slot in epoch i if it is present in the validator’s canonical chain2. Else, choose the highest slot block on the canonical chain from epoch i (cid:48) such that i (cid:48) < i . During each slot, all validators in the committee can issue a single attestation . Definition 2.
An attestation is the casting of a vote that contains: A − a source EBB A − a target EBB A − the head of the chain according to HLMD-GHOSTLet ( A = β, A = γ, A = δ ) denote an attestation for blocks β, γ , and δ . The A and A components of attestations are defined as the source and target EBBs of the CasperFFG vote. For example, attestation ( A = 0 , A = 32) can be interpreted as “I want to move thefinality gadget from the block at slot 0 to the block at slot 32”. We discuss how these votes contributeto the finalization process in Section 2.2. For simplicity, we will sometimes elide part of an attestationwhen it is not relevant to the analysis; e.g., writing an attestation as ( A = δ ) when the values of A and A are unimportant. Definition 3.
Let the weight of a given block, B, be the sum of the stake owned by validators whoattest (with A ) to B or any descendants of B. Definition 4.
Based on the most recent set of attestations, one per validator, LMD-GHOST dictatesthat the head of the chain can be reached by starting at the genesis block and choosing the higherweight branch at each fork until hitting a leaf block (a block with no children). The hybrid version of Definition 4 from Buterin et al. [2020] also adds that the start of the LMD-GHOST weight calculation is the last justified EBB (defined in Section 2.2) rather than the genesisblock, which improves the computational efficiency of the system. Our attacks are not impacted bythis distinction because they do not rely on any attestations from before the current epoch.For the remainder of this work, we assume that each validator has equal stake, which we normalizeto 1 without loss of generality. This allows us to count attestations instead of summing the weight Hybrid Latest Message Driven Greedy Heaviest Observed SubTree Friendly Finality Gadget These are defined as epoch-block pairs in Buterin et al. [2020] because they account for the possibility that an EBBmay be used for multiple epochs, but for the scope of this work, just using EBBs is sufficient. Latest Message Driven Greedy Heaviest Observed SubTree ( A = 0 , A = 32) justifies block 32. Since the EBB of epoch 2 was not produced asexpected (there is no block 64), block 63 is “borrowed” from the previous epoch to fill in as the EBBfor epoch 2. The supermajority link with ( A = 32 , A = 63) finalizes block 32 and justifies block 63.over each attesting validator. Figure 1 demonstrates the use of HLMD-GHOST to pick the head of thecanonical chain. Based on the results of HLMD-GHOST, an honest validator can choose which blockwill receive their A vote. In an network with full participation, with honest validators, and with nonetwork delays, the proposer releases a block at the start of the slot and each validator in that slot’scommittee votes for this block as the head of the chain. Finality is achieved through the use of the source and target EBBs (the A and A components ofattestations from Definition 2). Definition 5.
There is a supermajority link between EBBs β and γ if validators controlling / ofthe total stake release attestations with ( A = β, A = γ ) . Definition 6.
The genesis (first) block is defined to be justified. An EBB, γ , is justified if there is asupermajority link between a previously justified EBB, β , and γ . Definition 7.
A justified EBB, β , is finalized if there is a supermajority link between β and γ , and γ is the justified EBB of the next epoch. In other words, EBBs become justified by being the target of a supermajority link, and becomefinalized by being the source of a supermajority link from the previous epoch. For example, considerthe first three epochs pictured in Figure 2. The genesis block at slot 0 is justified by definition. Over thecourse of epoch 1, validators controlling / of the total stake issue attestations with ( A = 0 , A = 32) ,which creates a supermajority link and justifies . Subsequently in epoch 2, a supermajority link isestablished with ( A = 32 , A = 63) , which finalizes block 32 and justifies block 63. Block 63 is usedas the EBB of epoch 2 because the expected EBB, block , was not created (Definition 1). This is Case 4 of the “Four-Case Finalization Rule” in Section 8.5 of Buterin et al. [2020]. Though the other 3 casesare implemented in the spec, they do not impact our analysis and are omitted for brevity. n + 1 block using both its slot n + 1 and n + 2 attestations. Thus, a minorityattacker’s attestations on block n + 1 can outnumber the honest attestations on block n + 2 . Beforeblock n + 1 is released by the attacker, the n + 2 block is the head of canonical chain based on HLMD-GHOST. After block n + 1 is released, the honest nodes see that the weight of block n + 1 is 3 (thenumber of grey circles) and the weight of the block n + 2 is 2 (the number of blue circles). As a result,HLMD-GHOST denotes n + 1 as the head of the chain because it is the heaviest leaf block that is achild of block n , and block n + 2 becomes an orphan.Once an EBB is finalized, all the blocks in the corresponding epoch and any prior epochs are alsofinalized. Buterin and Griffith [2017] demonstrate that these blocks will remain on the canonical chainpermanently unless validators controlling at least / of the total stake are provably dishonest. In this section we present a dishonest strategy in which the attacker can force malicious reorgs byprivately creating blocks and releasing their private fork at an opportune time. We analyze the casewhere the attack takes place within a single epoch.
Definition 8.
In a length- n malicious reorg, n consecutive blocks that are part of the canonical chainare orphaned as a result of a reorganization that is caused by an attacker. Note that all attestations in this section refer to A , or the fork-choice component of the attestation. Consider Figure 3, in which the attacker (illustrated with the grey attestations and purple blocks)is the block proposer for the n + 1 st slot. The attacker executes a length- malicious reorg to orphanthe n + 2 nd slot block in the following manner:1. The attacker privately creates block n + 1 and uses its slot n + 1 attestations to privately attestthat block n + 1 is the head of the chain, that is ( A = n + 1) . As the honest attesters in the n + 1 st committee will not see the private block, they instead attest with ( A = n ) .2. At slot n + 2 , an honest validator will propose a block whose parent is the slot n block becauseit has not observed block n + 1 . The honest slot n + 2 committee members attest ( A = n + 2) .The attacker uses its slot n + 2 attestations to privately attest ( A = n + 1) .3. The attacker then releases block n + 1 and the private attestations. Since both blocks n + 1 and n + 2 are leaf blocks with a common parent, they are conflicting and HLMD-GHOST mustchoose one. Block n + 1 has attacker attestations from both slots n + 1 and n + 2 , while block n + 2 has attestations from honest validators from slot n + 2 only (since honest n + 1 attestationswere given to the common parent block n ). In this example, block n + 1 has a higher weight than n + 2 (3 versus 2 respectively), and thus is seen as the head of the chain by HLMD-GHOST.This causes the n + 2 block to be orphaned.This attack is possible because during the private fork, the honest attestations of slot n + 1 willvote for the block at slot n , which is an ancestor of block n + 1 and thus isn’t a competing fork. Figure3 demonstrates a relatively minor reorg, in which only a single honest block is deleted from the chain,but this pattern can be extended to execute longer attacks. See Appendix A for calculations in regardto the frequency and cost of this malicious reorg attack.5igure 4: The probability and cost of a malicious reorg as a function of the reorg length for a 30%-stakeattacker. These approximations are from a Monte Carlo simulation of epochs. The cost is shownin Gwei ( Gwei = Eth) as well as USD.Figure 5: An attacker who makes use of a delayed release of the slot 32 and slot 33 blocks to preventepoch 1 from being justified. The 5 honest attestations (green circles) over the course of slot 32 and33 will identify block 31 as the EBB of epoch 1. Once the attacker releases blocks 32 and 33, thehonest validators will recognize block 32 as the EBB, but with the attacker withholding their remainingattestations a supermajority link with ( A = 0 , A = 32) is not formed and epoch 1 is never justified.The left-hand plot of Figure 4 shows numerical approximations to the probability that a maliciousreorg is feasible for a 30% stake attacker as a function of the reorg length n , based on a Monte Carlosimulation of randomly generated epochs. While long reorgs are uncommon, it is possible for a30% attacker to frequently execute short reorgs. As an example, a length- reorg can be executed bya 30% attacker once an hour for a total cost of 2 USD per reorg. From the right-hand plot of Figure 4,we see that the attacks are cheap; a length n reorg costs the attacker approximately n − USD.
In this section we present a dishonest strategy in which an attacker seeks to delay the finality offuture epochs by delaying the release of EBBs.
Definition 9.
In a length- n finality delay, an attacker ensures that none of the next n epochs arefinalized on time. This attack ensures that over the next n epochs, no new transactions are finalized. This does notmean that these transactions will never be finalized. Since an epoch being finalized also finalizes anyblocks in previous epochs, once the attack ends, a future epoch becomes finalized (likely the secondafter the attack ends) and all the transactions sent during the attack will be as well. This is why werefer to the attack as a finality delay rather than a permanent liveness attack on Casper FFG.Note that attestations in this section may refer to A , A (Casper FFG vote), or A (HLMD-GHOST vote), and thus we will specify this as necessary. An attacker can delay finality by being the proposer of the EBB and the subsequent block (i.e.,block 32, the EBB of epoch 1, and block 33 in Figure 5), and creating a private fork until there isenough attestations from other validators that a prior epoch block is the target EBB (Definition 1). InFigure 5, the other validators make attestations with ( A = 0 , A = 31) where block 31 is the targetEBB. When the private fork is revealed by the attacker, block 32 is recognized as the start of epoch 16igure 6: The probability with which a 30% attacker can delay finality for n epochs, and the associatedcost. Hourly, daily, and yearly rates are delineated by horizontal lines. See Appendix B.2 for thecalculation of the cost.but because Casper FFG votes for block 31 have been incorrectly cast and the attacker withheld theirown attestations, block 32 cannot gain sufficient attestations. No supermajority link between either and or and is formed, and epoch 1 is not justified.In the context of Figure 5, this attack unfolds as follows:1. Consider an attacker who is the proposer for block 32 (the EBB of epoch 1) as well as for block33. After block 31 is published, the attacker creates block 32, a single attestation ( A = 0 , A =32 , A = 32) , and block 33. These are all kept private until step 3.2. Since the honest validators do not see the EBB (block 32), they attest with ( A = 0 , A =31 , A = 31) that the last published block, 31, is the highest slot block of the previous epoch,and thus the new EBB (by Definition 1). In order to succeed in the attack, a 30% attacker waitsuntil 139 (about 3.3% of the total number of attestations in the epoch) honest attestations arepublished that identify 31 as the FFG target block (see Appendix B).3. The attacker releases the private fork, which is identified as the head by HLMD-GHOST because31 is the predecessor of block 32 and therefore the honest attestations for ( A = 31) do notconflict with the attacker’s attestation to ( A = 32) . The effect is that the honest attestationsare wasted on the wrong EBB for epoch 1. Since 33 is the only leaf block, it is seen as the headof the chain.4. The attacker withholds the rest of their attestations in epoch 1 that would otherwise indicatethat 32 is the correct EBB. No supermajority link with ( A = 0 , A = 32) or ( A = 0 , A = 31) is created, and epoch 1 is not justified.See Appendix B for calculations of the cost of this attack and an example calculation of how manyattestations a 30% stake attacker needs to “waste” (cause to incorrectly identify the target EBB, A )for the attack to succeed. From Figure 5, the 30% attacker has a (0 . = 0 . probability of ensuring anon-justified epoch. This is the probability that the attacker is the block proposer for the EBB (block32) as well as the subsequent block. Since finality occurs when two consecutive epochs are justified,the attacker can delay finality for as long as they can ensure no two epochs in a row become justified. The probability of a length- n delay in finality is equal to the probability that there are no twoheads in a row in a sequence of n flips of a biased coin with P ( H ) = 0 . and P ( T ) = 0 . . Wecalculate this probability through enumeration. The left-hand plot of Figure 6 shows this probabilityfor different values of n ; a 30% attacker can delay finality with high frequency. The right-hand plot ofFigure 6 gives the cost of the attacks, which ranges from 100 to 1200 USD. We have presented two dishonest strategies that a 30% stake attacker on the Ethereum 2.0 beaconchain can launch with high probability and low cost. Though the focus of this paper is on introducingthese two strategies and studying them for a 30% attacker, it is also worth considering the attackpossibilities for participants with smaller stakes. In both cases, the likelihood of an attack succeeding7ecreases with the available stake of an attacker. For example, we can show that a 25% attacker canexecute a length-2 reorg once per 3 hours and a 2 epoch finality delay once per hour. An interestingavenue for future work is studying how these probabilities change as a function of stake. Further, itwould be useful to quantify how much an attacker could expect to earn by executing a malicious reorgand how much a finality delay attack can impact the average transaction finalization times.
Acknowledgements
The authors would like to thank an anonymous reviewer for useful comments as we prepared thismanuscript for the Game Theory in Blockchain Workshop (GTiB) at the 2020 conference on Web andInternet Economics (WINE 2020). This work is supported in part by two generous gifts to the Centerfor Research on Computation and Society at Harvard University, both to support research on appliedcryptography and society.
References
Vitalik Buterin, Diego Hernandez, Thor Kamphefner, Khiem Pham, Zhi Qiao, Danny Ryan, JuhyeokSin, Ying Wang, and Yan X Zhang. Combining ghost and casper, 2020.Ethereum 2.0 Spec. Ethereum 2.0 phase 0 – the beacon chain, 2020. URL https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md .Vitalik Buterin and Virgil Griffith. Casper the friendly finality gadget. arXiv preprintarXiv:1710.09437 , 2017.Yonatan Sompolinsky and Aviv Zohar. Secure high-rate transaction processing in bitcoin.
Conferenceon Financial Cryptography and Data Security , pages 507–527, 2015.Miguel Castro, Barbara Liskov, et al. Practical byzantine fault tolerance. In
OSDI , volume 99, pages173–186, 1999.Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008. URL https://bitcoin.org/bitcoin.pdf .Philip Daian, Steven Goldfeder, Tyler Kell, Yunqi Li, Xueyuan Zhao, Iddo Bentov, Lorenz Breiden-bach, and Ari Juels. Flash boys 2.0: Frontrunning, transaction reordering, and consensus instabilityin decentralized exchanges. arXiv preprint arXiv:1904.05234 , 2019.Vitalik Buterin. Hf1 proposal, 2021. URL https://notes.ethereum.org/@vbuterin/HF1_proposal .Ittay Eyal and Emin Gün Sirer. Majority is not enough: Bitcoin mining is vulnerable.
Communicationsof the ACM , 61(7):95–102, 2018.Kartik Nayak, Srijan Kumar, Andrew Miller, and Elaine Shi. Stubborn mining: Generalizing selfishmining and combining with an eclipse attack. In , pages 305–320. IEEE, 2016.Yujin Kwon, Dohyun Kim, Yunmok Son, Eugene Vasserman, and Yongdae Kim. Be selfish and avoiddilemmas: Fork after withholding (faw) attacks on bitcoin. In
Proceedings of the 2017 ACM SIGSACConference on Computer and Communications Security , pages 195–209. ACM, 2017.Ayelet Sapirshtein, Yonatan Sompolinsky, and Aviv Zohar. Optimal selfish mining strategies in bitcoin.In
International Conference on Financial Cryptography and Data Security , pages 515–532. Springer,2016.Jonah Brown-Cohen, Arvind Narayanan, Alexandros Psomas, and S Matthew Weinberg. Formalbarriers to longest-chain proof-of-stake protocols. In
Proceedings of the 2019 ACM Conference onEconomics and Computation , pages 459–473. ACM, 2019.8ichael Neuder, Daniel J Moroz, Rithvik Rao, and David C Parkes. Selfish behavior in the tezosproof-of-stake protocol. arXiv preprint arXiv:1912.02954 , 2019.Michael Neuder, Daniel J Moroz, Rithvik Rao, and David C Parkes. Defending against maliciousreorgs in tezos proof-of-stake. In
Proceedings of the 2nd ACM Conference on Advances in FinancialTechnologies , pages 46–58, 2020.Joachim Neu, Ertem Nusret Tas, and David Tse. Ebb-and-flow protocols: A resolution of theavailability-finality dilemma. arXiv preprint arXiv:2009.04987 , 2020.Ryuya Nakamura. Decoy-flip-flop attack on lmd ghost, 2019a. URL https://ethresear.ch/t/decoy-flip-flop-attack-on-lmd-ghost/6001 .Eth 2.0 Spec Pull Request 1466. Bounce attack resistance, 2019. URL https://github.com/ethereum/eth2.0-specs/pull/1466 .Ryuya Nakamura. Analysis of bouncing attack on ffg, 2019b. URL https://ethresear.ch/t/analysis-of-bouncing-attack-on-ffg/6113 .Eth 2.0 Spec Pull Request 1465. Bounce attack resistance, 2019. URL https://github.com/ethereum/eth2.0-specs/pull/1465 . A Calculating Probability and Cost of Malicious Reorgs
A.1 Probability
We consider the probability with which a 30% attacker can execute a length- n reorg within anepoch. Probabilistically, this can be phrased as follows. Consider an urn with ·
32 = 4096 balls , 30% of which are red (the attacker) and theremainder are black. The balls are drawn in groups of without replacement until theurn is empty. What is the probability that there is a sequence of m + n draws of 128, overwhich there are more red balls drawn in total than black balls drawn in the final n draws ofthe sequence, for any m where the first ball in each of the m draws is red. Let m be the length of the attacker fork, where each of the private blocks must be in consecutiveslots, and n be the number of honest blocks that will be orphaned. Intuitively, we care about therelationship between the number of attacker attestations over m + n slots (grey circles in Figure 3)versus the number of honest attestations over the last n of those slots (blue circles in Figure 3), becausethe honest attestations during the attacker fork (seen as green circles in Figure 3) will contribute to theweight of an ancestor to both conflicting forks, and thus won’t impact the leaf block HLMD-GHOSTcount. We approximate this probability with Monte Carlo simulations. A.2 Cost
All constants are shown in this
FONT and are copied from the Ethereum 2.0 Spec [2020]. Validatorsare rewarded for both creating attestations and including attestations in the blocks they create. Noticethat in Figure 3, the attacker is still able to include the honest attestations heard over the privatefork, because they attest to the predecessor block “n”. Thus we only consider the loss in rewards to theattackers attestations. Assume there are · validators who each have the MAX_EFFECTIVE_BALANCE of × Gwei = 32
Eth.
Definition 10.
The base reward (in Gwei), denoted ρ , for each validator is, ρ = BASE_REWARD_FACTORBASE_REWARDS_PER_EPOCH · × (cid:98)√ · · × (cid:99) (1) = 2 · × ≈ . (2)
128 represents the number of validators per committee, and 32 is the number of slots in each epoch. efinition 11. The inclusion reward, denoted ι , as a function of the inclusion delay (differencebetween the slot that the attestation is created for and the slot at which that attestation is included), d , for each attestation is, ι ( d ) = 1 d (cid:18) ρ − ρ PROPOSER_REWARD_QUOTIENT (cid:19) (3) = ρd (cid:18) − (cid:19) = 7 ρ d . (4) Definition 12.
The max value, ν , of a single attestation is, ν = 3 ρ + ι (1) (5) = 318 · ≈ . (6) The attester is rewarded for being included, having the correct source and destination epoch boundaryblocks, and pointing to the correct head of the chain.
When the attacker is following the reorg policy in Section 3, they only miss out on the inclusionreward for their attestations not being included immediately (because they will correctly identifysource and target epoch boundaries as well as the head of the chain). Since the attacker attestationsfor blocks after the end of the private fork may not be included for some time (due to the fact that MAX_ATTESTATIONS =128), we will assume that those attestations will eventually be included , but thatthe inclusion reward will be zero because the value of d will be high. Thus the cost of a length- n malicious reorg is k · ρ/ , where k is the number of attestations that the attacker creates after theend of the private fork. Figure 4 demonstrates the low costs of reorg attacks.
B Finality Delay
B.1 Example of Finality Delay with 30% Attacker
Consider an attacker with 30% of the total stake. In order to ensure a specific epoch is not justified,the attacker must ensure the / threshold for justification isn’t met. Given 32 slots per epoch and128 validators per committee, there are 4096 attestations for each epoch. This implies that in orderfor an epoch to become justified, at least (cid:100) · / (cid:101) = 2731 attestations must identify the correctepoch boundary block, and thus the attacker needs to ensure that at least 1366 of the attestations areincorrect. The 30% attacker will withhold their own (cid:98) · . (cid:99) = 1228 attestations, and thus needsto ensure − honest attestations are incorrect. Because there are attestationsper slot, this corresponds to the attacker needing at least 2 slots at the beginning of the epoch.
B.2 Calculating Cost of Finality Delay
We now directly calculate the cost for each finality delay attack. Again we consider the case wherethere are · validators who each have the MAX_EFFECTIVE_BALANCE = 32 × Gwei. Recall thatin this case the max value, ν , of a single attestation is Gwei. When the network has not beenfinalized for 4 epochs, the system enters an inactivity leak state, where it remains for each subsequentepoch until finality
Definition 13.
The inactivity leak penalty, denoted λ , as a function of the number of epochs sincefinality, e f , for e f > is, λ ( e f ) = e f · MAX_EFFECTIVE_BALANCEINACTIVITY_PENALTY_QUOTIENT (7) = e f · × ≈ . e f . (8) Attacker attestations during the private fork will be included by subsequent attacker blocks. They will be included because the honest nodes will be incentivized to include as many attestations as possible dueto the proposer rewards. Even though the attacker attestations may not immediately be included in the chain, they will still count towardsthe value of the LMD-GHOST fork choice. We use 139 in the main text because the attacker creates a single attestation to their own EBB.
10n addition to the inactivity leak penalty, the attacker will incur a penalty of ν for each missingattestation. Thus for each attestation that the attacker owns, the cost is ν , because if they wereplaying the honest strategy they would earn · ν , and now each attestation missing will be worth − · ν Lemma B.1.
The cost of a length- n delay in finality, C ( n ) , for a 30% attacker is, C ( n ) = (cid:40) (cid:100) n/ (cid:101) · · ν if n ≤ (cid:100) n/ (cid:101) · · ν + λ ( n ) if n > (9) Proof.