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
2 replies
13 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.
3 replies
14 recasts
133 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.
0 reply
4 recasts
34 reactions
swen
@swen-sjn
The Solana protocol currently has a flat base fee irrespective of the compute used by the TX, but it charges a flat upfront bond per regular account creation that makes it 'rent-exempt'. The price arbitrage is causing these large multiples. That said, if blocks are full, users will have to pay relatively higher priorityFees compared to more lightweight TXs, given that those are prioritized based on (priorityFee/compute)
0 reply
1 recast
4 reactions
0x2a
@0x2a
What use case/scenario do you anticipate this compression to be used? (gaming?DeFI?DePIN?)
0 reply
0 recast
0 reaction
