Measurement

Progress that can be inspected

Claims about quantum cryptanalysis are easy to make and hard to compare. Potomac reports progress in a way that states what was run, on what, under which assumptions, and how reliably, so that results can be checked, repeated, and compared over time.

Purpose

What the measurements are for

Measurements serve three purposes at Potomac. They select useful experiments, by showing which kernel, operand size, and platform would teach the most. They compare software improvements, by putting a new circuit or compilation pass against a reproduced baseline under one accounting convention. And they evaluate progress toward meaningful hardware execution, by recording what actually ran, how reliably, and at what cost.

None of the displays on this page show achieved milestones. The framework describes how results will be reported; the research path shows where the work is headed.

The framework

Six things every report states

Task and scale
Which operation is being studied and at what operand size.
Correctness
The validation method and the assumptions under which the result is considered valid.
Logical resources
Logical qubits and the applicable gate count or depth, with the accounting convention identified.
Execution assumptions
Architecture, compilation, error correction, scheduling, and runtime assumptions, where applicable.
Reliability
The success criteria, the observed probability where measured, and the relevant uncertainty.
Evidence status
Whether the entry is measured hardware work, a simulation, or a resource estimate.

Maximum Reliable Kernel

A proposed measure for each operation and platform

Definition

For a defined arithmetic operation, the largest operand size executable on a specified platform under declared correctness and reliability criteria.

Maximum Reliable Kernel is a proposed framework under development, not an adopted standard. It is reported for one operation on one platform at a time, never as a single score, and it carries its validation method and assumptions with it.

Its purpose is to make progress toward larger and more complex kernels legible without implying that any particular milestone has been reached. A report that cannot state its correctness criterion and evidence status is not a Maximum Reliable Kernel result.

Sample report structureFormat schematic: no result data
Operation
The arithmetic kernel studied, for example an adder, controlled modular addition, or comparison.
Operand size
The width n in bits for which the result holds.
Platform
The hardware or simulator, its architecture, and the access conditions under which it was used.
Correctness
How outputs were validated and the criteria applied.
Logical resources
Logical qubits and gate counts or depth, with the accounting convention.
Execution assumptions
Compilation, error correction, scheduling, and runtime assumptions, where applicable.
Reliability
Success criteria, the observed success probability where measured, and its uncertainty.
Evidence status
Measured on hardware, simulated, or estimated.

A report declares every field. Fields that do not apply are marked as such rather than omitted.

Research path

Research path to 256-bit arithmetic

Adders sit inside modular addition, modular operations inside multiplication, and multiplications inside elliptic-curve point addition. The matrix below organizes the kernels the program studies by operation and operand size. The path drawn across it is a schematic of increasing scope: from small arithmetic kernels toward larger operand sizes and higher-level operations, ending at point addition on 256-bit operands.

The 256 bits refer to operand width, the size of the numbers the circuit adds or multiplies. They are not a count of physical qubits, and reaching the end of the path would not by itself be a demonstrated key recovery. The path does not assert that every row depends on the row below in one fixed order, and the columns are labelled operand widths, not a timeline or equally spaced distances.

Illustrative research path

Research targetEC point addition, 256-bit operands

L8EC point addition
L7In-place multiplication
L6Lookup
L5Controlled multiplier
L4Comparison
L3Modular doubling
L2Controlled modular addition
L1Adder
  1. L1 Adder6-bit operandsSmall adders are the first kernels to validate on any platform: simple to check exhaustively and quick to run.
  2. L1 Adder32-bit operandsAdders at word size show how reliability and depth scale with width before anything is built on them.
  3. L2 Controlled modular addition32-bit operandsControlled modular addition composes adders with comparison and correction: the first test of composition.
  4. L3 Modular doubling48-bit operandsModular doubling reuses the modular adder and shows whether validated components compose without new bottlenecks.
  5. L4 Comparison64-bit operandsComparison at 64 bits is a building block for modular reduction and for the lookups above it.
  6. L5 Controlled multiplier96-bit operandsControlled multipliers stress qubit reuse and scheduling; operand width starts to dominate cost.
  7. L6 Lookup128-bit operandsLookup structures trade gates for qubits, a key operand size for comparing accounting conventions.
  8. L7 In-place multiplication176-bit operandsIn-place multiplication at large widths tests whether the arithmetic stack holds together under fault-tolerant accounting.
  9. L8 EC point addition224-bit operandsPoint addition below the target width, to compare against published logical-circuit results.
  10. L8 EC point addition256-bit operandsThe research target: elliptic-curve point addition on 256-bit operands, executed reliably on a specified platform. Not a claimed result.
681216243248648096112128144160176192208224240256

Operand size n (bits)

L8
EC point addition
L7
In-place multiplication
L6
Lookup
L5
Controlled multiplier
L4
Comparison
L3
Modular doubling
L2
Controlled modular addition
L1
Adder
Illustrative research path toward 256-bit elliptic-curve arithmetic.

Proposed and illustrative. No cell represents a measured result; future measured data will appear as a separate, sourced layer.

Waypoints on the path

  1. L1 Adder, 6-bitSmall adders are the first kernels to validate on any platform: simple to check exhaustively and quick to run.
  2. L1 Adder, 32-bitAdders at word size show how reliability and depth scale with width before anything is built on them.
  3. L2 Controlled modular addition, 32-bitControlled modular addition composes adders with comparison and correction: the first test of composition.
  4. L3 Modular doubling, 48-bitModular doubling reuses the modular adder and shows whether validated components compose without new bottlenecks.
  5. L4 Comparison, 64-bitComparison at 64 bits is a building block for modular reduction and for the lookups above it.
  6. L5 Controlled multiplier, 96-bitControlled multipliers stress qubit reuse and scheduling; operand width starts to dominate cost.
  7. L6 Lookup, 128-bitLookup structures trade gates for qubits, a key operand size for comparing accounting conventions.
  8. L7 In-place multiplication, 176-bitIn-place multiplication at large widths tests whether the arithmetic stack holds together under fault-tolerant accounting.
  9. L8 EC point addition, 224-bitPoint addition below the target width, to compare against published logical-circuit results.
  10. L8 EC point addition, 256-bitThe research target: elliptic-curve point addition on 256-bit operands, executed reliably on a specified platform. Not a claimed result.

Collaboration

Experiments with hardware collaborators

We seek quantum computing teams to test cryptanalytic kernels and identify practical constraints.

Proposed collaboration model

  1. DefineAgree on a kernel, operand size, and success criterion.
  2. CompileMap the kernel to the platform’s operations and architecture.
  3. RunExecute under agreed access and operating conditions.
  4. MeasureRecord correctness, reliability, resources, and runtime.
  5. ReportIdentify the limiting layer and propose the next experiment.
Each report defines the next experiment.
Potomac brings
Workloads, optimization software, and reproducible analysis.
Collaborators bring
Device access, platform expertise, and agreed technical interfaces.
Output
A tested workload, an identified bottleneck, and a better next experiment.

Hardware and software ecosystem

Continue