L2 Future - Session 1

# L2 Future - Session 1 ### "Starting with L2s" Fri. Nov. 13, 2020 4pm CET - 6pm CET [Airmeet link](https://www.airmeet.com/e/f7234320-1930-11eb-9211-9535c027e26b) Subsequently: [Notes from Session 1](https://hackmd.io/NKIQcAHuRmqWkOno64jgkA?view) --- ## Proposed schedule 4pm CET: **Welcome** **~ 4:10pm CET**: Beginner's introduction to ZK Rollups, optimistic rollups, and why these are the most likely path to a scalable Ethereum ecosystem. **~ 4:45pm CET**: Review of practical options that are (or will soon be) available. **~ 5:20pm CET**: Work session / discussion for needs-finding, identifying blockers for deployment and adoption, creating a basic agenda for the next two L2 Future sessions. --- ## Background reading [ZK Rollup: Making Scalable Blockchains Possible](https://medium.com/ppio/zk-rollup-making-scalable-blockchains-possible-7308b695d929) by Xin Jiang [Ethereum Smart Contracts in L2: Optimistic Rollups](https://medium.com/plasma-group/ethereum-smart-contracts-in-l2-optimistic-rollup-2c1cef2ec537) by Karl Floersch EthHub overview, UX implications, pros/cons: - [Optimistic Rollups](https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/optimistic_rollups/) - [ZK Rollups](https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/zk-rollups/) [Optimistic vs. ZK Rollup: Deep Dive](https://medium.com/matter-labs/optimistic-vs-zk-rollup-deep-dive-ea141e71e075) by Alex Glukovski [a rollup-centric ethereum roadmap](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) by Vitalik Buterin --- ## Presentation Notes **Brecht Devos from Loopring** People enter a smart contract, they deposit. They want to exit, they can withdraw their funds. Once funds are in the smart contract, additional rules can be enforced. They are in their own separate chain. Funds are locked until they exit from the L2. The basic idea of the rollup is that they bundle many many transactions together. You submit them to a block. You only do the minimal stuff on chain. You have the block, you store the state, a single root. Then all the transactions that are executed would only change the single root variable. This is the latest state of this "side chain". One of the things differet in Plasma: you put all the data on-chain that is needed to reconstruct this single committed root. This is where the on-chain costs are many times lower. You only update one storage root. You don't execute all of the transactions inside of the block. This is where there is a difference between ZK and optimistic rollup. ZK rollup actually proves that all of the transactions within the block are valid, and you submit that block through the rollup smart contract. For optimistic rollup you don't do that, so there is a problem there because the smart contract does not know that the block is actually valid, and if all these transactions were executed correctly, and if the new state is correctly updated in this root variable. This is solved by a fraud proof. Optimistically all of these blocks are accepted on-chain. People need to monitor the chain, if they detect an invalid state transition. They need to submit a fraud proof. The rollup chain would then be updated to the last valid state, was certainly valid. That is a big problem for ORU. This is less efficient, or less clean than ZKRU where you always know that the state transition was correctly updated. You know if it is immediately the case. With ORU you need to wait for the fraud proof to be submitted and to be able to do that, it takes a long time before it can be made sure that the block is valid. One of the important things is that how the state root is managed inside of the rollup. In Loopring's case it is the same was as Ethereum stored the state, but a different format. It is still a Merkle tree, optimized for our specific use case. If you execute a transaction, the operator submitting the proof can prove that certain data is available in the Merkle tree by using a Merkle proof. If someone whats to prove that they have 1 ETH, there is a valid Merkle path from this Merkle tree to this root, from this account to this Merkle root. WHich is this value stored on-chain. That is the high overview. This rollup part is the data not posted to L1 chain. If you post the data on-chain, and have a validity proof, this is a ZK plasma. If you have an ORU, you post the data, and you don't have the proof, and you depend on fraud proofs. If you have a ZK rollup, that is where you put the data on-chain, you post a proof, which brings you to very fast finality, and in a way that you expect on-chain stuff to work. One of the major problems with ORUs is long finalization times. You have to wait on the fraud proof to be submitted. The time needed to wait on a fraud proof is 1-2 weeks, if you want to exit from the ORU rollup, 1-2 weeks for the withdrawal to go though. This is a big problem for capital efficiency. So if you have lots of funds inside of your rollup then well it makes it very hard to move capital around. There's a couple of things there that could solves this a little bit. State channels, makes it possible to move funds out of the ORU. Still not capital efficient, needs these extra funds that are available. For stuff like AMMS which contain a lot of funds this is a big problem. One of the things we will ship at Loopring is also AMM support, using the Balancer curve. If you were on ORU it would be a pretty inefficient way. For Plasma the data is simply not available on chain so if you want to exit you need to do it quickly. For ORU the data is on chain, so there is no problem in that regard. Jamie: is the user responsible for maintaining the data. Brecht: Yes I think so. You need to exit quickly enough, you have a limited time to exit. **Alex Glukovski from Matter Labs** Alex: I would go as far as to say that we only have rollups as viable solutions on Ethereum because rollups and sidechains are the only solutions which allow arbitrary smart contracts. With state channels you can only do very very limited smart contracts between two parties and you maintain some state transitions within them but you cannot interact Ethereum-style with any contract. With Plasma you theoretically could have built a system with smart contracts like on Ethereum, but you would have to work around this exit problem where the data is not available. And that's a really really hard problem specifically with regard to smart contracts. You might still mitigate this with individual user accounts where you would have mass exit problem with Brecht spoke about. It is really problematic with lots of users like millions of users all of them should be able to exit from Plasma into layer one within a period of one week, which might simply not wotk with Etheruem because the network itself is congested. With smart contracts it gets much worse because you need to plan for these exit scenarios. Contracts have to be audited for both contract functionality and the exit functonality, which is entirely different. And you need to build specialized exit predicates and it gets very complex. It is really not a viable solution if you want to scale your dapp or protocol in a way which keeps the usability and these movements of Ether. You really only have the option of either rollups where you just have the same exoerience, or side chains. But side chains are not Layer 2 solutions, because as you previously correctly explained, Layer 2 securty is rooted in Ethereum security, rooted in the security of Layer 1. Side chains it is always an external source of security. Also it depends on a couple of parameters if you have a side chain and you bridge some assets from Ethereum onto the side chain then your weakest link in the system is the bridge. So the side chain itself might be more or less secure but the bridge is the part which is essentially just a multisig. If you compromise more than half or 2/3 of participants in this multisig you can steal all of the assets which have been bridged over to that chain. It is not in the spirit of crypto and not in the spirit of Ethereum, so I agree with Viktalik Buterin that roll-ups are the way to scaling. When we talk about rollups, we only have two flavors, two fundamental differences, which Brecht did a good job describing, optimistic and ZK rollups, the direct highlight of the technical differences. I would like to focus on the practical differences. What it means from the point of view of developers and implementers. So Brecht do you mind switching off your screen share because we can only get one. Thank you. You should see my screen now. There are some questions in chat which we will address later, let me just finish this presentation. I tried to succintly present the differences between optimistic and XK rollup approaches. This is the succinct, comprehensive version of what is really different. The biggest and most impactful difference is that ORU reply on a series of assumptions about security which practically limit the amount of funds which you can place in a single instance of an optimistic call, whereas with ZK rollups, they rely on purely mathematical or cryptographic assumptions. If the crypto is right, the basic primitives and crypto assumptions, and the implementation of the protocol is correct, then ZK rollups give you exactly the same security guarantes as L1. You are guaranteed that if you put your money in a ZK rollupand you put your money in some simple smart contract like wrapped ETH and you have exactly the same situation with both of these cases. You can go and not have to do any work, come back after a definite period of time and get your funds back, which is not the case with optimistic rollups. With optimistic rollups you have some risks. Now the first big assumptions or ORU is that you have 1 of N of honest operators, or validators, or observers, like there is someone who executes all of the transactions in the optimistic rollup and checks that they are not fraudulent. If they find fraud, they send it into the fraud proof. This can theoretically be users, but the users are not incentivized to do this, so these are more likely going to be validators. So you want to have a lot of validators who have skin in the game, who monitor the system, and they get slashed if they misbehave. And you can kind of reasonably assume that with a large enough set of participants, one of them should be honest. So this is kind of an acceptable assumption. Then if one of them is honest and the service is fine then they will be able to spot the transaction. Of course there is also a problem with this part: they might be honest but maybe their servers are compromised? Or maybe their DevOps team is compromised and adre not ptotecting the service properly, the software just shuts down and nobody knows whether the monitoring is going on or not, if there is no onging fraud. So if the system is silent, you don't know whether it is silent because noting happened, or because you software just did not notice these things. So we have to remember the latest incident with MakerDAO Black Thursday that was exactly the situation. There were not going right on the main chain but the software which was supposed to intervene and make collateral trades just did not work properly because the bidding mechanism was not adjusted for higher gas prices and MakerDAO almost collapsed on that day. Luckily people intervened, they saw the problem and they could do something about it. With an optimistic collapse it might be trickier, but that is still in the realm of manageable risk. https://forum.makerdao.com/t/black-thursday-response-thread/1433 https://insights.glassnode.com/what-really-happened-to-makerdao/ https://www.buildblockchain.tech/newsletter/issues/no-88-how-makerdao-survived-black-thursday So you can say that you have a lot of independent implementations of ORU in terms of software, and validators run it on different servers, maybe some hidden servers nobody knows where they are, it is hard to compromise all of them. At least one fo them should be honest. Ok, we can accept that. But then they also have a job to deliver the fraud proof to Ethereum within one or two weeks. Probably going to be one week, otherwise usabiluty will be very bad. They must be able to mine the fraud proof transaction within one week on Ethereum and this is where things get really problematic. You can always initiate an attack on the fraud proofs from the side of Ethereum miners. It is possible to rent external hash power and run a 51% attack on Ethereum for one week and prevent the fraud proof from being mined into the optimistic contract. And the cost of this attack is not very high. It is something like 20-30 million USD, because the actual cost is 40 million to maintain the attack, but then you would collect all of the block rewards and all the fees from all of the blocks instead of normal miners. You override their blocks so you kind of compensate half of that cost. But this is brute force. In practice you don't have to run it for one week. What you do as an attacker is tou initiate this attack and then you communicate to all of the other miners and tell them: Look guys, either you cooperate with me and you also start censoring this particular ORU or I'm going to override your blocks. But whoever cooperates with me, I'm going to send you some tokens wich represents the proceeds from this attack. Because the attack can be channeled into some smart contract which is tokenized. People can start trading this contract's tokens on Uniswap. The practical cost is much lower than 30 million. Of course you have some risks executing such an attack. But if you put a lot of money in a single instance of an ORU, it is really straightforward to run this attack and just grab all of the funds from the rollup. That means that your security assumptions carefully managed are only valid as your contract is under 50 million USD or some amount, it is hard to quantify exactly, but let's say 50 million USD. This could be mitigated once Ethereum moves to PoS, Then you could say as a community we agree that if there is censorship behavior, then we consider this anti-social and we slash the value of those who do this. But this is probably still a couple of years away. So long as Ethereum remains PoW this cannot be mitigated and your best strategy is not to put a lot of money in a single instance, which is not the problem of ZK of course. So this is the most important difference. ORU can be used to scale individual applications, or maybe some smaller group of applications, but you cannot have this one big composable contract w/ a lot of value. The second difference is what Brecht already hinted at, is that to move funds from an ORU to mainnet it takes 1 or 2 weeks because that is your finality time, the delay period to grant anyone time to submit fraud proofs, whereas with ZK rollups the time is only a couple of minutes, necessary to construct the validator proof, the ZK proof, to validate the funds and transactions. This is a slightly less severe problem, because for small amounts in liquid tokens, you can accelerate the exit by the use of external liquidity providers. Develop a lot of liquidity which can be borrowed from someone, use this money on L1, sell them the exits in your ORU and you just paid the cost of capital parked for one week, which is quite substantial, exits will cost a percentage of the value, which is not nice. Usually in Ethereum we pay a fixed fee, not a percentage. This could mitigate this problem somehow. This cannot be mitigated for NFTs. If you were to move an NFT out of an ORU, you would have to wait 1-2 weeks, there's no way you could make it faster. This cannot be mitigated for non-liquid tokens, it would be hard to find LPs for that. It would probably be very hard to move large amounts of capital. If you want to split your protocol between L1 and L2, something like Curve or Balancer, you want to build a system which is a hybrid which balances liquidity, if you move funds over to L2, you can move your assets back, for this order of magnitude of 100Ms of USD or Billions of USD, you cannot mitigate this, you still have to wait one week. With ZK rollups it would be just a couple of minutes. The final difference is that certain operations which have large inputs on call data would be quite expensive on ORU, they won't have any scaling effect, they would cost the same as what we have now on Ethereum. With ZK rollups they can cost almost nothing. It will be very cheap to build privacy-preserving protocols on ZK rollups. These are three big differences. So why are people signing up for ORU this year? ORU promise a much easier way to port existing smart contracts, thereas for ZK rollups this was not clear, how to do this, is this possible at all, will it be efficient? Do we have ZK proof generation costs that have a cost-prohibitive factor that will make porting EVM contracts not possible? These were reasonable concerns. We now have quite some progress with ZK proof research this year, I am happy to announce that it will be possible to port existing solidity and vyper contracts to ZK rollups. It will be possible to do practically w/ no code changes. For most contracts, definitely for most DeFi protocols, there will be no changes required. On the client-side, there will only be minimal hanges required. For example with Curve we only have to change a couple of lines of code on the front-end of Curve, and I just worked. The contracts we had to rewrite the smart contracts which were in vyper, we wrote them in Zinc. In the near-term it will be possible to automatically confer that. ORU will be easier for some contracts, there will be some which will just work out of box. These would require some re-works for ZK rollups, the ease of use of ORU will be somewhat ahead there. For most contracts it will work with ZK rollups just the same. Jamie: I get the impression that ZK rollups have significant advantages, but the reality is that ORUs will be a big part of this scene. The developer will have to evaluate what is best for their users and for themselves as they make these choices. What we could do next is take on some of these questions. ## Questions asked during the introductions Dmitry: Alex, what about service availability guaranties in zkRollaps? > Samuel: zksync has a [mass exit / exodus mode](https://github.com/matter-labs/zksync/blob/0826f71211cc77af11a32a45933d43095730f35a/docs/contract.md#cenosorship-resistance) functionality @dimitry --- Hadrien: please, could you share the slides afterwards. I'd love to show that to coworkers --- Dmitry: what is the service operator goes offline? Is there any scheme to make the role of zkOperator permissionless, i.e. anyone could become an operator if the old one is disappears? --- Hadrien: what if someone updates the zk chain with a "private operation", but does not disclose the proof for that particular operation. --- Hadrien: Is is possible for the mainnet contract to verofy the proof for a "state" that other actors cannot reconstruct, thus preventing any further update to the zk chain ? --- Fengkie: Why does most zkrollups implementation are mostly need developers to develop in new language and toolings instead of providing similar toolings to eth l1 (use solidity/vyper, truffle-like framework, etc)? > Hadrien: My understanding was that protecting against this requiered all zk operation to be published on eth calldata BEFORE being processed by the zk chain, which as a cost :/ > Jamie summarizing Alex: early implementations could not have turing complete languages, now breakthroughs in the prover technology now make it possible to have turing complete comtracts > Jamie summarizing Alex: some it was initiatives to improve on Soldity, it was not clear that Solidity had a long-term future > Brecht: thinks zkSync's language is better than Solidity, "nicer language", but if you want to reuse code Solidity is better --- Fengkie: I wonder what's the planned source of revenue for the projects those are developing rollups solutions so they can keep maintaining and provide support in the long term? --- Daniel: How do Optimistic vs ZK compare in transaction fees? Or is that depending on the particular implementation? > Jamie summarizing Alex: we should separate fees from costs. Fees will not be much, there will be a market for validators. Call data is the most important driver. Two types of txns. Some are expensive on input, less on output. Only change storage. Other has a lot of storage. ORM bound to pubish all inputs. Scale computation. Inputs have to be passed as they are, add signatures, etc. Txns with small input are more expensive for ORU. Txns with large inputs will be much expensive on ORU. ZK has the ability to choose. Operators will pick which is cheaper. > Jamie summarizing Brech: there may be an explicit fee. For Loopring we can hide any fees which would be paid by the user. Transfers are made free, etc. --- Samuel: How do AMM's work on Loopring? Do you have to create the circuit and regenerate the set up parameters ? Or will it be open like Uniswap where anypne can easily add an AMM? or will it be open like Uniswap where anypne can easily add an AMM? > Jamie summarizing Brecht: We support trading against AMM curve. We set parameters w/ a special transaction, this is enabled and then people can trade against your account. The circuit is fixed. Only set a couple of params to define the curve. Always uses balancer curve, update params using smart contract on mainnet. > Jamie summarizing Alex: ZKSync will support permissionless deployment of smart contracts --- Dmitry: Alex, Is there any trusted setup or similar in zkRollup & zkSync? > Jamie summarizing Alex: If you use proof system based on elliptic curves, you will need universal trustless setup. This is done once, can be re-used by any application in the future. In our case, more than 200 participants, only 1 had to be honest. > Jamie summarizing Brecht: Loopring is on the older technique. Has circuit specific, any changes need a new trusted setup. This is a drawback of our system. PLONK does not have to do this. --- Samuel: What about network level privacy? Unlke etthereum it seems to feasible for an operator to correelate IP addresses > Jamie summarizing Alex: ZK Sync is not aiming for network level privacy. Similar to Ethereum's P2P network. Some do implement privacy by default: Aztek, zeropool, --- Fengkie: I tried some sidechain & plasma+evm scaling solution (xdai, matic, etc), and those solutions requires end user to interact with different rpc endpoints, thus increasing the barrier of entry to get them to start using it, how does rollups solves this? --- Fengkie: I think currently loopring only addresses dex and payment, would compound-like defi would also be possible and how does it affect composability which is one of DeFi value proposition? > Jamie summarizing Brecht: We are not a general purpose rollup, so the answer is no. We do have functionality to interact directly with L1, but w/ no scalability. --- Fengkie: when does zksync v2 is planned to be launched (at least the testnet version of it)? I'm eager to try it out! haha > Solidity version testnet release date will be released in the next month. --- Fengkie: I would like to see how developers can leverage rollup solutions to create seamless service for the end-users so that non-tech sophisticated people don't even need to understand ethereum > Rollups are an extension of Ethereum, and don't address seamlessness and other aspects of the user experience as it relates to smart contract blockchains --- Samuel: Starkware has some interesting desgns around this , but it ivovles some liqudity service on L1 > Fast withdrawals, replay the LP. Use the funds from the LP directly --- ## Practical Options for Developers Note: only listing L2s which would share security with Ethereum mainnet (question: should this include plasma-based systems?) ### Loopring - ZK Rollups - [Loopring Website](https://loopring.org/#/) - [Overview](https://loopring.readthedocs.io/en/latest/English/overview/) - [2020 Roadmap](https://loopring.org/#/post/loopring-2020-development-roadmap) - Deployed systems: the [Loopring](https://loopring.org/#/) exchange itself ### Starkware - ZK Rollups - [StarkEx Website](https://starkware.co/product/starkex/) - Deployed systems: [DeversiFi](https://www.deversifi.com/) ### zkSync - ZK Rollups - [zkSync Website](https://zksync.io/), [zkSync Block Explorer](https://zkscan.io/) - [Overview](https://medium.com/matter-labs/zksync-is-live-bringing-trustless-scalable-payments-to-ethereum-9c634b3e6823), [Documentation](https://zksync.io/dev/) - Deployed systems: [zkSync Wallet](https://wallet.zksync.io/) ### Hermez - ZK Rollups - [Hermez Website](https://hermez.io/) - [White Paper](https://hermez.io/hermez-whitepaper.pdf) ### Aztec 2.0 - ZK Rollups w/ privacy - [Aztec Website](https://aztec.network/) - [Overview of Aztec 2.0](https://medium.com/aztec-protocol/aztec-zkrollup-layer-2-privacy-1978e90ee3b6) ### Optimism - Optimistic Rollups w/ EVM - [Optimism Website](https://optimism.io/) - [ORU overview](https://medium.com/plasma-group/ethereum-smart-contracts-in-l2-optimistic-rollup-2c1cef2ec537), [OVM deep-dive](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52) ### Fuel Labs - Optimistic Rollups - [Fuel Labs Website](https://fuel.sh/) - [Overview of beta / testnet](https://medium.com/@fuellabs/announcing-the-fuel-v0-open-beta-565a2d340fc3) ### SKALE - Plasma L2 w/ an EVM - [SKALE Website](https://skalelabs.com/) - [Why SKALE?](https://medium.com/skale/why-skale-de649cbf3ab9) - Overview ### Matic Network - Plasma L2 w/ an EVM - [Matic Network Website](https://matic.network/) - [Matic 2019 Year In Review](https://medium.com/matic-network/year-in-review-2019-matic-network-aa47bf1b201b) - Deployed systems: [Polymarket](https://polymarket.com/), [Quickswap](https://quickswap.exchange/#/swap) ### Connext - State channels to bridge EVM L2s - [Connext Website](https://connext.network/) - [Instant Cross-L2 Transfers Are Now On Testnet](https://medium.com/connext/instant-cross-l2-transfers-are-now-on-testnet-2f1295530c22) --- ## Needs-finding and topics for the next sessions ### L2 from the developer perspective ### L2 from the end-user perspective ### Other implications