1 00:00:00,120 --> 00:00:04,080 That was really the core idea was to make the EVM execution a 2 00:00:04,080 --> 00:00:07,200 lot more performant and then build a consensus mechanism that 3 00:00:07,200 --> 00:00:10,520 can keep up with that really high execution throughput in 4 00:00:10,520 --> 00:00:13,480 order to maintain a really high degree of decentralization and 5 00:00:13,480 --> 00:00:15,800 then full decentralized block production. 6 00:00:16,079 --> 00:00:20,680 I think Solana is processing somewhere between 2 and 3000 7 00:00:20,680 --> 00:00:23,640 transactions per second. You know, where as Monad is 8 00:00:23,640 --> 00:00:27,240 supporting over 10,000 transactions per second and then 9 00:00:27,240 --> 00:00:31,800 also Solana is using relatively high hardware requirements. 10 00:00:31,800 --> 00:00:35,880 I believe the requirement is 256 gigs of RAM right now, whereas 11 00:00:35,920 --> 00:00:39,200 monad requires nodes to have 32 gigs of RAM. 12 00:00:40,040 --> 00:00:42,080 Welcome to Epicenter of the show, which talks about the 13 00:00:42,080 --> 00:00:44,800 technologies, projects and people driving decentralization 14 00:00:44,800 --> 00:00:48,120 and the blockchain revolution. I'm Brian Crane and today I'm 15 00:00:48,120 --> 00:00:52,520 speaking with Keoni Hong who is the Co founder and CEO at Monad 16 00:00:52,520 --> 00:00:56,120 Labs. Monad is one of the most 17 00:00:56,320 --> 00:01:01,600 ambitious and interesting new layer ones coming up, expected 18 00:01:01,600 --> 00:01:05,080 to launch next year. So I'm really excited to get 19 00:01:05,080 --> 00:01:08,000 into the details of that with Keoni. 20 00:01:08,720 --> 00:01:12,800 Now before we get into it, we just want to share a few things 21 00:01:12,800 --> 00:01:17,200 from our sponsors this week. If you're looking to stake your 22 00:01:17,200 --> 00:01:20,280 crypto with confidence, look no further than Course 1. 23 00:01:20,800 --> 00:01:24,360 More than 150,000 delegators, including institutions like Bit 24 00:01:24,360 --> 00:01:27,040 Go, Pantera Capital and Ledger Trust course one with their 25 00:01:27,040 --> 00:01:29,280 assets. They support over 50 block 26 00:01:29,280 --> 00:01:31,560 chains and are leaders in governance or networks like 27 00:01:31,560 --> 00:01:34,720 Cosmos, ensuring your stake is responsibly managed. 28 00:01:35,200 --> 00:01:38,040 Thanks to the advanced MEV research, you can also enjoy the 29 00:01:38,040 --> 00:01:41,160 highest staking rewards. You can stake directly from your 30 00:01:41,160 --> 00:01:44,600 preferred wallet, set up a white label note, re stake your assets 31 00:01:44,600 --> 00:01:47,920 on Eigenia or Symbiotic, or use their SDK for multi chain 32 00:01:47,920 --> 00:01:51,360 staking in your app. Learn more at Chorus .1 and 33 00:01:51,360 --> 00:01:55,760 start staking today. This episode is proudly brought 34 00:01:55,760 --> 00:01:58,720 to you by Gnosis, a collective dedicated to advancing a 35 00:01:58,720 --> 00:02:01,880 decentralized future. Gnosis leads innovation with 36 00:02:01,880 --> 00:02:06,480 Circles, Gnosis Pay and Metri, reshaping open banking and 37 00:02:06,480 --> 00:02:09,360 money. With Hashi and Gnosis VPN, 38 00:02:09,360 --> 00:02:12,280 they're building a more resilient, privacy focused 39 00:02:12,280 --> 00:02:14,840 Internet. If you're looking for an L1 to 40 00:02:14,840 --> 00:02:18,080 launch your project, Gnosis Chain offers the same 41 00:02:18,080 --> 00:02:21,280 development environment as Ethereum with lower transaction 42 00:02:21,280 --> 00:02:24,360 fees. It's supported by over 200,000 43 00:02:24,360 --> 00:02:27,800 ballot errors, making Gnosis Chain a reliable and credibly 44 00:02:27,800 --> 00:02:29,680 neutral foundation for your applications. 45 00:02:30,200 --> 00:02:34,040 Gnosis Dow drives Gnosis governance, where every voice 46 00:02:34,040 --> 00:02:36,720 matters. Join the Gnosis community in the 47 00:02:36,720 --> 00:02:41,160 Gnosis Dow forum today. Deploy on the EVM compatible 48 00:02:41,160 --> 00:02:46,280 Nosis chain or secure the network with just one GNO and 49 00:02:46,280 --> 00:02:49,320 affordable hardware. Start your decentralization 50 00:02:49,320 --> 00:02:53,160 journey today at nosis dot IO. Cool. 51 00:02:53,160 --> 00:02:55,440 Well, thanks so much for coming on Kioni. 52 00:02:55,840 --> 00:02:57,600 It's it's really great to have you on. 53 00:02:58,480 --> 00:03:00,040 Yeah. Thank you for having me, Brian. 54 00:03:01,360 --> 00:03:06,400 So I, I like to start by kind of asking people about how their 55 00:03:06,400 --> 00:03:10,040 crypto journey began. Like how did you first become 56 00:03:10,040 --> 00:03:13,240 interested in crypto? Yeah. 57 00:03:14,000 --> 00:03:19,120 So I'm, I'm 35. I've been working for like 1314 58 00:03:19,120 --> 00:03:22,600 years of this point. The 1st 10 years of of my career 59 00:03:22,600 --> 00:03:26,160 were spent in high frequency trading, working as a quant. 60 00:03:26,800 --> 00:03:30,800 So I traded in a number of traditional markets, mostly on 61 00:03:30,800 --> 00:03:35,080 the futures side. These are really high volume, 62 00:03:35,080 --> 00:03:39,960 like very liquid markets like S&P 500 futures or 10 year 63 00:03:39,960 --> 00:03:42,200 treasury no futures or crude oil futures. 64 00:03:43,280 --> 00:03:47,720 Building performance trading systems that trade in these 65 00:03:48,200 --> 00:03:52,520 really efficient markets generating very, very small 66 00:03:53,760 --> 00:04:00,440 statistical profits over a long period of time and over some 67 00:04:00,440 --> 00:04:05,080 period of time, our team started to trade crypto initially just 68 00:04:05,080 --> 00:04:10,440 sort of like without a lot of understanding about the 69 00:04:10,440 --> 00:04:12,280 underlying assets that we were trading. 70 00:04:12,280 --> 00:04:14,880 But crypto is really interesting from a trading perspective 71 00:04:14,880 --> 00:04:18,839 because there's so many different assets, like there's 72 00:04:18,839 --> 00:04:22,280 so many different coins themselves, but then a lot of 73 00:04:22,280 --> 00:04:28,160 different perpetual futures and deliverable futures and many 74 00:04:28,160 --> 00:04:30,320 different exchanges. So there's a lot of interesting 75 00:04:30,320 --> 00:04:32,960 correlation structure across the space. 76 00:04:33,640 --> 00:04:37,800 And that was initially what got me and, and my trading team at 77 00:04:37,800 --> 00:04:41,320 Jump Trading involved in crypto. But then at the same time, I was 78 00:04:41,320 --> 00:04:47,560 also just like getting really into crypto Twitter and enjoying 79 00:04:47,560 --> 00:04:51,480 all the narratives, all the memes, all the characters in in 80 00:04:51,480 --> 00:04:55,560 2020 and 2021. So that was sort of the 81 00:04:55,560 --> 00:04:59,000 introduction of the space. And then my team ended up 82 00:04:59,000 --> 00:05:03,440 merging into the crypto team at jump trading in mid 2021 and 83 00:05:03,440 --> 00:05:07,640 started working on Solana D5 for for a little bit of time. 84 00:05:07,640 --> 00:05:12,160 Then at that point I was fully professionally in crypto prior 85 00:05:12,160 --> 00:05:14,080 to starting Mon out at the beginning of 22. 86 00:05:16,480 --> 00:05:19,040 Right. So you basically first started 87 00:05:19,040 --> 00:05:21,840 trading, you know, just on centralized venues and then also 88 00:05:21,840 --> 00:05:23,680 started doing more like on chain stuff. 89 00:05:26,160 --> 00:05:31,880 Yeah, we, we were from a trading perspective, Yeah, I was more 90 00:05:31,880 --> 00:05:36,280 focused on the centralized side. I mean, in a personal capacity, 91 00:05:36,280 --> 00:05:43,920 I was trying out different Dexes and, yeah, buying NFTS and yeah, 92 00:05:43,920 --> 00:05:48,080 getting rug done on coins. Yeah, on meme coins of 93 00:05:48,080 --> 00:05:54,280 2020-2021, aside from Dogecoin, which which did really well, but 94 00:05:54,280 --> 00:05:56,800 yeah, it was mostly on the in the professional capacity, more 95 00:05:56,800 --> 00:06:01,160 on the centralized side. I'm curious sort of from all 96 00:06:01,160 --> 00:06:06,400 your knowledge you had about, you know, how markets work on in 97 00:06:06,400 --> 00:06:08,920 the traditional markets work and then when he kind of came to 98 00:06:08,920 --> 00:06:12,640 crypto, what were the things that you know, just seemed most 99 00:06:12,640 --> 00:06:15,440 weird to you or like most surprising? 100 00:06:17,600 --> 00:06:19,360 I think two things that come to mind. 101 00:06:19,360 --> 00:06:24,360 The 1st is just the general inefficiency of the markets and 102 00:06:24,360 --> 00:06:30,000 the typical spreads that you end up paying as as a retail trader. 103 00:06:30,880 --> 00:06:35,120 Like in the traditional markets of course depends on the 104 00:06:35,120 --> 00:06:39,400 liquidity of the asset. But for, you know, most normal 105 00:06:39,400 --> 00:06:43,720 futures or most normal equities, people will end up paying single 106 00:06:43,720 --> 00:06:49,000 digit basis points in, in spread and, and in slippage like spread 107 00:06:49,000 --> 00:06:52,520 and slippage combined, like their execution price is never 108 00:06:52,520 --> 00:06:56,760 more than, you know, like one or two cents different from 109 00:06:58,200 --> 00:07:00,920 whatever the midpoint of the market is. 110 00:07:01,720 --> 00:07:07,120 And this is for equity that's trading at $100 or $200 or more. 111 00:07:07,600 --> 00:07:11,480 So single digit basis points. And then if you go to the D5 112 00:07:11,480 --> 00:07:17,040 space, it's, you know, the default is like a 30 bit fee. 113 00:07:17,240 --> 00:07:20,040 And then in addition, like when you trade, there's like some 114 00:07:20,400 --> 00:07:23,160 impact. And then when you price him like 115 00:07:23,160 --> 00:07:26,680 some slippage and then you end up getting sandwiched, attacked. 116 00:07:27,600 --> 00:07:30,760 You know, it's just like it's very common for people to end up 117 00:07:31,280 --> 00:07:35,680 paying like 50 basis points or 1% or 2% in slippage. 118 00:07:36,320 --> 00:07:40,120 So it's just, you know, like 2 orders of magnitude more than 119 00:07:40,120 --> 00:07:41,760 you would in, in the centralized space. 120 00:07:41,760 --> 00:07:44,000 So that's the first thing. And then the second thing is 121 00:07:44,800 --> 00:07:48,200 just the fact that when a transaction is submitted, it's 122 00:07:48,200 --> 00:07:50,680 in a pending state in most block chains. 123 00:07:50,960 --> 00:07:56,640 Therefore, it's subject to the actual discretion of the the 124 00:07:56,640 --> 00:07:59,920 block producer in terms of the ordering, which then has an 125 00:07:59,920 --> 00:08:01,800 effect on the execution price as well. 126 00:08:03,920 --> 00:08:06,960 And then tell me what? What's the origin story of 127 00:08:06,960 --> 00:08:09,240 Monad? Is that what you did after jump? 128 00:08:11,200 --> 00:08:18,640 Yeah. So I met James Hunsaker who's Co 129 00:08:18,640 --> 00:08:23,240 founder and and CTO here at Monad Labs in 2014 when we were 130 00:08:23,240 --> 00:08:26,520 both a jump on the same trading team and we've been working 131 00:08:26,520 --> 00:08:31,720 together ever since then. We both left jump at the very 132 00:08:31,720 --> 00:08:36,720 beginning of 2022 and then started Monad shortly after that 133 00:08:36,720 --> 00:08:41,280 along with the third Co founder. And what was the, what was sort 134 00:08:41,280 --> 00:08:46,200 of the vision that like you would think that cost you say, 135 00:08:46,200 --> 00:08:47,960 OK, this is the thing I want to work on? 136 00:08:48,920 --> 00:08:54,040 Yeah, I think what with any start up, you really need an 137 00:08:54,040 --> 00:09:01,480 idea and an idea of also how that idea fits into the broader 138 00:09:01,480 --> 00:09:06,760 landscape of, of, of the space that you're working in and, and 139 00:09:06,760 --> 00:09:08,360 a clear problem that it's solving. 140 00:09:09,040 --> 00:09:12,800 For us prior to starting Monad, when we were at jump trading for 141 00:09:12,800 --> 00:09:16,040 about 6 months, we were mostly working on Solana Defy. 142 00:09:16,040 --> 00:09:20,520 And at that time in 2021, we could see that there were a lot 143 00:09:20,520 --> 00:09:25,560 of advantages to building on Solana because you know, Salon 144 00:09:25,560 --> 00:09:31,840 was offering like 500 to 1000 real TPS of throughput, so much, 145 00:09:31,840 --> 00:09:33,720 much more throughput than Ethereum. 146 00:09:34,400 --> 00:09:38,720 Ethereum was about 10 TPS and also much more throughput than 147 00:09:38,720 --> 00:09:42,440 any of the roll ups, which were you know, also in the like 10 to 148 00:09:42,440 --> 00:09:46,440 30 TPS range, much more throughput than other EVM layer 149 00:09:46,440 --> 00:09:50,120 ones which are also in the like 10 to 100 TPS of throughput 150 00:09:50,120 --> 00:09:52,480 range. So there are a lot of advantages 151 00:09:52,480 --> 00:09:56,280 to Solana, but at the same time builders were building in Solana 152 00:09:56,280 --> 00:09:58,800 had to build with a completely different bytecode standard. 153 00:09:58,960 --> 00:10:02,200 They couldn't reuse any of the work that they done if they 154 00:10:02,200 --> 00:10:04,760 built for the EVM already. They couldn't use any of the 155 00:10:05,680 --> 00:10:08,880 really rich array of tooling and libraries and so on. 156 00:10:09,840 --> 00:10:13,920 And we just realized that we could give developers the best 157 00:10:13,920 --> 00:10:16,200 of both worlds and give them both performance and 158 00:10:16,200 --> 00:10:20,480 portability, focusing very heavily on optimizing all parts 159 00:10:20,480 --> 00:10:25,120 of the EVM stack. And that was really the core 160 00:10:25,120 --> 00:10:29,120 idea was to make the EVM execution a lot more performant 161 00:10:29,360 --> 00:10:31,840 and then build a consensus mechanism that can keep up with 162 00:10:31,840 --> 00:10:35,520 that really high execution throughput in order to maintain 163 00:10:35,560 --> 00:10:38,400 a really high degree of decentralization and then full 164 00:10:38,400 --> 00:10:42,960 decentralized block production. So I'm curious because I feel 165 00:10:42,960 --> 00:10:45,560 like this EVM discussion, you know, it's been a very long 166 00:10:45,560 --> 00:10:49,160 standing discussion where, you know, some people will be like, 167 00:10:49,160 --> 00:10:52,240 oh, EVM is is fine. And then a lot of people be 168 00:10:52,240 --> 00:10:55,800 like, oh, it's kind of like this, you know, odd thing that 169 00:10:55,800 --> 00:10:59,080 was created early on and just because it was the first it, you 170 00:10:59,080 --> 00:11:01,960 know, it has so much, so much adoption. 171 00:11:02,440 --> 00:11:06,600 Do you feel like is the main, like how do you feel like 172 00:11:07,240 --> 00:11:10,680 comparing the EVM with other VMS? 173 00:11:10,680 --> 00:11:15,160 Do you feel like using the EVM is the biggest advantage? 174 00:11:15,160 --> 00:11:18,760 Is just existing developer ecosystem tooling contracts 175 00:11:18,760 --> 00:11:24,280 exist or are there other kind of pros and cons versus other VMS? 176 00:11:26,640 --> 00:11:32,200 Right, I think that we'll see. EVM is the the just to state of 177 00:11:32,200 --> 00:11:35,920 very explicitly. EVM is the low level by code 178 00:11:35,920 --> 00:11:39,320 standard, but then typically developers are building in 179 00:11:39,320 --> 00:11:44,400 Solidity or occasionally in Viper or Huff or other front end 180 00:11:44,400 --> 00:11:48,920 languages and that that high level language gets compiled 181 00:11:48,920 --> 00:11:52,000 down to EVM. But it is really true that 182 00:11:53,520 --> 00:11:56,840 almost all capital on chain is in the EVM right now. 183 00:11:57,400 --> 00:12:01,040 Like over 90% of all TVL on chain is in EVM dapps. 184 00:12:01,720 --> 00:12:06,120 Additionally, there's a ton of existing libraries and tooling. 185 00:12:06,760 --> 00:12:09,080 Almost all the applied cryptography research is being 186 00:12:09,080 --> 00:12:10,720 done in the context of the EVM as well. 187 00:12:10,720 --> 00:12:14,400 Like people don't really think about that part, but you know, 188 00:12:14,400 --> 00:12:16,520 very much on the on the research side. 189 00:12:16,520 --> 00:12:20,800 And a lot of 0 knowledge research is being done 190 00:12:21,680 --> 00:12:26,240 ultimately to interface with the EVM Bycode standard as well. 191 00:12:26,520 --> 00:12:33,800 So it's really like for developers, they would probably 192 00:12:33,800 --> 00:12:37,400 prefer to build for the EVM given all these network effects 193 00:12:37,400 --> 00:12:40,360 and the fact that by building for the EVM, they're not tied to 194 00:12:40,360 --> 00:12:45,480 like a, you know, one ecosystem or a very small subset of 195 00:12:45,480 --> 00:12:47,560 ecosystems. They can really deploy their 196 00:12:47,560 --> 00:12:49,560 their work almost anywhere in the future. 197 00:12:49,800 --> 00:12:52,600 So it's really just future proofing the work that they've 198 00:12:52,600 --> 00:12:56,040 done, in addition to having access to all of the existing 199 00:12:56,040 --> 00:13:00,840 libraries and tooling. Do you think this is something 200 00:13:00,840 --> 00:13:04,320 that like kind of network effect is going to just continue 201 00:13:04,320 --> 00:13:07,880 compounding and grow bigger in the future or you feel other 202 00:13:07,880 --> 00:13:12,040 things like you know Slana VM or like move VM or any of these 203 00:13:12,040 --> 00:13:16,640 others have a real shot at at some point taking over? 204 00:13:18,560 --> 00:13:20,600 I think the future is very fluid. 205 00:13:20,720 --> 00:13:27,240 It really depends on the path of least resistance for developers 206 00:13:27,240 --> 00:13:31,840 and our team thinks that the work that we're doing to make 207 00:13:31,840 --> 00:13:35,680 the EVM lot more performant so that then developers are really 208 00:13:35,960 --> 00:13:39,600 not forced to choose between performance and portability will 209 00:13:39,600 --> 00:13:43,720 have an impact on how people think about like what VM to 210 00:13:43,720 --> 00:13:46,600 build for. You're right that in the current 211 00:13:47,080 --> 00:13:51,920 regime, at this very moment, developers might be moving over 212 00:13:51,920 --> 00:13:55,560 to Solana because they feel that that's where they'll get the 213 00:13:55,560 --> 00:13:58,600 best performance, and also because there is a lot of 214 00:13:58,600 --> 00:14:01,560 excitement around the Solana ecosystem right now. 215 00:14:02,040 --> 00:14:05,360 But that all just can change with the introduction of new 216 00:14:05,360 --> 00:14:10,440 technology. So when it comes to scaling, so 217 00:14:10,440 --> 00:14:14,280 moving all the bottlenecks and making sort of the EDM very 218 00:14:14,280 --> 00:14:18,440 performant, what are the things that you guys did to achieve 219 00:14:18,440 --> 00:14:23,080 that? Yeah, there are at least four 220 00:14:23,080 --> 00:14:26,560 different major areas of optimization or or four 221 00:14:26,560 --> 00:14:30,680 different new architectures that have been introduced in addition 222 00:14:30,680 --> 00:14:34,400 to just more generally optimizing. 223 00:14:34,720 --> 00:14:37,080 First of all, monad is completely from scratch. 224 00:14:37,760 --> 00:14:41,360 So all parts of the stack are are built from scratch for 225 00:14:41,360 --> 00:14:45,520 performance in C++ and Rust. And then we've introduced 226 00:14:45,520 --> 00:14:48,440 several new architectural improvements, which I can 227 00:14:48,440 --> 00:14:51,920 describe sort of briefly. I think the main way to think 228 00:14:51,920 --> 00:14:55,120 about it is that there is execution improvements, there is 229 00:14:55,120 --> 00:14:59,200 consensus improvements, and then there is improvements in how 230 00:14:59,200 --> 00:15:01,960 consensus and execution interact with each other. 231 00:15:03,320 --> 00:15:05,920 So the first two improvements that I want to mention are both 232 00:15:05,920 --> 00:15:09,080 related to execution. The third one is related to 233 00:15:09,120 --> 00:15:12,920 consensus, and the fourth one is related to how consensus and 234 00:15:12,920 --> 00:15:17,440 execution interact. So on the execution side, the 235 00:15:17,440 --> 00:15:20,640 two things that we've, the two major things that we've done are 236 00:15:21,920 --> 00:15:25,600 introducing a new database and introducing optimistic parallel 237 00:15:25,600 --> 00:15:29,080 execution. And the reason why these two 238 00:15:29,080 --> 00:15:32,000 things are both needed in order to make execution a lot more 239 00:15:32,000 --> 00:15:36,600 performant is because, well, first of all, to talk a little 240 00:15:36,600 --> 00:15:40,960 bit about the job of execution. So like in Ethereum, there's a 241 00:15:40,960 --> 00:15:46,160 block, it has a whole bunch of individual transactions that are 242 00:15:46,160 --> 00:15:49,880 supposed to be run sequentially in order to get to the end 243 00:15:49,880 --> 00:15:53,520 result. And initially you might think 244 00:15:53,520 --> 00:15:57,360 that there's no way to parallel process because the true state 245 00:15:57,360 --> 00:16:01,800 of the world is the state of the world assuming that all those 246 00:16:01,800 --> 00:16:03,680 transactions are run one after another. 247 00:16:03,680 --> 00:16:09,360 So for example, if I start with 200 USDC in my account and then 248 00:16:09,360 --> 00:16:13,640 the first transaction is me sending 150 USDC to you, and 249 00:16:13,640 --> 00:16:16,800 then the second transaction is me sending 100 USDC to my 250 00:16:16,800 --> 00:16:19,480 brother. So you know, the first 251 00:16:19,480 --> 00:16:23,000 transaction, when it gets executed, it'll take my balance 252 00:16:23,000 --> 00:16:26,840 from 200 to 50. And then the second transaction 253 00:16:26,840 --> 00:16:31,160 when it runs will take my balance from 50 to still 50 254 00:16:31,360 --> 00:16:34,080 because that transaction will fail because it was trying to 255 00:16:34,080 --> 00:16:36,080 send 100, but I don't have 100 anymore. 256 00:16:36,920 --> 00:16:40,880 And so I think this is an example that shows you that you 257 00:16:40,880 --> 00:16:43,680 kind of do have to execute the transactions, at least in some 258 00:16:43,680 --> 00:16:48,080 sense serially because you need to have done that first 259 00:16:48,080 --> 00:16:52,760 transaction where I was sending you 150 before we can actually 260 00:16:53,120 --> 00:16:55,160 get the correct result of the second transaction. 261 00:16:55,160 --> 00:16:58,320 If you ran them in parallel, just totally naively, we would 262 00:16:58,320 --> 00:16:59,840 think that both of them succeeded. 263 00:17:00,120 --> 00:17:05,720 So there is a notion in which sequential execution is needed, 264 00:17:06,040 --> 00:17:10,079 but in Monad we introduce optimistic parallel execution to 265 00:17:10,079 --> 00:17:12,680 do a bunch of work in parallel, but then do the right amount of 266 00:17:12,680 --> 00:17:16,599 bookkeeping so that we're keeping track of inputs and 267 00:17:16,880 --> 00:17:22,240 outputs, IE storage slots, both the values that were read in 268 00:17:22,240 --> 00:17:25,400 from a storage slot and then the values that are written to a 269 00:17:25,400 --> 00:17:28,480 storage slot. And although we do a bunch of 270 00:17:28,480 --> 00:17:31,480 work in parallel, we do bookkeeping and then commit 271 00:17:31,480 --> 00:17:34,640 those pending results in the original serial order and re 272 00:17:34,640 --> 00:17:38,560 execute any unexpected results where the inputs have since 273 00:17:38,560 --> 00:17:41,120 changed. And so in that particular 274 00:17:41,120 --> 00:17:43,320 example, we do those two pieces in parallel. 275 00:17:43,480 --> 00:17:46,520 We would get pending results for both of those two transactions 276 00:17:47,080 --> 00:17:48,600 and then the second pending result. 277 00:17:49,000 --> 00:17:52,200 We would then invalidate and re execute because we would realize 278 00:17:52,200 --> 00:17:53,880 that it was done wrongly the first time. 279 00:17:54,760 --> 00:17:59,400 OK, because I think some other chains they were like first try 280 00:17:59,400 --> 00:18:01,920 to check like OK, what contracts does it touch? 281 00:18:01,920 --> 00:18:04,120 And then if it doesn't touch this contracts, then you say, 282 00:18:04,120 --> 00:18:08,000 OK, you can paralyze it. But in your case you you just 283 00:18:08,000 --> 00:18:11,800 execute it and then you see afterwards what it touches and 284 00:18:11,800 --> 00:18:15,880 then you kind of like roll things back almost or. 285 00:18:17,160 --> 00:18:19,400 Yeah, that's, that's exactly right. 286 00:18:19,400 --> 00:18:21,720 Although I wouldn't call it rolling it back necessarily 287 00:18:21,720 --> 00:18:23,880 because nothing has really been committed yet. 288 00:18:24,080 --> 00:18:28,240 But but yeah, that's that's a good characterization though 289 00:18:28,240 --> 00:18:34,280 that a lot of block chains, they do parallel execution require 290 00:18:34,280 --> 00:18:37,600 explicit dependency specifications. 291 00:18:37,600 --> 00:18:40,800 So Solana is a good example of this, where when you submit a 292 00:18:40,800 --> 00:18:44,760 transaction, you have to say the exact pieces of state that that 293 00:18:44,760 --> 00:18:48,520 transaction is going to touch and indicate which ones are 294 00:18:48,720 --> 00:18:52,600 going to be read and which ones are going to be written to, AKA 295 00:18:52,600 --> 00:18:56,240 the read write locks. And then that information is 296 00:18:56,240 --> 00:19:00,520 used as an input to the salon, a scheduler to make decisions 297 00:19:00,520 --> 00:19:04,640 about how to parallelize work. And if you misspecify one of the 298 00:19:04,640 --> 00:19:07,680 dependencies, like if the transaction tries to go out of 299 00:19:07,680 --> 00:19:10,760 bounds and touch a piece of state that wasn't specified 300 00:19:10,760 --> 00:19:13,200 ahead of time, then it just automatically fails. 301 00:19:13,680 --> 00:19:19,520 So that's sort of a more explicitly defined model for 302 00:19:19,520 --> 00:19:22,120 transactions. And I think you would think that 303 00:19:22,120 --> 00:19:24,960 it might allow for more performance because you have all 304 00:19:24,960 --> 00:19:28,800 the dependencies upfront. But in practice, what we found 305 00:19:28,800 --> 00:19:32,120 is that you can get a lot of performance from this pure 306 00:19:32,120 --> 00:19:35,680 optimistic approach where you just assume that everything is 307 00:19:35,680 --> 00:19:39,440 OK, that you know you're just reading dependencies on the fly, 308 00:19:39,800 --> 00:19:43,760 but then you put the results in a pending state and you commit 309 00:19:43,760 --> 00:19:46,320 them serially and re execute if you need to. 310 00:19:47,680 --> 00:19:49,400 Maybe we can come back to this later. 311 00:19:49,400 --> 00:19:51,720 But you know, one question I'm very curious about, it's the 312 00:19:51,720 --> 00:19:56,920 whole question of like MEVPBS because that I think maybe 313 00:19:56,920 --> 00:19:59,480 relates to this as well. But maybe let's go through the 314 00:20:00,240 --> 00:20:03,320 the You mentioned 4 things, so let's go through the other ones 315 00:20:03,520 --> 00:20:04,640 first. Oh, yeah, sure. 316 00:20:04,640 --> 00:20:08,760 So I was telling you about, I guess one of two major 317 00:20:08,760 --> 00:20:11,080 improvements that are improving execution. 318 00:20:11,800 --> 00:20:14,160 So I told you about the first one already, which is optimistic 319 00:20:14,160 --> 00:20:18,440 parallel execution. The second one related execution 320 00:20:18,440 --> 00:20:21,520 is this new database that we've built called Monad DB. 321 00:20:22,600 --> 00:20:27,240 And so the thing to know about this particular topic is 322 00:20:27,800 --> 00:20:31,000 Ethereum stores all of its state in a Merkel tree. 323 00:20:31,760 --> 00:20:34,320 And the benefit of storing all the state in the Merkel tree is 324 00:20:34,320 --> 00:20:37,480 that the Merkel tree has a Merkel root, which is 325 00:20:37,480 --> 00:20:42,520 essentially a check sum over all of that state and in that way a 326 00:20:42,520 --> 00:20:45,720 commitment to all of that state. So like if you and I are both 327 00:20:45,720 --> 00:20:50,280 running full nodes and we both have the same Merkel root at the 328 00:20:50,280 --> 00:20:53,400 top of our tree, then we both know that literally every single 329 00:20:53,400 --> 00:20:56,760 piece of state is exactly the same on both of our machines. 330 00:20:56,880 --> 00:21:00,800 So we don't have to go like state by state in compare all of 331 00:21:00,800 --> 00:21:02,000 them. We can just compare the Merkel 332 00:21:02,000 --> 00:21:03,560 roots. It's a very efficient way of 333 00:21:04,280 --> 00:21:06,080 ensuring that we're on the same page. 334 00:21:06,880 --> 00:21:12,920 And the Merkel tree is, you know, a successively hashed tree 335 00:21:12,920 --> 00:21:17,280 where every parent is a hash of all of its children. 336 00:21:17,520 --> 00:21:20,040 And then you just kind of like propagate that all the way up to 337 00:21:20,040 --> 00:21:23,200 the root of the the tree. And the thing to know about 338 00:21:23,200 --> 00:21:26,720 existing systems is that this Merkel tree structure is 339 00:21:26,720 --> 00:21:30,000 generally embedded inside of another database. 340 00:21:30,760 --> 00:21:37,720 For Go Etherium, it's Level DB or Pebble DB in Aragon and Rath 341 00:21:38,320 --> 00:21:42,640 it MDBX, which is another database. 342 00:21:42,840 --> 00:21:47,080 But any, in any event, like all of these Ethereum clients, they 343 00:21:47,080 --> 00:21:51,200 use a different database as an actual store for all this Merkel 344 00:21:51,200 --> 00:21:53,080 tree data. And it creates a lot of 345 00:21:53,080 --> 00:21:56,440 interaction because each of those databases themselves have 346 00:21:56,440 --> 00:22:00,360 another tree under the hood that's being used to define how 347 00:22:00,360 --> 00:22:03,360 state is or how data is being stored on disk. 348 00:22:03,680 --> 00:22:07,040 So when you want to navigate from the root all the way to one 349 00:22:07,040 --> 00:22:09,680 of the leaves in the Merkel tree, each time you visit a 350 00:22:09,680 --> 00:22:12,720 node, you're actually triggering another look up into another 351 00:22:12,720 --> 00:22:15,520 tree. And so there it's just really 352 00:22:15,520 --> 00:22:18,880 inefficient to let go navigate from the root of the Merkel tree 353 00:22:18,880 --> 00:22:22,280 down to any particular node because each node that you visit 354 00:22:22,280 --> 00:22:25,240 is going to trigger an entire look up into another tree. 355 00:22:25,640 --> 00:22:29,520 So with Mona DB, we apologies for the long explanation there, 356 00:22:29,520 --> 00:22:33,840 but for Monad DB, we're actually storing the Merkel tree natively 357 00:22:33,840 --> 00:22:36,440 on disk. So there's an exact mapping 358 00:22:36,440 --> 00:22:40,400 between how the tree is laid, the Merkel tree is laid out and 359 00:22:40,720 --> 00:22:43,560 the, you know, the locations on disk, the pages. 360 00:22:44,520 --> 00:22:46,440 And then in addition to that, there's also a lot of other 361 00:22:46,440 --> 00:22:50,640 optimizations like introducing asynchronous IO support so that 362 00:22:50,640 --> 00:22:55,120 many pieces of state can be read at the same time, bypassing the 363 00:22:55,120 --> 00:22:57,280 kernel, A bunch of other optimizations. 364 00:22:57,520 --> 00:23:00,760 But what you really get is a much more efficient look up 365 00:23:00,760 --> 00:23:05,280 system and also one that can support effectively parallel 366 00:23:05,280 --> 00:23:08,640 reads, which then interacts really well with the optimistic 367 00:23:08,640 --> 00:23:11,120 parallel execution. Because an optimistic parallel 368 00:23:11,120 --> 00:23:14,920 execution you are running many transactions, each of which is 369 00:23:15,120 --> 00:23:19,880 at some point encountering S stores and S loads and 370 00:23:19,880 --> 00:23:22,640 triggering database lookups. And so while all these database 371 00:23:22,640 --> 00:23:25,800 lookups are being triggered in parallel, by running all these 372 00:23:25,800 --> 00:23:29,400 transactions in parallel, the the disk is also able to service 373 00:23:29,400 --> 00:23:32,920 a lot of those requests in parallel and start, you know, 374 00:23:32,920 --> 00:23:36,440 serving serving state back to each of those transactions. 375 00:23:37,760 --> 00:23:41,480 OK. So basically what you're saying 376 00:23:41,480 --> 00:23:44,640 is like this kind of this Ethereum has this like tree 377 00:23:44,640 --> 00:23:49,880 structure defined where you know the the data, the state is 378 00:23:49,880 --> 00:23:52,120 hashed and then you have a root hash. 379 00:23:52,120 --> 00:23:56,880 And then that's implemented on top of other tree structures 380 00:23:56,880 --> 00:23:58,680 which depend on the different databases. 381 00:23:58,680 --> 00:24:01,920 So you have sort of the three on three, which then makes it 382 00:24:01,920 --> 00:24:05,480 deficient, whereas you guys just have basically use the 383 00:24:05,480 --> 00:24:09,480 underlying tree structure of the database to just store 384 00:24:09,480 --> 00:24:11,360 everything. So you kind of get rid of one 385 00:24:11,360 --> 00:24:18,040 layer of complexity there. Yeah, that's exactly right. 386 00:24:18,040 --> 00:24:21,040 And that's super important because all of this data is 387 00:24:21,040 --> 00:24:24,960 living on SSD. And the mental model that you 388 00:24:24,960 --> 00:24:31,520 should have about an SSD is that it supports a lot of a lot of 389 00:24:31,520 --> 00:24:34,480 work being done and a lot of look UPS being done in parallel. 390 00:24:34,480 --> 00:24:40,960 So like a good SSD is a million or more IOPS IO operations per 391 00:24:40,960 --> 00:24:44,560 second, but the latency of each one of those look UPS is 392 00:24:44,560 --> 00:24:46,920 somewhere between 40 and 100 microseconds. 393 00:24:47,240 --> 00:24:50,440 So you can think of it as like a bottle that has a really wide 394 00:24:50,440 --> 00:24:53,040 bottleneck and you want to be able to stick a whole bunch of 395 00:24:53,040 --> 00:24:55,400 straws into the bottle at the same time. 396 00:24:55,720 --> 00:24:59,080 And you know, like put all the straws in your mouth and suck a 397 00:24:59,080 --> 00:25:03,480 whole bunch of juice out of the out of the jar all at the same 398 00:25:03,480 --> 00:25:06,120 time. But there's the straws are long, 399 00:25:06,120 --> 00:25:09,560 like there's a long amount of latency to look up any single 400 00:25:09,560 --> 00:25:15,160 piece of storage. So in the context of that nested 401 00:25:15,160 --> 00:25:18,800 tree structure that we were talking about, where you know, 402 00:25:18,800 --> 00:25:21,320 you're going to end up having to go back and forth with the disk 403 00:25:21,320 --> 00:25:24,920 a whole bunch of times just to get one piece of state. 404 00:25:25,200 --> 00:25:27,720 And when you can reduce the number of back and forths 405 00:25:28,080 --> 00:25:30,960 substantially, you can get a lot more throughput out of the 406 00:25:30,960 --> 00:25:34,920 system. And so that is primarily and now 407 00:25:34,920 --> 00:25:37,840 an advantage also because I can imagine there's different 408 00:25:37,840 --> 00:25:41,480 advantages to this, right? Like so 1 is that when you 409 00:25:41,480 --> 00:25:44,080 execute a lot of transactions, you can just do it faster 410 00:25:44,640 --> 00:25:47,600 because I maybe it also makes like running a node more 411 00:25:47,600 --> 00:25:50,240 efficient. You know, if it's just like a 412 00:25:50,240 --> 00:25:53,520 normal node where you look up the state that doesn't that's 413 00:25:53,520 --> 00:25:57,000 not like a validator or. Yeah, that's right. 414 00:25:57,320 --> 00:26:02,560 The database is is just how all the state for any node, whether 415 00:26:02,560 --> 00:26:08,120 it's a full node or like a non validating full node or a 416 00:26:08,120 --> 00:26:11,080 validating full node. Either way, they're still going 417 00:26:11,080 --> 00:26:15,520 to need to respond to RPC calls and execute transactions. 418 00:26:15,520 --> 00:26:18,720 Or go look up pieces of state, and all of those are accelerated 419 00:26:18,720 --> 00:26:20,440 by having a better state back end. 420 00:26:21,880 --> 00:26:24,720 Cool. So we have the this optimistic 421 00:26:24,720 --> 00:26:27,640 parallel execution of the new database and then what are the? 422 00:26:28,680 --> 00:26:30,720 What's the next one? Right. 423 00:26:30,720 --> 00:26:35,240 So the two other areas that I mentioned are on the consensus 424 00:26:35,240 --> 00:26:40,040 side and on the interaction between consensus and execution. 425 00:26:40,760 --> 00:26:45,240 So to mention the consensus part first, we have a new consensus 426 00:26:45,240 --> 00:26:50,560 mechanism called Monad BFT, which is pipelined to phase hot 427 00:26:50,560 --> 00:26:55,800 stuff. So hot stuff is a consensus 428 00:26:55,800 --> 00:26:58,840 mechanism that has linear communication complexity. 429 00:26:59,120 --> 00:27:04,920 That means that as the number of nodes in the network increases, 430 00:27:05,520 --> 00:27:09,160 the amount of overall number of messages that need to be sent 431 00:27:09,720 --> 00:27:12,080 increases linearly with the number of nodes. 432 00:27:12,640 --> 00:27:18,560 As opposed to other consensus mechanisms like Tenderman AKA 433 00:27:18,560 --> 00:27:21,520 comma BFT where it it's quadratic. 434 00:27:21,520 --> 00:27:26,000 Like you know, it's the square of the the number of nodes in 435 00:27:26,000 --> 00:27:28,320 the network. Because in tenderment it's all 436 00:27:28,320 --> 00:27:32,000 to all communication, whereas in hot stuff it's generally one to 437 00:27:32,000 --> 00:27:38,320 many, many to one communication. OK, so what's what's the kind of 438 00:27:38,320 --> 00:27:42,680 number of validators that you expect that monad can scale to? 439 00:27:44,320 --> 00:27:48,880 We expect a couple of 100 validators participating in 440 00:27:48,880 --> 00:27:53,720 consensus on day one of Monad Mainnet and then we have a 441 00:27:53,920 --> 00:27:58,520 slightly longer term road map to get that to the thousands. 442 00:27:58,520 --> 00:28:05,360 But with the current consensus mechanism implementation, the IT 443 00:28:05,360 --> 00:28:09,680 can support somewhere between 2 and 300 validators participating 444 00:28:09,680 --> 00:28:11,640 in consensus. OK. 445 00:28:11,640 --> 00:28:15,120 Because that's kind of similar to, I mean, OK, tenement chains 446 00:28:15,120 --> 00:28:18,600 maybe is more like I would say sort of up to 200. 447 00:28:18,600 --> 00:28:20,360 I think it's probably the most that people run. 448 00:28:21,000 --> 00:28:27,760 What about their block time? Right, so monad BFT in monad is 449 00:28:27,760 --> 00:28:33,360 being configured with a one second block time, as I said, 2 450 00:28:33,400 --> 00:28:37,560 to 200 or more validators participating in consensus. 451 00:28:39,760 --> 00:28:43,160 And the other thing I forgot to mention is that monad BFT has 452 00:28:43,160 --> 00:28:46,640 single slot finality, which we think is really important 453 00:28:46,640 --> 00:28:53,000 because you know, there's it affects the the bridging time. 454 00:28:53,280 --> 00:28:55,960 Like if you're trying to bridge off of monad to another 455 00:28:55,960 --> 00:29:00,720 blockchain, then typically, well, the bridge really should 456 00:29:00,720 --> 00:29:04,480 wait until the chain is finalized before relaying a 457 00:29:04,480 --> 00:29:08,880 message to any other chain. And in Ethereum where you have 458 00:29:09,680 --> 00:29:12,480 somewhere like 12 to 18 minute finality, that means it just 459 00:29:12,480 --> 00:29:16,360 takes a super long time to get your assets off of it. 460 00:29:16,560 --> 00:29:19,360 Assets off of Ethereum to another blockchain. 461 00:29:19,520 --> 00:29:23,080 Single slot penality really helps a lot with faster bridging 462 00:29:23,080 --> 00:29:27,080 and faster settlement times. What are your thoughts on the 463 00:29:27,080 --> 00:29:34,120 comparison of this versus the Solana consensus which is you 464 00:29:34,120 --> 00:29:37,720 know this proof of history BFT like consensus I? 465 00:29:39,280 --> 00:29:45,000 Think Solana has Tower BFT which is not single slot finality. 466 00:29:46,000 --> 00:29:50,680 I think that the some of the benefits right now of tower BFT 467 00:29:50,680 --> 00:29:56,400 are support for the higher number of validators 468 00:29:56,400 --> 00:29:59,600 participating in consensus. I think they have somewhere 469 00:29:59,600 --> 00:30:03,600 between 2 and 3000 validators right now, which is actually 470 00:30:03,600 --> 00:30:06,720 quite impressive. Like I know that the the meme on 471 00:30:06,720 --> 00:30:10,440 Twitter at least in the a couple years ago, like people would 472 00:30:10,440 --> 00:30:12,760 always say that Solana is really centralized. 473 00:30:13,000 --> 00:30:17,480 And there are some aspects in which I would say that that that 474 00:30:17,480 --> 00:30:20,840 could be true. For example, the high RAM 475 00:30:20,840 --> 00:30:22,920 requirements of running a Solana node. 476 00:30:23,280 --> 00:30:27,120 But on the other hand, from a pure consensus perspective, it 477 00:30:27,120 --> 00:30:31,240 is impressive that Solana has 2000 plus validators 478 00:30:31,240 --> 00:30:36,520 participating in consensus. But that does come at a cost and 479 00:30:36,520 --> 00:30:41,160 the cost is really finality is like not single slot it, it 480 00:30:41,160 --> 00:30:43,800 takes some time. I think in practice they say 481 00:30:43,800 --> 00:30:48,880 like after 32 slots you can consider it to be finalized. 482 00:30:49,360 --> 00:30:52,480 But it it's a, it's a little bit probabilistic even there as 483 00:30:52,480 --> 00:30:55,920 well. I'm at 32 slots in Solana. 32 * 484 00:30:55,920 --> 00:31:01,160 400 milliseconds is what is it like 12.8 seconds? 485 00:31:03,000 --> 00:31:05,560 Yeah. And I mean one big difference 486 00:31:05,560 --> 00:31:07,800 with sauna, I guess that's not consensus related. 487 00:31:07,800 --> 00:31:12,040 No, but they said there's no Merkel proofs, No. 488 00:31:12,880 --> 00:31:16,160 Yeah, Yeah. That's another example where 489 00:31:16,160 --> 00:31:21,200 Solana removed the merkelization, which I think has 490 00:31:21,200 --> 00:31:25,000 an impact on bridging, has an impact on the ability to run a 491 00:31:25,000 --> 00:31:27,960 light client. In Solana, they say that the 492 00:31:27,960 --> 00:31:32,640 light client is like a node that submits a transaction, that 493 00:31:34,080 --> 00:31:38,640 creates a yeah, transaction that generates a proof, but it 494 00:31:38,640 --> 00:31:42,000 actually has to be included in the blockchain in order to 495 00:31:42,000 --> 00:31:44,880 generate like that that proofs. It's kind of it's not really a 496 00:31:44,880 --> 00:31:49,520 light client in the same way that when people typically talk 497 00:31:49,520 --> 00:31:55,680 about light clients. And from the light client 498 00:31:55,680 --> 00:31:58,560 perspective, those are. How do the light clients work 499 00:31:58,560 --> 00:32:03,240 for Monad? So I think on on day one we will 500 00:32:03,240 --> 00:32:07,680 not have and the light client implemented, but it it 501 00:32:07,680 --> 00:32:12,400 definitely could be implemented in the future with the consensus 502 00:32:12,400 --> 00:32:18,000 mechanism that exists. And yeah, there's there's no 503 00:32:18,000 --> 00:32:21,240 impediment per SE because there is, there is a Merkel route and 504 00:32:21,240 --> 00:32:23,520 there is like all the other things that you need. 505 00:32:26,000 --> 00:32:28,000 OK, cool. So that was consensus. 506 00:32:28,040 --> 00:32:30,400 And then let's go to the last one. 507 00:32:32,320 --> 00:32:37,120 Monad implements something that we call asynchronous execution 508 00:32:38,000 --> 00:32:43,080 and the way to understand that is for sort of best understood 509 00:32:43,080 --> 00:32:46,920 by sort of just want to mention some numbers here. 510 00:32:46,920 --> 00:32:52,960 So Etherium has 12 second block times, but the actual rough time 511 00:32:52,960 --> 00:32:58,240 budget for execution is only about 100 milliseconds, which 512 00:32:58,240 --> 00:33:01,480 is, you know, if you do the math like less than 1% of the block 513 00:33:01,480 --> 00:33:04,160 time. And so that's, that's really 514 00:33:05,200 --> 00:33:08,800 interesting that the budget for execution is so small, like such 515 00:33:08,800 --> 00:33:12,080 a small fraction of the block time in Ethereum or another 516 00:33:12,080 --> 00:33:14,800 block chains. And the reason for this is the 517 00:33:14,800 --> 00:33:17,400 fact that execution and consensus are interleaved with 518 00:33:17,400 --> 00:33:20,600 each other. So typically in block chains, 519 00:33:21,520 --> 00:33:24,800 the you know what'll end up happening is the leader ends up 520 00:33:25,640 --> 00:33:29,000 choosing a list of transactions and then executing all of them, 521 00:33:29,440 --> 00:33:33,360 generating the Merkel root of the resultant state tree and 522 00:33:33,360 --> 00:33:37,000 then sending that as a block proposal to everyone else, then 523 00:33:37,000 --> 00:33:38,640 everyone else. Can you repeat that? 524 00:33:39,880 --> 00:33:41,680 Can you repeat that? How they're interleaved? 525 00:33:42,520 --> 00:33:47,760 Yeah, so in most block chains, execution and consensus are 526 00:33:47,760 --> 00:33:50,960 interleaved. Execution is the single node 527 00:33:50,960 --> 00:33:54,240 problem of, you know, given a list of transactions, what's the 528 00:33:54,240 --> 00:33:56,760 end state? And then consensus is a 529 00:33:56,760 --> 00:34:00,840 distributed systems problem of nodes talking to each other over 530 00:34:00,840 --> 00:34:03,320 a network. The nodes, if they're globally 531 00:34:03,320 --> 00:34:06,640 distributed, which they should be, then that means round the 532 00:34:06,640 --> 00:34:10,760 world communication, which can take hundreds of milliseconds. 533 00:34:10,760 --> 00:34:12,800 There might be multiple rounds of communication. 534 00:34:13,159 --> 00:34:17,760 So I think All in all, what you can see is that consensus ends 535 00:34:17,760 --> 00:34:22,000 up taking the vast majority of the block time and execution 536 00:34:22,000 --> 00:34:24,800 ends up being squeezed into a very small fraction of that 537 00:34:24,800 --> 00:34:28,080 block time because of the interleavedness of execution and 538 00:34:28,080 --> 00:34:31,679 consensus. Yeah, yeah. 539 00:34:32,320 --> 00:34:35,159 But for example, that's something where Solana is also 540 00:34:35,159 --> 00:34:37,480 much more because of their system, there's much more 541 00:34:37,480 --> 00:34:41,080 execution, right? Right. 542 00:34:41,239 --> 00:34:46,400 So with Solana, they're also exploring the idea of 543 00:34:46,400 --> 00:34:50,920 asynchronous execution. Tolle has written about this 544 00:34:50,920 --> 00:34:53,880 couple times on Twitter, which has been really interesting for 545 00:34:53,880 --> 00:35:00,960 us to see. But yeah, Monad has been, you 546 00:35:00,960 --> 00:35:04,600 know, since day one, asynchronous execution has been 547 00:35:05,080 --> 00:35:06,840 a big part of the overall design. 548 00:35:06,840 --> 00:35:11,520 And asynchronous execution means decoupling those two problems of 549 00:35:11,520 --> 00:35:13,600 consensus and execution from each other. 550 00:35:14,520 --> 00:35:19,080 Asynchronous execution is the idea of moving execution out of 551 00:35:19,080 --> 00:35:22,880 the hot path of consensus into I guess what I would call a 552 00:35:22,880 --> 00:35:27,680 separate swim lane that is slightly lagging consensus. 553 00:35:27,960 --> 00:35:32,160 So it what what ends up happening is as soon as the 554 00:35:32,400 --> 00:35:36,240 nodes in the network come to consensus about an official 555 00:35:36,240 --> 00:35:40,640 ordering of transactions, then two things happen in parallel. 556 00:35:40,920 --> 00:35:44,080 One is they can start consensus in over the next block. 557 00:35:44,400 --> 00:35:48,440 And the other thing is they can all each independently execute 558 00:35:48,720 --> 00:35:51,160 that list of transactions that they've just agreed upon. 559 00:35:51,760 --> 00:35:54,680 And so when you move the execution out of the hot path of 560 00:35:54,680 --> 00:35:58,600 consensus into the separate swim lane, you can massively raise 561 00:35:58,600 --> 00:36:01,520 the budget of execution and use the full block time as opposed 562 00:36:01,520 --> 00:36:07,880 to only a small fraction of it. So first the network agrees on 563 00:36:07,880 --> 00:36:10,480 just the order of all the transactions and how they're 564 00:36:10,480 --> 00:36:13,920 being executed. We just we just consensus on 565 00:36:13,920 --> 00:36:17,520 that and then the execution happens. 566 00:36:19,000 --> 00:36:23,480 That's right, yeah. OK, OK, very interesting. 567 00:36:24,320 --> 00:36:32,320 So that also means, for example, if you're now a proposer or like 568 00:36:33,240 --> 00:36:38,480 you don't really have like there's no nothing really you 569 00:36:38,480 --> 00:36:41,560 can no discretion you can apply I guess. 570 00:36:43,280 --> 00:36:44,680 That's a, that's a good question. 571 00:36:44,720 --> 00:36:50,880 So as a proposer you still can apply discretion and we think 572 00:36:50,880 --> 00:36:54,960 that in practice the proposers definitely would apply 573 00:36:54,960 --> 00:37:00,720 discretion because that allows them to, you know, more 574 00:37:00,720 --> 00:37:05,800 optimally choose the set of transactions that that will end 575 00:37:05,800 --> 00:37:09,040 up paying fees. You were asking earlier about 576 00:37:09,080 --> 00:37:14,600 how MEV will end up working and we do think that there will 577 00:37:14,600 --> 00:37:20,840 probably be some sort of mechanism for network 578 00:37:20,840 --> 00:37:25,800 participants to submit ordering preferences to the block 579 00:37:25,800 --> 00:37:30,160 proposer in some way and attach a tip alongside that. 580 00:37:31,080 --> 00:37:33,480 So then that tip revenue is additional revenue for the 581 00:37:33,480 --> 00:37:36,200 proposer of. Course the proposers are the 582 00:37:36,200 --> 00:37:40,640 proposers are the ones that come up with the ordering of 583 00:37:40,640 --> 00:37:42,800 transactions. Correct. 584 00:37:42,800 --> 00:37:46,880 And and then that gets consensus on and then the execution part 585 00:37:46,880 --> 00:37:49,720 is kind of that is basically predefined. 586 00:37:50,720 --> 00:37:52,520 Correct. That's exactly right. 587 00:37:52,520 --> 00:37:57,000 So I think you said it better than than I did the first time, 588 00:37:57,000 --> 00:38:00,360 which is when you think about a blockchain. 589 00:38:00,360 --> 00:38:04,600 A blockchain is really just a bunch of blocks that are in 590 00:38:04,600 --> 00:38:09,040 sequential order and then in each block, a list of 591 00:38:09,040 --> 00:38:11,400 transactions which are also in sequential order. 592 00:38:12,240 --> 00:38:18,280 So if you sort of like let the blocks themselves fade into into 593 00:38:18,280 --> 00:38:21,200 the distance for a second, you just literally have like a long, 594 00:38:21,200 --> 00:38:24,400 long, long list of transactions that are all canonically 595 00:38:24,400 --> 00:38:28,840 ordered. And if, if everyone or, like 596 00:38:29,120 --> 00:38:32,040 Brian, if you and I are both running nodes and we both have 597 00:38:32,040 --> 00:38:34,840 exactly the same list of transactions starting from 598 00:38:34,840 --> 00:38:39,560 Genesis, then we should have the same exact state of the world 599 00:38:39,560 --> 00:38:44,000 because we're both applying the same transactions, 1 by 1 by 1 600 00:38:44,000 --> 00:38:47,800 by 1 by 1, and each time making the exact same state transition 601 00:38:47,800 --> 00:38:51,440 and getting the same state of the world, the same Merkel root. 602 00:38:52,120 --> 00:38:56,480 So the ordering of the transactions purely determines 603 00:38:56,480 --> 00:38:58,880 the execution. It purely determines, like, what 604 00:38:58,880 --> 00:39:01,160 the correct state is. Yeah. 605 00:39:01,160 --> 00:39:03,560 Basically. Like the only reason why we have 606 00:39:03,560 --> 00:39:06,760 Merkel roots is so that we can check each other's work and make 607 00:39:06,760 --> 00:39:11,120 sure that, you know, neither of our computer is like got hit by 608 00:39:11,120 --> 00:39:13,760 cosmic rays and and made a computational error. 609 00:39:13,960 --> 00:39:16,080 It's like just to make sure that we're we're doing the same 610 00:39:16,080 --> 00:39:19,840 thing. OK, so, but it also means now if 611 00:39:19,840 --> 00:39:25,560 I'm the proposer, I, you know, I get all these transactions and 612 00:39:25,560 --> 00:39:29,520 now I can come up with a list like an order of these 613 00:39:29,520 --> 00:39:32,520 transactions. So then there is potentially all 614 00:39:32,520 --> 00:39:39,040 the value right in changing this order, you know, accepting 615 00:39:39,040 --> 00:39:42,560 different orders, putting in your own transactions, like all 616 00:39:42,560 --> 00:39:47,120 that kind of stuff. Yeah, that's that's right. 617 00:39:47,120 --> 00:39:52,320 So and and this is really just true of any any blockchain, but 618 00:39:54,440 --> 00:39:58,320 yeah, almost every blockchain is leader based. 619 00:39:59,160 --> 00:40:06,000 So there's a rotating leader, and then when it's your turn as 620 00:40:06,000 --> 00:40:10,040 the leader, you. Sort of have the privilege of 621 00:40:10,040 --> 00:40:13,320 being able to choose from various pending transactions 622 00:40:13,320 --> 00:40:16,640 that are in the mem pool and assembling the next block, IE 623 00:40:16,640 --> 00:40:20,240 assembling the next ordering of the next set of transactions 624 00:40:20,240 --> 00:40:23,480 that get enshrined into the history of the blockchain. 625 00:40:24,160 --> 00:40:28,280 Of course you need to choose valid transactions so that 626 00:40:28,280 --> 00:40:32,840 everyone else like verifies them and accepts them and votes in 627 00:40:32,840 --> 00:40:35,880 your block. But you have discretion over 628 00:40:35,880 --> 00:40:39,200 what the ordering is. And what I'm saying is that that 629 00:40:39,200 --> 00:40:42,240 choice about the ordering is all determined during consensus. 630 00:40:42,240 --> 00:40:46,280 So you as the block proposer, you choose an ordering, you send 631 00:40:46,280 --> 00:40:48,800 it to everyone, everyone looks at it, checks at all the 632 00:40:48,800 --> 00:40:52,360 transactions are valid, does some other validity checks which 633 00:40:52,360 --> 00:40:55,760 I can talk about in a second, and then votes yes. 634 00:40:55,760 --> 00:41:00,320 And then once you know, super majority of the network, like 635 00:41:00,320 --> 00:41:02,440 super majority stake weight has voted yes. 636 00:41:02,720 --> 00:41:05,880 Now, that list of transactions is now enshrined in the history 637 00:41:05,880 --> 00:41:09,280 of the blockchain, but that can be done actually before 638 00:41:09,280 --> 00:41:11,560 execution of that list of transactions happens. 639 00:41:12,320 --> 00:41:14,520 And so that's exactly what's happening in asynchronous 640 00:41:14,520 --> 00:41:18,080 execution, is having the nodes all agree on the official 641 00:41:18,080 --> 00:41:19,800 ordering. And then once they've agreed 642 00:41:19,800 --> 00:41:23,160 upon it, then they can do two things in parallel, which are 643 00:41:23,160 --> 00:41:26,400 like start working on consensus, seeing the next list of 644 00:41:26,400 --> 00:41:29,400 transactions, but then in parallel go execute the things 645 00:41:29,400 --> 00:41:36,800 they all just agreed upon. So I'm curious now if you do you 646 00:41:36,800 --> 00:41:40,960 think that where this is going to is that we also going to have 647 00:41:41,000 --> 00:41:43,800 a sort of proposal builder separation. 648 00:41:43,800 --> 00:41:48,640 Where as a, as a proposer, I'm going to basically, you know, 649 00:41:48,640 --> 00:41:52,680 plug into some builder or some other entity that, you know, 650 00:41:52,680 --> 00:41:56,200 applies a lot of like intelligence to basically give 651 00:41:56,200 --> 00:42:01,240 me an order that sort of produces the highest value, I 652 00:42:01,240 --> 00:42:03,720 mean highest value for, for that builder then. 653 00:42:04,120 --> 00:42:09,280 And because that presumably there's, there's a lot of value 654 00:42:09,280 --> 00:42:12,120 right in, in determining that order. 655 00:42:14,840 --> 00:42:16,480 Is that where you expect things to go? 656 00:42:18,480 --> 00:42:22,920 Yeah, I think so. So the the question of how the 657 00:42:22,920 --> 00:42:26,680 ordering is chosen is sort of orthogonal from all the other 658 00:42:26,680 --> 00:42:31,240 stuff that I mentioned. Like in the story I was telling 659 00:42:31,240 --> 00:42:34,760 you about how the proposer just chooses an ordering and then 660 00:42:34,760 --> 00:42:37,160 message it to everyone. They all agree upon it. 661 00:42:37,160 --> 00:42:41,200 Now the order is enshrined and now everyone can go execute in 662 00:42:41,200 --> 00:42:43,160 parallel to consensus in the next block. 663 00:42:43,520 --> 00:42:48,920 That entire story just kind of black boxed the decision of the 664 00:42:48,920 --> 00:42:52,600 proposer of how he or she chose that ordering. 665 00:42:52,920 --> 00:42:59,000 And to your point just now, like that decision could be made by 666 00:42:59,720 --> 00:43:04,080 outsourcing that decision to like a third party network that 667 00:43:04,080 --> 00:43:11,320 is, you know, like a proposer builder, like APBS type thing in 668 00:43:11,320 --> 00:43:14,880 Ethereum where there's a system for people to be able to submit 669 00:43:15,960 --> 00:43:21,000 bundles to the builders, Have the builders build a block, have 670 00:43:21,000 --> 00:43:25,800 the block be submitted to a relay, which conducts a private 671 00:43:25,800 --> 00:43:29,320 auction from different builders to choose the ordering that 672 00:43:29,640 --> 00:43:33,880 offers the best overall amount, overall amount of revenue before 673 00:43:33,880 --> 00:43:38,560 presenting some like the best option to the proposer and 674 00:43:38,560 --> 00:43:42,440 having the proposer choose that and, and trying it all of that 675 00:43:42,440 --> 00:43:45,640 still like kind of work could work the same way. 676 00:43:46,200 --> 00:43:48,600 I don't know. The like it's, it's sort of out 677 00:43:48,600 --> 00:43:52,840 of protocol, so we'll see how it develops over time. 678 00:43:53,400 --> 00:43:56,120 But yeah, I think you could think of the ordering choice as 679 00:43:56,120 --> 00:44:00,240 being orthogonal to the other considerations of how consensus 680 00:44:00,240 --> 00:44:04,200 and execution end up working. But like by default when Monet 681 00:44:04,200 --> 00:44:08,240 launches, you know, proposer and builder would be basically the 682 00:44:08,240 --> 00:44:11,960 same. And then so it's not like 683 00:44:11,960 --> 00:44:15,000 enshrined to propose a builder separation and then someone may 684 00:44:15,000 --> 00:44:19,600 come and say, hey, we are going to create a modified client that 685 00:44:19,600 --> 00:44:24,120 separates out the proposal or like or plugs in some kind of 686 00:44:24,120 --> 00:44:27,320 builder mechanism. That's right. 687 00:44:27,320 --> 00:44:29,480 Yeah. The the default mechanism for 688 00:44:29,480 --> 00:44:33,160 block building is priority gas auction. 689 00:44:33,600 --> 00:44:37,520 So choosing the ordering of transactions based on descending 690 00:44:37,520 --> 00:44:41,640 gas bid. I know like I think PBS is 691 00:44:41,640 --> 00:44:46,200 something that's fairly, you know, controversial. 692 00:44:48,000 --> 00:44:53,800 I actually remember we did interior Vitalik at the ECC and 693 00:44:53,800 --> 00:44:56,440 asked him the question, how do you, you know, do you feel it 694 00:44:56,440 --> 00:44:58,640 was the right decision? And you know, I'm not really 695 00:44:58,640 --> 00:45:02,600 sure if this PBS separation was the right decision. 696 00:45:03,280 --> 00:45:08,240 Do you feel like is this a desirable end state, the kind 697 00:45:08,240 --> 00:45:12,640 this kind of separation or because in the end right there 698 00:45:12,640 --> 00:45:17,680 is potentially that a lot of value ends up kind of being 699 00:45:17,680 --> 00:45:21,240 extracted by, I mean in Ethereum's case, right, we now 700 00:45:21,240 --> 00:45:24,920 have I think really just two, two builders. 701 00:45:25,080 --> 00:45:27,600 Who? They are completely dominant. 702 00:45:28,800 --> 00:45:31,160 Like how, how do you want this ecosystem to evolve? 703 00:45:31,160 --> 00:45:33,240 Do you hope that there's going to be a lot of builders who 704 00:45:33,240 --> 00:45:37,720 compete or, or you sort of say like don't really care, It's 705 00:45:38,880 --> 00:45:43,560 it's up to the market to figure this out or like how do you want 706 00:45:43,560 --> 00:45:46,120 to see this evolve? Right. 707 00:45:46,760 --> 00:45:49,280 Yeah, it's definitely a a complex topic. 708 00:45:49,320 --> 00:45:54,000 I think that, you know, one thing that I hope we can 709 00:45:54,000 --> 00:45:59,760 accomplish through what whatever the the ultimate block building, 710 00:46:00,520 --> 00:46:04,720 whatever block building mechanism becomes sort of the 711 00:46:05,120 --> 00:46:08,280 the dominant 1. I hope that it involves a lot of 712 00:46:08,280 --> 00:46:12,480 builders. Ideally it would be possible for 713 00:46:12,480 --> 00:46:17,840 the proposers themselves to just run the software themselves and 714 00:46:18,160 --> 00:46:21,640 build an optimal block that way. It's it's much more 715 00:46:21,640 --> 00:46:25,400 decentralized in terms of that. The thing that you were 716 00:46:25,400 --> 00:46:29,960 mentioning like ultimately the set of agents that are 717 00:46:31,520 --> 00:46:34,320 sequencing transactions, we want that number to be as high as 718 00:46:34,320 --> 00:46:37,520 possible. I think in terms of the the 719 00:46:37,520 --> 00:46:42,960 value capture in Etherium right now the proposers are capturing 720 00:46:42,960 --> 00:46:49,240 a lot of the value because although there aren't that many 721 00:46:49,560 --> 00:46:53,120 entities that have a high market share on the in the builder 722 00:46:53,120 --> 00:46:59,080 space due to competitive forces, they do have to bid up to give 723 00:46:59,080 --> 00:47:02,440 up most of the value that is in that block to the proposer. 724 00:47:02,440 --> 00:47:07,040 So it is still very beneficial to the proposer network, which, 725 00:47:08,800 --> 00:47:11,320 you know, that is sort of revenue maximizing for the 726 00:47:11,320 --> 00:47:15,920 proposers, which is then good for all token holders because 727 00:47:15,920 --> 00:47:20,720 anyone can, you know, has the ability to stake and thus, you 728 00:47:20,720 --> 00:47:23,600 know, sort of get the returns of a proposer or at least most of 729 00:47:23,600 --> 00:47:27,560 them. There's also the part about how 730 00:47:28,560 --> 00:47:33,640 over time we're seeing more value get captured by 731 00:47:33,640 --> 00:47:39,560 applications through, yeah, mechanisms where the the builder 732 00:47:39,560 --> 00:47:44,120 needs to rebate some of the value to the application itself. 733 00:47:44,720 --> 00:47:47,600 And you know, then when the revenue flows back to the 734 00:47:47,600 --> 00:47:52,800 application, that can be good because either it makes the 735 00:47:52,800 --> 00:47:55,720 proposition of building an app more attractive, which I think, 736 00:47:56,560 --> 00:47:59,440 you know, a lot of us in the space would agree is like a good 737 00:47:59,440 --> 00:48:03,400 thing to happen because then it'll just encourage more 738 00:48:04,280 --> 00:48:08,000 ambitious apps to get built. Or potentially the revenue, 739 00:48:08,000 --> 00:48:10,760 although originally going back to the app then could flow back 740 00:48:10,760 --> 00:48:17,080 to either LP's of that particular D5 protocol or maybe 741 00:48:17,240 --> 00:48:20,280 a rebate to the to the taker to the end user. 742 00:48:21,960 --> 00:48:28,240 So I think those are all different things that can evolve 743 00:48:28,240 --> 00:48:32,200 over time. But yeah, I think to your 744 00:48:32,200 --> 00:48:37,120 original question like we we do, I think it is objectively better 745 00:48:37,120 --> 00:48:42,040 for there to be more actors that are ultimately choosing the 746 00:48:42,040 --> 00:48:46,160 ordering of transactions for the purposes of censorship 747 00:48:46,160 --> 00:48:50,920 resistance and decentralization. OK, cool. 748 00:48:50,960 --> 00:48:53,400 Fantastic. So now I think we're coming to 749 00:48:53,400 --> 00:48:55,440 the the fourth thing you mentioned. 750 00:48:56,880 --> 00:49:03,040 Oh, actually I think I, you know, I've gone all the way out 751 00:49:03,040 --> 00:49:07,400 the plank cause I've given the first two things were both 752 00:49:07,400 --> 00:49:10,400 execution related, then the third third one is consensus, 753 00:49:10,680 --> 00:49:13,080 and then the 4th was the separation between consensus and 754 00:49:13,080 --> 00:49:15,800 execution. Oh, the asynchronous. 755 00:49:16,240 --> 00:49:19,520 Yeah, yeah. OK, OK, Yeah, yeah, yeah, OK, 756 00:49:19,520 --> 00:49:24,000 yeah, optimistic parallel, new database, the consensus and then 757 00:49:24,000 --> 00:49:26,160 asynchronous execution. Cool. 758 00:49:26,320 --> 00:49:31,680 So where do we end up with this? Like what is the the kind of 759 00:49:32,720 --> 00:49:35,880 throughput that is achievable here? 760 00:49:37,040 --> 00:49:40,360 Yeah, I think the cool thing about these different 761 00:49:41,200 --> 00:49:43,960 technologies that we're introducing is that they all 762 00:49:43,960 --> 00:49:48,320 stack on top of each other. So it's like, you know, it's 763 00:49:48,320 --> 00:49:52,560 always exciting when you get a bunch of coupons in the mail and 764 00:49:52,560 --> 00:49:56,800 then you know, 1 is like 50% off, 1 is 25% off, but they 765 00:49:56,800 --> 00:49:58,800 actually stack on top of each other 'cause then you really 766 00:49:58,800 --> 00:50:04,200 have a magnifying effect. So as I was mentioning before, 767 00:50:04,200 --> 00:50:08,440 asynchronous execution on its own is a massive unlock because, 768 00:50:09,280 --> 00:50:12,120 you know, an existing interleave systems, only a very small 769 00:50:12,120 --> 00:50:15,120 fraction of the block time can be used for execution. 770 00:50:15,120 --> 00:50:22,640 Whereas by decoupling the two, basically the full block time 771 00:50:22,640 --> 00:50:25,080 and expectation could be allocated to execution. 772 00:50:25,280 --> 00:50:31,240 So we can pack a lot more, you know, literal, just like we can 773 00:50:31,240 --> 00:50:34,240 pack in the full block time as opposed to only a small fraction 774 00:50:34,960 --> 00:50:38,680 as execution time. And then if in addition to that 775 00:50:38,680 --> 00:50:44,040 you have parallel execution, since we can do a lot more work 776 00:50:44,040 --> 00:50:47,600 in parallel, and then we can also have a more performance 777 00:50:47,600 --> 00:50:50,840 state database, we can respond much more efficiently to all 778 00:50:50,840 --> 00:50:54,320 these S loads and S store requests that are happening in 779 00:50:54,320 --> 00:50:57,560 parallel. Yeah, we have a more performing 780 00:50:57,560 --> 00:51:00,320 consensus mechanism. We can keep up with this entire 781 00:51:00,320 --> 00:51:04,600 system of execution that's fast, then we can really, really see 782 00:51:04,600 --> 00:51:08,440 massive gains. The other analogy I want to 783 00:51:08,440 --> 00:51:13,440 mention is that in asynchronous execution, like I, it reminds me 784 00:51:13,440 --> 00:51:17,120 a lot of the, the movie Limitless where there's this, 785 00:51:18,000 --> 00:51:22,320 which is sort of based on the premise that you only use 10% of 786 00:51:22,320 --> 00:51:24,520 your brain. What if you could use 100% of 787 00:51:24,520 --> 00:51:26,320 your brain? Like imagine how super powered 788 00:51:26,320 --> 00:51:29,760 you would be. And of course, that's like a 789 00:51:29,760 --> 00:51:32,720 little bit misleading 'cause I think that 10%, like the 790 00:51:32,720 --> 00:51:37,000 denominator, has a lot of Gray matter like supportive tissue or 791 00:51:37,000 --> 00:51:39,320 something in there. But it's not really true that 792 00:51:39,320 --> 00:51:43,240 you can go from 10% to 100%. But it's a nice fantasy to think 793 00:51:43,240 --> 00:51:45,000 about. And in this movie, there's this 794 00:51:45,000 --> 00:51:48,920 guy who takes a pill that allows him to go to use 100% of his 795 00:51:48,920 --> 00:51:54,000 brain and he's he's just immediately super powered and 796 00:51:54,000 --> 00:51:55,880 he's doing awesome. And then of course, there's like 797 00:51:55,960 --> 00:51:59,600 a narrative arc where you know, by being so powerful, he gets in 798 00:51:59,600 --> 00:52:02,680 a lot of trouble and then he's able to somehow work out of it. 799 00:52:03,600 --> 00:52:05,880 So asynchronous execution is like that where you're going 800 00:52:05,880 --> 00:52:08,640 from using only a small portion of the block time to using the 801 00:52:08,640 --> 00:52:11,080 full block time. And then when you stack this on 802 00:52:11,080 --> 00:52:14,520 top of these other improvements, we can really get significant, 803 00:52:15,120 --> 00:52:18,400 significant throughput. So now back to your the question 804 00:52:18,400 --> 00:52:22,360 you're actually asking. So Monad is supporting over 10 805 00:52:22,360 --> 00:52:27,800 KTPS replaying existing Ethereum history. 806 00:52:27,800 --> 00:52:33,480 So this is not 10,000 transfers or 10,000 ERC 20 transfers. 807 00:52:33,480 --> 00:52:38,800 This is 10,000 real transactions from the distribution of recent 808 00:52:38,800 --> 00:52:43,120 Ethereum blocks per second, which ends up being about a 809 00:52:43,120 --> 00:52:48,000 billion transactions per day or about 1 billion gas per second, 810 00:52:48,760 --> 00:52:50,440 which actually is, is kind of funny. 811 00:52:50,440 --> 00:52:53,880 Like now on Twitter, a lot of people talking about this goal 812 00:52:53,920 --> 00:52:58,880 of Giga gas throughput or 1 billion gas per second, which is 813 00:52:58,880 --> 00:53:03,240 the throughput that we're able to achieve on Monad by stacking 814 00:53:03,240 --> 00:53:06,640 these different technology improvements while running on 815 00:53:06,640 --> 00:53:08,200 reasonable hardware requirements. 816 00:53:08,600 --> 00:53:11,720 Which I think is another thing to point out because a lot of 817 00:53:11,720 --> 00:53:16,080 the goals of getting to Giga gas throughput are assuming that 818 00:53:16,880 --> 00:53:21,520 you're running a, you know, a centralized L2 where there's one 819 00:53:21,520 --> 00:53:24,920 server and that one server has like a massive amount of RAM. 820 00:53:25,880 --> 00:53:29,080 And, you know, it's like kind of a supercomputer that doesn't 821 00:53:29,080 --> 00:53:32,480 really work with the principles of decentralization. 822 00:53:32,480 --> 00:53:36,760 Like we want to have a fully decentralized network where the 823 00:53:36,760 --> 00:53:39,720 nodes are literally globally distributed with the full 824 00:53:39,720 --> 00:53:42,600 overhead of consensus. You want anyone to be able to 825 00:53:42,600 --> 00:53:44,800 run a node. Like it shouldn't be expensive 826 00:53:44,800 --> 00:53:47,600 to run one of these nodes. So if you can get to a gig of 827 00:53:47,600 --> 00:53:55,800 gas of throughput, but you have to have a massive like, you 828 00:53:55,800 --> 00:53:59,960 know, a TB of RAM or more like people are talking about having 829 00:53:59,960 --> 00:54:02,880 like machines that have 10 terabytes of RAM just like 830 00:54:02,880 --> 00:54:05,640 crazy, crazy machines in order to get that throughput. 831 00:54:06,040 --> 00:54:08,960 But with Monad we're getting that throughput while using 832 00:54:08,960 --> 00:54:13,640 commodity hardware, like a server that costs $1000 a year 833 00:54:13,640 --> 00:54:16,800 to run. OK, OK. 834 00:54:16,800 --> 00:54:21,280 And then so can you just contrast this with Solana today? 835 00:54:22,000 --> 00:54:27,920 How, how does it compare? I think Solana is processing 836 00:54:27,920 --> 00:54:33,160 somewhere between 2 and 3000 transactions per second of of 837 00:54:33,160 --> 00:54:39,520 real non voting transactions. And you know whereas monad is 838 00:54:40,120 --> 00:54:43,160 supporting over 10,000 transactions per second. 839 00:54:43,160 --> 00:54:47,920 So it's like, you know, 3 to 5X the throughput right now. 840 00:54:48,880 --> 00:54:52,840 And then also Solana is using relatively high hardware 841 00:54:52,840 --> 00:54:55,880 requirements. I believe the requirement is 256 842 00:54:55,880 --> 00:55:01,640 gigs of RAM right now, whereas monad requires nodes to have 32 843 00:55:01,640 --> 00:55:06,240 gigs of RAM. How do you imagine this is going 844 00:55:06,240 --> 00:55:10,280 to evolve in the future? Do you think you can scale that 845 00:55:10,280 --> 00:55:14,640 a lot more or is this sort of are you hitting the limits here 846 00:55:14,640 --> 00:55:19,760 with these improvements? I think there's the capacity for 847 00:55:19,760 --> 00:55:25,880 another like two to 5X of of throughput improvements. 848 00:55:26,720 --> 00:55:31,760 The real constraint is the on the networking side. 849 00:55:32,640 --> 00:55:41,160 So monad wants nodes to have 100 megabit bandwidth and you know, 850 00:55:41,160 --> 00:55:46,320 the throughput is up to a certain point is sort of linear 851 00:55:46,320 --> 00:55:49,000 on the consensus side with the amount of bandwidth that's 852 00:55:49,000 --> 00:55:54,440 allocated. So, but it's like not we, we 853 00:55:54,440 --> 00:55:56,680 don't think it's reasonable for a decentralized network to 854 00:55:56,680 --> 00:55:59,960 require Gigabit bandwidth, for example. 855 00:56:00,760 --> 00:56:05,560 Like there's just sort of like a physical limitation to the 856 00:56:05,560 --> 00:56:09,000 overall throughput that's imposed by the networking. 857 00:56:10,400 --> 00:56:12,800 OK, OK. So basically bandwidth becomes 858 00:56:12,800 --> 00:56:16,920 like the main bottleneck. And then that's something where 859 00:56:16,920 --> 00:56:19,840 OK, if you if you go up with bandwidth requirements, it just 860 00:56:19,840 --> 00:56:24,880 means that you have to start compromising decentralisation to 861 00:56:24,880 --> 00:56:26,920 some extent or to another extent. 862 00:56:26,920 --> 00:56:30,400 It just becomes harder to run about this. 863 00:56:30,400 --> 00:56:33,640 I mean, I think in Solana Solana's case, right that that 864 00:56:33,640 --> 00:56:36,880 is a real challenge. I mean, we've had various times 865 00:56:36,880 --> 00:56:40,640 in the past, you know, data centres would basically say, 866 00:56:40,640 --> 00:56:43,760 hey, you're getting, you know, it's getting DDoS because it's 867 00:56:43,760 --> 00:56:47,800 getting so much traffic. So I think finding like data 868 00:56:47,800 --> 00:56:51,200 centers that support like Solana Valley is not it's not so easy. 869 00:56:52,560 --> 00:56:55,960 Right. Yeah, I think that, well, I 870 00:56:55,960 --> 00:57:00,000 think the the more the most important thing to focus on is 871 00:57:00,000 --> 00:57:06,400 like the fact that there is like for Solana or Monad, there is a, 872 00:57:08,160 --> 00:57:11,640 you know, commitment to having a fully geographically 873 00:57:11,640 --> 00:57:15,560 decentralized validator set, having hundreds or thousands of 874 00:57:15,560 --> 00:57:17,400 nodes participating in consensus. 875 00:57:18,640 --> 00:57:23,160 Like a lot of the more recent narrative has been around like 876 00:57:24,400 --> 00:57:27,560 just like very, very centralized setups where there's a single 877 00:57:27,560 --> 00:57:32,680 sequencer. Like if in that situation, 878 00:57:32,680 --> 00:57:35,680 there's no consensus at all. And so if there's no consensus, 879 00:57:35,680 --> 00:57:40,000 then that whole thing about the bandwidth, like doesn't become a 880 00:57:40,000 --> 00:57:42,960 consideration because the node doesn't have to talk to anyone 881 00:57:42,960 --> 00:57:45,080 else. Like, it literally is just the 882 00:57:45,080 --> 00:57:47,880 one super node that all the requests are flowing to. 883 00:57:48,680 --> 00:57:54,920 And all of the yeah, all of the RPC calls are, are are going to 884 00:57:54,920 --> 00:57:58,000 or or maybe going to like a slave or something, but you 885 00:57:58,000 --> 00:57:59,560 know, something in the same data center. 886 00:58:00,240 --> 00:58:02,360 So I think that's the the single biggest thing. 887 00:58:02,360 --> 00:58:06,400 And that is ultimately what the constraint will be is the the 888 00:58:06,400 --> 00:58:14,120 networking limitations to support a fully geographically 889 00:58:14,120 --> 00:58:16,080 distributed decentralized network. 890 00:58:16,480 --> 00:58:17,720 But I think it is very important. 891 00:58:17,720 --> 00:58:22,920 And then I think from that point onward, then Monad would perhaps 892 00:58:22,920 --> 00:58:27,520 pursue a horizontal scaling strategy where there is several 893 00:58:27,520 --> 00:58:31,600 instances of Monad that each are very computationally dense, like 894 00:58:31,600 --> 00:58:34,840 each over each or each delivering over 10 KTPS of 895 00:58:34,840 --> 00:58:37,720 throughput. And then, you know, when that 896 00:58:37,720 --> 00:58:41,560 10K gets saturated by whatever set of apps that are there, then 897 00:58:41,560 --> 00:58:45,880 maybe there's like another Monad instance that's also highly 898 00:58:45,880 --> 00:58:49,440 decentralized, has nodes all the way all around the world that 899 00:58:49,440 --> 00:58:54,320 has a more specific, like different, different focus as 900 00:58:54,320 --> 00:58:55,680 well. Right. 901 00:58:55,680 --> 00:58:58,880 It becomes sort of a sharding like design. 902 00:58:58,880 --> 00:59:02,720 But I mean fortunately 10 KTPS is is quite a bit right. 903 00:59:02,720 --> 00:59:04,880 So it should probably have some time. 904 00:59:05,720 --> 00:59:08,960 Yeah, you want a Shard at. You want a Shard when you've 905 00:59:09,520 --> 00:59:14,000 reached the limits of what you know the hardware can really 906 00:59:14,000 --> 00:59:16,880 support. Like I think that it doesn't 907 00:59:16,880 --> 00:59:19,680 make sense to Shard. Like if each network could only 908 00:59:19,680 --> 00:59:23,480 support 100 TPS and then you need to have 100 shards in order 909 00:59:23,480 --> 00:59:25,400 to get to 10 KTPS, that's not very good. 910 00:59:25,640 --> 00:59:29,840 But if one Shard itself is 10 KTPS and then you set up 100 to 911 00:59:29,840 --> 00:59:34,360 get to 1,000,000 TPS, that seems much more justifiable to me. 912 00:59:35,400 --> 00:59:37,760 Yeah. And I mean, it sounds like 913 00:59:38,000 --> 00:59:40,440 previously you were sort of referring a bit to like Mega 914 00:59:40,440 --> 00:59:44,400 Eve, right, which is the other project that's trying to super 915 00:59:44,400 --> 00:59:49,400 scale EDM, but doing it with this kind of supercomputer 916 00:59:49,400 --> 00:59:52,640 centralized approach. To me, it seems very obvious 917 00:59:52,640 --> 00:59:58,760 that's like a massive compromise on on in the end what we're 918 00:59:58,760 --> 01:00:01,680 trying to do here, right? You're having like decentralized 919 01:00:01,680 --> 01:00:04,880 networks. But yeah, I mean, I guess they 920 01:00:04,880 --> 01:00:08,880 do you think, but mega, let's say Mega Eve will at the expense 921 01:00:08,880 --> 01:00:12,320 of decentralization, then probably be able to to process 922 01:00:12,320 --> 01:00:15,560 even much more than Monet or like what are your thoughts on 923 01:00:15,960 --> 01:00:17,760 on like Mega Eve as a comparison? 924 01:00:19,040 --> 01:00:23,480 Yeah, I think there's there's a a number of different projects 925 01:00:23,480 --> 01:00:29,120 that are trying to build like high performance L twos taking 926 01:00:29,120 --> 01:00:32,440 advantage of the the fact that there's no consensus overhead 927 01:00:32,440 --> 01:00:37,680 and you know, you can run that one note on a on a really big 928 01:00:37,680 --> 01:00:40,960 box. I think another example is is 929 01:00:40,960 --> 01:00:46,360 Ryze L2 is, is also doing this. I think radio is also doing 930 01:00:46,360 --> 01:00:49,200 this. I mean, you could argue the 931 01:00:49,200 --> 01:00:54,960 hyper Liquid itself is also kind of doing this because the nodes 932 01:00:54,960 --> 01:00:58,960 are all in Tokyo, like the node in order to run a node, you kind 933 01:00:58,960 --> 01:01:03,400 of have to have it in this one geography, high RAM requirements 934 01:01:03,400 --> 01:01:05,400 on the nodes. So yeah, I think there's a 935 01:01:05,480 --> 01:01:07,880 there's a number of different projects that are all trying to 936 01:01:08,720 --> 01:01:11,560 trade decentralization for performance. 937 01:01:12,640 --> 01:01:17,880 And I mean, if you think about it like just your expectation 938 01:01:17,880 --> 01:01:22,880 should be that there could be more performance if you cut out 939 01:01:22,880 --> 01:01:27,480 all of the decentralization aspects and all of the overhead 940 01:01:27,480 --> 01:01:30,040 of consensus and so on. I think Mert actually has a 941 01:01:30,040 --> 01:01:37,440 pretty funny take on this where he talks about how L twos really 942 01:01:37,440 --> 01:01:42,600 should be like a lot higher TPS than Solana because they're all 943 01:01:42,600 --> 01:01:45,720 running single centralized sequencers and you can Add all 944 01:01:45,720 --> 01:01:48,200 of their throughputs together. The fact that like right now 945 01:01:48,200 --> 01:01:50,720 Solana has higher throughput than all the L twos combined 946 01:01:51,240 --> 01:01:54,440 when the L twos like have this massive advantage of 947 01:01:54,440 --> 01:01:57,240 centralization is actually pretty crazy. 948 01:01:58,040 --> 01:02:00,600 So yeah, I think that they're different designs. 949 01:02:00,600 --> 01:02:04,800 Like there's, there's definitely some trade-offs being made, but 950 01:02:04,840 --> 01:02:09,840 the goal of Monad is to offer really high performance while 951 01:02:10,120 --> 01:02:12,760 having a very high degree of decentralization as well at the, 952 01:02:12,760 --> 01:02:14,720 at the layer one level. And we, we think that that's 953 01:02:14,720 --> 01:02:19,280 quite important that that's, you know, that's why we're all here 954 01:02:19,280 --> 01:02:22,680 is to, to help build new technology that helps 955 01:02:22,680 --> 01:02:25,840 decentralization to have a greater impact and decentralized 956 01:02:25,840 --> 01:02:29,160 apps have a greater impact. So I'm curious about the 957 01:02:29,160 --> 01:02:32,760 developer experience here. Is it basically just going to be 958 01:02:32,760 --> 01:02:37,680 hey I'm developing just like for Etherium and pretty much the 959 01:02:37,680 --> 01:02:41,680 same but the difference is just faster block times, more 960 01:02:41,680 --> 01:02:43,560 throughput, cheaper transactions? 961 01:02:43,840 --> 01:02:47,000 Or are there differences when it comes to developer experience as 962 01:02:47,000 --> 01:02:50,760 well? On day one of mainnet the focus 963 01:02:50,760 --> 01:02:56,320 is really just pure EVM equivalents so that any you can 964 01:02:56,320 --> 01:02:59,960 take any application built for Aetherium and redeployed on 965 01:02:59,960 --> 01:03:02,920 Monad without any changes. You don't even need to recompile 966 01:03:02,920 --> 01:03:06,680 it. We are thinking about some 967 01:03:07,000 --> 01:03:10,760 additional quality of life improvements for developers. 968 01:03:11,000 --> 01:03:16,960 Those are things like raising the the the bike hood size limit 969 01:03:16,960 --> 01:03:22,040 from 24 kilobytes to 48 or maybe even more than that. 970 01:03:22,840 --> 01:03:25,240 It's things like adding support for new pre compiles for 971 01:03:25,240 --> 01:03:28,480 example. There's a number of different 972 01:03:29,320 --> 01:03:33,640 cryptographic functions that frequently come up that 973 01:03:33,640 --> 01:03:37,480 currently have to get implemented in Solidity and are 974 01:03:37,480 --> 01:03:40,760 very expensive to do so. But if there's a native 975 01:03:40,760 --> 01:03:44,200 implementation, then that should just kind of be baked into the 976 01:03:45,240 --> 01:03:47,560 the node code and you should just be able to call it with a 977 01:03:47,560 --> 01:03:50,600 pre compile. So we're, we're working on some 978 01:03:50,600 --> 01:03:54,320 of those and they will either be included in mono mainnet or if 979 01:03:54,320 --> 01:03:57,640 not right at mainnet, then at some point a little bit later 980 01:03:57,640 --> 01:04:00,040 on. We're also looking at the 981 01:04:00,040 --> 01:04:05,200 account abstraction space quite a bit and thinking about, well, 982 01:04:05,200 --> 01:04:09,240 first of all, following along with the existing Eips that are 983 01:04:09,440 --> 01:04:13,960 contemplating different ways to ultimately get to native account 984 01:04:13,960 --> 01:04:18,680 abstraction. I think EIP 77 O2 is getting a 985 01:04:18,680 --> 01:04:23,480 lot of traction. So this is the EIP that would 986 01:04:24,040 --> 01:04:31,160 sort of allow any EOA to effectively become a smart 987 01:04:31,520 --> 01:04:35,480 contract account as well by having a pointer in its code 988 01:04:35,480 --> 01:04:39,240 slot to point to another smart contract, like another address 989 01:04:39,760 --> 01:04:42,920 where code lives. So we're we're looking into 990 01:04:42,920 --> 01:04:45,800 that. And again, it'll either be 991 01:04:45,840 --> 01:04:49,880 included in mainnet or probably sometime shortly thereafter. 992 01:04:50,440 --> 01:04:52,960 But yeah, at the end of the day, from a developer experience, 993 01:04:53,520 --> 01:04:59,320 developers can expect a fully EVM equivalent experience so 994 01:04:59,320 --> 01:05:00,960 that they don't have to change anything. 995 01:05:01,240 --> 01:05:06,160 But in addition, our team is evaluating ways to make life 996 01:05:06,160 --> 01:05:08,320 easier for developers. That's actually easier to 997 01:05:08,320 --> 01:05:10,120 develop on Mon AD rather than on Etherium. 998 01:05:12,000 --> 01:05:13,680 Cool. I'm curious on like a very 999 01:05:13,680 --> 01:05:15,800 different topic. You know, there's a lot of 1000 01:05:15,800 --> 01:05:20,000 competition around at once and you know, building community and 1001 01:05:20,000 --> 01:05:22,080 sort of getting mind chair is not easy. 1002 01:05:22,600 --> 01:05:25,640 I think you guys have done a fantastic job there and it feels 1003 01:05:25,640 --> 01:05:28,640 like there's already a lot of like interest in Monad, people 1004 01:05:28,640 --> 01:05:32,360 building on monad. What have you guys done in that 1005 01:05:32,360 --> 01:05:34,280 front that has had the biggest impact? 1006 01:05:35,840 --> 01:05:37,720 Yeah. I think everything is, is very 1007 01:05:37,720 --> 01:05:43,960 synergistic in the sense that I think there's, there's a lot of 1008 01:05:43,960 --> 01:05:47,640 people in the the crypto space that are really passionate about 1009 01:05:49,400 --> 01:05:53,800 the ideals of the space and excited about seeing the success 1010 01:05:53,800 --> 01:05:58,640 of new, new decentralized apps and excited about trying new 1011 01:05:58,640 --> 01:06:02,200 things and giving feedback. And also that spend, you know, 1012 01:06:02,200 --> 01:06:05,720 frankly, like spend a lot of time on crypto Twitter everyday 1013 01:06:05,720 --> 01:06:09,040 and follow along with a lot of the storylines. 1014 01:06:09,040 --> 01:06:12,560 I think what our team has done well is just creating a 1015 01:06:12,560 --> 01:06:17,640 welcoming home for many people that share these common 1016 01:06:17,640 --> 01:06:20,880 interests. And especially during the, you 1017 01:06:20,880 --> 01:06:26,760 know, bear market of 2022-2023, just having a creating this 1018 01:06:26,760 --> 01:06:30,600 welcoming environment where everyone was kind of a little 1019 01:06:30,600 --> 01:06:34,800 bit down in the, the dumps from all the negative news and 1020 01:06:34,800 --> 01:06:36,880 sentiment and so on around crypto, but still very 1021 01:06:36,880 --> 01:06:39,880 passionate. And a lot of people sort of 1022 01:06:39,880 --> 01:06:42,880 ended up joining the Monarch community and making a ton of 1023 01:06:42,880 --> 01:06:45,880 friends and contributing in different ways. 1024 01:06:45,880 --> 01:06:52,040 Which then really has a, a flywheel effect of now we're at 1025 01:06:52,040 --> 01:06:58,840 the point where artists that are creating new art involving the, 1026 01:06:58,920 --> 01:07:01,480 the Mon animals which were created by members of the 1027 01:07:01,480 --> 01:07:05,280 community or like just leaning into all the memes and, and 1028 01:07:05,280 --> 01:07:08,600 jokes and fun, then have a massive audience for their art. 1029 01:07:08,800 --> 01:07:13,760 Which then is very just encouraging to them and gives 1030 01:07:13,760 --> 01:07:17,000 them more of a reason to create more art, Which then creates 1031 01:07:17,000 --> 01:07:19,640 more enjoyable experiences for everyone else. 1032 01:07:19,640 --> 01:07:23,960 Which then you know, it's, it's very, very positive some. 1033 01:07:23,960 --> 01:07:27,640 And then, you know, lastly, also very positive for builders who 1034 01:07:27,640 --> 01:07:31,720 were building a monad, because then they immediately get some 1035 01:07:31,720 --> 01:07:35,760 moral support from people who are cheering for them to be 1036 01:07:35,760 --> 01:07:39,640 successful and trying out the beta versions of their products 1037 01:07:39,640 --> 01:07:42,960 and giving the feedback and becoming community members. 1038 01:07:42,960 --> 01:07:47,360 And yeah, I just think that there is it, it's really just 1039 01:07:47,360 --> 01:07:52,520 about the fact that for various reasons the community is 1040 01:07:52,520 --> 01:07:54,760 attracted. A lot of people are very long 1041 01:07:54,760 --> 01:07:59,480 term oriented and care a lot about the space and have enjoyed 1042 01:07:59,480 --> 01:08:02,360 making friends and then getting to go to meetups around the 1043 01:08:02,360 --> 01:08:06,040 world to, to meet up with their friends that they've been 1044 01:08:06,040 --> 01:08:08,120 hanging out with a lot in person in real life. 1045 01:08:08,680 --> 01:08:13,760 One last anecdote that I'll mention is so around Devcon, we 1046 01:08:13,760 --> 01:08:16,600 hosted the Monet Madness pitch competition. 1047 01:08:17,120 --> 01:08:21,080 This is the second iteration of something that we're hoping will 1048 01:08:21,080 --> 01:08:25,640 become like very much a fixture of what we do, but it's it was a 1049 01:08:25,640 --> 01:08:31,200 competition for 25 teams to present in front of a panel of, 1050 01:08:32,760 --> 01:08:35,160 you know, really leading investors in the space. 1051 01:08:35,640 --> 01:08:40,080 We had people from Paradigm, Electric Capital, Pantera, 1052 01:08:40,479 --> 01:08:47,479 Animoca, IOSG, and then anyway, the those were the judges and 1053 01:08:47,479 --> 01:08:49,840 then a bunch of other investors were in attendance in the 1054 01:08:49,840 --> 01:08:56,520 audience, but we had anyway. So it was like these teams got 1055 01:08:56,520 --> 01:09:02,160 to go on a giant stage, pitch their their project, compete for 1056 01:09:02,160 --> 01:09:07,000 $500,000 worth of prizes, get the attention of judges so that 1057 01:09:07,600 --> 01:09:10,680 they could attract money in their next fundraise. 1058 01:09:11,000 --> 01:09:14,800 And then also got over 400 people to attend in person, 1000 1059 01:09:14,800 --> 01:09:17,160 people attending on the live stream. 1060 01:09:17,479 --> 01:09:21,880 And then kind of around this, we had over 150 people fly from 1061 01:09:21,880 --> 01:09:25,640 other countries, mostly in the Asia area, but we had people 1062 01:09:25,640 --> 01:09:30,439 traveling from as far away as as Greece and Turkey and so on all 1063 01:09:30,439 --> 01:09:33,800 the way flying to Thailand just to go attend the community meet 1064 01:09:33,800 --> 01:09:37,000 up and spend the week like hanging out with their friends 1065 01:09:37,000 --> 01:09:40,160 that they've met online. So yeah, I think in short, 1066 01:09:40,160 --> 01:09:42,960 there's just an incredible amount of energy and excitement 1067 01:09:42,960 --> 01:09:45,720 in the monad community. And then that has translated 1068 01:09:45,720 --> 01:09:50,200 into benefits for builders as well, which then makes the 1069 01:09:50,240 --> 01:09:53,600 ecosystem stronger, which then pulls more people and it 1070 01:09:53,600 --> 01:09:58,000 hopefully pulls a lot of people and that have never but known 1071 01:09:58,000 --> 01:09:59,680 anything about crypto in the past as well. 1072 01:10:00,800 --> 01:10:04,440 There may be final question. So the what are the timelines 1073 01:10:04,440 --> 01:10:07,000 here like? When do you expect mainnet to 1074 01:10:07,000 --> 01:10:10,360 launch? We're expecting Mainnet to 1075 01:10:10,360 --> 01:10:15,560 launch sometime early next year. No exact date at the very 1076 01:10:15,560 --> 01:10:21,520 moment, but the team is working really hard on this and I think 1077 01:10:21,520 --> 01:10:25,320 in in particular we're expecting to launch the test net 1078 01:10:25,320 --> 01:10:28,600 imminently in 2025. Cool. 1079 01:10:29,040 --> 01:10:31,480 Well, thank you so much Keoni. That was really great. 1080 01:10:31,480 --> 01:10:35,080 I really enjoyed getting into the details here. 1081 01:10:35,080 --> 01:10:39,360 And I feel like this is a lot of like very smart and interesting 1082 01:10:39,360 --> 01:10:42,920 and reasonable decisions that you guys have made that I think 1083 01:10:42,920 --> 01:10:45,720 can can end up in a in a really powerful blockchain. 1084 01:10:45,720 --> 01:10:47,320 So thank you so much for coming on. 1085 01:10:47,320 --> 01:10:50,160 It was a great pleasure. Yeah, thank you for having me, 1086 01:10:50,160 --> 01:10:51,800 Brian. It's really nice chatting with 1087 01:10:51,800 --> 01:10:52,000 you.