---
tags: eth2network
description: Notes from the Eth2 networking working group call
image: https://benjaminion.xyz/f/favicon-96x96.png
---

# Eth2 networking call #6 (or #7?) 2020/12/10

[Quick contemporaneous notes by Ben Edgington]

[Agenda](https://github.com/ethereum/eth2.0-pm/issues/194)

## gossipsub v1.1 scoring

Are most clients using some form of scoring right now on mainnet?
- Lighthouse: yes
- Teku: no
- Nimbus: yes
- Prysm: Unknown (not present on call)

Scoring is not currently in the spec, and clients differ in approach.

LH has two systems in parallel: LH and gossipsub. Peers are not dropped due to poor gossipsub scores. Gossipsub system _looks_ ok; honest peers don't get penalised too much, but does it help to avoid attacks?

Discussion about Protocol Labs's testing, and general cost of testing. EF and PL willing to fund some large scale tests. Need to verify that the scenarios tested (and published) match the use cases for Eth2.

[Jacek] enabling the message cache (mcache) has helped. Propagation time can be a problem in borderline situations. The mcache bumped up the memory usage significantly. Should be 6 heartbeat (6 x 0.7s) cache length, and 3 heartbeat IHAVE length - this is enough to show up in memory profiles. Value of answering IWANTs is very small. But IWANTs seem few and far between.

The number of messages in an IHAVE: Lighthouse is configurable, currently 5000 (in total; not per topic). This is generous and could be reduced. Gossipsub 1.1 introduced a budget for how many IWANTs may be answered (part of spam protection). The libp2p spec does not yet include guidance on the right number for this. We should agree on this between clients.

**Actions:**
- open up some of these additional params in gossipsub v1.1.1
- get scoring parameters into a PR against ETH2 specs repo
- plan some attack scenario testing (Giovanni's multinet scripts can help)

Most penalty situations found so far have been related to bugs in clients. Tightening up the params can help to find bugs!

## discv5.1

Any issues with discv5.1? Nodes appear to be finding peers just fine :-)

## block sync and WS state start

There is an [open PR](https://github.com/ethereum/eth2.0-specs/pull/2131) for this with some discussion.

What to do with peers that cannot serve blocks they ought to be able to? A "harsh" requirement would be that a node must have all the blocks in the weak subjectivity period before participating: if you are not yet synced, you are not allowed to participate in gossip (since you are not contributing to the network). How to detect if nodes are doing this? Should this be policed (randomly requesting blocks to see if peers are honest)? There's no carrot for clients to serve old blocks, so a stick may be needed.

So, what changes are needed to the PR? Avoid clients implementing weak subjectivity starts until they have backfilled blocks within the WSP. Syncing 2 weeks will take a few minutes. Only start advertising that you are following head until you have these blocks: this side-steps various issues that the PR seeks to deal with.

**Action:** Danny to revisit the PR and seek review.

## Open Discussion

A lot of clients implement their own ad hoc rate-limiting schemes. There is a [closed issue](https://github.com/ethereum/eth2.0-specs/pull/1577) to add a "RateLimited" response to the spec - it might be good to revisit this.

**Action:** Age to reopen/revive the issue.

Note that Jacek is not in favour of relying on any assumptions about rate limiting based on the error messages that counterparties return. The only thing that matters is whether I am receiving blocks. Nimbus doesn't send error codes, just slows down serving blocks. To be discussed in the issue.

[Danny] Need to consider what we are trying to achieve with this. Concerned that it may be a tough one to resolve.