@StopAndDecrypt：
Any Bitcoin enthusiasts out there to explain zkrollup?
I don't expect ethereum developers to be honest about the tradeoffs, nor do i expect ethereum fans to actually understand how it works.
(this is a serious question)
@SomsenRuben：
In Bitcoin terms, this is a large block scheme - everyone downloads additional data. Before the transaction enters the block, an intermediary uses a SNARK proof to aggregate/compress all the witness data (witness, such as signature) (the current SNARK needs to use the trusted startup setting), and publishes the UTXO set commitment of the new state ( It is also proved by the above SNARK evidence).
Everyone verifies this SNARK, proving the validity of the block and the correctness of the UTXO set commitment. No one has to generate a UTXO set, because SNARK has proved that if you want, you can generate it. If that middleman is missing, you can spend your funds simply by proving your state using the UTXO set commitment.
In short, the advantage is that you can save witness data and computation (both outsourced to SNARK proofs). zkrollup just applies what we have always known that SNARK can do. The only difference may be that it is used on a single UTXO set.
See also my SNARK article: SNARKs and the Future of Blockchains. (Translator's Note: Attached below. It clearly explains what SNARK can do, and why zkrollup publishes transaction data without witness data.)
second rule(very long, please be patient):
(Omit the two people's discussion on whether the rise of the second-tier network will reduce the demand for the first-tier block space)
@AdrianoFeria：
Sidechains cannot provide the same level of security as L1. Statechain is not completely trustless. I haven't researched Chaumian banks yet.
@bergealex4：
(Sidechain) Of course not, it never said it could.
You cannot replicate the security of L1 across layers.
@AdrianoFeria：
"You can't replicate L1 security across layers."
This is what ZK-Rollup can do.
@bergealex4：
Well, even if we accept this premise, this alone does not make ETH better than BTC.
@AdrianoFeria：
Based on this alone, Ethereum has a scaling mechanism that preserves the security of L1 without the overhead of opening/closing channels or the data availability risks inherent in the Lightning Network.
We can't rely on Twitter to discuss which system is better overall.
In any case, zk-rollup is a big step forward and offers much greater benefits than payment channels.
@SomsenRuben：
ZK-rollup and payment channels are orthogonal. zk-rollups are like extension blocks - non-witness data is put on-chain and verified by everyone (via SNARKs, cheaply). I can understand why you guys call it "L2", but technically it's not. It just does non-interactive witness data aggregation (NIWA). See my article "SNARKs and the Future of Blockchain".
@AdrianoFeria：
It's an L2 because the computation of the SNARK is delegated to another network. L1 is only used to store proofs, and it turns out that it improves the throughput of L1 by about 100 times. From what I understand, it's equivalent to lossless compression.
@SomsenRuben：
"L2" is just a label. The key is that we agree with what SNARK does in this process - non-interactive witness data aggregation, which can also be used on the main chain (that is, it is completely used on L1, and the miners do NIWA), or used on the chain in the chain (Just like zk-rollup, but it's just "enlarged blocks").
In the Bitcoin network, the witness data only accounts for 50% of the block (unlike Ethereum), so you can only get a maximum of 2 times the efficiency improvement (from the perspective of block space), and this is assuming perfect SNARK technology; this expansion effect is very general. Even with it, payment channels are clearly beneficial.
@AdrianoFeria：
Is it impossible to run the payment channel on the basis of rollup?
@SomsenRuben：
Of course you can, that's why I said they are not of the same dimension.
(slightly)
@AdrianoFeria：
Is it possible to assert that it (zk-rollup) increases L1 throughput at the cost of additional computation (in the case of Ethereum, verifiers cannot do this due to current specification requirements)? And, even if the provider of the evidence crashes, the funds can still be retrieved.
@SomsenRuben：
The NIWA concept presented in my article explains this intuition. Anyone can collect all witness data (including signatures, data that proves the legitimacy of the transaction) and compress/aggregate into a SNARK proof. All it takes is a little more for someone to benefit everyone.
Funds can always be retrieved, and providers of evidence can always be replaced.
@AdrianoFeria：
I understand this, but ideally, SNARK computation should be provided as a service by a decentralized network. That's what's happening in the Ethereum ecosystem, and I don't see why something like that wouldn't be desirable for Bitcoin.
@SomsenRuben：
It always has merit, but you're overestimating its benefits (scaling is only 2x at most) and underestimating its costs (its math is untested, it's inefficient without using trusted boot settings) , and centralization of miners).
I do believe that one day SNARKs will mature and make sense, but it's not there yet.
@AdrianoFeria：
The general consensus is that zkrollup scales 100x better on Ethereum (this information is consistent across multiple sources).
Why doesn't it have the same effect on Bitcoin?
@SomsenRuben：
Two reasons I can think of:
Compared with Bitcoin, the witness data in Ethereum is much larger and more expensive to verify - so SNARK can better alleviate the inefficiency of Ethereum.
Address reuse further reduces non-witness data—a privacy sacrifice that is unlikely to be acceptable for Bitcoin.
My claim is easy to reason about:
SNARK can only reduce witness data
Bitcoin's witness data accounts for about 50% of the block
As long as you understand these, you don't need to "believe I'm an expert", but 100 times, it's really hard to reason.
@AdrianoFeria：
I don't see anyone challenging this 100x claim anywhere. I'm assuming that the technical design of zkrollup might be slightly different than your bitcoin example, and/or have something to do with UTXO or bitcoin script limitations.
@SomsenRuben：
I wouldn't be that quick to start assuming. "Don't trust, verify yourself".
In general, I would also advise against defending a claim unless you have very strong conviction. Be humble, http://www.paulgraham.com/identity.html
@AdrianoFeria：
So I also welcome technical challenges to this statement. Based on the fact that it has been cited by many notable developers, is widely circulated, and has not been challenged, it is reasonable to favor this statement. Rollup is almost integrated, and the proof is in sight.
You need to be pragmatic about this "don't trust, verify for yourself" mantra. There are reasons to believe in something, rather than verifying everything yourself. for example:
Trust SHA-256 to work well
Trust in Public Key Cryptography
Creating binaries for the client doesn't necessarily mean the compiler is valid
@SomsenRuben：
I just gave a proof that you (should) be able to verify that Bitcoin cannot be expanded more than twice by SNARK.
Viewed in this light, the claim that Ethereum can achieve 100x scaling is at least initially suspect.
If this isn't called "validation" then I don't know what is.
@AdrianoFeria：
I haven't been able to fully digest this, but this article looks like a completely different situation than what you describe with Bitcoin. Do you have any comments? https://medium.com/interdax/ethereum-l2-optimistic-and-zk-rollups-dffa58870c93
@SomsenRuben：
There are many expansion schemes listed in the article, but as far as I know, except for zk-rollup, other schemes have been abandoned by the Ethereum community.
But in comparison, I understand Bitcoin better. If you have any questions about my articles, I'd be happy to answer them. This will also indirectly help you understand Ethereum.
@AdrianoFeria：
Vitalik just published this article, I haven't had time to read it, but it seems to explain a lot of technical design details, and the details of how much data can be compressed for various types of transactions. "The Incomplete Guide to Rollup》
@SomsenRuben：
good article. So both of my reasons are correct, but now I understand better how this 100 times came about. In Ethereum, both space and calculation consume gas, but the gas cost of the former is lower. Because SNARK reduces the calculation amount to close to 0, all gas can be used to publish data. What are the disadvantages? Blocks get bigger.
@AdrianoFeria：
Blocks are getting bigger, but this is the most efficient use of storage space I know of.
In addition, this article also proves that a common transaction can save 10 times the space. So, this shows that rollup has a 5 times efficiency advantage over the situation you describe with Bitcoin. This is not small.
@SomsenRuben：
You forgot the second cost, address reuse, which is a serious privacy downgrade. You can also introduce such a reverse upgrade for Bitcoin to save block space, it has been proposed before, but it was rejected for good reason.
@AdrianoFeria：
I don't see how address reuse is a rollup-specific problem that can be mitigated by specially designed privacy-enhancing smart contracts. Moreover, can't the wallet use a new address every time it receives cash, simulating the privacy of UTXO?
@SomsenRuben：
The key is that address reuse is their way to reduce transaction size. If you use a new address (and change address) for every transaction, the transaction size of zk-rollup will be much larger.
(There are other side discussions in this discussion, which are not attached here)
(Translator's Note: I don't know if readers still remember how the expansion effect of zk-rollup was demonstrated. Simply put, it assumes that an ordinary transaction on the main chain consumes X units of gas, while in zk-rollup Rollup only needs to consume Y units of gas, so the expansion effect is X/Y. In other words, all arguments are based on the gas pricing of different operations on Ethereum, but gas is not a real resource, it is just a The virtual unit assumes that the cost of different resources can be reduced to an index. If you double the gas price of calldata now, the expansion effect of zk-rollup can be doubled (EIP-4488 and 4490exactly what it means). Isn't this a bit of a joke? On the contrary, Somsen's demonstration of SNARK's expansion effect is closer to the original face of the technology, which is to save witness data (and ideally, save verification calculation).
This articleThis article). Adriano's so-called method of simulating UTXO and using a new address every time is not impossible, but it is not a good practice in the world of Ethereum, because all historical addresses will remain in the state and become a burden on nodes. This is The so-called state explosion problem.
first level title
SNARKs and the Future of Blockchain
By Ruben Somsen
Source: https://medium.com/@RubenSomsen/snarks-and-the-future-of-blockchains-55b82012452b
SNARK (succinct non-interactive argument of knowledge, succinct non-interactive proof of knowledge) is often considered a panacea to "solve" the expansion problem. Although SNARKs can provide unimaginable benefits, we also need to know that SNARKs cannot solve the bandwidth constraints that blockchains currently face.
This article hopes to demystify SNARKs by providing a (relatively) brief overview of what SNRAKs can and cannot do for blockchains. We’ll start by talking about why its blockchain-related functionality can be succinctly summarized as “Non-Interactive Witness Compression (NIWA)”. As long as you know how Bitcoin works, you can understand this article.
first level title
What are SNARKs?
secondary title
chess case
- Rules: Chess Rules
- Starting state: the starting position A of the board
- Result: new position B of the board
The traditional way of proving that a game transition from position A to position B is valid is to expose each step and check that each step is valid. SNARKs can also be used to check the validity of state transitions, but better:
- Steps don't have to be public (privacy, data saving)
- Validation is computationally more efficient
secondary title
Blockchain case
- Rules: Full Node Software
- Starting state: block header and UXTO set hash value at time point A
- Result: block header and UTXO set at time point B
Similar to the chess we mentioned above, the normal way to verify the validity of state transitions is: start from the UTXO set at point A (all unspent transactions), receive all blocks up to point B and update the UTXO set. With SNARKs, there is no need for such data to prove validity. In fact, if time point A is set to the genesis block (empty UTXO set), and time point B is set to the present, then the entire chain can be verified without receiving any historical data.
The important thing is that you need the entire UTXO collection of point B, and you only need to know the hash value of the UTXO collection for point A. While this data is not strictly necessary to demonstrate validity, we are also concerned with availability. If you can always only get the hash value of the UTXO set, then even if you know that a valid state exists, you can't know what that state is. That means you can't spend any funds because you have no data to prove that a UTXO belongs to the current set. If you use the chess analogy, you know the hash value of a new situation, but you don't know what the situation is like, so you can't continue to play the game.
first level title
SNARK blockchain
In order to guarantee that everyone will spend their money, all data required to update the UTXO set must be propagated with each block. You still need to know which UTXOs are spent (ie input) and which UTXOs are newly generated (output). This is called "non-witness data".
The validity of state transitions can be verified by a SNARK, so SNARK can replace all witness data (scripts, signatures) and consume almost no bandwidth. The link between inputs and outputs will be erased - a block will look like one big coinjoin transaction. Most of the data is non-witness data.
So, contrary to popular imagination, SNARKs cannot solve the fundamental problem behind light clients or non-confederation sidechains, because you have to download non-witness data. Full nodes have the ability to reject a valid SNARK if non-witness data is lost; but if a light client neglects to download non-witness data, it may mistakenly believe that a data-lost chain is valid. Even if a small piece of non-witness data is withheld by a miner, no one else can create new blocks on a valid SNARK - eventually it becomes a permissioned system.
SNARK consumes witness data
Perhaps the best summary of SNARKs for blockchains is that they enable one feature: non-interactive witness aggregation (NIWA).
I use the word "witness" here quite loosely. In Bitcoin, witness data is the data placed in the transaction to prove whether a specific UTXO can be legally created. But as time goes by, this UTXO (non-witness data) will also become its own witness data when it is spent. Assuming that 1 btc is transferred from Alice to Bob and then to Carol, Bob's transaction is the witness data of the transfer from Alice to Carol. Similarly, all payment transactions since the genesis block are the witness data of the current UTXO set.
brief summary
brief summary
We have summarized the core functions provided by SNARKs for blockchains with the concept of NIWA. Any witness data can be non-interactively aggregated together by a SNARK. The remaining non-witness data is a direct reflection of the system state (UTXO collection). Although SNARK can achieve some magical functions, such as directly downloading a UTXO set and a SNARK to jump from the creation state to the latest state, and non-interactively aggregating the sequence of unlinked transactions into a single transaction, we still need to provide Every new block publishes all non-witness data so that all full nodes can update their UTXO sets. Therefore, SNARKs cannot solve the fundamental bandwidth constraints faced by blockchains.
image description
- NIWA in action. SNARK consumes witnesses, but it is also a witness itself. So SNARKs can swallow SNARKs -
