← Home · Compare
commit-reveal vs py_ecc
Pure-Python ECC for Ethereum (BN128, BLS12-381, secp256k1)
Two very different products with overlapping language and ecosystem. py_ecc gives you elliptic curves and pairings; commit-reveal gives you a commitment primitive. You will reach for them in different sentences.
| Feature | commit-reveal | py_ecc | Better fit |
|---|---|---|---|
| Primary purpose | Commit-reveal commitments + Schnorr proofs of knowledge | Elliptic-curve arithmetic, pairings, BLS signatures | Comparable |
| Language | Pure Python (stdlib only) | Pure Python | Comparable |
| Runtime dependencies | None (only Python >= 3.8) | cached-property, eth-typing, eth-utils, mypy_extensions | commit-reveal |
| Curves implemented | secp256k1 (for the Schnorr ZKP only) | BN128 (alt_bn128), BLS12-381, secp256k1 | py_ecc |
| Pairing support | None | Optimal Ate pairing on BN128 and BLS12-381 | py_ecc |
| BLS signatures | Not implemented | Implemented (eth2 spec compatible) | py_ecc |
| Commit-reveal primitive | First-class, with eight selectable hash algorithms | Not provided as a primitive; build it yourself | commit-reveal |
| Zero-knowledge proof system | Schnorr proof of knowledge, non-interactive via Fiat-Shamir | Curve primitives only; bring your own proof system | commit-reveal |
| CLI for protocol prototyping | commit-reveal-secure with no-plaintext-at-rest storage | No CLI; library only | commit-reveal |
| Production usage at scale | Newer; designed for protocol prototyping and small-volume use | Used by Vyper, Ethereum tooling, consensus spec tests | py_ecc |
| Audit posture | mypy strict, Hypothesis property tests, bandit clean, no formal external audit claimed | Long deployment history in the Ethereum ecosystem; no formal external audit either | Comparable |
| License | MIT | MIT | Comparable |
Pick commit-reveal when
- ¶You need a commit-reveal scheme: H(value || salt) with a timing-safe reveal
- ¶You need a Schnorr proof of knowledge for a commitment, not a general circuit
- ¶You want zero external dependencies in your runtime
- ¶You want a library you can read top to bottom in an afternoon
Pick py_ecc when
- ¶You need pairing-friendly curves (BN128, BLS12-381) for SNARK arithmetic
- ¶You need BLS signatures, including aggregation, for Ethereum-style protocols
- ¶You are building EVM precompile equivalents and need exact compatibility
- ¶You need arithmetic over a specific finite field as a building block for something else
Honest note
They solve different problems.
It is entirely reasonable to depend on both: py_ecc for
the curve and pairing primitives, commit-reveal for the
commitment scheme. The libraries do not overlap on their core jobs.