A fundamental property of blockchains is the notion of "finality," which roughly means that after a certain period of time, transactions that have been included in the canonical chain are extremely difficult or almost impossible to revert. Eth2 has an "explicit" mechanism of chain finality enshrined within the protocol, which is different from the "probabilistic" finality found in proof-of-work chains such as Ethereum or Bitcoin today. In proof of work, consensus is fundamentally a global race that a lucky miner wins by being the first to produce a valid block: a result of finding a mathematical solution to a computationally difficult problem. As such, block times are probabilistic. The more blocks are added to the chain, the harder it is to revert, as each represents a cumulative sum of electrical and computational power required to create it. Given there are real, physical guarantees that would prevent an attacker from being able to revert the Bitcoin and Ethereum blockchains today, we can consider transactions past a certain amount of time included on-chain as "finalized." The objective of Stateless Ethereum RPC is to enable the client to operate without the need to store the entire state tree. Ethereum proof of stake, however, does not function on the concept of probabilistic finality. Instead, it enshrines finality into the protocol by saying "If > 2/3s of validators have voted correctly on the chain head for a long period of time, we can consider everything before a specific checkpoint as finalized". Finality is explicit, and nodes that follow the protocol will not be able to revert the finalized checkpoint as it is fundamentally impossible regardless of consensus weight. How Finality Works in ETH2 ETH2 is a synchronous protocol that operates on a "checkpoint" mechanism for bookkeeping. Essentially, a set of validators is assigned to either produce blocks or vote on blocks in a window of 32 potential slots. Each slot is a period of 12 seconds. Those 32 slots constitute an epoch. In an epoch, there are 32 assigned block proposers and everyone else is known as an attester, assigned to vote on proposed blocks once per epoch. There is only one block proposer assigned per slot, but many "attesters" can be assigned per slot For example, Alice is selected as a block proposer for slot 4 in the epoch and Bob, James, Charlie, and Susan are assigned as attesters at slot 4, meaning they should be voting on Alice's produced block as canonical.
7/4/2024Contextual logging:
12/6/2023This guide will set up
11/17/2023Today in BOLD, challenges can have subchallenges, and we have a total of 3 levels. We do this because at each challenge, validators have to commit to N state roots of a block’s history, which can be very expensive to compute. For example, computing 2048 machine hashes for the execution of a block and collecting them takes around 5 minutes on a modern MacBook Pro.
8/16/2023or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up