4D explains in detail the PoS attacks and defense measures that may be faced after the merger of Ethereum
Compilation of the original text: Overnight Porridge
Compilation of the original text: Overnight Porridge
Translator's Note: For the upcoming merger of Ethereum, the author jmcook.eth summarizes the relevant consensus attack methods based on a large number of research literature, and mentions some solutions. In general, after switching to the PoS consensus mechanism, the more the proportion of pledged ETH controlled by the attacker, the greater the chance of success of the attack, and the built-in "carrot and stick" incentive layer of Ethereum can prevent most malicious behaviors , especially for low-staking attackers, but for 34%, 51% or 66% attacks, it may require community coordination to solve them, so preventing the centralization of pledged rights and interests will be crucial to the security of the Ethereum network .
Thanks to Tim Beiko and Caspar Schwarz-Schilling for helpful comments on early drafts!
Ethereum is a notoriously adversarial environment, and it has even been likened to a "dark forest" (the dreaded game-theoretic concept of the three-body problem). This reputation mainly comes from weaknesses in the application layer (insecure smart contracts) or social layer (where users are manipulated into giving up their private keys or inadvertently signing transactions), and the presence of bots that extract value (MEV) from transaction storage pools. However, sophisticated hackers who are thieves or vandals are also constantly looking for opportunities to attack Ethereum’s client software. Client software, which turns a computer into an Ethereum node, is the code that defines all the rules for connecting to other nodes, exchanging information, and agreeing on the state of the Ethereum blockchain. An attack on the protocol layer is an attack on Ethereum itself.
Soon, the ethereum client will undergo a major upgrade (called a "merge") that will switch off the proof-of-work (PoW) algorithm that secures ethereum and replace it with a proof-of-stake (PoS) consensus mechanism. There are many reasons for this, which have been explained in detail in other articles. It will be a philosophical change as well as a technological one.
Merging into a proof-of-stake (PoS) consensus mechanism brings sustainability and scalability benefits, but on the other hand, the complexity of the client software will increase, as will the potential attack surface of the protocol. Currently, only a single piece of software needs to be running to secure the PoW Ethereum blockchain, but after the “merge”, the number of pieces of software that needs to be running increases to three (execution client, consensus client, and validators).
This article provides an overview of known attack vectors on the Ethereum consensus layer and outlines some methods of defending against these attacks. Readers may need to have some basic knowledge of the beacon chain to get the most value from this article. Also, it will be helpful to have a basic understanding of the Beacon Chain’s incentive layer and the fork choice algorithm LMD-GHOST.
preamble
preamble
incentive layer
The Beacon Chain is a proof-of-stake (PoS) blockchain that is secured using Ethereum's native cryptocurrency, ETH. Node operators who wish to participate in validating blocks and identifying the head of the blockchain deposit ETH into Ethereum In the smart contract of Fangfang. They are then paid in ETH to run validator software, check the validity of new blocks received through the peer-to-peer network, and apply the fork choice algorithm to identify blockchain heads. Node operators are now "validators", and validators have two main roles: 1) check new blocks and "prove" that they are valid, and 2) propose new blocks when randomly selected from the total validator pool. If a validator fails to complete either of these two tasks when asked, they miss out on the ETH payment. There are also some operations that are very difficult to perform accidentally and indicate malicious intent, such as proposing multiple blocks in the same slot, or proving multiple blocks in the same slot. These are "slashable" behaviors that can lead to verification Tokens burn a certain amount of ETH (up to 0.5 ETH) before being removed from the network, which takes 36 days. ETH from slashed validators is slowly drained over the exit period, but on day 18, when more validators are slashed at the same time, they receive a larger "correlation penalty". Therefore, the incentive structure of the Beacon Chain is to reward honest actors and punish bad actors.
Fork choice
The fork choice algorithm is run by each validator and its role is to identify the head of the blockchain. Under the ideal conditions of completely honest validators and zero network latency, the fork choice algorithm is actually unnecessary, since there is only one block at the top of the blockchain. In reality, however, some clients will receive blocks later than others, creating multiple versions of the blockchain header, and there may be a percentage of misbehaving validators who may be in the The same slot proposes or votes for multiple blocks. This means that there has to be some kind of algorithm to pick out the real blockchain header from multiple options.
As a side note, the beacon chain also immobilizes the blockchain at regular intervals, which is called "finality". The process works by considering the first slot in each epoch as a "checkpoint". A checkpoint is said to be "justified" if it collects proofs (votes) from validators holding at least 2/3 of the total staked ETH in the deposit contract. Once that checkpoint has another checkpoint above it, it becomes the "final" checkpoint. The fork choice algorithm then only considers blocks from an unreasonable part of the blockchain. The algorithm that proves and finalizes the blockchain is called "Casper FFG", while the fork selection algorithm itself is called LMD-GHOST (stands for "Latest News-Driven Greediest, Heaviest Observed Subtree"), which is a A way of saying this in jargon that the correct blockchain is the one that has accumulated the most proofs (GHOST), and if multiple messages are received from the same validator, only the last one counts (LMD). Each validator evaluates each block using this rule and adds the heaviest block to its canonical chain.
During each epoch, the validator needs to sign a certificate, which contains two key pieces of information: "LMD vote" and "FFG vote". The LMD vote is the root of the block that the validator considers to be the head of the blockchain, the FFG vote contains the block hash and epoch of the target checkpoint and the source checkpoint, where the source checkpoint is the latest valid checkpoint that the chain already knows, and The target checkpoint is the next checkpoint to prove.
Therefore, the consensus algorithm of the beacon chain is a combination of LMD-GHOST and Casper FFG, sometimes we also call it Gasper. After a brief understanding of this background knowledge, we can continue to study some possible attacks on this system.
Layer 0 Attacks
First, individuals who are not actively participating in Ethereum (by running client software) may choose to target the social layer (layer 0) to attack the Ethereum network. Although these attacks never actually directly affect the execution of any Ethereum software, they pose a risk to Ethereum. Layer 0 is the foundation upon which Ethereum is built, so it represents a potential attack surface with consequences that ripple through the rest of the stack. Here are some examples that come to mind:
A major misinformation campaign launched across multiple platforms and sustained for months or years could erode community trust in the Ethereum roadmap, development team. This may reduce the number of individuals willing to participate in network security, reducing decentralization and cryptoeconomic security.
Targeted attacks or intimidation against the developer community, which could lead to voluntary developer exits and slow down the development of Ethereum while hitting morale more broadly.
Overzealous regulation can also be considered a Layer 0 attack, as it can quickly dampen participation and adoption.
Knowledgeable but malicious actors infiltrate developer communities with the aim of slowing down progress by reducing discussion, delaying critical decisions, creating spam posts, or diverting attention from proposals, among other things.
Deliberately stoking discontent in the Ethereum community with the intent of creating enough unrest to cause a permanent split.
Bribes to key players in the Ethereum ecosystem to influence decisions.
In many cases, very little money or technical knowledge is required to launch an L0 attack, making attacks on the social layer especially dangerous. All it really takes is time and malicious intent, not scarce resources. It's also interesting to think about how a layer-0 attack can be a multiplier for a cryptoeconomic attack. For example, if censorship or finality reversals are achieved by a malicious majority of stakers, disrupting the social layer could make it more difficult for an out-of-band community to coordinate a response.
Defending against Layer 0 attacks may not be simple, but some basic principles can be established. One is to maintain an overall high signal-to-noise ratio of public information about Ethereum, created and disseminated by honest members of the community through blogs, discord servers, annotated specifications, books, podcasts, and YouTube. Ethereum.org is a good example, especially as they are rapidly translating their extensive documentation and explainer articles into multiple languages. Flooding a space with high-quality information and memes is an effective defense against misinformation (information gaps are vulnerable). The Ethereum community is good at this, but long-term Layer 0 security requires a continued commitment to creating and disseminating high-quality information.
Another important defense against social layer attacks is a clear mission statement and governance agreement. Ethereum positions itself as a decentralization and security champion in smart contract L1, while also placing a high priority on scalability and sustainability. Regardless of any disagreements in the Ethereum community, these core principles will be minimally affected. Evaluating narratives against these core principles, and passing through successive rounds of review in the EIP (Ethereum Improvement Proposal) process, may help the community separate the good guys from the bad, and limit the scope for malicious actors to influence the future direction of Ethereum.
Finally, it is critical that the Ethereum community remains open and welcoming to all participants. A community with gatekeepers, elitism, and exclusion is especially vulnerable to social attacks, as it is easy to construct an “us and them” narrative. An open and inclusive community, on the other hand, is one that more effectively counters misinformation through open discussion. Tribalism and toxic maximalism hurt communities, which erodes Layer 0 security. Ethereum generally has a very open community that welcomes new participants, but this can become increasingly difficult to maintain as the community grows in size. Members of the Ethereum community who have a vested interest in the security of the network should view their actions both online and in the real world as direct contributions to Layer 0 security on Ethereum because, as we will discuss later in this article, strong social Layers are the last line of defense against protocol attacks.
attacker's reward
Layer 0 attacks could be aimed at undermining public trust in Ethereum, devaluing ETH, reducing Ethereum adoption and making Ethereum vulnerable to competing chains, or weakening the Ethereum community and making out-of-band coordination more difficult . However, the benefits to be gained from attacking the Ethereum network itself are not obvious.
A common misconception is that a successful attack allows the attacker to generate new ETH, or withdraw ETH from arbitrary accounts. Neither statement can be trusted because all transactions added to the blockchain are executed by all executing clients on the network. They must satisfy basic conditions for validity (e.g. the transaction is signed by the sender's private key, the sender has sufficient balance, etc.), otherwise they are simply reverted. There are actually several outcomes an attacker might attack: reorgs, double finality, or finality delay.
"Reorganization" is the rearrangement of the blockchain header blocks. In an attack, this aims to ensure that certain blocks are included or excluded even if they are not on the honest network. This could allow an attacker to "double spend", for example, send their ETH to an exchange and cash it out for fiat currency, then reorganize the Ethereum blockchain to delete this transaction so they can eventually get their ETH back and Get fiat currency. Alternatively, a reorganization might allow a sophisticated attacker to extract value (MEV) from someone else's transactions via front-running or back-running transactions, or a reorganization might prevent someone or some organizations from continuing transactions are included in the canonical chain, effectively censoring them from the Ethereum network.
The most extreme form of reorganization is "finality reversion," which removes or replaces previously finalized blocks. This is only possible if at least 1/3 of the staked ETH is destroyed. This guarantee is called "economic finality", which we will describe in more detail later.
A double finality (Double finality) attack is very unlikely, but serious, when two forks are able to finalize blocks at the same time, causing a permanent blockchain split. This is theoretically possible, as long as the attacker can control 34% and above of the total staked ETH, and is willing to risk losing them. The community will then be forced to coordinate off-chain and come to a consensus on which chain to follow. We will explore these types of socially coordinated defenses in detail later.
Finality delay attacks prevent the network from reaching the necessary conditions for Casper-FFG to finalize the chain. This would be extremely disruptive to Ethereum's application layer, as many applications running on top of Ethereum rely on fast finality to function. Without a high level of confidence in the finality of the blockchain, it is difficult to trust financial applications built on top of it. The purpose of the finality delay attack may only be to destroy Ethereum, rather than directly profit, unless the attacker deploys some strategic short positions.
Laziness and Equivocation
Anyone can run Ethereum's client software, even without running validators. People do this because it provides a local copy of the blockchain that can be used to verify data very quickly and enables transactions to be submitted privately to the Ethereum network without going through a centralized third party such as Infura or Quicknode. However, node operators who do not also run validators cannot participate in block production or validation. This means they do not affect network security at all. The chances of a non-validator operator attacking the beacon chain are negligible, unless they also launch an unrelated layer-0 attack.
To add a validator to the consensus client, users need to stake 32 ETH in the deposit contract. With an active validator, users begin to actively participate in Ethereum's network security by proposing and attesting to new blocks. While taking on these additional responsibilities, users are rewarded in the form of ETH, but this also presents them with new opportunities for acts of revenge. Validators now have a say, which they can use to influence the future content of the blockchain, they can work honestly to grow their ETH reserves, or they can take the risk and try to manipulate the process for their own benefit. One way to launch an attack is to accumulate a large percentage of staked stake and then use it to defeat honest validators. The greater the proportion of stake stake controlled by an attacker, the greater their voting power, especially at certain economic milestones that we will explore later. However, most attackers won't be able to amass enough ETH to pull this off, so they'll have to use subtle techniques to manipulate the honest majority into acting a certain way.
Fundamentally, all small-stake attacks against the beacon chain are subtle variations of two types of validator misbehavior: underactivity (failure to attest/propose or delay execution) or overactivity (too many proposals/proofs in one slot time period). In their most general form, these behaviors are easily handled by fork choice algorithms and incentive layers, but there are clever ways to make these algorithms work in the attacker's favor. Several such techniques have been identified, primarily carefully coordinating the timing and propagation of their messages to control how different subsets of the overall validator set see the state of the blockchain and thus how they behave. The next section describes some of the ways low-stake attackers can attack the network, and how to defend against these attacks.
Attack of small stakers
Short range re-orgs
There are several papers explaining attacks against the beacon chain that use only a fraction of staked ETH to achieve reorganization or delay finality attacks. These attacks usually rely on the attacker withholding some information from other validators and then releasing it in some subtle way or at some opportune time. These attacks usually aim to replace some honest blocks from the canonical chain. These honest blocks had not yet been created when the attack started, and this attack is known as ex ante reorg, as opposed to ex ante reorg (in which the attacker retrospectively deletes from the canonical chain validated blocks). In PoS Ethereum, ex post reorganization is practically impossible without controlling 2/3 of the staked ETH (approximately $18 billion at current prices). If the attacker controls less than 66% of the stake, the attacker's chance of completing a post-mortem reorganization is very low (even if the attacker controls 65% of the stake, their chance of success is less than 0.05%).
Figure: A post-mortem reorganization attack performed by an attacker controlling 2/3 of the stake. They ignore the honest block B proposed in slot N+1 and instead vote for block N as the head of the blockchain. They then vote for block C in slot N+2, and at the same time, because the fork choice rule sees a proof from the previous one but not the current slot, they vote for block B in slot N+2, and the dishonest Validators vote for block C. When slot N+3 arrives, both forks have 66% weight, which is then determined by the lexicographical order of competing block hashes. If this is beneficial to the attacker, they have successfully deleted block B from the blockchain.
On the other hand, the same mechanisms that work well to prevent ex post reorganization can be used by sophisticated attackers under very specific and unlikely network conditions to create pre ex post reorganization. For example, this paper shows how an attacking validator can create and attest a block (B) for a specific slot n+1, but avoid propagating it to other nodes on the network. Instead, they withhold that proven block until the next slot n+2. Honest validators propose a block (C) for slot n + 2. Almost at the same time, the attacker can release the block (B) they withheld and the proof they retained, and prove that block (B) is the head of the blockchain, their vote for slot n + 2, effectively denying honesty Existence of block (C). When the honest block (D) is released, the fork choice algorithm sees that block (D) builds on block (B) more than block (D) builds on block (C). Heavy. Thus, the attacker successfully removes the honest block (C) in slot n + 2 from the canonical chain using 1 block pre-reorganization. An attacker with a stake of 34% has a good chance of winning this attack, as their vote gives the attacker's preferred fork 68% weight, while the honest fork has 66% weight, as in stated. This means they don't need to rely on manipulating honest validators to vote with them. In theory, though, this attack could be attempted with a much smaller stake ratio. Neuder et al. described a pre-reorganization attack with a 30% pledge ratio, but later proved that such a pre-reorganization attack is also feasible under the control of a 2% pledge ratio.
sourcesource）
A successful restructuring attacker cannot change history, but they can dishonestly change the future. They don't need to control a majority of staked ETH to do this, although their chances of success increase with the proportion of staked they control. This reorganization attack could allow them to double spend or withdraw MEV by front-running large transactions. This attack can also be extended to multiple blocks, but the probability of success decreases as the reorganization length increases.
Bouncing and Balancing
A more sophisticated attack can split the set of honest validators into discrete groups with different views of the blockchain header, known as a balancing attack. In this case, the attacker waits for an opportunity to propose a block, and when it arrives, they propose two blocks in the same slot. They send one block to half of the set of honest validators and another block to the other half. The fork choice algorithm will detect this ambiguity, and the block proposer will be slashed and ejected from the network, but both blocks still exist, and about half the validator set will attest to each fork . At the cost of slashing a single validator, the attacker successfully splits the blockchain in two. Meanwhile, the rest of the malicious validators withheld their proofs. Then, by selectively publishing proofs in favor of one or the other fork to enough validators when executing the fork-choice algorithm, they were able to make the network see whichever fork had the most accumulated proofs. This can continue indefinitely, with the attacking validator maintaining an even split of validators on both forks. Since neither fork could attract a 2/3 supermajority, the beacon chain could not be finalized. The larger the proportion of stake stake controlled by an attacking validator, the more likely an attack will be at any given epoch, since the more likely they are to select a validator to propose a block in each slot. Even if you only control 1% of the pledged equity, the opportunity to launch a balance attack will appear once every 100 epochs on average, and it doesn't take long to wait.
A similar attack, called a bouncing attack, also only requires control of a small fraction of the stake. In this case, the attacking validator again rejects the vote. This time, instead of issuing votes to maintain an even split between the two forks, they use their votes to justify alternate checkpoints between fork A and fork B when appropriate. This flip between two forks stops finality.
Defenses against bounce and balance attacks
Both bouncing attacks and balancing attacks rely on attacking validators to delay their proofs until an appropriate moment in order to have a large impact on the network. Therefore, this attack is only feasible under unlikely network synchronization conditions and the attacker has very fine-grained control over message timing through tightly coordinated colluding validators. Still, there is a need to close this attack vector. To prevent late messages from affecting consensus, late messages can be weighted less compared to messages received in time. This is called a proposer-weight boosting scheme.
For bouncing attacks, the fix is to update the fork choice algorithm so that the latest reasonable checkpoint can only switch to the alternative chain's checkpoint during the first 1/3 slot of each epoch. This situation prevents an attacker from saving votes for later deployment. Another defense against these delayed voting attacks is to assign more weight to votes arriving in time than votes arriving late for each slot.
Combined, these measures create a scenario in which an honest block proposer issues their block very quickly after the slot begins, and then about 1/3 of the slot (4 seconds) period, the New blocks may cause the fork choice algorithm to switch to another chain. After the same deadline, proofs from slower validators are given lower weight compared to proofs that arrived earlier. This is very beneficial for fast proposers and validators to determine the blockchain head, and greatly reduces the possibility of bouncing attacks and balance attacks. Essentially, these defenses prevent attacks based on the asynchronous nature of large networks, even in the cases described above, without the need for fine-grained control over message publication. Thus, to a large extent, the risk of these types of attacks has been mitigated by modifications to the fork choice algorithm that favor fast activity and penalize delay.
It is worth mentioning that the proposer-weight boosting scheme can only defend against "cheap reorganization" attacks, that is, reorganization attacks carried out by attackers with a small amount of stake. In fact, in another type of pre-reorganization attack, the proposer weight boost scheme itself could be gamed by larger stakers. The authors of this post describe how an attacker controlling 7% of staked stake strategically deploys their votes to trick honest validators into building on their fork, reorganizing an honest block. Honest validators voting for the opponent's fork vote in time for the attacker to benefit from the proposer weight promotion scheme. Again, this attack is designed assuming ideal latency conditions, which are difficult to satisfy in real situations. In general, the greater the proportion of stake stake controlled by an attacker, the greater the chance of a successful attack. And larger pledged interests also mean more risk capital and stronger economic inhibition.
advanced balance attack
The bouncing and balancing attacks described above rely on malicious validators to have very fine-grained control over when other validators on the network receive their messages, and such attacks have been made effective through proposer-weight boosting schemes relieved.
However, the researchers also describe an additional attack that does not rely on fine-grained control over network latency. In this case, the attacker needs to use a proposed validator in two subsequent slots (the probability of this happening in any two slots increases with the number of validators controlled by the attacker) . One of the adversarial block proposers proposes a block in slot n, and then the second adversarial block proposer proposes a conflicting block in slot n+1, thus creating a fork. Since no block proposer is equivocated, no slashing occurs. In this example, we assume that forking A would be more beneficial. The attacker can know this, and the attacker can also estimate the time it takes for half of the validators on the network to submit a proof... the reserved vote from slot n can be released at about the point in time when half of the validators voted. These are proofs of support for fork B from slot n. Thus, half of the validator group votes for fork A because they don't know about the additional proofs on fork B, while the other half votes for fork B with more weight. Withholding hostile votes in n+1 can be used to make up for any shortfall on fork B caused by inaccurate timing of the issuance of the withholding proof.
This balancing attack is described against an idealized version of the fork choice algorithm, which has a more predictable proof time than the fork choice algorithm actually implemented in the Ethereum consensus client, while executing this on the real beacon chain Attacking is much more difficult. Distributing the attacker's nodes in the network topology can help the attacker to overcome this problem to some extent, since their messages propagate throughout the network faster than messages from one topological location.
A balancing attack specific to the LMD rule has also been proposed, which is considered feasible despite a proposer-weight boosting scheme. The attacker establishes an approximate balance between the forks by obfuscating their block proposals and propagating each block to roughly half the network to create two competing chains. The colluding validators then vote ambiguously so that half of the network receives their votes for fork A first and the other half of the network receives their votes for fork B first. Since the LMD rule discards the second proof and only keeps the first for each validator, half of the network will only see A's vote and B's no vote, and the other half of the network will see B's vote and A's none vote. The article's authors describe the LMD rule as giving attacking opponents "extraordinary power" to launch balanced attacks.
This LMD attack vector has been closed by updating the fork choice algorithm so that it completely drops ambiguous validators from fork choice consideration. Ambiguity validators can also reduce their future influence through the fork choice algorithm. This prevents the balancing attacks described above while also maintaining resilience to avalanche attacks.
Avalanche attacks
A March 2022 paper describes another type of attack called avalanche attacks. The authors of this paper argue that proposer-weight boosting schemes cannot protect against certain variants of the avalanche attack. However, the authors of the paper also only demonstrated an attack on a highly idealized version of Ethereum's fork choice algorithm (they used GHOST without LMD).
To launch an avalanche attack, the attacker needs to control multiple consecutive block proposers. In each block proposal slot, the attacker withholds their blocks, collecting them until the honest chain reaches a subtree weight equal to the withheld block. The attacker then releases the withheld block, allowing it to cause maximum confusion. This means, for example, that for 6 withholding blocks, the first honest block n competes with hostile block n to create a fork, and then all 5 remaining hostile blocks compete with the honest block at n+1 compete. This means that the fork that established hostile blocks n and n+1 now attracts honest proofs, because the weight of the honest chain is now equal to the weight of the hostile chain. This can now be repeated for the remaining withheld blocks, allowing the attacker to prevent honest validators from following the honest head of the chain until the attacker runs out of ambiguous blocks. If the attacker has more opportunities to propose blocks during the attack, they can use those blocks to scale the attack so that the more validators participate in the collusion attack, the longer the attack lasts and more Honest blocks are moved out of the canonical chain.
The LMD part of the LMD-GHOST fork selection algorithm mitigates the avalanche attack. LMD means "last message driven", which refers to a table kept by each validator, which contains the latest received from other validators. information. This field will only be updated if a new message comes from a later slot than one already exists in the particular validator table. In practice, this means that in each slot, the first message received is the one it accepts, and any additional messages can be ignored. In other words, the consensus client uses the message from each validator that arrives first, and conflicting messages are simply discarded to prevent avalanche attacks.
finality delay
The same paper that first described the low-cost single-block reorganization attack also describes a delayed finality (also known as "liveness invalidation") attack that relies on the attacker being a block proposer for an epoch boundary block. This is critical because these epoch boundary blocks become the checkpoints that Casper FFG uses to finalize various parts of the chain. Attackers simply withhold their blocks until enough honest validators use their FFG to vote for the previous epoch boundary block as the current finality goal. They then release the withheld blocks and attest their own, and the rest of the honest validators do the same, creating forks with different target checkpoints. If they timed it just right, they would prevent finality because there would never be a 2/3 supermajority to prove either fork. The smaller the proportion of stake stake controlled by the attacker, the more precise the timing needs to be, because the fewer proofs the attacker directly controls, the lower the chance of the attacker controlling the validators proposing a given epoch boundary block.
Notes on long range attacks
There is also a class of attacks specific to proof-of-stake (PoS) blockchains, which involves validators participating in the genesis block maintaining a separate fork of the blockchain alongside the honest one, eventually convincing the honest validators to Switch to it at some appropriate time in the future. This type of attack is impossible on the beacon chain because the "finality gadget" (literally translated as finality gadget) ensures that all validators periodically agree on the state of the honest chain ("checkpoints"). This simple mechanism removes concerns about long-range attackers, since the Ethereum client will not reorganize finalized blocks at all. New nodes joining the network build by finding a trusted recent state hash (called a weak-subjectivity checkpoint) and using it as a pseudo-genesis block. This will create a "gateway of trust" for new nodes entering the network before it can start verifying information for itself. However, the trust required to collect checkpoints from peers or block explorers or elsewhere does not increase the trust implicit in the client development team, so subjectivity is "weak". Since, by definition, checkpoints are shared by all nodes on the network, dishonest checkpoints are a symptom of consensus failure, at which point out-of-band social coordination must take over to save honest validators anyway.
This all goes to show that it is very difficult to successfully attack the beacon chain with a small amount of staked stake. The feasible attacks described here require an ideal fork selection algorithm, and the extremely low probability that network conditions, or the attack vector has been closed by a relatively minor patch to the client software. Of course, we cannot rule out the possibility of a zero-day exploit in the wild, but it does demonstrate the extreme technical skill, knowledge of consensus mechanisms, and luck required for a small number of staking attackers to pull off a successful attack. From an attacker's perspective, their best bet may be to accumulate as much staked ETH as possible.
Denial of Service attack (Denial of Service)
Ethereum's PoS mechanism selects a validator from all validator sets to be the block proposer in each slot. This can be computed using a public function, and it is possible for an adversary to identify the next block proposer slightly ahead of their block proposal. An attacker can then spam block proposers to prevent them from exchanging information with their peers. To the rest of the network, block proposers appear to be offline, and slots will simply become empty. This could be a form of censorship of specific validators to prevent them from adding information to the blockchain. The cost to the attacker depends on the bandwidth of the validator, which means that it is much cheaper to launch a denial of service attack on a home staker than a professional with industrial-grade hardware and an internet connection, making amateurs more vulnerable to censorship. There are some workarounds for this problem, but these schemes also favor professional validators over family stakers. For example, running multiple nodes and separating block building from network communication can provide an additional layer of protection because node identity and validator identity are decoupled. Node runners may switch identities or reacquire identities within a short period of time to avoid denial of service attacks. In the long run, implementing single secret leader election (SSLE) or non-single secret leader election schemes can more effectively mitigate the validator censorship problem, since only block proposers know that they have been chosen, and their choice is not known in advance . All validators submit commitments to the secret to an repeatedly shuffled pool. A random commitment is then publicly chosen, only known to the chosen validators, since the connection has been obfuscated. This work has not yet been implemented, but it is an active area of research and development.
The proportion of pledged equity controlled by the verifier is greater than or equal to 33%
It is safer to distribute the control of pledged ETH to more people than to concentrate it in the hands of a few. This is because the more staking stake one controls, the more influence it has on the Ethereum consensus. All of the attacks mentioned in this paper are more likely to succeed when the attacker has enough stake to stake, and may select more validators to propose blocks in each slot. Therefore, the goal of a malicious validator may be to control as much staked ETH as possible.
33% of staked ETH is a baseline for attackers, if they control more than this amount of ETH, they have the ability to prevent the beacon chain from finalizing without fine-grained control over the actions of other validators. They can simply disappear together. This is because to finalize the beacon chain, there must be 2/3 staked ETH proving pairs of checkpoints. If 1/3 or more of the staked ETH is maliciously attested or not attested, then a 2/3 absolute majority cannot exist. The defense against this is the beacon chain's inactivity leak mechanism, an emergency safety measure that triggers after the beacon chain fails to finalize for 4 epochs. The inactivity leak identifies validators who fail to prove or prove contrary to the majority. The pledged ETH owned by these non-proof validators will be gradually lost until eventually they account for less than 1/3 of the total, so that the blockchain can be finalized again.
The purpose of the inactivity leak mechanism is to make the beacon chain finalize again, and the attacker will also lose part of the pledged ETH. Assuming there is no slashable attack, and attacking validators simply fail to prove, their inactivity score is updated, indicating to the rest of the network that the validator will be penalized every epoch until their inactivity score returns to zero. When the inactivity leak mechanism is active, the inactive validator score is increased by 4 and the active validator score is decreased by 1 each epoch. Once the inactivity leak mechanism is deactivated (and the beacon chain is finalized again), the inactivity score of all active validators is reduced. This will take longer for validators who have been inactive for a longer period of time, since they have more inactivity points to burn. Continuous inactivity will consume inactivity points more slowly. For a validator offline for 100 epochs, its inactivity score will reach around 400, and the penalty size is calculated as:
inactivity score * validator balance / (inactivity score bias x inactivity penalty quotient)
inactivity_score * validator_balance/(inactivity_score_bias x inactivity_penalty_quotient)
where the inactivity score bias is the number by which to increase the validator's score each epoch, and the inactivity penalty quotient is the time it takes to reduce the balance of a non-attesting validator to approximately 60% of its initial value squared, the setup time is approximately 37.5 days. This means that the longer an attacker prevents finality by failing to prove it, the more their stake is burned. Upgrading Ethereum presents a graph that estimates the reduction in validator balances during and after a short (100 epoch, roughly 13.5 hours) negative penalty for validators that are always offline. After 135 epochs, the validator's balance dropped from 32 ETH to 31.996 ETH, a loss of 0.004 ETH. And for an attacker to control 33% of the staked ETH, they would have to run roughly 144,000 validators each holding at least 32 ETH. This means their attack to delay beacon chain finality will cost at least 0.004 x 144000 = 576 ETH. At current market prices, that equates to roughly $1.09 million. At a cost of nearly $1 million, delaying beacon chain finality by half a day has little long-term impact on the beacon chain itself. (Translator's Note: The numbers in the original text have been modified here)
Of course, longer-lasting negative penalties are more expensive, and in fact, the magnitude of the penalty increases quadratically until the beacon chain starts finalizing again. The exact cost to an attacker of delaying finality depends on their initial balance, how long they remain offline, and how long it takes to regain finality. However, the bottom line is that even if validators are not slashed, the continued inactivity of 33% of validators is extremely expensive.
Assuming the Ethereum network is asynchronous (i.e. there is a delay between sending and receiving a message), an attacker controlling 34% of the total stake stake could trigger a double finality attack. This is because an attacker can be ambiguous when being elected as a block producer, and then double-vote with all validators in his possession. This creates a situation where the blockchain forks, each of which has 34% of the staked ETH voting for it. Each fork requires only 50% of the remaining validators to vote for both forks, resulting in supermajority support, in which case both chains can be finalized (since 34% of the attacker validators + remaining Half of 66% = 67% per fork). Each competing block must be received by approximately 50% of the honest validators, so this attack is only feasible if the attacker can control to some extent when the message propagates on the network, so that they can get half of the honest validators to each chain. This is also why this attack requires the network to be asynchronous - if all nodes receive the message immediately, they will know both blocks immediately, and handle the ambiguity by rejecting the earlier received block. An attacker would have to burn their entire stake (34% of the 14 million staked ETH today) to achieve this double finality attack, since 34% of their validators will be double voting at the same time, which is a A slashable attack with maximum relevance penalty. The cost of defending against this attack is only the huge cost of destroying 34% of the total pledged ETH.
Recovering from such an attack requires the Ethereum community to coordinate out-of-band and agree to follow one of the forks while ignoring the other. The complexities associated with such social support are discussed later.
The attacker controls approximately 50% of the stake
In theory, in the case where a malicious validator controls 50% of the staked ETH, he could split the Ethereum blockchain into two forks of equal size. Similar to the balancing attack described earlier, an attacker can use only one of their validators by proposing two blocks for the same slot. Then, instead of manipulating one half of the network by carefully transmitting messages, the attacker can simply use its full 50% stake to vote against the honest validator set, thereby maintaining both forks and preventing finality. After four epochs, the inactivity leak mechanism activates on both forks, as each fork sees that half of its validators fail to attest. Each fork leaks the other half of the stake in the validator set, eventually resulting in two chains completing with different validators representing a 2/3 supermajority. At this point, the only option is to rely on community recovery, which we'll get to later. However, given variations in the number of honest validators, network latency, etc., it seems unlikely that an adversarial set of validators will always control exactly 50% of the total stake, but perhaps there is a way that an attacker could exploit % stake, dynamically adjusting its voting ratio in each slot to maintain a perfect balance between the two forks. Although the risk of a successful attack will undoubtedly increase with the size of the staked ETH ratio in the hands of the attacker, the attack vector associated with 50% staked equity seems unlikely to be successfully exploited, and the huge cost of launching such an attack and low success rate, seems to be a strong disincentive to rational attackers.
And when the stake controlled by the attacker accounts for more than 51%, it can control the fork selection algorithm. In this case, the attacker would be able to testify with a majority vote, giving them enough control to perform short-term reorganizations without deceiving honest clients. Controlling 51% of staking stake does not allow attackers to change history, but they have the ability to influence the future by applying majority votes to forks in their favor, or reorganizing blocks. Honest validators will follow suit, as their fork choice algorithm will also consider the chain favored by the attacker as the heaviest chain, so that attack chain can be finalized. This enables an attacker to censor certain transactions, perform short-range reorganizations, and extract maximum MEV by reordering blocks in their favor. Like proof-of-work (PoW) chains, 51% attacks are very problematic. The defense against this problem is the huge cost of majority stake (currently just under $19 billion), and the attacker faces a huge risk as the social layer could step in and fork the honest minority, making the attack The stakeholder's pledged interest depreciated significantly.
The stake ratio controlled by the attacker is greater than or equal to 66%
An attacker controlling 66% or more of staked ETH can determine its preferred chain without forcing any honest validators. Attackers can simply vote for their preferred fork and then finalize it, simply because they can vote with a dishonest supermajority. As a supermajority staker, the attacker will always control the content of the final block, he has the power to spend, roll back and spend again, he can also censor certain transactions and reorganize the blockchain at will. By purchasing additional ETH to control 66% staked instead of 51%, the attacker is effectively buying the ability to restructure and eventually reverse (i.e. change the past and control the future) after the fact. The current cost of controlling 66% of staked ETH is about $25 billion, and the only defense here is to fall back to the social layer to coordinate the adoption of an alternative fork. We'll explore this in more detail in the next section.
Layer 0: The Last Line of Defense
What happens when a blockchain's coded defenses are compromised, and an attacker is able to finalize a dishonest blockchain?
This situation can arise in a number of ways, most notably when the attacker controls a majority of staking stake, and can be done simply through their own vote or additional proof from 51%+ honest validators. With ETH in control of 34% staked, and some control over messaging on the network, the attacker could finalize both forks. In some cases, reorganized chains may be finalized due to an inactivity leak mechanism. If an attacker succeeds in splitting the validator set into two forks, the inactivity leak mechanism will activate on both forks, and the question becomes, which validators, honest or dishonest, will regain finality? If the honest validators decide first, then the honest chain becomes the canonical chain, the fork selection algorithm of all clients on the network accepts the finalized part of the chain, and Ethereum is back under the control of the honest players. But if dishonest validators manage to finalize the blockchain, the Ethereum community will be in a very difficult position. The canonical chain will contain dishonest parts in its history, and honest validators will eventually be punished.
A third less likely scenario is a permanent network split where validators on one fork somehow do not know their counterparts on the other fork. This creates two independently determined forked chains, each of which leaks the staked stake of another set of validators. Then the two chains will never be reassembled because they will have different final checkpoints. Vulnerabilities (rather than attacks) from dominant clients can also lead to broken but finalized chains. When it comes to Ethereum’s execution layer, the go-ethereum (Geth) client dominates, with over 85% of nodes running it. In terms of the consensus layer, the Prysm client currently dominates, and its share has only dropped to around 50% after continued community activity. Vulnerabilities in the dominant execution client or the consensus client could stop finality or cause incorrect data to be finalized. On the Kiln testnet, a bug in Prysm affected block production, which doesn't matter since nodes have an roughly equal share of four different clients, but on the mainnet, there are over 66% of clients will encounter the same error. Thus, there will be several routes to dishonest finalization chains, although their probability is very low. They all require huge investments in staking ETH, or very complex operations on validator sets, which as of now have only proven feasible under ideal conditions, and these attacks have all been mitigated through software updates. However, we cannot rule out the case that the ultimate solution is to rely on the social layer (layer 0).
One of the strengths of Ethereum's PoS consensus mechanism is that the community can employ a range of defensive strategies in the face of attackers. The minimal response might be to forcefully remove the attacker's validator from the network without any additional penalty. To re-enter the network, an attacker must join an activation queue to ensure that the validator set grows gradually. For example, adding enough validators to double the amount of ETH staked takes about 200 days, effectively giving honest validators 200 days to react before an attacker can attempt another 51% attack. Of course, the community can also decide to punish the attacker more severely, such as canceling past rewards, or burning some (up to 100%) of the attacker's staked capital.
Regardless of the penalties imposed on attackers, the community must also collectively decide whether a dishonest blockchain (albeit one favored by the fork-choice algorithm coded into the Ethereum client) is actually invalid, and the community should Built on an honest alternative chain. Honest validators can collectively agree to build on top of a community-approved fork of Ethereum, e.g. the canonical chain may have been forked before the attack began, or the attacker’s validators were forcibly removed. Honest validators will be incentivized to build on this forked chain, and exchanges and applications built on Ethereum may prefer to be on the honest chain and follow honest validators into the honest blockchain. However, this will be an extremely messy governance challenge. Some users and validators will undoubtedly lose funds by switching back to the honest chain, and the verified block transactions after the attack may be rolled back, thereby disrupting the application layer, which completely shocks users who tend to believe that "code is law". Furthermore, some users, possibly even institutional users, who benefit from a dishonest blockchain through shrewdness or serendipity, may oppose forks to protect their gains. There was a call for the community to rehearse responses to more than 51% staking attacks so that reasonable coordinated mitigations could be quickly executed. Vitalik had some good discussions on ethresear.ch as well as on Twitter.
Summarize
Summarize
This article explores some of the ways an attacker might attack the Beacon Chain after Ethereum merges into the Proof-of-Stake (PoS) consensus mechanism. Overall, the more staked ETH an attacker controls, the greater their chances of success, as their stake can be converted into voting rights that can be used to influence the content of future blocks. As the proportion of pledged ETH controlled by the attacker increases, the destructive power it can achieve is greater:
33%: delayed finality
34%: results in double finality
51%: Censorship, Controlling the Future of Blockchain
66%: Censorship, past and future of blockchain control
There are also more sophisticated attacks that only require control of a small amount of staked ETH, but these attacks require the attacker to have fine-grained control over message timing in order to favor the set of honest validators in their favor.
Overall, despite these potential attack vectors, the beacon chain is low risk, even lower than a proof-of-work equivalent chain. This is because an attacker needs to put at risk the huge cost of staking ETH in order to overwhelm honest validators with voting power. The built-in "carrot and stick" incentive layer prevents most malicious behavior, especially for low-staking attackers. More subtle bouncing and balancing attacks are also less likely to succeed because real-world network conditions make it difficult to achieve fine-grained control over messaging to a specific subset of validators, and client teams have quickly shut down known attacks with simple patches. Bounce Attack, Balance Attack, and Avalanche Attack Vectors for .
A 34%, 51%, or 66% attack may require community coordination to resolve. While this can be painful for the community, the ability of the community to respond out-of-band is a powerful disincentive for attackers. The Ethereum social layer is the ultimate backstop, and a technically successful attack could still be killed by the community agreeing to adopt an honest fork. Ultimately, there will be a race between the attacker and the Ethereum community, and if it goes fast enough, the $25 billion spent on the 66% attack could be wiped out by a successful social coordination attack.
For the attacker, the probability of being profitable would be low enough to be an effective deterrent. This is why maintaining a cohesive social layer with aligned values is so important for crypto investing.
Original link
