Ethereum Foundation DevCon 6 - Layer 2s Track, 13 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: ELI5: Scaling Ethereum by Patrick McCorry | Devcon Bogotá

Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/eli5-scaling-ethereum/

Everything you wanted to know about approaches to scaling Ethereum

Speaker(s): Patrick McCorry
Skill level: Beginner
Track: Layer 2s
Keywords: scaling

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

A

A

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

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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?

A

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.

A

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.

A

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.

A

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?

A

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.

A

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?

A

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.

A

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.

A

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.

A

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.

A

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.

A

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?

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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

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?

A

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.

A

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.

A

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?

A

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.

A

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.

A

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?

A

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?

A

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.

A

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.

A

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?

A

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.

A

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.

A

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.

A

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?

A

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.

A

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?

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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?

A

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.

A

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.

A

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!

A

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?

A

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?

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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?

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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?

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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?

A

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.

A

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?

A

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?

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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!

A

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

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?

A

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?

A

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.

A

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.

A

So, if you're on an off-chan system, okay and all my funds are locked on I, don't know arbitrim.

A

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?

A

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.

A

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.

A

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?

A

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.

A

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.

A

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.

A

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.

A

Okay. That is what we mean by protecting decentralization. Can you get the data across the network as fast as possible?

A

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.

A

And so, just to summarize, oh sorry, I'll put that back up I see someone's taking a photo cheers.

A

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.

A

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.

A

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.

A

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.

A

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.