The Highs and Lows of Ethereum Gas Fees

In the Ethereum network, gas refers to the computational effort required to execute operations. The more complicated an operation, the more gas it requires. Gas prices, denominated in gwei, are volatile and change rapidly based on network demand. This can result in exorbitant transaction costs, which can erode profit margins for traders on platforms like Uniswap V3.

Periodically checking gas prices is cumbersome and does not guarantee that you will catch a low gas price moment. What if you're sleeping, busy, or just not at your computer? This was the problem that I, and undoubtedly many others, faced. Thankfully, there's a solution in the form of a bot that can automatically monitor gas prices and execute transactions when the cost falls within a predefined range.

Meet UniBot: Your Personal Ethereum Gas Tracker

UniBot is a Uniswap V3 swap routing bot that tracks gas prices and executes trades when a specified target is met. It is a simple, yet powerful tool developed for the very purpose of tackling the aforementioned problem.

Here's how UniBot works:

• Track Gas Prices: UniBot continuously monitors the Ethereum network's gas prices.

• Automate Swaps: When the gas price falls within your predetermined range, UniBot automatically executes a swap transaction on Uniswap V3.

• Notifications: After completing a transaction, UniBot sends an alert to your Mailchain inbox with the details of the swap and the associated gas price.

Getting Started with UniBot

Follow these steps to install and run UniBot on your machine:

Clone the repository:

git clone https://github.com/protocolwhisper/UNI-BOT-.git & cd UniBot

Install the dependencies:

yarn install

Create a .env file like this :

GAS_TARGET=The gas target that you want

ETHERSCAN_API_KEY=""

#Variables for trading

TOKEN_IN=""

TOKEN_OUT=""

POOL_FEE= MEDIUM

##Wallet Confiuration

PRIVATE_KEY=""

1. GAS_TARGET: This is the gas price (in Gwei) that you aim for. UniBot will only perform transactions when the gas price on the Ethereum network falls to or below this target value.

2. ETHERSCAN_API_KEY: This is your API key for Etherscan. Etherscan is a block explorer and analytics platform for Ethereum. UniBot uses Etherscan to fetch real-time gas price data.

3. TOKEN_IN: This represents the token you want to swap from. It should be the contract address of the ERC-20 token you want to swap.

4. TOKEN_OUT: This represents the token you want to swap to. Similarly to TOKEN_IN, it should be the contract address of the ERC-20 token you aim to obtain.

5. POOL_FEE: This value indicates the pool's fee tier on Uniswap V3. The MEDIUM value typically represents a 0.3% fee tier. Other possible values include LOW and HIGH for 0.05% and 1% fee tiers respectively.

6. PRIVATE_KEY: This is your Ethereum wallet's private key. UniBot uses this key to sign the transactions on your behalf. It's extremely sensitive data and should be kept secure.

Please note that these values should be filled with your actual data when running UniBot, except for POOL_FEE where you should pick a value that represents your preferred fee tier. Make sure to keep your .env file secure, especially the PRIVATE_KEY, as it can provide full access to your Ethereum wallet.

Run UniBot:

yarn run

We should expect an output like:

If you encounter any issues while running the tool, consider viewing this video tutorial, which provides a walkthrough of operating the tool and accessing the Mailchain notifications https://www.youtube.com/watch?v=-gz_CiwYzt8&ab_channel=protocolwhisper

Mailchain Notifications

UniBot uses Mailchain to send notifications about completed swaps and gas prices. Once a swap is executed, you'll receive an email notification containing the details of the transaction, such as the gas price used and the number of tokens swapped.

Contributing

Contributions, issues, and feature requests are welcome! Feel free to check the issues page.

Final Thoughts

UniBot serves as a brilliant solution to a pervasive issue in the world of Ethereum trading. It is open-source, free to use, and effectively automates a tedious process, thereby reducing the possibility of missed trading opportunities due to gas price fluctuations.

As developers and blockchain enthusiasts, we often have the power to not just identify issues but also create innovative solutions. With UniBot, I believe we've taken another small step in this direction. I'm excited to see how this tool can further evolve and continue to serve the trading community.

In the dynamic realm of open-source software, many hardworking developers are the unsung heroes behind crucial projects. Their tireless efforts ensure that vital libraries are well-maintained and continuously improved. However, providing these indispensable contributors with the fair recognition and remuneration they deserve has always been a formidable challenge.

Decentralized-BountyBoard, our project, was conceived to address this very issue. Our goal was to pioneer a unique, decentralized model that could transform the compensation system for these library maintainers. We envisioned a system that encourages innovation while also fostering a sense of fairness and appreciation.

Our first significant stride in this journey was the creation of the 'GitHub Oracle'. An open-source, decentralized bounty board, the GitHub Oracle mirrors the status of repositories on a blockchain. When an issue changes to 'merged', it triggers a function in a smart contract that initiates a payment process. This innovative mechanism does more than just reward the hardworking maintainers - it also drives transparency and paves the way for further innovation in our digital community.

Tutorial

In order to conjure up the Oracle magic let's see the structure

🛠️ Prerequisites:

Ensure you have the following:

• Docker compose⛵

• Yarn 🪄

🚀 Getting Started:

git clone https://github.com/protocolwhisper/Github-Oracle-BB.git

Let's go to the directory: ./oracletx/locklift/sample-project-typescript/ and execute

yarn install & npx locklift init -f & npx locklift build

We need to wait for the Locklift framework, which is somewhat similar to the Hardhat framework, but it's designed for TON blockchains.

To deploy the smart contract located in the src/contract folder, we must use Locklift

npx locklift run --network local --script scripts/1-deploy-sample.ts

Next, we need to create a .env file in the root directory, which includes the 'SC_ADDRESS: String'. This is obtained as an output from executing the previous command.

Currently, this process is strictly designed to interact with the Venom Blockchain. However, we plan to update the templates to make them compatible with EVM chains in the future.

1. To wake up the Oracle, simply run:

sudo ./initoracle.sh

This is when we need to have the docker-compose installed because this will setup for us all of the docker for and will build the images then we will have exposed the ports

We should see these ports open:

• 6379 (Redis Database)

• 8001 (Fast Api)

• 80 (Venom Node)

On port 80, we have our Dockerized node. You can access it using the /graphql route to view the available methods in the GraphQL playground. Additionally, you can use the /docs route to interact with the API methods, as shown in the picture below.

So now that our contract is on-chain we can create a bounty simulating the user need to create the bounty

npx locklift run --network local --script scripts/write-bounty.ts

2. To let the Oracle rest, use:

./stoporacle.sh

Be sure to be at the root directory

🔮 Interacting with the Oracle:

We need to interact with the REST API built so we can take a look at how to interact with this in the FastAPI docs, so for now let's do it with plain curl and params when calling the route.

Initiating the Oracle:

Send this request to get the Oracle started:

curl -X POST -H "access_token: 3e9bd24a88d140c29926d8c96453a39b" -H "Content-Type: application/json" -d 
'{
 "user_id": "your_user_id",

  "url_input": "https://example.com",

  "task_index": 1

}' http://localhost:8000/start

🔮 Querying the Oracle's task status:

Use the following request to inquire about the status of your bounty:

curl -X GET -H "access_token: 3e9bd24a88d140c29926d8c96453a39b" -G http://localhost:8000/status --data-urlencode "user_id=your_user_id" --data-urlencode "url_input=https://example.com"

Final thoughts

In conclusion, our Oracle system has shown promise but also has room for improvement. Feedback has highlighted trust issues due to our API's centralization. We're now exploring ways to transition to a decentralized model, without relying on another network or consensus for data replication. This is a complex task, but we're confident that with innovation and careful design, we can create a more trustworthy and independent decentralized Oracle system. ✨

Ethereum waits for two consecutive rounds where less than one-third of the stake is slashed before declaring a block final. Interestingly, Ethereum does not necessarily need to reach finality via Casper for it to function. It can continue operating using the GHOST protocol, maintaining a good probabilistic finality. Therefore, unlike most protocols utilizing a purely BFT-based consensus model, Ethereum would not freeze if a third of its validators go offline. However, Proof of Stake (PoS) systems are not immune to attacks, with the well-known long-range attack being a significant concern. In such an attack, an individual stakes a substantial amount for a specific period and then ceases staking. They then secretly create a fork from the point before they stopped staking. In this hidden chain, they can amass block rewards and slash other inactive validators, gaining a majority stake in their chain, thereby creating a chain heavier than the honest one. Addressing such attacks is challenging since the attacker would have ceased staking before they created the fork, making it hard to penalize them. While most online nodes would reject this new fork, new nodes joining the network or nodes returning after a lengthy offline period could unknowingly follow the attacker's chain. To tackle this, Ethereum introduces a slight level of subjectivity for nodes joining or rejoining the network. These nodes need to request an identifier from the most recent block in the honest chain to determine the correct fork to follow.

During each epoch, Ethereum randomly splits validators into 32 committees. Each committee is responsible for adding a block in their assigned time slot, with validators having to attest to a block during their time slot. The chain with the most attestations becomes the winning branch where new blocks should be added. Ethereum provides a robust protocol by combining the 'longest chain wins' rule with a BFT-based consensus model. Although complex, and despite some speed sacrifices compared to full BFT-based consensus methods, Ethereum's PoS consensus model excels in security and decentralization, making it one of the most secure PoS consensus methods currently available. If after two epochs, 67% of the vote is in agreement for both epochs and no slashing has been recorded for validators voting on multiple forks, the chain can be finalized. If this isn’t achieved, the chain will continue operating with probabilistic finality. Validators are expected to be slashed until the consensus can be achieved again. This mechanism underpins the consensus model in Ethereum.

Unlike most proof of stake protocols that operate under an honest majority assumption, Ethereum's model takes a different approach. Most protocols assume that as long as more than 51% of the stake is honest, the protocol is secure. Ethereum, on the other hand, assumes that more than 51% of the stake is economically motivated. This distinction is crucial as the honest majority assumption does not consider the potential of attackers bribing validators or users willing to reorganize the chain for Maximum Extractable Value (MEV) opportunities, such as significant arbitrage. Quantifying security against these kinds of attacks is inherently difficult, as it’s challenging to determine the exact amount required to bribe someone. Ethereum has implemented slashing mechanisms to address this issue. Slashing imposes a significant cost on any dishonest validator, providing a significant disincentive for malicious behavior. As a result, Ethereum's model is arguably one of the most secure proof of stake-based consensus methods currently available because it actively seeks to safeguard against attacks that other proof of stake-based protocols overlook. In conclusion, Ethereum has successfully integrated both a 'longest chain wins' strategy and a BFT-based consensus model. This combination results in a highly robust protocol, utilizing the strengths of both models: the speed of a 'longest chain wins' model and the finality offered by BFT consensus. While this complexity could increase the chance of bugs, and Ethereum has sacrificed some speed compared to fully BFT-based consensus methods, it compensates for this with a strong emphasis on security and decentralization. Through its innovative combination of models, Ethereum has established an incredibly secure proof of stake-based consensus method. This framework enables the platform to adapt to evolving security threats, ensuring its resilience in the dynamic landscape of blockchain technology. Despite the challenges it poses, Ethereum's approach to consensus offers an effective blueprint for enhancing the security and reliability of blockchain platforms. Moving forward, the Ethereum network continues to evolve and adapt. As we've seen, the consensus mechanism is an integral part of Ethereum's functionality and resilience. Nevertheless, the platform's commitment to innovation and improvement means that the consensus mechanism will continue to be optimized, with security, speed, and decentralization at the forefront of any enhancements. Ethereum's model offers valuable lessons for other blockchain networks. One of the most significant is the notion that an 'economically motivated' majority can provide a more robust safeguard than an 'honest' majority. By adopting an approach that anticipates potential issues such as validator bribing or users reorganizing the chain for personal gain, Ethereum is designed to be resilient in the face of these threats. Ethereum's model of consensus is also intriguing for its integration of different strategies. Its blend of a 'longest chain wins' approach with BFT-based consensus highlights the potential for hybrid models in enhancing blockchain security and efficiency. While the complexity of this model introduces potential challenges, the benefits it provides make it a compelling strategy for other networks to consider. Despite the potential for bugs due to its complexity, Ethereum’s consensus method has demonstrated robust resilience against various threats. By emphasizing security and decentralization over speed, Ethereum has set a high standard in the realm of proof-of-stake blockchain networks. While Ethereum’s method may not be the simplest or the fastest, it showcases the platform's commitment to creating a secure, reliable, and robust blockchain network. As blockchain technology continues to evolve, Ethereum’s innovative consensus mechanism will undoubtedly inspire other platforms to prioritize security and decentralization, promoting the growth and development of the entire blockchain ecosystem.

In conclusion, Ethereum’s consensus model not only fortifies the network's security but also demonstrates the potential for hybrid consensus mechanisms. Through this, Ethereum contributes significantly to the blockchain space, fostering a more secure and resilient future for decentralized technologies.

Remember our discussion about Casper and its impact on the blockchain world? It was quite insightful! Now, let's explore the GHOST and LMD-GHOST protocols, which have made significant contributions to bolstering blockchain performance and security. These protocols are more than just fancy acronyms; they offer robust features that have reshaped the blockchain landscape. By understanding their inner workings, you'll realize why they are considered game-changers. Additionally, familiarizing ourselves with GHOST and LMD-GHOST will provide a solid foundation for our next topic: Gasper, the powerful consensus mechanism driving Ethereum. Ready to delve into these protocols and uncover their significance? Let's begin!

In order to understand LMD GHOST, it is beneficial to first refresh our memory about what GHOST is. GHOST was presented as a new policy for selecting the main chain in the block tree. The primary improvement that GHOST introduced was in relation to the scenario of a 51% attack. In Proof of Work or Proof of Stake chains, an attacker only needs that amount of computational power or stake, respectively. With GHOST, however, the security threshold is 1, implying that an attacker would need to control all of the network resources (100%) to manipulate the chain successfully. This approach is applicable to the scenario where the network suffers from extreme delays, and it's not impacted by whether the attacker has low latency or faster block propagation. The proposed protocol modification allows for increased block creation rates and larger block sizes without the risk of a 50% attack. This ensures high transaction throughput security. The key insight is that even off-chain blocks can contribute to the overall weight of the main chain.

In Figure 1, the attacker creates a longer chain (1A, 2A, ..., 6A) in secret, surpassing the honest network's longest chain (ending at 5B). Faster block propagation would prevent such forks and keep the honest chain dominant. It is shown that blocks off the main chain can still contribute to its weight. The heaviest subtree protocol suggests assigning additional weight to blocks based on the support they receive from other blocks. This increases their chances of being part of the main chain and strengthens its structure, which inhibits the attacker from secretly creating a longer chain (1A, 2A, ..., 6A) as can happen with the longest chain rule.

We can define two terms then:

• Protocol Modification: Allows off-chain blocks to contribute to the main chain's weight, ensuring their inclusion.

• Block Weight: The significance or importance of a block within the network. Additional weight is assigned to blocks based on the support they receive from other blocks, which increases their chances of being included in the main chain. This strengthens the chain's structure and enhances network security.

What’s new?

The old definition states that each node selects the parent of its next block based on policy s(T), which identifies a block in T as the main chain. We're introducing a new protocol, a parent-selection policy, that redefines this main chain as the valid transaction history branch. In a block tree T, for a block B, "subtree(B)" is the subtree rooted at B, and "ChildrenT(B)" are blocks that directly reference B as their parent. We propose "GHOST(T)" as a new parent-selection policy, determined by a specific algorithm[1].

The algorithm

The Greedy Heaviest-Observed Sub-Tree (GHOST) algorithm works with a block tree (T) and aims to follow the path from the tree's root (genesis block) to the heaviest subtree at each fork, defining the main chain of the blockchain.

Here's a step-by-step breakdown of the process:

• Start with the genesis block (the first block in the blockchain) as B.

• If there are no children of B, return B and end the process.

• If there are children, select the one (C) with the largest subtree as the new B.

• Repeat step 2.

In practice, let's say you have two forks from a block, 1B with 12 blocks and 1A with 6 blocks. The algorithm chooses 1B because it leads to a heavier (larger) subtree. It will then resolve any forks inside this 1B subtree, selecting blocks leading to the heaviest subtrees. This process results in the choice of blocks 0, 1B, 2C, 3D, and 4B as the main chain. Note that this may not be the longest chain; it is the heaviest.

This algorithm is robust against an attacker trying to publish a secret chain since adding blocks to a subtree of an existing block (like 1B) only reinforces its position in the main chain. The main chain's composition remains unaffected even when an attacker introduces a 6-block secret chain.

Properties of the protocol:

• Convergence of History: Every block is eventually either fully adopted or abandoned by all nodes. The expected time for this convergence, represented by E[ψB] (which signifies the average time for block B to be either fully adopted or abandoned by all network nodes in the GHOST protocol), is finite.

• Resilience to 50% Attacks: If one waits for a significant period after a block's creation, the probability of its status changing from "accepted" to "abandoned" can be made arbitrarily small. In other words, GHOST is resilient to 50% attacks, even at high block creation rates or with substantial network delays.

• High-Security Threshold: GHOST has a security threshold of 1, meaning an attacker would need to control the entire network to threaten its security. This is a distinct advantage over some other protocols which have a lower security threshold.

• Rapid Collapse: In GHOST, the 'collapse' time (the point at which all nodes agree on the block history) tends to be quick, reducing waiting times for network confirmations and transaction authorizations.

We can see deep explanations and proof of these statements in [1].

Comparison of the main chain growth in GHOST and Longest-Chain protocols

The comparison uses two approaches: analytical bounding and network simulation.

• A Lower Bound: The lower bound is established based on a sub-network with computational power α. For the Longest-Chain rule (Lemma 5), the main chain grows at a rate of β(λ) ≥ 1 + λ/λ ·D. For the GHOST rule (Lemma 6), the main chain grows at a rate of β(λ) ≥ 1 + 2λ/λ ·D. These bounds are achieved in a decentralized network.

• Application to Throughput (Under Longest-Chain): The understanding of network topology can be used to guarantee security and throughput. An achievable throughput equation is provided based on the block creation rate and delay diameter. Higher throughput would require full knowledge of the network’s topology, which is currently difficult to measure in the Bitcoin network.

• Application of the Bound to GHOST (Efficiency): While the security threshold in GHOST is always 1, implying no security constraint, throughput cannot grow indefinitely as the transmission of many blocks consumes bandwidth. The ratio βλ serves as a measure of network efficiency in resource utilization. An efficiency equation is provided, showing that the network can process a certain number of transactions per second while maintaining an efficiency threshold.

• An Upper Bound: The upper bound is established by locating a network partition such that blocks take a certain time to cross the partition. This creates inefficiencies as the communication delay may cause forks. Theorem 9 gives the upper bounds for both the Longest-Chain and GHOST protocols, suggesting that the main chain's growth rate is bounded by a complex formula that involves the computational power distribution and delay.

What’s LMD GHOST?

The Latest Message Driven GHOST (LMD-GHOST) is a variant of the GHOST protocol and is based on the validators' votes (also known as attestations). In this protocol, each validator creates an attestation for the block it thinks should be added to the chain. The block that is referenced by the most recent message (latest attestation) from each validator is chosen. In the case of a tie, the hash of the block header is used as a tie-breaker[2].

Definition

The LMD-GHOST rule is a fork-choice rule used in blockchain protocols, notably Ethereum 2.0. Its purpose is to help nodes in the network to decide which chain they should extend when they have a choice.

The algorithm operates on the concept of blocks in a blockchain, validators that attest or vote for certain blocks, and weights assigned to blocks based on these attestations.

The algorithm

It starts with the genesis block - the first block in a blockchain. Then, it continuously steps forward in the blockchain from this genesis block, always choosing the child block that has the greatest weight.

The weight of a block is the sum of the stakes of the validators who have attested to that block or its descendants. A validator's stake is essentially the amount of cryptocurrency they have locked up as collateral in order to participate in the consensus protocol. In essence, the block with the most stake behind it (either directly or through its descendants) is considered the heaviest and is the chosen path. The process continues until it arrives at a block with no children, meaning we're at the end of a chain. This block is returned by the algorithm as the head of the canonical chain according to the LMD-GHOST rule. This rule works on the basis that the more stake there is behind a block (directly or indirectly), the more likely it is to be included in the canonical chain. This creates an incentive for validators to attest to the block they see as having the most stake behind it, making it less likely that the network will be split over which block should be next in the chain[3].

Conclusion

In conclusion, our exploration of the GHOST and Longest Chain rules, as well as the adaptation of LMD-GHOST, illuminated the complexities and nuances in managing blockchain growth, fork resolution, and overall system security.

We found that the GHOST protocol, particularly its LMD variant, offered compelling advantages over the Longest Chain rule. LMD-GHOST's use of validator attestations to dynamically weigh branches led to a more equitable and security-focused blockchain growth. However, it's critical to note that the appropriate choice of protocol ultimately depends on the specifics of the network, including its size, transaction volume, and inherent topology.

Furthermore, understanding and fine-tuning the main chain growth rate under each rule elucidates critical insights into network security, throughput, and resource utilization, paving the way for more robust and efficient blockchain networks.

Our analysis underlines the vital role of informed protocol selection and configuration in optimizing blockchain functionality, and we anticipate that further research in this domain will continue to enhance the safety, efficiency, and scalability of blockchain technology.

References

[1] Y. Sompolinsky and A. Zohar, "Secure high-rate transaction processing in Bitcoin," in Financial Cryptography and Data Security, Berlin, Springer, 2015, pp. 507-527.

[2] V. Zamfir, "Introducing Casper 'Correct-by-Construction'," 2018. [Online]. Available: https://github.com/ethereum/research/blob/master/papers/cbc-consensus/overview.pdf.

[3] V. Buterin and V. Griffith, "Casper the Friendly Finality Gadget," arXiv preprint arXiv:1710.09437, 2017.

Glossary

• G=(V, E): This notation represents a graph. In this context, it refers to a network graph where V represents the set of vertices (or nodes) and E represents the set of edges (or connections between nodes).

• λ: Lambda in this context is used to represent the rate at which blocks are generated in the network.

• α: Alpha represents the fraction of the computational power of the entire network that is contained within a particular sub-network.

• D: This symbol stands for the delay diameter, which is the maximum time it takes for a block to propagate across the network.

• β(λ): Beta of lambda represents the rate of growth of the main chain with respect to the block generation rate λ.

• pS, pT: These represent the fraction of computational power owned by nodes in partitions S and T of the network, respectively.

• d{s,t}: This represents the delay for a block to cross from one partition of the network to another.

GM :) , developers. If you're eager to delve into the workings of Ethereum 2.0, contribute to Ethereum, build MEV bots, or create anything that bolsters the network's security, then this series is indispensable.

This three-part series unravels the intricacies of Casper FFG, LMD GHOST, and Gasper - the consensus protocols that form the bedrock of Ethereum's architecture. We start our exploration with Casper FFG, proceed to LMD GHOST, and conclude with Gasper, the heart of Ethereum 2.0. By understanding these complex systems, you'll be better equipped to contribute to Ethereum's ecosystem, develop efficient MEV bots, or devise robust security solutions. Let's embark together on this enlightening journey through Ethereum's consensus protocols.

The protocol

To make things clearer, let's presume we have a fixed set of validators and a proposal mechanism (like a PoW mechanism) that generates child blocks from existing ones, forming an ever-expanding tree. The starting point for this is usually called the "genesis block."

Normally, we'd anticipate one child block originating from one parent block. However, issues like network latency and intentional attacks might cause the mechanism to create multiple child blocks from a single parent. This is where Casper steps in - it assists us in selecting the correct child block, helping us create the final canonical chain (the chain that’s more likely to be accepted by all validators).

Casper, aiming for efficiency, concentrates on the checkpoints tree instead of the entire block tree see Fig2. The genesis block is a checkpoint, and all block heights or numbers that are multiples of 100 will also be checkpoints. The "checkpoint height" of a block with a block height of K*100 is simply K. Similarly, the height h(c) of a checkpoint 'c' is determined by the number of elements in the checkpoint chain from 'c' to the root.

Every validator, as a condition of joining the chain, makes a deposit. This deposit may increase due to rewards or decrease due to penalties. The security of the PoS system hinges on the total amount deposited. So, when we mention "⅔ of validators," we're referring to "⅔ * the total amount deposited on the chain."

Validators can broadcast a message as follow:

Fig 1. Structure of a single vote.

Let’s define some terms:

• Supermajority Link: An ordered pair of checkpoints (a, b), or a → b, is termed a supermajority link if at least two-thirds of validators, by deposit, have issued votes with source 'a' and target 'b'. These links can bypass checkpoints, implying that the height of 'b' can exceed that of 'a' by more than one see Fig 2.

• Conflicting Checkpoints: Two checkpoints, 'a' and 'b', are considered conflicting if they are situated in separate branches, indicating that neither is an ancestor nor a descendant of the other.

• Justified Checkpoint: A checkpoint 'c' is considered justified if it is the root, or if there is a supermajority link from a justified checkpoint to 'c' (c0 → c).

• Finalized Checkpoint: A checkpoint 'c' is deemed finalized if it is the root, or if it is justified and there is a supermajority link from 'c' to its direct child (c → c0). Therefore, a checkpoint is finalized if and only if the checkpoint is either the root or a justified checkpoint with a supermajority link to its direct child.

  

Fig 2. Block tree with height and supermajority links.

The dotted lines represent 99 blocks

Casper commandments

Fig 3. Casper commandments

Note: Equivalently, a validator must not vote within the span of its other votes. Any validator who violates either of these commandments gets slashed.

The most notable property of Casper is that two conflicting checkpoints cannot be finalized unless >= ⅓ of the validators violate the two rules above. If a validator violates the conditions, their entire deposit is forfeited, with a minor "finder's fee" provided to the individual who submitted the evidence transaction[2].

Proving Safety and Plausible Liveness

Accountable Safety: This principle implies that two conflicting checkpoints can't both be finalized unless at least one-third of the validators breach a slashing condition, which would result in the loss of at least one-third of the total deposit.

Plausible Liveness: This means that, no matter what has occurred in the past (e.g., slashing events, delayed blocks, censorship attacks, etc.), if at least two-thirds of validators follow the protocol, it's always possible to finalize a new checkpoint without any validator violating a slashing condition.

Assuming that less than one-third of the validators (by weight) violate a slashing condition, the following properties are derived:

1. If there are two distinct supermajority links (s1 → t1 and s2 → t2), then the heights of t1 and t2 are not equal.

2. For two distinct supermajority links (s1 → t1 and s2 → t2), the inequality h(s1) < h(s2) < h(t2) < h(t1) can't hold true.

From these two properties, we can immediately see that, for any height n:

1. There's at most one supermajority link s → t with h(t) = n.

2. There's at most one justified checkpoint with height n.

With these four properties in hand, we move to the main theorems. We can see the proof of this in [1], but for now, let's assume this to be true.

Theorem 1 (Accountable Safety): Two conflicting checkpoints, am and bn, cannot both be finalized.

Theorem 2 (Plausible Liveness): Supermajority links can always be added to produce new finalized checkpoints, provided there are children extending the finalized chain[3].

Casper fork choice rule

Casper is more complicated than standard PoW designs. This is because if users, validators, or block-proposers follow the standard PoW fork choice rule of "always build on top of the longest chain," there are related scenarios where Casper can get "stuck." In such cases, any blocks built on top of the longest chain cannot be finalized or even justified without some validators altruistically sacrificing their deposit. So, the new fork choice rule is: Follow the chain containing the justified checkpoint of the greatest height.

Enabling dynamic validators set

The set of validators needs to be able to change. New validators should be able to join and existing validators must be able to leave. To accomplish this, we define the dynasty of a block (b) as the number of finalized checkpoints from the root to the parent block b. When a potential validator's deposit is included in a block with dynasty "d," this refers to a number that is determined by the sequence of finalized checkpoints in the blockchain. So, when a deposit is included in a block with dynasty "d," it means that the deposit is acknowledged and accepted. However, the validator does not immediately join the active validator set. Instead, they will join the validator set at the first block with dynasty "d + 2". We call "d + 2" this validator's start dynasty, DS(ν).

A validator must issue a "withdraw" message to exit the validator set. If this message is included in a block with dynasty 'd', the validator will exit at the first block with dynasty 'd + 2’, termed the validator's end dynasty. If a withdrawal message has not yet been included, then DE(ν) = ∞. Once a validator leaves, their public key is permanently banned from rejoining the set, simplifying the management of dynasties. At the start of the end dynasty, the validator's deposit is locked for a substantial duration, known as the withdrawal delay, before it can be withdrawn. This delay is approximately equivalent to the time span of "four months' worth of blocks". If the validator breaches any rules during this withdrawal delay, their deposit is subject to slashing.

We define two functions that generate two subsets of validators for any given dynasty 'd' the forward validator set and the rear validator set. They are defined as follows:

Fig 4. Validators set

It is important to note that the forward validator set of dynasty 'd' is identical to the rear validator set of dynasty 'd + 1', as expressed by Vf(d) = Vr(d + 1). To accommodate these dynamic validator sets, we need to redefine a supermajority link and a finalized checkpoint as follows:

For an ordered pair of checkpoints (s,t), where 't' is in dynasty 'd', a supermajority link between (s->t) can be established if:

• At least two-thirds of the validators from Vf(d) have published votes from 's' to 't'

• At least two-thirds of the validators from Vr(d) have published votes from 's' to 't'

• A checkpoint 'c' is considered finalized if and only if the votes for the supermajority link from 'c' to 'c’', as well as the supermajority link justifying 'c', are included in 'c’s' blockchain and appear before the child of 'c’'. We assume this to be before h(c’)*100 + 1.

The forward and rear validator sets usually have significant overlap. However, if these two validator sets diverge substantially, this "stitching" mechanism prevents a safety failure. Such a failure could occur when two grandchildren of a finalized checkpoint have different dynasties because the evidence was included in one chain but not in the other.

Mitigating attacks

There are two notorious threats to proof-of-stake systems: long-range revisions and catastrophic crashes. Let's tackle each one:

Long-Range Revisions

Our preventive mechanism thwarts long-range revision attacks by ensuring that validators who have withdrawn their deposits can't manipulate finalized checkpoints. This is achieved through a combination of measures:

Fork Choice Rule: By ensuring that finalized blocks are never reverted, we prevent malicious validators from rewriting history.

Synchronized Clocks: With all clients maintaining synchronized clocks, we ensure consistent time comparisons and ward off manipulation of timestamps.

Timestamp-based Rejection: We reject blocks with future timestamps or those too far in the past, making sure that any evidence of slashing is included promptly.

Withdrawal Delay: Validators must endure a specified withdrawal delay before they can receive their deposits back. If this delay exceeds four times the maximum communication delay, any validator attempting malicious actions stands to lose their deposit.

Any disagreements among clients regarding the timing of slashing evidence are treated as liveness failures rather than safety failures. It's already acknowledged that a compromised proposal mechanism can hinder finality. Therefore, the possibility of disagreement doesn't weaken the security claims of the protocol.

Catastrophic Crashes

In the unfortunate scenario of catastrophic crashes, where a substantial number of validators fail simultaneously, the system could be left without supermajority links, impeding the finalization of future checkpoints. To combat this, we introduce a mechanism called "inactivity leak." This feature gradually depletes the deposits of validators who neglect to vote for checkpoints until the remaining active validators constitute a supermajority.

The most straightforward formula for the inactivity leak involves subtracting a fraction, denoted as "p" (0 < p < 1), of a validator's deposit size, D, for each epoch in which they abstain from voting. To counteract catastrophic crashes more effectively, the leak rate may escalate if a streak of non-finalized blocks continues.

This consensus protocol does not delve into the exact treatment of the drained ether, whether it should be incinerated or returned to validators, nor does it specify the exact formula for the inactivity leak. These issues pertain more to economic incentives than Byzantine-fault-tolerance.

The inception of the inactivity leak creates a scenario where conflicting checkpoints can be finalized without directly slashing validators. Subset VA, voting on chain A, will witness deposits leaking from subset VB, and vice versa. Consequently, each subset will possess a supermajority on their individual chains, culminating in the finalization of conflicting checkpoints without explicit slashing. In such cases, validators are recommended to prioritize the finalized checkpoint they detected first.

This consensus protocol concedes that the exact algorithm for rebounding from such assaults remains an unsolved problem. Currently, the expectation is that validators can discern blatantly malicious behavior and manually trigger a "minority soft fork." This minority fork operates as a standalone blockchain that rivals the majority chain on the market. If conniving malicious attackers gain control of the majority chain, the expectation is that the market will lean towards the minority fork. The recovery mechanisms for catastrophic crashes, the handling of leaked deposits, and the algorithm for managing such attacks are topics that warrant further investigation and research.

Conclusion

In conclusion, the Casper consensus protocol introduces a novel approach to blockchain consensus systems. Its unique features, such as the implementation of dynamic validator sets, the establishment of supermajority links, and the use of a checkpoint-based system, greatly enhance the robustness of the overall network. The protocol's emphasis on accountable safety and plausible liveness also ensures a high degree of reliability, even in complex and uncertain network conditions.

However, despite its innovative mechanisms, Casper doesn't fully address all challenges inherent to proof-of-stake systems. Issues such as managing catastrophic crashes and appropriately treating drained deposits remain areas that require further exploration. While Casper's approach to these challenges is promising, the protocol's limitations emphasize the need for continued research and development in the field of blockchain consensus systems.

References

[1] V. Buterin and V. Griffith, "Casper the friendly finality gadget," arXiv preprint arXiv:1710.09437, Oct. 25, 2017.

[2] Vasin, P. Blackcoin’s proof-of-stake protocol v2 (2014). URL http://blackcoin.co/ blackcoin-pos-protocol-v2-whitepaper.pdf.

[3] Bentov, I., Gabizon, A. & Mizrahi, A. Cryptocurrencies without proof of work. In Sion, R. (ed.) International Conference on Financial Cryptography and Data Security, 142–157 (Springer, 2016). URL http://www. cs.technion.ac.il/~idddo/CoA.pdf.