Translator’s note: The 500tps expansion plan proposed by Ethereum founder Vitalik based on the ZK-SNARKs technology triggered more thoughts on the expansion of the blockchain in the community. Since then, Ethereum researchers Barry Whitehat, Alex Gluchowski, Harry R, The snark sidechain scheme jointly proposed by Yondon Fu and Philippe Castonguay claims to allow the Ethereum network to achieve a transaction throughput of 17,000 tps. So what is going on with this scheme? This article attempts to give the answer. Original author: Barry Whitehat, Alex Gluchowski, HarryR, Yondon Fu, Philippe Castonguay I. Overview This article introduces a snark-based side chain scheme, which requires a constant gas for each state transition, which does not depend on the number of transactions included in each transition. This limits the scalability of snark size, which is economically provable, which is different from the previously proposed gasBlockLimit/gasPerTx proposal (Note: Ethereum founder vbuterin's 500tps expansion plan). If there is a malicious operator (in the worst case), the system will degenerate into an on-chain token, and the malicious operator will not be able to steal people's funds. If the data becomes unavailable, the operator can be replaced, we can roll back to the previous valid state (according to the request of the existing user), and then continue the operation of this state through the new operator. Second, the role of the system There are two roles in the system 1. Users who create transactions to update their status; 2. Operators who use snark, they will aggregate these transactions into a single chain status update; They use smart contracts to interact. The system has an item list in the merkle tree, which associates the public key (owner) with the irreplaceable token. The token can be withdrawn, but there is only one chance. 2.1, in the snark transaction The user creates a transaction to update the ownership of the token sent to the operator through the off-chain method. The certificate created by the operator contains: ·Previous state; · Transaction set; Through the newState code, we can verify the proof in the EVM virtual machine. If and only if the proof is valid, the system will update the merkle root; 2.2, priority queue Users can also request a retrieval operation through the smart contract layer. If the operator cannot serve the queue within a given time, we assume that the data is unavailable. As a result, the operator will be punished, and the system will start looking for new operators. It is impossible to take out the same leaf (cotyledon) twice, because each time it is taken out, the system will store the leaves (cotyledons) that have been withdrawn and check all the leaves (cotyledons) that have been withdrawn in the future; 2.3. Operator auction activities If the previous operator has been punished, the system will start searching for a new operator, and this is achieved through auction activities, where users can bid for the operator. After a period of time, the new operator will be selected based on the highest bid (higher than a certain minimum bid) of the latest sidechain status. 2.4, rollback When the operator changes, the system will allow the user to log out. The reason for this is that when a rollback occurs, users can get back their coins in a certain state. The system will sort these withdrawal operations by status, and roll back chain transactions in this status until the new operator continues to be responsible for status updates. Please note that since it is impossible to withdraw the same leaf (cotyledon) twice, the user cannot withdraw from the same leaf (cotyledon) from the old state; 3. Discussion Operators are forced to process requests in the priority queue, otherwise they will be punished. If they refuse to run the system's snark sidechain, they will still be forced to allow the priority queue to exit. Therefore, if the operator is malicious, the system will degenerate into a kind of on-chain token. Users should not accept a transmitted leaf (leaf transaction) unless all chain data is available so that they know that in the worst case (if a rollback occurs), they can become the new operator. The authority to become an operator may exceed that of ordinary users, but as long as there is an honest operator who wants to take over the state, the user's money will be safe. In addition, in the newer state bidding, the bids of these operators have advantages over other bids. However, this allows current operators to continue their re-election because they will know the latest status data and can bid for the latest status. However, we can set a minimum right. If they refuse the priority service again, these operators will be punished again. Therefore, such a system can guarantee that someone will come to process the queue, otherwise the chain will roll back to its original state, and the user can exit when the rollback occurs. Unlike the Plasma structure, which cannot guarantee the validity of all states, this design avoids competitive withdrawals because snark does not allow invalid state transitions. Therefore, we can recover from scenarios with malicious operators without forcing all users to log out (of course, users who want to log out can still log out). 4. Appendix: Calculation of TPS Currently, each signature requires ~500k constraints. Through optimization, we think this can be reduced to 2k constraints; Currently, our hash function (sha256) consumes 50,000 transactions per second. We can replace this with a pedersen commitments scheme that consumes 1k constraints. If we create our own merkle tree 29 layers, the system can hold 536,870,912 leaves. For each transaction, we must: · Confirmation signature = 2k constraints Confirm the old leaf transaction in the tree = 1k * 29 = 29k constraints ·Add a new leaf transaction and recalculate the root = 1k * 29 = 29k constraints This is equivalent to 60k constraints per transaction; The paper written by Wu et al. pointed out that they can prove a snark of 1 billion gates; 1000000000 / 60,000, each snark confirms 16666 transactions; And to verify a snark, you need 500,000 gas, and each block of Ethereum can have 8 million gas. This means that in each block, we can accommodate 16 such snarks; In other words, each block can theoretically hold 16666 * 16 = 266656 transactions; 266656/15 = 17,777 transactions per second; We can achieve higher tps by creating larger clusters; Note: It may be quite expensive to run hardware to achieve this rate, but at the same time, the reward is much smaller than the reward of the current block. Five, community comments fleupold replied: Regarding the exit during the rollback period, I am a little puzzled: "BarryWhiteHat: When the operator changes, the system allows users to log out. The reason for this is that when a rollback occurs, users can get back their coins in a certain state." Does this mean that after a rollback occurs, you can withdraw the coins obtained in a certain block (which is no longer part of the chain) (for example, suppose we roll back to the 42nd block, we can withdraw in 44 Coins obtained in the block)? Assuming that the data of the 44th block is not available, can anyone prove that the exit is valid? barryWhiteHat replied: During the rollback process, you will have the opportunity to withdraw your coins from state 44. If you miss this opportunity, you will lose your coin, and the sender of the coin will regain ownership of it. Once you exit a leaf, the same leaf cannot exit again, even if we roll back to before it was exited; kaibakker replied: I really like the progress of this project. The github code of this project can be found here: https://github.com/barryWhiteHat/roll_up. Let me discuss a question: How do you ensure that an honest person is always ready to become an operator? What kind of fees are meaningful? As an operator, he has to pay a certain cost: · Server cost for snark calculation and data availability; ·Gas cost for verification and withdrawal; The operator can recover these costs in the following ways: · Deposit and withdrawal fees; ·transaction fee; ·Interest without trust (up to 0.5% through PETH or DAI) It is important for a new operator to be profitable, otherwise no one will pay for it. If no one wants to become an operator, the cost can be increased appropriately. Take the current gas price as an example: Suppose an operator wants to update the snark every hour. His annual gas expenditure is approximately 0.50$ × 24 × 356 = 3560 + 812 = 4372 USD. He has to process 50,000 deposits and withdrawal transactions every year. Assuming that the operator only pays 0.1 USD for each withdrawal An additional cost of 5,000 US dollars is required, and the cost of the server needs 4,000 US dollars, and his estimated profit is 5628 US dollars per year. Then his estimated total income will reach 20,000 US dollars, and he needs to charge 0.3 US dollars for each deposit transaction, or 3 times the Ethereum gas fee, so that his business is sustainable. This question may be interesting. barryWhiteHat replied: "What kind of charge is meaningful?" It depends on the purpose. I hope it can be applied to irreplaceable tokens, decentralized media, and a bunch of other applications. We didn't discuss the cost in detail in the article. If you want to charge a fee per transaction, you can use a deposit fee or a withdrawal fee (of course, the priority queue is not included, which means that your withdrawal fee must be lower than the priority queue fee to prevent fees from avoiding problems) , You may need to use technologies such as plasma debit. At the moment, I don't know which method makes the most sense. I would like to see some full use cases. "How do you ensure that an honest person is always ready to become an operator?" They don’t need to be honest, we just need someone to come forward, and the best way seems to be to pay them. Of course, this also depends on the use case. MihailoBjelic: @barryWhiteHat pays tribute to your previous and current work! "BarryWhiteHat: The system has an item list in the merkle tree, which associates the public key (owner) with an irreplaceable token." It can be said, why the whole design is based on NFT, do you think it is also effective for the public key-balance model (of course there will be some modifications)? barryWhiteHat: The Balance model is tricky, because you can take out the same balance twice by moving the balance from one leaf to another leaf. We can try and establish a plasma debit to increase the adjustable balance (Balance). But this requires us to think more. MihailoBjelic: Sorry, I did not understand what you said. How can you transfer your balance to another leaf? Don't you only have one leaf representing your account (and its balance)? Perhaps your idea is to use SMT? If you have time, please check @jieyilong's post: Off-chain Plasma state verification through smart contracts on the chain (you can only read the "Plasma state construction" and "Probabilistic Plasma state verification"). I'm thinking about something similar, but using SNARK instead of random sampling? barryWhiteHat: Not sure if we are on the same channel. This is my answer, I hope it can answer your question. "How can you transfer your balance to another leaf? Don't you only have one leaf representing your account (and its balance)?" If you cannot move the balance between the leaves, then you have no account balance, because the balance will never change. If you can't move the balance between the leaves (excluding the plasma debit), then all you have is an input-output model. "I'm thinking about something similar, but using SNARK instead of random sampling?" I took a quick look. If you want to verify the integrity of the entire merkle tree, why not verify every transaction? Proving a large Merkel tree requires a lot of hashes, which is quite expensive. Shenzhen Kaixuanye Technology Co., Ltd. , https://www.icoilne.com