Imagine you have a secret recipe for the world's most delicious cake, but you don't have a kitchen big enough to bake it. You need to send the ingredients to a professional bakery (the "Server") to do the baking. However, you can't let the baker see your secret recipe, or they might steal it, or worse, they might change the ingredients and serve you a bad cake without you knowing.

This paper is a blueprint for how to send your secret recipe to a bakery that you don't fully trust, using different strategies depending on how much "kitchen equipment" (quantum resources) you have at home.

Here is the breakdown of their solution, using everyday analogies:

The Core Problem: The "Black Box" Kitchen

In the world of quantum computing, the "bakery" (the Server) is powerful but expensive. The "home cook" (the Client) wants to use it but needs to keep their data (the recipe) and their specific instructions (the angles of the cake layers) hidden.

The paper proposes a hierarchy of solutions. Think of it like a menu of security levels, where the level of security depends on how much equipment you have at home.

The Four Levels of Security (The Protocols)

1. The "Full Kitchen" Client (Protocol 1)

Who you are: You have a decent home kitchen with a full set of tools (an M-qubit quantum computer). You can bake small cakes yourself, but the big one needs the pro bakery.
The Strategy: You encrypt your ingredients with a "Quantum One-Time Pad" (QOTP). This is like putting your ingredients in a box that changes its lock every time you touch it.

What the Baker sees: They see a box of ingredients and instructions to mix them in a specific, public way (like "stir clockwise"). They can't see what is inside the box.
What you do: You keep the secret parts of the recipe (the non-standard spices) for yourself. When the baker finishes the public mixing, you take the box back, unlock it, add your secret spice, re-lock it, and send it back.
The Catch: The baker still knows how many ingredients you used and when you sent them, but not what they are.

2. The "Single Tool" Client (Protocol 2)

Who you are: You don't have a full kitchen. You only have a few single tools (independent single-qubit devices). You can't mix two ingredients together at home.
The Strategy: You still use the secret lockbox (QOTP), but now you have to be very careful about how you send things.

The Trick: To hide the shape of your recipe, you use "Routing Permutations." Imagine you have 5 jars of ingredients. You shuffle which jar goes to which shelf in the bakery. The baker sees jars moving, but because you shuffled them, they can't tell if you are making a cake or a pie just by looking at the order of the jars.
The Catch: You have to constantly swap jars back and forth, which takes time.

3. The "Minimalist" Client (Protocol 3)

Who you are: You have almost no tools. You can only lock and unlock boxes, but you can't even rotate the ingredients inside.
The Strategy: This is the most clever part. You can't hide the angle of a rotation (like "turn the knob 45 degrees") by doing it yourself. So, you use a "Secret Code Sharing" trick.

The Analogy: Imagine you need to tell the baker to turn a knob, but you can't say "45 degrees." Instead, you tell them to turn it "10 degrees" and "35 degrees" separately. But here's the twist: you also secretly tell the baker to turn one of them backwards (negative sign).
The Magic: The baker sees two turns: +10 and +35. But because of the secret "backwards" instruction you hold, the real math adds up to 45. The baker doesn't know which turn was the real one and which was the "backwards" one.
The Catch: This only works if the baker can't figure out which two turns belong to the same secret instruction. You hide this by shuffling the order of the turns and using "dummy" turns that look real but do nothing.

4. The "Purely Classical" Client (Protocol 4)

Who you are: You have no quantum tools at all. You are just a person with a laptop.
The Strategy: You can't lock the boxes yourself. So, you hire two competing bakeries (Server 1 and Server 2) and a neutral manager (Common Node).

The Setup: You split your secret recipe into two halves. You give half to Baker A and half to Baker B. The Manager holds the "key" to how to put them back together.
The Rule: Baker A and Baker B are not allowed to talk to each other. The Manager is trusted to shuffle the keys so that neither Baker knows the full picture.
The Catch: If Baker A, Baker B, and the Manager all decide to team up and share their notes, your secret is lost. The system relies on them not colluding.

The "Trap" Layer (Verification)

How do you know the baker didn't cheat? Maybe they didn't steal the recipe, but they just baked a burnt cake.
The authors suggest a "Trap" system.

The Analogy: Imagine you send the baker a few "dummy" ingredients that look exactly like your real ones, but you know exactly what they should turn into (e.g., "This specific egg should turn into a perfect sphere").
The Check: If the baker returns a misshapen sphere, you know they were cheating or made a mistake. Because the dummy ingredients are mixed in randomly with the real ones, the baker doesn't know which ones are the traps. They have to be honest with everything to avoid getting caught.

The "Leakage" Reality Check

The paper is very honest about what it doesn't do. It admits that while the baker can't see the ingredients (the data), they might still guess some things based on:

Timing: How long it took to bake.
Size: How many jars were used.
Structure: The general shape of the recipe (e.g., "It looks like a cake, not a soup").

The paper calls this "Leakage-Dependent Privacy." It means: "We hide the secret details, but we admit the baker might guess the general type of dish unless we add extra padding and noise to hide that too."

Summary

This paper doesn't promise a magic shield that makes you invisible to a super-powerful hacker. Instead, it offers a modular toolkit:

If you have a quantum computer: Use the "Lockbox" method.
If you have limited tools: Use the "Shuffling" and "Secret Code Sharing" methods.
If you have no tools: Use the "Two Bakeries + Manager" method.
For everyone: Add "Traps" to catch cheaters.

It's a practical guide for how to use powerful quantum computers today without giving away your secrets, acknowledging that perfect secrecy is hard, but "good enough" secrecy is achievable with the right mix of tricks.

Technical Summary: Private Delegated Quantum Computing for User-Level and Industry-Level Settings

1. Problem Statement

Access to quantum hardware remains a bottleneck for individual users and industries due to the high cost of building, operating, and maintaining quantum devices. Delegated Quantum Computation (DQC) offers a solution where a resource-constrained client delegates computations to a powerful server. However, a critical challenge is preserving the privacy of the computation's input data, output data, and the computation's description (structure and parameters).

Existing approaches, such as Measurement-Based Blind Quantum Computation (MBQC) and Circuit-Based Blind Quantum Computation (CBQC), often require the client to possess significant quantum capabilities (e.g., generating graph states or storing all qubits) or rely on specific trust models. Furthermore, standard privacy definitions often conflate different types of secrecy (state privacy vs. structural privacy) or assume universal blindness that may not be achievable with limited client resources.

This paper addresses the need for a modular hierarchy of private delegated quantum computation protocols tailored to varying client capabilities, ranging from fully capable multi-qubit devices to purely classical controllers. The work explicitly distinguishes between protecting the quantum state (via encryption) and protecting the circuit structure (via compilation and routing), while clarifying the specific leakage assumptions required for each.

2. Methodology and Framework

The authors propose a resource-based hierarchy where the protocol choice depends on the client's quantum capabilities ( $M$ qubits) and the nature of the operations (Clifford vs. non-Clifford). The framework relies on several core techniques:

2.1 Core Privacy Mechanisms

Quantum One-Time Pad (QOTP): The foundation for state privacy. The client encrypts qubits with random Pauli $X$ and $Z$ keys. Under the purified semi-honest model, if keys are fresh, secret, and uniform, the server's reduced density matrix is maximally mixed, revealing no information about the state.
Clifford Key Updates: Public Clifford operations (H, S, CNOT, CZ) can be performed by the server on encrypted data. The client updates the Pauli frame classically without decrypting the data.
Non-Clifford Handling: The base protocols restrict the server to Clifford operations. Non-Clifford gates (e.g., $T$ $T$ , generic rotations) are handled via:
- Local Execution: The client decrypts, applies the gate, re-encrypts, and returns the qubit (for clients with local capability).
- Decomposition: Breaking non-Clifford gates into public Clifford layers and local single-qubit gates.
- Angle-Ambiguity Primitives: For restricted clients, private rotation angles are hidden using finite-grid sharing and sign randomization.

2.2 Structural Privacy and Leakage

The paper introduces a rigorous leakage-relative privacy definition. Privacy is not absolute but relative to a declared leakage function $L(D)$ .

Structural Privacy: Hiding the circuit layout, gate positions, and routing. This is achieved through randomized compilers, padding with dummy/canceling gates, and routing permutations.
Transcript-Level Ambiguity: For restricted clients, the paper defines "angle ambiguity" rather than universal blindness. By using finite-grid routing-hidden sign-randomized $r$ -share sharing, the server sees valid rotation shares but cannot uniquely determine the logical angle due to hidden signs (induced by QOTP keys) and hidden grouping (induced by routing permutations).

2.3 The Protocol Hierarchy

The paper defines four distinct protocol branches based on client resources:

Protocol 1 (Fully Capable $M$ -qubit Client):
- Capabilities: Can store $M$ qubits and perform local multi-qubit gates.
- Mechanism: The client sends batches of $M$ qubits to the server. The server performs public Clifford operations on encrypted data. Private/non-Clifford gates are executed locally by the client (decrypt-apply-reencrypt) if the arity $\le M$ .
- Privacy: QOTP state privacy; structural privacy depends on the compiler.
Protocol 2 (Client with $M$ Independent Single-Qubit Devices):
- Capabilities: $M$ independent devices; no local entangling gates.
- Mechanism: Similar to Protocol 1 but restricted to local single-qubit gates. Multi-qubit operations are delegated as public Clifford layers. Structural hiding is achieved via port randomization (routing permutations) between devices to hide logical wire mappings.
- Privacy: QOTP state privacy; structural privacy relies on routing permutations and padding.
Protocol 3 (Restricted Single-Qubit Devices):
- Capabilities: Devices limited to Pauli $X, Z$ (QOTP masks) and routing control; cannot perform arbitrary rotations.
- Mechanism: Uses a finite-grid routing-hidden sign-randomized $r$ -share angle-ambiguity primitive. Private rotation angles are compiled to a finite grid, split into $r$ shares with hidden signs (via QOTP $X$ keys) and hidden grouping (via routing).
- Privacy: QOTP state privacy; transcript-level angle ambiguity (not universal blindness) under hidden-sign and hidden-routing assumptions.
Protocol 4 (Classical Client):
- Capabilities: Purely classical; no direct quantum interaction.
- Mechanism: Uses two computational servers ( $S_1, S_2$ ) and a common node ( $R$ ). The client maintains a persistent matching-hidden split-QOTP. The common node hides the matching between key shares held by $S_1$ and $S_2$ .
- Privacy: State privacy under persistent split-QOTP plus $\epsilon_{key}$ -key hiding (assuming non-total-collusion). Angle privacy is transcript-level unlinkability via shuffled $r$ -share sharing.
- Assumption: The full coalition $\{S_1, S_2, R\}$ is excluded; the common node is trusted or side-channel controlled.

2.4 Trap-Based Detection Layer

To address malicious deviations (where the server does not follow the protocol), the paper proposes an embedded statistical detection layer.

Method: The client compiles "verifier blocks" (with known answers or simulable outputs) and mixes them with data blocks using private relabeling and routing.
Guarantee: Under indistinguishability assumptions, the server cannot target only data blocks. Detection probability depends on the density of verifier slots and the soundness of the verifier mode (known-answer, simulable, or echo).
Limitation: This is a statistical detection layer, not a full malicious-security proof or authentication mechanism.

3. Key Contributions

Resource-Indexed Protocol Hierarchy: A structured set of protocols (Protocols 1–4) that map specific client capabilities (from $M$ -qubit to classical) to appropriate privacy mechanisms, avoiding a "one-size-fits-all" approach.
Leakage-Relative Privacy Definitions: A formal framework separating QOTP state privacy (information-theoretic) from structural privacy (compiler-dependent) and angle ambiguity (transcript-dependent). The paper clarifies that "blindness" is often a function of declared leakage and compiler randomness, not an inherent property of the encryption alone.
Routing-Hidden Sign-Randomized Primitive: A novel technique for restricted clients to hide private rotation angles using finite-grid sharing, hidden signs (via QOTP), and routing permutations, providing transcript-level ambiguity without requiring full quantum state blindness.
Split-QOTP for Classical Clients: A multi-party protocol (Protocol 4) enabling classical clients to achieve state privacy via a split-key model across non-colluding servers, replacing client-side QOTP with a persistent matching-hidden invariant.
Explicit Security Scope: The paper explicitly delineates what each protocol does not claim (e.g., no universal blindness for Protocol 3, no malicious security for the base protocols, no unconditional structural hiding without compiler assumptions).

4. Results and Examples

The paper demonstrates the applicability of these protocols through three algorithmic examples:

Grover's Algorithm: Shows how to delegate the oracle (structural privacy) and diffusion operator. Private structure is hidden via padding and routing; non-Clifford components (CCZ) are handled locally or via decomposition.
QAOA (Quantum Approximate Optimization Algorithm): Illustrates the separation of private parameters (angles in $RZ$ and $RZZ$) from public structure. The $RZZ$ entangling part is delegated as public Clifford, while private angles are handled locally or via the angle-ambiguity primitive. The paper highlights the need to pad optimizer transcripts to prevent leakage of convergence properties.
Quantum Neural Networks (QNN): Demonstrates hiding input encoding angles and model weights. Private rotations are executed locally or via the sign-randomized primitive, while entangling gates are delegated.

Security Analysis:
The paper provides formal proofs for:

State Privacy: Under the purified semi-honest model with fresh QOTP keys (Theorem 1).
Angle Ambiguity: Bounds on the size of the candidate set for private angles given hidden signs and grouping (Proposition 5.1, 5.4).
Detection Probability: Hypergeometric bounds for the probability of detecting malicious deviations based on verifier density (Proposition 6.2, 6.3).

5. Significance and Claims

The authors position this work not as a replacement for Universal Blind Quantum Computation (UBQC) or Verifiable Blind Quantum Computation (VBQC) in their strongest regimes, but as a modular, resource-indexed framework for practical settings where clients have partial or no quantum capabilities.

Modesty of Claims: The paper explicitly states that it does not provide universal blindness or malicious security by itself.
- Protocol 3 offers "transcript-level angle ambiguity," not universal blindness.
- Protocol 4 relies on the non-total-collusion assumption and side-channel control; it does not offer malicious security without additional verification layers.
- Structural Privacy is conditional on the randomized compiler and declared leakage; it is not an unconditional guarantee against all side channels.
Practicality: The hierarchy allows industries and users to select a protocol that matches their specific hardware constraints (e.g., a company with a small quantum processor vs. a user with only a classical computer) while understanding the precise trade-offs in privacy and overhead.
Future Directions: The authors note that future work could focus on reducing qubit transmission overhead and strengthening non-Clifford and detection components for fault-tolerant settings.

In summary, the paper provides a rigorous, nuanced taxonomy of private delegated quantum computing, clarifying the exact conditions under which privacy can be achieved for clients with varying levels of quantum resources, while explicitly bounding the limitations of each approach.

Private Delegated Quantum Computing for User-Level and Industry-Level Settings