measurements/graviton-fast-rollout-20260910/README.md

Optimized 84-group RandomX rollout

Production source 2737c4559d616e543be706ec576630d21eae9007 is running non-debug on the Graviton5 parent. Fresh public Nitro verification at 2026-09-10 09:10:33 UTC confirmed its exact PCR0, TLS peer, hardware, 84 groups, 3,647,344 iterations, Mullvad up, and warming. Ordinary client verification rejects warming and forwarding returns 503. Full-work generation and daily rollover remain pending.

The prior warm-up was terminated with user authorization; see termination.json. The short-work diagnostic was then replaced by production. All source, releases, logs and archive files were retained.

Grouping and CPU allocation

The candidate combines the ARM JIT optimization (previously measured at +19.23% sequential speed) with 84 independently generated, serially wrapped groups. A bounded worker pool uses available enclave CPUs, capped at 84. Each worker owns one VM and shares the initialized dataset/cache; it takes another group when its current group completes. Linux generation threads inherit nice 19. Only the first seed is public, so recovery still traverses every group serially.

Total work: 84 * 3,647,344 = 306,376,896 hashes, versus 306,376,868 previously. 84 divides evenly across 7, 12 or 14 workers. This preserves computational work; it does not establish a hardware-independent seven-day delay.

Actual allocation is 14 enclave CPUs (physical IDs 1–14) and 8 GiB. Parent CPUs 0 and 15 remain online; approximately 24 GiB is outside the enclave reservation. Nitro CPUs are exclusive: nice 19 prioritizes other work inside the enclave, but does not lend CPUs to parent workloads.

Legacy seven-group signatures and recovery remain compatible. Rust and Python accept only 7 or 84 groups, require the matching wrapper count, and enforce the manifest's equality with signed attested policy. Checkpoints use the actual manifest count, including the final 84th group.

Verification

PCR0: d48f4df3b4e369ac6c97bb4b7ba0157c21ddbc4708abbe488a152ad2eead54f2418f65e622a2272f678090ad63997c42. Source archive and signed build evidence are public with anonymous hash readback; URLs and digests are in source-84-publication.json and public-build-evidence.json.

Operations and handoff

Production enclave: production-groups84-2737c45, ID i-0de9795ee9d3ce090-enc1a08a949353529e. Its launch record is under production/.

The nine-worker Hetzner solver controller now uses the new pin and recorded source from /opt/attested-relay-fleet-v2/source-2737c45. The native solver SHA256 is 75fb9778f9933352af2e51b75b932cec7eccc066fc8b624716626c6311b966e5. The existing packaged 0.2.0a2 environment is retained, with explicit source and native overrides in zz-groups-84.conf; see fleet-activation.log. The mirror continues running. Published PyPI 0.2.0a2 does not yet support 84 groups; a new public package release is still needed. No public readiness is claimed.

Frozen source is local at .local/graviton-fast-rollout-20260910/source and remote at /home/ec2-user/graviton-fast-rollout-20260910/source-84. Build output is the sibling build-84 directory. Parent release and artifacts have distinct preserved production-groups84-2737c45 directories.

On the Graviton parent, the release-specific control script is:

python3 /home/ec2-user/graviton-fast-rollout-20260910/control-84.py status
sudo python3 /home/ec2-user/graviton-fast-rollout-20260910/control-84.py stop
sudo python3 /home/ec2-user/graviton-fast-rollout-20260910/control-84.py start

stop terminates only this named enclave, returns its reserved CPUs to the parent and releases its hugepage reservation. It retains files and appends a control record. Stopping loses unfinished in-memory generation; start begins a fresh warm-up, after verifying the immutable installed image hash and current host release. The stop/start paths are prepared for the next task and have not been exercised against the new production warm-up; read-only status was verified. Other enclave names cause an error rather than affecting unrelated runs.