EinHops: Minimalist FHE Tensor System

• EinHops is a minimalist FHE tensor system that leverages einsum notation to explicitly map tensor algebra into encrypted operations over RNS-CKKS ciphertexts.
• It supports a fixed repertoire of homomorphic operations including SIMD addition/multiplication, cyclic rotations, and BSGS-based linear transforms for tensor contractions and permutations.
• By keeping packing decisions explicit, EinHops enhances slot-level reasoning, debugging, and prototyping in homomorphic encrypted tensor computation.

Searching arXiv for the EinHops paper and closely related FHE tensor-systems context. EinHops is a minimalist fully homomorphic encryption (FHE) tensor system that treats Einstein summation notation as both the programming interface and the execution plan for encrypted tensor computation over RNS-CKKS ciphertexts. It is designed around a fixed repertoire of homomorphic operations—SIMD addition, SIMD multiplication, cyclic rotation of 1-D vectors, linear transformations used as permutations, masking, and rotate-and-add broadcast and reduction—while keeping the packing strategy fully explicit rather than hiding it behind graph IRs and compiler passes. In the formulation introduced in "EinHops: Einsum Notation for Expressive Homomorphic Operations on RNS-CKKS Tensors," the system is simple, general, and interpretable, and it is evaluated on workloads ranging from transpose and reductions to matrix multiplication, batched matmul, high-dimensional tensor contraction, and attention-style contractions (Garimella et al., 10 Jul 2025).

1. Problem setting and design objective

EinHops addresses a standard limitation of CKKS-style tensor computation under FHE: RNS-CKKS encrypts 1-D vectors of complex values, and the primitive encrypted operations are SIMD addition, SIMD multiplication, and cyclic rotation of slots. Multi-dimensional tensors must therefore be flattened into 1-D slot vectors, and tensor operations must be mapped onto that one-dimensional layout rather than their conventional nested structure (Garimella et al., 10 Jul 2025).

The design target is not merely encrypted linear algebra, but a transparent tensor system in which packing decisions remain visible. Prior FHE compilers and tensor systems such as CHET, Fhelipe, Orion, and HECO are described as automating layout decisions and low-level FHE details, often through graph IRs and optimizers. That supports end-to-end performance, but it also makes packing and slot-level reasoning opaque. EinHops instead asks whether a tensor system can remain simple and explicit, support many einsum patterns, and remain reasonably efficient without heavy compiler machinery (Garimella et al., 10 Jul 2025).

The central premise is that einsum notation already encodes the dimensional structure needed for packing and manipulation. Shared indices identify contraction dimensions, operand-local indices determine required broadcasts, and the output equation fixes output ordering. A plausible implication is that the syntax of tensor algebra can directly serve as a low-level planning formalism for homomorphic execution, rather than being compiled away into a separate hidden representation.

2. RNS-CKKS model and the role of einsum notation

In the computational model assumed by EinHops, one chooses a polynomial degree $N$, typically a power of two such as $2^{15}$, giving $N/2$ complex slots. A cleartext is therefore a length-$N/2$ vector of complex values, encoded into the ring

$\mathcal{R}_Q = \mathbb{Z}_Q[X]/(X^N+1).$

Encryption produces a ciphertext over this ring, and the effective tensor primitive set is

$$\texttt{ct1 + ct2}, \qquad \texttt{ct1 * ct2}, \qquad \texttt{rotate(ct, k)},$$

corresponding approximately to elementwise addition, elementwise multiplication, and cyclic slot rotation of the underlying packed vectors. Noise and scale are handled through RNS and rescaling, and EinHops relies on an existing backend, Liberate.FHE via desilo-fhe, for these mechanisms (Garimella et al., 10 Jul 2025).

Einsum notation supplies the structural metadata required for homomorphic tensor planning. For example, "ij,jk->ik" specifies that $j$ is contracted and that $i,k$ define the output; "ij->ji" specifies a pure permutation; "bthd,bThd->bhtT" specifies an attention-score contraction over $d$. EinHops uses these labels to infer the full participating index set, distinguish contraction indices from output indices, and decide how ciphertext slots must be aligned before multiplication and reduction (Garimella et al., 10 Jul 2025).

The paper’s interpretation of einsum is operational rather than merely syntactic. Einsum is used as both the user interface and the internal plan. This distinguishes EinHops from systems in which tensor syntax is translated into a larger graph optimization problem whose packing strategy may not remain legible at the slot level.

3. Packing model and algorithmic decomposition

EinHops assumes that the entire logical tensor for a given einsum side fits into a single ciphertext, that every logical dimension is padded to the next power-of-two size, and that flattening follows a row-major-like convention in which inner dimensions vary fast and outer dimensions vary slow. For a tensor with dimensions

$(d_0,d_1,\dots,d_{k-1}),$

the slot index is

$2^{15}$0

with

$2^{15}$1

This mapping is fully explicit and derived directly from the einsum labels and the internal ordering rule (Garimella et al., 10 Jul 2025).

The internal ordering rule is canonical: all contraction indices are placed first, as the outermost dimensions, and output indices are placed afterward, as innermost dimensions, in the order required by the einsum output equation. The paper identifies two immediate consequences. First, reductions over contraction indices can be implemented so that outputs end up in contiguous slots at the top of the ciphertext, eliminating a final permutation. Second, the stride associated with each symbolic dimension is fixed and directly traceable from the equation (Garimella et al., 10 Jul 2025).

Operationally, any einsum is decomposed into three stages. The first stage matches dimensions by expanding operands with singleton dimensions and broadcasting them to a common full shape over all participating indices. The second stage performs elementwise multiplication once the broadcasted operands are aligned. The third stage reduces over any index that appears on the left-hand side of the equation but not on the right-hand side (Garimella et al., 10 Jul 2025).

The primitive homomorphic operations used in these stages are fixed:

Primitive	Function in EinHops	Realization
SIMD add / mul	Pointwise tensor algebra	Ciphertext addition and multiplication
Cyclic rotation	Broadcast and reduction patterns	Slot rotations
Linear transform	Permutations and slot rearrangements	BSGS matrix–vector products
Masking	Zeroing padded or unused slots	Binary plaintext multiplication

Permutations are implemented through Baby-Step Giant-Step (BSGS) linear transformations. For a linear map

$2^{15}$2

the matrix is diagonalized by rotation offsets, each diagonal is encoded as a plaintext, and rotated ciphertexts are multiplied by those plaintext diagonals and accumulated. Naively this requires $2^{15}$3 rotations for an $2^{15}$4 transform; BSGS reduces this to $2^{15}$5. In EinHops, these transforms are specialized to permutation matrices for transpose, inner-dimension expansion, and other slot-space rearrangements (Garimella et al., 10 Jul 2025).

Broadcast and reduction are both implemented as log-depth rotate-and-add patterns because dimensions are padded to powers of two. For a dimension of size $2^{15}$6, the steps use rotations by $2^{15}$7 for $2^{15}$8, giving $2^{15}$9 rotations and additions for either duplication or accumulation (Garimella et al., 10 Jul 2025).

4. Supported operations and execution semantics

EinHops is presented as supporting any einsum that fits in one ciphertext. The paper explicitly lists transpose and permutation operations such as "ij->ji" and "pqrs->psqr"; elementwise products such as "ij,ij->ij" and "ij,ij,ij->ij"; reductions such as "ij->", "ij->i", "ij->j", and "pqrs->ps"; matrix operations such as "ik,k->i", "ik,kj->ij", "i,i->", and "i,j->ij"; batch operations such as "ijk,ikl->ijl" and "bij,bjk->bik"; and high-dimensional contractions such as "pqrs, tuqvr->pstuv" and attention-style patterns such as "bthd,bThd->bhtT" (Garimella et al., 10 Jul 2025).

The paper’s matrix-multiplication example makes the execution model concrete. For "ij,jk->ik", the operands are parsed into the index sets $N/2$0 and $N/2$1, the contraction index is $N/2$2, and the canonical internal order is "jik". After padding, each operand is permuted or expanded to "jik", singleton dimensions are broadcast by rotate-and-add, the aligned tensors are multiplied pointwise, and reduction over $N/2$3 is performed by rotate-and-add with stride $N/2$4. The top $N/2$5 slots then contain the result, after which masking removes padded or unused positions (Garimella et al., 10 Jul 2025).

The same semantics extend to attention-score computation. For $$\texttt{ct1 + ct2}, \qquad \texttt{ct1 * ct2}, \qquad \texttt{rotate(ct, k)},$$1 the full index set is $N/2$6, the contraction index is $N/2$7, the output indices are $N/2$8, and the internal order is "dbhtT". Each operand is expanded to that order, broadcast across its missing axis, multiplied, reduced over $N/2$9, and masked (Garimella et al., 10 Jul 2025).

The paper states that the expressiveness argument is semantic rather than theorem-driven. It does not present formal lemmas; instead, the core correctness argument is that einsum semantics are exactly: broadcast all inputs to a common full shape, multiply elementwise, and sum over contracted indices. Under the assumptions that padded dimensions fit in one ciphertext and that dimensions are padded to powers of two, EinHops implements those three steps directly (Garimella et al., 10 Jul 2025).

5. Implementation and empirical profile

EinHops is implemented in approximately 1,000 lines of pure Python. The front-end exposes einhops.einsum(equation, *operands) with operands supplied as PyTorch tensors or FHE ciphertexts, and it uses opt_einsum to parse and validate equations. The middle-end determines contraction and output indices, fixes the internal ordering, computes padding to powers of two, and plans required permutations, broadcasts, and reductions. The back-end uses Liberate.FHE via desilo-fhe for homomorphic execution, while a cleartext 1-D PyTorch backend simulates slot-level operations with torch.add, torch.mul, and torch.roll for debugging (Garimella et al., 10 Jul 2025).

BSGS is implemented at the Python level because the backend exposes opaque ciphertext objects with add, mul, and rotate. The implementation supports two rotation-key configurations. The first uses only power-of-two rotation keys, roughly 14 keys, about 3 GB of memory, and arbitrary rotations formed by chaining power-of-two rotations. The second adds all BSGS keys, using 14 plus 256 keys in the experiments, about 32 GB of memory, single-step arbitrary rotations, and more effective hoisting (Garimella et al., 10 Jul 2025).

The experimental setup uses an Intel Xeon Platinum 8480+ with 13 cores and 26 threads, an NVIDIA H100 PCIe GPU with 80 GB, and the desilo-fhe medium engine with polynomial degree $N/2$0, giving 16,384 slots. Level 3 is used for most operations and level 4 for deeper ones. All inputs are encrypted, each experiment is averaged over 10 runs, and the difference to plaintext PyTorch is around $N/2$1 in $N/2$2 norm (Garimella et al., 10 Jul 2025).

Representative measurements illustrate the computational profile:

Operation	CPU	GPU
Matrix transpose, ij->ji, (128,128)	60.55 s $N/2$3 19.58 s	11.52 s $N/2$4 5.91 s
Matrix × vector, ik,k->i, (128,128),(128)	124.41 s $N/2$5 34.84 s	17.69 s $N/2$6 11.58 s
Matrix × matrix, ik,kj->ij, (16,32),(32,32)	27.16 s $N/2$7 10.17 s	5.91 s $N/2$8 4.97 s
Bilinear transform, ik,jkl,il->ij	167.89 s $N/2$9 69.16 s	29.2 s $\mathcal{R}_Q = \mathbb{Z}_Q[X]/(X^N+1).$0 27.07 s
Tensor contraction, pqrs,tuqvr->pstuv	104.28 s $\mathcal{R}_Q = \mathbb{Z}_Q[X]/(X^N+1).$1 28.13 s	16.12 s $\mathcal{R}_Q = \mathbb{Z}_Q[X]/(X^N+1).$2 12.04 s

Here each arrow denotes the transition from power-of-two rotation keys only to the configuration with additional BSGS keys. The paper further reports that GPU execution is generally about $\mathcal{R}_Q = \mathbb{Z}_Q[X]/(X^N+1).$3 faster than CPU in the power-of-two-key setting, and that adding BSGS keys often reduces runtime by another $\mathcal{R}_Q = \mathbb{Z}_Q[X]/(X^N+1).$4–$\mathcal{R}_Q = \mathbb{Z}_Q[X]/(X^N+1).$5, at the cost of roughly $\mathcal{R}_Q = \mathbb{Z}_Q[X]/(X^N+1).$6 more memory for rotation keys (Garimella et al., 10 Jul 2025).

The attention case study, using "bthd,bThd->bhtT" with $\mathcal{R}_Q = \mathbb{Z}_Q[X]/(X^N+1).$7, $\mathcal{R}_Q = \mathbb{Z}_Q[X]/(X^N+1).$8, $\mathcal{R}_Q = \mathbb{Z}_Q[X]/(X^N+1).$9, and $$\texttt{ct1 + ct2}, \qquad \texttt{ct1 * ct2}, \qquad \texttt{rotate(ct, k)},$$0, runs in about 28.57 s, with about 23 s spent aligning data through BSGS permutation operations. This isolates slot alignment and permutation as the dominant cost for generalized tensor contractions in the presented regime (Garimella et al., 10 Jul 2025).

6. Relation to prior FHE systems, limitations, and scope

EinHops is positioned against prior FHE tensor systems and compilers including CHET, EVA, HECO, Porcupine, Hecate, DaCapo, Orion, Fhelipe, HeLayers, and TenSEAL. Those systems are described as providing high-level tensor or graph interfaces while compiling to optimized circuits or IRs that handle parameter selection, data layout, bootstrapping placement, noise and scale management, and operator fusion. EinHops differs by using einsum itself as both interface and IR, by fixing the mapping from indices to slot strides through the rule “contractions outer, outputs inner,” by restricting itself to a minimal fixed repertoire of permutations, broadcasts, reductions, masking, and SIMD pointwise operations, and by executing eagerly rather than through a global graph optimizer (Garimella et al., 10 Jul 2025).

This explicitness also underwrites one of the system’s distinctive debugging mechanisms. Because the abstraction is effectively “einsum over 1-D vectors with roll/add/mul,” the cleartext backend allows exact inspection of slot contents at intermediate stages. A plausible implication is that EinHops is especially suited to slot-level reasoning, prototyping, and pedagogy in settings where opaque compiler transformations would obstruct diagnosis of packing or rotation costs.

The system’s limitations are stated directly. It is single-ciphertext only, so the product of all padded dimensions must fit within one ciphertext; it does not perform bootstrapping or explicit depth management; it uses BSGS-based matrix transforms for permutations, which are efficient but heavy on rotation keys; it runs only in eager mode, without JIT or global optimization across multiple einsum calls; and it does not automate parameter selection or systematic error analysis beyond backend defaults (Garimella et al., 10 Jul 2025).

The future directions named in the paper are multi-ciphertext tensors, semantics for rotate and broadcast across multiple ciphertexts, alternative permutation schemes such as shift networks or VVE circuits, integration of bootstrapping and depth control, better packing heuristics and FHE-aware contraction-order selection, and integration with machine-learning frameworks such as PyTorch and JAX (Garimella et al., 10 Jul 2025). Taken together, these constraints and prospects indicate that EinHops is not presented as a full production compiler for deep encrypted models. Rather, it is a deliberately transparent system showing how far einsum semantics can be carried directly into homomorphic tensor execution while making the underlying packing strategy and bottlenecks legible.