UltrafastSecp256k1: a multi-backend secp256k1 execution engine for wallets, ZK, and high-throughput Ethereum tooling

Magicians Primordial Soup
, , ,
1

Hi everyone,

I would like to introduce UltrafastSecp256k1, an open-source secp256k1 cryptographic execution engine I have been developing.

Ethereum still relies heavily on secp256k1 at the wallet, signing, recovery, account, and infrastructure layers. Even when the protocol itself does not expose every primitive directly as an EVM operation, a large amount of Ethereum tooling still depends on efficient and correct secp256k1 execution:

  • wallet key generation and signing

  • ecrecover-style workflows

  • EIP-191 / personal signing

  • EIP-155 chain-id signing semantics

  • account recovery tooling

  • batch verification

  • ZK witness generation around ECDSA/secp256k1

  • hardware-constrained signing environments

  • mobile and embedded wallets

  • indexers, relayers, and signing infrastructure

The original goal of UltrafastSecp256k1 was performance, but the project has grown into a broader execution platform.

The short version:

UltrafastSecp256k1 is not only a secp256k1 library. It is a multi-backend cryptographic construction kit: primitives, protocols, GPU backends, bindings, benchmarks, and continuous verification in one repository.

What it includes

The project currently includes:

  • CPU fast-path secp256k1 implementation

  • constant-time paths for secret-bearing operations

  • C ABI

  • C++ API

  • static and shared-library builds

  • zero required runtime dependencies for the production engine

  • ECDSA sign / verify / recoverable signatures

  • Schnorr / BIP-340 primitives

  • ECDH

  • Ethereum signing and recovery layer

  • EIP-191 / personal-sign helpers

  • EIP-155 chain-id handling

  • Ethereum address derivation

  • Keccak-based Ethereum address workflow

  • batch verification paths

  • MuSig2 / FROST-related infrastructure

  • ZK / DLEQ / Pedersen / Bulletproof / witness-oriented primitives

  • CUDA backend

  • OpenCL backend

  • Apple Metal backend

  • ARM64, RISC-V, x86-64, embedded, and GPU benchmark coverage

  • CAAS, a continuous audit and reproducible evidence pipeline

The production engine itself does not require Python, CodeQL, SonarCloud, Cryptol, Lean, or any audit tooling at runtime. Those belong to the audit/development pipeline, not to the shipped library.

Ethereum-specific layer

The Ethereum module currently covers:

  • Ethereum address generation from secp256k1 public keys

  • keccak256

  • EIP-191 message hashing

  • personal-sign style signing and verification

  • recoverable ECDSA signatures

  • ecrecover-style public-key recovery

  • EIP-155 v encoding / chain-id handling

  • multi-chain coin descriptor support

The goal is to make Ethereum wallet and infrastructure workflows available as product-shaped APIs, not only as raw field/scalar/point primitives.

Why this may matter for Ethereum

A lot of Ethereum infrastructure is bottlenecked not by “can we do the cryptography?” but by:

  • how fast can we batch it?

  • how cheaply can we run it on mobile?

  • can it run on ordinary ARM64 devices?

  • can it run on RISC-V?

  • can GPU acceleration be local instead of cloud-dependent?

  • can ZK witness generation around ECDSA become cheap enough for practical pipelines?

  • can the same engine run across wallet, server, mobile, embedded, and accelerator contexts?

My view is:

Ethereum cryptography should scale across the hardware spectrum, not only across high-end x86 servers.

For example, low-power ARM64 devices, RISC-V boards, Jetson-class CPU+GPU devices, and integrated GPUs can all become practical targets if the cryptographic engine is designed for portability and reproducible validation from the beginning.

GPU and ZK work

The GPU backends are not meant to turn normal users into cloud-GPU dependents.

The intended model is:

  • CPU-first where possible

  • local GPU acceleration when available

  • server GPU acceleration only when explicitly useful

  • same API concepts across CUDA, OpenCL, and Metal

  • reproducible benchmarking and backend parity checks

For Ethereum, I am particularly interested in ECDSA/secp256k1 witness generation and ZK-adjacent workloads.

The project includes GPU-side work for:

  • knowledge proofs

  • DLEQ proofs

  • Pedersen commitments

  • Bulletproof-related operations

  • ECDSA SNARK witness generation

This is still an area where I would like feedback from people working on Ethereum ZK systems, account abstraction, wallet recovery, proving systems, and rollup tooling.

Design principles

The project follows a few principles:

  1. One engine, many targets
    The same codebase is intended to cover x86-64, ARM64, RISC-V, embedded devices, CUDA, OpenCL, and Metal.

  2. Runtime should stay lightweight
    The production engine has no required external runtime dependency.

  3. Acceleration should be optional
    GPU acceleration should be a local or infrastructure option, not a required trust dependency.

  4. Performance claims should be reproducible
    Benchmarks should be runnable by others, not treated as marketing claims.

  5. Security claims should become evidence
    Invariants, exploit classes, bug fixes, and regressions should become executable tests.

What I am looking for

I am not asking anyone to trust the project blindly. I am looking for adversarial technical feedback.

Questions I would especially like Ethereum developers to challenge:

  1. Which Ethereum wallet or infrastructure workloads would be most useful to benchmark first?

  2. What secp256k1/ECDSA/ZK witness flows are currently painful in Ethereum tooling?

  3. Which API semantics would make this more useful to wallet developers?

  4. Which parts of the Ethereum signing/recovery layer should be stricter?

  5. Which test vectors or differential references should be added?

  6. What would be required for Ethereum projects to consider such a library for non-consensus tooling?

  7. Are there EIP/ERC/RIP-adjacent use cases where this could reduce implementation friction?

Repository

Project:
https://github.com/shrec/UltrafastSecp256k1

I would appreciate feedback focused on correctness assumptions, missing tests, API shape, Ethereum-specific integration gaps, and workloads worth benchmarking.