We’ve already explained the logic and how to build a validation engine out of six components on paper in the first three articles of the series. Now it’s time to move to the real silicon: the digital signature validation card, Blitz. Designed to verify signatures in hardware and remove the major bottleneck in scaling cryptocurrencies.
Invented by Nexa Chief Scientist, Dr Peter Rizun, and being worked on for many years until we’ve reached this stage where we are running prototypes and validating signatures with the hardware. The machine is coming to life, and it takes on the most time-consuming and slowest step in the whole validation pipeline: checking digital signatures, now in real silicon.
This is the fourth article in the series where things are materializing, and we’re about to meet Blitz and head towards the main destination this journey leads to.
Digital Signature Verification
Nowadays we have fantastic ASICs for doing SHA-256. Unfortunately, hashing doesn’t help us to scale Bitcoin, because digital signature verification is a computational bottleneck. This isn’t just our claim: signature verification is expensive enough that Bitcoin Core skips it for historical blocks by default (assuming they are valid). The ecosystem’s most conservative software already treats checking every signature from genesis as too slow to insist on. However, with cheap verification, you can follow the main principle of crypto: “don’t trust, verify” and check everything.
To get a sense of how big a bottleneck it is, consider a global adoption scenario with five billion people making two transactions per day. That is 10 billion transactions per day in total, or about 100,000 transactions per second constantly sustained. The vision is hardware that can easily keep up, with lots of headroom, so about 1 to 10 million signature checks per second. A modern processor gets through twenty, maybe thirty thousand signature checks per second per core. A big desktop machine with enough cores can already keep up with the lower end of that range, but nobody likes running a node on their main desktop machine with all its cores bogged down, the fans blazing, and the office heating up. What we want is a tiny little node that plugs into the router. To do that, we need to build a digital logic circuit that verifies signatures more efficiently.
So what does that hardware look like? The hard part of signature verification is doing what’s called elliptic curve point scalar multiplication. You have these curve points, an x and a y coordinate; both coordinates are 256-bit numbers, and you’re doing a kind of crazy remapping procedure to calculate a new point. The circuit to do that is much larger and more complex than the circuit for SHA-256, but its heart is very simple. It’s just a ginormous 256 x 256-bit modular multiplier that’s built with millions of transistors. It takes two numbers, A and B, multiplies them, and returns the product modulo Bitcoin’s special prime. Everything else in the circuit exists to keep that machine busy.
A Card You Can Hold
This isn’t just an idea; Nexa’s Chief Scientist, Dr Peter Rizun, has built a signature accelerator called Blitz.
Blitz uses an FPGA rather than an ASIC as a starting point, and that’s pretty normal: you use an FPGA to prove your design first. An FPGA is like a reconfigurable ASIC, and it stands for field-programmable gate array. You describe your circuit in a hardware description language like Verilog, then use the FPGA toolchain to synthesize it onto the chip. So it’s not like the FPGA simulates your circuit in software; it actually rewires itself to become the circuit that you described. The circuit inside Blitz was built from the ground up specifically for digital signature verification. Only the transistors needed to perform this computation are active, and the data paths are laid out in hardware to allow the computation to proceed as quickly as possible.
The exploratory work that led to Blitz was a UBC Engineering Physics capstone project to build an FPGA elliptic-curve point multiplier; the project won the Roy Nodwell Award for the top capstone project. A “Signature FPGA” was already an item on the Nexa roadmap in November 2022. In February 2024, Bitcoin Unlimited approved taking part in the Australian Crypto Convention, where hiring a stand would also permit a demonstration of Nexa’s prototype FPGA for highly accelerated signature verification.
From Prototype to the Fourth Spin
The first Blitz was a 22 x 60 mm M.2 card. A few months later, in March 2025, the Blitz V0.2 elliptic curve point multiplier was routed, and it was half the size of its V0.1 predecessor: at only 22 x 30 mm, it fit in an M.2 A or E slot, just like the Google Coral accelerator card. The FPGA could now be reloaded with a new bitstream (the file that configures the FPGA into a circuit) without removing the card, so your node software could update the accelerator directly. In October 2025, V0.21 of the Blitz M.2 accelerator card arrived, with the 484-pin Efinix Ti375 FPGA installed, sitting in its USB-C debug cradle after being loaded with a bitstream.
Blitz is now on its fourth board spin. It is a standard M.2 2280 M-key card, the same size and socket as an NVMe SSD, and it needs one PCIe lane, which any NVMe-capable M.2 slot provides. Most desktop motherboards have a spare slot; many laptops do too. No spare M.2 slot? Inexpensive passive M.2-to-PCIe adapters let you use a regular PCIe slot. Rated maximum power is 8 W, within the socket’s normal envelope. Even a Raspberry Pi 5 has an exposed PCIe lane which can connect to Blitz to offload digital signature verification.
Blitz Looks Like a File
So how does Blitz connect to your computer? The answer is PCIe and memory-mapped Input/Output (I/O). When your computer boots up, the PCIe subsystem scans all the devices, sees Blitz, and maps its registers into the address space reserved for memory-mapped I/O. This is really cool because, from your computer’s perspective, it doesn’t know it’s talking to Blitz. It can’t tell the difference between Blitz’s registers and just plain old memory.
Of course, a modern operating system won’t let you poke around physical memory, so user-space access to Blitz goes through a kernel driver, which makes it even easier. A user process connects to the kernel driver, and Blitz looks like a file with no SDK or vendor library. A signature check is a 160-byte record: five curve values, 32 bytes each, and a verdict is one byte. You write requests and read verdicts in order, and batching is just longer writes. Multiple user-space processes can run in parallel, and they can all have Blitz open and make signature requests at the same time. The kernel driver does the heavy lifting, tagging every request and routing each verdict back to the process that asked.
PASS, FAIL, or UNKNOWN
Signature verification is consensus-critical: a wrong PASS is how a node accepts an invalid chain. Hardware that accelerates it must therefore do more than be fast, it must make its own failure visible.
So the card never answers in binary. A verdict is PASS, FAIL, or UNKNOWN, and every failure of the machinery itself (a timeout, a dropped response, an integrity-checksum mismatch) is delivered as UNKNOWN, structurally distinct from a cryptographic verdict. The hardware can stall, the cable can be pulled mid-batch, and the one thing that cannot happen is a transport problem dressed up as a PASS or a FAIL.
That is what makes the card fit for consensus-critical software: an UNKNOWN is an instruction to fall back and re-check in software, never a signal to accept or reject a signature. A “don’t know” must never become a FAIL: coercing it would reject a block the rest of the network accepts, and that is a chain fork.
The Card Checks Itself
A verdict from opaque silicon isn’t a proof. Ask any auditor, and you don’t trust the report; you trust the independent check, and every Blitz card carries its own.
The auditor is an independent RISC-V processor beside the accelerator, and the two answer the same question from opposite media. The verify engine is a hardened, deeply pipelined hardware datapath built for throughput; the auditor is software, the trusted libsecp256k1 C library, the same reference implementation the ecosystem uses to verify signatures, compiled onto the RISC-V core. The split is deliberate; the auditor is not a second hardware verifier, which could repeat the same design mistake. It shares nothing with the engine but the mathematics: different authors, different medium, and different tools.
The check is constant and continuous. At power-up, the verification pipeline is closed, and the only thing that opens it is the auditor passing its power-on self-checks. From then on, the auditor feeds vectors through the accelerator’s own datapath, 100 audit sigchecks per second by default, including invalid signatures the engine must reject.
All Signatures Verified
In July 2026, Dr Peter Rizun pressed a button, and an app streamed every signature in the Nexa blockchain to Blitz. Blitz verified each one and sent the result back; there were over ten million signatures to check: 10,648,406. Every one came back PASS, with zero FAIL and zero UNKNOWN. Check a single signature, and it comes back in about ninety microseconds, round trip, but change one digit, and it fails.
“They said Bitcoin couldn’t scale: watch our tiny Blitz FPGA accelerator card verify every signature in the Nexa blockchain (10.6 million) in 75 seconds.” – Dr Peter Rizun, X, 17 July 2026
That run used an earlier two-core build, and the current design has four verifier cores, four copies of the verify engine side by side, and with all four busy, the host measures 297,100 verifications per second sustained, every one of them sent and answered over PCIe. Measured on the same signature scheme with the same reference library, libsecp256k1, one core of a desktop CPU (Intel Core i7-12700KF) does about 29,900 verifications per second. Four cores of Blitz sustain about 9.9 times that, while your CPU stays free for everything else. Multiplied across all twelve cores, that CPU would edge out one Blitz, but then the whole machine does nothing but verify signatures, and nobody runs a node that way. Both the whole-chain run and the 297,100 figure were measured with the Blitz design running on Efinix’s Ti375 development kit, the same FPGA the card carries.
That is about three times the raw rate of the global adoption scenario at the top of this article, 100,000 transactions per second, from four cores on one FPGA. The 1 to 10 million we said we wanted for headroom comes from more cores, more cards, and, eventually, an ASIC.
As of September 2026, a real Ti375 is running on a test bench, verifying Schnorr signatures, including checks mirrored from a live node on Nexa: real signatures from real traffic, compared against the node’s own verdicts. Most of the time it sits near idle, because today’s networks barely register against hardware like this. That headroom is the point: capacity has to exist before the traffic that needs it can, and validation should never again be the reason a chain stays small.
In Conclusion
Our vision at Nexa is decentralized, open protocols; simple open-source reference implementations, and a competitive market for the best implementations. The host side is already public as open source: the kernel driver, the demos, the test rigs, and a virtual card that lets you develop and test with no hardware at all, plus a working reference verification core and the auditor. One block is closed by design: the optimized engine that makes the card fast, and the one block you can’t read is the one block the card audits continuously.
The card is never locked either, and it runs the encrypted production bitstreams out of the box, but you can load any bitstream you build, whenever you want, so Blitz is also a general-purpose PCIe FPGA development platform.
So this is Blitz: the slowest step of the validation pipeline, lifted off the CPU and handed to a circuit built for nothing else, fast enough to check every signature Nexa has ever seen in little more than a minute. It is proven on an FPGA today, with a beta batch ahead of us. But signatures are only one piece of a node. The next article asks the bigger question: what happens when you put the whole node inside an FPGA?
Sources
-
Why signatures are the bottleneck, the global adoption scenario, the modular multiplier, why an FPGA, memory-mapped I/O, and “Blitz looks like a file”: Peter Rizun, “Introduction to Hardware Acceleration for Cryptocurrency,” BCH Bliss, Ljubljana, 2025, https://www.youtube.com/watch?v=NsCi4FJ13JE. Written recap on the Nexa forum: https://forum.nexa.org/t/scaling-with-hardware-dr-peter-rizun-presents-an-introduction-to-hardware-acceleration-for-cryptocurrency/606.
-
Blitz as an FPGA-based digital-signature verification engine, the first 22 x 60 mm card, the circuit built from the ground up for signature verification, and the open reference implementations vision: https://forum.nexa.org/t/blitz-a-digital-signature-verification-engine-for-the-nexa-software/433. The Sydney debut: https://forum.nexa.org/t/week-48-nexa-news-blitz-fpga-based-digital-signature-verification-engine/441.
-
The board spins, the Raspberry Pi 5, and the whole-chain run, Peter Rizun on X: https://x.com/PeterRizun/status/1896914713893908970, https://x.com/PeterRizun/status/1978255046874652843, https://x.com/PeterRizun/status/1877448593184796894, https://x.com/PeterRizun/status/2078059071505367294.
-
Bitcoin Core skipping historical signature checks by default (assumevalid), Bitcoin Core 0.14.0 release notes: https://bitcoincore.org/en/releases/0.14.0/.
-
Previous articles in this series: “Why Nexa Builds Hardware,” https://forum.nexa.org/t/why-nexa-builds-hardware/1723, “A Node Made of Wires,” https://forum.nexa.org/t/a-node-made-of-wires/1730, and “Scaling By Circuit,” https://forum.nexa.org/t/scaling-by-circuit/1749.





