ELI5: Scaling Ethereum by Patrick McCorry | Devcon Bogotá

foreign [Music] I guess what we're going to cover is you know what is it we actually need to scale and why like what do we mean by scalability uh the bottlenecks of scalability today I'm picking some core bottlenecks that we can go over that are pretty simple to grasp and then finally the future roadmap that a theorem is sort of considering I know the whole modular approach I'm sure you've heard off already what do we actually need to scale so this does a basic recap of you know what is a blockchain a block is just an ordered list of transactions a block is produced every 12 seconds and has appended to something called the blockchain you know given the name as a chain of blocks and it represents the canonical history of the entire network now Alice you know all those is an inspector so she's a cute little heart and her job is to make sure that every new block that is produced is valid and so what you'll do is you'll get a copy of the blockchain so you'll replay and execute every transaction and eventually still compute a copy of ethereum's database okay so the one thing I want to highlight is we have the blockchain which is the canonical history of the network and every single transaction that has ever occurred and we have the database which is your current account balance smart smart contract byte code you know the actual you know the programs did as well and there are two very different things the blockchain's history the databases up to date on my current balance it's very important to have that distinction and of course the blockchain computes the database so anyone here who gets a copy of the database or copy of the blockchain can compute the CM copy of the database as everyone else so it's widely replicated across the world and I like to call the blockchain a cryptographic data trail because it allows us the audit the database in real time you know there's no let's say your bank you can't audit your bank can you you ignored the blockchain it's an audit Trail now all this the inspector could be any of us you know who's actually running a node here is anyone running a node one guy over there there you go we've got some inspectors that's great you know a small sample size but still a grip so the peer-to-peer Network I mean it's changes from time to time but it's normally around like 10 000 computers that are online fully synchronized with the network and they're auditing you know blockchain real time now the peer-to-peer network is responsible for propagating blocks and transactions its only goal is the gossip if you have a transaction it goes bad to peer-to-peer Network and it spreads out the everyone so a single transaction will reach you know 10 000 computers 100 000 computers and the oil has to help them within a few seconds the CM for blocks on the peer-to-peer Network as well are the block block proposers and a theorem we call them the validators and the proof of stake chain in Bitcoin they're the miners the ball proposals are also on the peer-to-peer Network they're listening now for users transactions and of course new blocks now the only thing block the block proposers provide is a transaction ordering service they have absolutely nothing to do with what it means for a transaction to be valid they just tick user transactions stick them in a block order them and then you know send that out to the world so as an example user sends their transaction flows across the network and every block proposal will hear about this in about two to three seconds and then a block proposal will produce a block based on the transactions they hear and every single peer in the network will get this block validate it and then update their copy of the database and that's basically what's happening under the hood a block is really like a Bots update you know for a database you're just doing it every 12 seconds and you're updating everyone across the world they're a database and so what we end up with is this public and Global database conceptually it's like a bulletin board like everyone here can see the exact same image under the hood there's thousands of copy of this database everywhere it's widely replicated and that's what helps secure the network because if anyone can get a copy off it then we can also check that it's correct sort of scalability come in you know why do we care about scalability so there's two real people there's two you know parties we care about one are the block proposers it's really important to block proposers and get the most recent block right away so they can you know take the block check is correct and then extend the blockchain the block proposers want to converge let me get back to the blockchain the block proposers want to converge on a single blockchain so when a new block is produced they want to take it and then extend it you know block one block two block three block four so it's really important they can get the blocks very quickly at the same time we have the peer-to-peer Network we have Alice the auditor and some people in this room and your job is to hold the block proposers accountable you want to validate every transaction and if they try to break the rules you know they try to include an invalid transaction then the peer-to-peer network will reject it gets rejected they don't make any money they wasted their time and of course you know blog proposers will then just not extend it so there's two parties we care about block proposers and the verifiers and what's important is that you know what do we mean for scalability what we really care about are the resources you know what compute isn't required What bond with is required on what storage is required and we have to consider these Resources with the goal of decentralization in mind you know what are the minimum requirements for someone to run a node for someone the volatia blocks or even for someone to become a block proposer do you have any stakers here by the way any eve two stickers there you go over there got a couple of e-stickers you know we got to make sure that the resources are good enough so you can run your sticker at home hopefully you're running it at home anyway I don't know how you're doing it but we know we care about compute bandwidth and Storage now there's one takeaway here I hope this is the biggest takeaway you take scalability cares about resources on the delicate balance between verifiers and proposers so proposers can make blocks and verifiers can check it in real time it has absolutely nothing to do with transactions per second that's more like a byproduct you know you could have one transaction to explode to the database and then none of will know in here could be a verifier so if you ever hear blockchain project which of course you will you're like we can do 10 000 TPS then you can just call our because sorry the character because it's all about resources and that's the most important thing we have to consider and how we measure scalability so the reason just to recap the basics there you know we have block proposers transaction ordering service they propose blocks to the network we have the peer-to-peer Network that has block proposers and verifiers anyone here can be a verifier and your job is to hold the block per block proposers accountable and make sure that the consensus rules and the network rules are enforced in real time and finally scalability has nothing to do with TPS it's about resources and how you know what's the likelihood that someone can participate in the network so let's have an overview on some of these scalability bottleneck oh yeah exactly yeah it's we'll get to this sort of the balance there but that's a good point Nick what what is the meaning of resources and for the goal of these centralization we need to pick the right you know configuration that maximizes the population so we say you know we want 90 of people in this room the Runa verifier what are the requirements that's what we have to have on the network and the other questions by the way please throw your hands up you know there's no dumb question so let's have an overview of some of the scalability challenges that we face today and we're going to do this again through storage competition and bandwidth and you'll see computation and bandwidth sort of join The Gather when we talk about the fork Grit so let's jump in the storage okay so the storage requirements for a node is you know how big is the database it's a database of everyone's account balance how big is that there's something called the mempool and it's more like a cache so you're on the peer-to-peer Network you're running a node and you hear a new pending transaction what you'll do is keep a copy of this and pass it on to your peer if you hear the CM transaction again you'll just reject it so it's really the prevent the now a service attack on the peer-to-peer Network so people can't spam it with the CM transaction over and over again but again that's something you will have to consider when you run a node and of course the blockchain itself how big is the blockchain and even how long does it take to synchronize it you know how long does it take us to compute a copy of the database so before I begin has anyone ever heard of an archival node or a full node or a print node okay awesome and read your hand if you think they're really confusing terms oh look at this oh there's one guy thank you the good guy over there the honest guy they're pretty confused I know the Bitcoin Maxes have no idea you know uh they're always misinterpreting the freeze so let's talk about them what's a full node a full node is a piece of software that will take the entire blockchain validated from scratch up to the beginning and then compute a copy of the database importantly they keep a whole copy of the blockchain locally so they don't discard blocks they keep all the blocks the reason they do that is if you join the peer-to-peer Network well you need a copy of the blockchain so a full node will supply new peers on the network with a copy of the blockchain so they keep it all around and uh most important was actually quirky about ethereum is that so if you look at the blocks you know block 7 e at 910 nodes typically keep around copies of the database I think it's like 120 ear blocks worth I forget the exact number and the reason for that is to handle reorgs so has anyone ever heard of a block reorg before okay we're going to jump into the block reorgs very soon that's part of the fork Grant but the idea is that if your transaction got confirmed in Block seven and naira block 10. you have some guarantee that is probably going to get finalized but an alternative block for maybe from block five could emerge that removes your transaction but if that's the key is well you need to have this database so you can quickly jump back and then deal with the new fork and so we have to keep around you know but 100 copies of the CM database just to deal with reworks but all the other databases can be deleted you don't care about you know very historical database is just the most recent copies and archival node is very different an archival node is something that ether scar mode run or a block Explorer an archival node is where you want to quickly look up historical theater so maybe you have a request what was my balance a block to that could have been a year ago there's no reason to run that on the peer-to-peer Network because the you know the probability of a one-year reorg is very small in fact impossible in proof of stick ethereum but an arc Avenue will run this and that's why when you hear quotes you know an archival node is like two terabytes in storage and ethereum isn't scalable well that's because they run an archival node in you know you don't need all these databases you just need 100 of the most recent databases then a print node is where a prune node will discard the historical blocks a prune will just keep around the most recent blocks and the most recent copy of the databases they prune as much as they can and they have minimal resources they still validate everything you know you still go from the start to the end you validate it all but you just keep around the most recent data so my question to you guys is you know uh it's my next slide if you're going to run a node like a block proposer or a verifier which one would you run lastly reviews of hands would you run a full node for either verify or block proposal yeah okay read your hand guys if you think you want to run yep that's fine that's a good answer what about an archival node would you run an archival node for the network when you come but there's no need you know it's spent a waste of resources what about a print node yep exactly that's probably what most people run today you know most people do want to keep around the entire blockchain they just discard most of it and as we're going to see that's quite a lot of gigabytes yes so an event that's a great question so basically when you execute a trump so in solidity and a smart contract you can define an event so let's say it's the vote function if I caused by vote it will emit an event that will tell the world and notify the world that Patrick has caused the vote the way you get an event is when you execute a transaction it produces a transaction receipt and then the receipt is there is the event importantly most I don't even think archival knows receipts aren't typically stored they're normally discarded right away but yeah so you don't really store them but you can still get the events in real time because you're validating blockchain real time any other questions by the way yep I think I mean I will touch on this that's a great question so just to summarize ethereum now has two layers has the beacon layer that deals with proof of stick and you have the execution layer which deals with obviously the execution of smart contracts for now I'm assuming they're the same thing you know if you're joining the beacon you know for the beacon chain again you just care about the last finalized block after it finalize you've done that's about like 15 minutes you could technically just delete the rest of it you need to keep around recent data but for now we'll just assume they're both the same thing but we will hopefully touch on that soon yeah so the real difference is that in a full node you keep around the entire blockchain and the reason you do that is the serve at the peers on the network a print node deletes most of the blockchain they just keep around I'd say in this case four blocks and that's the deal with forks and reorgs it's called reorg cfd I think there's default settings um I think there's a default setting but really you know the more you store the better you can handle reorgs so one issue we had was I previously worked on a transaction relayer where you'd send transactions and try to guarantee the delivery so we wrote Our Own blockchain machine the deal reorgs we would keep around three to four hundred blocks and you know obviously copies of the database but if you run this in robsten robstim was a very adversarial Network and you'd wake up one day and there's a 20 000 block reorg and the reader will just tip over because it just can't deal with 20 000 block reorgs so it really comes down to what network are you running and you know uh what so another example is a theorem classic ethereum classic has had 10 000 block rewards in the past which would also make a lot of notes just collapse over because they they're not expecting that huge reorg oh for reorgs um I think okay so let me I'll make it to the rework section first we have a picture of it but yeah reorgs are less likely to hop in and proof of stick you know because part of it was part of the puzzle for proof of work but I will touch on that because there is still probably you know a good chance on proof of stick yep exactly so improve of stake is above for 15 minutes worst case scenario could be like three weeks um well maybe we'll chat about that afterwards it's a great topic okay cool any other questions or are we all satisfied cool I guess your goal is to make sure I don't finish my slides as well very likely to happen Okay so let's look at what a note with store so on bitcoin this is maybe four months ago when I made this uh the database was roughly about five gigabyte but if it was an archival node version it was about 35 gigabyte on ethereum the you know a normal pruned a normal database was about 700 gigabyte so the database is quite big on ethereum you know according to the stock that I have here an archival node was 10 terabytes and that's normally the number you hear throwing around Twitter by all the Bitcoin Maxis but as you know that's where block explores an Aragon got this down to about 1.9 terabytes uh I actually forget how about but we'll first we'll figure it out and then what about the the blockchain itself I can just look here the blockchain so for Bitcoin you can see that the blockchain's about 422 gigabytes which is huge by the way but on a print node they keep around seven gigabytes perfect blocks they discard most of it on ethereum next slide the blockchain's about 200 gigabytes you know so it's actually smaller than Bitcoin was a surprise in actually given you know there's blocks every 12 seconds that's generally because blocks are smaller in ethereum than they are in Bitcoin because we worry more about gas then we do bite size you know Bitcoin is all about you know one megabyte two megabit blocks and it's really about the size of the transactions but here you know it's about 200 gigabytes for the blockchain and overall in cleaning Watson memory a muscle disc you're probably going to store around 560 gigabytes give or take it's a roundabout uh like Klein got me this by the way he's really really thankful from getting me that that picture and of course flood protection you know how do we deal with you know now the service attacks in the network on ethereum it's about I ought to rough estimate about 100 megabytes you might store in the worst case so the memory pool has nothing to do with scalability really so far we're not really hitting any storage problems for dealing with uh pending transactions on the network such storage you know we covered you know blockchain the database and the mempool and the different types of software that you could run so what about competition and so there's this really great blog post I'm going to run through by Jimson Lop he runs this every year how long does it take to synchronize a node and he has this pretty beefy machine has one terabyte stories 32 gigabyte let's see how let's see how well it works so on bitcoin back in 2011 but November it took about 400 minutes to synchronize the entire blockchain that's pretty damn fast I don't even know how long that is like five six hours and you're fully caught up on every transaction that's ever occurred in Bitcoin yep that's a great question I'm not too sure if this includes bandwidth I don't know if they already have a copy of the blockchain or of the request not in real time because because our latency will cause an issue well I lots of seems for computation for now and we're not worried about latency because I'm not actually too sure I don't think he defines it in the in the blog but anyway it took about you know 500 minutes or 400 minutes for Bitcoin what about ethereum so his issue was that uh go with the amount out of memory when it was synchronized and has stopped but after five days but that's because he has one gig you know one terabyte storage and he could have more stories to deal with synchronizing uh but he would estimate it would take about 10 days but the important bit here is what's the bottleneck why has it taken 10 days to synchronize ethereum and you would think as execution but actually is input and output it's just reading and writing to the database here according to the the stats that he had you would read 15 terabytes from disk and 12 terabytes back the disk for the first five days of trans of you know the blocks and there's another five days to do by the way so that's probably 20 30 terabytes worth of reading and writing and why is this you know why are we doing like 15 terabytes of reading from desk for a blockchain there's about 500 gigabytes or the database so the reason is that oh actually just before I get into the reason by deleted the reason oh I haven't okay it's over there obviously I've messed up my slides the reason is that in ethereum in the block header there's something called the state route and this is good for the snapshots you know you want to download a copy of the database you want to make sure this database was correct for this block and so in the block header you have a hash of the entire database you know you get the entire database you build your Merkle tree then you have a host that represents the entire database but if you're hush in the database for every single block that's a lot of reading and writing from the database and that's why you have those dots um it's also this is very expensive so Aragon stopped doing that so they're reading and writing the disc is still about a terabyte after 10 days but actually you know they heard of us that they synchronize they synchronized in two days so just removing that one part of the validation you see if it days worth of time to synchronize the question is do you need to do this should you have to Hash the entire database and store it in a block header so in Aragon when you get to the most recent block you'll download the database from the peer and peer to network and your checkup is correct and if it's not correct then you'll start rolling back until you find the Mystique so it's not as an essential check but it's useful if you want to download snapshots from the network of the actual database itself but there's a present takeaway here is that execution isn't really the bottleneck it is expensive Extrusion is expensive but just reading and writing from the database is the current bottleneck for ethereum the disconnect I think it's the first point that you made it's just the latency from Reading Writing from disk that's why it doesn't work on his new hard drives Works in ssds that's also a great find very good technical Point uh yeah they should I mean so uh there is work on that called an access list so in your transaction if you define an access list I think I touch upon it later you can Define what storage slots in the database you're accessing and so if you have two transactions that don't access the CM part of the database you could run that in parallel but right now access lists aren't heavily used but they they should be because they help a parallel execution anyway just a final joke I mean I don't mind Solana actually I'm not a hitter on Solana but I just made a joke that you know some projects give up on the fact that people can synchronize the blockchain uh I think actually this is the internet computer you have to get special Hardware from their own suppliers they run a node on their Network very permissionless isn't it um but anyway that's synchronizing is a fun topic to talk about so what about the fork Grant so let's assume more block all block proposers are honestly following the protocol they get a block they extend it and they propose a new block no malicious behavior whatsoever by the block proposers so the fork grit is the following so let's say you have block one and block two than a magical wild Fork appears you can have block 3A on block 3B proposed by two different block proposers the question is what which one do you extend eventually you know you'll get Block four block five and everyone will Converge on the longest chain or the heaviest chain block 3B becomes a steel block you know the content is ignored and it eventually ends up as an uncle block so if you ever hear the word Uncle block as a fork that didn't make it into the canonical chain but it did exist and in a way this is wasted resources and we have these two competing blocks you've wasted some resources because this never actually gets used you really want to maximize a single canonical fork with no with no Forks okay any questions on this part before I continue because this is quite important fairly straightforward awesome so the inability so what do we why do we consider the the the the the fork rate so one is about just you know how reliable is the network you know if you get your transaction confirmed in a block but there's a 16 chance that it gets dropped and reconfirmed later well that sucks from user experience perspective you know if I only have to wait two or three confirmations that's way better than winning 20 confirmations and the fork grid is really about how reliable is a confirmation and a block at the same time there's a bond with on a compute overhead if I send everyone here a block I've used your bun with you then validate the block I wasted your compute but in the end the block never gets in the blockchain so I've just wasted your resource for a block that wasn't actually useful so you really want to minimize that fork grip and there's two aspects that we have to consider is one you know what's the length of time between blocks is it 12 seconds is it 10 minutes and how fast does a block reach another block proposer okay and also of course what's the Frequency so this is sort of the big block first it's a small block we're back in the 2015 World with the block size Wars you know this is pre actually I guess the theorem was born around this time so if you have a one megabyte block every 10 minutes if you imagine this being the peer-to-peer Network and reaching all the peers in the network then it won't megabyte block should fly across you know everyone gets this within a second not much issue we have a one gigabit block you know every 30 seconds well maybe you know one gigabyte takes a long time to get across the network then you may have a competing block at the same time then you have another competing block and you just have lots of forks and then you know you've wasted time because there's more there's three competitive blocks and of course this is a bomb within compute and so these are two extremes we have a two megabyte block every oh yeah I'm right now you know if you have a you know a block that's greater than two megabytes but less than one minute you increase the fork rate smaller blocks longer interval smaller Fork grip so is there a good way to get you know a good feel in the numbers here so there's a study back in 2016 for Bitcoin and I would love it to be repeated for ethereum because it's very useful for proof of stake is oh and this one point is uh on bitcoin we only consider megabytes the size of the block on ethereum we consider gas because gas takes into account bandwidth stories and compute you know 30 million gas is the maximum size of a block and it tries to take into account all the resources that are required and actually there's a z cash article there because right now Z cost is being spammed is costing ten dollars a day and they're going the database by like a gigabyte per day or something you know it's very cheap that you know attack the network so on ethereum you know blocks you around 120 kilobytes there are 30 million gas and they occur every 12 seconds roughly even proof of stake on proof of work that's that was for the proof of work chain on Bitcoins you know well on the three megabyte every 10 minutes so on ethereum and proof of work ethereum the fork rate was around five to six percent at any time so that means you know five percent of all blocks were wasted resources and that's just because of the nature of proof of work where today with proof of stake is less than one percent and one thing to highlight is that on proof of stake ethereum the block proposer has to send the block within four seconds then the validators not committee will vote on that block if it takes longer for a block does it take if it takes longer than four seconds for a block proposal to get their block across the room you'll end up with a fork because the committee will vote on the parent block and not the current block and so you can see right now there's very little Forks so clearly you know there's a good block size for the proof of stake chain if the fork rate goes up then we know stakers are no longer keeping up of the network and on bitcoin I got this picture from February 2022. they happen every one the two months because it's small blocks every 10 minutes very rare to have a fork in Bitcoin so what's the idea of block size and interval again from 2016 for Bitcoin and they were trying to work out you know given the current peer-to-peer Network like this room if I want to make sure 90 of people in this room can get blocks in real time whilst the ideal block size and so actually what do you guys think that I do block cookware I'm just about to get on that that is a big part of it yep the Chinese firewall specifically um so I'll leave that for a second any other questions before we continue awesome Okay cool so just look like just told some numbers out there back in 2016 if we want to keep 90 of peers on the network what do you think the ideal block size would have been without increasing the fork Grant does any wild megabyte number out there 1.5 megabyte there we go on the other megabytes two megabytes one more guess one more guess oh Bitcoin this is 2016 Bitcoin 20 megabytes oh wow so we found the Bitcoin Maxis on the Bitcoin unlimited if you know your history that's a great clear graph so um so the ideal block if I deleted the slide of course I have so the ideal block size was actually around four megabyte from what I remember was by 4.

2 megabytes or something uh to keep 90 appears on the network and just for that table so what we're saying there is that that table is really saying you know how long like how fast did the top 10 of nodes get the recent block and then how long does it take for 90 90 of nodes do you also get the same block so in the first example for for the second one for one megabyte block ten percent of nodes will get this within 1.5 seconds then ninety percent of nodes will get this in 2.4 minutes so that's a 2.4 minute difference between the top nodes or the Foster nodes and the well-connected nodes on the slowest on the network what impact does this have so that's my little China logo so as I mentioned back in 2016 2017 uh some there were some Forks on the network because the chat like 70 of miners were in China 30 percent were in the rest of the world which implies the Chinese miners got the blocks faster they get the blocks faster well then they can you know start working on it before the rest of the world so they may get like a 30 second or a minute head start on just solving the proof of work and so there was a bass towards Chinese Miners and what actually happened was that you have this private relay Network between all the miners so they just bypassed the peer-to-peer Network altogether because of this issue but basically you know uh block proposers will fall behind if they're you know the 90 nodes in the network on them for proof of stick if it takes longer for four seconds for you to get the new block and you vote for the wrong block or even 12 seconds you may incur some penalties you know if you won't get sloshed and it's not like you want to lose all your money but you might not get like little rewards and your your yield will go down a bit so your yields directly impacted by how well you're connected to other peers and obviously as a verifier well you know the if there's blocks every 12 seconds but I'm getting the block after two minutes well I just fall behind eventually and I just can't keep up with the network I can't get up to the a cup of the database I just fall behind and I'm not useful anymore so typically when we think about the size of blocks we normally assume that the block proposals are very powerful you know they should be able to quickly get blocks execute them and send them out within two to three seconds we assume verifiers are weak so verifiers maybe it takes them you know six or seven seconds to get the block but that's okay because 12 seconds is the deadline so you normally assume you know different specs for different parties and I do have it there there you go four megabytes was what would the report recommended on bitcoin and you still have 90 of nodes participate on the network it's probably much higher now but that's like six years ago why is this all important you know why do we care about this aspect of scalability and it really comes down to you know what does the mean to be decentralized and everyone has different takes and what it means to be decentralized my take is really you know what percentage of the world's population can validate and protect the database in real time so regardless if you're in an Olivia Australia China the US you should have the right to run the software get a copy of the database rather be a blocked in real time or participate as a proof of stake you know sticker validator it's the same for both because that's what it means to be decentralized it's a bit like Captain Planet we put our rings together and we protect the network so there are the bottlenecks you know I've just gone over some bottlenecks that impact the network there's obviously a lot more but there's always good not the overwhelmed people so let's summarize this storage you know the storage bottleneck is really how big is the database uh how big is the blockchain I'm realistically who can you know cut my Hardware deal with that you know the size of that database as we saw his computer GM's lob's computer he couldn't synchronize to ethereum because he ran out of space so clearly his computer could not participate on the peer-to-peer Network so you have to consider storage and you know how big this database gets two is compute how long does it take me to get a copy of the database and be convinced it is indeed you know the the one true database that we all have and right now our proof of work at least you're supposed to objectively follow you from the beginning to the very end and then you know how long does it take for blocks to get across the network and can we fall behind because we just can't get the blocks in time you know what's the latency issues around that and the most important bit is and this is why I don't like transaction throughput as a metric you know if you just blow up the TPS you know the the tip of the chin can become unstable because there's too many forks and then it's also difficult for us to keep up so I think for I remember hearing a stop for polygons so the proof of stay polygon an archival node was growing two megabytes every second and that's pretty damn big isn't it like two megabytes every seconds it goes to 15 terabytes then AWS can no longer handle that in a you know straightforward monitor so anyway that's actually why again the whole point of scalability is that fine balance between block proposers and verifiers and you know how big that database gets so how can we scale by still adhering to what it means to be decentralized and before I get into this was there any questions for the previous section I remember there's no stupid question so the uncle blocks um so you have the answer the entire block is the block header and the block content the block content or the transactions that gets thrown away all we keep around is the block header I know be included in a future block so block one's the block here if block one was the uncle block then maybe the header gets included in Block five so we're still aware that it exists yeah that'll be an uncle block so an uncle block has no impact on the database we just acknowledge it to say that it existed and then you reward the block proposal for doing their job oh definitely I hope I allude a point I think I've got that my style but what he's saying is that you know one of the ways we're going to solve these issues is your knowledge proofs so their knowledge proof is really useful it allows me to do a lot of the hard work to say you know let's just say I want to prove a transactions valid I do all the hard work then I send you the result of the transaction on a small proof that will convince you that it was correct so that way you don't have to natively replay the transactions yourself I give you the result plus the proof and you're convinced is fine but that proving part is very expensive I think a TX uh one or two seconds per transaction on a CPU and you know if you're having to do that for uh when you're proposing a blocking I create a block I make a proof for every transaction that's pretty slow so uh that's still very much a work in progress so that'll be more for the Roll-Ups so the rule apps you would assume there's a very powerful executor you can run gpus paralyze them and do the proofs in real time for proof of stake ethereum it's probably a little while off because proving is still very expensive I mean it's not too it's much cheaper than it was four years ago anyway I think a z cash transaction because that uses your knowledge proofs back in 2015 I think it was 60 seconds on a CPU to prove your Z cash transaction and now it's like a second or something I don't know it's pretty fast I think it's like so he's all stand by the bite size so I think that's more of a problem for Stark so Starks will grow based on how much you're proving where a snark is constant sizes they're funny I forget the bite size with a Freddy Spa but star has a stalker issue yeah they're I think it proves to cost like five million gas and ethereum to verify just for the proof because they're very big but anyway any other questions guys before I continue awesome cool okay so how are we going to solve these scalability issues so just a reminder when we consider scalability for the blog proposer we want to reduce the forcreant we want to make sure no one is wasting their resources when they propose a block and on the verifier side we want to maximize the population of who can validate blocks in real time so reduce the resource requirements to run a node that's basically what we're trying to achieve now over the years since 2015 up to about 2020 and today there's been lots of crazy Wizardry tricks from basic engineering principles on the you know the make it easy to run a node so one is you know you can compress Data before you send it across the wire so when Bitcoin may call that a compact block you know I gave you a block but actually I don't give you the transactions I give you the block you know like the the transaction hash and then you've already got the transaction in your mempool so you can quickly reconstruct a block yourself so you reduce the data you're setting Across The Wire very simple engineering you have private relay Network so in Bitcoin all the miners had a private Network that only they could connect to and probably get blocked so you bypass the peer-to-peer Network completely you know is that you know ideal for a censorship resistant currency it's a different question you know you could do parallel execution we had a question down there before maybe if you access lists you know I know two transactions don't conflict execute them parallel we speed up our ability the volatility of transactions in real time oh no there's also like you know sat reconciliation that's also compact blocks but the issue is that in all of these engineering approaches we're making it easier to do the job but they still have to do it so now a lot of the scalability research is thinking do they need to do it could we take that responsibility away from the peer-to-peer Network and you know give it to a external provider who could do it in their behalf so the peer-to-peer network does the absolute minimum so what's the goal so it should look like this the protect decentralization we work out what is the absolute minimum the peer-to-peer network has to do and what can we offload to Services providers businesses they always make the joke and fewer could do this you know why could you pass off to inferior to protect the peer-to-peer Network and so who's heard of this idea like the monolithic blockchain and the I guess modular blockchain but this says macro Services who's heard of that idea before the monolithic blockchain okay but the last people that I expected actually that's great so I stole this actually from a normal web 2 company because it isn't a new idea you know you build this big monolithic cobius difficult to maintain difficulty upgrade and what you really want to do is take out the little components and maintain them individually and hopefully delete them as well so that's what a theorem has been struggling with for the past six years we had this monolithic blockchain we're trying to do everything at once and now what we're trying to do is Define each of the macro services or the modular components and then of course solve each problem individually so let's go through how we're doing this so first we have compute compute was one of the resources that we cared about you know how long does it take the execute a block what if you could uh have a dedicated execution layer so there's an execution layer that's doing most of the work and ethereum doesn't really care about that all a theorem cares about is the result of that execution if ethereum doesn't have to do the execution well it's way easier to run a node if you don't have to execute anything you know you pass it off to someone else the other one was bandwidth so right now we have to propagate all the transactions and blocks to cross the network you know what if you could have a dedicated availability layer where you don't even care about the transaction content it's like a blob of data as long as there's a blob of data you know you get the blob of data then you can throw it away eventually you know could we have a dedicated layer just for data and a theorem doesn't necessarily care about that either and finally storage what of a node you know didn't have to have a database could you run a node and just delete the entire database and not care about it but the database is stored somewhere else so if you want to transact you talk to the provider you get the database content and then you send it off to the peer-to-peer Network you know could we build a settlement layer in a sense where all it does is minimal competition maybe stores account balances but otherwise it doesn't minimizes what has to store because you push that problem off somewhere else that's the idea behind the modular blockchain it looks like a simple Rini I mean you know I could be a marketing person being like well we're going to solve compute with an execution layer you know I just rename it but actually if you just find like you know if you make this dedicated layer in action then you can think how do I solve this problem so we're just really renaming the resource in a way but anyway where it makes more sense on how to solve it so what this actually leads to is the rule up Centric or the rule up Centric roadmap for ethereum has anyone heard of this the rule up Centric roadmap okay great about five or six people so that's good though because in 2016 ethereum they thought they would solve the world of execution sharding we all realized that was like a moonshot that was too hard to do and then roll up started to emerge and Rule UPS look like sharding in a way and so we've all pivoted towards this rule out world where we do all the execution and Rule UPS and what were actually was really solving the day are bridges you know uh this is how we've scaled cryptocurrencies for the past 10 years so raise your hand if you've ever used a coinbase binance or bit stomp or whatever there you go don't worry I'm not the SEC I'm not here to dox you you know uh but you know realistically speaking in a way cryptocurrency exchanges are like charting you know you deposit your funds in the coinbase you go in the Columbia's execution layer you transact as much as you want there and then you bring the funds back and you're using the theorem as a settlement layer you know the get your phones on and off coinbase but otherwise coinbase is where the execution happens the issue is that I already got the question but the issue is that if you move all your computation the Columbia is Kraken and binance well it sucks a bit doesn't it it's pretty custodial you have to deal with their customer supportive you get locked out there's a private database we have no idea of the art you know of the rsats cover the liabilities we have no proof of reserves we have to blindly trust this execution layer we can't audit it in any way and we can do better than this and that's the goal of this rule up Centric roadmap the goal is to build a bridge that connects to another blockchain system this off chain system that you can check in real time and the bridge will hold your assets you can mint it on this other system transact there as much as you want and then bring your funds back to ethereum you know you burn it on the on this chain and bring it back to ethereum so really bridging is at the heart of how we scale ethereum the vegan dogu Bridges move the computation elsewhere we solve a big Pro a big part of the scalability problem and a theorem then becomes a settlement layer that does minimal competition for the bridging and of course recording everyone's account balances so it really is how it's going to deal with bridging in the future okay so just to summarize what he means is that when you bridge the you put the funds in the bridge you go to this other network there's gas fees here as well and there's also bridging it back that causes funds or you know causes yeah so I think um I mean a theorem should be the most expensive chain so that'll always be expensive so ideally most users oh sorry I'll just finish this one most users should not have the interact with ethereum they just live in these other layers and quickly transfer their funds and because they're the execution layer we can assume that they have like you know like Stark net for example they can aggregate lots of transactions and you know aggregate the cost for everyone so there's still a cost but hopefully it'll be a lot less of ethereum it's the goal good yes that's a great point so what he's saying is that when you bridge your asset to another layer you're taking on the risk of the bridge and we've all seen the binance bridge The Nomad Bridge the real on bridge the Wormhole bridge and other Bridge there's obviously a collective War they'll all keep getting hacked and there's clearly a smart contract risk of using a bridge and then depending on how you've designed your Bridge you may also have risk on the off-chain system as well so that's why the roll-ups you know what they're trying to build is just jump to that now oh actually let me finish this bit so the Roll-Ups are trying to build a bridge where you don't have to trust the off chain system at all so really if the bridge is you know bug free then you should not have to trust the off chain system at all so that's the long-term goal but right now a lot of the bridges are a bit there's a lot of trust on a lot of bridges but anyway so let's go to the settlement layer a theorem is a set of funds and the execution layer are on these off-chean systems that offer a seamless user experience and the point here is that the option database and the execution layer of course the liabilities on the bridge records the assets and the bridges here just to make sure the outside cover liabilities armor taxi user on the off-chan system and how does the bridge protect the assets you know this is sort of the rule up talk where you talk about a validating bridge and how the bridge is designed to protect the funds for now we can just talk about you know how do we guarantee all the updates that the database are valid you know the bridge you get an update from the off-chain system then the bridge have to be convinced that this update is valid and correct and if it's correct then it will accept that that's the new state of the database you know the bridge will always check is every opt-in to this often system valid yes it is the funds are safe and the other one is where the fraud proves versus the optimistic roll-ups the next one is the availability problem and that's really what I want to talk about so if you're on an off-chan system okay and all my funds are locked on I don't know arbitrim what that assumes is that there's one honest party in this room you can come online get a copy of the database and guarantee that all our transactions are eventually executed we can withdraw our funds from the system if that system is malicious and this comes down the data and there's three things to consider you know why does the data need to be publicly available what data needs to be publicly available and how do we guarantee it is publicly available so for these Bridges what you're assuming is that there's one honest party who can get the data recompute the offchain database execute the transactions propose an update to the bridge and let you get your funds out of the bridge now this is very different to ethereum as we've just said for about you know the past 40 minutes they're just trade out between block proposers and verifiers and the resource constraints here we just have to assume there's one on this party there's one honest party out there with enough resources to get a copy of the database and execute the transactions and anyone in this room ideally could be that honest party so it doesn't allow you to go beyond the restrictions of the layer one you create all this big beefy machine this I don't want to say super computer but you have a beefy machine on this network that can you know reduce the fees for everyone because now the main fee on a roll up is not execution the main fee is the data that you push to ethereum that's the biggest cost now for using roll ups um the type of data that you propose to be you know the transaction history to ascend the bridge all the transactions or maybe just an update to the database and why does the state diff between the two databases um how do we make this available you know just to skip over this a bit those are challenges for plasma and sort of field any trust like arbitrary Nitro or Stark net um their data availability committee they have a committee that guarantees the data is available and that one honest party can get the database or a roll up where you take all the data and you post it to ethereum and that's the next part so now we have this settlement layer which is ethereum we have the execution there that's doing all the hard work the guaranteed one honest party can get that database all the data is being posted to ethereum and so ethereum also becomes this data availability layer they guarantee that one honest party can get the database for the off-chain system so the long-term scalability goal for ethereum is to make this data as cheap as possible if you give me a data or bond with cheap then you could have real Ops that are humongous in dealing with you know crazy amount of transactions this is the Dank sharding this is EAP 4844 and this is sort of what they're going towards in the next few releases of ethereum their goal is to make data cheap so roll ups are viable and so this is the case then we push all the hard work off to the execution layer and the protect decentralization we just care about data and we just care about settlement okay that is what we mean by protecting decentralization can you get the data across the network as fast as possible I know there's also you know different networks emerging because now that we've separated our concerns maybe you have a dedicated deliverability layer like so last year polygon novel or a theorem itself of tank charting I have a minimum theorem actually I don't know we have the settlement layer here which is ethereum because they are doing the Roll-Ups and all these different execution layers are emerging they're all solving different parts of that puzzle of how we scale ethereum and so just to summarize oh sorry I'll put that back up I see someone's taking a photo cheers it says to summarize because I know that's a lot to take in by the way as I mentioned we start off easy and then we get very very hard um this is summarized you know there's there's uh we allocate a resource of purpose no data settlement execution now we're solving each of these puzzles individually scalability is really by bridging skill ethereum because we'll move the assets but we'll move the assets to another Network and transact there bridges are a give or tick very insecure but we're working towards building a a secure version of bridges and of course data availability is really the big bottleneck now for how we're struggling with ethereum and just to finish up I've got one minute left is one of the authors last part oh God so the bridge should be able to independently check everything itself so when you give me an update about the bridge you give me the update and I used to be able to check this is a valid update so either you give me a zero knowledge proof so there's a mathematical guarantee I ran a fraud proof right get the update and there's like a one-week window for anyone to convince me that is incorrect so the bridge has to be convinced cool awesome so maybe I'll just finish here um I think this is a great talk we nearly I didn't finish the slides but that's awesome because we had a lot of great content so I'll leave it here and I'll let the next speaker come up because I think he's hanging down there somewhere so thank you guys GG awesome