Arbitrum 🛠 ETHGlobal India 2023 Workshop
ETHGlobal India 2023·Pragma (ETHGlobal)·Wed, Oct 9, 2024, 12:00 AM
Join us for an Arbitrum workshop! Embark on a journey with ETHIndia, where innovation thrives, collaboration knows no bounds, and hierarchies fade into self-sovereign ownership. The most skilled web3 developers, designers and product builders from all around the globe came together for a weekend-long adventure to advance the Ethereum ecosystem at ETHIndia in December of 2023! ----------------- Follow us: https://x.com/ethglobal Check us out: https://ethglobal.com Email us at: hello@ethglobal.com
Transcript
[Music] I really want to go my name is Patrick mccy by the way and I work at the arbitrum foundation but we're not really going to talk about arbitrum per se during this Workshop what I really want to do is give people here an appreciation for what does it mean to skill something like ethereum what are the skillability botton necks for ethereum and hopefully by the end of this Workshop you'll have an appreciation for why we should even care about R Ops as a way to scale ethereum so it's a bit like a history talk Going Back to Basics and hopefully picking up along the way how we sort of struggled to scale this network so Back to Basics how does something like the ethereum network work so as everyone's aware we have a blockchain you know block one block two block three and inside a block we have a list of ordered transactions and the fact that transactions are ordered is critical when you think about stuff like me you know front running back running subing it's all the knable because we have a canonical history of all transactions and all transactions have a single ordering now what about Alys Alice is an inspector and Alice wants to understand or Alice wants to see what is her Ballance on ethereum and she wants to be convinced what her balance really is so what she'll do is she'll join the network download the blockchain and execute the blocks in order you know block one block two block three up to the most recent block on the network and by processing the blocks what all should end up with is a copy of ethereum's database and then she can check her Ballance and she can say yep I have one or two coins on the network so if there's one takeaway from this Workshop if there's only one takeaway that you guys remember the whole point of a blockchain is just to allow anyone to Compu a copy of the database it's a bit like a cryptographic audit Trail I execute the blocks in order and I can get the same database as everyone else and that's the only thing the blockchain really does and then the second component is the peer-to-peer Network so Alice wants to send some coins she's on her metamask she you know puts in the transaction details she signs the transaction and then she'll want to get that out there and eventually confirmed on the network the way this is achieved is using a peer-to-peer Network or gossip protocol and the whole point of the peer-to-peer network is to broadcast recent blocks and recent transactions and I believe today ethereum's peer-to-peer network has about 30,000 nodes maybe someone in the audience can double check that but it's a pretty big damass peer-to-peer Network it's pretty D big there's 30,000 nodes facilitating this interaction and of course you can join the peer-to-peer Network you can download the blockchain that's where you get a copy of the blockchain and then of course compute a copy of the database yourself now the one of the big purposes of the blockchain is so allice can send her transaction it'll be sent across the network in a few seconds and hopefully a block proposer will pick up the transaction and confirm it and finalize that transaction so when you think of the miners or the pro or the stickers what these proposers in general are offering is a transaction ordering service we trust the proposers the order transactions in our behalf and generally speaking on ethereum they'll pick up the pending transactions ordered by fee and then confirm them based on you know whatever is going to pay them the most money so they're trusted to do this we trust proposers to confirm transactions but thankfully we don't really have to trust them because they they have a financial incentive to do that the more transactions they confirm the more tips they pick up the more money that they meet M so again the user sends the transaction to the peer-to-peer Network and then it'll eventually reach the block proposer now what's important here is that the transactions are kept so if you're running the node software so you're running go ethereum or Aragon or nethermind every new client has a special piece of storage called the mle which is really just the pending transactions they're not ordered and they're just waiting to get confirmed in a block it's really to prevent flood attacks on the network so they're all you know every block proposer has a CMM pool roughly and of course they'll produce a Block they'll produce a block that confirms these transactions they'll send at the every single peer in the network that takes about one or two seconds and every single peer in the network will get the block execute it check that it's correct and then they'll update their copy of the database and so when you think about this process all that's really happening is that the block proposers propose a block send it to the network and it's a bit like a botch update every 12 seconds there's a new block and there's a new botch update for your database and that's basically in a nutshell how something like ethereum works today and what's really nice about this system is that because it does work by the way because hopefully we've all used it I don't know you know re your H you used ethereum before let's check awesome look at that so everyone realizes this does work to to an extent what' you get from this is a global bulletin board a bit like this screen everyone in this room can have a copy of exactly the same database so they have a consistent view of what you know the state of the network the smart contracts the exchange rates whatever and what can you build with this where you can build auctions voting tokens transfers gambling nfts and art speculation trading amm that's all enabled because everyone in this room can have a consistent View of the C database this single database is widely replicated so where does scalability come in if this is how the system works what does it mean the skill this type of system well we have to consider two actors the first are the block proposers and really when we think about skillability what are the minimum requir what are the minimum resource requirements needed to be a proposer on the network and ethereum that is what are the minimum Hardware requirements or bondwire special what are the minimum requirements the volid new blocks in real time so everyone in this room what are the minimum requirements for you to run a node process blocks in real time and compute the exact same database as everyone else so what we really care about when we think about skillability is compute bandwidth and storage keeping in mind how do we decentralize both of these actors so we can maximize who can participate in the network so scalability cares about resources and that right balance between proposers and verifiers it has absolutely nothing to do with transactions per second so if you leave this workshop and you say oh potty was telling me that TPS is the source of skillability you never took this Workshop guys nothing to do with TPS TPS is like a proxy off this problem so back to BSC we spoke about the block proposers they offer an ordering service to the network we spoke about verifiers you know anyone in this room can download the blockchain process blocks and check that everything's correct there's a peer-to-peer Network and we spoke about scalability so what are the scalability problems fac today and my goal here is to give you a taste of those problems so first we're going to start with bandwidth as the resource how long does it take for a transaction to get across the network and in this case we're going to assume the entire system's honest all the block proposers are honest everyone in this room's honest the peer-to-peer Network's honest there's no malicious behavior is the ideal is the best case setup so when we think about bandwidth what we really what what we really talking about is the fork rate and re your hand have you've heard of the fork rate before awesome a few people great that's a perfect audience then so what do I mean by the fork rate so so let's say there's two blocks created at the same time block proposer a create a block 3A and block proposer and block proposer B created block 3B the issue here is that we have two competing blocks and they're both valid blocks but only one block can get in the blockchain so let's just say I said I created a transaction and I sent Alice one e and that gets confirmed in Block 3B okay so all this just going to get one e at as long as block 3B remains in the blockchain the issue that arises is what if 3B gets discarded block 3A get minted then block four then block five so the top part becomes a canonical chin block 3B it's not part of the chin it gets discard it so in this case out of six blocks we have a 16% Fork rate and that what that really means is that the Network's not reliable in the short term I can get a a transaction confirmed all confirmed reconfirmed and then maybe discarded and that sucks from a user experience you know if your transaction gets a confirmation then that should hopefully lead to more confirmations and you shouldn't be in the state of limbo where it's sort of going to get confirmed and it doesn't get confirmed then it gets dropped then it gets back in you know that doesn't help the user so that's what the for create is about how do we minimize competing blocks so there's only one canonico chain that's always being built and again as I mentioned why do we consider this because if the blockchain tips on stable it's just bad for the user because the Network's not reliably confirming transactions and as part of this when you think about the fork rate there's two components to it one how long does it take for a block or sorry what is the length of time it taks for a block to reach the entire network so if I produce a block how long does it take for everyone in this room they get a copy of that block and the second component is frequency how often are blocks created and produced so let's use some simple examples Big versus small blocks if you remember the block size Wars so let's consider a small block world there is a one megabyte block every 10 minutes so in this scenario it's one megabyte is really small it's going to zap across the network really fast within you know maybe five six seconds everyone in this room can get a copy of that block you will process it and you would have updated your database and if there's a block every 10 minutes then there's a very low probability that a competing block was created by the time your block was getting across the network so there should be very few Forks intuitively the flip side to that is what if there's a one gigabyte block every 30 seconds it w't gabay block then it's probably going to take me a minute they get it to everyone in this room so every everyone gets a copy of my block so as the blocks going across the network maybe someone over there in the front row you're a block proposer you create a competing block you didn't get my block in time you're still working on the old block so then you create your block then you brast that out and you have two gigaby you know you have two blocks going out and trying to get across the network and then maybe of course there's a third block and obviously this isn't working this sucks for everyone involved because one the network is on able and you're just wasting bandwidth there only one of these blocks get confirmed at the end so the question is can you get really good numbers on this and for the sake of time oh actually not for the sake of time I got it here so to put some good numbers on this and this is about a year old now I think the slide is an ethereum blocks her about 120 kilobytes and they're every 12 seconds and on bitcoin they're 1.2 megabytes and there every 10 minutes so in perect work ethereum before the merge there was a fork grid of about 5 to 6% and that clearly sucks for the users involved with per ethereum it's less than 1% now and that's really because protic ethereum nor synchronist they're strict their lines to do stuff so people know when they create a block when they volid dat a block it's much more structured system where on bitcoin there's a fork every one to two months they're so uncommon that bitmax writes a blog post when there's a fork you know because it's a big event in Bitcoin that there was one fork and one steel block um so what's the ideal block size in interval that's always a moving Target based on the you know the composition of the peer-to-peer Network so there's a research paper called ons scaling decentralized blockchains is from 2016 I think at the time it recommended a 4 megabyte block every 1 minute but back then that was like like God that's like eight years ago now the Network's way more way more effective than it is than it was back then but when you're thinking of this question you know this tradeoff the ideal block size and interval the question is really what is what percentage of the world's population could download that block process that block and pass it on while keeping up with the network you know if ion pro has a block every 10 seconds well there's a block every second then I just fall behind you like get the block I process it I pass it out oh no now there's T blocks and then I just can't keep up with the network I can't keep up with the latest state so it's just not useful for me I'm always behind so you have to really consider you know if someone's in Africa Australia us you know Hong Kong whatever you have to consider you know 90% of the population be us in the peer repair Network today what are the realistic settings that you could put so they can actually get the blocks in real time so let's B withd Fork rate hopefully that gives you a sense of the bandwidth problem the next one is hardware and compute and there's this really and really the question is how long does it take the computer fres copy off the database from scratch so if you download go ethereum today or Bitcoin core how long does it take you from scratch to get up to De with the network and jamesl does an experiment every year testing exactly this problem and it's agre I'm sure you'll do one in a few months is normally around the new year so look out for this blog post it has a relatively beefy machine one tbte storage you know six I guess core i7 some CPU regardless let's look at the results so in 2021 he was able to syn a Bitcoin full node from 2009 till today know every single block and about 400 minutes that's pretty damn fast to Pro says 14 years wor of transactions on ethereum well um uh go ethereum node ran out of dis space so he wasn't actually able to complete the task and this was after 5 days and 21 hours and then he you know B on the the work he suspects it would take 10 days to sing go ethereum again this is 2021 two years ago but the most interesting part of this is at the time of the crash gum had 15 terabyt reading from disk and 12 terabytes writing to disk and as you're going to see the database isn't that big the database is like 600 gabes so why is there so many I operations seems a bit much and actually what he worked out was executing transactions is not the bottleneck is IO reading and writing to the database itself that's the Boton neck and ethereum today so then if you look at Aragon because he run Aragon because he really does just want to syn synchronize a node with Aragon he was able to finish it and interestingly Aragon's iio was much better it went down to 1.9 terabytes and 1.8 terabytes so the question is why did it take why would it take 10 days to sing go ethereum but only two days and 16 hours of SN Aragon with a lot less IO the reason is because of this tweet and let me give you some detail so in a block header we have something called the state route the point of the state route is that it's a single H that represents a commitment to the entire database at this point so you can consider the database you build a Merkel tree or Patricia tree you end up with a single HH and you're put than the block header the reason why you have this is because if I want to prove what your Ballance was at a certain block I can use the steer route to prove at you know an entry in the database so I can prove to you what your Ballance is or what you know the size of an LP pool I can prove to you information about a block at a certain time so that's why it exists but a gone stop checking that it just skip that check all together and I was like whoops not going to check the steer route is too expensive so what they would do is you would synchronize from the Genesis block up to the latest block and if I remember correctly they would randomly sample previous Ste routs with the random sampling they would get some guarantee to say well there's probably all the St roofs are correct you need you know check a subset of of them but that's interesting you know to get over the AO issue you have to stop fully validating blocks so there's a present takeway here is really executing smart contracts in memory you know it is expensive but I is actually the real bottleneck and other blockchains you know this is a gam just from his tweets and definity they just give up on the issue you have to buy your Hardware from an approved supplier to run a node and even in salana again this is 2021 they have these crazy requirements that most people aren't going to have at home like 128 gab Ram I don't know what it is today that's from 2021 but it's just but and that's also isn't a wrong choice this is a a design choice on how many people in this room could validate the blockchain in real time that's really the decision here and obviously there's a spectrum so that's compute hopefully that gives you a taste and a flavor on the computational problem what about storage so when we think of storage there's three different things that we store one is the database the me pool those pending transactions and then the blockchain itself and the question is what's the minimum data required to run a node on validate new blocks in real time so a copy of the database and I think this is from 2022 the Bitcoin database is really small it's about 5 gigabytes it's not that large where when I checked ethereum a normal node a full node which we can talk about later is was about 700 g gabes it's probably a bit bigger now and then an archival node was you'd only run if you're an Explorer because it's really making it easy to look up historical data 10 terabyt for go theum back then or about two terabytes for Aragon but the problem with the database is that the database never gets smaller and I'll illustrate this with a with a question how many people like who in the audience write smart contracts raise your hand if you write smart contracts okay raise your hand if you delete data in your smart contract no one no hands look at this great citizens of the world and that's important cuz the database never gets smaller because no one deletes data so this database is always growing if I remember right um this is like two years ago I think on polygon and this was an archival note you know pin to self there but I think their database was growing or their storage requirements were growing two or one megabyte every two seconds that sound like a lot but eventually gets to 15 terabytes and it doesn't fit in AWS anymore and it never gets smaller so that's one of the big Bott knacks on ethereum a copy of the blockchain for Bitcoin is actually quite big it was about 400 gigabytes at the time and that's just because Bitcoin transactions are bigger because of the utu model than ethereum and on ethereum is about less than 200 gigabytes when I had this screenshot I think that was a year ago it's probably not that much bigger now maybe someone in the audience wants to check if you go ethereum installed and then finally the M Pool the me pool's that's like back of the envelope it's about 100 megabytes it's not really a bottleneck when it comes to scalability and it's really just to stop flooding of the network if I hear a transaction once I don't really want to send it again so that's you know they give you a f of the resource requirements we looked at bandwidth compute storage and we're really just understanding okay these are the problems on ethereum today when it comes to scalability so pup quiz I actually forgot I had this here why do we have the gas price on a gas limit on ethereum the reason why we have it is because we need to prioritize access to block space block space is our most scar resource so if there's high demand and high congestion the gas price goes up and only the people willing to pay the most money can get access to the block space but the reason for the gas limit is really the limit the maximum growth off the database and basically compute on the network if the gas from is 30 million gas or period of a year we can have a rough estimation to say maybe the database would grow 20 Gigabytes this year where if the gas limit was bigger then of course the database would also get bigger because it's just cheaper to transact so the gas that's really there to prevent the growth of the database and then compute is like the second priority after that so again you know a bit of a summary we look the stories compute bandwidth and the problem is if you just blow up the transaction through put you want to support 1,000 transactions per second the blockchain just becomes unstable at least the more Forks it's bad for the users and then people in this room you won't be able to keep up because there's too many transactions DS gets too big like Json couldn't run go ethereum doesn't help so to the final part is fighting back how can we skill something like ethereum while trying to adhere to the principles of being decentralized I.E maximizing who can participate as a proposer or as a verifier running a node at home so you can just have a copy of the database yourself so skillability has two goals one reduce the fork R Fork R should be highly reliable for everyone involved and two maximizing the population of nodes so everyone in this room can run a node and and verify that the database is correct and have access to the database for whatever whatever dep you're building and there's lots of widgy Tricks we can do to bring this down lots of widgy tricks from engineering now we you can compress data over the wire maybe have a private relay Network Bitcoin had that for a very long time where you bypass a peer-to-peer Network completely and the blocks are send directly to the minor maybe a parallel execution if transaction one and transaction two they don't interfere with each other why not run them at the same time so they're you know they're parallel and you're not just running everything sequentially or maybe you make better use of the bandwidth using special cryptography tricks so this is needed and this should be implemented so basically given your set of resources you're making the most efficient use of those Resources by doing this so you don't increase you know the storage or the bandwidth or the compute but you're making better use of the resources that you have but it only goes so far so need so many widy tricks you can do at that level as we saw with the block size Wars and over the past couple of years so is there another way is there another way to solve this problem and the way we like to think about it in the in the L2 world is can we protect the peer-to-peer Network can we protect decentralization of the peer-to-peer Network such that the peer-to-peer Network can check the results but you move all the hard work out of the network so ethereum is no longer storing the database ethereum is no longer Computing all the transactions a theem is just checking the result of what H what happens somewhere else so all the hard work happens over here you have different resource requirements over there but on ethereum we just check the results we don't actually do the hard work ourselves how we do that and this is sort of the play on you know the monolithic architecture versus the macr service serves or the modular you know sort of narrative or theme right now ethereum is trying to do all the work itself can you move the work elsewhere and what this is sort of led to is renaming the resources the special layers so compute is now the execution layer bandwidth is now the data availability layer you know can I guarantee the broadcast of data and it reaches everyone in this room at a certain time that's now the da but it's really just bandwidth and then three storage the settlement layer where is the database that records all the assets and it is the source of Truth itself and it may look like you're simple renaming but by renaming these resources Del layers we can solve each problem individually and of course hopefully scale the network and so for the final part because only have a few minutes left all of Chen and the multi Chen world so the way this works works for you know the road map the rollup Centric road map is you take your co co coins you lock it into a bridge then you unlock it on an aan system you transact there then you bring the coins back to ethereum so what is the achan system so let me ask the audience who's ever used an exchange before who's used binance coinbase bitstamp there you go we found the people who bought the coins I'm only joking but what's important is is that this is how we've actually scaled the network for the past 14 years you take your coins in ethereum you put it in this bridge then it pops up on coin beas crack in binance you perform all your transactions there then you bring your phones back so this is actually help you've already scaled you know Bitcoin and ethereum in the early days were an inability solution for the exchanges you buy your coins in coin beit you move it to binance you mess them up with the shitcoins then you move your funds back and people aren't actually using the cryptocurrency they're using the the exchanges but the problem of exchanges is one I mean most people here are aware now they're fully custodial they can freeze their funds they can confiscate our funds maybe they'll use our funds to buy some up you know some uh Villas in the Bahamas they can lose our funds they're not auditable you know I can't check if they're solvent I can't you know I can't even check if uh have they've been audited you know there's no way they audit the system to make sure that every transaction process there was actually correct we just have to trust the operator to do that and that sucks so could you help the offchain system to be a blockchain where I take my coins I Bridge it over it's another blockchain I transact there and because of the blockchain be a system I can verify the blocks you know I can download the blocks I can execute them and I can check that everything's correct and then eventually I bring my funds back to ethereum and what's nice here is that if you can do this ethereum becomes a settlement layer and all the hard work happens on this other blockchain system and with the bridge you can then check your assets against the liabilities you know the assets are on ethereum liabilities on this offchain system you can check that they're correct you can have full-time audits Orr realtime audits it's just a much better tax stack for building these type of off Chan systems and that's why we're trying to build rops when you think about rule Ops they're really just replacing these custodial Services the arbitrium stares optimism zking Scrolls it should eventually feel like you're interacting on an offchain system but in a way where you don't have to trust the operator and that's my final slide so thank you guys for listening
Automatic transcript — names and jargon may be misspelled.