Real-Time Blockchains: How Fuel's Rollup OS Supercharges Execution - TOKEN2049 Dubai 2024

all right so I'll try to be um really quick and uh just explain some of these uh these ideas and hopefully they'll be useful for people building blockchains right now but um as well if you're building a project and you're shopping around for particular rollups or blockchains um this is sort of a presentation you know for you so um today I'm going to talk about real-time blockchains which um is quite frankly something we all just made up recently uh so it's another term uh we just made it up and there's no fundamental basis for it other than the fact that real time has um some meaning in web to and it's somewhat relevant to the conversation for technical architecture for um web 3 so so effectively um uh imagine a world where blockchain were actually real time by virtue of what you see in the web what does Real Time mean typically it means like less than 100 milliseconds so right now like salon's block times at 400 milliseconds so you can imagine okay well how could you get that a lot faster more Regional um something um where you can actually do a lot more sophisticated work um around the world um and do it in a way that uh uh won't interrupt the user experience for 90 to 95% of users so 100 milliseconds real Time That's sort of what we mean so typically in the span of what we mean by um you know timing and and as well just the life cycles of transactions Etc there's some different notable times that um you can you can actually see in in blockchain itself so um you know hitting an RPC uh usually for a user like anywhere from 100 to 200 milliseconds depending on where it's located uh salana slot times at 400 milliseconds uh fuel um my project our layer 2 finality sitting at around 1 second Cosmos finality sitting around 6 seconds um ethereum block times uh at 12 seconds and an ethereum finality at around 13 minutes and two or two epochs something like that so there's some there's a sort of wide spectrum of of time um that means different things for different users on different blockchains presently um and effectively if you really want to make a user experience that's um you know incredible but you also have many different rollups and many different blockchains and you need to communicate a lot of different information potentially over a global sphere this becomes really complicated because um things are just too slow typically for um the kinds of user experiences that people want um and I'll explain why it's too slow so if you look at um like this is just a an average of global ping times and it's from location to location um basically you can see that you know if you're roughly in a similar region like you know the E for example like if you're going from Stockholm to Paris in terms of your ping time uh you've like a pretty decent ping time like around 30 milliseconds but if you're going from say like Los Angeles to uh to Tokyo then your ping time starts to increase then it goes to 107 milliseconds if you're going from Frankfurt to Tokyo then you know here's where the real problem starts you have about 254 milliseconds on average so the problem is is like if you want to build a global blockchain or you you have a project that wants to be globally accessible and you want the times to be very very fast you're really fighting actually just physics and the ocean to be able to come to consensus um just because of ping time which is really really simple um your your signal can't Traverse the Earth fast enough to really get everything done because it's not just communicating any bit of information around the earth it's also you have to come to consens ensus over what's been communicated and it's very very difficult um and so basically you could see why a team like salana would set their block slot time to around 400 milliseconds because you literally can't chart the Earth very quick uh in general and you need to leave enough time to actually execute all the transactions so we kind of have a big problem here in terms of if we want blockchains to go faster and do more sophisticated things over more sophisticated environments we're kind of fighting physics in order to achieve this um and here's like a really good kind of diagram from uh he.net where you can see some of the underc cables for connecting different places on on planet Earth right now and um you know you can send some pretty sophisticated signals all the way around the world but again you're fighting physics in terms of just how fast that can actually happen and how fast you can actually Traverse the Earth um in order to produce the speed that we're really looking for so we have a lot of problems if we want blockchains to be really really fast and we want them to be highly available we're going to be fighting physics basically in order to achieve what we what we want to get done so like what do really fast blockchains well who really gives a if it's 1 second or 400 milliseconds or whatever isn't that fast enough and you would think yeah that seems totally fast enough 400 milliseconds whatever that seems like it's a pretty good time but you're not factoring in the fact that blockchains are becoming a lot more complicated there's a lot more actors and those actors are very sophisticated and they actually need really really fast um communication time also finality Etc they they need everything to speed up a lot um so some examples of like what I'd call like real power users of blockchain are um block Builders solvers relays uh data infrastructure market makers improvers all these parties actually need things to speed up a lot because they need to get the information to just do whatever they want to do market makers need it to be able to actually assess the current state the view of things and make trades RS need it so that they can send it out to all the different Asic that are available you know in two 3 years from now they'll still need to send out all the information to to actually prove somewhere that you know hey this is actually the the state of things or this is actually how things become final so um so it's a real issue um for for these people and as blockchains progress and as architecture progresses um we're going to be hitting some real serious issues and um basically 1 second to 400 milliseconds is not really going to fast enough so um you know and if if we look at the two different kinds of users regular users versus just like the power users regular users don't really care so you know 400 milliseconds to 3 seconds doesn't really matter um you know 0.1 to one Set uh Cent price Target all that doesn't really matter they're not particularly sophisticated most of these sort of regular users don't really care but for the power users they actually need um they they need a lot faster speed to be ble to get all the work that they want to do um done uh 400 milliseconds is way too slow um it requires more of a real-time view so under 100 milliseconds as well the price target of even 0.1 Cent is far too high for a lot of those actors um and as well they're highly sophisticated so they're typically running servers on T1 lines in you know well positioned locations for them all the time um that that you spend just doing random garble goop is actually really affecting how how they they operate so um when you look at um just like typical sequencer designs right now that are coming up particularly in the rollup space um you you have the transaction it's going to builders Builders are working with sequencers and then uh it's going to rollups and it's actually being proved or um or you have prod proving so you're in an optimistic setting and then eventually at the end of the day it's ending up at ethereum this is a typical trajectory of what we see with the current sequencer designs right now um and the problem is uh as I described before there's some really big physics issues going on with just the the trajectory trajectory of how that is actually unfolding for teams um so even just going from the transaction to the Builder you're already at anywhere from 10 to 250 milliseconds depending on the location right now even that is already too slow so um for these Builders they would love to receive things a lot faster so they can actually execute things in a in a more efficient way and then as well with provs uh similarly you you're also going to have um a very long time between something like say rollup finality post the challenge window um versus like in a world where we had Asic fpgas and you know these these other things for ZK like uh you know effectively you're you're still going to want the information as fast as possible to to prove it um and then you have to go to ethereum layer one at the end of the day if you're really really fast um and and again you know we're we're talking about a a long span of time for effectively those power users that I was talking about before um so even if you have fpgas and as6 for ZK right now um just to get all the information to build the view and actually send all these these proofs around is going to be um something that needs to happen much faster than the way that we're currently designing uh the chains right now um so um settlements is far too late so looking at like ethereum or salana settlement times Etc it's just far too late in the game for um the amount of communication that needs to happen in order to um efficiently build blocks in a um in a blockchain itself so um so we're going to run into a lot of issues um if we don't actually figure out how do we make this system a lot faster um and even if you just consider rollup finality um so just when transactions have been received and could could be even considered final in the rollup phase it's still too late so even with fuel's current rollup time uh finality time of 1 second it's still even too late for a lot of uh uh block building applications everything else if you're also thinking about the time that it's going to take to process say 5,000 TPS over um like a a really really short period of time and then also building those blocks and then getting them out and finalizing them so the pipeline really really sucks um so um a concept that's been applied from the salana slide is basically that you have this Global Network and then you you provide these Global locks on different aspects of state so you lock it off and then um you know that's how they're trying to achieve sort of um the guarantee or assuredness that state transitions are going to happen in a global context the problem is is those signals have to go all the way around the Earth in order to actually come to consensus um and so so unfortunately just Global locks alone on different pieces of State say locking off one section over in Asia and one section over in in America it's going to be really tricky unless you design for it so Global locks just in and of themselves don't work and again coming back to this ping time chart um we're working with very um uh we're working with time scales here that like um really really suck if you have to go all the way around the ocean so unfortunately um you have to come with some kind of Solution that's more Regional so um one idea that's been sort of floated around um to get these um you know sort of the view and um and the communication improved for blockchains um is effectively to have different leaders in different places so you could have a leader in Asia a leader in the the EU West a leader in the EU East um and basically when they're building um and and and and they're leading the chain um effectively this is going to allow you to have sort of faster blockchains times at least for those users the problem is is that you know you could easily commit a double spend here if you don't have the right kind of uh bft system um and that's going to cause you some significant problems obviously because the whole point of a blockchain is to prevent double spends so you're going to run into issues so some possible solutions to kind of improving the regionality of blockchains and improving the um the actual speed of blockchains so there's been some interesting designs in the past um that are somewhat notable um avalanche's leader leaderless bft consensus is an interesting um interesting choice potentially because if you have a more leaderless system maybe you can get leaders closer to where the users are um and then maybe you can build blocks faster there are a lot of caveats though to how that actually ends up working um as well SE had some stuff with twin turbo consensus which is quite frankly all marketing jargon it's BS but the point is at least they're trying to think about more Regional um subcommittees that are going to form and actually process transactions as well espresso has some notable ideas about um sort of using uh very fast blockchains for sequencing um and they're more sensitive to to these times as well there's also happy path and um and sort of like fallback path um style designs that you know in the happy path everything works in the fallback you go to a much slower peer-to-peer consensus um and then there's also things like execution tickets which is basically just trying to speed up the whole process and say well if I'm the leader and I'm the block Builder um I'll give you an execution ticket to say I've executed the transaction even before I've published or build the Block it's just I've executed it it's going in in this order and this is where um where things are happening so in web 2 um I've got 18 seconds I'll try to go through this quick in web 2 how do we how do we deal with this well we have userdefined regionality so users pick a region if you're in Tokyo making a Visa payment you're you're defining yourself there so you're going to be settling within that region um you have Edge Computing and then you have things like asset transactions all these things are going to be used to try to come to consensus quickly in a more Regional setting um basically to skip over some of the ideas the idea is that um if you have builders in different regions and they're coming to consensus in their own way but you have users that are basically saying hey I'm over over here in Asia and I'm not over here in America um if you're really really time-sensitive or you have a time sensitive user um this is the way that you can actually kind of block off different builders in different regions um and you can actually reduce communication overhead significantly um and yes the builders have to communicate eventually to lock off certain aspects of state which is going to be a little slower um but the idea is that for a user you can actually get this execution ticket down to about 10 to 100 milliseconds if you're within the region of where those users are so locking things off actually works really really well um and you would have Regional Builders then you'd have Global Builders um the global Builders it's a little slower maybe it's 400 to you know 1 second but for the regional Builders is very very fast you just need to as a user so to say hey I'm over here in Tokyo or hey I'm over here in LA and then the applications can adjust um depending on the region um and depending on how uh you want building to happen and so effectively using more regionality like Edge Computing you can um bring down execution ticket time significantly um which is which is really great um so there's some some key benefits here uh Builders have more regionality um user preferences are defined in more Regional terms um and basically what this means is is that we can have these Global blockchains but if your app is really time sensitive like U like an order book um you can bring the users over to that more time sensitive region and you can have users participating in that more time sensitive region region the NASDAQ does something similar where they make all the cables the same length between all the high frequency trading firms because they figured out eventually that the physical distance of the cable to where the fpga is in New York actually mattered as to how um things were being processed so speed and regionality actually really really matter your positioning really matters at fuel we care a lot about speed we're building very very very fast stuff with fuel we have um what we Define as the best rollup OS for ethereum and the best rollup OS for blockchain itself um so if you're building things that want to go very fast a lot of TPS uh with no and actually have real genuine fraud proofs through and through um you know definitely check us out um we built the first optimistic rollup for for ethereum and launched that on mainnet um we've done it before we'll do it again um yeah and uh thanks everyone really uh really great chatting thank you thank you