mert
@0xmert
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
3 replies
10 recasts
83 reactions
Vitalik Buterin
@vitalik.eth
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.
6 replies
7 recasts
94 reactions
Ajit Tripathi
@chainyoda
Mert is "modularity's man in monolithic Kremlin"
2 replies
1 recast
5 reactions
TheModestThief🎩
@thief
444 $degen lmfao
0 reply
0 recast
0 reaction
✿ Gil Alter ✿
@gilalter.eth
I'd really like to understand this but it's going above my head. Can you explain it to me like im, idk, 15?
0 reply
0 recast
0 reaction
