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
120 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
14 recasts
94 reactions
Vitalik Buterin
@vitalik.eth
What confuses me is, how does this achieve anything like the numbers you're claiming??? It feels like if you're doing it separately per-tx, the overhead of verifying a SNARK would be *higher* than the cost of doing a few bit-twiddling and hashing operations (which is what eg. token transfers are). The gains of ZK rollups come from having *one* SNARK wrapping *many* transactions.
4 replies
3 recasts
33 reactions
K3🫵👁️
@keith33333.eth
this all sounds like BS to be honest. why do you need all this in the first place? what value does it give? they need to work on stability and reliability before all this BS. lmao!! what do i know!
0 reply
0 recast
0 reaction