Written by: jmcook.eth
Compilation: Overnight porridge, the way of the metaverse
Translator's note: Regarding the upcoming Ethereum merger, the author jmcook.eth summarized the relevant consensus attack methods based on a large number of research documents and mentioned some solutions. In general, after moving to the PoS consensus mechanism, the more proportion of pledged ETH controlled by the attacker, the greater the chance of successful attack, and Ethereum's built-in "carrot and stick" incentive layer can prevent most malicious behaviors , especially for low-staking attackers. However, 34%, 51% or 66% attacks may require community coordination to solve, so preventing the centralization of pledged interests will be crucial to the security of the Ethereum network. .
Thanks to Tim Beiko and Caspar Schwarz-Schilling for their helpful comments on earlier drafts!
Ethereum is a notoriously adversarial environment, and it has even been compared to a “dark forest” (the terrifying game theory concept in Three Body). This reputation mainly comes from weaknesses in the application layer (insecure smart contracts) or social layer (users are manipulated into giving up private keys or inadvertently signing transactions), as well as the presence of bots that extract value (MEV) from transaction storage pools. However, sophisticated hackers who are thieves or saboteurs are constantly looking for opportunities to attack Ethereum’s client software. Client software turns a computer into an Ethereum node, which 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 shut down 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. This will be a philosophical change as well as a technological change.
Incorporating 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 run to secure the PoW Ethereum blockchain, but after the "merger", the number of pieces of software that needs to be run increases to 3 (execution client, consensus client, and validator).
This article provides an overview of known attack vectors on the Ethereum consensus layer and outlines some methods to defend against these attacks. Readers may need to have some basic knowledge of beacon chains to get the most value from this article. In addition, it will also be helpful to have a basic understanding of the beacon chain’s incentive layer and the fork selection algorithm LMD-GHOST.
These are big topics. But I've included some very accessible primers in the preface below.
Preface
1) Incentive layer
The Beacon Chain is a proof-of-stake (PoS) blockchain that is secured using Ethereum's native cryptocurrency, ETH, which is expected to be deposited into ether by node operators involved in validating blocks and identifying the blockchain head. in Fang’s smart contract. They are then paid in ETH to run validator software, check the validity of new blocks received over the peer-to-peer network, and apply a fork-choice algorithm to identify the blockchain header. Node operators are now "validators", and validators have two main roles: 1) checking new blocks and "certifying" whether they are valid, 2) proposing new blocks when randomly selected from the total validator pool. If validators fail to complete either of these two tasks when asked, they miss out on ETH payments. 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 The server burns a certain amount of ETH (maximum 0.5 ETH) before being removed from the network, which takes 36 days. Slashed validators will slowly lose their ETH during the exit period, but on day 18, when more validators are slashed at the same time, they will suffer a greater "correlation penalty." Therefore, the incentive structure of the Beacon Chain is to reward honest actors and punish bad actors.
2) Fork selection
The fork-choice algorithm is run by each validator and its role is to identify the head of the blockchain. Under ideal conditions of perfectly honest validators and zero network latency, the fork-choice algorithm is actually unnecessary because there is only one block at the top of the blockchain. However, in reality, some clients will receive blocks later than others, creating multiple versions of the blockchain header, and there may be a proportion of misbehaving validators that may Propose or vote for multiple blocks in the same slot. This means that there must be some algorithm to pick the real blockchain header from multiple options.
As a quick aside, the beacon chain also makes the blockchain immutable at regular intervals, which is called "finality." The process works by treating the first slot in each epoch as a "checkpoint". A checkpoint is said to be "justified" if it collects proofs (votes) from validators that hold 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 portion of the blockchain. The algorithm that certifies and finalizes the blockchain is called "Casper FFG," while the fork-choice algorithm itself is called LMD-GHOST (standing for "Latest News Driven Greediest, Heaviest Observed Subtree"), which is A way of saying it in jargon is 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 message counts (LMD). Each validator evaluates each block using this rule and adds the heaviest block to its canonical chain.
In each epoch period, 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 believes is 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 most recent legitimate checkpoint already known to the chain, 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 briefly understanding this background knowledge, we can continue to study some of the possible attacks on this system.
Level 0 Attack
First, individuals who are not actively participating in Ethereum (by running client software) can choose to attack the Ethereum network by targeting the social layer (Layer 0). While these attacks never actually directly affected the execution of any Ethereum software, they pose risks to Ethereum. Layer 0 is the foundation on 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:
1. Major misinformation campaigns launched across multiple platforms and lasting for months or years may erode the community’s trust in the Ethereum roadmap and development team. This may reduce the number of individuals willing to participate in cybersecurity, making the decentralized and cryptoeconomic economy less secure.
2. Targeted attacks or intimidation against the developer community, which could lead to developers voluntarily quitting and slow down the development of Ethereum while damaging morale more broadly.
3. Overzealous regulation can also be considered a layer 0 attack, as it can quickly inhibit participation and adoption.
4. Knowledgeable but malicious actors infiltrate the developer community with the goal of slowing down progress by reducing discussions, delaying key decisions, creating spam posts, or distracting proposals.
5. Deliberately inciting dissatisfaction in the Ethereum community with the purpose of creating enough turmoil to cause permanent division.
6. Bribery key players in the Ethereum ecosystem to influence decisions.
In many cases, little money or technical knowledge is required to launch an L0 attack, making attacks on the social layer particularly dangerous. All it really takes is time and malicious intent, not scarce resources. It's also interesting to think about how layer 0 attacks can become multipliers for a cryptoeconomic attack. For example, if censorship or finality reversal is achieved by a malicious majority of stakers, disrupting the social layer may make it more difficult for the 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 for public information on Ethereum, which is created and disseminated by honest members of the community through blogs, discord servers, annotated specs, books, podcasts, and YouTube. Ethereum.org is a good example, especially since they are rapidly translating their extensive documentation and explainer articles into multiple languages. Flooding a space with 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 an ongoing 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 the champion of decentralization and security in L1 smart contracts, while also placing a high priority on scalability and sustainability. Whatever disagreements arise in the Ethereum community, these core principles will be minimally affected. Evaluating the narrative against these core principles, and passing it through successive rounds of review during the EIP (Ethereum Improvement Proposal) process, may help the community separate the good guys from the bad guys and limit the scope for malicious actors to influence the future direction of Ethereum.
Finally, it is crucial that the Ethereum community remains open and welcoming to all participants. A community with gatekeeping, elitism, and exclusivity is particularly vulnerable to social attacks because it makes it easy to construct an “us and them” narrative. On the other hand, an open and inclusive community is one that more effectively combats misinformation through open discussion. Tribalism and toxic maximalism harm communities, which erodes Tier 0 security. Ethereum generally has a very open community that welcomes new participants, but as the community grows in size, this can become increasingly difficult to maintain. Members of the Ethereum community with a vested interest in network security should view their behavior online and in the real world as a direct contribution to the security of Ethereum’s Layer 0 because, as we will discuss later in this article, strong social The layer is the last line of defense against protocol attacks.
Attacker's reward
Layer 0 attacks may be designed to undermine public trust in Ethereum, devalue ETH, reduce Ethereum adoption, and make Ethereum vulnerable to overtake by other competing chains, or weaken the Ethereum community and enable out-of-band coordination. -of-band coordination) is 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. Both claims are untrustworthy because all transactions added to the blockchain are executed by all execution clients on the network. They must meet basic conditions for validity (e.g. the transaction is signed by the sender's private key, the sender has a sufficient balance, etc.), otherwise they will simply revert. There are actually several outcomes that an attacker might target: reorgs, double finality, or finality delay.
"Reorganization" is the rearrangement of the blocks in the head of the blockchain. In an attack, this aims to ensure that certain blocks are included or excluded even if they are not in the honest network. This could allow an attacker to "double spend," for example, sending their ETH to an exchange and cashing it out for fiat, then reorganizing the Ethereum blockchain to delete this transaction so they can eventually get the ETH back and Obtain fiat currency. Alternatively, the reorganization could allow a sophisticated attacker to extract value (MEV) from other people's transactions through front-running or back-running, or the reorganization could permanently block someone or some organization. of transactions are included in the canonical chain, effectively censoring them from the Ethereum network.
The most extreme form of reorganization is "finality reversion", which deletes or replaces previously determined blocks. This is only possible if at least 1/3 of the staked ETH is burned, a guarantee called "economic finality" which we will detail later.
The possibility of a double finality attack is low, but it can be serious and occur when two forks can confirm blocks at the same time, causing a permanent blockchain split. This is theoretically possible, as long as the attacker has access to 34% or more of the total staked ETH and is willing to risk losing them. The community will then be forced to coordinate off-chain and reach 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 determine 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 degree of confidence in the finality of the blockchain, it will be difficult to trust the financial applications built on it. The purpose of a finality delay attack may simply be to damage 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 a validator. 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 verification. This means that they do not impact network security at all. The likelihood of non-validating node operators attacking the beacon chain is negligible unless they also launch unrelated layer 0 attacks.
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 proving new blocks. While taking on these additional responsibilities, users receive rewards in the form of ETH, but it also gives them new opportunities for retaliatory behavior. Validators now have a voice that they can use to influence the future content of the blockchain, they can work honestly to increase their ETH reserves, or they can take risks and try to manipulate the process to their own benefit. One way to launch an attack is to accumulate a large percentage of stake and then use it to defeat honest validators. The greater the proportion of stake that an attacker controls, the more voting power they have, especially on certain economic milestones that we will explore later. However, most attackers will not be able to accumulate enough ETH to implement this attack method, so they will have to use subtle techniques to manipulate the honest majority to behave in 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 delayed execution) or overactivity (Too many proposals/proofs in one slot). In their most common form, these behaviors are easily handled by fork-choice algorithms and incentive layers, but there are clever ways to make these algorithms work in an attacker's favor. Several such techniques have been discovered, essentially carefully coordinating the timing and propagation of their messages to control how different subsets of the entire validator set view 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 by small stakers
1) Short range re-orgs
There are several papers explaining attacks against the beacon chain that use only a small portion of staked ETH to implement reorg or finality delay 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 moment. These attacks usually aim to replace some honest blocks from the canonical chain. When the attack starts, these honest blocks have not yet been created, this attack is called an ex ante reorg, as opposed to an ex post reorg (in which the attacker retrospectively removes from the canonical chain already verified block). In PoS Ethereum, post-event restructuring is virtually impossible without controlling 2/3 of the staked ETH (approximately $18 billion at current prices). If the attacker controls less than 66% of the staked stake, the attacker's chance of completing a post-mortem reorganization is very low (even if the attacker controls 65% of the staked stake, their chance of success is less than 0.05%).
Above: Post-hoc 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 rules see proofs from the previous instead of the current slot, they vote for block B in slot N+2, dishonestly. Validators vote for block C. When slot N+3 is reached, both forks have a weight of 66%, which is then determined by the lexicographic order of competing block hashes. If this benefits the attacker, they successfully remove block B from the blockchain.
On the other hand, the same mechanisms that work well against ex-post reorganizations can be exploited by sophisticated attackers to create ex-ante reorganizations under very specific and unlikely network conditions. For example, this paper shows how an attacking validator can create and prove a block (B) for a specific slot n+1, but avoid propagating it to other nodes on the network. Instead, they withhold the attested block until the next slot n+2. Honest validators propose a block (C) for slot n + 2. At almost 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 and their vote for slot n + 2, effectively denying honesty Block (C) exists. When the honest block (D) is released, the fork choice algorithm sees that the block (D) built on the block (B) is more advanced than the block (D) built on the block (C). Heavy. Therefore, the attacker successfully uses 1 block pre-reorganization to remove the honest block (C) in slot n + 2 from the canonical chain. An attacker holding 34% of the stake has a good chance of winning this attack, as their vote gives the attacker's preferred fork a weight of 68%, while the honest fork has a weight of 66%, as shown here Describe. This means they don’t need to rely on manipulating honest validators to vote with them. However, in theory, this attack could be attempted with a smaller stake ratio. Neuder et al. described a pre-event reorganization attack under a 30% stake ratio, but later proved that this pre-event reorganization attack is also feasible when controlling a 2% stake ratio.
Conceptual diagram of the above single-block reorganization attack (adapted from https://notes.ethereum.org/plgVdz-ORe-fGjK06 BZ_3 A#Fork-choice-by-block-slot-pair)
A successful recombinant attacker cannot change history, but they can dishonestly change the future. They do not need to control a majority of the staked ETH to do this, although their chances of success increase as they control the staked proportion. This reorganization attack could allow them to double spend or front-run large transactions to extract MEV. This attack can also be extended to multiple blocks, but the likelihood of success decreases as the reorganization length increases.
2) Bouncing and Balancing
A more sophisticated attack can split the honest set of validators into discrete groups with different views of the blockchain header, which is called 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 honest validator set 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 will still exist and there will be about half of the validator set attesting to each fork . At the cost of slashing a single validator, the attacker successfully split the blockchain in two. Meanwhile, the remaining malicious validators withhold their proofs. Then, by selectively publishing proofs favoring one fork or the other to enough validators while executing the fork choice algorithm, they are able to let the network see whichever fork has the most cumulative proofs. This can continue indefinitely, with attacking validators maintaining an even distribution of validators across both forks. Since neither fork can attract a 2/3 supermajority, the Beacon Chain cannot be finalized. The greater the proportion of stake controlled by an attacking validator, the greater the likelihood of an attack at any given epoch, as they are more likely to select validators to propose a block in each slot. Even if you only control 1% of the stake, the opportunity to launch a balancing attack will appear once every 100 epochs on average, which does not need to wait too long.
A similar attack called a bouncing attack only requires control of a small portion of the stake. In this case, the attacking validator rejects the vote again. This time, instead of issuing votes to maintain an even split between the two forks, they use their votes to justify alternating checkpoints between fork A and fork B when appropriate. This flip between two forks stops finality.
3) Defense measures against bouncing attacks and balancing attacks
Both bounce attacks and balancing attacks rely on attacking the validator to delay its proof until some appropriate moment in order to have a dramatic impact on the network. Therefore, this attack is only feasible under unlikely network synchronization conditions and the attacker has very granular control over message timing via tightly coordinated colluding validators. Still, it is necessary to shut down this attack vector. To prevent late messages from affecting the consensus, the weight of messages received late can be reduced compared to messages received in time. This is called a proposer-weight boosting scheme.
For bouncing attacks, the fix is to update the fork selection algorithm so that the latest reasonable checkpoint can only switch to the checkpoint of the alternative chain during the first 1/3 slot of each epoch. This scenario prevents attackers from saving votes for later deployment. Another defense against these delayed vote attacks is to assign a greater weight to votes that arrive in time compared to late votes for each slot.
Combined, these measures create a scenario in which an honest block proposer issues their block very quickly after the slot starts, and then roughly 1/3 of the slot (4 seconds) later, this New blocks may cause the fork-choice algorithm to switch to another chain. After the same deadline, proofs from slower validators will have a lower weight than proofs that arrive earlier. This greatly facilitates fast proposers and validators in determining the blockchain head and greatly reduces the possibility of bouncing attacks and balancing attacks. Essentially, these defenses prevent attacks based on the asynchronicity of large networks, even in the above cases, without requiring fine-grained control over message publishing. Therefore, 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 latency.
It is worth mentioning that the proposer-weight boosting scheme can only resist "cheap reorganization" attacks, that is, reorganization attacks carried out by attackers with a small amount of pledged equity. In fact, in another type of ex-ante reorganization attack, the proposer weight boosting scheme itself could be gamed by larger stakers. The authors of this article describe how an attacker controlling 7% of the staking stake strategically deployed their votes to trick honest validators into building on their fork, reorganizing an honest block. Honest validators who vote for the opponent fork vote in time so that the attacker benefits from the proposer weight boosting scheme. Again, this attack is designed assuming ideal latency conditions, which are difficult to meet in practice. In general, the greater the proportion of pledged equity controlled by the attacker, the greater the chance of a successful attack. And larger pledged interests also mean more risk capital and stronger economic restraint.
4) Advanced balanced attack
The bouncing and balancing attacks described above rely on malicious validators exercising very fine-grained control over when their messages are received by other validators on the network, and such attacks have been made effective through proposer-weight boosting schemes. The ground eased.
However, the researchers also describe an additional attack that does not rely on fine-grained control of 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, creating a fork. Since no block proposer is equivocated, no slashing occurs. In this example, we assume that fork A would be more advantageous. An 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 votes from slot n can be released at about the point in time when half of the validators have voted. These are proofs from slot n in favor of fork B. Therefore, half of the validator group voted for fork A because they were unaware of the additional attestations on fork B, while the other half voted for fork B, which is more heavily weighted. Hostile votes withheld in n+1 can be used to make up for any shortfall on fork B caused by inaccuracies in the timing of issuing withholding certificates.
This balancing attack is described against an idealized version of the fork-choice algorithm, which has more predictable proof times than the fork-choice algorithm actually implemented in the Ethereum consensus client, while executing this on a real beacon chain Attacking is much more difficult. Distributing the attacker's nodes across the network topology can help attackers overcome this problem to an extent, since their messages propagate throughout the network faster than messages originating from one topological location.
A balancing attack specifically targeting LMD rules has also been proposed, which is considered feasible despite the proposer-weight boosting scheme. The attacker creates two competing chains by obscuring their block proposals and propagating each block to approximately half of the network, thereby creating an approximate balance between the forks. The colluding validators then vote ambiguously so that half of the network receives their votes for fork A first, while the other half receives their votes for fork B first. Since the LMD rule discards the second proof and keeps only the first proof for each validator, half of the network will only see A's vote and B's none, and the other half of the network will see B's vote and A's none. vote. The article's authors describe the LMD rules as giving an attacking opponent "extraordinary power" to launch a balancing attack.
This LMD attack vector has been closed by updating the fork-choice algorithm so that it completely drops ambiguous validators from fork-choice consideration. Ambiguous validators can also have their future impact reduced through fork-choice algorithms. This prevents the balancing attacks mentioned above while also remaining resilient to avalanche attacks.
5) Avalanche attacks
A March 2022 paper describes another type of attack called avalanche attacks. The authors of this paper believe that proposer-weight boosting schemes cannot protect against certain variants of avalanche attacks. However, the authors of the paper only demonstrated an attack on a highly idealized version of the Ethereum 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 blocks, allowing them to cause maximum chaos. This means that, for example, for 6 withheld blocks, the first honest block n competes with adversary block n to create a fork, and then all 5 remaining adversary blocks compete with the honest block at n+1 compete. This means that the forks establishing adversarial blocks n and n+1 now attract honest proofs because the weight of the honest chain is now equal to the weight of the adversary 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 an attacker has more opportunities to propose blocks during an attack, they can use those blocks to scale the attack so that the more validators involved in the collusion attack, the longer the attack lasts and more can be added Honest blocks are removed from the canonical chain.
The LMD part of the LMD-GHOST fork selection algorithm mitigates avalanche attacks. LMD means "last message driven", which refers to a table saved by each validator containing the latest messages received from other validators. information. This field will only be updated if new messages come from a later slot than a slot that already exists in the specific validator table. In practice, this means that in each slot, the first message received is the message it accepts, and any additional messages can be ignored. In other words, the consensus client uses the first arriving message from each validator, and conflicting messages are simply discarded to prevent avalanche attacks.
6) Finality delay
The same paper that first described a low-cost single-block reorganization attack also describes a finality delay (also known as "liveness invalidation") attack that relies on the attacker being the block proposer of the epoch boundary block. . This is critical because these epoch boundary blocks become the checkpoints used by Casper FFG to finalize various parts of the chain. The attacker simply withholds their block until enough honest validators vote for the previous epoch boundary block as the current finality target using their FFG. They then release the withheld blocks and certify their own blocks, and the remaining honest validators do the same, creating forks with different target checkpoints. If they time it just right, they will prevent finality because there won't be a 2/3 supermajority to certify either fork. The smaller the proportion of stake that the attacker controls, the more precise the timing needs to be, because the fewer proofs the attacker directly controls, the lower the chance that the attacker controls the validators that propose blocks at a given epoch boundary.
7) Notes on long range attacks
There is also a class of attacks specific to Proof-of-Stake (PoS) blockchains, which involves the validators involved in the genesis block maintaining a separate fork of the blockchain next to the honest blockchain, eventually convincing the honest validators to Switch to it at an appropriate time later. This type of attack is not possible on the beacon chain because "finality gadgets" ensure that all validators regularly agree on the state of the honest chain ("checkpoints"). This simple mechanism eliminates concerns about long-range attackers because Ethereum clients simply do not reorganize finalized blocks. New nodes joining the network are constructed by finding a trusted hash of the most recent state (called a weak subjectivity checkpoint) and using it as a pseudo-genesis block. This will create a "trust gateway" for the new node entering the network before it can start validating 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 the subjectivity is "weak". Because checkpoints are, by definition, shared by all nodes on the network, dishonest checkpoints are a symptom of consensus failure, at which point, no matter what, out-of-band social coordination must take over to save honest validators.
This all goes to show that it is very difficult to successfully attack the beacon chain with a small amount of stake. A viable attack described here requires an ideal fork-choice algorithm, as well as extremely unlikely network conditions, or that the attack vector has been closed with a relatively minor patch to the client software. Of course, we cannot rule out the possibility that zero-day vulnerabilities exist in the wild, but it does demonstrate the extremely high technical ability, knowledge of the consensus mechanism, and luck required by a small number of staking attackers to successfully pull off their attack. From an attacker's perspective, their best option may be to accumulate as much staked ETH as possible.
8) Denial of Service
Ethereum's PoS mechanism selects one validator from the set of all validators to serve as the block proposer in each slot. This can be calculated 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, the block proposer appears to be offline and the slot will simply become empty. This could be a form of censorship on specific validators to prevent them from adding information to the blockchain. The attacker's cost depends on the validator's bandwidth, meaning it is much cheaper to mount a denial-of-service attack on a home staker than a professional using industrial-grade hardware and an internet connection, making amateurs more vulnerable to censorship. There are some workarounds to this problem, but these also favor professional validators over home stakers. For example, running multiple nodes and separating block construction from network communication can provide an additional layer of protection because node identity and validator identity are decoupled. Node operators may switch identities or reacquire identities for a short period of time to avoid denial of service attacks. In the long run, implementing a single secret leader election (SSLE) or a non-single secret leader election scheme can more effectively mitigate the validator censorship problem, since only the block proposer will know that they have been selected, and their selection will not be known in advance . All validators submit their commitments to the secret into a pool that is repeatedly shuffled. A random commitment is then publicly elected, and only the chosen validator knows about it because the connection has been obfuscated. This work has not yet been implemented, but it is an active area of R&D.
The proportion of pledged equity controlled by the validator is greater than or equal to 33%
It is safer to spread control of staked ETH among more people than to concentrate it in the hands of a few. This is because the more stake a person controls, the greater their impact on the Ethereum consensus. All attacks mentioned in this article are more likely to succeed when the attacker has sufficient stake, and more validators may be selected 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, and if they control more than this amount of ETH, they have the ability to prevent the beacon chain from being finalized without having to fine-grained control over the operations of other validators. They can simply disappear all together. This is because for the beacon chain to be finalized, there must be 2/3 of the staked ETH to prove the pairs of checkpoints. If 1/3 or more of the staked ETH were maliciously proven or failed to prove, then a 2/3 absolute majority would not be possible. The defense against this is the beacon chain's inactivity leak mechanism, which is an emergency security measure that is triggered after the beacon chain fails to be finalized for 4 epochs. Inactivity leaks identify validators that fail to prove or prove contrary to the majority. The staked ETH owned by these non-proof validators will gradually drain away 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 allow the beacon chain to become final again, and the attacker will also lose a portion of the staked ETH. Assuming there is no slashable attack, and the attacking validator simply fails 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 is zero. When the inactivity leak mechanism is active, the inactive validator score increases by 4 and the active validator score decreases by 1 every epoch. Once the inactivity leak mechanism is deactivated (and the beacon chain is finalized again), the inactivity score of all active validators will be reduced. This takes longer for validators that have been inactive for longer periods of time because they have more inactivity points to burn. Continuous inactivity will consume inactivity points more slowly. For a validator that has been offline for 100 epochs, its inactivity score will reach about 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)
The inactivity score bias is the number by which the validator score is increased in each epoch, and the inactivity penalty quotient is the time it takes to reduce the balance of a non-proof validator to approximately 60% of its initial value. squared, the set time is approximately 37.5 days. This means that the longer an attacker prevents finality by failing to attest, the more their stake is burned. Upgrading Ethereum shows a graph that estimates the decrease in validator balances during and after a short (100 epochs, approximately 13.5 hours) negative penalty for a validator that is always offline. After 135 epochs, the validator's balance dropped from 32 ETH to 31.996 ETH, a loss of 0.004 ETH. For an attacker to control 33% of ETH staking, they would have to run approximately 144,000 validators, each holding at least 32 ETH. This means that their attack to delay beacon chain finality would cost at least 0.004 x 144000 = 576 ETH. At current market prices, this equates to approximately $1.09 million. Delaying the finalization of the Beacon Chain by half a day at a cost of nearly $1 million will have 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 will increase quadratically until the beacon chain starts finalizing again. The exact cost to an attacker of conducting a finality delay attack depends on their initial balance, how long they remain offline, and how long it takes to regain finality. The bottom line, however, is that continued inactivity of 33% of validators is extremely expensive even if validators are not slashed.
Assuming that the Ethereum network is asynchronous (i.e. there is a delay between messages being sent and received), an attacker controlling 34% of the total stake could trigger a double finality attack. This is because an attacker can equivocate when being selected as a block producer and then double-vote all validators at their disposal. This creates a situation where the blockchain forks, each of which has 34% of the staked ETH voting in support. Each fork only requires 50% of the remaining validators to vote in favor of both forks, thus gaining supermajority support, in which case both chains can be finalized (because 34% of 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 have some control over the time the message propagates on the network, such that they can match half of the honest validators The device is pushed onto 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. The attacker would have to destroy their entire stake (34% of the 14 million staked ETH today) to achieve this double finality attack because 34% of their validators would be double voting simultaneously, which is a A slashable attack with a maximum correlation penalty. The cost of defending against this attack is 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 fork and ignore the other. There are complexities associated with this kind of social support that we will discuss later.
The proportion of pledged equity controlled by the attacker is approximately 50%
In theory, if a malicious validator controls 50% of the staked ETH, he can split the Ethereum blockchain into two forks of equal size. Similar to the balancing attack described previously, an attacker can use only one of their validators by proposing two blocks for the same slot. Then, instead of manipulating half of the network by carefully transmitting messages, the attacker can simply use all 50% of their staking stake to vote against the honest set of validators, thus maintaining both forks and preventing finality. After four epochs, the inactivity leak mechanism will activate on both forks, as each fork will see half of its validators unable to attest. Each fork leaks the other half of the stake of the validator set, ultimately resulting in both chains finishing 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 a group of hostile validators will always control exactly 50% of the total stake, but perhaps there is a way that an attacker can exploit slightly more than 50% of the total stake. % of the stake, dynamically adjusting its voting ratio in each slot to maintain a perfect balance between the two forks. While the risk of a successful attack will undoubtedly increase with the proportion of staked ETH held by the attacker, the attack vector associated with 50% of the stake seems unlikely to be successfully exploited given the huge cost of launching such an attack. As well as a lower success rate, it appears to be a strong disincentive for rational attackers.
When the attacker controls more than 51% of the pledged equity, he can control the fork selection algorithm. In this case, the attacker would be able to vouch for a majority vote, giving them enough control to perform a short-term reorganization without having to trick honest clients. Controlling 51% of the stake does not allow an attacker to change history, but they have the ability to influence the future by applying a majority vote to a fork in their favor, or by reorganizing blocks. Honest validators will follow suit because their fork-choice algorithms will also consider the attacker's preferred chain 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 the maximum MEV by reordering blocks in their favor. As with Proof of Work (PoW) chains, 51% attacks are highly problematic. The defense against this problem is that due to the huge cost of majority staking (currently just under $19 billion), attackers face a huge risk that the social layer could step in and adopt an honest minority fork, making the attack The investor's pledged interests depreciated significantly.
The proportion of pledged equity controlled by the attacker is greater than or equal to 66%
An attacker controlling 66% or more of staked ETH can determine their 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 of stakers, the attacker will always control the contents of the final block. He has the power to spend, rollback, and spend again. He can also review certain transactions and reorganize the blockchain at will. By purchasing additional ETH to control 66% of the staking ratio instead of 51%, the attacker effectively purchased the ability to reorganize and finalize after the fact (i.e., change the past and control the future). The current cost of controlling 66% of the ETH staked stake is approximately $25 billion, and the only defense here is to fall back on the social layer to coordinate the adoption of alternative forks. In the next section we explore this in more detail.
Tier 0: The last line of defense
What happens when a blockchain’s coding defenses are breached and an attacker is able to end up with a dishonest blockchain?
This situation can arise in a number of ways, most notably when an attacker controls a majority of the staking stake, and can be accomplished simply through their own votes or additional attestation from more than 51% of honest validators. With control of 34% of the ETH staked, and some control over messaging on the network, the attacker was able to finalize both forks. In some cases, the recombination chain 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 be activated on both forks, and the question becomes, which honest or dishonest validator will regain first Finality? If honest validators finalize first, then the honest chain becomes the canonical chain, the fork choice algorithm for all clients on the network accepts the finalized portion of the chain, and Ethereum is back under the control of 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 of its history, and honest validators will eventually be punished.
A third, unlikely scenario is a permanent network split, where validators on one fork are somehow unaware of their counterparts on the other fork. This creates two independently determined forked chains, each of which leaks the staking stake of another set of validators. The two chains will then never come back together because they will have different final checkpoints. A vulnerability (rather than an attack) from a dominant client can also result in a broken but finalized chain. In terms of Ethereum's execution layer, the go-ethereum (Geth) client occupies a dominant position, with more than 85% of nodes running this client. In terms of the consensus layer, the Prysm client currently occupies a dominant position. After continued community activities, its proportion dropped to about 50%. Vulnerabilities in the lead execution client or consensus client could halt finalization or cause finalized data to be incorrect. On the Kiln testnet, a vulnerability in Prysm affected block production, which didn't matter since the nodes had roughly equal shares among four different clients, but if it were on the mainnet, there were over 66% of clients You will encounter the same error. Therefore, there will be several routes to a chain of dishonest finalizations, although their probability is very low. They all require a huge investment in staking ETH or very complex operations on the validator set, and as of now have only proven feasible under ideal conditions, and these attacks have been mitigated through software updates. However, we cannot rule out the eventuality that the ultimate solution is to rely on the social layer (layer 0).
One of the advantages of Ethereum's PoS consensus mechanism is that the community can adopt a range of defensive strategies when facing attackers. The minimal response might be to force the attacker's validator off the network without any additional penalties. To re-enter the network, an attacker must join an activation queue to ensure that the validator set gradually grows. For example, adding enough validators to double the amount of staked ETH takes approximately 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 part of the attacker's staked capital (up to 100%).
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 should Built on an honest alternative chain. Honest validators could collectively agree to build on a community-approved fork of Ethereum, for example the canonical chain might have been forked before the attack started, 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 would be an extremely messy governance challenge. Some users and validators will undoubtedly lose funds by switching back to the honest chain, and block transactions verified after the attack may be rolled back, thus disrupting the application layer, which completely shocks users who tend to believe that "code is law". Additionally, some users, perhaps even institutional users, who stand to benefit from dishonest blockchains through shrewd or serendipitous means, may oppose forks to protect their gains. There has been a call for the community to conduct drills to respond to staking attacks exceeding 51% so that reasonable coordinated mitigation measures can be quickly implemented. Vitalik has had some helpful discussions on ethresear.ch as well as on Twitter .
Governance is already a complex topic, and having an emergency Layer 0 response to a dishonest final chain will undoubtedly be a challenge for the Ethereum community, but this has already happened twice in Ethereum’s history. Ultimately, even if we have such an amazing technology stack, if the worst happens, the players in the community will have to coordinate a way out.
Summarize
This article explores some of the ways attackers may attack the beacon chain after Ethereum merges with the Proof-of-Stake (PoS) consensus mechanism. In general, the more proportion of staked ETH an attacker controls, the greater the chance of a successful attack, 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 greater the destructive power it can achieve:
1. 33%: Delayed finality
2. 34%: leading to double finality
3. 51%: Censorship and control of the future of blockchain
4. 66%: Censorship and control of the past and future of blockchain
There are also more sophisticated attacks that only require control of a small amount of staked ETH, but these require the attacker to have granular control over the timing of messages to tip the honest set of validators in their favor.
Overall, despite these potential attack vectors, the beacon chain poses very low risks, even lower than its equivalent proof-of-work chain. This is because attackers need to put the huge cost of staking ETH at risk in order to overwhelm honest validators with voting power. The built-in “carrot and stick” incentive layer prevents most malicious behavior, especially from low-staking attackers. More subtle bouncing and balancing attacks are also unlikely to succeed, as real-world network conditions make it difficult to achieve granular control over messaging for a specific subset of validators, and client teams have quickly shut down known ones with simple patches. 's bounce attack, balance attack, and avalanche attack vectors.
And 34%, 51% or 66% attacks may require community coordination to resolve. While this can be painful for the community, the community's ability to respond out-of-band is a powerful disincentive for attackers. The Ethereum social layer is the ultimate backstop, and a technically successful attack can still be stifled by a community that agrees to adopt an honest fork. Ultimately, there will be a race between attackers 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 socially coordinated attack.
The likelihood of profitability for the attacker will be low enough to act as an effective deterrent. This is why maintaining a cohesive social layer with aligned values is so important for crypto investing.
Translator's Note: As of now, the number of Ethereum coins pledged on the entire Ethereum network is approximately 14 million ETH, and the number of Ethereum coins pledged through Lido has reached 4.28 million ETH, which accounts for approximately 30.5% of the ETH pledge ratio. This is undoubtedly the biggest security risk for the Ethereum network. Therefore, Ethereum developers also recommend that pledgers disperse ETH into different protocols. In the face of Tornado Cash-level scrutiny, PoS chains like Ethereum may They are all relatively fragile, and as vitalik said, the social layer will be used as the last resort for recovery.
Original link:
https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs
**This article only represents the views of the original author and does not constitute any investment opinions or recommendations.
-END-
[The purpose of publishing articles is to disseminate more valuable information. The copyright of the article belongs to the original author. Its content and opinions do not represent the position of Unitimes. The pictures appearing on this WeChat platform are all collected from the Internet, and the copyright belongs to the copyright owner. If the copyright owner believes that his work is not suitable for everyone to browse or should not be used for free, please add WeChat uniforms2018 to contact us, and this platform will make corrections immediately. 】
Just click " Like " when you come.
