The Obelisk

Understanding Quantum Execution Results

This guide explains every field in the quantum job execution results, helping you understand what each measurement means and how quantum computations are verified on real physical hardware.

Overview

When The Obelisk generates quantum randomness for NFT minting, it executes a quantum circuit on real IBM Quantum hardware. Each execution produces a detailed "quantum proof" that contains all the information needed to verify that the computation actually ran on physical qubits.

This proof is stored both on-chain (in the NFT contract) and off-chain (in our database), providing complete transparency and verifiability of the quantum randomness used.

Job Identification

Job ID

Type: String (e.g., d5pi81or0v5s739o1c8g)

A unique identifier assigned by IBM Quantum Platform to each job execution. This ID can be used to retrieve the complete job details programmatically using the Qiskit Runtime API. This is the primary way to verify that a quantum computation actually occurred.

Why it matters: The job ID is immutable proof that your NFT's quantum seed came from a real quantum computation. Anyone can verify this by retrieving the job from IBM Quantum Platform.

Job Status

Type: String (e.g., DONE, RUNNING, QUEUED)

The current status of the quantum job. DONE means the computation completed successfully and results are available.

Creation Date & Completion Date

Type: ISO 8601 timestamp

When the job was submitted to IBM Quantum and when it finished executing. The difference between these times includes both queue time (waiting for hardware availability) and execution time (actual quantum computation).

Quantum Hardware Information

Backend Name

Type: String (e.g., ibm_torino, ibm_fez)

The specific IBM Quantum processor that executed your quantum circuit. Each backend is a real physical quantum computer with unique characteristics:

  • ibm_torino: Heron v1 processor with 133 qubits
  • ibm_fez: Heron v2 processor with 156 qubits

Why it matters: Different processors have different qubit counts, error rates, and connectivity. Knowing which backend was used helps verify the computation's authenticity.

Backend Type

Type: String (always physical for our use case)

Confirms that the computation ran on real physical qubits, not a simulator. This is critical for proving genuine quantum randomness.

Processor Type

Type: Object with family and revision

Details about the quantum processor architecture:

  • Family: Processor family (e.g., "Heron")
  • Revision: Version number (e.g., "1" or "2")

Total Qubits

Type: Integer (e.g., 133, 156)

The total number of qubits available on the quantum processor. This is the full capacity of the hardware, not all of which are used in a single computation.

Qubits Used

Type: Array of integers (e.g., [43, 65])

The specific physical qubits that were used in your quantum circuit. Each qubit has a unique index on the processor. For example, [43, 65] means qubits numbered 43 and 65 on the processor were used.

Why it matters: This proves which specific physical qubits were involved in generating your NFT's quantum seed. Each qubit has unique properties (T1, T2, error rates) that can be verified.

Quantum Circuit Information

Circuit Depth

Type: Integer (e.g., 4)

The number of layers of quantum gates in the circuit. Each layer represents gates that can be executed in parallel. A depth of 4 means the circuit has 4 sequential layers of operations.

Why it matters: Circuit depth affects execution time and error rates. Deeper circuits are more susceptible to quantum decoherence (loss of quantum state).

Circuit Size

Type: Integer (e.g., 8)

The total number of quantum gates in the circuit. This includes all operations: rotations, measurements, barriers, etc.

Shots

Type: Integer (e.g., 50, 100)

The number of times the quantum circuit was executed. Each "shot" is a complete run of the circuit from start to finish, producing one measurement result. Multiple shots are needed because quantum measurements are probabilistic—you need many samples to understand the probability distribution.

Example: With 50 shots, the circuit runs 50 times, producing 50 measurement results. These results are then aggregated to show the probability distribution.

Gate Counts

Type: Object mapping gate names to counts (e.g., {"rz": 4, "sx": 2, "measure": 2})

A breakdown of how many of each type of quantum gate was used in the circuit:

  • rz: Rotation around the Z-axis (phase rotation)
  • sx: Square root of X gate (creates superposition)
  • measure: Measurement operation (collapses quantum state to classical bit)
  • barrier: Synchronization point (ensures gates complete before next layer)

Circuit QASM

What is QASM?

Type: String (OpenQASM 2.0 code)

QASM (Quantum Assembly Language) is a human-readable representation of the quantum circuit. It's like assembly code for quantum computers—a low-level description of exactly what operations were performed.

Example QASM Breakdown

OPENQASM 2.0;
include "qelib1.inc";
qreg q[133];
creg c[2];
creg meas[2];
rz(pi/2) q[43];
sx q[43];
rz(pi/2) q[43];
rz(pi/2) q[65];
sx q[65];
rz(pi/2) q[65];
barrier q[43],q[65];
measure q[43] -> meas[0];
measure q[65] -> meas[1];

Let's break this down line by line:

  • OPENQASM 2.0; - Specifies the QASM version
  • include "qelib1.inc"; - Includes standard quantum gate library
  • qreg q[133]; - Declares a quantum register with 133 qubits (the full processor)
  • creg c[2]; - Declares a classical register for storing results
  • creg meas[2]; - Declares a measurement register
  • rz(pi/2) q[43]; - Rotates qubit 43 by π/2 around Z-axis (phase rotation)
  • sx q[43]; - Applies square root of X gate to qubit 43 (creates superposition)
  • rz(pi/2) q[43]; - Another phase rotation on qubit 43
  • rz(pi/2) q[65]; sx q[65]; rz(pi/2) q[65]; - Same operations on qubit 65
  • barrier q[43],q[65]; - Ensures both qubits complete previous operations before measurement
  • measure q[43] -> meas[0]; - Measures qubit 43, stores result in meas[0]
  • measure q[65] -> meas[1]; - Measures qubit 65, stores result in meas[1]

Why it matters: The QASM code is a complete, verifiable description of the quantum circuit. Anyone can take this QASM and run it themselves (on a simulator or real hardware) to verify the results.

Execution Metrics

Execution Time

Type: Float (seconds, e.g., 1.022107759)

The actual time spent executing the quantum circuit on the hardware. This includes:

  • Time to initialize qubits
  • Time to apply all quantum gates
  • Time to perform measurements
  • Time to read out results

This is typically very fast (1-2 seconds) because quantum gates operate at the speed of light, but it includes all the overhead of controlling the quantum hardware.

Queue Time

Type: Float (seconds, e.g., 0)

How long the job waited in the queue before execution began. This depends on:

  • How many other jobs are running
  • Hardware availability
  • Your account's priority level

A queue time of 0 means the hardware was immediately available when your job was submitted.

Measurement Results

What are Measurement Results?

Type: Object mapping bitstrings to counts (e.g., {"00": 12, "01": 18, "10": 14, "11": 6})

When you measure a quantum state, it "collapses" to a classical bitstring. The measurement results show how many times each possible bitstring was observed across all shots.

Understanding the Bitstrings

For a 2-qubit circuit, there are 4 possible outcomes:

  • "00" - Both qubits measured as 0
  • "01" - First qubit 0, second qubit 1
  • "10" - First qubit 1, second qubit 0
  • "11" - Both qubits measured as 1

For a 3-qubit circuit, there are 8 possible outcomes ("000" through "111").

Example Interpretation

If you see {"00": 12, "01": 18, "10": 14, "11": 6} with 50 shots:

  • "00" appeared 12 times (24% probability)
  • "01" appeared 18 times (36% probability) ← Most likely
  • "10" appeared 14 times (28% probability)
  • "11" appeared 6 times (12% probability)

Why it matters: This distribution represents the true quantum randomness. The probabilities come from the quantum state's wavefunction, which is fundamentally probabilistic. This is where the genuine quantum randomness for your NFT seed comes from.

Random Value

What is the Random Value?

Type: Float between 0 and 1 (e.g., 0.333333)

A normalized value derived from the measurement results. It's calculated by:

  1. Randomly selecting one bitstring from the measurement distribution (weighted by frequency)
  2. Converting the bitstring to decimal (e.g., "01" = 1)
  3. Dividing by the maximum possible value (for 2 qubits: 2² - 1 = 3)

Example Calculation

With measurements {"00": 12, "01": 18, "10": 14, "11": 6}:

  • If "00" is selected: 0 / 3 = 0.000000
  • If "01" is selected: 1 / 3 = 0.333333
  • If "10" is selected: 2 / 3 = 0.666667
  • If "11" is selected: 3 / 3 = 1.000000

Important Note: The random value is a convenience metric. The TRUE quantum randomness is in the full measurement_results distribution. The random value can change between API calls because it randomly selects from the distribution each time.

Verifying Quantum Proof

Programmatic Verification

You can verify any quantum job using the Qiskit Runtime API:

from qiskit_ibm_runtime import QiskitRuntimeService

service = QiskitRuntimeService()
job = service.job('YOUR_JOB_ID')
result = job.result()

What to Verify

  • Job exists: The job ID should be retrievable from IBM Quantum Platform
  • Backend matches: The backend name should match a real IBM Quantum processor
  • Status is DONE: The job should have completed successfully
  • Results match: The measurement results should match what's stored in the NFT
  • QASM is valid: The QASM code should be syntactically correct and runnable

Why This Matters

Every NFT minted by The Obelisk includes a complete quantum proof that can be independently verified. This proves that:

  • The quantum seed came from real physical qubits, not a simulator
  • The computation actually happened on IBM Quantum hardware
  • The randomness is genuine quantum randomness, not pseudo-random
  • The entire process is transparent and auditable

Summary

Understanding quantum execution results helps you appreciate the genuine quantum randomness embedded in your NFT. Each field provides a piece of the puzzle that proves your NFT's quantum seed came from real physical qubits executing a real quantum circuit.

The most important fields for verification are:

  • Job ID: Unique identifier for retrieving the job
  • Backend Name: Which real quantum processor was used
  • Measurement Results: The actual quantum randomness distribution
  • Circuit QASM: Complete description of the quantum circuit
  • Qubits Used: Which specific physical qubits were involved