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

# Eth2 networking call #5 2020/05/06

[Quick contemporaneous notes by Ben Edgington]

[Agenda](https://github.com/ethereum/eth2.0-pm/issues/148)
[Recording](https://youtu.be/VPgMe6CVf5Q)

## Intro

Preparing for v0.12 release. Mostly BLS, but some networking updates.

## Gossipsub v1.1 implementations

David Dias from Protocol Labs on [gossipsub v1.1](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md). Important milestone. Since early March been working on enumerating attack vectors and designing mitigations. These are in v1.1. Created evaluation plan with 11 different attacks. Running simulations (Testground). Sixty page report is available. Tl;dr: v1.1 is a significant improvement over v1.0 under attack scenarios.

Now working with Least Authority to audit the implementation. Full report coming on May 13; no issues found so far. Launch of v1.1 in next two weeks.

Next week will implement in a real network and open it up to attack via Testground. Eth2 might adopt similar test framework.

How much effort to implement v1.1? It is backwards compatible, even to FloodSub. Estimate under one week to extend v1.0 to v1.1. Reference implementation is well documented. PL is happy to help out.

What are the key changes? Peer scoring - multiple ways to evaluate peers, with parametrisation and multiple threshholds. Peer exchange: peers help each other to find new peers. Spam protection. Custom validators: able to discard peers publishing wrong information in a configurable way.

Number of peers in simulation 10-12k: maxed out Testground.

[Danny] v1.1 is very important. We should integrate this before mainnet launch. Suggest clients add it to their backlogs. Will open up a discussion channel for Q&A.

## Stethoscope update

[Lakshman] on [stethoscope](https://github.com/lsankar4033/stethoscope) - YAML defined networking tests and a test runner. Simple to run locally.

Test runner is complete. Now writing tests. Let Lakshman know if you have edge cases for testing.

Creating shell scripts for each client in _clients_ directory. Client teams please help if you can. [Jacek] There is the multinet repo from Interop that has some scripts.

Range of testing? Focus on valid and edge case messages for 1-1 tests currently. Future: multiclient and state propagation. Using Rumor to drive clients.

## Spec discussion

### beacon state sync

Danny created [a PR](https://github.com/ethereum/eth2.0-specs/pull/1782) yesterday to require nodes to provide (some) historical state, but has had some pushback on this.

Problem with making it optional is that you then can't rely on it.

[Mikhail] How can we verify that the state received is canonical? Within the weak subjectivity period (3 weeks?), need to get a checkpoint out-of-band that we trust (e.g. from client implementers). Can then verify the state against the checkpoint root. [Jacek] How to calculate WSP? Depends on churn of validator set, which is a bit dynamic. [Zahary] State could be signed by multipe parties such as EF and others to prove it is correct.

Seems that the proper way forward is to document the expected sync scenarios with user stories about how different clients might get the state. Then decide whether p2p state sync is required or not. UX of being able to start client from only a finalised checkpoint does seem attractive.

Also need to nail down what the WSP is.

### dynamic persistent attnet count

Jonny Rhea has been doing some analysis. Finds that only of small number of subnets used although many are subscribed to. What strategy should be used?

Need persistent back net of subnets - will come naturally in Ph1. Current spec looks like Ph1 expected size. [The Issue](https://github.com/ethereum/eth2.0-specs/issues/1777) suggests subscribing only to used subnets. This partially stems from having removed all references to shards from the Ph0 spec.

With small validator counts most subnet subscriptions are not used, since number of committees per slot is low.

Concern is that if we simplify this too much now, we are not well-simulating how Phase 1 will perform.

[Danny] Will consider changing the calculations around this and propose new function to calculate subscriptions.

### dht peer sharing across nets

Observed by Jonny Rhea on existing networks.

ForkID filters ENRs by network. So we could just fill our DHTs with only ENRs with the right forkID. Not sure about the consequences of this.

[Mikhail] Adding all ENRs is not a benefit from a security perspective.

[Age] It would be an easy config option to implement this. Might need to modify searches as well: peers could give us ENRs with wrong fork IDs.

Couple of options (1) reduce attestation subnet count on test networks to allow finding peers more quickly, but not representative of real network. (2) Modify discv5 to filter what we put in DHT.

Danny to follow up with Felix to determine how much of a problem this is.

### allow aggregate without aggregator included

[Issue](https://github.com/ethereum/eth2.0-specs/pull/1732) from Paul: Allow aggregate where aggregator has not attested.

Any concerns about removing the one condition? Not on the call.

Please comment if any issues. Plan to merge within 48 hours. Could impact validator/beacon node architecture.

### stricter type-based limits in chunk sizes

[Proto] Can be based on SSZ type information, so don't need to be hard-coded. This is implemented in Rumor. Makes it easier to reject bad messages quickly. Makes bad behaviour more explicit.

[Age] Are the sizes documented? Can just be derived from SSZ types for the most part. [Danny] Could just be an advisory note in the spec. This is more like an optimisation: early rejection of messages without having to read the whole thing.

Need to take into account worst-case Snappy compression (extra 25% of original size). [Jacek] We use a variable length integer for the length. Protobuf allows over-long encoding so could result in longer message. [Proto] Could limit this to 10 bytes, uint64 cannot be bigger. Most Protobuf implementations enforce this (given you read it as uint64).

[Age] FYI, found a panic in Lighthouse Snappy library today.

Add notes to spec about
- Message size limits based on SSZ type
- Variable length integer encoding has a size limit of 10 bytes

And encourage clients to adopt this.

## Open discussion

Nope.

## Close

Next call TBD. 3-5 weeks.

## Chat log highlights

From danny to Everyone: 02:20 PM
: https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md

From danny to Everyone: 02:25 PM
: https://github.com/lsankar4033/stethoscope

From Lakshman Sankar to Everyone: 02:26 PM
: https://github.com/lsankar4033/stethoscope/blob/master/tests/single_client_genesis.yml

From danny to Everyone: 02:28 PM
: https://github.com/eth2-clients/multinet

From danny to Everyone: 02:51 PM
: https://github.com/ethereum/eth2.0-specs/issues/1777

From Me to Everyone: 03:09 PM
: https://github.com/ethereum/eth2.0-specs/pull/1732

From danny to Everyone: 03:12 PM
: https://github.com/ethereum/eth2.0-specs/pull/1732
https://github.com/ethereum/eth2.0-pm/issues/148#issuecomment-624252194