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

# Eth2 Implementers’ Call #55 - 2021-01-14
[Quick contemporaneous notes by Ben Edgington]

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

## Testing and Release updates

## Client updates

**Teku**
Merged in a community contributed feature to load graffiti during runtime. Latest API updates to return SSZ or JSON based on request headers. Use "dependent root" field for triggering recalculation validator duties: this is running on Pyrmont, but default off for mainnet now. Preparing and refactoring for future protocol updates. Hardening of P2P layer.

**Nimbus**
Release 1.0.6. Reproducible builds for ARM. Improved subnet logic: fewer unnecessary attestations received. New form of slashing protection in development: start validators as inactive for a few epochs, and look for conflicting attestations on the network. Starting work on the standard REST API. There is now a mailing list for release announcements.

**Lighthouse**
Blog post about roadmap planning due soon. Added a new system for monitoring validators: additional logging around blocks and attestations (PR). Weak subjectivity sync support in progress. Reviewing upgrade PRs and planning for support of forks.

**Lodestar**
Working on stability and usability. Speeding up epoch transition. Storing fewer states. Refactor of Req/Resp code. Updating sync to download and process blocks in parallel. Looking at how to support future forks. Next release due Monday.

**Prysm**
Slashing protection is more performant on validator side, due in v1.1 release on Monday. Bug fixes. API implementation almost done. Experimenting with light client sync committees. Better test set ups and utilities.

## Upgrade 1

(Commonly called "Hard fork 1", but I am [hoping to modify](https://github.com/ethereum/eth2.0-pm/issues/198#issuecomment-760170970) the terminology)

Plan is to do a minor upgrade in mid-year. Add some features, do some clean-ups.

Currently in the form of some proposals in the "lightclient" folder - will rename this. Seeking feedback from teams, especially the state reform parts. [Accounting reform](https://github.com/ethereum/eth2.0-specs/pull/2176) and [Global quotient penalties](https://github.com/ethereum/eth2.0-specs/pull/2177) PRs particularly. In addition, adding sync committees: similar to beacon committees, but larger and longer-lasting. Supports light clients as first class citizens. Re-uses a lot of existing concepts.

A couple of network fixes are due; should be prior to the fork/upgrade. Also security fixes to the fork choice rule are in review and will be discussed with teams in a couple of weeks.

This will be good practice for larger upgrades later.

[V] Need to come to consensus fairly soon on the contents of this first upgrade. (1) Sync committees; (2) Accounting reforms (lighter or deeper version); (3) Fork choice changes. Should try to agree by end of Jan (next call).

[Jacek] How much of epoch processing is due to rewards and penalties vs. finality handling? In Nimbus, persisting the state is the heaviest load by far. [V] Even if the accounting is not the biggest load, moving it will still help. Any numbers from clients would be useful. Relative proportions will change as the number of validators grows.

[Danny] The changes make reasoning about the spec and updating the spec easier. E.g. the proposer reward is [currently wrong](https://github.com/ethereum/eth2.0-specs/issues/2152#issuecomment-747465241). Also improves processing of long empty chains, which can be a DoS vector.

[PaulH] Accounting reforms should make it easier to optimise storage.

**Action:** plan to make a decision on contents by end of January.

## Research Updates

Q1 R&D. Working towards Eth1/Eth2 merge and sharded data availability. Specs on sharding R&D are mostly in PRs; merge work is mostly visible on ethresear.ch at present.

Aim to have good specs for both by the end of Q1, and at that point decide priorities for implementation: which comes first. [My prediction: sharding will be first.]

Teams could divide internally between implementing the upgrade and digging into the research. Planning a workshop early Feb to look through the research topics.

[Mikhail] Planning some testnets for executable beacon chain in next weeks. Still some open questions, such as what to do with `BLOCKHASH`. How to follow the merge work? Ethresear.ch post, plus some docs: https://hackmd.io/T9x2mMA4S7us8tJwEB3FDQ It's a good time to compile the work from the working group into broader docs and begin engaging more publicly. There is a "Merge" channel on the Discord. **Action:** Do this.

Fun cryptography: Kate commitments. Recommend digging into this before the workshop. **Action:** Find your crypto wizard.

[Proto] There are two Go repos: (1) data availability; (2) [Kate commitments](https://github.com/protolambda/go-kate).

[Justin] Roadmap: there are two types of features planned, (1) functionality (sharding, merge), and (2) security. Security of the beacon chain is probably good enough in the short term, and we should probably focus on functionality for now. Hopefully this separation of concerns will help implementers to prioritise.

## Networking

There is [an issue](https://github.com/ethereum/eth2.0-specs/issues/2183) around ignoring duplicate aggregates from different aggregators: this was intended as an optimisation, but actually results in more work. This may be removed next week. [Jacek] Better optimisation could be to drop `IHAVE`/`IWANT` altogether. [Danny] If the benefits/disbenefits of `IHAVE`/`IWANT` could be quantified, that would help to decide. Also need to consider attack scenarios, not just the happy case.

Changes to this would be in a minor spec release, rather than waiting for the Upgrade.

## Open discussion

Testnets: are we still happy with Pyrmont?

Testnets serve two purposes: staging releases for client teams, and for users to try out staking. Currently looks like Pyrmont is meeting these needs. Could add some more client team validators to help increase stability. General view seems to be that Pyrmont should suffice until the Upgrade.

Could also auto-register client team validators as others come on board to maintain ratios.

For exchanges etc. that want to run many 1000s of validators, we could spin up private testnets for them fairly easily. Please contact a client team.

* * *

# Chat highlights

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

From Mikhail Kalinin to Everyone: 02:33 PM
: https://hackmd.io/T9x2mMA4S7us8tJwEB3FDQ

From protolambda to Everyone: 02:36 PM
: https://github.com/protolambda/go-kate