Table of Links Abstract and 1. Introduction Abstract and 1. Introduction Bitcoin and the Blockchain 2.1 The Origins 2.2 Bitcoin in a nutshell 2.3 Basic Concepts Crypto Exchanges Source of Value of crypto assets and Bootstrapping Initial Coin Offerings Airdrops Ethereum 7.1 Proof-of-Stake based consensus in Ethereum 7.2 Smart Contracts 7.3 Tokens 7.4 Non-Fungible Tokens Decentralized Finance and 8.1 MakerDAO 8.2 Uniswap 8.3 Taxable events in DeFi ecosystem 8.4 Maximal Extractable Value (MEV) on Ethereum Decentralized Autonomous Organizations - DAOs 9.1 Legal Entity Status of DAOs 9.2 Taxation issues of DAOs International Cooperation and Exchange of Information 10.1 FATF Standards on VAs and VASPs 10.2 Crypto-Asset Reporting Framework 10.3 Need for Global Public Digital Infrastructure 10.4 The Challenge of Anonymity Enhancing Crypto Assets Conclusion and References Bitcoin and the Blockchain 2.1 The Origins 2.2 Bitcoin in a nutshell 2.3 Basic Concepts Bitcoin and the Blockchain 2.1 The Origins 2.1 The Origins 2.2 Bitcoin in a nutshell 2.2 Bitcoin in a nutshell 2.3 Basic Concepts 2.3 Basic Concepts Crypto Exchanges Crypto Exchanges Crypto Exchanges Source of Value of crypto assets and Bootstrapping Source of Value of crypto assets and Bootstrapping Source of Value of crypto assets and Bootstrapping Initial Coin Offerings Initial Coin Offerings Initial Coin Offerings Airdrops Airdrops Airdrops Ethereum 7.1 Proof-of-Stake based consensus in Ethereum 7.2 Smart Contracts 7.3 Tokens 7.4 Non-Fungible Tokens Ethereum Ethereum 7.1 Proof-of-Stake based consensus in Ethereum 7.1 Proof-of-Stake based consensus in Ethereum 7.2 Smart Contracts 7.2 Smart Contracts 7.3 Tokens 7.3 Tokens 7.4 Non-Fungible Tokens 7.4 Non-Fungible Tokens Decentralized Finance and 8.1 MakerDAO 8.2 Uniswap 8.3 Taxable events in DeFi ecosystem 8.4 Maximal Extractable Value (MEV) on Ethereum Decentralized Finance and 8.1 MakerDAO Decentralized Finance and 8.1 MakerDAO 8.2 Uniswap 8.2 Uniswap 8.3 Taxable events in DeFi ecosystem 8.3 Taxable events in DeFi ecosystem 8.4 Maximal Extractable Value (MEV) on Ethereum 8.4 Maximal Extractable Value (MEV) on Ethereum Decentralized Autonomous Organizations - DAOs 9.1 Legal Entity Status of DAOs 9.2 Taxation issues of DAOs Decentralized Autonomous Organizations - DAOs Decentralized Autonomous Organizations - DAOs 9.1 Legal Entity Status of DAOs 9.1 Legal Entity Status of DAOs 9.2 Taxation issues of DAOs 9.2 Taxation issues of DAOs International Cooperation and Exchange of Information 10.1 FATF Standards on VAs and VASPs 10.2 Crypto-Asset Reporting Framework 10.3 Need for Global Public Digital Infrastructure 10.4 The Challenge of Anonymity Enhancing Crypto Assets International Cooperation and Exchange of Information International Cooperation and Exchange of Information 10.1 FATF Standards on VAs and VASPs 10.1 FATF Standards on VAs and VASPs 10.2 Crypto-Asset Reporting Framework 10.2 Crypto-Asset Reporting Framework 10.3 Need for Global Public Digital Infrastructure 10.3 Need for Global Public Digital Infrastructure 10.4 The Challenge of Anonymity Enhancing Crypto Assets 10.4 The Challenge of Anonymity Enhancing Crypto Assets Conclusion and References Conclusion and References Conclusion and References 7.1 Proof-of-Stake based consensus in Ethereum Ethereum initially started as a blockchain based on the proof-of-work consensus mechanism but in order to reduce the negative externalities of proof-of-work, it switched to a proof-of-stake based consensus mechanism similar to one described in the section 2.3.9. The Ethereum proof-of-stake mechanism is based on each validator staking 32 ETH to be a part of the set of validators which propose and attest blocks. Besides this the validators have various other duties assigned to them, for which they get paid in the form of rewards at regular intervals. Any malicious behaviour by a validator is penalized through slashing – a mechanism in which the staked Ether is slashed for violating the proof-of-stake rules, it also results in removal of the validator from the network. The validators deposit 32 ETH in a smart contract on Ethereum and must wait for certain period in the activation queue before they can take part in proposing and validating blocks. The 32 ETH deposit is made to a smart contract that keeps track of all the staking validators. The validators specify a withdrawal address in the smart contract to which the payouts are made, as shown in Fig. 29 The depositor sends 32 ETH along with its public address and a withdrawal address to the smart contract. It is important to note that the staked ETH becomes a part of the consensus layer and is accounted for separately from Ether in execution layer Ethereum accounts and contracts. No Ethereum execution layer transactions can be run on staked ETH and no transfers can be made between validator accounts. The validators can top-up their ETH balance on the smart contract later if it goes below 32 ETH. The validators are rewarded for proposing as well as validating proposed blocks with a part of the user fee and newly issued ETH by the Ethereum consensus layer known as ‘Issuance.’ The validators are also penalized if they do not complete their assigned duties of block proposal and validation. However, these penalties are much less severe than the slashing penalties which are levied for malicious behaviour. The base fee in each block is burnt in accordance with EIP 1559[74] which may be smaller or larger than Issuance for the block. Validators are paid rewards at regular intervals of time. At any point if a validator is found violating proof-of-stake rules, its deposit is slashed and it exits the system. The remaining deposit of a slashed validator can only be withdrawn after certain time has elapsed. If a validator voluntarily decides to withdraw its stake and cease to be a part of the Ethereum consensus mechanism, it can initiate a withdrawal and if no breaches of the proof-of-stake rules are found, the entire staked ETH is returned to the validator which can be withdrawn after a certain interval. No gas is required for this transaction. The flowchart depicting deposits and withdrawals in the Ethereum proof-of-stake smart contract is given in Fig. 30 [75] The system of entry and exit of validators is not instantaneous to maintain a stable pool of validators over a certain period. The proof-of-stake based consensus mechanism in Ethereum is like a voting-based mechanism in which the validators carry out the functions proposing the next blocks of the blockchain as well as attesting the blocks proposed by others. The attestation of a block is essentially a vote on the validity of the block and its inclusion in the blockchain. The validators maintain the integrity of the blockchain by honestly carrying out the duties assigned to them, with the other validators keeping an eye over their conduct. The mechanism is designed such that it incentivises honest behaviour by the validators and places heavy penalties on dishonest behaviour by the validators. In the proof-of-work consensus mechanism, the high capital required for establishing a mining farm along with its high running costs creates barriers to entry in the mining ecosystem and plays a major role in incentivising honest behaviour by the validators. Similarly, in the proof-of-stake based consensus mechanism of Ethereum, staking of 32 ETH by each validator creates a high capital requirement. Ethereum tries to achieve consensus amongst the set of validators through a combination of two different consensus mechanisms – the Latest Message Driven Greedy HeaviestObserved Sub-Tree (LMD GHOST) and the Casper Friendly Finality Gadget (Casper FFG). The LMD GHOST is different from the longest chain rule in the Bitcoin Blockchain and the proof-of-work based Ethereum as it counts every block in a fork as a vote, even if they are conflicting blocks and not a part of the longest chain. This means that the fork with the highest number of validator votes is the one to which new blocks are added. 7.1.1 Slots and Epochs 7.1.1 Slots and Epochs Time periods on the Ethereum Blockchain are divided into slots and epochs. One slot which results into a block proposal and attestations is 12 seconds long and 32 slots together form an ‘epoch’ as shown in Fig.31. By design, in Ethereum every 12 seconds a random validator is chosen to propose a block to be added to the Ethereum Blockchain. The block proposed by the validator needs to be verified by other validators in the validator set through an ‘attestation.’ These validators, other than the proposer have a responsibility for verifying the proposed block if it is correct. Attestations include information about the current block the validators are attesting to, as well as the previous block they are building upon. However, not all the validators are required to attest every block and, in each epoch, the set of validators is distributed into 32 randomly chosen committees, with each committee being responsible for one slot which is 12 seconds long. At the start of each slot, the first validator of the committee proposes a block to be added to the Ethereum Blockchain. The rest of the members of the committee are supposed to attest the proposed block. Validators attest to the validity of proposed blocks by signing and broadcasting attestations. A validator can only attest one block per slot in an epoch and any violation of this results into slashing. Each proposer validator is required to propose a block in the first 4 seconds of the slot, failing which the validators in the committee are required to attest the previous block. Considering the current number of validators is >800,000 each committee is likely to consist of >25000 validators. It is an uphill task to collect signatures of so many validators for each slot. Consequently, validators in each committee are further divided into 128 subnets, as shown in Fig. 32, and validators produce an aggregate BLS signature in each subnet. Validators in the committee collect all the individual BLS signatures they receive and aggregate them into a single BLS signature using a process called "signature aggregation." This aggregation is possible because of the unique additive property of BLS signatures, allowing multiple signatures to be combined into one without losing any security properties. By collecting attestations from an ample number of validators, the network can finalize blocks, guaranteeing their inclusion in the Ethereum Blockchain and making them resistant to reversal unless a substantial portion of the validator set collaborates to do so. The choice of the block proposal and assignment of validators into committees and subnets is dependent on an Ethereum Blockchain process that generates a pseudo-random number. The random number is generated on Ethereum using an algorithm called RANDAO[78]. The validator selection is fixed two epochs in advance. This implies that validators know a few minutes in advance about their upcoming proposer or attestation duties. This process pre determines a small set of 64 validators who are entrusted to propose blocks for each slot in the two epochs (12 mins 48 seconds). Besides the LMD GHOST which provides the fork choice rule[79], the Ethereum Blockchain also aims to achieve finality in the blockchain through the Casper FFG which is a Practical Byzantine Fault Tolerance (PBFT) inspired and improved consensus protocol. Finality refers to the guarantee that a block cannot be altered or removed from the blockchain without burning at least 33% of the total staked Ether. Finality in Casper FFG is achieved through “checkpoint” blocks, which are always the first blocks in an epoch. Validators agree on the state of a block at checkpoint blocks, and if two-thirds of the validators agree, the block is finalized. It usually takes two epochs for the Ethereum Blockchain to attain finality as by the end on two epochs >2/3rd of the validators likely vote for two ‘checkpoint’ blocks. If a block is not able to exceed the two-thirds threshold, finality is not achieved, the fork choice rule would kick-in to determine which chain to follow and finality will be achieved when the 2/3rd majority is met. If finality is not achieved for more than four epochs, ‘inactivity leak’ mechanism gets activated. The inactivity leak is a feature of the Ethereum proof-of-stake consensus mechanism that is activated when the network fails to finalize a checkpoint for more than four epochs (25.6 minutes). The inactivity leak is designed to restore finality in the event of the permanent failure of large numbers of validators. It does so by gradually reducing the stakes of validators who are not making attestations until the remaining validators control two-thirds of the stake and can resume finalizing checkpoints. The inactivity leak also prevents validators from receiving attestation rewards during this period, to discourage attacks that might deliberately cause the network to lose finality. 7.1.2 Rewards and Penalties 7.1.2 Rewards and Penalties To incentivise the validators, the Ethereum Blockchain offers rewards to the participants in the network. Also, to penalize behaviour that is detrimental or outrightly malicious, the Ethereum Blockchain also has a system of penalties and slashing which act as a deterrence against such behaviour. 7.1.2.1 Rewards 7.1.2.1 Rewards The main rewards which validators receive in the Ethereum ecosystem are the newly issued Ether created by the protocol and the transaction fee paid by the users transacting on the Ethereum Blockchain. The validators are assigned various duties like proposing and attesting blocks in a slot as well as participation in sync committees and they receive rewards for correct and timely performance of these duties. ‘Correct’ attestation implies that the attestation of the block by the validator agrees with the fork choice of the block proposer. This ensures that only participants in the winning fork (in case of an available fork choice) receive the rewards. Failure in performing duties in the specified timeframe results in missed rewards. The block proposers are also rewarded for reporting any violations of the slashing rules, which may not happen so often. In a block, majority of rewards of the validators come from attestations. An attestation contains three votes and each vote is eligible for a reward if it satisfies the conditions given in Table 5: Even if the above duties are performed in a timely manner by the validator, it may not receive the rewards due to various extraneous factors like the block proposer missing to propose a block within 4 seconds in a slot, or the block proposer proposing a block on a minority fork which is discarded after a few blocks. Thus, the rewards accrued to the validator due to randomness in allocation of duties as well as other extraneous factors stated above have a variance and vary over time. The breakdown of expected rewards for proposers and validators is given in Fig. 33 Sync committees allow light Ethereum clientsto keep track of the chain of beacon block headers. Light clients are nodes that do not download the entire blockchain, but only rely on the block headers and some cryptographic proofs to verify the state of the blockchain. Sync committees are groups of 512 validators that are randomly selected every 256 epochs (about 27 hours). They are responsible for signing the block headers that are the new head of the chain at each slot. The signatures of the sync committee members are broadcast to the network and are used by light clients to authenticate the block headers without downloading the full blocks. Validators are rewarded for participating in sync committees. The maximum amount of newly issued Ether per year – Annual issuance, is proportional to the square root of the number of validators in the network. However, the annual returns of the validators are inversely proportional to the square root of the number of validators. This results in a design like the proof-of-work based consensus where the difficulty level of the target hash is related to the overall hashing power of the network. Similarly, in Ethereum as the number of validators increases the annual return on staked Ether goes down and vice versa, resulting in an optimal number of validators being present in the Ethereum consensus protocol. Mathematically Here 𝑁 is the number of validators on the Ethereum consensus layer. This mechanism helps the consensus layer in reaching the equilibrium number of validators at a given time. 7.1.2.2 Penalties and Slashing 7.1.2.2 Penalties and Slashing To create negative incentives for validators who fail to contribute in a desired manner to the Ethereum Blockchain, penalties are levied. The validators are penalized for incorrect, late, or missing attestations(votes). The validators are penalized for incorrect, late, or missing source[82] and target votes[83] but there is no penalty for a missed head vote[84]. Besides this, validators who fail to participate in sync committees receive a penalty equal to the reward they would have earned had they participated in the committee correctly. These penalties act as ‘sticks’ in the consensus protocol to motivate the validators to perform their duties diligently. However, these are not penalties for malicious behaviour or potential attacks on the protocol. The mechanism to deal with malicious activity on the Ethereum consensus layer is Slashing. Upon detection of violation of rules or any dishonest behaviour by a validator the Stake of such validator is slashed and it is removed from the network. Slashing protects the protocol against any attacks. For example, it prevents a validator from voting for two blocks in the same slot. Also, the incentive to the block proposers for reporting any violations of slashing rules acts as a protection against such malicious behaviour. The penalties and slashing mechanisms in the Ethereum consensus layer have important tax implications which are related to the admissibility of the such penalties and slashing to be allowed as an admissible expense. While penalties can be allowed, as they might be caused due to bona fide reasons, the stake of a validator slashed due to malicious behaviour may not be allowed as an expense for the purpose of taxation. 7.1.3 Staking Pools 7.1.3 Staking Pools When an individual/entity runs an Ethereum validator node on its own and makes the entire 32 ETH deposit it is said to be involved in ‘Solo’ staking. Solo staking also involves a reasonable degree of technical knowledge and the validators retain the full control of the keys of their deposited Ether. This form of staking also involves incurring the hardware and operational costs only, without paying any service fee to staking pools, resulting in higher profits. It also helps to prevent the accumulation of majority stake with one central entity on the consensus layer. For the validators who have access to the required capital but do not possess the required knowhow or do not want to run a validator node, usually delegate the technically difficult tasks to a service provider for a fee. The validators retain the control of the keys of their deposited Ether and do not need to purchase any hardware or software to run validator nodes. However, this method of staking might involve increased third party risks due to potential downtime or bugs with the software of the service provider. The 32 ETHs required to be deposited for being a validator on the Ethereum consensus layer is a significant barrier to entry for individuals/entities which want to participate in the consensus mechanism and earn rewards. Those inclined to participate in staking who do not possess the required capital or those who want to earn rewards over and above the staking rewards collaborate and stake Ether through a staking pool. Various stakers who possess smaller amounts of ETH collaborate and pool their assets to participate in staking on the Ethereum consensus layer and earn rewards. In many staking pools the depositors are issued tokens that represent a claim on the staked ETH amount and its associated rewards. For example, on depositing ETH on a popular staking platform LIDO, the depositor gets and equivalent number of stETH tokens which are pegged 1:1 with Ether and can be traded or used like any other ERC token on Ethereum to earn additional income, over and above the staking rewards by transacting on various DeFi platforms as shown in Fig. 34 Consequently, more than 30% of the ETH currently deposited on the Ethereum consensus layer Deposit Smart Contract is staked through LIDO[85]. The stakers on such platforms have a choice to run a pool node and get additional rewards for it. The stakers pay a commission/fee (For example LIDO charges 10%) which is split between the pool node operators and the Decentralized Autonomous Organization (DAO) of LIDO. 7.1.4 Taxation of Proof-of-Stake based consensus in Ethereum 7.1.4 Taxation of Proof-of-Stake based consensus in Ethereum The activities of the validators in the proof-of-stake based consensus in Ethereum and the rewards received by them can have direct and indirect tax implications as they result in accrual of income and involve providing certain services to the users of the Ethereum Blockchain. The main issues concerning the direct tax treatment of rewards accrued by staking revolve around the treatment of the reward as an active or passive income for the validator. For the levy of indirect taxes, the classification of nature of service provided by the validator, the classification of Ethereum as a negotiable instrument, property, asset etc. and the tax residency of the validation service recipient for ascertaining the place of supply would be important to determine the incidence of taxes. 7.1.4.1 Direct Taxes related to Proof-of-Stake based consensus in Ethereum 7.1.4.1 Direct Taxes related to Proof-of-Stake based consensus in Ethereum As discussed above, the validators in the Ethereum consensus layer receive rewards for block proposals and attestation along with participation in sync committees and reporting any violation of the proof-of-stake rules. The rewards received by the validator above 32 ETH does not increase the weight of the validator in the consensus layer and is withdrawn automatically every few days as reward payment. The rewards are credited to the validator’s payout address at regular intervals and as these are initiated at the consensus layer, no gas is required for such payout transactions. The receipt of a staking reward by a validator would be a taxable event in most tax jurisdictions as it results in accession of wealth over which the validators have complete dominion. However, their tax treatment depends largely upon whether a jurisdiction considers the reward as a passive income for the stake deposited in the deposit contract by the validators or as an active self-employment income. The treatment would also be contingent upon the rewards being accrued because of solo staking or staking through a staking pool. To classify the income from staking as active or passive income it is important to understand the nature of relationship between: i) The Ethereum consensus layer and the Solo staking validator ii) The Ethereum consensus layer and the staking pool validator iii) The staking pool and person/entity contributing ETH to the staking pool and/or running a pool node. The solo and staking pool validators are assigned with specific duties and tasks of proposing and attesting blocks on the blockchain. They agree to the rules of the consensus layer protocol and receive regular rewards for performance of assigned duties. Moreover, they are also subject to penalties for downtime and malicious behaviour. Also, the rewards received cannot be considered a compensation for the use or forbearance of money. Thus, the solo validators can be subject to self-employment taxes in some jurisdictions and the associated social security contributions. Some jurisdictions may consider the fact that as staking involves little or no effort and can be earned without the active involvement of the person or entity, and tax it as a passive income akin to interest. The staking pool validators, being involved in the business of staking would be treated correspondingly. The taxpayers earning income by contributing ETH to a staking pool cannot be considered to be self-employed as instead of the contributors, the staking pool/pool node operator is assigned with specific duties and tasks of proposing and attesting blocks on the blockchain and is also subject to penalties for downtime and malicious behaviour. The rewards accrue to them on the Ethereum execution layer through the staking pool instead of the consensus layer. Thus, they may not be subject to self-employment taxes and the corresponding social security contributions. The accrual and/or ‘disposal’ of the rewards would be a taxable event in most tax jurisdictions and attract income tax or a capital gains tax. If the validators are engaged in the business of providing validation services on a commercial scale, the income might be taxed as business income. The fair market value of the rewards at the time of accrual would be the basis for calculation of the capital gains tax. In this ecosystem, the staking pools are also likely to accrue income as an entity, which usually exists as a Decentralized Autonomous Organization. For example, LIDO which is the leading staking pool on Ethereum operates as a Decentralized Autonomous Organization. The tax issues related to such entities are discussed in subsequent sections. 7.1.4.2 Indirect Taxes related to Proof-of-Stake based consensus in Ethereum 7.1.4.2 Indirect Taxes related to Proof-of-Stake based consensus in Ethereum The validators, staking pools, the individuals/entities that contribute to the staking pools and Ethereum users involved in providing or receiving services may be subject to indirect taxes depending upon: i) The nature of service provided ii) The place of supply of services iii) The recipient of the services The solo validators and staking pools are involved in providing validation services to the users carrying out transactions on the Ethereum Blockchain and may be considered to be self-employed. They essentially provide two kinds of services, those to the users carrying out transactions on the Ethereum Blockchain (for which they get rewarded in the form of transaction fee) and to the Ethereum consensus layer for finalizing blocks (for which they get rewarded in the form of newly issued ETH). For the transaction validation services to the user, the validators might be subject to GST if the validator is a resident of the jurisdiction same as that of the validator. Services provided by the validator to users in other jurisdictions would constitute an export of services and would be zero rated in most jurisdictions. In case of Ethereum, taxation of services provided by the staking pools or solo stakers to the Ethereum Blockchain itself, for which they receive the issuance reward programmed in the Ethereum Blockchain, would be a complicated issue. In this case also, the place of supply of such service cannot be determined and the payment for the service may amount to billions of dollars each year. Mechanism like those described in section 2.3.8.1 for collecting indirect taxes on miners and mining pools in Bitcoin can be applied for services of staking pools and solo stakers. In case of other models of staking like using Staking-as-a-Service the services provided by the staking service provider might also be subject to GST depending upon the place of supply and the residency of the staking service provider and the individual/entity staking the ETH. In the case of staking pools, the commission charged by the pools would also be subject to GST as it is in lieu of a service provided to the depositors. As discussed in the case of mining rewards, only the direct validation services provided to the Ethereum users and the consensus protocol may be considered exempt services as other services would largely qualify as input to validation services. Similar to the treatment of miners providing services to users in other jurisdictions, the validators providing zero-rated services might be entitled to refunds for the input taxes paid for exporting the service. 7.1.4.3 Taxes on MEV rewards on Ethereum 7.1.4.3 Taxes on MEV rewards on Ethereum As described above the users broadcast their transactions on the Ethereum Blockchain into a ‘mempool’ and the validators which are supposed to propose blocks in a slot bundle the transactions into a ‘Block’. As all the mempool transactions are visible to everyone, the validators can also come to know about potential arbitrage opportunities on various DeFi applications. This can enable the validators to ‘front run’ such transactions to extract a profit by altering the order of transactions. This is known as Maximal Extractable Value on the Ethereum Blockchain and acts as an ‘invisible tax’ on Ethereum users and leads to imperfect markets. The role and taxation of MEV Ecosystem on the Ethereum Blockchain is described subsequent to the section on DeFi as the readers can better appreciate the mechanism through which value is extracted by validators and other actors by reordering DeFi transactions. Author: (1) Arindam Misra. Author: Author: (1) Arindam Misra. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv available on arxiv https://eips.ethereum.org/EIPS/eip-1559 https://notes.ethereum.org/@hww/lifecycle https://ethos.dev/beacon-chain https://ethos.dev/assets/images/posts/beacon-chain/Beacon-Chain-Slots-and-Epochs.png.webp https://ethereum.org/gu/developers/docs/consensus-mechanisms/pos/block-proposal/ https://eips.ethereum.org/EIPS/eip-1559 https://eips.ethereum.org/EIPS/eip-1559 https://eips.ethereum.org/EIPS/eip-1559 https://notes.ethereum.org/@hww/lifecycle https://notes.ethereum.org/@hww/lifecycle https://notes.ethereum.org/@hww/lifecycle https://ethos.dev/beacon-chain https://ethos.dev/beacon-chain https://ethos.dev/beacon-chain https://ethos.dev/assets/images/posts/beacon-chain/Beacon-Chain-Slots-and-Epochs.png.webp https://ethos.dev/assets/images/posts/beacon-chain/Beacon-Chain-Slots-and-Epochs.png.webp https://ethos.dev/assets/images/posts/beacon-chain/Beacon-Chain-Slots-and-Epochs.png.webp https://ethereum.org/gu/developers/docs/consensus-mechanisms/pos/block-proposal/ https://ethereum.org/gu/developers/docs/consensus-mechanisms/pos/block-proposal/ https://ethereum.org/gu/developers/docs/consensus-mechanisms/pos/block-proposal/ \ \ The Fork Choice Rule (FCR) is a crucial mechanism in blockchain networks, determining which branch of a forked chain to accept as the canonical or main chain. https://eth2book.info/capella/part2/incentives/rewards/ https://eth2book.info/capella/part2/incentives/rewards/ Source vote: This is a vote for the lower checkpoint of a link between two checkpoints from different heights. A checkpoint is a block that is divisible by 50, and a link is a connection between two checkpoints that represents a validator’s attestation. A source vote is used to determine the justified and finalized checkpoints, which are the blocks that have received enough votes from validators to be considered final and irreversible Target vote: This is a vote for the higher checkpoint of a link between two checkpoints from different heights. A target vote is used to measure the participation rate of validators and to reward them for voting on the correct chain. A target vote also contributes to the finality of checkpoints, as a checkpoint can only be finalized if its previous checkpoint is justified Head vote: This is a vote for the most recent block that the validator sees as the head of the chain. A head vote is used to implement the LMD-GHOST fork choice rule, which selects the chain with the most votes from validators as the canonical chain. A head vote also helps to prevent stale blocks from being proposed and included in the chain https://dune.com/hildobby/eth2-staking The Fork Choice Rule (FCR) is a crucial mechanism in blockchain networks, determining which branch of a forked chain to accept as the canonical or main chain. The Fork Choice Rule (FCR) is a crucial mechanism in blockchain networks, determining which branch of a forked chain to accept as the canonical or main chain. https://eth2book.info/capella/part2/incentives/rewards/ https://eth2book.info/capella/part2/incentives/rewards/ https://eth2book.info/capella/part2/incentives/rewards/ https://eth2book.info/capella/part2/incentives/rewards/ https://eth2book.info/capella/part2/incentives/rewards/ https://eth2book.info/capella/part2/incentives/rewards/ Source vote: This is a vote for the lower checkpoint of a link between two checkpoints from different heights. A checkpoint is a block that is divisible by 50, and a link is a connection between two checkpoints that represents a validator’s attestation. A source vote is used to determine the justified and finalized checkpoints, which are the blocks that have received enough votes from validators to be considered final and irreversible Source vote: This is a vote for the lower checkpoint of a link between two checkpoints from different heights. A checkpoint is a block that is divisible by 50, and a link is a connection between two checkpoints that represents a validator’s attestation. A source vote is used to determine the justified and finalized checkpoints, which are the blocks that have received enough votes from validators to be considered final and irreversible Target vote: This is a vote for the higher checkpoint of a link between two checkpoints from different heights. A target vote is used to measure the participation rate of validators and to reward them for voting on the correct chain. A target vote also contributes to the finality of checkpoints, as a checkpoint can only be finalized if its previous checkpoint is justified Target vote: This is a vote for the higher checkpoint of a link between two checkpoints from different heights. A target vote is used to measure the participation rate of validators and to reward them for voting on the correct chain. A target vote also contributes to the finality of checkpoints, as a checkpoint can only be finalized if its previous checkpoint is justified Head vote: This is a vote for the most recent block that the validator sees as the head of the chain. A head vote is used to implement the LMD-GHOST fork choice rule, which selects the chain with the most votes from validators as the canonical chain. A head vote also helps to prevent stale blocks from being proposed and included in the chain Head vote: This is a vote for the most recent block that the validator sees as the head of the chain. A head vote is used to implement the LMD-GHOST fork choice rule, which selects the chain with the most votes from validators as the canonical chain. A head vote also helps to prevent stale blocks from being proposed and included in the chain https://dune.com/hildobby/eth2-staking https://dune.com/hildobby/eth2-staking https://dune.com/hildobby/eth2-staking
