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
8 recasts
61 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.
5 replies
4 recasts
155 reactions
mert
@0xmert
thanks for the reply! will just bump the response from the founder of Light for the questions: https://warpcast.com/swen-sjn/0xa6ac8750
1 reply
1 recast
6 reactions
K3🫵👁️
@keith33333.eth
sounds like tech gibberish to me. lmao!! devs are amazing tho. smart as fuck but honestly what do you need this for?
0 reply
0 recast
0 reaction
