Multifunction Tree Unit (MTU) Accelerator

• MTU is a specialized hardware accelerator that performs balanced binary-tree computations for zero-knowledge proof systems using unified modular arithmetic and cryptographic hashing.
• It supports multiple operations such as Build MLE, MLE Evaluation, Multiplication and Product MLE, and Merkle Tree commitments, enhancing on-chip reuse and traversal efficiency.
• Its Hybrid traversal strategy, merging BFS and DFS techniques, delivers significant performance speedups—up to 9440× over CPU baselines—across key ZKP workloads.

The Multifunction Tree Unit (MTU) is a specialized hardware block within the zkSpeed architecture for accelerating balanced binary-tree kernels that recur across zero-knowledge proof systems, especially HyperPlonk. It is “multifunction” because the same architectural structure supports multiple node operators: modular arithmetic for SumCheck-related kernels such as Build MLE, MLE Evaluation, Multiplication Tree, and Product MLE, and cryptographic hashing for Merkle Tree commitments. The defining claim is that these prover subroutines are not arbitrary computations but balanced binary tree computations whose efficiency depends strongly on traversal order, on-chip reuse, and interface regularity, so a reusable tree accelerator can outperform both generic CPU execution and traversal-agnostic hardware designs (Mo et al., 22 Jul 2025).

1. Concept and architectural role

MTU is presented as a compact, reusable binary-tree accelerator rather than as a separate accelerator for each proving subroutine. Its central abstraction is that several expensive kernels in modern ZKPs share the same computational skeleton: every internal node is derived from two children, and the global computation is organized either as a forward expansion tree or as an inverted reduction tree. This permits one processing-element fabric, one scheduling framework, and one traversal philosophy to be reused across arithmetic trees and hash trees.

Within zkSpeed, MTU targets workloads related to SumCheck and Merkle Tree, “seen in HyperPlonk and Orion respectively.” The emphasis is therefore dual. On one hand, MTU is directly relevant to HyperPlonk because HyperPlonk relies heavily on SumCheck and requires efficient support for Build MLE, MLE Evaluation, Multiplication Tree, and Product MLE. On the other hand, the paper generalizes beyond HyperPlonk to a broader class of binary-tree kernels common across ZKPs.

The motivation is explicitly tied to two bottlenecks. On CPUs, these kernels involve either large-scale 255-bit modular arithmetic or repeated cryptographic hashing, often over data sets of size $2^{20}$ or larger. On hardware, arithmetic throughput alone is not decisive: traversal strategy governs memory traffic, parallel control, and pipeline regularity. MTU is therefore motivated by the need to balance parallelism across sibling nodes, on-chip reuse of intermediate nodes, simple control, low initiation interval, and compatibility with streamed upstream and downstream modules.

2. Binary-tree formulation of the targeted kernels

The workloads accelerated by MTU are unified by a balanced binary-tree interpretation, but their node semantics differ. For SumCheck, the paper recalls the target

$S = \sum_{x_1 \in \{0,1\} \sum_{x_2 \in \{0,1\} \cdots \sum_{x_p \in \{0,1\} f(x_1,x_2,\ldots,x_p) \tag{1}$

with $f$ multilinear in HyperPlonk. For $p=3$, the multilinear extension is written as

$$f(x_1,x_2,x_3)=f(0,0,0)(1-x_1)(1-x_2)(1-x_3) + f(0,0,1)(1-x_1)(1-x_2)x_3+ ... + f(1,1,1)x_1x_2x_3 \tag{2}$$

This lookup-table form over $\{0,1\}^p$ induces the tree-shaped computation used by MTU.

For Build MLE, the equality polynomial is

$$eq(x,r) = \prod_{i=1}^{\mu}(r_i x_i +(1-r_i)(1-x_i)) \tag{3}$$

where $x \in \{0,1\}^{\mu}$ and $r \in \mathbb{F}^{\mu}$. The task is to evaluate $eq(x,r)$ for all Boolean $S = \sum_{x_1 \in \{0,1\} \sum_{x_2 \in \{0,1\} \cdots \sum_{x_p \in \{0,1\} f(x_1,x_2,\ldots,x_p) \tag{1}$0. A naive implementation costs $S = \sum_{x_1 \in \{0,1\} \sum_{x_2 \in \{0,1\} \cdots \sum_{x_p \in \{0,1\} f(x_1,x_2,\ldots,x_p) \tag{1}$1 modular multiplications, whereas the tree formulation reduces this to

$S = \sum_{x_1 \in \{0,1\} \sum_{x_2 \in \{0,1\} \cdots \sum_{x_p \in \{0,1\} f(x_1,x_2,\ldots,x_p) \tag{1}$2

modular multiplications. Build MLE is a forward tree: computation begins from challenge-derived values near the root and expands toward many outputs. The paper further uses

$S = \sum_{x_1 \in \{0,1\} \sum_{x_2 \in \{0,1\} \cdots \sum_{x_p \in \{0,1\} f(x_1,x_2,\ldots,x_p) \tag{1}$3

to save one modular multiplication.

For MLE Evaluation, the direct expression is

$S = \sum_{x_1 \in \{0,1\} \sum_{x_2 \in \{0,1\} \cdots \sum_{x_p \in \{0,1\} f(x_1,x_2,\ldots,x_p) \tag{1}$4

which maps naturally to an inverted binary reduction tree. The combine step uses

$S = \sum_{x_1 \in \{0,1\} \sum_{x_2 \in \{0,1\} \cdots \sum_{x_p \in \{0,1\} f(x_1,x_2,\ldots,x_p) \tag{1}$5

so that two modular multiplications are replaced by one modular multiplication plus additions. The paper states that the modular multiplication count is reduced from $S = \sum_{x_1 \in \{0,1\} \sum_{x_2 \in \{0,1\} \cdots \sum_{x_p \in \{0,1\} f(x_1,x_2,\ldots,x_p) \tag{1}$6 to $S = \sum_{x_1 \in \{0,1\} \sum_{x_2 \in \{0,1\} \cdots \sum_{x_p \in \{0,1\} f(x_1,x_2,\ldots,x_p) \tag{1}$7.

Merkle Tree commitment follows the same inverted-tree structure, but with hashing as the node operator: leaves are hashes of inputs, each internal node hashes its two children, and the root is the commitment. Multiplication Tree computes products of the form $S = \sum_{x_1 \in \{0,1\} \sum_{x_2 \in \{0,1\} \cdots \sum_{x_p \in \{0,1\} f(x_1,x_2,\ldots,x_p) \tag{1}$8, reducing dependence depth through a binary tree. Product MLE is similar to a multiplication tree, but must emit all intermediate levels rather than only the root, which increases output-bandwidth pressure.

Kernel	Tree orientation	Node operator
Build MLE	Forward tree	Modular arithmetic
MLE Evaluation	Inverted tree	Modular arithmetic
Multiplication Tree / Product MLE	Inverted tree	Modular arithmetic
Merkle Tree commitment	Inverted tree	SHA3 hashing

This common binary-tree structure is the basis for MTU’s claim to multifunctionality. A plausible implication is that the architectural reuse is justified less by high-level cryptographic protocol similarity than by the regularity of the underlying parent-from-two-children computation.

3. Traversal strategies and the Hybrid traversal

A major contribution associated with MTU is the claim that traversal strategy is a first-order determinant of hardware efficiency. The paper studies BFS, DFS, and a hardware-friendly Hybrid traversal, and states that all three have time complexity $S = \sum_{x_1 \in \{0,1\} \sum_{x_2 \in \{0,1\} \cdots \sum_{x_p \in \{0,1\} f(x_1,x_2,\ldots,x_p) \tag{1}$9, while their hardware properties differ substantially (Mo et al., 22 Jul 2025).

BFS processes the tree level by level. Its reported characteristics are: $f$0, easy parallel control, initiation interval $f$1, continuous input indices, high memory cost, and bandwidth cost linear in number of PEs. This makes BFS simple and regular, but memory-hungry. The paper gives a concrete example: Build MLE of size $f$2 would require 128 MB of on-chip SRAM if all intermediate levels were retained on chip. If those levels are moved off chip, bandwidth becomes the bottleneck.

DFS recursively completes one subtree before moving to the next. Its reported characteristics are: $f$3, hard parallel control, initiation interval $f$4, discontinuous input indices, low memory cost, and fixed bandwidth cost. DFS improves on-chip reuse and reduces memory traffic, but it complicates scheduling, introduces dependency-heavy execution, and interferes with straightforward pipelining from strictly ordered upstream producers.

The proposed Hybrid traversal combines BFS at the top of the tree with DFS deeper in the tree. The design principle is rate-matching the upstream. For an inverted tree receiving eight Level-1 nodes per cycle, four PEs compute Level 2, two PEs compute Level 3, and one PE computes Level 4, so the upper levels form a streaming local BFS pipeline. Once the generation rate becomes one node per cycle, DFS takes over for deeper levels. The resulting reported properties are: $f$5, medium control, initiation interval $f$6, continuous input indices, low memory cost, and fixed bandwidth cost.

This organization is intended to preserve the simple streaming behavior of BFS at the interface while retaining DFS-style on-chip reuse in deeper levels. The paper’s central performance claim about traversal is that the Hybrid traversal outperforms a standalone approach by up to $f$7, and that for workloads other than Product MLE, DFS and Hybrid achieve nearly $f$8 speedup over BFS when enough bandwidth and compute are available. Product MLE is the exception because every intermediate level must still be emitted to memory.

4. Microarchitecture and scheduling

MTU is implemented as a set of processing elements interconnected to support both forward and inverted binary-tree dataflows. The example architecture contains 8 PEs. Each PE supports modular addition, modular multiplication, and SHA3 hashing, which is the basis of the unit’s multifunction character.

In inverted-tree mode, the example MTU accepts eight inputs per cycle. The front-end seven PEs pipeline the first three levels, reducing 8 inputs to 4, then 2, then 1. That one output per cycle feeds the final PE, designated as the DFS accumulator, which recursively computes deeper levels. In forward-tree mode, used for Build MLE, the same PE network is reused with reversed dataflow and different wiring, generating up to eight outputs per cycle. The grouped pipeline covers Levels 3 to 1, while the DFS accumulator computes Level 4 and above.

The DFS accumulator and its controller are central to MTU’s scheduling model. For the inverted tree, the schedule is governed by generation rate: if Level 4 produces one element per cycle, Level 5 produces one every two cycles, Level 6 one every four cycles, and so on. Temporary deeper-level outputs such as $f$9 are buffered in a small SRAM until their matching sibling arrives. The controller prioritizes deeper-level computations when both operands are ready. The paper states that explicit scheduling tables are provided for inverted and forward trees, using level/index notation $p=3$0, and argues that the rate-matched interleaving pattern keeps control simple enough for hardware.

The memory hierarchy combines off-chip DDR/HBM for input and output streams, on-chip SRAM for temporary deeper-level buffering, and PE-to-PE streaming connections for the grouped upper levels. A major goal is to avoid the need to store full intermediate levels off chip, which is the principal weakness of BFS. Product MLE remains bandwidth-intensive because all intermediate levels are required outputs.

The implementation assumptions reported in the paper are specific. Modular addition is treated as a short operation and is noted as 1 pipeline stage in zkSpeed; modular multiplication is described as much more expensive and is mentioned as a 10-stage pipeline in the traversal discussion; the MTU clock is 1 GHz. The design uses 255-bit datatypes matching HyperPlonk’s field setting. Montgomery multipliers are generated with Catapult HLS 2023, SHA3 is taken from the OpenCores block, and SRAM is modeled using a Synopsys 22 nm memory compiler and scaled to 7 nm.

5. Evaluation methodology and quantitative results

The performance study combines software benchmarking with hardware simulation and modeling. The CPU baseline is an Intel Xeon Gold 5218 with DDR4 memory and TDP 125 W. The software stack uses a HyperPlonk implementation, the arkworks Rust library, and Rayon for multithreading, with thread counts from 1 to 32. The MTU evaluation spans 2 to 32 PEs and bandwidth assumptions from 64 GB/s to 1024 GB/s, intended to cover DDR-class systems around 64 GB/s and HBM-class systems up to 1024 GB/s. The main plots use size $p=3$1 for Build MLE, MLE Evaluation, Product MLE, and Merkle Tree commitment workloads (Mo et al., 22 Jul 2025).

The hardware results are derived from a cycle-accurate simulator for MTU hybrid traversal and scheduler behavior, with synthesized arithmetic and instantiated hash units plus SRAM/compiler-based area models. The paper reports runtime, speedup over CPU, area, TDP, and runtime–area Pareto behavior under bandwidth sweeps.

The headline performance result is that MTU achieves up to $p=3$2 speedup over CPU at DDR-level bandwidth and up to $p=3$3 average speedup with HBM-level bandwidth. Under 64 GB/s, speedup declines as PE count rises because the accelerator becomes bandwidth-bound while CPU performance still benefits from more threads. Even so, averaged over the workloads, MTU with Hybrid traversal achieves 1478x speedup over CPU. At 1024 GB/s, average speedup rises to 9440x because PE utilization improves.

Traversal effects differ sharply between CPU and hardware. On CPU, BFS and DFS differ only modestly; DFS is typically somewhat faster by under 200 ms, attributed to lower synchronization overhead from static subtree partitioning, better cache locality, and less per-level thread scheduling overhead than BFS with Rayon’s level-wise parallel iterators. Merkle Tree scales best with thread count because SHA3 benefits from optimized CPU SHA extensions and thread-level parallelism, whereas Build MLE, MLE Eval, and Product MLE scale less well because 255-bit modular arithmetic is compute-heavy and more dependency-laden.

On MTU, traversal matters much more. At 64 GB/s and 2 PEs, DFS and Hybrid significantly outperform BFS because BFS repeatedly writes and reads levels to and from off-chip memory. At 1024 GB/s and 2 PEs, traversal differences shrink because execution becomes compute-bound rather than memory-bound. At 64 GB/s, increasing PEs gives little benefit because bandwidth saturates. At 1024 GB/s, scaling with PE count improves; BFS plateaus after 16 PEs, Product MLE also encounters limits after 16 PEs because of output bandwidth, and DFS and Hybrid scale better beyond 16 PEs for Build MLE, MLE Eval, and Merkle Tree.

6. Area, power, relevance, and related interpretations

The paper argues that MTU is compact enough to be a practical SoC or chiplet component. For a 32-PE MTU, the reported area and TDP breakdown is: Modulus Ops, $p=3$4 and $p=3$5; SHA3, $p=3$6 and $p=3$7; Misc., $p=3$8 and $p=3$9; Memory, $$f(x_1,x_2,x_3)=f(0,0,0)(1-x_1)(1-x_2)(1-x_3) + f(0,0,1)(1-x_1)(1-x_2)x_3+ ... + f(1,1,1)x_1x_2x_3 \tag{2}$$0 and $$f(x_1,x_2,x_3)=f(0,0,0)(1-x_1)(1-x_2)(1-x_3) + f(0,0,1)(1-x_1)(1-x_2)x_3+ ... + f(1,1,1)x_1x_2x_3 \tag{2}$$1; Total MTU, $$f(x_1,x_2,x_3)=f(0,0,0)(1-x_1)(1-x_2)(1-x_3) + f(0,0,1)(1-x_1)(1-x_2)x_3+ ... + f(1,1,1)x_1x_2x_3 \tag{2}$$2 and $$f(x_1,x_2,x_3)=f(0,0,0)(1-x_1)(1-x_2)(1-x_3) + f(0,0,1)(1-x_1)(1-x_2)x_3+ ... + f(1,1,1)x_1x_2x_3 \tag{2}$$3. For reference, an HBM2 PHY is listed separately at $$f(x_1,x_2,x_3)=f(0,0,0)(1-x_1)(1-x_2)(1-x_3) + f(0,0,1)(1-x_1)(1-x_2)x_3+ ... + f(1,1,1)x_1x_2x_3 \tag{2}$$4 and $$f(x_1,x_2,x_3)=f(0,0,0)(1-x_1)(1-x_2)(1-x_3) + f(0,0,1)(1-x_1)(1-x_2)x_3+ ... + f(1,1,1)x_1x_2x_3 \tag{2}$$5. The runtime–area Pareto analysis on Merkle Tree with Hybrid traversal shows that increasing bandwidth moves the Pareto front leftward, especially for larger PE counts, but below about $$f(x_1,x_2,x_3)=f(0,0,0)(1-x_1)(1-x_2)(1-x_3) + f(0,0,1)(1-x_1)(1-x_2)x_3+ ... + f(1,1,1)x_1x_2x_3 \tag{2}$$6 several bandwidth regimes overlap; the paper further states that a design just above $$f(x_1,x_2,x_3)=f(0,0,0)(1-x_1)(1-x_2)(1-x_3) + f(0,0,1)(1-x_1)(1-x_2)x_3+ ... + f(1,1,1)x_1x_2x_3 \tag{2}$$7 can achieve similar performance at 256 GB/s and 1024 GB/s.

MTU accelerates HyperPlonk by speeding up core kernels inside the prover rather than by changing the proof algorithm itself. The relation is explicit: HyperPlonk uses SumCheck, and efficient support for Build MLE, MLE Evaluation, Multiplication Tree, and Product MLE is therefore directly relevant to end-to-end proving throughput. The paper also positions MTU as a reusable building block for future SumCheck accelerators or as a polynomial commitment engine in broader ZKP hardware stacks.

The work is compared to NoCap, UniZK, and zkSpeed. NoCap accelerates Spartan+Orion and maps Merkle tree computation through level-order BFS on a vector engine, without specializing Build MLE or MLE Eval, and uses 64-bit datatypes rather than MTU’s 255-bit setting. UniZK partitions trees into subtrees but still applies BFS within each subtree, whereas MTU’s Hybrid traversal mixes BFS and DFS more tightly. zkSpeed is the broader HyperPlonk accelerator into which MTU is integrated.

A useful clarification concerns nomenclature. The phrase “Multifunction Tree Unit” in the sense discussed here is specific to the zkSpeed/HyperPlonk accelerator work. The radar paper “Multifunction Cognitive Radar Task Scheduling Using Monte Carlo Tree Search and Policy Networks” does not define a “Multifunction Tree Unit” by that name; it presents a tree-search-based scheduling framework for multifunction radar, where the closest tree-structured entity is a search-tree node representing a partial schedule rather than a hardware or proof-system accelerator (Shaghaghi et al., 2018). This distinction matters because the acronym “MTU” could otherwise be misread as a generic term for any multifunction system with a tree structure.

Taken together, the reported results suggest that the main significance of MTU lies in elevating balanced binary tree structure to a first-class hardware abstraction for ZKP acceleration. A plausible implication is that future accelerator design for HyperPlonk-like systems may benefit from treating traversal and data movement, rather than arithmetic units alone, as the dominant optimization target.