Transición de fase de Nishimori
Estimación de uso: 3 minutos en un procesador Heron r2 (NOTA: Esto es solo una estimación. Tu tiempo de ejecución puede variar.)
Resultados de aprendizaje
Tras completar este tutorial, los usuarios deberían esperar los siguientes resultados:
- Comprender la transición de fase de Nishimori y cómo se manifiesta como la aparición de entrelazamiento de largo alcance en el modelo de Ising con enlaces aleatorios.
- Implementar el protocolo de generación de entrelazamiento por medición (GEM) en hardware cuántico utilizando mediciones a mitad de circuito y circuitos de profundidad constante.
- Caracterizar la transición extrayendo la correlación de dos puntos y la varianza normalizada de la magnetización a partir de datos experimentales.
Prerrequisitos
Recomendamos estar familiarizado con los siguientes temas antes de comenzar este tutorial:
- La guía Medir qubits, en particular la sección sobre mediciones a mitad de circuito en las que se basa el protocolo GEM.
- Simulación exacta y ruidosa con primitivas de Qiskit Aer, que es cómo se ejecuta la sección a pequeña escala.
- Entrelazamiento de largo alcance con circuitos dinámicos, un tutorial complementario que utiliza el mismo paradigma de entrelazamiento basado en mediciones.
- Red heavy-hex, la topología de hardware de IBM® sobre la que se construye la red de plaquetas.
Contexto
Este tutorial demuestra cómo realizar una transición de fase de Nishimori en un procesador cuántico. Este experimento fue descrito originalmente en Realizing the Nishimori transition across the error threshold for constant-depth quantum circuits.
La transición de fase de Nishimori se refiere a la transición entre fases con orden de corto y largo alcance en el modelo de Ising con enlaces aleatorios. En una computadora cuántica, la fase con orden de largo alcance se manifiesta como un estado en el que los qubits están entrelazados a lo largo de todo el dispositivo. Este estado altamente entrelazado se prepara utilizando el protocolo de generación de entrelazamiento por medición (GEM). Mediante el uso de mediciones a mitad de circuito, el protocolo GEM es capaz de entrelazar qubits a lo largo de todo el dispositivo utilizando circuitos de profundidad constante. Este tutorial utiliza la implementación del protocolo GEM del paquete de software GEM Suite.
Requisitos
Antes de comenzar este tutorial, asegúrate de tener instalado lo siguiente:
- Qiskit SDK v1.0 o posterior, con soporte de visualización
- Qiskit Runtime v0.22 o posterior (
pip install qiskit-ibm-runtime) - Qiskit Aer v0.14 o posterior (
pip install qiskit-aer) - GEM Suite (
pip install gem-suite)
Configuración
# Added by doQumentation — required packages for this notebook
!pip install -q gem-suite matplotlib qiskit qiskit-aer qiskit-ibm-runtime
import matplotlib.pyplot as plt
import warnings
from collections import defaultdict
from qiskit_ibm_runtime import QiskitRuntimeService
from qiskit_aer import AerSimulator
from qiskit.transpiler import generate_preset_pass_manager
from gem_suite import PlaquetteLattice
from gem_suite.experiments import GemExperiment
Ejemplo con simulador a pequeña escala
En esta sección se recorre el flujo de trabajo completo sobre el AerSimulator sin ruido. La red de plaquetas se restringe a una sola plaqueta (12 qubits) para que la simulación sea pequeña y rápida, mientras se ejercitan todas las partes del protocolo GEM: medición a mitad de circuito, el barrido de ángulos , la decodificación y el análisis de varianza normalizada. El mismo flujo de trabajo se escala posteriormente a múltiples plaquetas y a la red completa en hardware real.
Paso 1: Mapear entradas clásicas a un problema cuántico
El protocolo GEM opera sobre un procesador cuántico cuya conectividad de qubits se describe mediante una red. Los procesadores cuánticos actuales de IBM Quantum® utilizan la red heavy-hex. Los qubits del procesador se agrupan en plaquetas según la celda unitaria de la red a la que pertenecen. Dado que un qubit puede pertenecer a más de una celda unitaria, las plaquetas no son disjuntas. En la red heavy-hex, una plaqueta contiene 12 qubits. Las plaquetas en sí también forman redes, donde dos plaquetas están conectadas si comparten algún qubit. En la red heavy-hex, las plaquetas vecinas comparten tres qubits.
En el paquete de software GEM Suite, la clase fundamental para implementar el protocolo GEM es PlaquetteLattice, que representa la red de plaquetas (la cual es distinta de la red heavy-hex). Un PlaquetteLattice se puede inicializar a partir de un mapa de acoplamiento de qubits. Actualmente, solo se admiten mapas de acoplamiento heavy-hex.
La siguiente celda de código inicializa una red de plaquetas a partir del mapa de acoplamiento de una unidad de procesamiento cuántico (QPU). La red de plaquetas no siempre abarca todo el hardware. Por ejemplo, ibm_torino tiene 133 qubits en total, pero la red de plaquetas más grande que cabe en el dispositivo utiliza solo 125 de ellos y comprende 18 plaquetas; ibm_pittsburgh (156 qubits) de igual manera encaja 144 qubits en 21 plaquetas. El mismo patrón se repite en otras QPUs heavy-hex con distintas cantidades de qubits.
# QiskitRuntimeService.save_account(channel="ibm_quantum", token="<YOUR_API_KEY>", overwrite=True,
# set_as_default=True)
service = QiskitRuntimeService()
backend = service.least_busy(
operational=True, simulator=False, min_num_qubits=127
)
aer_backend = AerSimulator.from_backend(backend)
plaquette_lattice = PlaquetteLattice.from_coupling_map(backend.coupling_map)
print(f"Number of qubits in backend: {backend.num_qubits}")
print(
f"Number of qubits in plaquette lattice: {len(list(plaquette_lattice.qubits()))}"
)
print(f"Number of plaquettes: {len(list(plaquette_lattice.plaquettes()))}")
Puedes visualizar la red de plaquetas generando un diagrama de su representación en forma de grafo. En el diagrama, las plaquetas se representan mediante hexágonos etiquetados, y dos plaquetas están conectadas por una arista si comparten qubits.
plaquette_lattice.draw_plaquettes()

Puedes obtener información sobre plaquetas individuales, como los qubits que contienen, utilizando el método plaquettes.
# Get a list of the plaquettes
plaquettes = list(plaquette_lattice.plaquettes())
# Display information about plaquette 0
plaquettes[0]
PyPlaquette(index=0, qubits=[3, 4, 5, 6, 7, 16, 17, 23, 24, 25, 26, 27], neighbors=[4, 3, 1])
También puedes generar un diagrama de los qubits subyacentes que forman la red de plaquetas.
plaquette_lattice.draw_qubits()

Además de las etiquetas de los qubits y las aristas que indican qué qubits están conectados, el diagrama contiene tres elementos adicionales de información relevantes para el protocolo GEM:
- Cada qubit está sombreado (gris) o sin sombrear. Los qubits sombreados son qubits de "sitio" que representan los sitios del modelo de Ising, y los qubits sin sombrear son qubits de "enlace" utilizados para mediar las interacciones entre los qubits de sitio.
- Cada qubit de sitio está etiquetado como (A) o (B), indicando uno de los dos roles que un qubit de sitio puede desempeñar en el protocolo GEM (los roles se explican más adelante).
- Cada arista está coloreada usando uno de seis colores, particionando así las aristas en seis grupos. Esta partición determina cómo se pueden paralelizar las compuertas de dos qubits, así como diferentes patrones de programación que probablemente incurran en diferentes cantidades de error en un procesador cuántico ruidoso. Dado que las aristas de un grupo son disjuntas, una capa de compuertas de dos qubits puede aplicarse simultáneamente sobre esas aristas. De hecho, es posible dividir los seis colores en tres grupos de dos colores de manera que la unión de cada grupo de dos colores siga siendo disjunta. Por lo tanto, solo se necesitan tres capas de compuertas de dos qubits para activar todas las aristas. Existen 12 formas de particionar los seis colores de esta manera, y cada partición produce un programa de compuertas de tres capas diferente.
Ahora que has creado una red de plaquetas, el siguiente paso es inicializar un objeto GemExperiment, pasando tanto la red de plaquetas como el backend en el que pretendes ejecutar el experimento. La clase GemExperiment gestiona la implementación real del protocolo GEM, incluyendo la generación de circuitos, el envío de trabajos y el análisis de los datos. La siguiente celda de código inicializa la clase del experimento restringiendo la red de plaquetas a una sola plaqueta (12 qubits), manteniendo la simulación pequeña y rápida. La red de plaquetas completa se utiliza más adelante al escalar al hardware real.
# Filter the plaquette lattice down to a single plaquette (12 qubits)
# so the AerSimulator run stays fast. The full lattice is used later
# in the large-scale hardware example.
gem_exp = GemExperiment(plaquette_lattice.filter([9]), backend=aer_backend)
# visualize the plaquette lattice after filtering
plaquette_lattice.filter([9]).draw_qubits()
Un circuito del protocolo GEM se construye siguiendo estos pasos:
- Preparar el estado de todos aplicando una compuerta Hadamard a cada qubit.
- Aplicar una compuerta entre cada par de qubits conectados. Esto se puede lograr usando tres capas de compuertas. Cada compuerta actúa sobre un qubit de sitio y un qubit de enlace. Si el qubit de sitio está etiquetado como (B), entonces el ángulo se fija en . Si el qubit de sitio está etiquetado como (A), entonces se permite que el ángulo varíe, produciendo diferentes circuitos. Por defecto, el rango de ángulos se establece en 21 puntos igualmente espaciados entre y , inclusive.
- Medir cada qubit de enlace en la base de Pauli . Dado que los qubits se miden en la base de Pauli , esto se puede lograr aplicando una compuerta Hadamard antes de medir el qubit.
Ten en cuenta que el artículo citado en la introducción de este tutorial utiliza una convención diferente para el ángulo , que difiere de la convención utilizada en este tutorial por un factor de 2.
En el paso tres, solo se miden los qubits de enlace. Para entender en qué estado permanecen los qubits de sitio, es instructivo considerar el caso en que el ángulo aplicado a los qubits de sitio (A) en el paso dos es igual a . En este caso, los qubits de sitio quedan en un estado altamente entrelazado similar al estado GHZ,
Debido a la aleatoriedad en los resultados de medición, el estado real de los qubits de sitio podría ser un estado diferente con orden de largo alcance, por ejemplo, . Sin embargo, el estado GHZ se puede recuperar aplicando una operación de decodificación basada en los resultados de medición. Cuando el ángulo se reduce desde , el orden de largo alcance aún se puede recuperar hasta un ángulo crítico, que en ausencia de ruido es aproximadamente . Por debajo de este ángulo, el estado resultante ya no exhibe entrelazamiento de largo alcance. Esta transición entre la presencia y la ausencia de orden de largo alcance es la transición de fase de Nishimori.
En la descripción anterior, los qubits de sitio se dejaron sin medir, y la operación de decodificación puede realizarse aplicando compuertas cuánticas. En el experimento tal como se implementa en GEM Suite, los qubits de sitio sí se miden, y la operación de decodificación se aplica en un paso de posprocesamiento clásico.
En la descripción anterior, la operación de decodificación puede realizarse aplicando compuertas cuánticas a los qubits de sitio para recuperar el estado cuántico. Sin embargo, si el objetivo es medir inmediatamente el estado (por ejemplo, con fines de caracterización), entonces puedes medir los qubits de sitio junto con los qubits de enlace, y aplicar la operación de decodificación en un paso de posprocesamiento clásico.
Además de depender del ángulo en el paso dos, que por defecto recorre 21 valores, el circuito del protocolo GEM también depende del patrón de programación utilizado para implementar las tres capas de compuertas . Como se discutió anteriormente, existen 12 de estos patrones de programación. Por lo tanto, el número total de circuitos en el experimento es .
Los circuitos del experimento se pueden generar utilizando el método circuits de la clase GemExperiment.
circuits = gem_exp.circuits()
print(f"Total number of circuits: {len(circuits)}")
Total number of circuits: 252
Para los propósitos de este tutorial, es suficiente considerar un solo patrón de programación. La siguiente celda de código restringe el experimento al primer patrón de programación. Como resultado, el experimento tiene solo 21 circuitos, uno para cada ángulo recorrido.
# Restrict experiment to the first scheduling pattern
gem_exp.set_experiment_options(schedule_idx=0)
# There are less circuits now
circuits = gem_exp.circuits()
print(f"Total number of circuits: {len(circuits)}")
# Print the RZZ angles swept over
print(f"RZZ angles:\n{gem_exp.parameters()}")
Total number of circuits: 21
RZZ angles:
[0. 0.07853982 0.15707963 0.23561945 0.31415927 0.39269908
0.4712389 0.54977871 0.62831853 0.70685835 0.78539816 0.86393798
0.9424778 1.02101761 1.09955743 1.17809725 1.25663706 1.33517688
1.41371669 1.49225651 1.57079633]
La siguiente celda de código dibuja un diagrama del circuito en el índice 5. Para reducir el tamaño del diagrama, se eliminan las compuertas de medición al final del circuito.
# Get the circuit at index 5
circuit = circuits[5]
# Remove the final measurements to ease visualization
circuit.remove_final_measurements()
# Draw the circuit
circuit.draw("mpl", fold=-1, scale=0.5)
Paso 2: Optimizar el problema para la ejecución en hardware cuántico
La transpilación de circuitos cuánticos para su ejecución en hardware generalmente involucra varias etapas. Típicamente, las etapas que conllevan mayor costo computacional son la elección de la disposición de qubits, el enrutamiento de las compuertas de dos qubits para ajustarse a la conectividad del hardware, y la optimización del circuito para minimizar el conteo y la profundidad de compuertas. En el protocolo GEM, las etapas de disposición y enrutamiento son innecesarias porque la conectividad del hardware ya está incorporada en el diseño del protocolo. Los circuitos ya tienen una disposición de qubits, y las compuertas de dos qubits ya están mapeadas sobre conexiones nativas. Además, para preservar la estructura del circuito a medida que varía el ángulo , solo se debe realizar una optimización de circuito muy básica.
La clase GemExperiment transpila los circuitos de forma transparente al ejecutar el experimento. Las etapas de disposición y enrutamiento ya están anuladas por defecto para no hacer nada, y la optimización de circuitos se realiza a un nivel que solo optimiza compuertas de un solo qubit. Sin embargo, puedes anular o pasar opciones adicionales utilizando el método set_transpile_options. Para fines de visualización, la siguiente celda de código transpila manualmente el circuito mostrado anteriormente y dibuja el circuito transpilado.
# Demonstrate setting transpile options
gem_exp.set_transpile_options(
optimization_level=1 # This is the default optimization level
)
pass_manager = generate_preset_pass_manager(
backend=aer_backend,
initial_layout=list(gem_exp.physical_qubits),
**dict(gem_exp.transpile_options),
)
transpiled = pass_manager.run(circuit)
transpiled.draw("mpl", idle_wires=False, fold=-1, scale=0.5)
Paso 3: Ejecutar utilizando primitivas de Qiskit
Para ejecutar los circuitos del protocolo GEM en el hardware, llama al método run del objeto GemExperiment. Puedes especificar el número de shots que deseas muestrear de cada circuito. El método run devuelve un objeto ExperimentData que debes guardar en una variable. Ten en cuenta que el método run solo envía los trabajos sin esperar a que terminen, por lo que es una llamada no bloqueante.
exp_data = gem_exp.run(shots=10_000)
Para esperar los resultados, llama al método block_for_results del objeto ExperimentData. Esta llamada hará que el intérprete se detenga hasta que los trabajos hayan finalizado.
# The noiseless AerSimulator produces zero-variance UFloat objects in the
# analysis, which triggers a harmless warning from the `uncertainties`
# library. Suppress it so the output stays clean.
with warnings.catch_warnings():
warnings.filterwarnings(
"ignore", message="Using UFloat objects with std_dev==0"
)
exp_data.block_for_results()
exp_data
ExperimentData(GemExperiment, 90bf2a90-f729-4c4e-a6da-664aecb11039, job_ids=['04a7c405-47fd-46ca-aa4b-aaf7e339cfbe'], metadata=<5 items>, figure_names=['two_point_correlation.svg', 'normalized_variance.svg', 'plaquette_ops.svg', 'bond_ops.svg'])
Paso 4: Posprocesar y devolver el resultado en el formato clásico deseado
A un ángulo de , el estado decodificado sería el estado GHZ en ausencia de ruido. El orden de largo alcance del estado GHZ se puede visualizar graficando la magnetización de las cadenas de bits medidas. La magnetización se define como la suma de los operadores de Pauli de un solo qubit,
donde es el número de qubits de sitio. Su valor para una cadena de bits es igual a la diferencia entre el número de ceros y el número de unos. Medir el estado GHZ produce el estado de todos ceros o el estado de todos unos con igual probabilidad, por lo que la magnetización sería la mitad de las veces y la otra mitad. En presencia de errores debidos al ruido, también aparecerían otros valores, pero si el ruido no es demasiado grande, la distribución seguiría concentrándose cerca de y .
Para las cadenas de bits sin procesar antes de la decodificación, la distribución de la magnetización sería equivalente a la de cadenas de bits uniformemente aleatorias, en ausencia de ruido.
La siguiente celda de código grafica la magnetización de las cadenas de bits sin procesar y las cadenas de bits decodificadas al ángulo de .
def magnetization_distribution(
counts_dict: dict[str, int],
) -> dict[str, float]:
"""Compute magnetization distribution from counts dictionary."""
# Construct dictionary from magnetization to count
mag_dist = defaultdict(float)
for bitstring, count in counts_dict.items():
mag = bitstring.count("0") - bitstring.count("1")
mag_dist[mag] += count
# Normalize
shots = sum(counts_dict.values())
for mag in mag_dist:
mag_dist[mag] /= shots
return mag_dist
# Get counts dictionaries with and without decoding
data = exp_data.data()
# Get the last data point, which is at the angle for the GHZ state
raw_counts = data[-1]["counts"]
# Without decoding
site_indices = [
i for i, q in enumerate(gem_exp.plaquettes.qubits()) if q.role == "Site"
]
site_raw_counts = defaultdict(int)
for key, val in raw_counts.items():
site_str = "".join(key[-1 - i] for i in site_indices)
site_raw_counts[site_str] += val
# With decoding
_, site_decoded_counts = gem_exp.plaquettes.decode_outcomes(
raw_counts, return_counts=True
)
# Compute magnetization distribution
raw_magnetization = magnetization_distribution(site_raw_counts)
decoded_magnetization = magnetization_distribution(site_decoded_counts)
# Plot
plt.bar(*zip(*raw_magnetization.items()), label="raw")
plt.bar(*zip(*decoded_magnetization.items()), label="decoded", width=0.3)
plt.legend()
plt.xlabel("Magnetization")
plt.ylabel("Frequency")
plt.title("Magnetization distribution with and without decoding")
Text(0.5, 1.0, 'Magnetization distribution with and without decoding')
Para caracterizar el orden de largo alcance de manera más rigurosa, puedes examinar la correlación promedio de dos puntos , definida como
Un valor más alto indica un mayor grado de entrelazamiento. La clase GemExperiment calcula automáticamente este valor para las cadenas de bits decodificadas como parte del procesamiento de los datos experimentales. Almacena una figura que es accesible a través del método figure de la clase de datos del experimento. En este caso, el nombre de la figura es two_point_correlation.
exp_data.figure("two_point_correlation")
Para determinar el punto crítico de la transición de fase de Nishimori, puedes observar la varianza normalizada de , definida como
que cuantifica la cantidad de fluctuación en la magnetización al cuadrado. Este valor se maximiza en el punto crítico de la transición de fase de Nishimori. En ausencia de ruido, el punto crítico ocurre aproximadamente en . En presencia de ruido, el punto crítico se desplaza hacia arriba, pero la transición de fase aún se observa siempre que el punto crítico ocurra por debajo de .
exp_data.figure("normalized_variance")
Ejemplo de hardware a gran escala
Habiendo validado el protocolo en un simulador, ahora puedes escalar el experimento y ejecutarlo en el backend de hardware cuántico real seleccionado en la sección Configuración. Este ejemplo utiliza dos tamaños de problema más grandes:
- Seis plaquetas (~49 qubits): una ejecución de tamaño intermedio que ya muestra el desplazamiento hacia la derecha del punto crítico bajo el ruido del hardware.
- La red de plaquetas completa: todas las plaquetas que admite la topología heavy-hex del dispositivo (por ejemplo, 18 plaquetas / 125 qubits en
ibm_torinoo 21 plaquetas / 144 qubits enibm_pittsburgh), entrelazando qubits a lo largo de todo el dispositivo con circuitos de profundidad constante.
La siguiente celda de código es autocontenida: construye la red de plaquetas a partir del mapa de acoplamiento del backend y ejecuta ambos experimentos, por lo que esta sección puede ejecutarse después de las celdas de Configuración sin necesidad de ejecutar primero la sección a pequeña escala.
# -------------------------Step 1-------------------------
# Initialize the runtime service, pick a real quantum hardware backend,
# and build the plaquette lattice from its coupling map. This is repeated
# from the small-scale example so this cell can run standalone after the
# Setup section. The full plaquette lattice is the "large-scale" target;
# a six-plaquette subset (range(3, 9)) is also used to show an intermediate
# scaling step.
service = QiskitRuntimeService()
backend = service.least_busy(
operational=True, simulator=False, min_num_qubits=127
)
plaquette_lattice = PlaquetteLattice.from_coupling_map(backend.coupling_map)
# Build a GemExperiment for the full plaquette lattice and one for the
# six-plaquette subset, each restricted to a single scheduling pattern so
# the experiment has one circuit per RZZ angle (21 circuits total).
gem_exp_full = GemExperiment(plaquette_lattice, backend=backend)
gem_exp_full.set_experiment_options(schedule_idx=0)
gem_exp_6 = GemExperiment(
plaquette_lattice.filter(range(3, 9)), backend=backend
)
gem_exp_6.set_experiment_options(schedule_idx=0)
circuits = gem_exp_full.circuits()
print(f"Total number of circuits (full lattice): {len(circuits)}")
# -------------------------Step 2-------------------------
# GemExperiment transpiles internally for the target backend: the layout
# and routing stages are overridden because the plaquette lattice already
# matches the hardware connectivity, and optimization is restricted so the
# RZZ angle structure is preserved. The code below manually transpiles one
# circuit from the six-plaquette experiment with the same settings this
# experiment will use, and draws it for inspection. (The full-lattice
# transpiled circuit has too many qubits to visualize cleanly, so the
# six-plaquette circuit is used here as a representative example.)
gem_exp_6.set_transpile_options(optimization_level=1)
circuits_6 = gem_exp_6.circuits()
pass_manager = generate_preset_pass_manager(
backend=backend,
initial_layout=list(gem_exp_6.physical_qubits),
**dict(gem_exp_6.transpile_options),
)
transpiled = pass_manager.run(circuits_6[5])
display(transpiled.draw("mpl", idle_wires=False, fold=-1, scale=0.5))
# -------------------------Step 3-------------------------
# Run both problem sizes on real hardware:
# 1. Six plaquettes (~49 qubits) — an intermediate scale-up.
# 2. The full plaquette lattice — every plaquette the device supports.
exp_data_6 = gem_exp_6.run(shots=10_000, job_tags=["TUT_NPT"])
exp_data_full = gem_exp_full.run(shots=10_000, job_tags=["TUT_NPT"])
exp_data_6.block_for_results()
exp_data_full.block_for_results()
# -------------------------Step 4-------------------------
# Plot the normalized variance at each scale. The peak marks the critical
# point of the Nishimori transition; as the system grows, hardware noise
# shifts the peak rightward.
display(exp_data_6.figure("normalized_variance"))
exp_data_full.figure("normalized_variance")
Total number of circuits (full lattice): 21

Ten en cuenta que, dependiendo del nivel de ruido del backend utilizado, las curvas de varianza normalizada en los tamaños más grandes pueden no mostrar un pico claro dentro del rango de ángulos recorrido. En las ejecuciones anteriores, el pico se ha desplazado hasta , el borde derecho del barrido (el análisis reporta critical_angle = 0.5000 tanto para la ejecución de seis plaquetas como para la de la red completa). Esto significa que el ruido del hardware ha desplazado el punto crítico hasta (o justo más allá de) el límite del rango de ángulos físicamente significativo del protocolo, por lo que la transición está en el límite de lo que este barrido puede resolver.
Conclusión
En este tutorial, realizaste una transición de fase de Nishimori en un procesador cuántico utilizando el protocolo GEM. Las métricas que examinaste durante el posprocesamiento — en particular, la correlación de dos puntos y la varianza normalizada — sirven como referencias de la capacidad del dispositivo para generar estados entrelazados de largo alcance. Estas referencias extienden la utilidad del protocolo GEM más allá de explorar física interesante. Como parte del protocolo, entrelazaste qubits a lo largo de todo el dispositivo utilizando circuitos de profundidad constante. Esta hazaña solo es posible gracias al uso de mediciones a mitad de circuito por parte del protocolo. En este experimento, el estado entrelazado fue medido inmediatamente, pero considera explorar más allá utilizando este estado en procesamiento cuántico adicional.
Próximos pasos
Si este trabajo te resultó interesante, puede que te interese el siguiente material:
Referencias
[1] E. H. Chen, G.-Y. Zhu, R. Verresen, A. Seif, E. Bäumer, D. Layden, N. Tantivasadakarn, G. Zhu, S. Sheldon, A. Vishwanath, S. Trebst, A. Kandala. Realizing the Nishimori transition across the error threshold for constant-depth quantum circuits. arXiv:2309.02863 (2023).
[2] GEM Suite software package.