vano · #1 ·
Over the last several months I have been working on a large hardening and restructuring cycle for UltrafastSecp256k1.
v4.0 is not just another optimization release.
It represents a shift in how I think about cryptographic infrastructure, benchmarking, integration, and verification itself.
The release focuses on:
- verification-first engineering
- reproducible benchmark evidence
- shim-based integration
- large-scale audit infrastructure
- CI hardening
- cross-platform organization
- performance regression detection
- rollback-safe experimentation
The central idea behind the release is simple:
Don’t trust the claims. Verify the system.
Why I Started This Project
UltrafastSecp256k1 did not begin as a “replacement project”.
I originally built the engine independently, without even knowing much about libsecp256k1’s internal structure or Bitcoin Core’s integration details.
The goal was straightforward:
Build a highly optimized, portable secp256k1 engine.
Over time, however, the project evolved into something larger:
- performance experimentation
- cross-platform optimization
- audit automation
- integration research
- benchmarking methodology
- verification tooling
Eventually the question stopped being:
“How fast is this?”
and became:
“How do we verify all of this continuously?”
From Library to Verification Package
One of the biggest conceptual shifts in v4.0 was changing how I viewed the repository itself.
Instead of treating it as “just a crypto library”, I started treating it as:
a verification package
This changed almost every engineering decision.
The repository now emphasizes:
- measurable evidence
- reproducible benchmarks
- explicit limitations
- CI traceability
- audit coverage
- integration isolation
- rollback-safe adoption paths
The idea was heavily inspired by Bitcoin’s philosophy:
Don’t trust. Verify.
Shim-Based Integration
One of the most important additions in v4.0 is the shim architecture.
The shim allows experimentation and benchmarking without deeply modifying Bitcoin Core itself.
This matters because integration risk is often one of the biggest concerns for any alternative backend.
The shim approach provides:
- optional adoption
- minimal integration surface
- easier rollback
- comparative testing
- backend isolation
The intention is not:
“Replace everything immediately.”
The intention is:
“Make experimentation measurable and reversible.”
CAAS — Continuous Assurance Architecture System
A major part of the release cycle was the evolution of CAAS.
Originally it started as a testing system.
But during the v4.0 hardening cycle it evolved into a broader verification methodology.
The idea behind CAAS is continuous evidence reconciliation:
documentation
benchmarks
CI
audit modules
integration behavior
performance claims
must continuously agree with reality.
This sounds obvious.
In practice, maintaining that consistency across a large optimized codebase is extremely difficult.
During the v4.0 cycle CAAS helped identify:
- benchmark drift
- CI false-green scenarios
- stale documentation
- integration inconsistencies
- performance regressions
- edge-case arithmetic issues
- audit wiring problems
Multi-Agent Review Workflows
Another major area of experimentation during v4.0 was structured LLM-assisted review.
I found that large language models become surprisingly effective engineering review tools when:
- scope is constrained
- repository structure is clean
- graph-aware tooling exists
- invariants are explicit
- verification loops are strong
The workflow evolved into:
small scoped reviews
memory/state tracking
performance-oriented passes
false-positive suppression
rollback-safe commits
continuous validation
This process uncovered a large number of:
- hot-path inefficiencies
- unnecessary recomputations
- stale validation logic
- integration edge cases
- CI inconsistencies
- performance regressions
Many optimizations in v4.0 came directly from this workflow.
Benchmarking Philosophy
One thing I intentionally tried to avoid in v4.0 was relying entirely on synthetic microbenchmarks.
Microbenchmarks are useful.
But real-world execution flow matters more.
Recent benchmark passes focused heavily on:
- Bitcoin Core integration paths
- ConnectBlock workloads
- transaction signing
- verification flows
- script path validation
- Schnorr operations
- EllSwift-related behavior
The release also places strong emphasis on reproducibility and evidence artifacts instead of isolated benchmark screenshots.
Cross-Platform Focus
UltrafastSecp256k1 now has significantly improved organization for multiple targets:
- x86
- ARM64
- RISC-V
- ESP32
- STM32
- Android
- iOS
- WASM
- CUDA
The long-term goal is portability without abandoning optimization.
The Hardest Part Wasn’t Optimization
Ironically, the most difficult part of v4.0 was not performance engineering.
It was convergence.
For weeks the work consisted almost entirely of:
- fixing small edge-case bugs
- reconciling benchmark evidence
- cleaning CI semantics
- removing stale references
- validating documentation
- fixing integration drift
- tightening verification loops
That phase is exhausting because progress becomes less visible.
But it is also the phase where engineering systems become trustworthy.
Final Thoughts
v4.0 is not the end of the project.
It is the point where the engineering process itself became significantly more mature.
The repository now reflects a much stronger emphasis on:
- verification
- reproducibility
- transparency
- auditability
- rollback safety
- measurable engineering
And ultimately, that is what I believe matters most for infrastructure software.
Not:
“Trust the implementation.”
But:
Measure it.
Verify it.
Challenge it.
Improve it.
Release
UltrafastSecp256k1 v4.0.0 Release