what are your thoughts on zk compression in solana?

what are your thoughts on zk compression in solana?

https://www.zkcompression.com/learn/core-concepts

I’m trying to find more details about the trusted setup for the circuits. I see how they work (groth16), but can't find any info about the actual setup process they used to secure it.

BDFL of Quilibrium, Eng @ Farcaster, ex-Coinbase, always opinionated, never hydrated

/quilibrium

ceo @ helius.dev, host @ lightspeed, ex coinbase — wartime shitposter

So my current understanding of the scheme (from reading https://www.zkcompression.com/learn/core-concepts):

1. You have a new class of accounts. For these accounts, only the hash of their state is stored onchain.
2. To interact with these accounts, you make a tx which specifies the pre-state-hashes of those N accounts and the post-state-hashes and provides a validity proof (which I assume means a ZK-SNARK)
3. The new state is required to be public (which is reasonable; otherwise you can send someone a random amount of money and their account will become inaccessible to them, you can get around this by making it a utxo system but that would be a significant limitation)
4. QUESTION: the docs say 128 Bytes for the validity proof. What proof scheme is this?
5. QUESTION: do the contents of a transaction have to be made public, or just the state delta?

I guess this feels to me like a stateless client architecture more than anything else.

according to Vitalik the architecture is more similar to stateless validation than a rollup

also, they likely went Groth16 due to succinctness but how would they deal with the upgrades if they have to?

according to Vitalik the architecture is more similar to stateless validation than a rollup

also, they likely went Groth16 due to succinctness but how would they deal with the upgrades if they have to?

https://warpcast.com/vitalik.eth/0xf986f71e