Why Cairo/STARKs for Ztarknet and STARK_VERIFY_TZE

Fantastic, thanks for the links! Running the latest locally (`b632a3ec889d3e31de511d731d53add7ea7560d9`), I see proof.json is 8.2MB, but very sparse. proof_rec.json brings it down to 2.4MB, and proof_rec_rec (packed in a different structure?) to 848KB, then bzipped to 717KB (proof_rec_rec.bz). Are there paths to reducing this further?

I also saw GitHub - Ztarknet/quickstart: Tutorial: deploy privacy preserving application on Ztarknet – if ZK applications rely on ECC‑based SNARKs aggregated in Stwo proofs, and users interact on the aggregated application (i.e. the Circle STARK isn’t hiding anything because the activity inside is public over some other channel), aren’t those applications vulnerable (integrity) to quantum adversaries? (Edit: UltraHonk appears to be secure against store-now-decrypt-later quantum adversaries? So the issue for long-running applications is similar to ZEC’s Orchard pool – needs a commitment strategy for a PQ upgrade path.)

1 Like