Try   HackMD

Reorg of late blocks

The mechanism is the same as in our design doc. I'm summarizing here implementation details.

  • At threshold x (think 4") we decide that any block after this is subject to be reorged
  • At threhold y (think 10") we evaluate our chances.
  • Final decisions are always done at second 0

Changes to Forkchoice

  • Forkchoice will emit a message whenever justified checkpoint has changed.
  • Forkchoice will have a new setter func (f *Forkchoice) SetJustifiedBalances([]uint64)
  • Forkchoice will have a new getter func (f *Forkchoice) ProposerHead() [32]byte

Changes to StateGen

StateGen will now listen to the justified checkpoint changed message from forkchoice. When it gets such a message it calls Forkchoice.SetJustifiedBalances with the effective balances at the justified checkpoint.

Changes to BlockChain Package

  • onBlock is modified to not update Head if the block arrives after x and not call notifyEngineIfChangedHead subsequently.
  • BlockChain package now is required to process attestations every block at y in addition to 0. The way this is currently achieved is by calling NewSlot on a ticker, and then right after calling UpdateHead.
  • UpdateHead signature will change to func (s *Service) UpdateHead(*context.Context) ([32]byte, error). It will return the new head root.
  • After calling to UpdateHead, both at second y and 0, blockchain will call Forkchoice.ProposerHead() if these two are equal, then blockchain package will call Service.notifyEngineIfChangedHead. If they differ, then no call to the engine is made.

Changes to the validator server

  • When requested to propose a block, the proposer will not build a block on top of Head() but rather ProposerHead()

  • No changes when attesting, we will always attest on Head()

Rationale

The main dangerous changes are being done in the BlockChain package. From the point of view of a proposer the following happens

  • At second y we process attestations and call to UpdateHead forkchoice knows at this stage if we need to fork or not the last block. if we need to fork it then it will return a different head than the ProposerHead so we do not need to call FCU. If the updated head is the same as the ProposerHead that means that we will not be forking the block, so we have to call FCU. This has to be done also at second 0.

From the point of view of an attester there are no changes. At second y and at second 0 we have updated head so there's nothing to worry, the right head is computed by the time we attest. If we proposed a block, we will import our own block before attesting, and so it will attest to our own head.

  • There is one danger, that at second y or second 0 the return from UpdateHead() and ProposerHead() are both different and both of them are different than the previous head. Forkchoice will take care that this never happens, so that when UpdateHead and ProposerHead are both different than the previous head, then it will return both of them equal, thus forcing the beacon to call FCU.

How does forkchoice compute ProposerHead?

Forkchoice gets calls to Head() after each process attestations. And it has the timings for each inserted block, so it can at each computation of Head() assess if the new head has changed, and if it was because of a late block, it can check itself the 10% threshold condition. So it can decide on each call to Head() if the ProposerHead needs to be updated or not.

Non-Goals

We could have a message system also for when Head updates. Blockchain could then update it's head view. This is part of the program of deprecating the head package.

Last changed by 
 
potuz
4
173

Read more

The case for EIP-7732 in Fusaka

A one sentence, no-nonsense, FAQ for why we should include EIP-7732 in Fusaka

Nov 21, 2024
The handwavy case for EIP 7732

Validators have 9 seconds to validate the blocks instead of 2

Sep 27, 2024
Validator performance tracking

We explain in detail the different components that make up an Ethereum validator's reward. We describe common situations that make stakers miss some of these rewards and show how to diagnose the -- typically uncommon-- scenarios in which there are actual problems with the software and action is required. 1. Introduction A common concern of node operators is --Is my node performing well?--, or -- Is my node performing at least as the average?--. The essence of the question is in fact --Should I be changing anything in my setup or not?--. It turns out that these questions do not really have an easy answer. There have been many attempts to trying to create a single score that would measure a validator's performance, but they all fail because of different reasons to answer the very basic questions mentioned above. Instead of trying to track a single indicator (or a ton of useless ones and be worried about some small variance on any of those), validators should analyze why their performance took a hit: did I miss an attestation due to a late block, a reorg, something else out of my control?, did I miss a proposal due to my EL being stressed or was my block reorged because it was received late by the network?. In this document, we will try to help node operators to identify warnings, their cause, and make informed decisions on when to tweak their setup. In order to do this we first start by describing, in some level of technical detail, the different components of a validator's reward. We then move to analyze each one of them separately as they are susceptible to different external factors. We finally describe how to exploit existing monitoring tools (grafana, logs, beacon explorers, etc) to diagnose causes for drops in rewards. The organization of this post is as follows. In section 2 we describe the statistical expected variance in income amongst perfectly working validators. In section 3 we describe all the components that make attestation rewards, how much to expect in different scenarios of attestation inclusion and how to diagnose a missing attestation. In section 4 we describe the analogous situation for proposals. In section [5](# 5-Sync-committee-messages) we describe quickly sync committee rewards. In section 6 we cover transaction tips. In section 7 we mention some tools to monitor performance that are available in Prysm, and finally in section 8 we mention how to get support from the Prysm team. 2. Reward variance is evil

Apr 4, 2023
Safe Head: happy case

Basic definitions and notation We will use $S$ for slots, $B$ for blocks, $E$ for epochs. Often times we will use $S$ for the block at slot $S$ abusing notation when no confusion could arise. For example, a forkchoice diagram of the form digraph{ rankdir=RL 10 -> 9; 11 -> 10; 12 -> 11; 13 -> 11; 13 -> 12 [style=invis];

Mar 23, 2023
Read more from potuz
Published on HackMD