Skip to content

Latest commit

 

History

History
205 lines (158 loc) · 10.6 KB

File metadata and controls

205 lines (158 loc) · 10.6 KB

Audit scoping

Last modified: November, 2024

This document suggests an audit scope for discussion to serve best the Ethereum ecosystem.

Overview

The Ethereum community is pursuing credible neutrality and implementation diversification wants to avoid single points of failure. This is examplified by investing in 5 different clients for the Consensus Layer (CL).

Similarly multiple implementations for cryptography are desired. Constantine is an alternative implementation of cryptography for both consensus and execution layers.

As of November 2024, it is also the fastest cryptography backend for pairing-based cryptography on x86. In particular, with the rise of zkRollups, current non-go BN254 are becoming a bottleneck in Besu (Java), Nethermind (C#), Nimbus-eth1 (Nim) and Reth (Rust) as they are based on the old Zcash implementation (https://github.com/zcash-hackworks/bn) or libff (https://github.com/scipr-lab/libff) which were over 10x slower than state-of-the art already in January 2021 (https://hackmd.io/@gnark/eccbench)

Library organization

TODO: tag a new version for audit

Constantine stores high-level protocols which are exposed to end-users in its root:

C, Go and Rust API are exposed respectively in

Lower-level implementation is done in subfolders

Elliptic curves:

Field/Curve constants are specified in:

Misc:

Cryptography for the Consensus Layer

The Consensus Layer of Ethereum relies on the following cryptographic components:

C, Go and Rust wrappers are available here (and there are parallel headers as well):

Not implemented

The following primitives are of interest but not currently implemented in Constantine:

Cryptography for the Execution Layer

The execution layer relies on the following cryptographic components:

In scope?

The following primitive may be in scope, to be discussed:

Not implemented

The following primitives are of interest but not currently implemented in Constantine:

  • ECDSA over secp256k1
    • Note that secp256k1 has a specific "Crandall primes" optimization pending further debugging in #445
  • Keccak, vectorized Keccak, multi-keccak for merkle trees
  • Precompiles:
    • ECRecover
    • RIPEMD160
    • Blake2f
    • KZG point verification precompile (trivial, delegates to a consensus layer primitive)

Specifications and alternative implementations

Consensus Layer

Spec:

Implementations:

Execution Layer

Note on name: There are multiple BN254 curves in the litterature, the one we refer to has high 2-adicity to enable large FFTs in Snarks application. It used to be called alt_bn128 (128 being the security level it was considered at before Kim & Barbulesco TNFS attack) and it is also sometimes called bn256.

Specs:

Implementations (used or that were referred to when EIP were drafted):

Fuzzing

Constantine is integrated in

Constantine is not integrated in