Endstate of High Throughput Blockchains with CTOs - TOKEN2049 Singapore 2024

we have all founders and very deep technical Founders on the stage so we're going to skip intros and get right into it I think today a lot of the blockchain industry has really been uh focused on low throughput chains you guys have each taken the stance that chains ultimately will be high throughput so I'd love to start the conversation there absolutely so I can start off I mean I think in the context of ethereum like it's not that it's a theoretical thing I think it's a pragmatic thing of like why is low throughput not working like you look at it say you look at ethereum today you see 12C block times processing about a million transactions a day costing around $12 a transaction or something like that and so there are some things you can do with that there's a lot of things you can do with that actually uh but it turns out like most of those things are high value defi uh and so if you want more use cases like you're going to need to have more throughput because that lets you have lower fees because you're not letting folks box out you want to have lower latency because that opens up the use cases that you can do and so I think like you know it I think there's going to be broad agreement on this panel but like that's the the thesis for why uh you need more throughput than you know we have in the the evm land today and ke I I think the monad team has been Express explicitly opinionated that the evm landscape needs higher throughput kind of going from kilobytes ultimately to megabytes and Beyond what's your take on that yeah I think at the end of the day um ethereum has proven out the incredible value of shared Global State and the incredible value of a World computer where um anyone can run a node anyone can verify the state of any transaction but I think when it comes to pragmatism like if you're a small business owner and you're trying to accept payments um you know using crypto rails you want to be able to run a full node to be able to actually verify that you know when someone sent you a transaction that sent money you can let the person walk out of the store or drive off of the Tesla lot or whatever it is um and be sure that there was no double spend um per se and in order to really facilitate that that story and have crypto be this means of settlement we just need to scale to a much higher throughput but the good news is that we're currently starting from a baseline that is very conservative and there are opportunities coming from um introducing asynchronous execution to utilize much more of the block time for execution or introducing parallelism for transaction execution um or improving the state access substantially in order to take that same standard and then scale it to a much higher uh throughput landscape and Avery the apos team and also with monad have kind of made the explicit decision to do block stdm a different form of parallelism than what s and salana are doing I would love for you to kick off the conversation about why block STM I'd love to do that thanks so when we think about the kind of the history of execution in the the blockchain space you have sequential with ethereum as we kind of start off with just single process doing transactions one at a time we have the static parallel execution where we kind of declare dependencies up front and then we have things like swe and Sal over taking that path then we think about Aptos which is dynamic parallelism it is the idea that we can take information at runtime and optimize for the most concurrency possible and also drive as much concurrency as possible in that that shared State through things like aggregators and others uh and that was kind of the general concept of how block STM works so having a dynamic kind of runtime parallelism that can take as much information for scheduling uh as as best as possible uh unlocks the kind of the most concurrency that you can have I an example of that say you have a centralized order limit book organized as a tree of nodes and a way for you to kind of put orders in that tree you don't have to lock that whole tree when you don't know exactly what pieces you're going to you're going to access Dynamic parallelism allows you to kind of go access different nodes to that tree and extract the most concurrency possible removing false sharing and making sure that you can run uh as many transactions as you can and Sam I'm sure you have uh some opinions as well because I think with generally all the high throughput blockchain what they've all also been opinioned on is doing parallel processing and the different flavors of parallel processing S is doing a little bit more State access list can you talk about whyu made that choice yeah absolutely so we you something it's a little bit different than State access lists we have an object Centric data model where a transaction specifies okay here's the move functions I'd like to call and here's the objects I'm going to pass to those functions and then this information makes it easy for the runtime to figure out what transaction is going to to touch Which object and then allocate efficiently okay if all these transactions are touching the same object they'll go to this thread if this transaction is touching a different object will allocate it to different threads and so on and so forth so this is an effective scheduling strategy Dynamic is also an effective scaling strategy I think like both of these things can work I think where having static dependency information or object information like really starts to help is in two areas so one is in local fee markets so of course like we all love parallel execution and parallel execution works well but it works well when somebody you a workload that has a nice parallelism in it if they don't if they hand you a purely sequential workload then like you're no better than your old school chain that has just one thread and a superpower we have in crypto is that we have some control over what workload we get because we can set up an incentive feedback loop and so basically like this is where I think the static dependency information really shines because you can say if there's a bunch of transactions that want to touch the same object and that object is hot you can make the fees go up for that where whereas the fees for other things go down and then this also means that you don't end up scheduling too many transactions that are touching the same object and then the the fast transactions have to wait for the slow ones I think the other area where this matters is if you want to do horizontal scalability so this story we told about you want to schedule execution across multiple threads now maybe I want to do it across multiple machines and so there the cost of a misprediction say if you're using Dynamic techniques is a lot higher like you think this is going to touch a certain object or account you send it to a remote machine it turns out it actually is going to touch an account on a different machine then things get trickier whereas with swee our research team has worked on um or the M Labs research team has worked on this pilot fish prototype where they show we can scale execution not only across cores but but across nodes and without sacrificing latency and this is possible because you have this upfront information about what a transaction is going to touch and that lets you efficiently allocate transactions to the data they need to touch and you don't get surprised by mispredictions um just to mention one quick thing about the um sort of like feasibility of local fee markets in the context of um static dependencies versus Dynamic it's still possible to have um local fee markets with Dynamic like it's just more like after the fact you um go and adjust you you know give a rebate like maybe overcharge a little bit initially and then give a rebate based on what the actual State access patterns were so I think this helps the fee issue but what about what the efficient scheduling issue like say you've already made the decision to touch a bunch of transactions that are touching the same piece of State it's too late to go back and undo thatc decision so you can rebate the folks who aren't touching that hot state but how do you deal with that yeah I think one thing to point out is that at the end of the day the cost of contention is um it's a little bit unclear like there it is true that if you have S you know a bunch of transactions that have serial dependencies um ultimately the execution like the real execution of those transactions has to be serial um but I think the reality is that the biggest cost for execution is actually State access so in at least in monads um you know dynamic parallel execution or what we refer to as optimistic parallel execution you could think of it as a two-phase approach where the first phase is executing a bunch of transactions in parallel assuming that they're starting from the same starting point uh but then when the commitment is done commitments are all done on those pending results in serial order and re-execution is usually quite cheap because those state dependencies are in cash right so um I think that you know the end of the day it is really like there are trade-offs there is actually a benefit to accessing State that's hot it's not all about like contention like reuse of state is a bad thing yeah I I know you have some opinions on this as well yeah definitely so I think good points by both both folks here but I I'll kind of say you don't need to trade off between the two because the way we're thinking about Dynamic parallelism is that yes we can optimize that runtime which is really great for concurrency the other thing great about it is that programmers don't need to actually specify their pendencies up front and kind of limit the scope of what the transaction can do but the second thing is that we also want to enable hints so that if they do want to specify those dependencies up front they can do that and so you can end up with this great work like kind of world where programmers can kind of decide the path they want to pick in and choose and then you know when it comes down to this the scaling aspect it's not an issue as long as most of those transactions can be uh known up front and then scaled out and paralyzed uh but the other aspect I would say is when it comes to uh the the the decision here it's it's it's not really if or or other choice it's it's the ability to take these um these runtime decisions and then make a decision as best as possible so we take this low fee market for example you can even do that in Dynamic world right so as you see those transactions piling up for sh shared hot State you can then decide at runtime oh I want to slow down the access to those transactions while leaving all the other lanes free for you to going continue on and so while pilot f is very interesting theoretically you know I I think the results we saw for them were like what 60k TPS or so you can do that on a single machine so what I'm saying is and we've run experiments here like trying out some these different strategies so what we've seen also is that um the horizontal scalability of a dynamic PR system is actually applicable to to millions of transactions per second we actually have a paper kind of coming out later describing this in Q4 describing how it's possible to kind of get that horizontal scaling to to a large level but I think the takeaway I want to have is it's not an if if or other choice you can actually have both and that's what we kind of think of when we think of dynamic parallelism in apos yeah I told agree with you on that to be fair like I think the static information versus Dynamic information you can have both and like you know it's always better to have more static information it gives you more it gives you you know more choices you can always ignore it if it's not help if you don't want to so I think these hybrid approaches are going to be the right long-term way I understand monad is sort of doing something hybrid with some static analysis and some the black STM or the dynamic approach as well yeah correct the the workload is really scheduled in an optimistic fashion um I think with to static analysis that's more um static analysis for um State access State dependencies um but purely within the black box of execution cool um I I think this is interesting because each of both uh monad and Aptos have taken the block STM approach Su and salana have taken the more deterministic approach uh and comparing and contrasting these each I think one of the other interesting things as we start to continue to explore high performance blockchains and really continuing to get the most performance out of them is really around how many liters should we have should we have one liter two lers 10 lers uh would love to open that up to the panel well I think as many as you have validators like uh more leaders is better right like more folks to submit transactions to more folks to abondon Black now like getting this to work is tricky of course like that's what these dag based consens protocols like M have been working on I think classically this has been a a throughput latency tradeoff you get better throughput because you have more more folks in the protocol they can make progress at the same time but you get higher latency because it takes longer to actually reconcile those dag views and to and to commit them with MTI I think it's fair to say like that trade-off no longer exists like the the message delay is the same as classical single leader bft like the the three message delays and so we get this very very low latency like 700 milliseconds and end um a little bit faster or slower depending on where in the world you are we're to the point where like that that matters as much as anything else but I think um I think a lot of other folks are going to go in this direction just because like there are clear benefits and it's just like the the design of these protocols is very subtle so it's taken a long time to get it right and to get the engineering right as well and there's kind of been some conversations even with the ethereum community uh the make ethereum great again Community to go multi-leader uh Happ to jump in next so I think um single leader versus dags it's it's a great discussion point but it's kind of not the key point I'd say it's more about you know talking earlier about ayous execution it's about dis disparate the data dissemination from the actual consensus piece because the data dissemination of transactions is really expensive that's a lot of data flowing throughout the network the agreement on it can be very quick it's very small amount of data being passed across a small number of validators and so um you know with our Jolan Plus+ protocol we' been super excited about kind of matching this quum store which is data dissemination with a super fast like super reliable uh leader based reputation like a BF consensus and it works really well about the same as lenes as as s misset but I think one of the biggest trade-offs of misset that we've seen is that it uses an uncertified dag an uncertified dag is different than kind of a certified dag and so when a certified dag you have this situation where some of these kind of uh nodes if they perform badly if they're unavailable they kind of block the progress of things and so while we kind of looked at the deag research with TR plus plus and SCH and others it's it's something that you know we're trying to make sure we find a balance of having U limits on how bad things can go if some nodes go bad that's why the Leo reputation is important that's why handling the certified dag is important um but definitely the the three hops of latency and the kind of theoretical optimal latency is really really important for for all consensus protocols any opinions ke um well I would just emphasize that the you know from the very start the design of monad has been to preserve evm compatibility and preserve ethereum compatibility from um just entirely like the the shape of the blockchain um you think of it as a puzzle piece with the same shape that the ethereum puzzle piece has so that all of their puzzle pieces when interacting have the same kind of interaction and so that's motivated a lot of the decisions um both with respect to um not having access list for example just to go back to where we were before um because the reality is that most wallets don't support access list there's a huge adoption curve to to even if we thought that it was the right approach to do that which we don't um for various other reasons um the reality is that the most important thing is to preserve support for ethereum so that all the same tooling that developers are used to whether that's Foundry or um the graph or um Alchemy other things like that all just work out of the box and I think from the perspective of you know ethereum also is a is a single leader mechanism um and I think that had you know similar implication there to preserve full compatibility for all tooling and infrastructure and both Sam and Avery you guys and the respective teams have spent a lot of time on dag architectures Avery you mentioned really the key thing separating uh data dissemination from consensus maybe we can nerd out on those designs a little bit more because I think they're pretty integral and kind of how you guys have built the blockchain I mean I think on that one there's more agreement that there is to agreement like you know I haven't heard as much about the like the Raptor and like this next generation of protocols but you know it sounds like it's going in a similar Direction um think weer and the advantages there are like these certain details of like the edge cases and consensus are always the hard Parts we're certainly looking a lot of extensions along those lines as well but um I don't think it's like um static vers Dynamic information where we could probably go into like five more rabbit holes i' be happy to talk about Raptor for a couple minutes that's okay like and since you bring it up I mean I think we're like I said with jol Plus+ we've already got amazing latencies in place but with raptor uh we're excited about kind of even pushing that further further down because the idea is that as we can start to bundle like right now we have a very pipeline architecture which we we think has been you know asynchronous is to some degree that but we think pipeline is even better because you can separate all the stages and think about how like a modern day supercal CPU can kind of optimize uh for uh very high throughput and very good latency um but Raptor will allow us to kind of compress these stages together and and get like the the blockchain latency to be the same as consensus which is really the theorical best you can do like today's consensus theorical best but you want the blockchain to be theorically best as possible as well so we're pretty excited about that and and and then solving that kind of like the edge case as you mentioned like the uncertified dag issue issue where a single node can kind of block and increase latency by 10x is a really bad outcome we got to make sure we solve those problems and raptor is a really good first step in that direction cool I guess one M setting difference that could be worth mentioning is you know s has had this fast path from the beginning where we do full consensus for Trans actions that require full agreement and then we had this fast path for payments for nft minting for publishing just for a lot of these things where you can do things faster and so there like 700 Mill seconds is quite good we get 400 milliseconds on the fast path which is even quicker and so the initial release of MTI is just the consensus but there's a new implementation of the fast path and the way it integrates into mtic cetti U reduces a lot of the overhead of signature checking and also enables some new features at the programmability level like being able to look up the public keys that are signing so that's something that we think will be coming in the fall that we're also super excited about the the mret FP and then also it just simplifies the protocol quite a bit because originally we had fast path and we had narwhal and we sort of tried to make them fit together whereas MTI was designed to end to end to have these two core Parts just like fit together really really nicely I think kind of the broader maybe context of these all these designs is as you kind of hit some of the limitations of the blockchain you can increase the bandwidth to all the nodes so that you can have more throughput as you enable parallel processing you can go from one core two core four cores is there any limitations to that uh perhaps you do different types of charting uh within the industry whether that's intra validator sharting kind of having uh one node be multiple Hardware devices act as one node or uh inra I think I got those backwards inra validator sharting where it's uh multiple Hardware act as one or you just have like explicit machines where that's more opaque to users yeah I mean on that like intra valid intra ra sharting validator sharting is the approach we take and what we've done with pilot fish just because when you have the sharting details inside the black box of what the validator is you just have a lot more design flexibility with what you can do you don't need bft assumptions between those nodes they're all run by the same operator they can be in the same Data Center and you can just use way more classical web 2 techniques like that's what like what we do with pilot fish is like very much inspired by stuff that folks have known how to do in a long time and just haven't been able to apply in the blockchain setting whereas inter validator sharting ER you know this is more like along the lines of what near or other folks are doing where it's it's i' put in the same bucket as l2s where you know it's it's a it's a strategy uh it's with interv valid starting versus l2s L2 is like anyone can start one it's sort of up to the community when we're going to have a new island of state and an interv validator starting it's part of the protocol deciding like I'm I'm going to partition the state in this ways at this time so that adds some more regularity but the same sort of disadvantages you might get from L2 is you have cross yard latency if you have a transaction that wants to touch that wants to go across multiple shards you might have to have two- phase commit you have transactions that can fail more often so I think all the I guess we didn't get to talk about uh reservations with the L2 thesis but I think like if you believe as Q&A was saying that shared state is where the value of blockchains come from anytime you start to fragment that state like that value proposition erods a little bit at least that's my point of view yeah you were asking about the sort of question of like okay well if we have eight cores now what if we ask for 16 what if we ask for 32 like where is the limit and I think one thing I want to point out is that at the end of the day um the biggest bottleneck for execution is not that CPU time so it's not the number of cores it's actually the state access um and so in particular for monad uh monad is introducing a new database that um is built from scratch that's specifically for the problem of storing ethereum Merkel tree data and we think that that's really important because um you know in line with all other monad decisions it's really preserving full ethereum compatibility this is a modular component that um just literally makes State access a lot more efficient and unlocks performant parallel execution um from delivering much better usage of um Merkel tree data stored on the SSD um now I know that um you know with other blockchain protocols that don't use the ethereum Merkel Patricia tree that's not a specific requirement but I think you know in light of the incredible um Network effects of ethereum and all of the applications all the libraries all the applied cryptography research it's all being done in the context of evm it's really valuable to preserve that ethereum Merkel tree um data structure and the way to address the state access problem is through um this initiative monad DB that you've been pioneering I mean I've done extensive podcasts with each three of you and I think all of you have communicated the St access problem will be relatively hard and state growth over time what do you think konia or sorry Avery about uh the state access problem State access I mean I it is a hard problem to solve but developers have told us very clearly they want shared State access that's the key thing they don't want to have this access fragmented across multiple places our defi projects have told us very clearly that that's where they all want things to be they want to be composable uh and they want to be easy to program with and so that our goal is to make the most parallel most efficient access State access as possible when it comes to the sharding and scaling aspect we've we taken a number of different unique approaches in that space one thing we've done that I think is pretty pretty novel is actually be able to Shard our database across a number of rock DB instances in a way that allows alleviation of that pressure and allows more access to ssds something we did our previe net uh back in December we ran a replicatable experiment where just did a whole bunch of peer-to-peer transactions and show we could do two billion transactions in a day which is uh more than 25,000 transactions a second which is also more than all credit card networks processing combined and so we know as we start to paralyze these things my background is actually in uh supercomputing and it's just all about how do you kind of you know use all the resources available to you as best as possible whether it's CPU networking uh storage access and just paralyzing every part of the stack so having that shared State access uh being paralyzed to the CPUs the memory as well as the ssds and then thinking about the you know cross Valor sharting we've kind of hinted at discussing like experiments that run you know Valor runs on one two five 10 machines we're going to see machines with 256 cores going uh very very soon uh and being able to leverage block hism techniques and all the information for scheduling across all those machines super super important to drive up you know performance keep fees really low and support the 5 billion users of Internet who desperately need this this bandwidth any other color on that or feel good cool um I'm curious just long term one thing that we've kind of heard is perhaps block space is infinite uh there always kind of be insation demand for Block space do you guys agree with that do you feel like there's going to be a certain point where the systems are kind of good uh we perhaps get to gigabytes of throughput per second the systems are optimized do we need 10 GB and then 100 gbt in the future are there's limits to these systems yeah I mean well I think the demands are definitely ever increasing I don't know about infinite but you know I feel like the narrative in the space has changed a lot since say 2018 or so like the era of the gas Wars or I think the feeling back then is like you know mainstream adoption is here but it's just blocked by not having enough block space and you know we scale things out a bit and then like we're here and there's going to be no problem whereas today like you have you're at the point where you have several blockchains that are operating way under their capacity all the time so s is in that category aptus is certainly in that category salana is in that category I expect that monad will be as well after they launch and then so I think the question is like you know what does the growth look like and where do you start to hit the limits first my point of view is you won't start to hit the global capacity limits first which is why you know we're so focused on local fee markets you know if the core value proposition of what you're doing is you create really valuable State and then you add Network effect acts to that state then I think the inevitable con consequence of that is you're going to that state is going to become a hot spot and then the challenge for you is you don't want that to suck up all of you don't want that to limit your parilis you don't want that to add latency to your other transactions so when we think about like what problems are we going to run into first we're very very focused on that and then for the long term like this is where the pilot fish story comes in it's like we think yes you want more throughput there's not some specific magic number that's the max you want to be able to add more machines we need more throughput and you also want to be able to decommission those machines when you don't need it because you don't want this High operational cost of like running a beefy machine with hundreds and hundreds of cores or tons of memory you want do what the what the two Giants do you have commodity machines you spin them up when you need when you have demand and you spin them down afterward so that's how we're thinking about the problem but you know I think folks were wrong in 2018 we could be wrong again now yeah I want to make two points the first one is and this is really a topic we haven't covered too much just because we've been sewing the Weeds about a lot of um super interesting technical um initiatives but decentralization like decentralization is why we are all here now and it's clear that that um you know there's a optim there's a sort of like a at least like um two-dimensional curve of decentralization versus performance and if one decreases decentralization for example by raising Hardware requirements can perhaps get more performance but at the end of the day it's really important that anyone be able to run a node anyone be able to fully verify all transactions and have access to the shared Global state so Logan to your point about about um you know like is there ever are we ever going to stop optimizing I think the optimization is really around how much performance you can get with a high degree of decentralization and um just kind of going up and the right in that um efficient Frontier um the second thing just to point out really really quickly is that we care about density of computation within one network so you know there's horizontal scaling there could be like multiple instances of the mon blockchain for example that are more specialized and there's vertical scaling with roll up or what I like to refer to as the fractal scaling approach but what matters the most is that for one unit for one network like one set of nodes in consensus we need as much throughput as possible I think for us uh we think a lot about the costs per transaction as being one of the limiting factors for Demand on the blockchain having a dollar per transaction really limits use cases in terms of what what you want to do and so I think you know when it comes to things like payments or Financial in instruments seeing that you can do like a you know a payment up to 5 thousand of a cent uh allows you to kind of take on much more use cases than you could in the traditional world and so as we start to drive throughput it can't be just done in isolation it's got to be done with cost in mind as well and so kind of keep pushing the efficiency curve further and further out so that the machine Hardware can be used more more effectively and be able to drive those costs down for users is something that we think is really important to the adoption and right now we have again 5 billion people using the internet we have a small less than 1% of those folks using the web three space and I think cost is a big part of that and so as we start to drive those costs down we see more applications building on top of blockchain leveraging the infrastructure giving people that utility they're looking for with decentralized infrastructure and ultimately hopefully that leads to that mass adoption I think all of us here are looking for fully agree maybe as we have one minute left we'll just go do rapid fire questions and we can just go down the line um are we I I guess bullish or bearish ethereum long term ethereum is always going to be around right so the the metaphor I've used before is like you know got to do yes or no Sam okay bullish bullish bullish bullish bullish bullish okay uh l2s bearish uh bullish bearish app chains bearish bearish mostly bearish cool awesome well we'll end it up there thank you so much everybody for coming and watch I hope you got to learn a little bit more about these different ecosystems and what they're building