hi @vitalik.eth — I am genuinely interested in your thoughts on the nomenclature here if you can spare a few mins

seems there are a ton of disagreements on all dimensions and it would be helpful imo

hi @vitalik.eth — I am genuinely interested in your thoughts on the nomenclature here if you can spare a few mins

seems there are a ton of disagreements on all dimensions and it would be helpful imo

https://x.com/0xMert_/status/1804244166584516865

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.

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

Mert is "modularity's man in monolithic Kremlin"