 I guess what we're gonna cover is you know, what is it we actually need to scale and why like what do we mean by scalability? The bottlenecks the scalability today I'm picking some core bottlenecks that we can go over that are fairly simple to grasp and then finally the future roadmap that a theorem 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 is a basic recap of you know, what is a blockchain a block is just an ordered list of transactions a Block has 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 Alice is an inspector so she's a cute little hut and her job is to make sure that every new block that is produced is valid And so what she'll do is she'll get a copy of the blockchain So you'll replay and execute every transaction and eventually she'll compute a copy for theorems database Okay, so the one thing I want to highlight is we have the blockchain Wiz 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 contract a smart contract by code, you know the actual You know the programs state as well and they're two very different things the blockchains history The database is 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 same copy of the database as everyone else So it's widely replicated across the world and I like to call the blockchain a cryptographic daughter trail Because it allows us to audit the database in real time, you know, there's no other than say your bank You can't audit your bank, can you you can order 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 great So the peer-to-peer network, you know, 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 blocks in real time Now the peer-to-peer network is responsible for propagating blocks and transactions It's only goal is the gossip if you have a transaction It goes bad a 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 all has to hop them event a few seconds to see them for blocks On the peer-to-peer network as well are the block per block Proposers and a theorem we call them the validators in the proof-of-stake chain in Bitcoin. They're the miners The block proposals are also on the peer-to-peer network. They're listening up for users transactions and of course new blocks Now the only thing block the block proposals provide is a transaction ordering service They have absolutely nothing to do with what it means for a transaction to be valid They just take user transactions Stick them in a block Order them and then you know send that out to the world. So as an example a 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 botch update, you know for a database You're just doing it every 12 seconds and you're updating everyone across the world their 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 perhaps secure the network because if anyone can get a copy off it Then we can also check that is correct So what does skill ability come in, you know, what why do we care about skill ability? So there's two real people there's two, you know parties we care about one are the block proposers It's really important the block proposers can get the most recent block right away So they can you know take the block check it's correct and then extend the blockchain The block proposers want to converge We 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 Get rejected. They don't make money. They wasted their time and of course You know block 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 skill ability? Well, we really care about other resources, you know, what compute isn't required what bandwidth is required and 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 to validate blocks or even for someone To become a block proposer. Do we have any stakers here? By the way any Eve to stakers There you go over there. You got a couple of these stakers, you know We got to make sure that the resources are good enough so you can run your staker 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 skill ability cares about resources and 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 can have one transaction to explode to the database and then none of what no one 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 called our bullshit because sorry the case because it's all about resources And that's the most important thing we have to consider and how we measure scalability So the week 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 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 bottlenecks. Oh, yeah, what exactly? Yeah It's what we'll get to this sort of the balance there, but that's a good point They got what is the meaning of resources and for the goal of decentralization 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 to run a 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 competition and bandwidth sort of join the gather when we talk about the fork rate So let's jump in the storage. Okay So the storage requirements for a node is, you know, how big is the database? You know, there's a database of everyone's account balance. How big is that? There's something called the mem pool 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 same transaction again You'll just reject it. So it's really the revamped and now the 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 raise 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 confusing Oh, the Bitcoin Maxis have no idea, you know They're always misinterpreting the phrase. 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 What's important was actually quirky about a theorem is that So if you look at the blocks, you know block seven eight nine ten Nodes typically keep around copies of the database. I think it's like 128 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 rate But the idea is that if your transaction got confirmed a block seven and now we're a blocked hen 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 case well, you need to have this database So you can quickly jump back and then do of the new fork and so you have to keep around, you know But a hundred copies of the same database just a deal of reorgs But all the other databases can be deleted. You don't care about your very historical Databases just the most recent copies An archival node is very different And I quote an archival node is something that either scam would run or a block explorer Archival node is where you want to quickly look up historical data. 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 you know the probability of a one-year reorg is very small In fact impossible in proof-of-stake Ethereum But an archival node will run this and that's why when you hear quotes You know an archival node is a two terabytes in storage and a theorem isn't scalable Well, that's because they run an archival node and you know, you don't need all these databases. You just need a hundred of the most recent databases then a print node is Where a print node will discard the historical blocks a print it will just keep around the most recent blocks and the most recent copy of the databases They print 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 We just keep around the most recent data So my question to you guys is you know a semantic slide If you're going to run a node like a block proposal or a verifier, which one would you run? Let's do your reads 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 it. Yep, that's fine. That's a good answer What about an archival node? Would you run an archival node for the network? No, maybe when you come but there's no need, you know, it's a waste of resources. What about a print node? Yep, exactly. That's probably what most people run today You know most people don't 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 trunk so insolidity and a smart contract You can define an event. So let's say it's the vote function if I cast my vote It will emit an event that will tell the world and notify the world that Patrick has caused a vote the way you get an event is when you execute a transaction it produces a transaction receipt and in the receipt is There is the event Importantly most I don't even think archival nodes 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 drawing the beacon, you know for the beacon chain again You just care about the last finalized block after it finalized you 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 the 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 to serve at the peers on the network A print node deletes most of the blockchain. They just keep around I say this gets four blocks And that's the deal with forks and reorgs. It's called reorg safety. I think there's default settings I Think there's a default setting but really know the more you store the better you can handle reorgs So one issue we had was I previously worked on a transaction relayer We had sent transactions and try to guarantee the delivery So we wrote our own blockchain machine the deal of reorgs We would keep around three to four hundred blocks, and you know, obviously copies of the database But if you were this in Robson Robson was a very adversarial network and you'd wake up one day And there's a 20,000 block reorg and the real era was just tip-over Because it just can't do with 20,000 block reorgs. So it really comes down to what network are you running in? You know what so another example is a theorem classic a theorem classic has had 10,000 block reorgs in the past Which would also make a lot of nodes just collapse over because they don't they're not expecting that huge reorg. Oh for reorgs I Think okay, so let me tell me get to the reorg section first. We have a picture off it But yeah, reorgs are less likely to happen in proof of stake You know because part of it was part of the puzzle for proof of work But I will touch on that because there there is still prop, you know a good chance on proof of stake. Yep, exactly So improve of stake is above Optimistically it should be about 15 minutes worst case scenario could be like three weeks 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 I was a good what a node was store So on Bitcoin, this is maybe four months ago when I made this The database was roughly about five gigabyte But if it was an archival node version, it was about 35 gigabyte on a theorem the You know a normal prune a normal database was about 700 gigabyte So the database is quite big on a theorem, you know corner the stuff that I have here an archival node was 10 terabytes And that's normally the number you hear thrown around Twitter by all the Bitcoin maxis But as you know, that's for block explorers an error gone got this down to about 1.9 terabytes I actually forget how but we'll be careful figure it out And then what about the the blockchain itself? I guess it's look here the blockchain So for Bitcoin, you can see that the blockchains about 422 gigabytes was a huge by the way, but in a prune node, they keep around seven gigabytes worth of blocks They discard most of it on a theorem Next slide the blockchains about 200 gigabytes, you know So it's actually smaller than Bitcoin Which is surprising actually given you know, there's blocks every 12 seconds That's generally because blocks are smaller in a theorem than they are in Bitcoin Because we worry more about gas than we do bite size, you know Bitcoin's all about one megabyte two megabyte blocks and it's really about the size of the transactions But here, you know, it's about 200 gigabytes for the blockchain an overall including what's in memory and what's on disk You're probably going to store around 560 gigabytes give or take is around that Like Klein got me this by the way. He's really really thankful for him getting me that picture And of course flood protection, you know, how do we deal with you know, Nala service attacks or the network on a theorem? It's about I got a rough estimate about 100 megabytes. You might store in the worst case So the memory pool has nothing to do with skill ability really so far We're not really hitting any storage problems for dealing with 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 computation? And so there's this really great blog post I'm going to run through by James some lop He runs his every year. How long does it take to synchronize a node? And he has a pretty beefy machine has one terabyte stories 32 gigabyte. That's he help 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. That's don't even know how long that is like five six hours And you're fully caught up on every transaction has ever occurred in Bitcoin. Yep. That's a great question I'm not too sure if this includes bandwidth I don't know they already have a copy of the blockchain or if they're requesting that in real-time Because that latency will cause an issue. Well, I Assume it's 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 I mean it took about, you know, 500 minutes or 400 minutes for Bitcoin. What about Ethereum? So his issue was that Go with the amount out of memory when it was synchronized and it stopped but after five days That's because it has one gig, you know one terabyte storage and he could have more stories to deal with synchronizing But he would estimate it would take about ten days But the important bit here is what's the bottleneck? Why is it taken ten days and synchronize Ethereum and you would think is execution But actually is input and output. It's just reading and writing to the database Here According to the stats that he had you would read 15 terabytes from disk and 12 terabytes back the disk for the first five days of turns off, you know the blocks and there's over five days to do by the way So what'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 disk 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 Right 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 Merkel tree Then you have a hash that represents the entire database, but if you're a 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 stats It's awesome. This is very expensive. So Ergon stopped doing that So they're reading and writing the disk is still about a terabyte after 10 days But actually know they would have also they synchronized they synchronized in Two days, so just removing that one part of the validation you see of eight days We're of time to synchronize the question is do you need to do this? Should you have the hush the entire database and stored in a block header? So an error gone when you get to the most recent block You'll download the database from the peer-in-peer to mat work and your checkup is correct And if it's not correct, then you'll start rolling back until you find the mistake So it's not as an essential check But it's useful if you want to download snapshots from the network off 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 a theorem This can run. I think it's the first point that you made it's just the latency from reading from disk That's why it doesn't work on easy. No hard drives works in SSDs. That's also a great point very good technical point Yeah, they should mean so 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 to see in 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 Salana except not a hitter on Salana, but He's just made a joke that you know some projects is give up on the fact that people can synchronize the blockchain. I Think actually the internet computer you have to get special hardware from their own suppliers They run a note in their network very permissionless, isn't it? But anyway, that's synchronizing as a cool. It's a fun topic to talk about so what about the fork rate? So let's assume all block all block proposals are honestly following the protocol they get a block They extended and they propose a new block no malicious behavior whatsoever by the block proposers So the fork rate is the following. So let's say you have block one and block two Then a magical wild fork appears you can have block 3a and block 3b proposed by two different block Proposers the question is both with which one do you extend? Eventually, you know, they'll get block 4 block 5 and everyone will converge on the longest chain Or the heaviest chain Block 3b becomes a steel block You know that 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 Ferdy's trip forward awesome So The inability so what do we why do we consider the the the fork rate? So what is about this, you know, however liable 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 waiting 20 confirmations And the fork rate is really about how reliable is a confirmation in 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 bond with you then validate the block I wasted your compute but in the end the block never gets in the blockchain So if those wasted your resource for a block that wasn't actually useful So you really want to minimize that fork rate 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 versus 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 1 megabyte block every 10 minutes, if you imagine this being the peer-to-peer network and reaching all the peers in the network Then a 1 megabyte block should fly across, you know, everyone gets this within a second Not much issue. If you have a 1 gigabyte block You know every 30 seconds. Well, maybe you know 1 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 on of course. This is a waste of bandwidth and 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 blocks is greater than two megabytes, but less than one minute You increase the fork rate smaller blocks longer interval smaller fork rate So it's a good way to get you know a good feeling 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 a Bitcoin we only consider megabytes the size of the block on a theorem We consider gas because gas takes into account Bond with 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 ZCOS article there because right now ZCOS is being spammed is costing $10 a day And they're growing 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 around 120 kilobytes. They're 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 and bitcoins, you know one the two 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 1% and one thing the highlight is that on proof of stake Ethereum The block proposal 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 as 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 as 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 with the network And in Bitcoin, I got this picture from February 2022 They happen every one the two months because it's small blocks every ten minutes very rare to have a fork in Bitcoin So what's the ideal 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 give blocks in real time what's the ideal block size and so Actually, what do you guys think that ideal block will quit I'm just about to get on that that is a big part of it Yep, try the Chinese firewall specifically So I'll leave that for a second any other questions before we continue Awesome. Okay, cool. So Just like just some numbers out there back in 2016 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 rate? Does any wild megabyte number out there? 1.5 megabyte there we go any other megabytes two megabytes one more gas one more gas Oh Bitcoin, this is 2016 Bitcoin 20 megabytes. Oh, wow. So we found the Bitcoin maxis and the big Bitcoin unlimited If you know your history, no, that's great. That's a great great gas So um, so the ideal block of it to leave the slide, of course, I have so the ideal block size was actually around four megabyte From what I remember it was by 4.2 megabyte or something They keep 90% of peers 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? Then how long does it take for 90 per 90% of nodes to also get the same block? So in the first example for the second one for one megabyte block 10% of nodes will get this within 1.5 seconds Then 90% of nodes will get this in 2.4 minutes So as a 2.4 minute difference between the top nodes or the faster nodes and the well connected nodes I'm the slowest on the network. So what impact does this have? So that's my little China China logo. So as I mentioned back in 2016 2017 some there were some forks on the network because The China like 70% of miners were in China 30% 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 bias towards Chinese miners and what actually happened was that you have this private relay network Between all the miners. So they just bypass the peer-to-peer network altogether because of this issue but basically, you know Block proposal will fall behind if they're you know the 90% nodes in the network on on proof on stake for proof of stake 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, so you won't get slosh It was not that you won't lose all your money But you may not get like little rewards and your your your yield will go down a bit So your yields directly impacted by how well you're connected the other peers And obviously as a verifier Well, you know 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 then 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 we normally assume, you know, different Spacks for different parties and I do have it there. There you go Four megabytes was what would the report recommend it on Bitcoin? I knew I 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 of your annual Libya Australia, China, the US You should have the right to run the software get a copy of the database Valid the a block in real time or participate as a proof of stake, you know staker validator It's the same for both because that's what it means to be decentralized It's barely kept implanted. You know, we put our rings together and we protect the network So they're the bottlenecks, you know, I've just gone over some bottlenecks that impact the network There's obviously a lot more But as always it's good enough to overwhelm people So let's summarize this Storage, you know, the storage bottleneck is really how big is the database? How big is the blockchain? I'm realistically who can you know, how my hardware deal with that, you know The size of that database as we saw his computer James Lops computer He couldn't synchronize go a theory and because he ran out of space So clearly his computer cannot participate on the peer-to-peer network So you have to consider storage and you know, how big this database gets To his 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 or proof-of-work at least you're supposed to objectively Validate from the beginning to the very end And then body 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 chain 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 here to start for polygon So the proof-of-stake polygon an archival node was growing two megabytes every second And that's pretty down big isn't it like two megabytes every seconds against the 15 terabytes Then AWS can no longer handle that and a you know, straight forward monitor so anyway That's actually why again the whole point of scalability is that fine ballins between block proposals and verifiers and you know How big that database gets? So how can we scale why 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 So you have the so 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 and they'll be included in a future block So if block ones the block hit block one was the uncle block then maybe the header gets included in block 5 So we're still aware that it exists. Yeah, they'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 or bulls if we're doing their job. Oh Definitely, I hope I alluded point. I think I've got that my side But what he's saying is that you know one of the ways we're going to solve these issues There's your knowledge proofs. So they're knowledge proof is really useful It allows me to do a lot of the hard work to say, you know, that'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 a proof and your convince is fine, but that proving part is very expensive I think it takes one or two seconds per transaction on a CPU and you know, if you're having to do that for When you're proposing a block, you know, I create a block. I make a proof for every transaction. That's pretty slow So that's still very much a work in progress So that'll be more for the rule ops. So the rule ops you would assume There's a very powerful executor who can you run GPUs paralyze them and do the proofs in real time For a proof of stake a theorem is probably a little while off because proving is still very expensive I mean, it's not too as much cheaper than it was four years ago Anyway, I think a z-cast transaction because that uses your knowledge proofs back in 2015 I think was 60 seconds on a CPU to prove your z-cast 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 also in bed 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's ball, but start as a starker issue Yeah, they're I think it proves to cause like five million gas in a theorem They're verified just for the proof because they're very big, but I am any other questions guys before I continue Awesome. Okay. So what how are we going to solve these skill ability issues? so just a reminder When we consider skill ability for the blog for proposer, we want to reduce the fork rate 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 widget retreats from basic engineering principles on the you know To make it easier to run a node. So one is, you know, you can compress data before you send it across the wire So on Bitcoin, we call that a compact block, you know, I give you a block But actually I don't give you the transactions I give you the block, you know, like the the transaction hush 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 sending across the wire very simple engineering And you have private relay networks So on Bitcoin all the miners had a private network that only they could connect to And probably get blocks. 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 to validate transactions in real time And there's also like you know set 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 skill ability 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 always make the joke and fewer could do this You know, what could you pass off to infura 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 is micro services. Who's heard of that idea before the monolithic blockchain? Okay, but the last people that I expected access 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 co-base Difficult to maintain difficult the 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 where this monolithic blockchain Where it's trying to do everything at once and now what we're trying to do is define Each of the micro 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 executed block? What if you could have a dedicated execution layer? So there's an execution layer that's doing most of the work and a theorem doesn't really care about that All a theorem cares about is the result of that execution If a theorem doesn't have to do the execution Well, it's way easier to run a node if you don't have the execute anything, you know, you pass it off to someone else The other one was bond with So right now we have to propagate all the transactions and blocks across the network, you know What if you could have a dedicated data 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 It could have a dedicated layer just for data and a theorem doesn't necessarily care about that either and Finally storage What if 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 the settlement layer in a sense where all it does is minimal computation Maybe stores account balances, but otherwise it doesn't minimize as well as the store because you push that problem off somewhere else That's the idea behind the modular blockchain And it looks like a simple renaming, you know It could be a marketing person being like well We're gonna 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 real renaming the resource in a way, but in a way where it makes more sense and how to solve it So what this actually leads to is the rule up centric are the rule up centric road map for a theorem Has anyone heard of this the rule up centric road map? Okay, great about five or six people. So that's good though because in 2016 the theorem they thought they would solve the role of execution sharding We all realized that was like a moon shot that was too hard to do and then rule up started to emerge and rule ups Look like sharding in a way And so we've all pivoted towards this rule up world where we do all the execution and rule ups And what we're actually was really solving the day are bridges You know This is how we've skilled cryptocurrencies for the past ten years So raise your hand if you've ever used a coin BS 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 But you know realistically speaking in a way cryptocurrency exchanges are like sharding, you know You deposited your funds in the coin BS You go in the coin BS execution layer you transact as much as you want there and then you bring the funds back And you're using a theorem as a settlement layer You know to get your funds on and off coin base, but otherwise coin base is where the execution happens The issue is that already got the question, but the issue is that If you move all your computation the coin BS cracking and binance Well, it sucks a bit doesn't it is fully custodial you have to deal with our customer supportive you get locked out There's a private database We have no idea of the out, you know of the assets cover the liabilities. We have no proof of reserves We have the 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 road map 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 to system Transact there as much as you want and then bring your funds back to Ethereum. You burn it on the on this chain I'm break it back to Ethereum So really bridging is at the heart of how we scale Ethereum that we can build good bridges and move the computation elsewhere We solve a big problem a big part of the scalability problem And a theorem then becomes a settlement layer that does minimal computation for the bridging and of course Recording everyone's account balances. So 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 his 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 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 Those 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 make you know like stark net for example They can aggregate lots of transactions and you know aggregate the cost for every one So there's still a cost But hopefully it'll be a lot less of the area to go good Yes, that's a great point So what he's saying is that when you bridge your asset to another layer You're taken on the risk of the bridge and we've all seen the Binance bridge the Nomad bridge the Ronan bridge the wormhole bridge Another bridge. There's obviously a collective war. They'll 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 I just jumped 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 right now. A lot of the bridges are a bit There's a lot of trust on a lot of the bridges But anyway, so let's go to the settlement layer a theme was a set of funds and the execution layer are on these off-chain systems That offer a seamless user experience and the point here is that the off-chain database and the execution layer records the liabilities and the bridge records the assets and the bridge is here just to make sure the arts has couple of Abilities and protects the user on the off-chain system and how is the bridge protect the assets? You know, this is sort of the roll-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 to the database are valid? You know the bridge you get an update from the off-chain system Then the bridge has 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 that bridge will always check is every update to this off-chain system valid. Yes, it is the funds are safe another one is There's one of the fraud proves versus the optimistic rule ups the next one is the availability problem And there's really what I want to talk about So everyone in off-chain system Okay, I'm all my funds are locked on. I don't know arbitrage 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 making withdraw funds from the system if that sentence 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 off-chain 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 aetherium As we've just said for about you know the past 40 minutes There's just trade-off between block proposers and verifiers and the resource constraints Here we just have to assume there's one honest 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 does allow you to go beyond the restrictions of the layer one You could 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 post to aetherium That's the biggest cost now for using roll-ups The type of data that you were supposed to be you know the transaction history So you send the bridge all the transactions or maybe just an update to the database And what is the state diff between the two databases? How do we make this available? You know just to skip over this a bit There's a challenge process for plasma. It's sort of failed any trust like arbitrary nitro or stark net There are 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 We take all the data and you post it to aetherium and that's the next part So now we have this settlement layer which is aetherium. We have the execution error that's doing all the hard work The guarantee one honest party can get that database all the data is being posted to aetherium and So aetherium also becomes this data availability layer The guarantee that one honest party can get the database for the off-chain system So the long-term scalability goal for aetherium is to make this data as cheap as possible If you can make data or bond with cheap Then you could have roll-ups that are humongous and dealing with you know crazy amount of transactions This is the dank sharding. This is EIP 4844 And this is sort of what they're going towards in the next few releases of aetherium 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? And now there's also, you know, different networks emerging because now that we've separated our concerns Maybe of a dedicated deal availability layer like Celestia, Polygon Oval or aetherium itself of dank sharding. I Have a minimum of aetherium max. I don't know We have the settlement layer here with the aetherium because they're doing the roll-ups and all these different execution layers are emerging They're all solving different parts of that puzzle of how we skill aetherium. And so just to summarize Oh, sorry, I'll put that back up. I see someone taking a photo. Cheers 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 This is summarized, you know, there's There's a we allocate a resource of purpose, you know, data settlement execution now We're solving each of these puzzles individually Skill abilities really by bridging Bridging is how we'll skill aetherium because we'll move the offsets what will move the offsets to another network And transact there Bridges are give or take very insecure, but we're working towards building a a secure version of bridges And of course did availability is Really the big bottleneck now for how we're struggling with aetherium and just to finish up to about one minute left I was one of the others last part. Oh, what? So the bridge should be able to independently check everything itself So when you give me an update of I'm the bridge you give me the update and I see all the 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 a go one week window for anyone that convinced me that is incorrect So the bridge has to be convinced Cool Awesome. So maybe I'll just finish here. 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