description: Notes from the regular Eth2 implementers call
# Eth2 Implementers’ Call #45 - 2020-08-06
[Quick contemporaneous notes by Ben Edgington]
## Medalla launch retrospective
### Pre-launch issues
Launchpad installation and usage pipeline. Getting binaries prepared was not completed in time. Python may not have been the best choice. Feedback is being taken onboard.
Genesis was agreed well and on time. Lots of issues with bootnodes, and including bootnodes in client distributions. Led to some stress scrambling to fix, and making required updates by node operators.
Some validators ended up with 64 or 96 Eth of deposits. There were issues between Metamask and Launchpad that need to be investigated and improved.
Genesis delay of two days is too short. Danny suggests 96 hours/4 days. Or perhaps a week. Allows time for clients to cut a release that includes the genesis state for non-validating nodes.
Good launch-party call!
Early blocks came in, but it became clear that participation was low (~52-58%). This was not enough for justification and finality. Lodestar and Nimbus had low attestation participation: this accounted for ~10% of the network. Also found 5% of large stakers offline. Contacted one who was able to get node running.
By the end of epoch 8 we finalised checkpoint 6. We have had participation up to 80% since. There have been some Lighthouse particpation failures, and some Prysm nodes had some epochs of no attestations.
Network generally looks quite healty, but lots going on. Generally things look stable.
Danny is looking at doing some short-term production launch dress-rehearsals, on networks with lower Eth stake requirement.
Might need some more education around how the genesis time is actually set. Increasing the genesis delay would help.
Would be good to include Trinity and Nethermind in launch simulations.
Prysm looks to be dominating the network. A more equal distribution would be better for the health of the network.
Do we need better tooling to debug network issues? (API endpoints, peer store dumps, metrics.) The tool that maps validator ID to Eth1 address to UserId has been very helpful in finding contacts to talk to about nodes that are down. May not be a great idea for privacy on mainnet, though.
## Testing and Release updates
v0.12.2 was released after the last call. Still tuning some peer-scoring parameters, which might lead to a v0.12.3.
## Client updates
Working through Medalla launch issues: gossip validation (block verification) and peering. Stability issues with sync. Expect to be back in the testnet in a few weeks.
Identified four issues on Medalla:
1. Increased number of attestations hit some limits, especially with non-finality. Fixed.
2. Attestation processing bug. Fixed
3. Medalla blocks are often filled with 128 attestations, and Milagro is too slow. Switching to Blst.
4. Race condition with outgoing and incoming connections. Leads to issues with Lighthouse. Makes node unresponsive.
Audit: first phase, networking, is done. Second phase on beacon node starts in 10 days.
- Finished integrating Blst BLS library and merged it in. It's showing some very useful speedups over the old Milagro JVM version (a factor of around 7). We're keeping the JVM version around for any architectures that Blst doesn't support.
- Basic slashing protection is done at the individual validator level.
- Work on splitting out the validators process from the beacon node continues well, and we're implementing the new API as we go on with that.
- We've been migrating a lot of our storage APIs from synchronous to async.
- Improve robustness in the face of a Jonny attack (handle denial of service attempts more gracefully).
- Dealing with a whole bunch of bugs, usability bumps, and general overall improvements.
- Finally, we're just closing out our security assessment RFP. We got a good range of responses and are interviewing vendors this week.
Shipped accounts management v2. Integrated with Launchpad steps. Now fixing bugs and issues. A few beacon node bug fixes since genesis. A surge of users has joined Discord and asking questions: updated docs portal with FAQs.
Sync performance improvements. Couple of orders of magnitude speedup. BLS performance is now the bottleneck. Looking at Blst library.
Fixing Medalla issues, stability, attestation inclusion improvements. Have a slasher functioning. Working with Blst people to improve consensus conformance and portability.
Started working on weak subjectivity things.
Working on node management UI.
## Research Updates
Pushing forward the Blst library edge cases, optimisations, and formal verification.
Trying to build an Eth2 security team. Finding bugs in Eth2 client implementations is a focus. Currently have ~40 applications. Contact `email@example.com` if you are interested.
There has been a breakthrough for secret single leader election. Dan Boneh's technique with a tailored ZK proof. based on discrete log assumption, so no trusted set-up. This makes SSLE very promising, possibly even at Phase 1.
Secret shared validators. Held a kick-off call a couple of weeks ago. Any client teams interested in implementing the API? It would be good to have at least one. Should be low-effort.
[Jonny] Client distribution metrics. What's the motivation for disabling the client-identification protocol? It's good for debugging. There are always proxies for explicit client identifcation (e.g. default ports), so we might as well leave it in.
There may be a DoS concern here - repeatedly hitting the identify endpoint. Should we put the client info in the ENR instead? How far should clients go in limiting DoS vectors (usually this is the concern of firewalls)?
Gossipsub v1.1 has signed peer records which are provided to pruned peers in the identify protocol. Not sure if this is beeing used - it is optional.
Could put the identify protocol as a "MAY" in the spec, but on the whole it seems useful.
Could just put the client name rather than the software version in the identify response, in order to reduce scope for attacks against older s/w versions. In Eth1, client versions can be identified, but it does not seem to be a big issue.
How should we evaluate the trade-offs? Benefits of knowing what's on the network are high for us: we gain more than an attacker.
New attacknets and devnets are up for debugging Nimbus <-> Lighthouse p2p issues. Ping Protolambda to get involved.
## Key management
[Issue](https://github.com/ethereum/eth2.0-pm/issues/171#issuecomment-668991497) about deriving both signing and withdrawal keys from the same mnemonic. Current status is more user friendly. Best avoid deriving keys on a "hot" system. Two separate mnemonics provides a lot of scope for confusion.
But there is demand for alternatives that separate the derivation. Hardware wallets for example. But they can't export current keystore formats (too low power).
Should make the EIP reflect that the process is optional. (Carl has done this already.) **Action: follow-up conversation in Discord key-management channel**
## Spec discussion
Ongoing work on Phase 1. Vitalik's annotated spec is now [in a repo](https://github.com/ethereum/annotated-spec).
## Open discussion
There is a new multiclient attacknet. Single client attacknets still exist.
* * *
# Chat highlights
From JosephC to Everyone: 03:22 PM
: (wondering if anyone had been able to check if the medalla deposit contract was compiled with same solc version that Runtime Verification used, so that the bytecode matches?)
great, am planning to check too thanks
From Hsiao-Wei Wang to Everyone: 03:25 PM
: @Joseph it is the formal verified version
From JosephC to Everyone: 04:00 PM
: fyi defcon.org starting tomorrow (some today)
From Jonathan Rhea to Everyone: 04:00 PM
: hide your ips, hide your ports
From Hsiao-Wei Wang to Everyone: 04:10 PM
: V’s https://github.com/ethereum/annotated-spec