AuthStream tests whether block-scale private authorization data can be compiled into typed streams and bounded sparse segments before terminal proof construction. The front end keeps claim construction within 4.7% of direct verification, bounds the largest segment at 2^17 rows and emits a compact internal handoff. A cryptographically complete dense terminal closes the relation but projects to roughly eleven minutes at maximum fan-in, so the architecture is not selected for consensus.
Can block-scale authorization proving be streamed?
A wallet-authorization sidecar is the private proof input attached to a transaction but omitted from its public body. A maximum block can carry roughly 14–16 MiB of this data. Materializing the complete workload as one dense circuit would make peak memory grow with the whole block. AuthStream tested a different front end: extract the secret-dependent field elements once, compile them into bounded sparse segments, then give those segments to the proof system. The complete relation means all constraints connecting every segment to one public authorization statement; no segment may remain outside the final proof.
The terminal proof was a requirement from the start. The study separated its feasibility question into two measurements: first establish whether witness production can be streamed with bounded resources; then determine whether a cryptographic backend can close the resulting relation inside the production latency budget.
The streaming compiler
The implemented compiler covered typed stream extraction, a canonical work plan, backend program, sparse constraint plan, witness layout, segment columns, constraints for the Poseidon2b hash permutation and Merkle authentication paths, split-backend coverage and a terminal plan. Every plan was digest-bound so independently implemented producer and backend stages could agree on the same workload.
Those digests were internal compiler contracts, not public proof authority. Their purpose was to make segmentation reproducible and tamper-evident between stages before paying the cost of a terminal proof.
Measured workload and resource bounds
| Probe | Measured result | Established property |
|---|---|---|
| 255 standard authorizations | 2.66 s claim construction vs 2.55 s direct verification | 4.7% streaming-compiler overhead |
| 100 standard authorizations | 863,530 operations; 4,695,640 witness reads | Concrete backend workload |
| Largest sparse segment | 217 rows; estimated 432 MiB peak working set | Bounded segment memory |
| Core accumulator | 113 B; 59.03 ms produce; 54.05 ms check | Compact internal handoff state |
The front end met its objective: private data could be consumed as a deterministic stream, the largest allocation was bounded by one segment rather than the full block, and the internal accumulator remained compact.
Evaluating terminal closure
The 113-byte accumulator summarized the compiler execution for the next stage; it was never a substitute for that stage. Consensus adoption still required one proof binding the sparse row relations, the hash and authentication-path constraints, segment ordering and complete coverage equation to the public authorization statement.
A dense terminal wrapper supplied that cryptographic authority for a measured unit. Its proof was 57.81 KiB, but the maximum 255-authorization workload projected to roughly eleven minutes. The construction closed the relation at a cost incompatible with the block-production path.
Streaming compilation passed its workload and memory gates. The evaluated terminal construction did not pass the production latency gate.
Protocol decision
AuthStream was not selected as the consensus authorization path. The reason was not uncertainty about what the compiler proved: the architecture explicitly required terminal closure. The reason was that the tested closure converted a viable streaming workload into an impractical end-to-end prover.
No compiler digest or core accumulator became a consensus acceptance object. The experiment ended at its decision gate and the production design pursued a different authorization composition.
Reusable result
For large private workloads, witness compilation and proof closure are separate engineering budgets. Typed streaming can bound extraction cost, memory and scheduling without determining whether the complete argument is deployable. Evaluate the terminal proof against the maximum workload before treating front-end compression as an end-to-end proof-system result.