-- (Updated)

Achronyme 0.1.0: stable at last

#achronyme #release #zk #rust #compiler

I published Achronyme 0.1.0 today. The tag points to the exact commit fd07b38e16256e2ed6a8f2b438d340a681c9b0ac.

I need to start with something simple: I’m sorry for how long this took and for going quiet. In March I wrote about a beta as if the stable release were just around the corner. I was wrong: I underestimated the remaining work, then said too little while I worked through it.

The delay needs more than a task list. I held the version number until there was evidence another person could inspect, and that decision deserves an explanation.

What changed since the beta

Since the language experiment I described at the start of the year, Achronyme has gained structured concurrency, lexically scoped tasks, channels, owned I/O, resource limits, and capability manifests. The compiler propagates effects across calls so the boundary between host behavior and provable behavior remains explicit.

That behavior is covered across the interpreter, LLVM JIT, AOT, and WebAssembly targets. The module system, LSP, diagnostics, and circuit compiler belong to the same release instead of being separate demos that happen to share a home page.

I also published Achronyme Editor 0.3.0, with Linux, macOS, and Windows packages that understand the language features shipped in 0.1.0.

The part a unit test could not cover

Groth16 needs a trusted setup tied to the circuit. Automating its commands does not remove that trust. The release gate therefore required a phase 2 contribution controlled outside my environment, a later public beacon, and cross-verification with snarkjs.

The acceptance circuit ended up with 1,501,364 constraints and 5,201,533 variables. Its final zkey is 2,213,426,379 bytes. Moving and verifying files at that size exposed every bad assumption about memory, storage, and runtime.

I prepared a Windows Home kit that required no WSL, Docker, Rust, Git, or private circuit data. A member of my family controlled their computer and entropy during the contribution. I received the resulting zkey and a minimal receipt, and I did not accept the file merely because it came back with the expected size.

Acceptance required rebuilding the exact R1CS and witness, checking their hashes, verifying the Powers of Tau transcript, running snarkjs zkey verify, and checking the contribution metadata. One verification ended with Signal 9, so I had to rethink memory use before continuing.

I then committed to a future drand round, waited for it to be published, and used that value as the final beacon. The result is bound to the circuit, the binary, and the release source.

The contributor name and hashes provide provenance. They do not make independent control a cryptographically provable property. What I can say is that I did not control that computer or its entropy, and that the procedure retains verifiable evidence for every artifact used in the result.

Two implementations had to agree

The final gate ran 13 measured stages. snarkjs generated a proof that both snarkjs and Achronyme verified. Achronyme then generated another proof from the trusted store, without a local setup, and both implementations verified it again. The R1CS regenerated by Achronyme was byte-identical to the one used in the ceremony.

The hashes, manifests, timings, peak memory measurements, public keys, and witness-free proofs are in the immutable ceremony and interoperability dossier. The release also includes achronyme-0.1.0-proving-evidence.tar.gz and its checksum.

I did not publish entropy, toxic waste, private inputs, the witness, Powers of Tau bytes, or the proving key. Those bytes are not public evidence and do not belong in a repository.

Less elegant things failed too

Ordinary engineering failures caused more delays. One CI contract assumed that rg was installed. A pending-request limit test depended too heavily on the exact moment a job started. An AOT smoke test for an installed package omitted the file.read and file.write capabilities that the runtime already required.

Each failure looked small in isolation. Together they showed that the release still depended on my workstation, a scheduler race, or implicit permissions. I fixed them because a stable version has to survive outside the environment where it was written.

I used disposable Google Cloud compute for the heavy stages. When finalization finished, I copied and rechecked the required private store, deleted the finalization VM and its auto-delete disk, and verified that both resources were gone. The temporary infrastructure was not left running after the release.

What shipped

The Achronyme 0.1.0 release includes binaries for Linux x86_64 and aarch64, Intel and Apple Silicon macOS, and Windows x86_64. The Linux bundles have SHA-256 sidecars, and GitHub records a digest for every asset. The proving evidence is a separate download so anyone can inspect the link between source, circuit, ceremony, and proofs.

For a concrete program that exercises the new module, concurrency, capability, and proof boundaries together, read A private auction as an Achronyme integration test.

The stable label applies to one exact source revision and the documented checks around it. The language still has unfinished work. Drawing that boundary accounts for much of the past few months.

Thank you to everyone who kept asking about Achronyme when I still could not give a serious date. Thank you as well to the person who made the external contribution and gave up hours of computer time for a process that was not especially exciting to watch.

Achronyme 0.1.0 is published. This time that sentence comes with a tag, hashes, binaries, and evidence.