Model Checking of Rewards and Penalties in Beacon Chain

Abstract

Ethereum 2.0 Beacon Chain has adopted the Proof of Stake (PoS) consensus mechanism to significantly advance the security, scalability, and decentralization of blockchain technology. It has played an integral role in organizing validator operations and addressing scalability issues. The Beacon Chain’s rewards and penalty system incentivizes honest behavior and penalizes dishonest actors inside the network. Ensuring the correctness of this mechanism is paramount for guaranteeing the system’s integrity. Therefore, this work formally verifies the rewards and penalty mechanism in the Beacon Chain using model checking, a formal methods-based technique. The formal specification of the rewards and penalties processes and several other epoch operations are described using the Communicating Sequential Programs (CSP#) language. The properties for rewards and penalties procedures are specified with Linear Temporal Logic (LTL). The Process Analysis Toolkit (PAT) model checker is utilized for verifying the formal model against the properties. The PAT model checker takes the specified formal model as input and determines whether the properties are satisfied or violated. The properties are examined in terms of verification time, visited states, total transitions, and memory utilization.

1 Introduction

Blockchain technology has gained prominence in academia and industry for its transparency, immutability, decentralized, and distributed nature. It stores information in blocks that are interconnected in the form of a chain. The security of blockchain lies in its irreversible transactions. Originally, blockchain was operated on the energy-intensive Proof of Work (PoW) consensus protocol. In 2020, Ethereum initiated a transition towards a more energy-efficient Proof of Stake (PoS) protocol with the launch of the Beacon Chain. It is responsible for managing the PoS protocol and its primary role is to coordinate and manage validators related information. The protocol incorporates a consensus algorithm Gasper FFG (the Friendly Finality Gadget) [1], a combination of Casper FFG [2] and the GHOST (Greediest Heaviest Observed SubTree) fork-choice rule. The validators are participants who lock up a certain amount of cryptocurrency (32 ETH) as collateral and play a crucial role by proposing and attesting to blocks on the Beacon Chain. Their selection for block creation depends on their stake and the protocol’s randomness. In Ethereum 2.0 Beacon Chain, the protocol operates on an epoch-based system, where each epoch represents a distinct 12-second interval in the protocol’s lifecycle, during which various events and processes occur. An honest block proposer extends the canonical chain when it generates a new block, and an honest validator exclusively casts its vote for blocks on the canonical chain to ensure the system’s liveness. Moreover, Gasper serves as a mechanism that essentially counts the validators’ votes (known as attestations), leading to the eventual finalization of specific blocks and ensuring the system’s safety.

Fig. 1

The distribution of various rewards and penalty among validators within the Beacon Chain

Ethereum employs an incentive mechanism to incentivize validators to maintain their online presence. This incentive mechanism of attestations comprises both rewards and penalties. The rewards are frequently provided in the form of additional cryptocurrency tokens, as a recognition of their contribution to the security and proper functioning of the protocol. The penalties refer to the reduction or confiscation of a validator’s staked funds for violating protocol rules or engaging in any malicious behavior. Specifically, validators who participate in the network and whose attestations are finalized will be rewarded. Those who fail to adhere to the protocol rules or remain inactive, or whose attestations remain unfinalized for an extended period will face penalties. On the other hand, slashing is a more severe punishment for a validator. As it may result in the loss of a portion of the staked funds and also the removal from the validators’ set that impacts their ability to participate in the network. The aforementioned several rewards and penalties are presented in Fig. 1. The incentive mechanism is crucial for validator participation and is established during epoch processing, which occurs at the end of each epoch as shown in Fig. 2. The Epoch processing includes several other functions, including justification and finalization, slashings, registry updates, and other protocol updates. To ensure network stability and security, it resets eth1 data, slashings, and randao mixes lists, and updates effective balance, historical roots, and participation record lists for each new epoch.

Fig. 2

An overview of epochs and the corresponding operations processing within the consensus mechanism of the Beacon Chain

Ensuring a fair distribution of rewards and penalties is crucial for maintaining the validators’ trust and network stability. The intricate nature of this mechanism necessitates thorough verification to mitigate potential risks of protocol deviations and malicious behavior. This complexity underscores the importance of ensuring the correctness of the rewards and penalties mechanism in Beacon Chain to maintain the integrity of the entire network. The primary challenge of achieving a fair distribution of rewards and penalties motivates us to ensure the correctness of this mechanism. As any mistakes or flaws in this procedure can compromise the network’s credibility and result in significant financial losses. Formal methods represent a cornerstone in the pursuit of system reliability and correctness across a broad spectrum of systems and applications. They offer a mathematically structured framework for specifying, designing, and verifying the correctness of complex systems. Formal methods facilitate the early detection of errors and inconsistencies, thereby mitigating the risk of costly failures and security vulnerabilities. Formal methods contribute to the early identification of flaws, bugs, or vulnerabilities in the design phase that might otherwise go unnoticed. Model checking and theorem proving are two important formal verification techniques based on formal methods. In this work, we have used the model checking technique because in comparison to theorem proving it is an automated technique that enables efficient exploration of system behaviors.

It is worth noting that many researchers have previously conducted formal verification of blockchain-based consensus protocols to ensure their correctness, contributing to the continuous improvement and reliability of the systems [3,4,5].

These efforts reflect the broader trend of utilizing formal methods to enhance the robustness and reliability of blockchain systems. Recognizing the significance of formal methods, the Ethereum Foundation has endorsed multiple projects aimed at employing formal methods to analyze the Beacon Chain. A contribution in this context was first presented by the Runtime Verification Inc. in 2019, where they provide an executable K-model of the Beacon Chain Python reference implementation [6]. The usage of the K Framework for formal verification of Beacon Chain have various challenges, primarily due to the complexity involved in modeling Python language features. The Runtime Verification Inc. formally specify and verify the Gasper and Casper FFG protocols [1, 2], using Coq [7, 8]. Coq is a proficient formal specification language, but it requires users to have a solid understanding of formal logic including skills in dependent type theory and functional programming. The formal verification of the reference implementation of the Ethereum 2.0 Beacon Chain was presented using a verification-friendly language Dafny [9]. However, it has scalability constraints when applied to extensive systems. It does not provide full solutions to all verification difficulties and needs careful assessment of its suitability for particular projects. It was observed that the existing formal verification approaches encounter limitations in terms of scalability and complexity.

In contrast to prior projects, our project’s focus is the formal verification of the Beacon Chain using the model checking technique. Our objective is to attain comprehensive correctness and reliability within the Beacon Chain. Therefore, we concentrate on the formal verification of the fundamental components of the Beacon Chain. In this paper, our focus is on formal verification of the rewards and penalty mechanism of Beacon Chain including several other processes that occur at the end of an epoch. In our previous work, the formal verification of justification and finalization process has been conducted employing the SPIN model checker at abstract level [10]. The formal verification of the validator exit process has been done utilizing the SPIN model checker [11]. Recently, we presented a detailed formal verification of justification and finalization checkpoints in the Beacon Chain, through the PAT model checker [12]. The novelty of our work is the use of model checking technique with the PAT model checker which is not used before. We utilize the PAT model checker because it is a powerful tool for modeling and analysis. The benefit of model checking lies in its capacity to offer a systematic and automated approach for validating the correctness of critical systems. In the cases where the system deviates from the desired property, the model checker generates a counterexample, that identifies the erroneous behavior. It not only facilitates a comprehensive understanding of the root cause of the failure but also provides important insights for effectively addressing the identified issue. It systematically explores all possible states of a model to check if certain properties hold.

Our current work is dedicated to the formal verification of the rewards and penalty mechanism, as well as other processes involved in epoch processing, utilizing the PAT model checker. We have concentrated on ensuring that proposers receive their rewards fairly, appropriate penalties are imposed for any misconduct, balances are accurately updated, and there are no deadlocks in these processes. The formal specification of all processes is defined using the Communicating Sequential Programs (CSP#) language due to its expressive nature for modeling various systems. Linear Temporal Logic (LTL) is employed to describe properties such as deadlock-free operation, proposer reward, penalty, and balance updates. These defined properties are formally verified against the formal model using the Process Analysis Toolkit (PAT) model checker. This rigorous verification ensures that the incentive mechanisms function correctly and fairly. The comprehensive approach to managing incentives and penalties highlights the importance of ensuring the correctness of the Beacon Chain to maintain the integrity of the entire network.

Table 1 Methodology of the proposed work

The description of our methodology used in this work is provided in Table 1. Our contribution is noteworthy because earlier work on the formal verification of Beacon Chain [6,7,8,9] lacks a thorough examination in terms of algorithms, formal model, and properties. To ensure the correctness of the Python reference implementation of Beacon Chain, we have thoroughly examined its every aspect.

The major contributions of this work are given below.

• We have analyzed the Python reference implementation of the Beacon Chain [13], and described the algorithms for an important process, i.e., rewards and penalties and several other processes of the process epoch.

• We have specified the formal model for rewards and penalties mechanism and various other processes of the process epoch using a formal methods-based specification language, i.e., Communicating Sequential Programs (CSP#).

• The properties of deadlock-free, proposer reward, penalty, and balance update are defined using Linear Temporal Logic (LTL).

• The Process Analysis Toolkit (PAT) model checker is utilized for the verification of the properties against the formal model.

The rest of the paper is organized as follows: the background of blockchain, Ethereum, and formal verification is provided in Sect. 2; the literature review is discussed in Sect. 3; the system model and algorithms are presented in Sects. 4, 5 that describe the formal specification of the proposed protocol; the results are presented in Sect. 6; finally, the paper is concluded in Sect. 7.

2 Background

This section covers the background of blockchain technology, detailing consensus mechanisms, the Beacon Chain, and formal verification through model-checking techniques.

2.1 Blockchain: Basic Concepts

Blockchain is a decentralized ledger system that records transactions securely and transparently across a network of computers, eliminating the need for intermediaries which were previously relied upon for internet transactions [14]. The cryptographic community aimed to democratize the internet by developing peer-to-peer (P2P) networks, thus removing the need for central authorities [15]. Satoshi Nakamoto’s use of P2P, hashing, and encryption led to the creation of blockchain with Bitcoin in 2008 [16]. Blockchain has revolutionized various industries by providing a secure, decentralized way to record transactions, reducing risks, preventing fraud, and enhancing transparency [17]. Blockchain technology incorporates decentralized ledgers, cryptographic hashes, consensus algorithms, and smart contracts to ensure transparency, immutability, and security in transactions [18]. These features allow multiple, previously untrusted entities to collaboratively maintain and verify the ledger’s integrity.

Blockchains are categorized into three types: permissionless (public), permissioned (private), and hybrid. Permissionless blockchains, like Bitcoin, allow anyone to run a full node and validate transactions [16]. In contrast, permissioned blockchains, such as Ripple, restrict access to authorized users and centralize decision-making and validation [19]. Hybrid blockchains, like XinFin Digital Contract (XDC), combine elements of both models: public nodes validate transactions transparently, while private nodes manage restricted access to data and transactions, offering a balance of privacy, security, and transparency [20].

Fig. 3

Structure of a block in blockchain

The blockchain structure comprises two main components: the header and the body, as illustrated in Fig. 3. The header contains crucial metadata such as the block hash, previous block hash, nonce, timestamp, and Merkle root. These elements ensure the integrity and security of the blockchain by uniquely identifying each block and establishing a chronological order. They also contribute to secure the transactions within the block. The body of the block includes a list of transactions, each containing sender and recipient details, transaction amounts, and additional information.

2.2 Consensus Protocol

Consensus mechanisms are crucial in blockchain networks to ensure agreement among nodes on transaction validity and the ledger’s state in a decentralized system without a central authority [21]. As transactions are submitted, validators are selected through the consensus process to propose new blocks. Once these blocks are broadcasted and validated by the network, they are added to the blockchain, forming a continuous, cryptographically linked chain [22]. Consensus mechanisms are categorized into proof-based, committee-based, and voting-based types. Proof-based methods, such as PoW and PoS, rely on computational proofs or resource commitment. Committee-based methods, like Delegated Proof of Stake (DPoS) and Practical Byzantine Fault Tolerance (PBFT), use selected nodes for efficient validation and scalability. Voting-based methods, such as Delegated Byzantine Fault Tolerance (DBFT), rely on collective votes for transaction validation. A comprehensive discussion of these various consensus protocols can be found in [23, 24].

2.2.1 PoW

PoW stands as the pioneer generation of the consensus mechanism, initially introduced and implemented by Bitcoin. The fundamental concept revolves around the notion of “pay for work". The miners participate in a competitive process to validate transactions and create new blocks on the blockchain. The first miner to solve the puzzle validates transactions and adds the block to the blockchain, which is then broadcasted to the network. If two blocks are created simultaneously, a fork occurs, and the network continues on both branches until one becomes longer [25]. PoW involves verifying transaction funds, prioritizing transactions by fees, and issuing mining rewards proportional to computational effort [24]. The target value is adjusted every two weeks to maintain a 10-minute block time. Although PoW is secure, it suffers from energy wastage and centralization risks, as miners with less power may join pools, concentrating control and potentially excluding smaller participants.

2.2.2 PoS

PoS is a consensus mechanism where participants, called validators, commit a stake to validate blocks instead of using computational power like in PoW [26]. Validators are selected to propose and attest blocks based on their stake, coin age, or currency use [27]. The validators with higher stakes in the network have a greater chance of being selected to validate transactions and earn rewards [28]. When selected, a validator proposes a block, and a committee of validators attests to it. If enough committee members agree, the block is added to the chain, and rewards are distributed. Validators face penalties for dishonest actions or prolonged inactivity, which can lead to loss of their staked funds. PoS is more decentralized than PoW since it doesn’t require expensive hardware, though staking requirements can be a barrier for some users.

The PoS offers a mechanism of staking pools [29], an alternative for users who cannot or do not want to stake the entire required amount. The users contribute a portion of their cryptocurrency holdings to a common pool or node. This aggregated stake increases the likelihood of the pool being chosen as the validator, and any rewards earned through the validation process are distributed proportionally among the pool participants based on their stake. The PoS algorithm resists 51% attacks through penalties imposed on validators for inaccurate verification [30]. However, a major issue in PoS is the “nothing-at-stake” problem, where a validator with stakes on both branches of a fork might attempt to validate both simultaneously, increasing the risk of fraudulent transactions.

2.2.3 Hybrid Protocols

Hybrid protocols in blockchain represent a strategic integration of diverse consensus mechanisms to capitalize on their respective strengths and address the limitations inherent in singular approaches. By combining elements from PoW, PoS, or other consensus models, these protocols seek to enhance network security, scalability, and efficiency [31]. The adaptive nature of hybrid protocols allows blockchain networks to dynamically adjust their consensus strategies based on varying conditions, ensuring optimal performance. In this approach, the blockchain is utilized not only to reach consensus on individual transactions but rather to establish agreement on rotating committees [32]. These committees subsequently employ permissioned consensus protocols to achieve consensus on transactions. This approach not only provides resilience against specific types of attacks but also facilitates smooth transitions between consensus mechanisms as blockchain networks evolve. Examples like Ethereum’s Casper [2] showcase the versatility of hybrid protocols in creating more robust and adaptable decentralized systems.

Fig. 4

Structure of Ethereum 2.0 Beacon Chain

2.3 Beacon Chain

The Beacon Chain is a fundamental component of Ethereum 2.0 and represents a major upgrade to the existing Ethereum network. It serves as the coordination layer for the transition from PoW to PoS consensus mechanism, introduced to address scalability concerns, managing validators and the protocol [9]. The Beacon Chain along with its underlying protocol is responsible for ensuring consensus among the network’s validators who are assigned with validating transactions and securing the network. It is also responsible for various other tasks such as handling blocks and attestations, rewards and penalties, and executing the fork-choice algorithm [33]. The validator’s set is dynamic, as new validators register themselves by staking 32 ETH. Upon registration, validators acquire the eligibility to propose, vote, and append new blocks of transactions to the Beacon Chain. The overview of the Beacon Chain specifications [13] and its underlying protocol [1] is briefly explained as follows. In Ethereum 2.0, the Beacon Chain operates with epochs and slots. An epoch consists of 32 slots, with a new block being added every 12 s. During each slot, a validator is selected to propose a block, and committees are formed for each epoch. The fork-choice rule Hybrid LMD, a variation of LMD GHOST, is used for proposing and attesting blocks. Validators must maintain synchronization to effectively participate in the system [1, 13].

The Beacon block is comprised of essential elements, including a slot, proposer_index, hash of the parent_root, hash of the current state_root, and block_body. The Fig. 4 illustrates the structure of a Beacon block in Ethereum 2.0. The Beacon block body further consists of several components. These include the randao_reveal, a random number disclosed by validators to contribute to the consensus algorithm’s randomness. The eth1_data incorporates information from Ethereum 1.0, maintaining a connection between the two chains. Additionally, the graffiti section allows for the inclusion of arbitrary data or messages. The block body also features proposer_slashings and attester_slashings, which contain information about penalties imposed on validators for malicious actions. Moreover, attestations represent votes on block validity, while deposits include collateral committed by validators, and voluntary_exits account for validators voluntarily leaving the system. These components collectively form the body of the Beacon block contributing to the integrity and security of Ethereum 2.0’s consensus mechanism.

Ethereum’s consensus protocol, known as the Gasper protocol in Ethereum 2.0, integrates two mechanisms: Latest Message Driven Greediest Heaviest Observed Sub-Tree (LMD-GHOST) and Casper FFG [1]. Casper FFG enhances security by finalizing blocks to ensure blockchain integrity, while LMD GHOST, as a fork choice rule determines the most valid chain by considering the latest messages and their associated weights. Together, they provide a robust consensus mechanism that ensures both block finalization and fork choice, promoting security and coherence in the Beacon Chain.

2.4 Formal Verification

This section provides a concise overview of formal modeling and verification methods. Formal methods refer to a set of mathematical techniques used for the comprehensive modeling, analysis, and validation of systems. Formal verification is a systematic and rigorous process used in software and hardware engineering to ensure the correctness and reliability of complex systems. It involves the application of mathematical methods to model, analyze, and formally validate the system designs. These methods utilize mathematical precision to specify and verify the correctness of system designs. Formal verification is increasingly employed by engineers to verify intricate software and hardware, particularly in safety-critical applications. The process often includes techniques such as model checking, theorem proving, and other formal methods to systematically verify that a system behaves according to specified requirements and properties. The primary objective of these techniques is to guarantee the reliability and correctness of critical software systems by mathematically modeling their behavior and properties [34].

The model checking approach used in our research involves three phases: modeling, running, and analysis which is graphically presented in Fig. 5. During modeling phase, the system is precisely and unambiguously represented through the transition system, utilizing the formal specification language of the model checker. CSP# is utilized for specifying the system model, while LTL is employed to formalize properties to analyze individual paths. The running phase involves executing the PAT model checker to validate specified properties, and the subsequent analysis phase evaluates whether the properties are satisfied or violated. In case of violation, the generated counter-example undergoes thorough analysis via simulation, leading to potential refinements of the model or properties.

Fig. 5

Model checking technique utilizing the PAT model checker

In our research, CSP# is utilized to model the system, and the PAT model checker automatically generates a transition system based on the formal model. While several model checkers are available for formal system verification, we specifically utilize the PAT model checker due to its efficiency in modeling, reasoning, and simulating concurrent systems. It streamlines the verification process by automating model generation, property specification, and verification tasks which reduce the reliance on manual intervention. It supports an enriched formal modeling language known as CSP# which seamlessly combines high-level modeling operators with low-level C# programming constructs. High-level modeling operators like interrupt, parallel/sequential composition, and interleaving are smoothly integrated with low-level C# programming structures like variables, arrays, and if-then-else expressions using CSP#. The syntax of CSP# employed in this study is outlined below:

$$\begin{aligned} \begin{array}{lcll} {A_1} & {:}{:}{=} & \textrm{SKIP} & (\text {termination}) \\ & \hspace{-3.5em} |& \hspace{-2.5em} e \rightarrow {A_1} & (\text {event prefixing})\\ & \hspace{-3.5em} |& \hspace{-2.5em} e \{program\} \rightarrow {A_1} & (\text {operation prefixing})\\ & \hspace{-3.5em} |& \hspace{-2.5em} [\,g ]\, {A_1} & (\text {state guard}) \\ & \hspace{-3.5em}|& \hspace{-2.5em} \textrm{if} \; g \; \textrm{then} \; {A_1}\; \textrm{else}\; {A_2} & (\text {boolean} \; \text {statement})\\ & \hspace{-3.5em} |& \hspace{-2.5em} c?a \rightarrow {A_1(a)} & (\text {channel input})\\ & \hspace{-3.5em} |& \hspace{-2.5em} c ! a \rightarrow {A_1} & (\text {channel output})\\ & \hspace{-3.5em}|& \hspace{-2.5em} {A_1} ; {A_2} & (\text {sequential} \; \text {composition}) \\ & \hspace{-3.5em}|& \hspace{-2.5em} {A_1} \;\vert \vert \; {A_2} & (\text {parallel composition}) \\ & \hspace{-3.5em}|& \hspace{-2.5em} {A_1} \;\Box \; {A_2} & (\text {external} \; \text {choice}) \\ \end{array} \end{aligned}$$

here, $A_1$ and $A_2$ represent processes, $g$ indicates a guard condition, $e$ signifies an event, program refers to a sequence of code statements executed atomically, and $c$ describes a synchronized communication channel.

In the PAT model checker, various assertions, including deadlock-freeness, LTL, determinism, non-termination, reachability, and refinement/equivalence, are formulated to analyze system behavior. The deadlock-freeness and LTL assertions utilized in this work is explained below. Deadlock-freeness guarantees continuous system operation by avoiding scenarios where processes are mutually blocked, waiting for resources that are held by other processes in a cycle. Wherein the LTL assertions are concise formal statements used to specify temporal properties in a system, facilitating the formal verification and analysis of reactive systems by expressing conditions over sequences of states. It provides a precise way to describe the desired behavior of a system.

Deadlock-freeness: This assertion determines whether a deadlock is present in the process $P$.

#assert P() deadlockfree;

Linear Temporal Logic (LTL): This assertion checks whether a process $P$ meets the criteria defined by the LTL formula $\varphi$.

#assert $P() \models \varphi$;

The syntax of LTL formula is specified based on the following rule:

$\varphi = e \,|\, p \,|\, \varphi _1 \wedge \varphi _2 \,|\, \lnot \varphi \,|\, \square \varphi \,|\, \Diamond \varphi \,|\, \bigcirc \varphi \,|\, \varphi _1 \cup \varphi _2$

here e denotes an event, and p signifies an atomic proposition. The symbols $\square$, $\Diamond$, $\bigcirc$, and $\cup$ are interpreted as always, eventually, next, and until respectively.

The two primary approaches are used for writing properties in model checking: LTL and Computation Tree Logic (CTL). LTL is useful for defining properties about state sequences in a system over a single path. On the other hand, CTL is explicitly designed for analyzing properties related to branching time, where the system’s behavior can diverge into numerous potential future states at each interval. CTL facilitates the specification of properties across various paths. In our research, we have employed the LTL approach for writing properties in model checking. LTL formulas are more intuitive and easier to understand, especially for users unfamiliar with formal logic or model checking techniques. The linear structure of LTL formulas corresponds directly to the linear execution paths of many systems simplifying the expressions of temporal properties. Additionally, many model checking tools provide robust support for LTL by offering features such as automatic translation of LTL formulas into appropriate model checking algorithms. These factors collectively contribute to LTL’s clarity, comprehensibility, and widespread adoption in formal verification tasks.

3 Literature review

This section provides a comprehensive survey of the blockchain consensus, including proof-based, hybrid, and BFT consensus protocols. The incentive mechanisms of various consensus protocols are reviewed along with the application of model checking for the analysis of these protocols and Beacon Chain.

3.1 Proof-Based Consensus Protocols

Proof-based consensus protocols are used in blockchain networks to achieve agreement among participants on the validity of transactions and the order in which they are added to the blockchain. These protocols typically rely on participants, known as miners or validators, providing proof of their computational efforts or stake in the network to secure the consensus process [35]. The most common example is the PoW, as seen in Bitcoin, where miners compete to solve complex mathematical puzzles, and the first to solve them gets the right to add a new block to the blockchain. Other proof-based consensus protocols include PoS, DPoS, and Proof of Elapsed Time (PoET), each with its unique approach to achieving consensus. These protocols ensure a secure, trustless environment by demanding commitment or investment from participants. The Nakamoto consensus protocol [16] in Bitcoin involves competitive block creation based on computational power, rewarding miners proportionally to their resources. Despite its decentralized P2P network and defenses against attacks like Sybil and double-spending, Bitcoin faces challenges such as unsustainable energy consumption, limited scalability, transaction capacity, and potential long-term security risks due to the increasing hashing power of mining pools. Alt-PoW [36] is a proof-based consensus mechanism designed to enhance mining efficiency by breaking a single large problem into smaller tasks. Participants can monitor progress, switch between multiple chains, and mine round blocks before the final transaction block, verifiable by the miner’s signature. This system allows miners to adjust strategies based on progress and success probabilities. However, the PoW mechanism still rewards only the first-place winner, leading to high energy consumption.

To address the energy inefficiency of the PoW, a new approach is introduced in [37]. Unlike traditional PoW, green PoW compensates runners-up with exclusivity to solve the next block, reducing competition and energy consumption by nearly 50%. This approach divides time into epochs with two mining rounds each, allowing all nodes to participate in the first round and only runners-up in the second. It showcases the effectiveness in reducing energy consumption, fork occurrences, mining centralization, and transaction censorship risks associated with PoW.

Ouroboros, a PoS protocol employs a coin-flipping mechanism for randomizing leader selection [38]. In this system, physical time is divided into fixed-time epochs, each further subdivided into N slots allocated to a single leader for block generation. Moreover, it integrates a reward mechanism to incentivize participation and counteract the selfish mining attack, though fairness may be compromised. In contrast, Snow White uses random selection and a sleepy consensus mechanism for validator appointment [39], allowing nodes to switch between online and offline states to handle adverse network conditions. In this protocol, stakeholders use the current blockchain, including stake information to determine the committee for the next epoch. Gasper [1], Ethereum’s PoS algorithm, also employs the concept of stakes to achieve consensus, distinguishing itself as a leadingedge PoS algorithm in the blockchain space. In our recent research on Ethereum 2.0’s Beacon Chain, we analyzed and verified key processes such as state initialization, justification, and finalization to ensure properties like deadlock avoidance and safe initialization, justification, and finalization [12].

3.2 Hybrid Consensus Protocols

Hybrid approaches are designed to overcome the limitations of existing consensus protocols by integrating their benefits and minimizing vulnerabilities to potential attacks. Proof of Activity (PoA) [40] is a hybrid protocol designed to foster an active online network while reducing overall network usage. It combines PoW for creating empty blocks with PoS for transaction validation. Validators are chosen pseudo-randomly based on their staked coins, and both the block header creator and stakeholders receive rewards. PoA defends against 51% attacks by necessitating attackers to control over half of the mining power. A new consensus model, Proof of Luck (PoL) [41], proposes to mitigate PoW limitations by minimizing computational demands and enhancing transaction throughput. PoL employs trusted execution environments and assigns a luck value (ranging from 0 to 1) to each mined block. Miners with higher luck values are prioritized for appending blocks to the chain.

In [42], a hybrid PoW-PoS cryptocurrency protocol is devised to counteract 51% attacks. The design incorporates a single-thread system with precise time intervals for block generation, ensuring a robust consensus mechanism, fair profit distribution, and preventing the dominance of any individual user or group. Even in rare cases of substantial CPU power and staking assets, a strict timestamp barrier prevents undue advantages, and validators reject manipulated transactions promptly.

3.3 BFT Consensus Protocols

Byzantine fault tolerance guarantees secure consensus among nodes in a distributed network, even in the presence of malicious actors [43]. PBFT is a notable example [44], which functions as a replication algorithm resilient to Byzantine faults. PBFT relies on a trusted set of nodes and arranges them sequentially, with one designated as the leader and others as backups. It offers higher transaction throughput than PoW but is more effective in private networks due to communication overhead. However, PBFT networks are vulnerable to Sybil attacks and less decentralized due to a central authority. To reduce communication overhead and to preserve decentralization within the blockchain, the Ripple network adopts the federated byzantine agreement protocol [45]. Unlike PBFT, FBA eliminates the need for a central authority to manage a node list for transaction validation and processing, enabling any node to participate in consensus. Transaction inclusion requires agreement from 80% of nodes, while potential communication obstacles are addressed with a unique node list management system. Bitcoin-NG [46] separates block functionality into key blocks for leader election and microblocks for transactions. A miner who solves a puzzle becomes the leader, creates a key block, and then generates microblocks every ten seconds. This design enhances throughput and reduces block splits. However, it does not solve transaction confirmation latency and raises concerns about leader compromise, selfish mining, and double-spending attacks.

In BFT consensus protocols, leader selection is a difficult and resource-intensive process that causes delays and vulnerabilities. To address this, we propose the STBC protocol [47], using trust metrics like deposit ratio, activity rate, and missed rate to identify reliable leaders and validators. These participants receive rewards for proposing and validating valid blocks. However, unresponsive nodes cause delays in block production and transaction finality which impact network throughput and responsiveness. To enhance fairness and efficiency, we introduce the TBC consensus protocol [48], which incorporates failure rate and waiting rate to prevent rich node from monopolizing the block generation process and providing opportunities for waiting nodes to emerge as trusted leaders or validators. Additionally, we present the TTC consensus protocol [49], prioritizing fraud resilience by selecting trusted leaders and validators. Both the leader and validators are rewarded if the majority approve the block, but penalized for malicious actions like adding invalid blocks or withholding them.

3.4 Rewards and Penalties-Based Consensus Protocols

The reward and penalty mechanisms in consensus protocols incentivize good behavior and deter malicious activities. In this section, we analyze the rewards and penalty approaches adopted by different protocols. The Sustainable Rewarding Mechanism (SRM) for Blockchain-based Transaction Systems (BTS) proposed in [50]. Under SRM, users pay a mandatory transaction fee into a public account, from which miners receive a fixed reward for mining new blocks. The blockchain ensures the security of these public accounts. The Anti-Withholding Reward System (AWRS), based on the theoretical analysis and simulations proves effective against Fork After Withholding (FAW) and Block Withholding (BWH) attacks with a particular emphasis on FAW due to its advanced nature and broader impact on attack and reward dynamics [51]. The mining pool managers ensure fair reward distribution based on each miner’s computational contribution.

Table 2 Comparison of various properties of formally verified blockchain-based protocols

The system proposed by [52] includes Non-Participating Nodes (NPN), Participating Nodes (PN), and the Malicious Nodes (MN) involved in block proposal and validation. Rewards go to the leader node and participating nodes at the end of each mining cycle, while penalties for malicious actions are deducted from offenders’ deposits. Initial Rewards (IR) consist of a Leader Reward (LR) and transaction fees, with Generated Rewards (GR) mainly rewarding participants and reinvesting for future rounds. Compliance ensures the full Final Reward (FR), whereas non-compliance results in penalties before awarding the remaining FR. Ethereum’s Casper [2] implements PoS which requires validators to stake deposits to prevent nothing-at-stake attacks by penalizing misbehavior. In Casper, validators vote on blocks based on their stake, ensuring liveness and safety even if up to 1/3 of the voting power is controlled by Byzantine nodes.

The application of game theory is applied in collective decision-making scenarios involving multiple participants, each aiming to maximize their payoff regardless of others’ actions [53]. In blockchain systems, validators (in PoS) or miners (in PoW) make strategic decisions to maximize their rewards. Validators compete for rewards similarly to players in a game, sometimes leading to dishonest behavior. Reward-penalty mechanisms in PoS, as explored in [54], evaluate validators’ reliability based on their voting behavior. Validators vote on new blocks, with rewards given for accurate participation and penalties, such as stake confiscation, for incorrect or malicious actions. The Ethereum platform’s post-merge reward system, as discussed in [55], emphasizes consensus-layer incentives (71.3% of rewards). Validators earn 61.4% from stable attestations, with low missed block (0.72%) and attestation (4.9%) rates. However, occasional performance issues during the merge affect up to 68% of rewards, especially with large staking entities’ block proposals. A rewards indexer tool monitors this, noting major staking pools may miss 1.77% of rewards due to client issues, distinguishing compliant from non-compliant behavior.

In another Ethereum reward system study [56], the staircase attack exploits delays in adversarial blocks and attestations to manipulate the LMD-GHOST rule, allowing adversaries to invalidate honest validators’ attestations and replace finalized blocks, leading to chain reorganization. With control over 29% of the stake, adversaries can repeatedly execute this attack, causing losses for honest validators and gains for malicious ones. This compromises system security if adversaries acquire more stake. Validators are incentivized with rewards for compliance and penalized for violations, crucial for maintaining system integrity. In this work, we provide a detailed analysis of various epoch-related processes including rewards, penalties and slashings, registry updates, and other relevant activities within the Beacon Chain. We have rigorously verified these processes to ensure they adhere to specific properties. These properties include the absence of deadlocks, the allocation of proposer rewards, penalties for misconduct, and updates to balance distributions. The network participants are incentivized to comply with protocol rules through rewards, while violations are penalized for maintaining protocol adherence among validators. The comparative analysis of the consensus protocols discussed above is provided in Table 2.

3.5 Formal Verification of Consensus Protocols

Model checking of consensus protocols is essential in ensuring the robustness and reliability of distributed systems. It is used to systematically analyze the protocols through model checking to identify and fix potential flaws, vulnerabilities, and inconsistencies. This method provides a structured approach to verify the correctness of intricate consensus algorithms, facilitating in the detection of potential pitfalls before deployment. Ultimately, the use of model checking contributes to the creation of more resilient and secure consensus protocols, fostering trust and stability in decentralized systems. The Bitcoin PoW protocol and its backbone protocol, along with an adversary model for selfish mining is presented in [57]. To formally specify the system, threshold automata is used and formal analysis is performed using the UPPAAL model checker. The analysis ensures a reduction in failure rate for the chain quality property, while an increase is observed for the common prefix property. It is computationally intensive to accurately determine the failure rate because only one property can be verified at a time. The BIP (Behavior, Interaction, Priority) framework is employed to formally model adversary scenarios on PoW blockchains in [58]. This approach utilizes the statistical model checker SBIP to investigate various attacks such as DNS (Denial of Network Services), double-spending, and consensus delay. It takes into consideration both stochastic and temporal interactions within blockchain systems.

The Tendermint consensus protocol is formally defined and verified using CSP# and the PAT model checker [59], demonstrating deadlock-free operation and agreement with at least 2/3 network nodes. However, disruptions occur if over 1/3 of nodes are in the minority. The protocol prioritizes consistency, resists double-spending, and is also specified with TLA+ and verified through TLA Proof System (TLAPS) [60]. The Apalache model checker evaluates safety properties like termination and synchronization, formalizing liveness properties and identifying issues with faulty peers, but it does not verify liveness. The analysis links timeout duration, message delays, and block generation rate.

Table 3 Comparison of various properties of formally verified blockchain-based protocols

The BFT consensus mechanism of the RedBelly blockchain [61] is articulated using threshold automata and validated through ByMC. This approach highlights the importance of the issue by identifying vulnerabilities in blockchain consensus and presents counter-examples. The emphasis is placed on examining different properties such as justification, consistency, and termination in detail.

The Continuous-Time Markov Chain (CTMC) model simulates the PBFT protocol’s temporal responses, validated by the PRISM model checker [62]. The analysis presents factors like the delay of primary and replica nodes but does not provide a discussion on potential node failures. Internet speed impacts the process, with minimal influence from replica nodes. HotStuff’s refined version, formalized with TLA+ and verified through TLAPS and the Ivy tool, shows increased complexity due to its tree model [63]. The Algorand employs a secure PoS, ensuring a single certified block per round to prevent forks [64]. Advancements in Coq address timing complexities and adversarial actions, with the asynchronous safety proof ensuring no two different blocks are certified in the same round, suggesting potential for verifying other properties like liveness.

The refinement of the Correct By Construction (CBC) Casper consensus is explored [65] to enhance the security of PoS protocols, focusing on safety and liveness despite Byzantine behavior. The research advances these properties within the CBC Casper framework, particularly examining Casper The Friendly GHOST (Casper TFG), formalized and verified using the Isabelle/HOL proof assistant. Key contributions include proving blockchain safety, adjusting properties like governing messages and state transitions, and proposing an improved clique oracle for validator decision-making. The Stellar Consensus Protocol (SCP) for federated Byzantine agreement is formally modeled using timed automata and validated with the UPPAAL model checker [4]. This ensures quorum configurations guarantee consensus before implementation. The abstraction of the model addresses large state space challenges but increases processing delay and packet overhead due to validators broadcasting and analyzing quorum information for each block.

Table 4 Comparison of formally verified Beacon Chain projects

In previous research, formal modeling techniques were applied extensively to analyze and improve blockchain consensus protocols. This approach led to the development of three key protocols: STBC, TBC, and TTC [47,48,49], aimed at enhancing security and efficiency in crowdsourcing applications. These protocols were modeled using CSP# and LTL formulas, verified with the PAT model checker. STBC focuses on identifying reliable leaders and validators based on criteria like deposit ratio and activity rate to achieve transaction consensus in crowdsourcing. However, it lacks analysis of properties such as persistence and liveness. TBC addresses this gap by enhancing trust models with considerations for failure and waiting rates. TTC leverages blockchain to enhance security in crowdsourcing, prioritizing resilience against fraud and attacks. Utilizing model checking for formal verification, the TTC protocol demonstrates robustness in critical crowdsourcing systems.

Previously, the aspects of blockchain technology including consensus mechanisms, smart contracts, and security have been thoroughly investigated by researchers. However, with the advent of the Ethereum 2.0 Beacon Chain, the focus is now switched towards the formal verification of this inventive component to ensure its integrity. In this regard, we have presented some preliminary work on the justification and finalization of checkpoints, and the validator’s voluntary exit processes using the SPIN model checker [10, 11]. In our most recent research, we have conducted a detailed formal verification of Beacon Chain state initialization and the justification and finalization of checkpoints using the PAT model checker [12]. By utilizing CSP# for specification and LTL for property definition, coupled with the PAT model checker, the paper ensures the reliability and correctness of the Beacon Chain. Now, the objective of this work is to formally verify the reward and penalty systems and operations associated with epoch processing using the PAT model checker. We meticulously validate operations linked to epochs, encompassing rewards and penalties, the slashing process, registry updates, and other pertinent activities within the Beacon Chain. A comparison of the aforementioned consensus protocols regarding their properties, languages, and tools is presented in Table 3.

3.6 Formal Verification of Beacon Chain

The Beacon Chain is the foundation of Ethereum 2.0 and the Chain consists of a sequence of Beacon blocks. It holds important data about validators, attestations and committees, justification and finalization, hashing and merkleization, and the state of the underlying Ethereum 1.0 blockchain. The Ethereum Foundation supported several essential projects on formally verifying the Beacon Chain. The standard implementation in Python defines the Beacon Chain’s structure and functionality and is widely utilized by many research academics. In this regard, the executable K-model of Ethereum 2.0 Beacon Chain (Phase 0) stands as a pioneering project initiated by Runtime Verification Inc. [6]. The formalization presents the specifications in the K framework including both the Beacon Chain state and state transition function. The model provides executable interpretations of the protocol by precisely specifying the beacon chain’s operations and structure, facilitating direct testing against standard test suites. The intricacy of the K Framework poses challenges for formally verifying the Beacon Chain, especially in modeling Python language features.

Runtime Verification Inc. has formally analyzed the Casper FFG and Gasper protocols using the Coq proof assistant [7, 8]. The partial specifications of Casper [7] focus on conceptual processes but lack detailed modeling. These specifications utilize five key parameters: participant nodes, validator weights, fault tolerance threshold, consensus values, and an estimator function, influencing the protocol’s states and messages. The protocol demonstrates Byzantine fault tolerance and proves safety and non-triviality properties. The analysis of Gasper models [8] its finality mechanism at an abstract level, ensuring properties consistent with Buterin’s original Casper proposal [2]. Validation is achieved through an abstract model of quorums without explicitly defining honest behavior and communication protocols. The formal verification of the state transition function is undertaken using theorem proving with Dafny and the Z3 SMT solver [9]. This identified issues like runtime errors, division by zero, underflow/overflow, and array out-of-bounds. However, it encounters scalability limitations in large-scale systems, and interpreting the feedback from the verifier in the event of verification failure proves challenging.

All preceding projects on the formal verification of the Ethereum 2.0 Beacon Chain, as outlined above, utilized the theorem proving technique. Unlike theorem proving, model checking provides a more detailed and automated verification process. Theorem proving demands substantial manual effort in constructing proofs, especially when handling the complexities of large-scale systems. As a result, in this research, we choose model checking because of its automated process, which facilitates a thorough analysis of system states to prevent any critical properties from being missed. In contrast to previous studies, we have also analyzed and formally verified the components of Ethereum 2.0 using the SPIN model checker at an abstract level. Specifically, we have contributed to verifying the Beacon Chain’s justification and finalization processes using the SPIN model checker. The SPIN model checker was employed to verify the Beacon Chain’s justification and finalization processes, using PROMELA and LTL formulas for evaluating safety properties [11]. Additionally, the voluntary exit of validators was formalized and verified to ensure secure exits without penalties [10]. These studies provide surface-level insights and lack thorough process modeling. In the context of our previous research, we formally verified the state initialization, justification, and finalization of the Beacon Chain through the PAT model checker [12]. To ensure correctness and reliability, we employ CSP# for precise formal specification of these processes while the properties are articulated using LTL formulas and subsequently verified using the PAT model checker.

This study aims to conduct formal verification of the Ethereum 2.0 Beacon Chain through the use of model checking techniques, with a key focus on the rewards and penalty frameworks. It also comprehensively verifies the other operations associated with the epoch, encompassing the slashing process, registry updates, and other relevant activities using the PAT model checker. Specifically, we have focused on ensuring that these processes do not result in deadlocks, proposers receive their due rewards, appropriate penalties are imposed for any misconduct, and balances are updated accurately. In order to achieve this, the processes are formally specified using CSP#, with the properties described using LTL formulas and verified through the PAT model checker. The PAT model checker is used in this research to automate tasks involved in the verification process, including model generation, property specification, and verification, thereby reducing the need for human intervention. It provides a unique combination of automation, user-friendliness, comprehensive analysis, and visualization capabilities, which makes it a valuable tool for formal verification. Table 4 presents a comparison of previous work on the formal verification of the Beacon Chain, with respect to the specification language, verification tools, verified properties, and limitations.

4 System Model of Process Epoch

This section describes the system model of the epoch process, including rewards and penalties, registry updates, process slashing, and other processes involved in epoch processing, and their algorithms.

4.1 Process Epoch

The epoch process is executed at the start of the next epoch, marked by the corresponding slot in the state. During the epoch processing, all other processes are performed in this primary function. The sequence of processes that are performed is described in Fig. 6. When the epoch process begins, it calls the justification and finalization process. This process handles all tasks related to justifying and finalizing checkpoints using the stored attestations. After that, it moves toward the rewards and penalties process, wherein rewards are computed for attestations and block proposals, while penalties are assigned for inactivity leaks, and unethical behavior. The entire process is illustrated in Fig. 7, showing all the necessary details. The next step is the registry update process, which manages updates to the validator registry, potentially incorporating new validators or updating existing ones based on changes in the system. The detailed process is explained in Fig. 8. The next process deals with the slashing conditions, determining if any validator has violated protocol rules and added to the slashed validators list. The concept of the slashing process is elaborated in Fig. 9.

After this, the process $eth1\_data\_reset$ resets Ethereum 1.0 chain data, ensuring a clean list for the next epoch. If the next epoch is a multiple of a specific interval, then the previous list is reset for new data, otherwise, nothing happens. Further, the process moves toward effective balance updates, involving adjustments to the balances of validators based on their performance and actions during the epoch. Similar to the data reset process of eth1, this next step reset the slashing data for the upcoming epoch. After that it invokes the resets randao mixes process, used for random number generation, ensuring a fresh start for the next epoch. Then the historical roots are updated, maintaining a record of the state of the system for historical purposes. The last process manages and updates the participation records related to epoch attestations. After an epoch is processed, the current epoch’s attestations become the previous epoch’s attestations. Then, the list for the current epoch’s attestations gets cleared, making way for the upcoming epoch attestations.

Fig. 6

The visual representation of the sequential steps and operations involved in epoch processing within the Beacon Chain

4.2 Process of rewards and penalties

Fig. 7

The flow diagram illustrates the process of calculating rewards and penalties in the Beacon Chain

The rewards and penalties process in Ethereum 2.0 is executed during epoch processing, a periodic phase where validators’ performance is assessed, and rewards are distributed. Figure 7 describes the flow of processing rewards and penalties in the system. The initial step checks whether the current epoch corresponds to the genesis epoch. If the current epoch is indeed the genesis epoch it returns immediately as no rewards are applied at the end of this epoch. However, if the current epoch is not the genesis epoch, the flow proceeds to the next step. The subsequent step in the process is the computation of rewards and penalties and the results are stored in the rewards and penalties lists.

The rewards and penalties are fetched for various attestation aspects such as source, target, and head from the previous epoch. These three processes invoke another function called get attestation component deltas. This serves as a helper function that provides a list of sequences containing rewards and penalties for each validator based on the attestation type. Firstly, initializes lists of rewards and penalties, then obtains the total active balance of all validators in the state. Then retrieves the indices of validators who have provided attestations and have not been slashed, and then calculates the total balance of those validators. The subsequent step involves iterating over the indices of those eligible validators who were either actively participating in the previous epoch or have been slashed and have reached the epoch where they can withdraw their funds. Getting eligible validators enables the protocol to distinguish validators who fulfill certain conditions from those who do not. For each eligible validator, it checks if they belong to unslashed attesting indices. If yes, it further checks if the system is in an inactivity leak state. If the system is in an inactivity leak state, it sets the increment amount and adds the full base reward to the rewards list for the validators. If it is not in an inactivity leak state, it distributes the reward among the attesting validators based on their balances. If the validator index does not belong to the unslashed attesting list, it adds the base reward to the penalties for the validator. After that, it returns the calculated rewards and penalties lists.

After processing the attestation component deltas, the flow proceeds to calculate inclusion rewards and inactivity penalties. Subsequently, the lists of rewards and penalties are calculated for each validator by summing the corresponding values obtained from the previous steps. The flow then enters a for loop, representing an iteration over each validator in the state. Then updates the list by increasing the balance of the validator at the specified index with the corresponding reward amount. Simultaneously, reduce the validator’s balance by applying a penalty at the given index. Ultimately, the entire process returns a list containing the calculated rewards and penalties for each validator.

The function increase balance, is designed to augment the balance of a validator at the specified index within the state. The increment amount, denoted by delta, is added to the current balance of the validator. The function operates directly on the balance attribute of the state, updating the balance value for the targeted validator. The decrease balance function is responsible for reducing the balance of a validator at the specified index in the state. The reduction amount, denoted by delta, is subtracted from the current balance of the validator. Importantly, the function includes underflow protection to ensure that the balance does not go below zero. If the reduction amount is greater than the current balance, the balance is set to zero, preventing negative balances. This function modifies the balance list of the state to reflect the updated balance for the specified validators.

4.2.1 Rewards Calculation

The purpose of the reward and penalty system is to maintain the integrity and security of the Beacon Chain network. This process encourages validators to act in the best interest of the network’s consensus protocol. The validators have a financial stake in the network, and the rewards they earn can be increased or decreased based on their adherence to the rules. Penalties serve as a deterrent against malicious behavior. The Ethereum 2.0 Beacon Chain rewards system includes base incentives for block proposals in addition to three different kinds of attestation for source, target, and head, plus an inclusion reward. At the same time, inactivity and failure to attest to source, head, and target result in penalties.

The base reward is defined as $B_R$, which is the average income for the validator’s optimal performance in each epoch. The base reward is directly proportional to the validator’s effective balance, which is denoted as $\lambda$. The $\mu _f$ denotes constant value BASE_REWARD_FACTOR equals 64, this parameter can be adjusted to either increase or decrease the overall reward for participating in Ethereum 2.0. The integer square root is denoted as $\surd$, it returns the integer value of the total balance which is denoted as $T_B$. At the end, an additional division is applied by constant value BASE_REWARDS_PER_EPOCH equals 4, denoted by $\mu _e$. This is the specific formula to calculate the base reward for all the validators in the network.

$$\begin{aligned} B_R = \frac{\lambda \, \star \, \mu _f}{\sqrt{T_B}} \, / \, \mu _e \end{aligned}$$

The proposer reward for each validator who performs attestation in the network is computed through the following formula. We denote the proposer reward as $P_R$, and $\rho _{q}$ represents constant PROPOSER_REWARD_QUOTIENT which is equal to 8. Each validator receives a reward equivalent to at least 1/8 of the base reward for a block proposal or attestation.

$$\begin{aligned} P_R = \frac{B_R}{\rho _q} \end{aligned}$$

The base reward per increment is the fundamental unit of reward in terms of which all other regular rewards and penalties are calculated.

4.3 Process Registry Updates

The process registry manages validator activation eligibility, ejections, and activations in the Beacon State. It ensures that the validator set evolves based on their eligibility and current conditions. In Fig. 8, the flow of the process is explained. The process started with iterating through all validators in the state. For each validator, it checks if the validator is eligible for an activation queue based on certain criteria. If the validator is eligible, it sets the activation eligibility epoch to the next epoch. Next, it checks if the validator is currently active and has an effective balance less than or equal to the ejection balance threshold. If both conditions are met, it initiates the validator exit process and marks the validator for removal from the active set. Subsequently, it forms an activation queue by iterating over validators to collect the indices of validators that are eligible for activation but have not yet been dequeued for activation. The queue is sorted based on the activation eligibility epoch setting and then by index. Finally, it dequeues validators from the activation queue for activation, up to the churn limit. For each dequeued validator, it sets the activation epoch to the computed activation exit epoch based on the current epoch.

Fig. 8

The detailed process of handling registry updates of validators, for their activation or exit from the network

4.4 Process Slashings

In the Beacon Chain reference implementation, the process of slashing is initiated after calculating rewards and penalties, targeting validators in the list of eligible entities subject to slashing. The flow of this slashing process is illustrated in Fig. 9. The process is initiated by retrieving the current epoch from the state where the slashings will be applied. Then compute the total balance of active validators during that specific epoch. After computing the total active balance, it calculates the adjusted total slashing balance. This adjustment ensures a proportional slashing balance without exceeding the total active balance. Then start iterating over the validators list in the state by checking if they belong to the slashed list or if their withdrawal criteria are met according to the slashing vector. If yes, then calculate the penalty accordingly, and further apply the computed penalty by decreasing the balance of the corresponding validator in the state. The iteration continues until all validators in the list have been processed.

Fig. 9

A visual representation of the steps involved in process slashings in the Beacon Chain

4.5 Algorithms

This section describes the algorithms designed for process epoch, rewards and penalties, registry updates, process slashings, resets, effective balance updates, and other updates in the context of the Ethereum 2.0 Beacon Chain.

The Algorithm 1 describes a structured approach responsible for coordinating the various tasks that need to be performed at the start of a new epoch (line 1). Each step is a separate function responsible for the specific processing related to that aspect of the epoch transition. The first process involves handling the justification and finalization of the checkpoints (line 2). It likely includes checking if the conditions for justification and finalization are met based on the state of the Beacon Chain. In the next step, the rewards and penalties are calculated and applied to validators based on their behavior during the epoch (line 3 Algorithm 2). Validators may be rewarded for good behavior and penalized for misbehavior. The next process is responsible for managing updates to the validator registry (line 4 Algorithm 8). It may include adding or removing validators based on specific criteria or changes in the network. The validators who have violated certain rules are slashed through this process (line 5 Algorithm 9). The process identifies and penalizes validators who have not adhered to the protocol rules. The next step involves resetting various aspects of the state (line 6 Algorithm 10). It includes resetting Eth1 data, randao mixes, historical roots, or other components that need periodic resetting. The effective balances of validators are updated in this step, which may change based on the performance and actions of validators during the epoch (line 7 Algorithm 11). The last step performs additional updates to the state that require modification or adjustment for the next epoch (line 8 Algorithm 12). Various aspects including historical roots, which are snapshots of certain state information, are updated. The participation records of validators are updated, reflecting their activity and contributions during the epoch.

The Algorithm 2, explains the procedure for applying rewards and penalties to the balances of validators in the state accordingly (line 1). The process begins by checking if the current epoch equals the genesis epoch. If true, it immediately exits indicating that no rewards are applied at the end of the genesis epoch because rewards are meant for work done in the previous epoch (lines 2–3). If the current epoch is not the genesis epoch, the process proceeds to calculate rewards and penalties through AttestationDeltas. The result is a list containing rewards and penalties for all the validators (lines 4–6). It then iterates over each validator in the state. For each validator, the balance is increased based on the corresponding reward list index. The balance of specific validators also decreases based on the corresponding index in the penalty list (lines 7–9). After calculating and applying the rewards and penalties to each validator, the process returns an updated state.

The process of AttesttionDeltas is described in Algorithm 3, which takes the state as input and returns the rewards and penalty lists for all the validators in the current state (line 1). The rewards and penalties lists for source, target, and head attestations are obtained from the GetDeltas (lines 2–4 Algorithm 4). Then the inclusion reward list gets from InclusionDelayDeltas because no penalties are associated with inclusion delay (line 5 Algorithm 6). The inactivity penalties list is obtained from InactivityPenaltyDeltas, as no rewards are associated with inactivity (line 6 Algorithm 7). After that, for each validator in the state, the total rewards are calculated by adding the obtained values of source, target, and head vote attestations, as well as inclusion delay rewards (lines 7–8). Further, the penalties for each validator are calculated by summing all the above calculated source, head, target, and inactivity penalties (lines 9–10). In the of the process, the updated lists of rewards and penalties are returned (line 11).

The Algorithm 4, describes the GetDeltas process, it takes the state as input and returns rewards and penalty lists for the proper FFG source, target, and head attestations (line 1). The list of attestations that match with the source epoch is obtained by getMatchingSourceAttestations function with the current state and the previous epoch (line 3). These attestations are forwarded to the AttestationComponentDeltas function to generate the rewards and penalties list based on the source attestations in the current state (line 4). The list of attestations that match the target epoch is obtained through getMatchingTargetAttestations function with the current state and the previous epoch (line 6). To obtain the rewards and penalties for these target attestations, the AttestationComponentDeltas function is used (line 7). Next, the head vote attestations list is obtained from the getMatchingHeadAttestations function for the previous epoch and passes the head attestations to the AttestationComponentDeltas (lines 9–10). The GetDeltas process returns a list containing two Gwei sequences, representing the rewards and penalties for each validator based on their participation in source, target, and head vote attestations (line 12).

This Algorithm 5, is defined to compute the rewards and penalties for validators based on the pending attestations in the state (line 1). Two lists are initialized with zeros by the number of validators in the state to store the rewards and penalties for each validator (lines 2–3). The total active balance of validators is calculated using the getTotalActiveBalance function (line 4). Then the indices list of attesting validators that are not slashed is obtained from the getUnslashedAttestingIndices function according to the pending attestations list (lines 5–6). The attesting balance is calculated through the getTotalBalance function based on unslashed attesting indices (line 7). After that, it iterates over the indices of eligible validators, where each validator index i is obtained by the function getEligibleValidatorIndices (line 8). This function identifies validators who are eligible based on whether they were active in the previous epoch or have been slashed and are past their withdrawable epoch. Obtaining eligible validators allows the protocol to differentiate between validators who meet specific requirements and those who do not, enabling appropriate actions to be taken based on their status within the network. The condition checks if the validator at the given index i has provided attestations and has not been slashed for any misconduct (line 9). The increment variable holds a constant value EFFECTIVE_BALANCE_INCREMENT that represents the increment used in calculating the base reward for validators (line 10). The next condition checks if the system is in an inactivity leak state. In an inactivity leak, validators may face penalties for not participating optimally. If a validator is actively participating (attesting) and is not slashed, then the base reward is computed with the getBaseReward function and added to their total rewards. The base reward is a portion of the overall rewards distributed to validators (lines 11–12). Otherwise, calculate the reward numerator using the formula where the total balance of validators is divided by the increment to check how many times the increment fits into the attesting balance. The result is then multiplied with the base reward and stored in the reward numerator. The reward is calculated by dividing the total balance by the increment value. Then the reward numerator is divided by this output, and the resulting amount is added to the rewards list corresponding to the validator’s index (lines 14–17). If the validator does not belong to unslashed attesting indices it means the validator is slashed, and will receive a penalty. Add the calculated penalty to the penalties list for the specified validator at the given index (lines 18–20). The penalty is based on the base reward, which is subtracted from the validator’s balance as a consequence of not actively participating or engaging in malicious behavior. After all the computation the updated rewards and penalties lists are returned, reflecting the changes made in either the rewards or penalties based on the validator’s behavior (line 21).

The Algorithm 6 describes the process of calculating rewards for validators based on their role as a proposer and their inclusion delay in the source attestations (line 1). At first, a list is initialized with zeros to store rewards for each validator in the state (line 2). The matching source attestations list is obtained from the previous epoch of the state by the function getMatchingSourceAttestations (line 3). Then it iterates over each validator indices that are unslashed and has participated in attesting to some source attestations. These indices are obtained from getUnslashedAttestingIndices function. For each index i, find the attestation with the minimum inclusion delay among the matching source attestations. Filter the matching source attestations to include only those, where the validator index i belongs to attesting indices (lines 4–7). This list of attestations is crucial for determining the rewards and penalties for the validators in the subsequent calculations. Then calculate the proposer reward for the validator at index i using the getProposerReward function and add it to the corresponding entry in the list of rewards (lines 8–9). The max attester reward is calculated by subtracting the base reward and proposer reward (line 10). The rewards list is updated for the validator based on the max attester reward and the inclusion delay of the attestation (line 11). The penalties list is sets to zero as no penalties are associated with the inclusion delay in this specific context (line 12). As a result, this process returns the calculated inclusion delay rewards and penalties lists (line 13).

The inactivity penalty deltas process is described through Algorithm 7, it takes state and calculates inactivity penalties and rewards for each validator based on their behavior during the inactivity leak period (line 1). If a validator is not attesting as expected, inactivity penalties are applied. Firstly, the list of penalties is initializes with zeros to store the inactivity penalties for specific validators (line 2). If the system is in the inactivity leak state, this is verified using the isInactivityLeak function (line 3). If it is true, then obtain the matching target attestations for the previous epoch using the getMatchingTargetAttestations function (line 4). Further, it gets the indices of unslashed validators who attested to the matching target attestations using the getUnslashedAttestingIndices function (line 5). Then iterates over all eligible validator indices, obtained from the getEligibleValidatorIndices function, and retrieves the base reward for each validator in the state through the getBaseReward function (line 6–7). The total reward is computed by multiplying the base reward with BASE_REWARDS_PER_EPOCH value, then subtract the proposer’s reward from the total reward to get the penalty for the validator (lines 8–9). The penalty list is then updated by adding the calculated penalty value for the specific validator (line 10). After that, the condition checks if the validator is not part of the set of validators attesting to the target checkpoint (line 11). Then retrieves the effective balance of that validator from the state (line 12). After that, calculates the balance by taking the product of the effective balance and the finality delay, and dividing the total penalty by the inactivity penalty quotient to get the final penalty for the validator (lines 13–14). The calculated penalty value adds up for that validator and updates the penalty list (line 15). On the other hand, the list of rewards is initializes with zeros for each validator, as in this case there are no rewards associated with inactivity penalties (line 17). In the end, the process returns a list of the rewards and calculated inactivity penalties list (line 18).

This Algorithm 8 explains the process of registry updates, which handles the validator’s exit and activation (line 1). The process starts with a loop that iterates over each validator V in the validators’ set in state to check if the current validator is eligible for the activation queue (line 2). If yes, then set the activation eligibility epoch of the validator to the next epoch for its activation(lines 3–4). For the exit procedure, it checks if the validator is currently active in the state through isActiveValidator function, and if its effective balance is less than or equal to the ejection balance threshold. If conditions are met, then it initiates the exit process for that validator in the state through initiateValidatorExit function (lines 5–8). After that, an activation queue that contains indices of validators that are eligible for activation is created. The activation eligibility epoch setting is used to sort the queue, followed by the index (lines 9–11). A loop is initiated over the validators in the activation queue to dequeue them for activation, with its iteration restricted by the churn limit. The activation epoch of each dequeued validator is established, setting it to the activation exit epoch determined by utilizing the computeActivationExitEpoch function with the current epoch (lines 12–14).

This Algorithm 9, is designed to process slashings for validators in the current state, applying penalties based on the specified conditions (line 1). Initially, the function retrieves the current epoch from the state by invoking getCurrentEpoch function (line 2). Then it obtains the total balance by the getTotalActiveBalance function, which aggregates the effective balances of all active validators (line 3). The constant value stores the PROPORTIONAL_SLASHING_MULTIPLIER (line 4). The adjusted total slashing balance is calculated as the minimum between the total balance and the sum of slashings multiplied by the constant value (lines 5–6). This ensures that the slashing balance does not exceed the total active balance. Next, the process iterates through the validators list in the state to checks if the validator is slashed and if the sum of the current epoch and half of the slashings vector duration matches the validator’s withdrawable epoch (lines 7–9). If true, it means that the slashing penalty is applied only to validators eligible to withdraw. Then assigns the constant value EFFECTIVE_BALANCE_INCREMENT to the variable named increment, which is factored out to avoid potential overflow (line 10). The numerator of the penalty is calculated by dividing the effective balance of the validator with the multiplication result of increment value with the adjusted total slashing balance (lines 11). The final penalty is calculated by dividing the penalty numerator by the result of the total balance multiplied by the increment (line 12). In the end, it applies the penalty to the specific validator through the decreaseBalance function which deducts the balance of the validator by the calculated penalty (line 13).

The Algorithm 10 is designed to process various resets for the given state, including resetting Eth1 data, slashings, and randao mixes based on specific conditions (line 1). To reset lists for the next epoch, the process retrieves the current epoch from the state using the getCurrentEpoch function (line 2). The next epoch is computed by incrementing the current epoch by 1 (line 3). Then checks if the next epoch is a multiple of the specified number of epochs per Eth1 voting period (line 4). If the condition is true, it resets the Eth1 data by setting the eth1 data votes in the state to an empty list, ensuring a fresh start for collecting new Eth1 data votes as the protocol progresses from one epoch to the next (lines 5–6). This process also resets slashings for the specific vector corresponding to the next epoch in the slashings array. The modulo operation % ensures that the index remains within the bounds defined by EPOCHS_PER_SLASHINGS_VEC-TOR. The value is set to 0, effectively resetting the slashings for the upcoming epoch (line 8). For the randao mixes, it resets the specific index corresponding to the next epoch in the randao mixes array. The reset value is obtained using the getRandaoMix function with the current epoch (lines 10–11).

The Algorithm 11 is designed for adjusting the effective balances of validators with hysteresis. It prevents frequent adjustments by using thresholds and ensures that the effective balance remains within certain bounds. The adjustments are based on the comparison of the current balance with the current effective balance and the defined thresholds. It takes the state as input and returns after updating the effective balances (line 1). A loop is initiated that iterates through each validator in the state, and for each validator, it retrieves the current balance from the state’s balances list (lines 2–3). Then it defines constants related to hysteresis for effective balance updates. HYSTERESIS_INCR is the increment for hysteresis, DOWNWARD_THRESHOLD is the threshold for downward adjustments, and UPWARD_THRESHOLD is the threshold for upward adjustments (lines 4–9). The condition checks if the current balance plus the DOWNWARD_THRESHOLD is less than the validator’s effective balance or if the validator’s effective balance plus the UPWARD_THRESHOLD is less than the current balance (lines 10–11). If the condition is true, it updates the validator’s effective balance. The new effective balance is calculated by taking the minimum value between MAX_EFFECTIVE_BALANCE and subtracting the remainder of the balance divided by EFFECTIVE_BALANCE_INCREMENT from the balance. The min ensures that the effective balance does not exceed max effective balance (lines 12–14).

The Algorithm 12 is described to manage various updates within the state (line 1). The updates are for the next epoch which is calculated by adding 1 to the current epoch (line 3). If the next epoch is a multiple of the number of slots per historical root divided by the number of slots per epoch. If the condition is true, it indicates that it’s time for historical roots updates (lines 4–5). Then a batch of historical data is created, which includes block roots and state roots from the state (line 6). The hash tree root of the historical batch is computed and this root is then added to the historical roots list of the state (line 7). After that, it moves towards the updation of the participation record. Essentially, it rotates the attestation records, making the current epoch’s attestations as the previous epoch’s attestations (line 9). Following the rotation, it resets the attestation records for the current epoch to an empty list, preparing it to accumulate new attestations for the upcoming epoch (line 10). This type of record management is crucial for protocol functionalities, analyses, and historical data retention.

5 Formal Specification of Epoch Processing in Beacon Chain

In this section, the formal model of the Python reference implementation of epoch processing is described using CSP#. The functions of the reference implementation are specified as processes. The properties of rewards, penalties, and ensuring the updation of the balance are specified through LTL and are verified using the PAT model checker.

The formal specification of the epoch processing includes several processes such as, processing of rewards, registry updates, processing of slashings, eth1_data_reset, effective balance updates, slashings and randao mixes reset, historical roots and participation record updates. After this, the next epoch starts.

The formal specification of rewards and penalties is described as a process $process\_~rewards\_~and\_~penalties$ (line 2). The process skips if the current epoch is the genesis epoch. Otherwise, the rewards and penalties are processed in the $call\_~proce$-$ss\_~rewards\_~and\_~penalties$.

The updates in the registry are described in the $process\_$ $~registry\_~updates$ (line 4). For all the validators, it is checked that if a validator is eligible for activation queue then the activation eligibility epoch of that validator is set as the next epoch (lines 4.1$-$4.2). It is also checked that if a validator is currently active and its effective balance is less than or equal to a predefined EJECTION BALANCE, a constant value, then the exit of the validator is initiated (line 4.3). A sorted list of eligible validators for activation is stored in the activation queue (line 4.4). For all the validators in the activation queue up to the churn limit, the activation epoch of each validator is set by computing activation exit epoch (line 4.5).

The process of slashings is specified on line 5. Firstly, it calculates the total active balance by summing up the effective balances of all active validators (line 5.1). It computes the adjusted total slashing balance, that is the minimum of the sum of all slashings in the state multiplied by a constant $PROPORTIONAL\_SLAS$ $HING\_MULTIPLIER$ and the total active balance (line 5.2). For each validator in the state, it is checked that if a validator is slashed and the current epoch plus half of the $EPOCHS\_PER\_SL$ $ASHINGS\_VECTOR$ equals to the validator’s withdrawable epoch then the penalty is applied only for validators that are eligible to withdraw (lines 5.3$-$5.4). The penalty is computed by calculating the penalty numerator, total balance, and the effective balance increment (line 5.4.1). At the end, it applies the penalty to the validator by decreasing its balance (line 5.4.2).

The process $process\_~eth1\_~data\_~reset$ (line 6) is called at the start of each epoch to determine whether a new eth1 data voting period has begun. If this is the case, the list of eth1 data votes is reset (line 6.1).

The formal specification of the process $process\_~effective\_$ $~balance\_$  updates updates the effective balance of a validator based on hysteresis conditions (line 7). Hysteresis is used to prevent frequent updates in the balance and to keep validators’ effective balances stable. Depending on the current balance, the process modifies the effective balance within given thresholds. At first, the process iterates over the state validators and records the balance of each validator. It computes the $HYSTERESIS\_~INCREMENT$ through the $EFFEC$ $TIVE\_$ $BALANCE\_~INCREMENT$ and $HYSTERESIS\_QUO$ $TIENT$. The downward and upward threshold are then calculated. If the computed balance and downward threshold are less than the validator’s effective balance or the upward threshold and the validator’s effective balance are less than the balance stored in the state then effective balance of the validator is set.

The formal specification of $process\_~slashings\_~reset$ is described below (line 8). It is invoked before the start of next epoch to reset the slashing balances guaranteeing that the slashing balances are unique to each epoch and does not accumulate endlessly.

Table 5 Verification results for rewards and penalties properties

In the process $process\_~historical\_~roots\_~update$ (line 10), it is described that when a certain number of epochs has passed, a new historical root is calculated and added to the list of historical roots in the state. This mechanism helps to maintain a historical record of the Beacon state at specific intervals.

The process $process\_~participation\_~record\_~updates$ is specified to rotate or organize the records of attestations in a blockchain’s state between epochs (line 11). The value of current epoch attestations is assigned to the previous epoch attestations list in the state. It happens while shifting to the next epoch. After this, the list of current epoch attestations in the state is set to empty to make space for the new attestations in the upcoming epoch.

In order to formally verify the processes described earlier, the process TestSpec is defined (line 12) that is helpful to specify the properties which will be described in the next section. For all the eligible validator indices to participate in the protocol, it is checked that if the proposer reward is greater than the rewards of other nodes then the maxPropRew  is set to true (line 12.1). If the balance of a validator is greater than or less than the maximum effective balance then it assures that the balance of an eligible validator is updated, i.e., it is rewarded or penalized for its behavior.

6 Results and Analysis

The formal verification of the formal model of the processing of epoch described in the previous section is performed through the PAT model checker. It is ensured that the formal model is deadlock-free. Moreover, the properties of rewards, penalties and balance updates are described through LTL and are verified using the PAT model checker.

6.1 Deadlock-Free

A deadlock-free model ensures that at any moment no process has to wait for another process to progress. It is shown in Table 5 that the formal model presented in this work is deadlock-free. The assertion P1 specified below for the processing of epoch is verified to be deadlock-free.

6.2 Proposer Reward

In the formal model, it is described that the proposer gets the maximum reward. It is specified below by an LTL formula that eventually always will be the case that the proposer reward becomes maximum. The Table 5 represents that the property is satisfied in our formal model.

6.3 Penalty

A validator is penalized if it is slashed and the current epoch plus half of the epochs per slashing vector become equal to the validators’ withdraw epoch as described earlier in the formal model. It is specified by an LTL formula P3 that infinitely often the validators are penalized. It is shown in Table 5 that the penalty property is verified in our formal model.

Fig. 10

Analysis of number of epochs versus time, states, transitions, and memory used for deadlock-free, reward, penalty, and balance update properties

6.4 Balance Update

In the formal model, it is specified that the balance of eligible validators to participate in the protocol is updated, i.e., either become greater than or less than the maximum effective balance. It means that either the validators are rewarded or penalized. The balance update property is specified below by an LTL formula P4. The Table 5 shows that the property is verified in our formal model.

6.5 Analysis of Properties

The formal verification of the specified formal model against the described properties has been performed on MacBook Pro, Apple M1 Max with 64 GB of memory, and and PAT version 3.5.1. The analysis of the deadlock-free, proposer reward, penalty, and balance update properties is presented in Fig. 10a–d. The horizontal axis shows the number of epochs and the vertical axis denotes the verification time in seconds, visited states, total transitions, and memory used for the described properties. A high increase in the verification time is observed for all these properties with the increase of number of epochs as presented in Fig. 10a. It is due to the time complexity of the model checking algorithm that is linear in the size of the transition system and exponential in the length of the formula [66]. Hence as the number of epochs increases, the complexity of the model checking also increases. Further the the state explosion problem occurs at epoch 135 in all these properties. The linear growth is observed for visited states and total transitions of these properties as presented in Fig. 10b–c. The estimated memory used by these properties is shown in Fig. 10d.

7 Conclusion and Future Work

The launch of the Beacon Chain in the domain of Ethereum blockchain stands as a significant development. The Beacon Chain serves as the foundation for Ethereum 2.0’s transition from PoW to PoS consensus mechanism, addressing scalability concerns and improving the network’s efficiency. The Ethereum 2.0 Beacon Chain introduces a novel incentive mechanism that is crucial for maintaining the network’s integrity and encouraging the participation of validators. The correctness of the incentive mechanism is paramount as it directly impacts the behavior of validators and the overall stability of the network. Therefore, formal verification of this mechanism is essential to ensure its reliability and trustworthiness. This paper presents the formal verification of the Ethereum 2.0 Beacon Chain, focusing on the critical aspects such as rewards and penalties. By leveraging formal methods-based techniques, i.e., model checking, we ensure the correctness and reliability of the Beacon Chain. This proactive approach not only enhances the integrity of a system but also minimizes the risk of financial losses and network compromise.

To gain a comprehensive understanding of the reference implementation Python code of the Beacon Chain, we have meticulously designed flow diagrams and algorithms for the processes. The algorithms of the processes are then converted into the formal model, where formal specifications are described using the CSP# language. After specifying the model, the important properties of deadlock-free, proposer reward, penalty, and balance update are described using Linear Temporal Logic (LTL) for the processes. Our utilization of CSP# for formal specification and LTL for property definition shows the versatility and effectiveness of formal methods in modeling and analyzing intricate systems like the Beacon Chain. The formal verification is conducted using the PAT model checker by providing the formal model and LTL properties as input. The PAT model checker assesses the correct execution of properties and verifies their adherence to the satisfaction criteria. Our analysis confirms that there are no deadlocks in the processes, rewards and penalties are eventually distributed fairly, and validators’ balances are updated correctly. The results for the verification of properties are analyzed for verification time, visited states, total transitions, and estimated memory. A high increase is observed for these parameters with the increase in the number of epochs. The chosen model checking technique has been proved to be highly effective for verification purposes and for enhancing the overall correctness of the system.

In the future, we aim to expand our efforts by formally verifying the complete state transition process, ensuring a comprehensive and robust validation of the Beacon Chain. Additionally, we intend to delve into the formalization of the fork choice rule and explore the behavior of honest validators, aiming to enhance the system’s reliability and integrity. Moreover, formal verification of further properties such as safety, persistence, and liveness within the Beacon Chain protocol will be done to ensure the elimination of undesirable states and encourage the system’s progression on time. We will also incorporate probabilistic verification into our research and consider extending formal verification techniques to other blockchain platforms. The state explosion problem will be handled in the future using advanced model checking techniques, such as symbolic [67] or bounded model checking [68].