Horizontal Scalability for L2s | Wei Dai - 1kx

[Music] all right how is everyone this afternoon okay so my name is Way D I'm a research partner at 1kx where early stage focused crypto investment funds and today I'm here to talk about scalability in particular about trust minimization and horizontal scalability so I hope I didn't just lose you guys right there ra raise your hand if you know what trust minimization means okay I see at least five hands great what about horizontal scaling great more hands okay so so hopefully this is going to be um somewhat educational for those of you that raise your hands and for those of you that didn't hopefully um yeah hopefully you know I I will be able to kind of show you something uh that you didn't know today okay this is outline first I'm going actually going to be defining what these terms mean in particular in the alto scaling context and I'm going to talking about some some of the open directions uh that we have so first off what is trust minimization largely speaking there are two categories of applications in relation to our one blockchain like ethereum there are those that are trusted for example centralized exchanges web2 Services Banks they can connect to ethereum but they're always trust it meaning something can go wrong in the case of for example FTX Celsius and you will lose your funds and on the other side you have trust minimized services for example smart contract applications rollups as well as validium these applications keep your phone safe even though the operator might be malicious and so that's what I mean by trust minimization a trust minimized service um it's allows you to have self- custody allows you to not trust the operator outside of trusting the base layer Network for example ethereum so if we go to more detail there's actually different properties for al2 um that require different levels of trust and largely speaking there are three of them liess and ordering meaning you should be able to submit transactions and they shouldn't uh operator shouldn't be able to censor your transactions validity meaning is you know your funds being used in a safe manner are you getting out the right amount of tokens and third data availability meaning can you actually carry can you actually reconstruct the state of application and then submit submit new transactions and the third one is a a really really important thing that you know everybody is trying to solve right now for rollups and it turns out that every single property requires different levels of trust in different skating paradigms and I'm going to stay on the very high level here and and and just tell you that there's a spectrum here and on the left hand side we have something like you know Unis swap on E L1 where you basically are making no external assumptions and on the right hand side you have offchain services like coinbase that's completely trusted but in the middle there you know this is where we have rollups uh you know different types of rollups and also also validum meaning it's almost like a rollup but you're not posting data to ethereum and okay let's jump to the second term scalability in particular two types of scalability vertical scalability we're making a resource bigger okay so so 444 is going in that direction meaning we're making ethereum a better da layer giving me more forut and then there's the other type of scalability which is horizontal scalability you are simply adding new instances of a system to make a system more scalable right so web 2 it's a clear example of you can add more web servers you can add more websites right but we only have one ethereum so what about this horizontal scalability of the systems we just mentioned so if you look at horizontal scalability of these systems in relation to e al1 you kind of get the following conclusion on the left hand sides because smart contracts share the all resource there's always congestion we don't have uh any form of horizontal scalability because we run BX as we add more smart contracts on the right hand side of services operates chain and they only communicate with with ethereum when they need to right when the users enter and deposit and withdraw in the case case of Point base um and so you actually have really really good horizontal scalability and in the middle is where the interesting thing happen uh in my opinion right where we can have trust minimized Services you can have self- custody but you're able to add more and more systems on top of ethereum and still not incur any Global bottlenecks and the interesting category here is actually smart contract rollups so so for validium you know these are effectively like they're like rollups but data is not1 right so there's actually no glob bik uh and for that most people agree but for smart contract rollups I actually want to zoom in a little bit more here so my argument is that there's going to be two types of rollups and I'm going to show you which one is which there's transaction data rollups so optimistic rollups are mostly transaction data rollups so whenever you make a request that entire request go on to1 and there State different rollups meaning the part that goes on chain is not your transaction request but the difference between uh the all2 system between batches okay so the examples are are basically as follows all the optimistic roller today that we know of are of the the first category meaning you po the entirety of the data to to R1 and in the case of starnet and ZK sync they actually have the second category meaning the larger the batch batches get gets the the data that you post to R1 get actually gets smaller uh and I'll show you some some data in the next slides and and this is something that's unique to ZK rollups um um you know because you can actually enforce validity even even though you're not posting the entirety of data okay so here's some data that we collected uh around the end of 2023 and is it's guys over a 30-day 30-day periods looking at the average data incurred by a transaction um on L1 right so these are all2 systems and it turns out after Tik sync made this upgrad um around December 2023 they're um they effectively enlarge the bat sizes and the call data per transaction become a lot lower than all the other Solutions and you can see this on various different charts in in the form of transaction cost uh you know per per transaction because da cost is actually the the you know number one contributing factor to to Al fees so and and actually if you look closer the um for the extremely large batches during those inscription events the call data per transaction actually get got as low as 10 bytes so so basically What's Happening Here is um for transaction data rollups if fact you are bounded in the data that you that you know you're lower Bound in the data you post L1 because transactions are off a certain format and in for state did rollups you actually get this aggregation benefits so as you aggregate more the less data you need to post all1 per transaction okay so here's here's kind of the the one of the main points I want to make uh in my talk today which is if we want to have ethereum connected services to scale like Web Two um counterparts we have to not congest etherum L1 um you know otherwise there's no way to get kind of web two back in scale uh transaction thp puts right and and and really there's two approaches one we don't post any data to ethereum L1 or two WE Post really really large batches so that you get really uh a lot of amortization benefits for um you know for the amount of like that you have on the L2 okay so here are some common questions that that I think um always get asked whenever I make this argument and the first one is you know why don't we just use an external da like Celestia I da Avail well my answer to this is first this is a temporary solution you know ethereum is also working on a better day solution right on E1 but this is still a global ball if you use a share da layer you we're basically just get the can down the road um and we cannot add infinite number all twos without congesting these data layers um if if the class class of applications gets richer and richer and further furthermore you know these external da services do not inherent all1 security and the alternative approach um is I think we should actually create really really large batches for for these al2 systems and post state divs to all1 and that's really should be the Bas case we can still use external da services for the full call data especially if there are actually independent independent instances for each rollup and and we we should always be posting state of all one to to to uh inherent ethereum security and the second question I get a lot is you know how does all of this relate to share sequencing uh which is also buzz word these days and and I think the answer is share sequencing just like Global Shar da is also a shared resource and as with all Global share resources they become bonex as as you add more systems and um but nevertheless I think I think that's you know they're a great invention because they allows you to automat compose between different l2s as if there are L1 smart contracts um and so I guess if you haven't uh seen sh sequencers I encourage you to look more into Astro expressive systems um okay so third question that I get a lot is yeah like what about interoperability you know as you add these horizontally scalable systems you're going to have more and more of them they're going to be more and more sils um yeah what do you do about inability um so first of all we definitely do not have aom composability between these all twos you know unless we use sh sequencers which have um Global bonex but you know I I think a sync composability um it's also a usable solution right we can um this can be very very similar to users um as well so like what do I mean by this there's two great examples uh of recent kind of paradigms proposed by um zync and polygon so if you look at zync hyper chains is really a horizontally scalable system where all all twos and all threes they call it are connected right via a share settlement and the same thing applies to polygon agar and I think this is this is basically the framework that I think most of these project are converging on which is that we should be able to instantiate more systems and they should actually you know benefit from being inside the same EOS system and and inherit the same liquidity okay um yeah so finally let me open uh discuss some open directions I think that I think um are somewhat under explored currently uh the first thing is of course what do we do about data availability right the entire point of rollups is we should be inheriting all security and if we don't want to post as much data to all1 because we have a global ball like yeah what do we do you know what if the data it's gone well uh yeah so this is definitely a hot topic of debate um and and a lot of people in the EF has been kind of this there's a Resurgence of you know discussing plasma based Solutions right which is you don't need to put data at one but you still get the data somehow and and that's basically you know the entire class of plasma based uh Solutions and and encourage you to kind of read more on um the post from bar hat and and metallic linked here um and second when there's a so system are currently pretty centralized and there's to be made that they actually give you better thrp put right like a sing caliz sequencer but they don't really give you kind of this soft confirmation guarantee in the sense that like you know that transaction is being it will be confirmed right if we're going to make these batches really large it's going to take a long time before they settle onto R1 how do we get more like guarantees for the user that the transaction is going through right so ideally you want like a really really fast confirmation but settlement could be like you know uh it takes a all longer and yeah so one example solution is um we could for example have like a dedicated datability committee um okay I actually should back a little bit so the problem is the technical uh solution to this is really called proof confirmation where uh the user after taking some confirmation with the sequencer is able to slash the sequencer uh if the sequencer did not include the user transaction in the place that the sequencer promised they would so I guess I I don't want to get to technical here um so really there should be a way for the user to prove that the sequencer didn't behave uh per the commitment and that mechanism requires data um about the system and and that's basically like you know form a DA problem and so um so yeah there's kind of this um yeah like do you actually have the sequence or share data against other uh to other nodes so that other nodes can help users frog proof in which case you know your system is less scalable or do you keep the data for the sequencer itself in which case sequencer can just do whatever they want right so there's definitely some open questions here um but I think I taken the midpoint of doing a DAT of Li committee you know this is something that starware does I think it's it's a you know good um immediate term solution okay and of course there a lot of related works so here's uh a post on base per confirmations which is something that's very adjacent uh um by Justin Drake on uh e Research Forum U encourage you to take a read okay lastly last final direction that I think um is really important is we've seen a lot of Autos system go down right like the centralized sequencer can go down um and they'll just be offline for like hours or days and um I I think we should be able to recover from these list failures much faster right there there if if for example um alternative sequencers are always queued up to be able to take over the work if the main sequencer goes down we'll have much better livess guarante uh and I think that's like one of the main ux problems of of alus right is that that like during periods of high demand they just centralized sign just go down uh and I think this is um definitely a problem to be solved okay so yeah let me actually skip this technical slide um not bre with the technical details so what is the main point what is the main takeaway um yeah the main takeaway is I think to really scale ethereum connected services to billions and billions of users to really compete with we2 scale um transaction speeds right we really really need to have horizontally scalable systems that is trust minimize um um that that can interoperate and we you know this is something that uh rollas by themselves do not really solve and we should really look into um validum okay and there's a blog post um on this that I recently put out uh which is called on trust minimization and horizontal scaling and if you want to read further I encourage you to scan this QR code but otherwise I think I will end early and if you have questions raise a hand okay I I don't see questions and I I don't think there's a mic for the audience so I'm going to be taking questions over there if you do have a question uh but yeah I I will here thank you for your attention