Paradigm introduces Goldfish: a secure alternative to the LMD GHOST fork rule in PoS Ethereum

Merge: From Proof of Work to Proof of Stake

Ethereum is about to transition from Proof of Work (PoW) to Proof of Stake (PoS), the culmination of years of research and development. Although PoS brings many potential advantages, it also means that Ethereum is abandoning Satoshi Nakamoto ‘s most “long love” protocol – certainly one of the simplest and most elegant consensus protocols, and has passed the centralized zone The practical test of blockchain.

A well-known vulnerable component of the Ethereum PoS consensus protocol has been shown to be the “LMD GHOST” choice fork rule, and its security remains unproven after multiple attacks and patches recently.

In an article titled “PoS Ethereum No Longer Attacked?”, we propose Goldfish, a provable, secure alternative to LMD GHOST’s choice fork rules in PoS Ethereum. We believe this is just the first step towards more rigorous protocol design and analysis to strengthen Ethereum’s security.

Ethereum’s Proof of Stake Protocol

Ethereum’s Proof of Stake (PoS) consensus protocol is much more complex than PoW.

It’s actually a combination of two different consensus protocols: a “finality gadget” (called Casper FFG) that finalizes blocks after a 6.4 minute long epoch, and a fork of choice that governs the chain within each epoch -choice rule (called ” Greedy Heaviest Observed Subtree “, or LMD GHOST for short). These two components interact with each other in complex ways, which are depicted in block diagrams below:


Specifically, LMD GHOST guides the block production process and runs with a 12-second time slot combined with a sub-sampling of validators. As such, it can be thought of as responsible for a weaker “short-term consensus” prior to PoS Ethereum block rewards. Once a short-term consensus is reached on the transaction ledger, it is handed over to Casper FFG for additional hardening, which operates on a timescale of 32 slots = 6.4 minutes and involves the full set of validators. Therefore, Casper FFG is responsible for providing a stronger “long-term consensus”, providing finality and responsible security.

Unfortunately, this complexity comes with challenges. In particular, the LMD GHOST component, as well as the interaction between LMD GHOST and Casper FFG, are subject to repeated attacks and patches. The currently adopted protocol for Merge has neither public attacks nor formal security analysis/proofs.

The lack of security proofs is cause for concern, but not because proofs in simple academic models necessarily perfectly demonstrate real-world security. Conversely, our inability to conclusively explain why this protocol is secure, even in the simplified model, suggests that we don’t actually understand the protocols, or the full scope of their consequences and interactions.


In an article titled “PoS Ethereum No Longer Attacked?”, we provide an alternative to PoS Ethereum’s LMD GHOST fork choice rule. Called Goldfish, the protocol is similar to LMD GHOST (so no major overhaul of current client implementations is required), but with proofs of security.

To better understand Goldfish, let’s first preview how LMD GHOST works:


Suppose the maximum delay caused by messages in our simplified network model is a known value of A (as in △ in the figure above). In LMD GHOST, a similar procedure yields a value of 2A. For each gap, a proposer and a small committee of validators are randomly selected from the full validator set. At the beginning of each slot, the proposer of the slot runs the LMD GHOST fork choice rule (with two modifications, “proposer boost” and “ambiguous discount”, which are patches in response to two earlier attacks) to determine the canonical The blockchain rewards and proposes a new block.

Halfway through the slot, the board members of the slot also use the same fork choice rules to determine the canonical block reward and vote for that reward. Instead of specifying confirmation rules, LMD GHOST lets users decide which blocks of the block tree have “enough” votes to be confident they won’t leave the canonical chain.

Goldfish closely follows this general structure, but introduces an additional phase for validators to synchronize their views on vote counts and confirm blocks:


At the beginning of each slot, the proposer of the slot runs a simple GHOST fork-choice rule based on the votes of the previous slot to determine where to propose a block. When entering a third of the slot, committee members for that epoch use the same fork-choice rule, which determines where to vote based on the votes from the previous epoch and the votes forwarded by the proposer. Finally, when entering two-thirds of the slot, all validators run a well-defined T-depth confirmation rule.

Goldfish is based on two key techniques, vote buffering and vote expiration, to carefully synchronize the views of honest validators:

  • Voting buffering (also known as view merge, first appeared on the new consensus protocol Highway). In short, buffering votes received from the network, and carefully timed inclusion of these votes in each validator’s local view, guarantees that in a slot with honest proposers , all honest validators vote for the proposer ‘s proposal. This leads to reorganization resilience: proposals from honest proposers are guaranteed to remain in the canonical chain. With that comes security (that is, the security and liveness of the output ledger).
  • Voting expiration (also known as provisional voting) means that within each slot, only the previous slot’s vote affects the behavior of the protocol (similar to the “forgetful” goldfish, from which the Goldfish protocol name derives). Voting expiry makes the voting set small, which may affect the short-term future actions of honest validators. Therefore, at any point in time, only a few protocol messages need to be buffered and merged in the view of honest validators. Therefore, voting expiration is a prerequisite for the efficiency/feasibility of the voting buffer. Voting expiry is also critical to support fluctuating levels of validator participation and to support running the protocol in a smaller subsample of voter committees per slot, rather than the entire validator set.

Finally, Goldfish’s confirmation rules confirm whether a block is still on the canonical chain some time after it was created. Analysis shows that the resulting confirmation flip probability decreases exponentially in the delay between block production and block confirmation.

Challenges for Goldfish: Asynchrony

Goldfish is simple and accepts rigorous security proofs. This analysis paid off immediately: keep in mind that we started by assuming that the network latency in our simplified model is capped at A (denoted by △ in the figure above). In the process of proving security, we must make this and other assumptions explicit.

What happens if this bound is violated, i.e. if the network is temporarily asynchronous? We can trace the steps of the security argument and see what goes wrong without the assumptions. We see that if the actual network latency is greater than 2A (that is, 8 seconds in current PoS Ethereum), then Goldfish will not be able to get the decisive vote for slot (t-1) in time to build on slot t, the protocol may will be affected by the reorganization.

Such a reorganization is not good. But at least thanks to rigorous security arguments, we can better understand what conditions our system’s security critically depends on, and why and how. We can make more informed decisions to ensure these prerequisites are met. For example, while in current peer-to-peer network protocols it may be easier for attackers to cause some network latency, there has recently been (also due to network-related data availability sampling challenges) renewed interest in hardened peer-to-peer protocols that re-enable consensus The stake distribution of the layer guides the selection of peers. Such a protocol is more resistant to attacks and can reasonably mitigate latency issues. In addition, certainty/accountability gadgets (which may eventually be further accelerated by “single-slot determinism”) underpin any restructuring.

what else needs to be done

We propose the Goldfish consensus protocol, intended as a replacement for LMD GHOST in the PoS Ethereum beacon chain. We did a rigorous security analysis of Goldfish itself, combined with endgame/accountability gadgets (based on another consensus protocol such as HotStuff). Other PoS Ethereum consensus security challenges remain, for example, from fork choice and the interaction of finality gadgets, and we look forward to seeing further consensus security improvements for PoS Ethereum in these areas in the future.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-09-12 00:09
Next 2022-09-12 00:11

Related articles