Hunting For Bugs In "Ethereum 2.0" by Denis Kolegov and JP Aumasson

### Overview In this presentation, JP Aumasson discusses security research on Ethereum consensus clients (formerly referred to as "Ethereum 2.0"), conducted under an Ethereum Foundation grant with collaborators Denis Kolegov and Evangelia Statopoulou. The talk covers the transition of Ethereum to Proof of Stake (PoS) via the Beacon Chain, the architecture of consensus clients, the audit methodology employed, and the vulnerability classes identified across cryptographic schemes, peer-to-peer transport, APIs, and dependencies.

### Key Topics - **Beacon Chain & Client Ecosystem**: Overview of the Beacon Chain deployed in December 2020 to introduce Proof of Stake and data sharding. The talk reviews four primary consensus clients: Prysm (Go), Lighthouse (Rust), Teku (Java), and Nimbus (Nim). Each client functions as a server composed of a passive beacon node and an active validator node managing block proposals and attestations. - **Audit Methodology**: The researchers compared implementation behavior across independent clients and checked code directly against official IETF drafts and Ethereum specifications to identify discrepancies in parameters, execution orders, and validation routines. - **Cryptographic Schemes & P2P Protocols**: Analysis of BLS signatures, the libp2p networking stack, and the libp2p-noise (Noise_XX) secure transport handshake used between validators. - **Software Supply Chain Risk**: Examination of third-party dependencies, transitive dependency graphs, and tooling (such as cargo-audit and dependabot) across different language ecosystems.

### Technical Details - **BLS Signatures**: BLS signatures use hash-to-curve operations and scalar multiplication. The speaker highlighted edge cases such as handling point-at-infinity/zero inputs (which could allow forged signatures regardless of the secret key), missing subgroup checks, and detailed error messages acting as potential oracles. Across the four clients and specifications, the researchers identified 90 non-critical bug instances. - **Noise Protocol Handshake & Transport**: In libp2p-noise, nodes exchange ephemeral keys and sign static keys with an identity key. The speaker noted vulnerabilities including potential replay attacks if key updates lack freshness tokens/challenges, and CPU DoS risks during initial handshake key exchanges. In the JavaScript/TypeScript implementation, an integer overflow bug originating from the Go noise-explorer code failed to stop after reaching 2^64 nonces, risking nonce reuse in AEAD ciphers. A separate TypeScript bug also resulted in unchecked signature verification. - **APIs & Supply Chain**: HTTP REST and RPC/gRPC endpoints exhibited schema validation omissions, unauthenticated endpoints, and instances where API tokens were leaked into logs. In dependency analysis, Prysm had 665 total dependencies (93 direct) and Lighthouse had 440 total (121 direct), highlighting the difficulty of auditing deep dependency trees against malicious sabotage or backdoors.

### Takeaways While no critical exploitable flaws allowing immediate theft of funds were discovered—largely due to extensive audits and fuzzing prior to the study—the complexity of distributed consensus mechanisms and asynchronous networks introduces subtle edge-case risks. Client diversity remains an important defense against network-wide outages, with Lighthouse singled out for strong security practices such as integrated CI fuzzing.