---
tags: eth2devs
description: Notes from the regular proof of stake [Eth2] implementers call
image: https://benjaminion.xyz/f/favicon-96x96.png
---

# PoS Implementers’ Call #65 - 2021-06-03
[Quick contemporaneous notes by Ben Edgington; fka "Eth2 Implementers' Call"]

Agenda: https://github.com/ethereum/eth2.0-pm/issues/220
Livestream: https://youtu.be/cgH8OsCg9tY

## Client updates

**Lodestar**
Passing the Alpha 5 spec tests, working on Alpha 6. Working on Altair interop by syncing to the Teku devnets. Has helped fix a number of performance issues. Now syncing to the head.

**Prysm**
A lot of Altair work: networking, transition. End of the month should be good for multiclient testnets. Also looking into sharding. Aligning with the Eth2 API - it's been a big project.

**Teku**
Finished Altair REST APIs, remote validation is working on Altair. Can now ingest the new config file format; maintaining a backward compatible version as well. Removed Java BLS lib since it is now too slow to keep up. Fixed an issue with Eth1 tracking follow distance.

We launched a couple of Altair devnets. Uncovered a few issues: updated ENR publishing (unresolved), transition process bug (resolved), sync net gossip subscriptions (unresolved). Other teams please contact Teku team for validator keys in order to join the devnets.

**Nimbus**
Started Altair work a little late, but entirely focused on it now. Expect to be ready end of month. Introducing multiple core capability in Nimbus, only in Blst for now, which is the majority of the load.

**Lighthouse**
Altair implementation is syncing and following the Teku devnet. Passing spec Alpha 6. All features for Altair implemented, but making some updates and merging into primary branch.

Made a Lighthouse "pre-release" today: not for production use. Expect to publish a release next week, with doppelganger detection and Altair to follow later this month.

## Altair

### Engineering progress

Patched the test vectors for Alpha 6 yesterday. Targetting Alpha 7 tomorrow, pending the following feature. (But see later discussion.)

### Feature: reduce reward variance

See [here](https://github.com/ethereum/eth2.0-specs/pull/2448). There is an asymmetry in rewards in the current Altair spec for sync committee validators. Two solutions have been proposed: [Potuz](https://github.com/ethereum/eth2.0-specs/pull/2450), [Vitalik](https://github.com/ethereum/eth2.0-specs/pull/2453).

[Vitalik]: Effectively, Vitalik, "+0.5 for participating, -0.5 for not"; Potuz, "+0 for participating, -1 for not participating". Only minor differences, but V's proposal preserves invariants around rewards better, and is less punitive towards innocent validators during inactivity leaks. Note that this process runs only when there is a block; if blocks are missing it doesn't run: keeping penalties milder would give less incentive to DoS other block proposers.

[Potuz] It's more like losing a reward if you do not participate in that slot. The status-quo becomes the worst thing that could happen to a validator: everyone receives the sync committee reward all the time, except when actually in a committee and not performing. In V's PR it is a genuine penalty being proposed. [V] But the level of incentive to participate goes way down, since the rewards are spread much more broadly - this could be an issue. [P] The penalty can be set to its current level, so incentives end up exactly the same.

[Dankrad] Another option is just to make sync committees much larger. But that introduces other issues.

[V] Question is lottery verses inverse-lottery. During a quadratic leak, the inverse lottery is more severe.

[Dankrad] Other things like MEV will likely dwarf the variance due to this mechanism in any case.

[Client teams] In terms of implementation complexity there is little difference between these proposals; we are happy to go with either.

Conclusion: V's proposal is simple and achieves the goals. For now, go with that, but it can always be revised in a later fork.

### Planning

Appreciation to Teku team for standing up the Altair devnets. Would be good to have one for Alpha 7 as well.

Looks like end of June/1st week of July for more substantial testnets. In 2 weeks from now, agree parameters for the first multiclient testnet.

Alpha 7 is expected to be final (but Alpha 6 was also...). Unless some issue comes up, this is the one.

[Jacek] What about the [state-root change](https://github.com/ethereum/eth2.0-specs/pull/2428) conversation? Generally agreed to be useful. Backfilling the data is complex for some clients; idea is to implement it across two forks. [Danny] Alternative is to upgrade the network protocol to share the info between clients: serve state roots alongside block roots.

[Jacek] Motivation is that it makes weak subjectivity sync much easier to validate, and also makes it easy to batch chunks of blocks for archive nodes.

Proposal: delay Alpha 7 until Wednesday next week to gather more input from teams.

[Adrian] The backfill process is probably doable in a single fork, but it would significantly increase the engineering load. Two fork release realises some benefit immediately, and is much easier to test.

[Danny] is concerned about scope-creep on Altair. Review the PR with that in mind. [Jacek] The actual substantive change to the spec is only two lines. [PaulH] But there is more to it beyond the spec, such as database storage. [Proto] We shouldn't commit to the first fork until we know what the second looks like, which adds to the overhead now.

## 0x02 credentials

See [here](https://github.com/ethereum/eth2.0-specs/pull/2454)

[Joe Clapis, Rocket Pool] There are cases in which a validator is not owned by only one entity. The 0x01 mechanism solves this by allowing for withdrawals to be made to a pre-agreed smart contract. However, execution client rewards (priority fees) will go to the block's coinbase, and the sharing mechanism could be subverted. This puts decentralised staking pools at a disadvantage.

Required characteristics:

1. Fair distribution of fees
2. Scales to arbitrary balances
3. Doesn't interfere with validators using 0x00 or 0x01 withdrawal credentials
4. Doesn't add any further burden to The Merge

Rocket Pool's conclusion is that the only way to meet all of these is in-protocol. 0x02 credentials would be the same as the 0x01 except that a proposed block is valid only if the coinbase of the block matches the withdrawal address. This has benefits beyond Rocket Pool, e.g. for Blox Staking.

There are other options, but is a strong candidate.

[Danny] This does have a minor impact on The Merge, and we are trying to avoid such things. One option is to defer 0x02 enforcement to some fork after The Merge.

[Dankrad] Why not just add this to the 0x01 mechanism? [Danny] Only because there might be unknown consequences.

Note that this does not solve MEV or side-channel payment issues. [Micah] Such a mechanism could even incentivise proposers to prioritise side-channel transactions over regular gossipped transactions. But this is probably an insurmountable problem.

To be continued... (in [the PR](https://github.com/ethereum/eth2.0-specs/pull/2454))

## Research Updates

None

## Spec discussion

Take a look at the [Merge transition PR](https://github.com/ethereum/eth2.0-specs/pull/2462).

* * *

# Chat highlights

From danny to Everyone: 03:02 PM
: https://github.com/ethereum/eth2.0-pm/issues/220

From terence(prysmaticlabs) to Everyone: 03:13 PM
: https://github.com/ethereum/eth2.0-specs/pull/2450
https://github.com/ethereum/eth2.0-specs/pull/2453

From Micah Zoltu to Everyone: 03:27 PM
: Are there legitimate reasons for not participating in a sync committee? Offline I'm guessing? Anything else?

From terence(prysmaticlabs) to Everyone: 03:29 PM
: Could also be client bugs… if that counts

From Micah Zoltu to Everyone: 03:29 PM
: Doesn't count. 😀 Client bugs can cause you to break consensus and get kicked out and bleed money.

From Adrian Sutton to Everyone: 03:30 PM
: You will fail to participate in sync committee at the same rate (at least) as you get incorrect head votes now just because of late blocks or gossip delays. So it won’t be uncommon to not have your signature included when you’re in a sync committeee.

From Potuz V to Everyone: 03:30 PM
: perhaps implementers can comment on the costs of having larger committees

From danny to Everyone: 03:45 PM
: https://github.com/ethereum/eth2.0-specs/pull/2428

From Ansgar Dietrichs to Everyone: 04:00 PM
: Can’t the operator of a validator always extract inclusion fees though? accept txs with 0 priority fee, collect payment out-of-band? Especially for MEV, which might make up most of the collected validator tx fees?

From Micah Zoltu to Everyone: 04:02 PM
: Perhaps this is obvious or already answered previously, but why do we want to encourage pooling? Naively, it feels like we would want there to be advantages (perhaps in possible trust models) for non-pooling validators to discourage centralization of validator control.
@Ansgar We actually see this currently with mining pools pocketing MEV by not sending it to coinbase but instead their own address.

From Ansgar Dietrichs to Everyone: 04:03 PM
: ah, makes sense. yes, then this really seems mostly hopeless (at least with regards to simple solutions)
“might provisionally help” seems like a good general summary of this fix

From danny to Everyone: 04:10 PM
: https://github.com/ethereum/eth2.0-specs/pull/2454

From Micah Zoltu to Everyone: 04:11 PM
: Gossip a tx, with nonce 1 @ 2 nanoeth/gas
Side Channel publish a tx with nonce 1 @ 1 nanoeth/gas
If an honest block producer produces a block, you pay 2.
If a rogue block producer produces a block, you pay 1.

From Mikhail Kalinin to Everyone: 04:12 PM
: https://github.com/ethereum/eth2.0-specs/pull/2462