Ethereum GASPER explained in simple terms
Ethereum is migrating to the Proof of Stake consensus mechanism with Ethereum 2.0. Gasper is the actual consensus protocol that secures the Ethereum PoS chain. This blog post will explain the main ingredients of Gasper in a simpler way. This information is taken from Vitalik Buterin’s research paper “Combining GHOST and Casper” and Ethereum.org Docs.
Chapter 1: Introduction
In Ethereum 2.0 Beacon chain, Gasper defines incentives and penalties for validators. It determines which blocks should be accepted and which ones should be rejected, as well as which fork of the blockchain should be used. Therefore, it is a complete consensus protocol or mechanism to secure Ethereum PoS chain. Gasper is the combination of two mechanisms: Gasper is the combination of two mechanisms:
(1) Casper the Friendly Finality Gadget (Casper FFG): It is a gadget that sits on top of an existing blockchain and marks certain blocks as finalized. By finalizing blocks, blockchain users can be assured that those blocks are part of the main (or canonical) chain and won’t be reverted (or removed) from it. Practical blockchains always have probabilistic finality. As the main chain grows, we become more certain that a block will be finalized, but we can never be 100% certain. (More on finality in another post).
(2) LMD GHOST: Latest Massage Driven Grediest Heaviest Observed Sub-tree (LMD GHOST) is a fork-choice rule that allows choosing among many forked chains. For example, if there are two different forks in a chain. Let’s say fork-1 is B_a ← B_b ← B_f ← B_g ← B_h and fork-2 is B_a ← B_b ← B_c ← B_d ← B_e, where B is block (illustrated in Figure 1). The LMD GHOST will pick one of them, say it picks fork-1.
LMD GHOST assists in picking the fork with the greatest accumulated weight of validator votes (more on this later). This mechanism gives a kind of law or a rule to asses the main chain.
Chapter 2: Setup
2.1 Validators and Blockchain
Validators (denoted by 𝓥) are those entities who participate in the protocol for data validation purposes. To become validators, validators must stake a certain amount of ether (currently 32 ETH) on the Ethereum 1.0 PoW chain. In order to limit the number of new validators, validators are pushed into an activation queue after depositing the required amount. Validators are responsible for proposing and attesting blocks. Attesting means voting that a certain block is valid. Validators are connected via a peer-to-peer network. Therefore, blocks are special kinds of messages among other types that can be broadcasted between validators.
In essence, blockchain is just a distributed network with specific conditions such as a network of validators and a consensus mechanism. Essentially, blockchain blocks act as registries for the state or history of the blockchain. The genesis block is the first block in the chain. The subsequent blocks are connected to their ancestor or parent blocks, forming a chain as depicted in Figure 2. A block can only have one unique parent, while the genesis block does not have one. Blocks could be contradictory, for example, one block may say that Bob owns a coin, while another block says Carol owns it as depicted in Figure 4. A conflict between blocks may occur as a result of network errors, latency, or malicious entities trying to sabotage the system. The consensus mechanism is commonly used to prevent and eradicate such issues from the blockchain by determining which blocks are correct based on the chain’s history.
2.2 Messages and Views
We have discussed validators communicating via peer-to-peer networks and broadcasting messages to each other. When an honest validator V broadcasts a message M, we assume M is sent to all validators on the network. It is possible for a malicious validator to not send any messages in order to sabotage the system or censor some information that he wishes to use for his own gain. From Vitalik’s paper:
The main type of message proposes a block, which is a piece of data, to the network. Other messages can be bookkeeping notices such as voting for blocks (“attestation”), putting new validators on the blockchain (“activation”), proving bad actions of other validators (“slashing”), etc. depending on the specific protocol. We assume that each message is digitally signed by a single validator, which means we can accurately trace the author of each message and attacks such as impersonation of honest validators are not possible.
Considering a perfect network in which latency issues are absent and malicious actors do not exist, we can assume that all validators are aware of every message broadcast across the network. Each validator has a set of messages that are the same for all others. Validators have full knowledge of the network’s state. However, in practice, latency issues and dishonest validators can affect the process. If that is the case, each valdiator may have different messages, and not all valdiators know the state of the network completely.
It is possible for a message to depend on one or more other messages, called dependencies. A block, for example, is a special type of message with a parent block. The parent block is a dependency of that block. Messages are accepted by a validator if all of their dependencies have already been accepted by him. In that context, we can define view(V, T) to be the set of accepted messages that the validator has seen up to this point. The Network can also be treated as a virtual validator that accepts all messages broadcast to it from any validator at any time without any latency, denoted as view(NW, T). Therefore, view(V,T) ⊆ view(NW, T), means that a validator’s view is always a subset of the network’s view. The notion of time T can also be dropped since we are implicitly discussing a specific point in time T at any time and call the view(V,T) and view(NW,T) just view(V) and view(NW) unless we need to explicitly discuss another point in time. From Vitalik’s paper:
Example: At time T, suppose validator V sees the message M with content “Yunice sends coin number 5340 to Bob,” but has not yet seen the message M’ containing “Yunice obtains coin number 5340” (which is on the network but has not yet made its way to V ). Also suppose that in our protocol M depends on M’ (and no other message), which captures the semantic meaning that we need to obtain a coin before spending it, and that V cannot and should not act on M without seeing M’ . In this situation we say that V has seen but has not accepted M, so M∉ view(V, T). However, the network has seen both; so if the network accepts M’ , we have M ∈ view(NW, T). This example is depicted in Figure 5 (not available in the paper).
Some assumptions can now be made about the views:
- The network initiates with a single message not signed by anyone and accepted by all called the genesis block, also known as B_genesis. Genesis block has no dependencies.
- Other than B_genesis, every other block has a parent block. For example, edge B ← B’ means B’ depends on B and B is an ancestor or parent of B’. Therefore, a view(V) can be visualized as a directed acyclic graph (or a directed tree). Blocks with no children are leaf blocks.
- The chain of blocks is formed by pairwise parent-child edges. For example, B_genesis ← B_1 ← B_2 ← B_3. A descendant block is any block that is not a direct child of another block. In the previous example, B_3 is a descendant of B_genesis.
- Blocks B and B’ conflict if they are different blocks (describing different states of the chain) and neither is a descendant of the other.
- Each block B defines a unique chain from B_genesis to B, denoted by chain(B). Validators who accept B must have the same chain(B) in their view(V).
Note: This blog post is not finished yet, I’ll keep updating it. Be sure to check the post periodically. Leave any queries or comments below.