Point compression for SRS

[ledwards2225]

We can halve the size of the SRS download by using the standard point compression technique of storing (x, sign_bit) instead of (x,y). This may have nontrivial decompression costs given the size of our SRS but (a) maybe it's acceptable if we can hide it in some init stage and (b) maybe there's an algorithm where we can speed up decompression by storing "hints" for computing the square roots at the expense of slightly worse compression.

[johnathan79717]

If this reduces the download time, it might compensate the decompression costs.

[johnathan79717]

WASM decompression benchmark results

Benchmarked realistic WASM decompression times (single-threaded):

SRS Size	Decompress Time	Uncompressed Baseline
2^17 (128K pts, 4MB)	2.22s	0.05s
2^18 (256K pts, 8MB)	4.39s	0.08s
2^19 (512K pts, 16MB)	9.72s	0.15s
2^20 (1M pts, 32MB)	18.78s	0.31s

The decompression overhead is too slow for client apps — a browser user on a decent connection downloads 64MB uncompressed in ~2s, but decompressing 32MB of compressed points takes ~19s in WASM. This rules out compressed CRS for browser/WASM use cases.

We can still evaluate whether this is useful for release image size reduction (native C++ decompression is fast: ~48ms with 32 threads).

PR: AztecProtocol/aztec-packages#21112

[johnathan79717]

@charlielye Do we think this would be useful just for reducing the size of the release image? Or is that not a concern?

[johnathan79717]

Quoting @alexghr: "on the server side, we need ~2GB of the CRS for proving and provers run 32 core machines. If we could compress the CRS to shave off 1GB from the image size that would be great"

[johnathan79717]

Fixed by AztecProtocol/aztec-packages#21112