Jacek Sieka

Ditto nimbus, where it needs finishing - since we last wrote here, the quic backend for libp2p is has been completed but its integration into eth2 has not (high prio)

> TCP+Yamux+Noise as a fallback transport TCP+Mplex+Noise - we never made the move to yamux formally so mplex is the only supported fallback option in clients - the goal being...

> because ocassionally middleboxes block UDP traffic. Btw, we already have a de-facto hard requirement on UDP working (discv5), so dropping TCP is a strictly an increase in the ability...

> mplex does not provide flow controw > not mplex for the reasons listed here This is mostly a theoretical issue, ie the marginal benefit to ethereum of this feature...

> when not in a nimble project. I suspect there's a conflict there with nimbus-build-system projects that have a nimble file but don't use it for package management per se...

nimbus-eth2/beacon_chain/nimbus_beacon_node takes several minutes to compile, if you're looking for a compiler speed stress test - it's _quite_ slow and not getting any faster

```nim import chronos async: proc f(): Future[int] = 10 proc g(): Future[int] = await f() echo waitFor g() ``` this works today, fwiw

> async keyword for the chronos version of raises tracking, what would have helped rather than an async keyword would have been the compiler exposing more type arithmetic utilities, as...

libp2p has several quic implementations of varying quality - which one is this? if anything, we should be using the standards-compliant one, ie quic-v1: https://docs.libp2p.io/concepts/transports/quic/#distinguishing-multiple-quic-versions-in-libp2p but this has not yet...

> Do you see dual stack to be forced? re ipv6, the idea _in general_ is to push towards a world where dual stack is enabled by default (if the...