feat: halo2 gpu test (DO NOT MERGE)

[gaxiom]

No description provided.

[github-actions]

Claude finished @gaxiom's task in 1m 51s —— View job

---

Code Review: PR #2772 — feat: halo2 gpu test (DO NOT MERGE)

• Gather context and read the diff
• Review Cargo.toml changes
• Review Cargo.lock changes
• Post review feedback

---

This PR makes two dependency-level changes to support testing the halo2 GPU (CUDA) prover path:

1. Switches all stark-backend workspace deps from branch = "develop-v2" to branch = "feat/halo2-gpu" (7 crates).
2. Adds a [patch.crates-io] for halo2-axiom, redirecting it from crates.io to the feat/cuda-common-bn254 branch of the private axiom-crypto/halo2-gpu repo via SSH.

---

Issues Found

1. Duplicate openvm-cuda-builder — branch mismatch (Medium)

The Cargo.lock contains two copies of openvm-cuda-builder 2.0.0-alpha:

Consumer	Source branch
Workspace crates (13 references)	feat/halo2-gpu (0e0e298c)
halo2-axiom (GPU fork)	develop-v2 (f36fefe5)

This means halo2-axiom from the GPU fork pins its own openvm-cuda-builder to the develop-v2 branch, while the rest of the workspace uses the feat/halo2-gpu branch. Two copies of the same crate at different commits can cause subtle type-mismatch or link issues at runtime. The halo2-gpu fork's Cargo.toml likely needs to be updated to also point at feat/halo2-gpu, or you should add a [patch] for openvm-cuda-builder as well to unify the resolution.

2. SSH source for halo2-axiom patch — CI compatibility (Medium)

[patch.crates-io]
halo2-axiom = { git = "ssh://git@github.com/axiom-crypto/halo2-gpu.git", branch = "feat/cuda-common-bn254" }

This uses ssh://git@github.com which requires SSH key authentication. This will fail in any CI environment that doesn't have the appropriate deploy key configured (including standard GitHub Actions runners). Since the title says "DO NOT MERGE" this is likely intentional for local testing, but worth noting. If this needs to work in CI eventually, consider using HTTPS with a token or making the repo public.

3. Legacy / deprecated transitive dependencies (Low)

The GPU fork of halo2-axiom pulls in several older crate versions as new transitive deps:

• cfg-if 0.1.10 (current: 1.x)
• bitflags 1.3.2 (current: 2.x)
• env_logger 0.7.1 (current: 0.11.x)
• atty 0.2.14 (unmaintained, replaced by is-terminal)
• humantime 1.3.0 (current: 2.x)
• hermit-abi 0.1.19 (current: 0.5.x)

These are not blocking for an experimental branch, but the halo2-gpu fork is carrying a fair amount of dependency debt. Worth tracking as tech debt for the upstream fork.

4. No [patch] for openvm-cuda-common (Low)

halo2-axiom depends on openvm-cuda-common (without a disambiguation suffix in the lockfile), meaning Cargo resolved it to the feat/halo2-gpu branch. This seems correct, but it's worth verifying that the openvm-cuda-common API is compatible between what halo2-axiom expects and what feat/halo2-gpu provides — an incompatibility here would be a compile error, not a silent bug.

5. Comment block is overly detailed for Cargo.toml (Nit)

# Point halo2-base / halo2-ecc at the GPU fork of halo2-axiom (halo2-gpu)
# so the CUDA prover path is exercised. Tracks the Phase 1 cuda-common
# migration branch; once that work merges back into halo2-gpu's main
# line, switch this to a stable branch or pinned rev. Tracking INT-6841
# / INT-7555.

Per repo conventions (CLAUDE.md: "default to writing no comments"), this 5-line comment is heavy for a Cargo.toml. The ticket references (INT-6841 / INT-7555) are useful, but the rest is better suited for a commit message or PR description. Consider trimming to a single line like:

# Tracking INT-6841 / INT-7555: GPU fork of halo2-axiom for CUDA prover testing

---

Summary

The main concern is issue #1 — the duplicate openvm-cuda-builder from two different branch commits is likely to cause problems when CUDA features are actually compiled and linked. Issues #2–5 are minor and acceptable for a "DO NOT MERGE" experimental branch.

[github-actions]

Claude finished @gaxiom's task in 1m 32s —— View job

---

Code Review: PR #2772 — feat: halo2 gpu test (DO NOT MERGE)

• Gather context and read the diff
• Review Cargo.toml changes
• Review Cargo.lock changes
• Post review feedback

---

This PR (6 commits) makes two dependency-level changes to support testing the halo2 GPU (CUDA) prover path:

1. Switches all 7 stark-backend workspace deps from branch = "develop-v2" to branch = "feat/halo2-gpu" (now at a71c091d).
2. Adds a [patch.crates-io] for halo2-axiom, redirecting it to a pinned rev (b691925a) of the private axiom-crypto/halo2-gpu repo via SSH.

Since the last review (May 4), the branch has progressed through 4 more commits — switching from branch tracking to pinned revs and bumping the stark-backend lock.

---

Issues

1. Duplicate openvm-cuda-builder — still present (Medium)

The lockfile still contains two copies of openvm-cuda-builder 2.0.0-alpha:

Source	Rev	Consumer
branch=develop-v2	260062e9	halo2-axiom (GPU fork, line 4043)
branch=feat/halo2-gpu	a71c091d	All workspace crates (13 references)

The halo2-axiom fork at rev b691925a hardcodes its openvm-cuda-builder dep to branch = "develop-v2" in its own Cargo.toml, so the workspace [patch] doesn't unify it. This means two different builds of the same crate coexist. When CUDA features are enabled, this can cause type mismatches (e.g., a CudaKernel type from one copy isn't the same as from the other).

Fix options:

• Add openvm-cuda-builder to the [patch.crates-io] section to force unification. Fix this →
• Update the halo2-gpu fork's Cargo.toml to point at feat/halo2-gpu instead of develop-v2.

2. SSH source for halo2-axiom — CI incompatible (Medium)

halo2-axiom = { git = "ssh://git@github.com/axiom-crypto/halo2-gpu.git", rev = "b691925a..." }

SSH auth will fail on standard GitHub Actions runners. Acceptable for a "DO NOT MERGE" local-testing branch, but this blocks any CI validation. If CI needs to run, switch to HTTPS with a PAT or make a deploy key available.

3. openvm-cuda-common resolution looks correct (Info)

openvm-cuda-common resolved to feat/halo2-gpu at a71c091d (line 6196), matching the workspace deps. The halo2-axiom fork lists openvm-cuda-common as a plain dependency (line 4044, no disambiguation suffix), and Cargo unified it with the workspace version. This is correct — no action needed.

4. Legacy transitive dependencies from the GPU fork (Low)

The GPU fork of halo2-axiom still pulls in outdated transitive deps:

• cfg-if 0.1.10, bitflags 1.3.2, env_logger 0.7.1, atty 0.2.14 (unmaintained), humantime 1.3.0, hermit-abi 0.1.19
• New GPU deps: cuda-driver-sys, rustacuda (0.1.3), yastl (via flume)

Not blocking for an experimental branch, but the halo2-gpu fork carries notable dependency debt. The rustacuda crate (0.1.3) and its cuda-driver-sys dep are quite old — worth tracking for the upstream fork.

5. Comment trimmed but still verbose (Nit)

The comment was trimmed from 5 lines to 2 lines compared to the earlier iteration — good improvement. The current 2-line comment is reasonable for context, though per repo conventions a single line would suffice.

---

Summary

The main outstanding issue from the previous review — duplicate openvm-cuda-builder (#1) — remains. It's the primary risk when CUDA features are actually compiled. Everything else is acceptable for a "DO NOT MERGE" experimental branch. The pinned rev approach (replacing branch tracking) is a good improvement for reproducibility.