Upgrading the Linea zkEVM With Alpha v2 | Declan Fox - Consensys

[Music] okay let's get started um hi everyone my name is Declan Fox I'm the product lead for Linea uh Linea is a ZK evm layer 2 on ethereum and uh today I'm going to give a talk about Alpha V2 Alpha V2 is a recent major upgrade on the linear uh rollup itself so we're going to go into a little bit of detail uh on Alpha V2 okay so high level what we'll cover we'll start a little bit with rollup economics 101 Alpha V2 is mostly about reducing costs and prices and therefore understanding how the sort of value throw uh flows through a rollup is quite important uh then we'll see you know specifically the impact of alpha V2 upgrade on the linear ecosystem uh we'll then take a look at the rollup landscape today like how does this fit in with all the other different ZK l2s and optim Mystic l2s out there and then lastly I'll just cover some of the uh future challenges and optimizations for rollup costs okay so just want to quickly go over how money moves through the rollup system so if you look here at the top you can see the users users submit transactions at a certain gas price to the L2 this then goes into the mle and the sequencer picks up the transaction from the mle and builds a block that uh Revenue there gas that equals revenue for the sequencer um and the sequencer basically builds a block on Layer Two so on linear and it does this over and over and over again and then what it does is it actually batches all of these blocks and these transactions it rolls them up hence the name roll up and then it publishes them in a compressed format to the layer one to ethereum okay so we submit the data batch to ethereum Meanwhile uh we're also sending this batch offchain to approver this is specifically for ZK rollups like linear uh the prover generates a ZK proof of the batch um there has some offchain UT computation costs and then we submit the zero knowledge proof to the layer one and essentially the zero knowledge proof then takes the data batch we previously submitted as a public input to the verifier and confirms that the transactions are valid um and you can see here that there are you know Revenue in form of sequencer gas fees but there's also costs so L1 costs for submitting data batches verifying proofs and then generating the DK proofs as well so what what's the problem here um well ethereum L1 is extremely expensive as we all know um firstly to submit the data so we're supp posting a lot of data to ethereum uh for our security and liveness properties for linear that costs a lot of money we also have to verify zero knowledge proof each zero knowledge proof costs about 450,000 gas um and that just turns out to be quite expensive rollups also take on a timing risk so the time at which you submit a transaction to linear and the time that you charge a US of transactions on linear is different to the costs that you end up paying on L1 there's a time delay and so you take on risk um mostly because the L1 gas price is volatile it's not predictable it's not stable uh but also because it's difficult ahead of time to really sort of estimate the resources that will be used in the transaction later down the line when it hits the L1 and so ultimately these problems just lead to higher L2 prices for end users this is the kind of previous problem that we had and that's what brought us to linear Alpha V2 so with linear alpha alpha V2 we had two key features first feature is data compression so data compression what we're doing is we're essentially encoding repeated bites so if we that data batch that we submit to the L1 we're encoding it uh compressing it making it very small you can kind of think of it as when you take a photo on your phone comes in a big file format and then you have to compress it maybe to send it over the Internet um it's very similar to how we're now submitting data batches we're compressing them and then we're decompressing them in the snark circuit to make sure that the proof is valid uh it's lossless so we want need to make sure the data that's being published uh even when it's compressed is still not losing Integrity which is akin to sort of a Gip and deflate if people are familiar with that format and we're seeing some amazing results so we're seeing up to 15x compression ratio calls for say a call to a Unis swap contract so we're getting a lot of cost savings from this data compression and then the second key feature for Alpha V2 is proof aggregation okay so with proof aggregation what we're now doing is those batches that I shared in the previous slide we're now recursively verifying them offchain so we're actually recursively proving them over and over again inside um single circuit and what that means is that we only have to verify um a sort of many batches with a single final proof so we're reducing our fixed proof verif ification costs um and sort of with the scheme that we've implemented like we could theoretically verify you know up to 250k proofs in a bw6 circuit so we can get lots of verification and aggregation with this feature okay so concretely then like how is Alpha V2 different to Alpha V1 so here we have on the slide at the top Alpha V1 what you can see is with each data submission each batch we're approximately we were um including about 150 linear L2 transactions and when we submitted each batch to L1 uh we then verified each batch of a single proof so every time there was one batch there was one proof and it cost about 450,000 gas very expensive um with Alpha V2 here you can see at the bottom how things have changed so a few key things firstly we're fitting way more transactions into a single batch not only are we using more of the sort of transaction size limit of ethereum we've gone from using 75 Koby to 125 KOB we're actually as I mentioned compressing the transactions as well so we've gone from fitting 150 linear transactions in a batch of alpha V1 to 1,500 so that's a 10x Improvement there but also with the proof aggregation we're now able to include many many batches into one final proof so you can see here we're getting up to 30 of these larger proofs uh sorry 30 of these larger batches and only then has has to be verified of a single ZK snar proof so this is great like the sort of tldrs we've gone from roughly having about 150 L2 transactions of alpha V1 verified in a single ZK snar to about 45,000 so that's sort of 300X increase um and the cost savings are significant we've actually reduced the L1 costs on Linear by 4X approximately so there's some big cost savings there and uh this this sort of results in uh cheaper prices as well so the the whole purpose of this is we can therefore lower prices on linear uh and we already immediately lowered prices by about 66% following the upgrade a couple weeks ago okay so practically like how does this work out then across the rollup landscape so you can see here I took this this is the data from the last week so on a per transaction basis now the sort of two main costs and these are onchain costs L1 costs um the data availability cost as I mentioned and then the actual settlement which is the sort of verification of the DK SN cost and you can see here that you know specifically you might notice that linear is the cheapest per transaction and again that's because of the data compression and the proof aggregation so the settlement cost which is only really for the sort of ZK rollups you in this comparison table you can see that sort of per transaction now we have less than a cent um 0.001 per transaction and that's because we're getting up to 45,000 transactions in a single proof and that's you know 37 times cheaper than ZK sync 150 times cheaper than scroll just for the settlement costs uh but the interesting part is that the data availability costs which are the more significant part of the overall picture they're also much lower due to the due to the uh data compression and so interestingly with the compression that we implemented on linear for Alpha V2 we're even getting compression ratios um much better than optimistic rollups so you can see here for even arbit an optimism some of the optimistic rollups we're paying less per transaction on ethereum cost now with this upgrade so there sort of tldr here you can see at the bottom is the L1 total cost you know of linear over the last week was something around 17 cents transaction CK sync around about the same with 18 cents a transaction uh and then you can see there's a big jump to the other sort of ZK EVMS and even the optimistic rollups are still much more expensive on a cost basis okay so uh you can see on the left hand side so for Alpha V2 what does the sort of cost profile onchain look like 99.5 % of that cost is now data availability only a smidge so half a percent of the overall cost is for verifying the ZK snar so the whole idea of you know ZK rollup ZK EVMS being more expensive is is now completely over like that sort of Paradigm is completely changed we can have much better security with zero knowledge rollups but also the same or cheaper prices now because the data availability cost is 99.5% the real Focus comes in how do we reduce that further and you know there's a big upgrade coming soon on ethereum which is EIP 4844 um that's probably going to reduce the sort of cost of the data availability by approximately 90% I I put maybe we we'll see because no one really knows it's a new fee Market but it kind of promises to lower costs by around 90% And you can you can see here that that's going to further reduce um cost for all rollups and so how does that sort of you know theoretically if we applied that 90% to the DA portion of the previous table you can see here sort of post 4844 the L1 cost per transaction for linear will go down to around 2 cents obviously it depends on the transaction but that's sort of like the median um and you can see for some of the other rollups as well we're getting much much cheaper costs therefore much cheaper fees but interestingly linear with its Alpha V2 upgrade still has the best or most cost efficient uh L2 now for ZK rollup this is all onchain costs but there is an offchain portion as well so we have to actually generate the zero knowledge proof um and this is where sort of linear um the technology the value proposition has come in very strongly and that's because we spent a lot of time in RNG to design Vortex Vortex is our sort of unique proof of Technology sort of essentially with Vortex when we generate the proof we have a two-step process so we have the inner proof uh it leverages ltis based cryptography which is much faster than elliptic curve cryptography um and it's optimized for what we call self- recursion okay so with Vortex we're able to take transactions we're able to take lots of transactions and then iteratively uh recursively prove them over and over again so we get them very small and then what we do is we wrap that sort of we compress it and wrap it into an outer proof and the reason we do that is that the outer proof is a snark which is much cheaper to verify on L1 so we're sort of optimizing for Speed and cost in the computation side but also optimizing for L1 verification costs when we finally settle to ethereum as well and so the purpose of of Vortex really is to make sure the costs are cheap for linear so when we think about having to include the offchain sort of computation cost around the Prov into the L2 price it will still be very cheap to use linear um and we haven't had to sacrificed any sort of evm compatibility here as well just to sort of give people a framing for like how the different sort of large ZK l2s uh stand in a sort of developer experience and compatibility perspective we sort of have the um specialized uh virtual machine um l2s on the on the left hand side there you can see Star which uses Cairo it's not evm compatible sort of ZK sync in the Middle where you can use a transpiler um polygon ZK evm which has a translation for the bik code into their own Assembly Language and then sort of linear and scroll on the far side as the most sort of evm equivalent byco compatible l2s and so using linear really much feels like ethereum and a couple point there is that we've been able to you know deliver a ZK evm with linear that is not only cheaper and more secure but has a great developer experience it really does feel exactly the same as ethereum and it still is the only L2 that you can go and syn an ethereum node to like if you want to go and take your vanilla gu or vanilla bzu node and you can sync it on linear and it will just sort of run out the box okay so uh challenges and future optimizations so what's coming down the line um I said 4844 it's a new fee Market uh we don't know necessarily how it's going to respond to all the different rollups trying to post blobs and competing for blob space so again we need to really think about the timing and optimization of how we're using these blobs to make sure the costs stay low uh we need to get better at trading L1 block space rollups are effectively commodity Traders you're sort of selling and buying of block space and there's ways that you can sort of optimize that to reduce your cost further and improve the user experience as well and then having accurate three-dimensional pricing as well for for users so when people are actually using linear um it's good to be able to price in three dimensions so the three dimensions are you know the First Dimension is the data availability layer which is ethereum uh the second dimension is your execution and your storage costs if I have this on here yeah execution and storage cost on Layer Two um and even storage today is not well priced in my opinion you have to store this data forever and it's probably underpriced so getting better at accurately pricing that on L2 proof generation so when you submit a transaction to a ZK rollup usually the sort of cost to execute it and the cost to prove it is roughly one to one but there are definitely some operations like catrack notoriously which is way more expensive to prove and so really what the ZK l2s need to start doing is actually saying if you want to use this op code you can but it's going to cost you more and then being able to accurately price that at the time of transaction to the user uh as I mentioned L1 data availability and getting better with compression as well I think for you know for linear with the the compression we're sort of getting around 90 90 bytes uh per transaction on L1 and with the sort of specs of 4844 initially that turns out to be about a throughput of 415 transactions per second before we start to see congestion so that's the sort of that's where we can get to with compression for rollups that are not using compression like linear it'll be even less so again it's better that more rollups adopting these these Tech Stacks with compression uh and then you know for us one way to solve that is we're going to be rolling out a new gas API on linear very soon which is going to help solve a lot of these problems and that's it thank you for [Applause] listening