arXiv:2606.14007v1 [cs.DC] 12 Jun 2026
VaultxGPU: GPU-Accelerated Blockchain Consensus Samuel Taiwo Fatunmbi
Om Amit Gandhi
Luke Logan
College of Computing Illinois Institute of Technology Chicago, USA [email protected]
College of Computing Illinois Institute of Technology Chicago, USA [email protected]
College of Computing Illinois Institute of Technology Chicago, USA [email protected]
Abstract—Blockchain consensus mechanisms based on Proof-
miners to repeatedly compute cryptographic hashes in a race to
of-Work consume significant energy, with Bitcoin alone estimated
solve an arbitrary puzzle, consuming approximately 150 TWh
at approximately 150 TWh per year. Proof-of-Space reduces this
of electricity per year in the case of Bitcoin alone [1], which
cost by replacing repeated computation with storage, but plot generation remains bottlenecked by CPU hashing throughput.
is comparable to the annual energy consumption of many mid
Prior work on VaultX demonstrated a high-performance CPU-
sized countries. Proof-of-Space (PoSp) offers a more energy-
based Proof-of-Space plotter using multi-threaded Blake3 hash-
efficient alternative by replacing repeated computation with
ing, achieving plotting speeds 4 to 50x faster than Chia depending
storage. Miners pre-compute and store large plot files on disk,
on hardware configuration. In this paper, we present VaultxGPU,
then respond to challenges by looking up matching entries
a GPU-accelerated extension of the VaultX plotter that offloads the Blake3 hashing pipeline to the GPU using custom kernels. We
rather than hashing on demand, reducing energy consumption
implement the plotter in both CUDA for NVIDIA hardware and
by approximately 1000x [2]. However, the one-time cost
SYCL for AMD and Intel GPUs, keeping Table 1 entirely in GPU
of generating these plot files is itself bottlenecked by CPU
VRAM and fusing the sort and match stages into a single kernel
hashing throughput, limiting how quickly a miner can begin
to minimize data movement. We evaluate VaultxGPU across K-
participating in the network. Prior work on VaultX introduced
values 27 through 31 against CPU baselines. Our SYCL GPU implementation achieves a 59.2x speedup over a single-threaded
a CPU-based PoSp plotter using multi-threaded Blake3 hash-
CPU baseline, completing a K=31 plot in 45.4 seconds compared
ing that significantly outperforms existing implementations
to 2688 seconds, and outperforms even the best 384-thread CPU
[3], yet even a high-end 192-core CPU costing upwards of
configuration. These results confirm that GPU acceleration is the
$10,000 is outpaced by a $5,000 machine equipped with
correct direction for scaling Proof-of-Space plotting beyond what
a single Tesla V100 GPU, a gap that motivates the GPU-
CPU parallelism can achieve. Index Terms—Blockchain, Proof-of-Space, GPU computing, CUDA, SYCL, Blake3, parallel hashing
accelerated approach presented in this paper. A. Challenges Accelerating Proof-of-Space plot generation on the GPU
I. I NTRODUCTION introduces several non-trivial engineering challenges. The first Blockchain networks rely on consensus mechanisms to
is parallelizing the Blake3 keyed hashing algorithm [4], which
ensure all participants agree on the state of a distributed ledger.
was designed for sequential CPU execution. In VaultxGPU,
The dominant mechanism, Proof-of-Work (PoW), requires
each of the 2k nonces must be processed by an indepen-
dent GPU thread, requiring the hash to be computed en-
entirely and eliminating all inter-thread dependencies by com-
tirely within a single thread’s register file with no shared
puting each hash entirely within a single thread’s register
state, a fundamental redesign of the data flow rather than a
file. Second, we provide dual backend implementation. CUDA
simple port. The second challenge is cross-vendor support:
[5] targeting NVIDIA hardware via nvcc and SYCL [6]
NVIDIA and AMD require entirely separate programming
targeting AMD and Intel GPUs via Intel oneAPI DPC++,
models. In the CUDA implementation [5], the 256-bit plot
sharing a common Blake3 kernel in blake3_common.h
key is stored in __constant__ memory and broadcast
while adapting memory management, atomic semantics, and
to all threads in a warp at zero memory bandwidth cost,
key storage to each programming model. Third, we fuse
while atomic bucket insertions are handled implicitly by the
the sort and Table 2 generation stages into a single GPU
runtime. In the SYCL implementation [6], constant mem-
kernel that operates entirely within shared memory per bucket,
ory does not exist as a concept; the key must instead be
avoiding any intermediate global memory round-trip between
allocated with malloc_device and passed as a pointer
the two stages and launching one block per bucket across all
argument, introducing additional memory fetch overhead, and
224 buckets simultaneously. Fourth, we integrate VaultxGPU
all atomic operations must be declared explicitly using fully-
into the VaultX Proof-of-Space consensus mechanism [3],
typed sycl::atomic_ref objects with defined memory
producing plot files that are byte-compatible with the existing
ordering, scope, and address space. The third challenge is that
CPU VaultX prover, enabling GPU-generated plots to be
the entire Table-1 data structure. All 2k nonce-hash records
searched directly without any format conversion. Finally, we
organized into 224 buckets which must reside in GPU VRAM
present a detailed performance evaluation across K-values
throughout hashing and matching, as any intermediate transfer
27 through 31, comparing CUDA and SYCL GPU backends
over PCIe would negate the GPU’s throughput advantage. At
against both a naive single-threaded CPU baseline and the
K = 31 this alone requires 24.7-GB of VRAM, pushing
best 384-thread CPU configuration, and characterize per-stage
against the physical limits of even high-end hardware. Finally,
bottlenecks in the pipeline across all tested K-values.
the sort and match stage runs insertion sort entirely within a
II. R ELATED W ORK
single thread per bucket, a deliberate simplicity tradeoff that becomes an O(n2 ) bottleneck as bucket sizes grow with K,
The work presented in this paper sits at the intersection of three active research areas which are energy-efficient
contributing to the sharp rise in Sort/Table-2 time from 9–11% blockchain consensus, Proof-of-Space protocol design, and of total pipeline time at K = 27–29 to 34% at K = 31. GPU-accelerated cryptographic hashing. This section surveys B. Contributions
the most relevant prior work in each area and positions VaultxGPU with respect to existing approaches, highlighting
VaultxGPU makes the following contributions to GPUthe gap that GPU-accelerated Proof-of-Space plotting fills. accelerated Proof-of-Space plotting. First, we design and implement a custom GPU kernel for Blake3 keyed hashing
A. Proof-of-Work and Its Energy Cost
[4] that assigns one thread per nonce across the full 2k
Proof-of-Work (PoW) consensus, first introduced by Bitcoin
nonce space, replacing the sequential CPU hashing pipeline
[7], requires network participants to repeatedly compute SHA-
256 cryptographic hashes in search of a hash value below
nonce-hash pairs into contiguous memory buckets, followed
a dynamically adjusted target threshold. The computational
by an in-place sort within each bucket, a pairwise match stage
difficulty of this puzzle is calibrated so that the network
that compares nonce pairs against a matching factor threshold
collectively finds a valid solution approximately once every
to produce Table-2, and finally a sequential disk write phase
ten minutes, ensuring a predictable block production rate
that flushes the completed plot file to storage. The entire
regardless of total network hash power. While this mechanism
pipeline runs multi-threaded on CPU using standard POSIX
provides strong security guarantees through its economic cost
threads, with all stages parallelized across available cores.
of attack, it achieves security at the direct expense of energy.
As shown in Fig. 2, benchmarking was conducted on a 64-
As of 2021, the Bitcoin network alone consumed an estimated
core server-grade machine, demonstrating that plotting time
143 TWh of electricity annually [1], a figure that places it
decreases consistently with thread count, dropping from 44.80
on par with the total electricity consumption of countries
minutes on a single thread to 0.87 minutes at 384 threads for
such as Norway and Bangladesh. This energy expenditure is
a K=31 plot. Compared against the Chia reference plotter [2],
structurally wasteful, every hash computed during a mining
VaultX achieved 4 to 50x faster plot generation depending on
round that does not meet the target is discarded immediately,
thread count.
contributing nothing to the network beyond demonstrating that work was performed. The introduction of applicationspecific integrated circuits (ASICs) optimized for SHA-256 hashing has further concentrated mining power and driven energy consumption upward, as miners are incentivized to
Fig. 1. VaultX CPU plotting pipeline: Hash Generation (Table 1) → Sort → Match (Table 2) → Write.
deploy ever-increasing amounts of specialized hardware to remain competitive. Numerous alternative consensus mechanisms have been proposed to address this inefficiency, including Proof-of-Stake [8], which replaces computational work with economic stake, and Proof-of-Space [2], which replaces computation with storage. VaultxGPU builds on the Proof-ofSpace direction, accepting its one-time plot generation cost as a worthwhile tradeoff against the ongoing energy drain of Proof-of-Work.
Fig. 2. VaultX CPU K=31 runtime vs. thread count across server-grade hardware, showing diminishing returns beyond 64 threads.
B. VaultX CPU Baseline The VaultX CPU plotter [3], the direct predecessor to
III. D ESIGN
VaultxGPU, implements a four-stage pipeline as shown in
This section describes the design and implementation of
Fig. 1: hash generation produces Table-1 by hashing all 2k
VaultxGPU, a GPU-accelerated Proof-of-Space plotter built
nonces using the Blake3 keyed hash algorithm [4] and storing
on top of the VaultX CPU baseline. We first present the
overall pipeline architecture and how computation is distributed between the GPU and CPU, followed by a detailed description of the CUDA implementation targeting NVIDIA hardware and the SYCL implementation targeting AMD and Intel GPUs. Both backends share a common Blake3 hashing kernel and produce byte-compatible plot files, differing only in how they handle memory management, atomic operations,
Fig. 3. VaultxGPU pipeline: Hash Generation and fused Sort+Match stages run entirely on the GPU in VRAM, with Table-2 transferred over PCIe to the CPU for disk write in 4MB sequential chunks.
and key storage. microarchitecture directly for maximum hardware-specific opA. VaultxGPU Architecture VaultxGPU redesigns the VaultX plotting pipeline to offload the three compute-intensive stages entirely to the GPU, as illustrated in Fig. 3. In the hash generation stage, a custom Blake3 CUDA kernel launches one thread per nonce across the full 2k nonce space, hashing each nonce independently and inserting the resulting nonce-hash pair into its corresponding bucket in GPU VRAM using atomic operations, producing Table-1 entirely on-device without any intermediate disk write. The sort and match stages are fused into a single GPU kernel, where each block is assigned one bucket, loads its nonces into shared memory, performs an insertion sort by hash value in shared memory, and then runs pairwise matching against an expected distance threshold to produce Table-2 records, with data never leaving shared memory between the two stages. Once Table-2 is complete, it is transferred from GPU VRAM to the host CPU over PCIe and written to disk in 4MB sequential chunks as a flat binary plot file. This design keeps all compute-heavy work on the GPU and limits PCIe traffic to a single transfer of the final output, minimizing the overhead of the CPU-GPU boundary.
timization. The 256-bit plot key is stored in __constant__ memory via cudaMemcpyToSymbol, which places it in the GPU’s broadcast cache and serves it to all threads in a warp at zero memory bandwidth cost. Table-1 generation launches one thread per nonce with a fixed block size of 256 threads, where each thread independently converts its global ID to a little-endian nonce, computes a Blake3 keyed hash, extracts the bucket index from the hash prefix, and atomically claims a slot in the corresponding bucket using atomicAdd, with memory ordering, scope, and address space all handled implicitly by the CUDA runtime. The fused Sort+Match kernel launches one block per bucket across all 224 buckets, dynamically sizing shared memory per block as RPB × (NONCE_SIZE + HASH_SIZE + 8) bytes to hold nonces, hashes, and 64-bit sort keys entirely in shared memory. Following the sort and match phase, Table-2 is streamed to disk using a 256-MB pinned host staging buffer allocated via cudaMallocHost, which enables faster DMA transfers during the PCIe write phase compared to pageable host memory. C. SYCL Implementation (AMD/Intel) The SYCL implementation targets AMD and Intel GPUs using Intel oneAPI DPC++ and is designed to
B. CUDA Implementation (NVIDIA)
be portable across GPU vendors while also supporting
The CUDA implementation of VaultxGPU targets NVIDIA
a transparent fallback to host CPU execution when no
hardware and is compiled using nvcc against the NVIDIA
compatible GPU device is detected. Unlike the CUDA
backend, SYCL provides no __constant__ memory
A. Experimental Setup
abstraction; the plot key is instead allocated on the device
VaultxGPU was evaluated across two sets of testbeds cor-
using sycl::malloc_device and passed as a pointer
responding to the CUDA and SYCL backends respectively.
argument to each kernel, introducing an additional global
For the CUDA backend, experiments were conducted on two
memory fetch per kernel invocation compared to the CUDA
server-grade machines: the Mystic Eightsocket, equipped with
constant memory broadcast. Atomic bucket insertions require
eight 32GB VRAM Tesla V100 NVIDIA GPUs and a 192-core
explicit declaration of a fully-typed sycl::atomic_ref
CPU with 770GB RAM, and the Mystic Epycbox, equipped
object
memory_order::relaxed,
with eight 16GB VRAM Tesla V100 NVIDIA GPUs and a
and
64-core CPU with 770GB RAM. For the SYCL backend,
with
defined
memory_scope::device, access::address_space::global_space
experiments were conducted on a 6-core Thermaltake PC with
parameters, in contrast to the implicit atomics of the
48GB RAM, testing two GPU configurations: an AMD/ATI
CUDA runtime. The SYCL backend also enforces a per-
Vega 20 Radeon GPU with 16GB VRAM and an Intel DG2
allocation size check against max_mem_alloc_size
Arc A770 GPU with 16GB VRAM. The CPU baseline results
before attempting to allocate Table-1 and Table-2, as some
were obtained on the 64-core server-grade machine running the
drivers, including Intel Arc, cap individual allocations at
naive VaultX CPU plotter with thread counts ranging from 1
approximately 4-GB regardless of total available VRAM.
to 384. All implementations were evaluated across K-values
The fused Sort+Match kernel mirrors the CUDA structure
27 through 31, with each K-value doubling the problem size
using SYCL local memory accessors in place of CUDA
relative to the previous, and best-run times recorded across
shared memory, and sycl::group_barrier in place
multiple runs for each configuration.
of __syncthreads(), with the disk write phase using a
B. Overall Speedup at K = 31
standard heap-allocated 256-MB staging buffer rather than pinned memory, as SYCL provides no direct equivalent to
Fig. 4 presents the speedup of all implementations at K = 31 relative to the naive single-threaded CPU baseline
cudaMallocHost. of 2688 seconds. The SYCL GPU achieves the best result at IV. E VALUATION This section evaluates the performance of VaultxGPU across K-values 27 through 31, comparing the CUDA and SYCL GPU backends against both a naive single-threaded CPU baseline and the best multi-threaded CPU configuration. We measure total plotting time, per-stage pipeline breakdown, parallel efficiency, and scaling behavior as problem size doubles with each K-step, with the goal of characterizing where GPU acceleration provides the most benefit and where bottlenecks remain.
59.2× speedup (45.4 seconds), followed by CUDA GPU at 50.0× (53.8 seconds). The best 384-thread CPU configuration achieves 51.5× (52.2 seconds), comparable to CUDA GPU but at significantly higher hardware cost. The SYCL CPU fallback trails at 27.1× (99.2 seconds), nearly double the runtime of either GPU implementation, confirming that the GPU-CPU performance gap widens as problem size increases. C. Pipeline Stage Analysis Fig. 5 presents the per-stage time breakdown of the CUDA GPU pipeline across K-values 27 through 31. The disk write
seconds, confirming that additional CPU threads cannot close the performance gap with GPU acceleration.
Fig. 4. Speedup at K = 31 relative to naive single-threaded CPU baseline (2688s) across all implementations.
Fig. 6. Naive CPU K = 31 actual vs. ideal speedup (left) and parallel efficiency (right) across thread counts 1–384.
stage dominates across all K-values, accounting for 80–82% of total time at K = 27–29 and remaining the largest stage at
E. Scaling with Problem Size
K = 31 with 59%. The Sort/Table-2 stage grows from 11% at
Fig. 7 presents the runtime ratio T (k + 1)/T (k) for both
K = 27 to 34% at K = 31, reflecting the O(n2 ) insertion sort
GPU implementations as problem size doubles with each K-
bottleneck as bucket sizes increase. Table-1 generation remains
step, with an ideal linear scaling ratio of 2.0× shown as a
the smallest stage at 7–9% across all K-values, confirming that
reference. The SYCL GPU maintains near-ideal linear scaling
the Blake3 hashing kernel scales efficiently with problem size.
across all K-steps, with ratios of 1.95×, 2.01×, 2.02×, and 2.03× from K = 27 through K = 31, demonstrating that SYCL scales predictably as problem size grows. The CUDA GPU begins in the sublinear region at K = 27→K = 28 with a ratio of 1.72×, converges toward ideal at K = 28→K = 29 with 1.94×, and then enters the superlinear region at K = 30→K = 31 with a ratio of 2.40×, indicating that CUDA kernel management becomes increasingly inefficient at larger
Fig. 5. CUDA GPU per-stage time breakdown across K-values 27–31, showing absolute runtimes (left) and proportional stage shares (right).
bucket sizes and higher K-values. F. Cross-Implementation Runtime Comparison
D. CPU vs. GPU Parallel Efficiency
Fig. 8 compares the best total runtime across all K-values
Fig. 6 shows the actual versus ideal speedup and parallel
for SYCL CPU, SYCL GPU, and CUDA GPU implementa-
efficiency of the naive CPU implementation at K = 31.
tions. Both GPU implementations consistently outperform the
While speedup improves consistently from 1 to 384 threads, it
SYCL CPU across all K-values, with the performance gap
diverges sharply from ideal linear scaling beyond 16 threads,
widening significantly as K increases. At K = 27 the SYCL
with parallel efficiency dropping from 100% at 1 thread to
CPU completes in 8.9 seconds compared to 2.8 seconds for
just 14% at 384 threads. The best CPU result of 52.2 seconds
SYCL GPU and 3.2 seconds for CUDA GPU. By K = 31,
at 384 threads remains slower than the SYCL GPU at 45.4
the SYCL CPU runtime nearly doubles to 99.2 seconds while
even the best 384-thread CPU configuration at a significantly lower hardware cost. The CUDA GPU implementation achieves 50.0× speedup, confirming that both NVIDIA and AMD hardware can effectively accelerate the Blake3 hashing pipeline. These results establish GPU acceleration as the correct direction for scaling Proof-of-Space plotting beyond what CPU parallelism can achieve. The most effective design decision was fusing the sort Fig. 7. GPU scaling with problem size: runtime ratio T (k + 1)/T (k) for SYCL GPU and CUDA GPU across K-steps 27–31, with ideal linear scaling at 2.0×.
and Table-2 match stages into a single GPU kernel operating
SYCL GPU and CUDA GPU reach only 45.4 seconds and
global memory round-trip between the two stages. SYCL’s
53.8 seconds respectively, demonstrating that GPU runtimes
portability across AMD and Intel hardware also proved to be
scale far more gracefully than CPU runtimes as problem size
a significant advantage, allowing a single codebase to target
grows. At K = 30, SYCL GPU and CUDA GPU achieve
multiple GPU vendors with minimal changes. However, two
identical runtimes of 22.4 seconds, with the gap between the
design decisions did not perform as well as anticipated. The
two opening only at K = 31 as CUDA kernel management
insertion sort running on a single thread per bucket introduced
degrades at larger bucket sizes.
an O(n2 ) bottleneck that became increasingly significant at
entirely within shared memory, eliminating any intermediate
larger K-values, contributing to Sort/Table-2 growing from 11% of total pipeline time at K = 27 to 34% at K = 31. Additionally, CUDA kernel management degraded at larger bucket sizes, causing CUDA to fall into the superlinear scaling region at K = 30→K = 31 with a runtime ratio of 2.40×, well above the ideal 2.0×. The most significant bottleneck identified across all Kvalues was disk I/O during the write phase, accounting for 59–82% of total pipeline time depending on K-value. This Fig. 8. Best-run time comparison across all K-values for SYCL CPU, SYCL GPU, and CUDA GPU implementations.
bottleneck persists regardless of GPU performance because the write stage runs entirely on the host CPU and is inher-
V. A NALYSIS AND C ONCLUSION
ently sequential. If we were to redo this project, we would
VaultxGPU demonstrates that GPU acceleration is a viable
address this from the start by overlapping PCIe transfers with
and effective direction for Proof-of-Space plot generation. The
GPU computation using asynchronous CUDA streams, and
SYCL GPU implementation achieves a 59.2× speedup over a
by investigating direct NVMe write paths to reduce host CPU
single-threaded CPU baseline at K = 31, completing a plot
involvement in the write pipeline. We would also replace the
in 45.4 seconds compared to 2688 seconds, and outperforms
single-threaded insertion sort with a GPU optimized parallel
sort algorithm such as radix sort or merge sort to eliminate the O(n2 ) bottleneck, and profile CUDA kernel occupancy earlier in development to close the performance gap with the SYCL implementation. Future work will focus on three directions. First, replacing the insertion sort with a GPU-parallel sort algorithm to eliminate the O(n2 ) bottleneck that becomes the dominant cost at larger K-values. Second, optimizing the disk write pipeline by overlapping PCIe transfers with GPU computation and exploring direct NVMe write paths to reduce the 59– 82% I/O overhead that currently dominates the pipeline. Third, extending VaultxGPU to support K-values beyond 31 through chunked VRAM tiling, which would allow the plotter to handle problem sizes that exceed the physical VRAM capacity of a single GPU without falling back to CPU execution.
ACKNOWLEDGMENT The authors thank Dr. Luke Logan for supervision and the Illinois Institute of Technology College of Computing for providing the research infrastructure used in this project. AUTHOR C ONTRIBUTIONS Om Amit Gandhi designed and implemented the CUDA backend targeting NVIDIA hardware, including the Blake3 hashing kernel, fused Sort+Match kernel, and pinned-memory disk write pipeline. Samuel Fatunmbi implemented the SYCL backend targeting AMD and Intel GPUs, conducted all benchmark experiments across K-values 27 through 31, and produced the performance figures and analysis presented in Section IV. Both authors contributed equally to the overall system architecture and the writing of this paper. R EFERENCES [1] “Bitcoin devours more electricity than many countries,” https://www.ibtimes.com/ infographic-bitcoin-devours-more-electricity-many-countries-3194694, May 2021. [2] B. Cohen and K. Pietrzak, “The chia network blockchain,” https://www. chia.net/wp-content/uploads/2023/01/proof of space.pdf, Jan. 2023. [3] S. T. Fatunmbi and O. A. Gandhi, “VaultX: A CPU-based Proof-of-Space plotter,” 2026, illinois Institute of Technology, unpublished. [4] J. O’Connor, J.-P. Aumasson, S. Neves, and Z. WilcoxO’Hearn, “BLAKE3: One function, fast everywhere,” https: //github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf, 2020. [5] NVIDIA Corporation, “CUDA C++ programming guide,” https://docs. nvidia.com/cuda/cuda-c-programming-guide/index.html, 2023. [6] Intel Corporation, “Intel oneapi DPC++ compiler,” https://www.intel.com/ content/www/us/en/developer/tools/oneapi/dpc-compiler.html, 2023.
[7] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” https: //bitcoin.org/bitcoin.pdf, 2008. [8] S. Dziembowski, S. Faust, V. Kolmogorov, and K. Pietrzak, “Proofs of space,” pp. 585–605, 2015.