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
126 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
154 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
38 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)
1 reply
1 recast
4 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
alex eth/acc
@alexhook.eth
“128 bytes” makes me assume that they're using verkle/KZG rather than anything else
0 reply
0 recast
0 reaction
Ismeth
@ism.eth
I believe it will be only useful for hibernating accounts for later rehydration. (to cut state rent) Every other use case seems to be quite expensive.
0 reply
0 recast
0 reaction
