Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Eth2 Spec > Phase0 - Beacon Chain > Flashcards

Phase0 - Beacon Chain Flashcards

1
Q

The BeaconState encapsulates all of the information relating to:

A
  • Who the validators are
  • Which state the validators are in
  • Which chain in the block tree this state belongs to
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What is the number of shard supported in Ethereum POS

A

64

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

The ethereum beacon chain supports how many shards per slot?

A

64

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

To enable state transitions, the beacon chain has a state_transition function which takes as input a _________ and a _______ and returns a new ___________

A

To enable state transitions, the beacon chain has a state_transition function which takes as input a BeaconState (pre state) and a BeaconBlock and returns a new beacon state (what we call a post state)

source: https://notes.ethereum.org/@djrtwo/Bkn3zpwxB

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What is the pre state

A

The beacon state before a state transition

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

What is a post state

A

The beacon state after a state transition has been applied

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

What are needed for state transition in beacon chain?

A
  • A pre state (Beacon state)
  • A beacon block
  • State transition function
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

When is the post state of a beacon block considered valid?

A

> Beginning with the genesis state, the post state of a block is considered valid if it passes all of the guards within the state_transition function

https://notes.ethereum.org/@djrtwo/Bkn3zpwxB

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

What does the fork choice rule do?

A

> Given a block tree, the fork choice rule provides a single chain (the canonical chain) and resulting state based upon recent messages from validators

> The fork choice rule consumes the block-tree along with the set of most recent attestations from active validators, and identifies a block as the current head of the chain

https://notes.ethereum.org/@djrtwo/Bkn3zpwxB

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

What does LMD GHOST stand for?

A

Largest Message Driven Greedy Heaviest Observed Sub Tree

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

What is the fork choice rule of the Beacon Chain?

A

LMD GHOST (“Latest Message Driven Greedy Heaviest-Observed Sub-Tree”),

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

How many attestation can a validator make within a slot within an epoch?

A

1

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

How long is a slot?

A

12 seconds

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

How many slots make an epoch?

A

32 slots

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

How long is an epoch?

A

12 seconds * 32 = 384 seconds = 6,4 minutes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

A validator attests to what via their vote?

A

A beacon block

17
Q

In addition to voting on the canonical chain (via the LMD GHOST algorithm), validators also contribute to deciding what? for blocks.

A

> In addition to voting on the canonical chain, validators also contribute to deciding finality of blocks. a process that tells us when a Beacon block can be considered final and non-revertible.

source: https://notes.ethereum.org/@djrtwo/Bkn3zpwxB

18
Q

What is the difference between fork choice rule and finality?

A

> In other words, whereas the fork choice rule allows us to choose a single canonical blockchain through the block tree, finality provides guarantees that certain blocks will remain within the canonical chain.

source: https://notes.ethereum.org/@djrtwo/Bkn3zpwxB

19
Q

What is the algorithm used by the beacon chain for finality called?

A

A modified version of Casper FFG.

20
Q

What does Casper FFG stand for?

A

Casper the Friendly Finality Gadget

21
Q

What is a finality gadget

A

> “Finality gadget” is a component that overlays any Nakamoto-inspired block proposal mechanism and provides deterministic finality with safety robust against network failure (asynchronous safety, Footnote 1). This idea is initially proposed by Casper FFG and now adopted by Polkadot (GRANDPA 5), NEAR (Nightshade Finality Gadget 6), and Concordium (Afgjort 4).

Source: https://ethresear.ch/t/hierarchical-finality-gadget/6829

22
Q

What does Casper FFG provides?

A

> Casper provides “accountable safety” that certain blocks will always remain in the canonical chain unless some threshold of validators burn their staked capital. This is a “crypto-economic” claim of safety rather than a more traditional safety found in traditional distributed systems consensus algorithms.

source: https://notes.ethereum.org/@djrtwo/Bkn3zpwxB

23
Q

What are the 3 primary responsibility of a validator?

A
  1. Attesting to the beacon chain (once per epoch).
  2. Aggregating attestations from validators in the same committee (occasionally).
  3. Creating beacon blocks when selected (infrequently).
24
Q

How are validators distributed across committees, slots and epochs?

A

Validators are grouped into a single committee, per slot per epoch. Each validator attests to a block in a slot. If validator is not block proposer or aggregator, then each validator in the committee attests to the head of the beacon chain (and the recent data of their assigned shard) at their assigned slot.

25
Q

At what points are proposal assignments known?

A

> At each slot, a single beacon block proposer is selected (via get_beacon_proposer_index) from one of the active validators. Based on the Beacon RNG, committees are randomly shuffled, and proposers are randomly picked. Proposal assignments are only known within the current epoch, but even then, any amount of public lookahead on block production is cause for DoS concern

Souce: https://notes.ethereum.org/@djrtwo/Bkn3zpwxB

26
Q

What are the slash-able offence?

A
  • A double proposal
    • In a double proposal, a selected proposer tries to propose more than one block for their assigned slot
  • An FFG surround vote
    • In an FFG surround vote you are casting a vote for a target and source (current and prior checkpoint blocks) that is surrounded by a previous FFG vote that you made. This basically discounts the validity of your previous vote, and is disallowed. For example you voted for slots 32 as a source and 64 as a target in your previous vote, but in the current epoch vote for Slot 0 and Slot 96. Your current vote would surround the previous one
  • An FFG double vote
    • In a double vote, you are casting two FFG votes in the same epoch, instead of the allowed one
27
Q

What are the sections of the Beacon chain spec?

A
  • Constants
  • Configuration
    • Presets
  • Data structures
  • Helper Functions
28
Q

What are Beacon operations?

A

Beacon operations are data structures that can be added to a BeaconBlock by a block proposer.

They form what constitutes the beacon block that is then operated on by the state transition process to create the post beacon state.

> They are the means by which new information is introduced into the beacon chain allowing it to update its internal state

29
Q

What are the Beacon Operations that can be found in a Beacon Block?

A
  • ProposerSlashing: For slashing double proposals
  • AttesterSlashing: For slashing double attestation or surround attestation
  • Attestation:
  • Deposit
  • VoluntryExit
30
Q

What are the components of the BeaconBlock?

A

>

  • slot - the slot for which this block is created. Must be greater than the slot of the block defined by parent_root
  • parent_root - the block root of the parent block
  • state_root - the hash root of the post state of running the state transition through this block
  • body - a BeaconBlockBody containing fields for each of the beacon operation objects as well as a few proposer input fields
31
Q

What are the components of the BeaconBlockBody?

A

BeaconBlockBody contains fields specific to the action of the block on the current state
It has eight fields:

  • randao_reveal - the BLSSignature of the current epoch (by the current block proposer). Constitutes the seed for randomness when mixed in with the other proposers’ reveals.
  • eth1_data - a vote on recent data from the Eth1 chain. It consists of the following fields:
  • deposit_root - the SSZ List hash_tree_root of all of the deposits in the deposit contract
  • deposit_count - the number of successful validator deposits that have been made into the deposit contract so far
  • block_hash - the eth1 block hash that contains the deposit_root. This block_hash is intended to be used for finalization of the Eth1 chain in the future
  • graffiti - 32 bytes for validators to decorate as they choose with no defined in-protocol use
  • proposer_slashings, attester_slashings, attestations, deposits, voluntary_exits are all lists (with max lengths) – one for each operation type – that can be included into the BeaconBlockBody
32
Q

How often does a validator perform its duties?
A - Once every epoch
B - Once every slot

A

During each epoch, each validator makes an attestation.
Technically once within a slot, every epoch
Answer is A

33
Q

What does an attestation contain?

A
  • A hash of what the validator thinks is the “head” of the beacon chain
  • A hash of what the validator thinks is the correct shard block to include (must be the shard it is assigned to)
  • Some other hashes (the “source” and “target” in Casper FFG) Used for finality
  • A signature from the validator, proving that the validator endorses all of the above
34
Q

What fraction of validators are needed to sign a head?

A

The chain comes to a consensus as a result of these attestations. Roughly speaking, if 2/3 of active validators sign an attestation supporting a block, that block becomes finalized

35
Q

In the forkchoice rule, how are the nodes in the blocktree weighted?

A

LMD GHOST (“Latest Message Driven Greedy Heaviest-Observed Sub-Tree”), the fork choice rule of Eth2.0, considers which block the latest attestation from each validator points to and uses this to calculate the total balance that recursively attests to each block in the tree.

This is done by setting the weight of a node in the tree to be the sum of the balances of the validators whose latest attestations were for that node or any descendent of that node.

The GHOST algorithm then starts at the base of the tree, selecting the child of the current node with the heaviest weight until reaching a leaf node. This leaf node is the head of the chain and recursively defines the canonical chain

36
Q

Through which mechanism does new information get added to the beacon state?

A

Beacon operations are datastructures that can be added to a BeaconBlock by a block proposer.

They are the means by which new information is introduced into the beacon chain allowing it to update its internal state.

Eth2 Spec (3 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions