Try   HackMD
  •  
    Prysmatic Labs
    ·
    Last edited by James He on May 17, 2022
    Linked with GitHub
  • Edit
Last changed by 

 
Prysmatic Labs
eth2 development team
0
114

Read more

What Happens After Finality in ETH2?

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.

Jul 4, 2024
Migrating Prysm to Slog

Contextual logging:

Dec 6, 2023
Running BOLD Challenges on Sepolia

This guide will set up

Nov 17, 2023
Generalized History Commitment

Today 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.

Aug 16, 2023
Read more from Prysmatic Labs

Published on HackMD
    Expand allBack to topGo to bottom
Expand allBack to topGo to bottom

Sign in

Forgot password

or

By clicking below, you agree to our terms of service.

Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox Sign in with Wallet
Wallet ( )
Connect another wallet

New to HackMD? Sign up