SVM vs EVM

Transcript

Welcome to Uncommon Core, where we explore the big ideas in crypto from first principles. This show is hosted by John Charbonneau, co-founder and general partner of DBA, and me, Hasu, strategy lead at Flashbots and advisor to the Lido DAO. Hey John, how are you doing? It's been a while. Good. It has been a very long time since we've done one of these. It's been Well, actually, what has it been? It's been like two three months? Yeah, probably actually months. People are already making very angry tweets, you know, at us on on Twitter. One of One of One of the jokes was like flying way over your head.

Yeah, I did not pick up on the sarcasm there, but we're finally back now. Uh how's DBA doing? Good. Doing well. Just like still I'm in like early stages in the fund for us. I mean, like the clearly the stuff that I've been spending time on, just our performance around VMs. So, a lot of that I've been like leading to clearly the Solana ecosystem is where we've been spending a lot of time. Those were the first couple investments that we actually made were around there. Just the Eclipse and Solana were around there. And a lot So, that's a lot of the stuff that we're looking at right now is just It started to become like kind of increasingly clear by like middle part of last year that like okay, like the second that we get into some kind of bull market again, like it seemed

like sort of apparently obvious that like the current like system just scalability-wise like wasn't kind of going to cut it of like the system of like single constrained DA on Ethereum and like a bunch of still very unoptimized EVMs like at the moment of just like single threaded, not, you know, super dealing well in an optimized manner with like state growth and all these things that, you know, fees are just going to get expensive is the like short answer to that. Like the second that we have, you know, somewhat of a bull market and like we're already starting to see that um, like, you know, on the traditional rollups, like, they're not like super cheap to use. Um, you know, you could be paying a dollar to like transfer, um, and more than that to like do a swap and stuff, uh, right now.

Um, so, paying a lot more attention to like, okay, how much juice can you squeeze out of these things, um, both on the side of like, okay, how much like further can you actually push the EVM? Like, are these like fundamental problems that you can, you know, you can never fix, or is it just not been a priority? Um, versus like clearly Solana, um, has had like a ton of these improvements over the past, you know, couple years, and like people are starting to finally care about those again. Um, so, been spending a lot of time around there. Okay, wow, that's a lot to unpack. So, you said Eclipse and Solana have been your first two investments. Okay, and how are these differentiated from Ethereum?

Yeah, I mean, like the simple part of it, I mean, is like just very the the left curve, fast and cheap of like, it's very clear that going into some kind of a bull market with any kind of uptick in demand, like, the current infrastructure just doesn't support like a lot of scale right now. Like, it's very fragmented, it's rather low throughput. Mhm. Um, and so, the reason like Eclipse's architecture like just got us excited was, okay, like, clearly Ethereum L2s are going to be a thing. Um, like, this is still the most important and biggest ecosystem where all the developers are, most of the users, the liquidity, all of these things. So, like, how do we bring those kind of innovations that Solana has had like over to the Ethereum ecosystem? Um, and like that that is like a lot of what they're doing. And

so, people are starting to like appreciate that tech again, particularly like as people need more scale again. Um, and so, like, that was like the very simple thesis. It was just like putting kind of the best pieces together. So, Eclipse is like Solana rollups on Ethereum. Yeah, basically, yeah. Like, they're they're going to have like an L2 that is trying to like address the scalability bottlenecks that like you're starting to see already like with existing just like simple rollups of, um, I mean, the the first bottleneck is honestly just like using Ethereum DA at the moment. I think that there's like going to be an increasing trend of like using um, alternative DA solutions, whether that's Celestia, EigenDA, Avail, like all these different ones popping up that like I think that they are going to be commonplace to start to become used

more. Like 4844 is obviously like on its own like not able to like provide, you know, these like thousands of TPS. Like like that alone like I mean like Solana alone would eat up more than like what 4844 would provide. Clearly like going to need to turn to those. And then once you have that extra bandwidth, it's like okay, now you don't want to be bottlenecked by your single-threaded execution either and like a low throughput environment. So like innovating innovating on the VM and that like that's what the SVM is doing. Uh-huh, okay. So Eclipse and Solana they both use the the SVM or the Solana virtual machine or C level virtual machine. I think nobody really knows you know what this acronym stands for. But you're basically acknowledging that throughput, you know, in in execution isn't really, you know, the bottleneck

in rollups. It's actually DA, you know, actually posting the data somewhere. Um to what degree do do you think that like that the SVM for rollups even, you know, makes a lot of sense? So in the steady state like bandwidth is definitely just the simple constraint of like DA. Like the steady state cost of you know just a regular transfer on like any of these rollups right now on Ethereum is going to be in the order of you know, you know, 40 cents, 50 cents, something like that. Um even just for like a basic transfer even if like the chain itself is not congested. The like innovating in the execution environment helps more particularly like when there's congestion within that virtual machine. And like we've seen that like

at different times where like there is something like idiosyncratic, some big thing is going on in Arbitrum and you know, now all of a sudden like Arbitrum fees are like $20, but like oh, it's still super cheap over on Optimism. Um and the reason you get that is when like even if Ethereum DA isn't the bandwidth constraint, like now that like there's just too much for like Arbitrum to handle. Um so you got to like be able to like kind of handle both of those if you want to hit like full scale. Um So it's kind of addressing both of those kind of together. So are rollups parallel execution for Ethereum?

Like it gets into the like what what exactly is Ethereum? Like do you consider these like extensions of it? Like it's like you know like the analogy that everyone everyone always gives is like it's a form of sharding. And a lot of other people will point out how like technically it's obviously like not really the same thing as sharding. It is different. But in a way I mean like they are a dirty form of sharding is still like a reasonably like understandable like rough analogy of like they they kind of are extensions of Ethereum in that manner. But yeah, it's not parallel execution like within a single composable obviously virtual machine. So like that is a lot of you know what obviously like Solana has innovated around is like okay having parallel execution like within an actual single composable virtual machine.

And like a lot of what people are starting to think about more in the EVM and particularly like Monad is the main one is like okay well while all of these EVMs to date have been you know super non-performant and generally single threaded and all of these bottlenecks like those aren't mostly fundamental. Like you can fix a lot of those things in the EVM. So it's trying to like kind of push out like okay like what is the boundary of like what a fully juiced out EVM really can do. And trying to like do more optimizations there. So been starting to look more around that lately as well as like what are the fundamental constraints? Like what can you do with the EVM? Like what are the bottlenecks there?

Before we dive into some of the technicals, talk to me a bit about kind of the social dynamics of these communities. I heard you went to Breakpoint. It's the biggest the official Solana conference. I I have never been myself. You know what's the energy over you know in Solana? It was great. I mean like Breakpoint was probably like the perfect timing possible for a conference where it was like just as Solana was like really starting to like kind of take off in the narrative. Like where I I like if Breakpoint was happening like now or like a month later or something, it would have probably been overrun by like a bunch of investors like myself and a bunch of other people, but it was like just early enough where like Solana wasn't the hyped up thing yet where like

not all those people that were there. So, it ended up being just like a great crowd of it was a lot of fun of like pretty developer heavy like a lot of just builders there. Like there were some investors as well certainly but like it was definitely a very different vibe than like most Ethereum conferences. Like if you go to one of the big Ethereum conferences, um it was my first time going to Breakpoint as well. Um so, it was a great mix of it was like mostly people who have been around building for the last couple of years who have just gone through all of the that has happened in the Solana ecosystem and like finally getting the kind of like recognition and excitement again and like people were getting excited about it. Um so, it was definitely great atmosphere. Like it was a it was a really really very well

organized and very fun conference. Eclipse and Solana competitive or complementary? No, because to argue that they're directly competitive, I mean like you mostly need to be holding on to the idea still that there's going to be this kind of one chain to rule them all at the end of the day. Um and then sure, like yeah, then every chain is competitive. Um in reality, this just isn't zero-sum unless they're just actually going for the exact same design and users. Mhm. Um in reality, they're both using the SVM but then I mean like the parallels basically stop there. The whole The whole point of Eclipse is they're making entirely different architectural tradeoffs and tapping into a new market which is Ethereum.

Yeah. Um so, from like Solana's perspective, like look, Ethereum L2s are going to exist and take different tradeoffs than you. You obviously prefer those to be SVM rather than EVM L2s. Like it's just purely additive to your network effects, infrastructure, reduces developer platform risk, like all those things. So, more concretely, like half of this is architectural differences. Um so, as an L2, I mean Eclipse is, you know, prioritizing data availability sampling and proofs. And then the other big part of that is kind of this just like core design difference philosophy um between Solana and these L2s is that just kind of like what commitment do you need at what time?

The benefit of like these kind of L2 architectures is you can get virtually instant confirmations, even faster like than Solana, using either a single sequencer, potentially small sequencer set. Because the whole point is like they are just fundamentally less trusted and then you post your data to this other DA layer with a larger validator set with a slight lag and then you can get those additional guarantees. And that compares versus Solana which is trying to give you like the gigantic validator set to give you those guarantees right away on its own. Yeah. And like that is just a very fundamentally difficult problem to kind of do that and a lot of Solana's issues in the past have kind of stemmed from the fact that it's Tower BFT consensus and proof of history around that.

Like they are still quite unproven. Like they're not formally proven. There are like aspects of it that are still not fully understood and you can just like simply gut that kind of complexity and risk with a trade-off. And so I think it's awesome that like both are experimenting with like radically different directions and I do think that we're going to see like both of those designs like be super successful in the long run for different things. So then on that's like half of it. Then the other half of Beacon L2 is honestly just like it summarizes like a UX thing and like a network effects thing on top of that. Like for better or worse Blast is a pretty good example of there's a lot of users and liquidity. If you can get the attention of kind of the Ethereum ecosystem.

So I mean like with an L2 design like this Ethereum users you get the whole, you know, the simple things of a clear mental mapping in their head of this being an extension of Ethereum. There's this canonical ETH that I get to use as a gas token. I don't need to figure out, you know, there are these different wrapped versions of ETH on this chain like which bridge do I use or like I need to get some new wallet and then get this gas token. Like it's a lot of complexity that you're putting onto the user which these kind of L2s are kind of really try to abstract abstract away as much as possible. Using like friend.tech was like a simple example of like I think something like that worked and like someone like me had a low barrier to go use this thing because it

was like, "Oh, sure. Like, you know, I'll just like put a few ETH over there. Like I'm like using the wallet like a couple of times." you a token yourself? Uh I mean, yeah. Like I like I went to go play or I like I haven't used it thick in months, but was the total market cap? Uh I actually don't know. Cuz I don't I don't know how many like people bought it. I haven't checked in like keys outstanding are there? doubt Yeah, I doubt that it was like that expensive of a non-shares? Yeah. You know, the funny thing about like what you said about Blast and Okay, so first first observation, people are like still building on Ethereum primarily as a distribution strategy, you know? It's like less about the tech. It's like all about tapping into that mind share and like that network effect and saying like you're

Ethereum aligned, right? Second thing is like it's kind of funny because like the Blast bridge isn't actually any more secure than like a centralized bridge to a Solana, right? So, they're they're not benefiting at all from from being a roll-up on Ethereum that has like a trustless um you know, validating bridge. Especially when the L2 doesn't exist. Exactly. Yeah. Let's Let's not talk about that too much. It's too triggering.

Um I mean, I guess there's like one meta point which you can kind of glean from this which there's like um you know, you can have an Ethereum like there's some apps and like some funds that that are so successful that they can give a project a critical enough halo basically to like get away with anything pretty much, right? And in Solana, I wouldn't know what like a similar fund, you know, as Paradigm and like a similar project as uh as Blur would be, right? So, I think if you kind of have already, you know, this reputation of being very successful and being very trustworthy, then yeah, then then you can get away with a lot, right? Whereas in in Solana maybe that kind of entities

don't yet exist. So, DBA, that's your fund. You're hosting a monthly research club. And you've been doing this for some time. You know, there's different uh different topics every month and I hear it's like a very you know, technically minded audience. And um yeah, we uh we are recording this this podcast the morning after uh you know, the last research club. So, you know, tell me what was last night's uh meeting about? Yeah, so most of them more technically minded than myself uh by a lot as well.

So, I try to pick up what I can. Um but yeah, I mean like we do these meetings kind of just like on like random fun topics that like we're thinking about every once in a while. Uh get like a small group together that just like talk about these things. Uh so like the one last night we were doing it kind of primarily around like uh some of the stuff that I was talking about earlier around like just generally like VM optimizations. Like what are the bottlenecks in execution for the EVM? Like how can we improve these things? Uh like how does the SVM tackle these things? Similarly, you know, what are the constraints between them? Like how do you know, how do we fix these things? Um so like most of the guys who were like leading the discussion, we had the Monad guys come in who were like awesome

at this um who like really really understand it super super well. Um so like they were around like had a few of the EF guys. Um and then also had like some others on the Solana side who understand that well. Um and also Kevin uh who works at Monad like used to be in Solana core. So, it was like the perfect mix of people just to like be able to talk about like all the different optimizations between the two. Uh it was like it was it was a really really good group. Okay, so before we dive into, you know, SVM versus EVM, what what even is a VM, John? Yeah, I mean just at like a super high level, I mean like for like in the blockchain context like it's the software that like the nodes are running um to be able to just basically, you

know, execute code and like, you know, compute like uh what is the new state of the chain. So, like they're the ones that are like actually running like what what is the code of the smart contracts deployed on chain and you know, feeding transactions through like what is the new state that I get out of this. And obviously, doing that in very different matters can be like far more or less efficient depending on how you do that. Like simple things like being able to execute code in parallel for different transactions. Like stuff like that is like the basic example. Very simply, it's the software that like knows they're running to be able to execute instructions and uh update the state of the chain.

Yeah, I would add that um you know, just as like you can have a hardware computer that has the CPU that uses transistors and stuff and and gates and you know, it has uh you know, uh you know, short-term memory and has long-term memory and you know, some way of like writing between these. You can have the same thing just made of software, right? Just the very same component, right? You have like a disc for long-term storage, like a disc for short-term storage and basically like you have a computer that like is kind of that actually is like the the thinking brain of the whole thing and you can have that made entirely out of just software parts and that's a VM, right? But it can do basically the exact same thing as as like a a hardware computer. And so, it's a software computer.

So, between the two most popular VMs that we have seen uh the Ethereum Virtual Machine or EVM and the Solana Virtual Machine or SVM, what would you say are the main differentiators between these two? So, I'd say the main thing that like certainly that gets the most attention at the very least is that um the SVM is like built to pretty natively support um parallel execution. Um so, the basic idea is and this is true for a bunch of different software.

Um you you want to be able to like generally try to parallelize workloads as much as you possibly can um because the simple TLDR TLDR of just like looking at like the way that computers are built and where progress is is that uh computers have a bunch of different cores that like individually can do sequential computation. So, you want to be able to try to parallelize across them doing, you know, different threads of of sequential computation. So, the problem is that like most of the advances kind of currently in performance like from year to year tend to be increasing core count rather than just like making each individual core like a lot faster.

Yeah. So, if you have a single threaded virtual machine that is which is the way that the EVM is implemented today Mhm. and you're unable to be able to try to execute transactions in parallel, then that means that like all of those extra cores are just kind of sitting there idling and you're not taking advantage of the fact that you know, you're adding more cores every year. It's getting cheaper and cheaper to do that. Yeah. So, the SVM was like very much built from the ground up of like, okay, how do we arrange everything in a manner such that we can very easily execute all of the transactions in parallel. And that just like helps you with like a lot of speedups and being able to like much more efficiently process transactions.

One of the like main things that Solana does to kind of enable that is they force up front that like all transactions have to be able to specify up front like when I send a transaction, okay, here are here's all of the state, here are all the accounts that like my transaction is going to read and write to. So, you know when you are like a node that you get all these transactions, they have declared up front that this is the state that you know, they're all reading and writing from. So, I can see which transactions are non-conflicting and then I can just schedule them accordingly to execute in parallel the ones that I know are not going to conflict with each other. In Ethereum, you don't have to do that. So, when you get a transaction, you don't know what state this is going to touch.

You don't know what storage slots it's going to touch. Yes. And so, by default what like every client does is you just you execute everything sequentially because otherwise you don't know what's going to conflict or not. Like that's the way that Ethereum works today and every other EVM chain currently works is you just have to execute everything sequentially because the EVM doesn't enforce anything like these access lists where you have to specify up front. And adding those would you can theoretically like make those mandatory in the EVM, but it would be a breaking change and then you wouldn't be backwards compatible anymore and like that's kind of the whole point of keeping EVM compatibility.

Right. And that's why not only Ethereum, but also like all of the other EVM chains are not adding state access lists because they would have, you know, they would break compatibility with all existing the entire existing EVM ecosystem meaning like all of the bytecode of all of the applications that exist. Okay. Exactly. If you make them mandatory then yeah, you break compatibility. So, between, you know, using state lists and not using like state access lists, um, if we like start from zero, is it strictly better in the sense I'm asking from the, you know, strategy perspective? Is it like table stakes like to do this now or, um, is it is it like are there trade-offs involved?

So, I think the parallel execution is going to become table stakes over time. I it's unclear that requiring access lists will become table stakes. I I I certainly don't have a strong opinion that that would be true that it that is like very unclear. So, I for background then like the way that you can parallelize the EVM and other virtual machines is you just do it optimistically. You can use heuristics to kind of see that like, "Okay, these transactions probably do not conflict with each other. I'm going to just optimistically execute, you know, all of these transactions in parallel and if when I run them, you know, I get an error on one of them that like, "Oh, this one did conflict with that one." then you rerun it again.

So, in the best case and the normal case is like most transactions won't overlap with each other and so you're just going to zip across them and like it'll be fine. Like most transactions aren't going to conflict. In the worst case, you do try them the first time and then, "Oh, wait, like everything conflicted, everything was sequential, and then you have to go and execute all of them again. Yeah. So, that like that is kind of the trade-off between the two is that is like in the worst case like you don't know like they could just all end up being sequential. If designed properly, I mean like the worst case is actually like not that bad because the worst case is you do have to execute all of them again, but like the actual computation at that point of just like re-executing them isn't like

actually the most like stressful part on the validator. Like that like that is not really the main constraint. Like just like just re-executing them is like actually like a relatively simple step. That like that isn't the primary bottleneck. So, it's unclear. I mean like which of them like there are trade-offs to both of them. I mean like the main trade-offs to like declaring up front with state access list is like honestly it's just annoying for developers. Like it makes their lives harder to develop applications for this that specify up front for every transaction. It's much easier if you just don't have to think about this, and then you just use heuristics.

All right. So, the developer has to be the one who has to basically manage the state access. Yeah. And that makes it much more tricky. Yeah. It puts more work on say a Solana developer versus a traditional Ethereum developer that like when they design the application in the first place that like it has to be designed in a manner that you're thinking about this and so that transactions are formed in this way. Like so it is it is more work for them. The other thing that is like annoying with state access list today and like this is to some extent fixable with better source pricing, but like you see this on Solana is you can just intentionally write lock like a bunch of state with a transaction that you're not actually using.

So, I could just like send an MBV transaction, and I could just like choose to like write lock the like top like 60 What transaction? Like write lock all different accounts that like my transaction isn't touching. So, I can send a transaction that says oh, I'm going to use like all of these like 50 high volume trading pools. So, you need So, like when the node goes to run that, they see they see the access list of like, "Okay, it's touching all of these. So, I need to lock all of these and I can't execute those in parallel." Um that like that that is a problem that like as of right now, that is just like a pretty trivial thing that is like free to do.

Wait, like how are they solving this? Does this problem exist right now in the wild? Like can I just like send transaction after transaction and like lock the Solana chain for like hours? Yeah. Yeah, people do that. At no cost? Okay. Well, you can't I mean you won't like lock the chain. Yeah, but like all of the like trading pools. Yeah, you make you make it much more inefficient of like I can just send a single transaction that like effectively for free will just like write lock a bunch of state that like I'm not actually using. And And like people will do that. This is a specific one which like can be most likely like addressed to the primary extent just with like better resource pricing. Like Solana has a lot of like wonky kind of things with resource pricing. Like and like the the

simplest thing for them is that like as of right now, their transactions are very different than Ethereum transactions in the way that they charge. Transactions just have like a fixed flat fee per signature. So, it doesn't matter how many compute units Compute units are the like Solana equivalent to like Ethereum gas, basically. Um whether you use a million CUs or like 20,000 CUs on a transaction, if it's got one signature, it gets charged the same. Um so, there should be a mechanism by which you're actually being charged more one for like the amount of CUs that you're using. And also, if you're like locking a bunch of other state, you should be you know, be able you should have a manner to to charge like what is the different state

that like I'm trying to access as opposed to being able to for free just, you know, send a gigantic transaction and lock a bunch of state that like I'm not actually using. Cuz otherwise, it makes it super inefficient if people start doing that. I still remember when Solana had no fee market at all. Right? That that was I mean that was a wild when, yeah, there was just no fee on on any transaction to you could just like DDoS the network for free basically. We talked about their fee market quite a bit last night as well. Like the local fee markets. That is often brought up as one of the benefits of like having parallel execution in the way that they do it like Yeah, I was going to say I mean it's interesting right because like Solana in theory was always lagging behind you know, Ethereum in in kind of the

economic design but because they have state access list in theory in theory they can do something that's actually really neat. Which is the idea of local fee markets. Tell us what that means. Yeah, and so yeah, that was a lot of the conversation was in theory versus in practice how it works. And so like the basic idea is that yeah, for like Ethereum or any chain today like you have a global fee market where everyone is just competing in the mempool and like you send a priority fee and like everyone's competing with each other. So this makes it easier for like if there is you know, one hot piece of state, you know, an NFT mint or whatever that they will drive up prices for the entire chain if say like everyone's trying to bid that up even if the bandwidth of the entire chain isn't

saturated and like the blocks aren't full. So what Solana does is like and they started to realize this after having some of the liveliness failures in the past where they were getting exactly this issue where it was just like you're getting a million transactions that are trying to spam some NFT mint but like everything else on the chain is fine. So like how do we just price this piece of state higher and like leave everyone else alone. So that's what local fee markets do is like trying to say like okay, you need to pay a higher priority fee to access this piece of state because this is a hot piece of state and then like all the other pieces of state, you know, everyone can just pay the same priority fees as normal and like they'll go through because you know, they're not conflicting it's easy

to do. And that's you couldn't do that easily in Ethereum because at the moment when basically the computation starts the client doesn't already know what part of state is going to be touched, yeah. Yeah. Yeah, they wouldn't be able to do it in like the same matter. Um and so like the the theory of it like definitely makes a lot of sense. The way that it is currently implemented and this is a lot of what we were talking around a bit around it was uh the idea definitely makes a lot of sense. The current implementation is like rather rudimentary. It's like not an actually like in protocol fully flushed out thing. It's just like implemented at the schedule level scheduler level. So at the kind of the client level um is just doing this. Um and it's also the problem

is like it's not actually like deterministic and and guaranteed to work just because of the way that like Solana uh builds blocks. Like in particular um like Solana is just like uh naturally building blocks continuously as opposed to like waiting a second and then like building a block at the end. There's like a continuous block production and propagation. Um and like there's like a weird part of it where like you're kind of assigning these transactions to different threads like somewhat randomly. So increasing your priority fee can like increase your chances of like actually getting what you want. But if you know that like they uh the they're going to be executing across like multiple different threads and assigning transactions to different threads, you could certainly end up in a

situation where like I paid a high priority fee, but like someone is like randomly got assigned to the a different thread and so like they beat me. And there's a lot of incentives to like so the priority fees can help on the margin, but there is still like a very high incentive to still like like race effectively. So it's like it's a very still imperfect solution. Um and we're talking about like some of the ideas of like how could you change it? How could you put it in protocol more? Of like you could try to have like a trailing like 1559 like mechanism of just for different pieces of state. Like okay, there was a million transactions that tried to touch this piece of state in the last block. So you know, it changes in the next block and try to implement it differently. Which again is

imperfect mechanism um because you could just get like a million that shows up the next block for one piece of state and then the next and then the next slot like no one cares about it anymore. So but it's you know, it's a balance of like if it is still an improvement if it's still helpful like people are starting to think about that more. Yeah, and it's it probably gets easier like the because like I guess calculating the right price for all of these different like pieces of state is relatively tricky to do on chain but yeah, something I guess you can do you know now off chain as well.

Yeah. It's It's difficult and like they definitely had a very like interesting and unique direction and like they'll keep innovating on it. Like I remember like one of the random things that we're talking about last night was was someone was talking about like how they like diligence Solana like before it launched as like an investment like they're looking at the white paper and everything and like when they're doing the diligence like the result was like oh this is like broken in so many different ways like without the men pool and there's like there's no fees and whatever. Like it's just going to get spammed and it's going to break and all these things and it was like that was technically right but it was also like clearly the wrong decision of like there's a degree of you got to ship these things. You see what breaks and

then like you iterate from there. And like they they've done a very great job with that. That's like the turn the turn of struggle, you know, it's like when I saw Solana in the beginning I thought the exact same things and you know, I also didn't invest I didn't invest in any like what in its chains etc. So it wasn't like Solana was the exception but I mean ultimately you just have to assume that you know, teams the team can figure it out, right? And it can be successful you know, and like stay staying at it for a long time and like build a community and like go to market and yeah, solve some of these challenges not that like they are solved in the beginning.

It's like the big challenge I guess as an investor to it yeah, like to play out to to play the scenario out you know, like five years, right? Because yeah, you're you're locked up anyway anyway, right? It's like it doesn't No what happens in one year and 2 year, in 3 years, you know. Um like what matters is only like how is project doing in like 4 to 5 years, right? Yeah, it was one of the things I was like joking about with this last night. It was like like like there's a I mean other people in Solana will say this. Like there's a I almost certainty that like there will be some sort of like variation of liveness failure or if you like look at like a long enough time horizon for Solana and like the same thing is true for all of these rollups

and other chains of like we've seen the same thing with sequencers of like multiple of these rollups whether it's base or arbitrum like at times where the sequencer has gone down or it's being DDoS'd and you can't get a transaction through and all these different things and like they need to iterate and like fix these things. Like it's going to happen with early stage tech. If you're basically not Bitcoin or Ethereum at this point, you should really be kind of pushing the limits for the most part of like how can we actually get this thing more performant like and really kind of juice it. Um and so yeah like yeah I was like joking I would like it would be very nice if like the next time there's a liveness failure for these chains it's for some like ridiculous exogenous reason and that like Solana and the

rollups and like multiple of them just kind of go down at the same time so it's not like a tribal like OC Solana went down like or OC like your sequencer went down and we could both realize like it's early stage tech like Yeah. it's going to happen at times. Like you need to plan accordingly and like you know try to kind of push the limits sometimes. Okay, so we we get the parallel execution um you know in Solana in the SVM we have uh what you what you call it, you know, deterministic parallel execution and then we have some some some other projects you know Monad um say and they're doing speculative um parallel execution like we learned that these are quite different. One works with access lists and one works with using heuristics for you know the pipelining of the transactions.

Um and so does this solve all our problems? You know, is this is like going to make you know you know Ethereum or like new blockchains you know magically much more performant? Uh short answer no, unfortunately. Um like the the kind of like basic framework to look at it is like I mean like nodes have a bunch of different resources that they need to use. Whether it's like disk space, IO costs of like going in and out, like actual raw compute, bandwidth, all these different things. And like there are multiple bottlenecks kind of along that supply chain. Like you kind of got to figure out like what is like the bottleneck and like how to address that before kind of moving on to okay, what is the next bottleneck after that? And particularly for Ethereum, that is like

kind of what the case is for like parallel execution. Particularly looking at Ethereum itself is like you can optimistically execute transactions in parallel for Ethereum, but like that is not actually like the bottleneck like the gas limit is intentionally constrained on Ethereum to limit the state size growth. And like you so you can sequentially execute transactions at a much higher gas limit than Ethereum is doing right now. And you see that like on other chains. And what actually is the the bottleneck kind of for Ethereum and that is state growth.

And so the perfect example of like what happens when you push it too far is like you look at what happened with like BNB chain like roughly a year ago ish. Of they fork Geth which is the primary Ethereum execution client like didn't make modifications and just said like okay, let's just juice the gas limit like incredibly high, you know, do hundreds of TPS. Yeah. And the EVM can do that. The problem was that running it at that speeds without any optimizations at all Mhm. just like the state size started to explode. And even with like a small validator set and really high hardware requirements Yeah.

they were able to still kind of keep up with that. The problem was it just became impossible at a certain point to be able to like sync to the chain for a new node. You just like it was just actually just like impossible at that point even with like a supercomputer basically to like actually to sync to the chain and catch up. So what they ended up doing was like they okay, they reduced the gas limit, they added Aragon as a client, which like deals with state differently, and like Real is like, okay, there like there is a fundamental bottleneck here. Um and so, that is a lot of what like Monad like uh kind of pushes on is like parallel execution tends to like grab the headlines, um but if you don't like solve the state bottlenecks kind of in Ethereum first, well, then it doesn't

really matter because like the like doing like simple math, imagine that like the just like making up numbers, imagine that the like EVM could do, say, 1,000 TPS with parallel execution, and it could only do 100 um with sequential execution, well, if like going over that was just going to blow up your state size so far that, you know, it's just impossible to use the chain anyway, well, then like it doesn't matter that you implemented parallel execution. So, you need to implement all these other changes kind of holistically to deal with state in like a very different matter. So, like that's a lot of what they're doing is like they're literally just rewriting a new client from scratch in C++ and Rust. Like like basically like the FireDancer ish like of kind of the EVM world is like, okay, how do we need to like optimize this thing from

the ground up because just doing one thing on its own like is is not actually going to solve any problems. Yeah, let's say it again for the folks in the back, right? Like the the the key bottleneck um for scaling your blockchain is actually state growth. Um let's unpack that a bit. So, what's in the state? The state is like actually somewhat hard to describe. It's like almost like intuitively, it is like basically a snapshot of like all of the current stuff that matters in Ethereum as opposed to history, which is all like which is like everything that has happened. So, simple example is like if we transfer, you know, one ETH me and you back and forth 100 times, like all of those transactions are like in the history, the state of the chain at the end of that is just like you have one

ETH and like I have zero ETH. Like that's that's the state. Um so, in something like Bitcoin, that's like really simple. It's like literally just like the UTXO set of like what address has what coin. Like that's a that's a very simple state to keep track of. In Ethereum and in other chains I think I think it's actually what coin has what address. But yeah, I'm surely a little bit, but yeah. Um But yes, it's much it's much simpler. And as opposed to Ethereum or any of these other general purpose virtual machines where it could be like anything where you have a smart contract that has arbitrary code and data in there and that is like tracking, you know, who has what tokens and like who's approved what and all of these different things.

So the state is much more complex. Yeah. And it gets a lot bigger. And like the primary bottleneck for Ethereum ends up being basically the state size just continues to grow indefinitely. Like that is kind of like the fundamental resource pricing problem of I do something which changes the state of the chain and updates it in some way. Like I pay some cost up front, but the problem is that is that I have increased the state size and that is just like an eternal burden on the network that is just an ever increasing Okay, now every future node that ever executes another transaction, this adds a cost for them. It is now harder for them to compute new states because like I have just forever increased the state

of the chain and there's like no kind of rolling that back. So that is kind of like the fundamental resource pricing and so like the different approaches to that. So like Before we go into that, I I I do want to like build some more intuition. Yeah. For how like why is this a problem? So why is like the state the state size a problem? Walk me I guess through like an operation of like how the state even comes into play when I make an Ethereum transaction. Yeah, so so concretely like on the resource side of things, basically history is not like as big a problem. You could stick it on a hard drive. Hard drives are cheap. Like you don't need access to quickly.

The the problem with state is that you need to be able to like access it like relatively quickly as a validator to be able to like look things up and like up to because what happens in a block is that like a validator is executing all these transactions and they need to compute the new state at the end of it. So, that requires like okay, I need I get a transaction that says update my balance from zero ETH to one ETH. Like that validator needs to go look through the Merkle tree which Merkle tree is the data structure that Ethereum stores all of its data in and they need to like go look up like okay, that's this person's account. Okay, I found it at the bottom of the tree here and now I need to like update this leaf to say this and now I

just update the entire tree. Um, so that the problem is that like you need to be able to access that like in like relatively real time throughout the block. Um, and so you can't just like stick it on a hard drive. You need like relatively quick access to it. So, the easiest thing would be okay, just stick it in RAM and you have like instant access like keep it in memory. But obviously you can't have 1 TB of RAM. I think. Exactly. Exactly. Yeah. Like and that is what like some if you're like super high-powered and you're you know, you're running a relay that's like trying to be like super optimized. That'd be like you can do that. Like you literally just stick the whole state in RAM and it'll be yeah, it'll be fast.

Because now you don't have to reach down at the disk to go look things up. But if you can't have that, yeah, then you'll be storing most of the stuff actually on disk and you'll be yeah, basically like pulling it into RAM, looking something up, putting it back, taking something else, etc. So, okay, we can already see there's probably like an infinite amount of optimization that you can do just in predicting what state you need. I mean, either the user tells you what kind of state you will need like in Solana or you will have to optimistically predict what kind of state you need and that's the kind of the other system, right?

Yeah, exactly. So, for like for any validator reason like you don't want to obviously don't want to require like you need a terabyte of RAM. So, people put it in a like SSD is what you practically need to store state in as an Ethereum client. Um, and so the bottleneck ends up becoming concretely like the disk size of like how much data am I keeping and then the IO costs of like reaching down into disk and going back out. Like that is like a heavy operation. Okay, so when people say IO, they mean reading from disk into RAM and like that's the I and the the O is like from RAM to to hard drive. Okay.

Yeah, like it's really easy to if you just have everything in RAM, which is like in memory, which is just like live, um, it's like very easy to look stuff up in there. It's just like it's like effectively like instant. It is a more computationally intensive like when you're storing something in SSD to like reach into it, look up something, and then get it back. Like that takes more time and resources. Um, and so like that ends up becoming kind of the bottleneck is that state size just keeps growing indefinitely, um, effectively like the the way that it's currently structured. And so the bigger the state size grows, the harder of an operation that becomes continuously of like the bigger the state is, the harder it is to go like look through it and go find like, "Okay, this is this person's balance." Like the

Merkle tree just keeps getting bigger and you're looking deeper in the tree every time and it's like it's harder to find things the bigger the state is. So it just becomes like increasingly problematic as the state size grows. And obviously like as like as a species we're like incredibly good at compression, but compression doesn't matter here at all, right? It doesn't help because you constantly have to like unpick it in order to use it. All right. Yeah. Um, okay. Now I want to hear about, you know, what does the solution space for this look like? So if parallelization doesn't really help us yet, like how do we remove What's the design design space like for removing the current bottleneck of of state growth?

Yeah, so the the short answer is there's no silver bullet. Um, there are different tradeoffs and different optimizations that you can make. Um, so kind of going through the list of things, um, I would say the the primary thing that Ethereum itself is focused on doing, um, is what is called weak statelessness. Mhm. And so the basic idea of this is that like currently the way that validators um work today is as I was describing is like they keep locally every validator client keeps locally a copy of the entire state. They keep it in their SSD and then when they go to execute transactions they're looking up, you know, through the tree and saying like, "Okay, this is the state I need to update. I need to update this." and so on and they execute everything. Um the

the proposal for weak statelessness is to change it such that you say the validators, "Okay, you don't have to save the state at all anymore. Um what we'll do is the builder um cuz now we have these like high resource builders that are actually building the blocks um is we just say like, "Okay, when the builder sends a block to the proposer um what they'll do is they include what are called witnesses with the block um and that's basically just giving the validator, 'Okay, here are the relevant pieces of state that you like need to go look at and update.'" So that the validator doesn't need to go search through, you know, keep an entire local copy of the entire state and like go look through everything. The builder just sends them with each transaction like, "Hey, here's a transaction to send

one ether miles to Bob. Like, here's the info you need to update the state for like Alice and Bob and like prove that like this is correct." Yeah. Um so you're basically shifting the work of saying like, "Okay, the validators don't need to do this anymore." and you shift a little more work over to the builders. Um so like there's a there's a lot of movement in this direction with Ethereum. It's like the same idea with like dank sharding of how they're going to scale DA is like that is kind of like the general philosophy is we're going to offload try to as much as possible offload work from the validators and like put it over to the builders. Um so like that is like the primary idea um that like Ethereum is pursuing as a solution to this because they want decentralization of the validators and

it's not as big a deal if like we have we have some resource requirements on the builders like they're already high resourced. Um so basically what that ends up requiring for Ethereum is you just need to switch the way that like uh the state is stored. Yeah. Like currently I was saying like it's stored in Merkle tree. Um modified Merkle Patricia Merkle Patricia tree specifically. You need to switch that to Merkle trees is kind of the technical change just because like with a Merkle tree like all of those proofs those like witnesses I was describing of like what state you need to update. With a Merkle tree those are just like Too big.

gigantic and super efficient inefficient that like it just like wouldn't work sending that over the network and being able to download this and everything. So a Merkle tree is a different kind of tree format. That lays out the data differently such that it's much more efficient and like the witnesses are like just like actually very small so it's not like actually any meaningful increase in like bandwidth or anything like that. So that that is the primary solution that like Ethereum is kind of pushing towards. It really reminds me of proposal builder separation. It's kind of Yeah. Yeah, it leverages and relies entirely on that. Like without proposal builder separation like it doesn't work. You need like that is the kind of like fundamental truth of this. Is that you always need someone to have the state.

Yeah. And the question is who do you want to give that burden to? Yeah. Do you want it to be a validator? Do you want it to be a builder? Do you want it to be every user has to know like their own local state? Do we want just like some other big provider to like store all of it? Yeah. Like someone has to have it and someone has to show it. The question is like just who do we want to give that work to? And like who do you kind of prioritize? And and how do you incentivize it? Right? Yeah. Which brings us I guess to the second solution. So the yeah, the next idea and this doesn't seem to be something that like Ethereum is prioritizing but you could start to see other places start to look at more like roll ups and

other chains is like some notion of like state expiry or state rent. So trying to more directly as opposed to statelessness which kind of just like shifts the problem to someone else. Um state expiry and state rent kind of tries to more specifically address what I was describing of just like the kind of fundamental resource mispricing that we have of like there is just a cost on the network that is like eternally there whenever I like I increase the state size. So the idea here is that after some period you would basically just take a certain you know like the the simplest idea is like let's say that we have an epoch of like one year and after one year what every client does is like okay all of

the state that is older than one year we just prune that from the tree and like we just cut that we like get rid of it. Um so it doesn't like make the data like disappear that it's you know irretrievable and like my money's gone. It just means that like if you know let's say I haven't used my account in like two years that means if I want to use my account again you need to have a transaction to kind of like refresh that state because otherwise they will have like pruned the old state but you just as long as you have the data to prove that like hey I did have this account it's just inactive you need to send another transaction that says like hey here's my state like please add this back to the tree and like that it's

ready to go again. And so these other retired transactions like retired like parts of state folks would still be it wouldn't just be you saving that it would be you know everyone but it wouldn't have to be part of the state it could just be part of the history you know it could be somewhere on some hard drive but it wouldn't have to be you know eternally on base layer. Yeah it goes to a like one of the end storage requirement of like someone has the data out there to be able to refresh this. You're just not mandating that like clients don't need it anymore like the actual like to be a validator on the network they don't have to store this anymore. So you're relying on either like the the simple centralized

providers or like that you assume that like our PC providers and block explorers and so on like that they're going to keep this, like there're business reasons to keep it. Um users could, in theory, like keep it themselves. Um and there are like more decentralized solutions um that can, you know, can store the whole chain and like all of the data. I mean, I guess people are already storing stuff on hardware wallets and so on, you know, and with custodians. So, it's will just like be one more thing for them to store, even on the same device. Yeah, generally like the one of end storage requirement isn't seen as like, you know, kind of a major blocker or something like this.

What about state rent? Um yeah, so the idea there is that basically um you you can also expire state based on like, okay, we charge them ongoing fee to like maintain this account. Um and there are like there's different ways to do it. Um but you could literally just like have like, okay, the you know, there's continuously continuously like some amount of your balance is taken out just to like keep it in active state. And then like if it runs out of balance, then like we push it to inactive state. And then same idea to refresh it, you would need to like show proof and here's a transaction and like pay a fee of like, "Hey, like please bring this account back. Like I want to use it again." Um again, just you know, charging in some way of like for the fact that like, "Yeah, we're

keeping this actively around." Um obviously that gets like more complicated. There's kind of like UX things to think about with that of like, you know, charging people continuously and like making things more complicated there. Um yeah. It's the basic idea. And could you do this today on Ethereum if you wanted to or would it break everything? Uh for state expiry and state rent, yeah, they they're kind of like breaking changes. Like you'd need to make meaningful changes to Ethereum that are like probably not realistically going to happen. Here they are annoyingly there in this in this camp. I mean, so if you make a new blockchain, there's there's things that you can basically differentiate on with like the the with like your kind of your you know, your early users. And then there are things that you can differentiate on with like your later

users, you know? But it doesn't make sense to differentiate with any of the later stuff. And that definitely includes everything related to state growth, right? I think that's what I have we haven't seen in the web any innovation on this because no chain really other than Ethereum has run into this limit, right? I mean, you could say okay, maybe Binance Smart Chain has, but I mean they have like seven nodes, right? So, um and they I guess they don't really have a tech team that's really like um looking for long-term solutions. So, Yeah, problems like this and like to a somewhat similar extent like MEV, too, is just like a general thing that when you're launching a new chain, this is just not the thing that you're incentivized to figure out. You figure this out when it's a problem, when we

have enough activity and like have things such that like there is MEV. When we have enough activity such that there is state growth. Um but when you're starting from scratch, like you just don't have that problem really, you know, you think about it later on when it starts to get bigger. MEV, I mean, you can you can get it right away. State State growth, less so. MEV is changing, yeah. Yeah, I mean, nowadays, I think people are aware like okay, front running, huge problem for traders. LVR, huge problem for a piece, and so there's actually now a lot of incentive to make, you know, quote unquote like finance chains that are MEV optimized or or something like that, so.

Um but yeah, state state growth, that that one's like a 5-year plus even under best conditions, like a 5-year plus problem. Yeah. So, you end up back loading it. Um what about uh you know, any other approaches? So, the one to at least I quickly mention is like Solana just does this completely differently. Uh you can just have like a fundamentally different model of like how you require people to store state. Um so, Solana just like doesn't have its validators like keep a Merkle tree actively like that has all of the state such that they're like always updating the Merkle tree every um block.

They just like ripped it out basically and only like Merkle-ized it like very infrequently. Um so, that makes it much uh like that makes it an easier problem to deal with. There are also other trade-offs with that of like it makes it more difficult to make light clients and prove it in like certain ways. Um but like there are just completely different models like that. And and then lastly to mention I mean is a lot of the stuff that is like very client level optimizations that like different teams can do. And like this is some of the stuff that like you know Geth and Aragon and typical Ethereum clients have worked on and that like a lot of what Monad is doing is like okay why don't we just rebuild this thing from scratch?

Um just making a lot of different optimizations. So like simple things that you could think of as just like an example that like you know current clients Ethereum clients even do um is just like as we mentioned before it's really expensive operationally to kind of like reach down on disk and look up you know different state. So different clients what you could try to do is try to be really efficient about even though you can't fit all of the state in RAM keep like some of the state in RAM that in particular is the state that is like most likely to be used such that like if that's the stuff that I'm constantly updating just keep that in RAM and then like it's really easy to update it.

I guess that as a new chain you can't keep everything in RAM the state is actually zero. Yeah exactly. Yeah but it wouldn't scale. Yeah and the problem is again like okay but as the state size grows now disproportionately you can't keep it in RAM the SSD is growing and like more and more you're reaching down to disk as opposed to like just being able to pull stuff out of RAM but like that is an optimization that like makes sense to like try to keep what you can in RAM. Um and then Monad a lot of what they're doing is like I mean this is why it'll take the time to do this stuff is like they're just like rewriting the whole client from scratch and like putting a completely different database like Monad I think Monad DB I believe is what they call it but just like using a

completely different database to store all of the data in the Merkle tree that is like much more optimized for being able to like look stuff up in here quickly. Um But then, do you know if if Monad is also looking to innovate on like that the you know, the the state size, state growth size? Because I mean, so there's a few things that we said and now we are trying to put them together, I guess. One is that, you know, parallel execution is going to be table stakes, you know, it's one of those fundamental improvements of the virtual machine that, you know, you won't get around. Everyone will use it.

Second, the real bottleneck of scaling blockchains today is actually the state size and how to manage that. But number three, there's very different things like like a a kind of a new blockchain, you know, it has different things, like different inventory of things to differentiate on that in a five-year-old blockchain than in a 10-year-old blockchain. Yeah. And like this kind of this the state growth is is kind of a five-year problem. So, in Monad is like a zero-year-old chain. So, um Do you think that like for a new chain, the solutions are kind of, you know, sufficiently in place, theoretically speaking, to

like go into, you know, the benefits of parallelization now? Um maybe also with the expectation that, you know, either you know, by the time we get there, like and we're a new chain, like there's things we can do, but also maybe the space itself will have matured and, you know, by the time there will be new solutions, etc. So, parallelizing execution on its own like wouldn't really help any chains today. Um any of the EVM chains EVM chains, like if you look at like the gas limit, like Arbitrum or Optimism or Ethereum, like any of them, they're not actually bottlenecked right now by execution. It's just like it's state problems. Um and especially as they go longer. Um,

and so it's going to be dealing with that kind of first and like that's why like Monad is kind of like doing both of them together, um, is to deal with that. Um, but like yeah, I mean to your point of like most of the stuff that I certainly imagine that they're going to be focusing on early on from talking to them is like more of the kind of performance related client level type things of like okay, how do we store this in a different database that's just like it's super inefficient, uh, su- super efficient, um, as opposed to like how do we think about properly expiring state uh, to like keep that in check because like that's just like not what you need to think about quite frankly as least as a priority as a new chain. That is like what you think about kind of after a few years. Um, and

also just disproportionately what more Ethereum researchers are also working on like Yeah. you know, Monad doesn't need to lead the charge on like how do we implement like weak statelessness or something like that like like Ethereum is like doing that already. Um, so both like the older chain is like more incentivized to work on those things and like they're doing a lot of that stuff as well. Uh, while also still like, you know, a lot of it overlaps and they'll be looking at it, but yeah. Yeah, so okay. So in in general you would say that okay, so parallelization alone doesn't really help you, but if you bundle it with a bunch of other basically like rethinking of the whole client architecture and like state management and so on then you can also generate some immediate benefits as a new chain. Like and and those are basically is it is it

just like you know, higher TPS, lower latency? Yeah. Yeah. Okay. But yeah, it doesn't it doesn't But yeah, the parallel execution doesn't help you if you have like a super inefficient database that like, you know, you can't look stuff up quickly to update state anyway and like quickly retrieve data. Um, like they they kind of go hand in hand. To zoom out, you know, a little bit, um, before we close out here, do you think that um all of these approaches to to doing it? I think we saw, you know, the EVM on the one side, um, saw Solana on the other side and then, you know, Monad and Sei in the middle and like some other chains as well that, you know, are neither Solana nor EVM but use, you know, Move or something else.

Um are these converging on the same shared end game? Like is this a temporary fork in the road and then at some point they converge on some, you know, mega thing or that's what, you know, triple ZK scaling or whatever, um you know, recursive to the nth degree or are we moving to permanent places of differentiation here? I mean, there are going to be some things that are fundamental and like are not going to change.

Um I would say the majority of it is going to converge more and more and more. Uh like certain things that are just like not going to change are like something like like we're describing with like mandatory access lists. Like Ethereum and EVM chains are just not going to add that cuz it would just break compatibility. Um but are you going to get to roughly the same place where, you know, we execute transactions in parallel in like a very similar manner? Um like yeah, like that that seems reasonable on like a long enough time horizon. So, the the exact mechanics of it, like some of them are fundamental and you just like you can't change them like because like I mean, in theory anything could be you know, like in theory like Facebook could become Google tomorrow if like they just make all the

changes to the company but like they're not going to do that cuz uh obvious reasons. Um and it's like it's kind of the same idea here is like there are some reasonable limitations to like what you can't change because it's just going to break everything and so those won't be done. Um but directionally everyone is kind of moving to the same ideas of like, okay, how do we just like deal with state in a much more efficient manner? How do we try to price this more accurately like in the long run? Um how do we access it more efficiently? And then like on top of that, how do we execute transactions in parallel to kind of take advantage of that? Um It's all the same concept. So, it's basically just like validators have resources, nodes have resources. How do we use them as efficiently as possible? It's solving

one bottleneck after another, and like most of the ideas are like kind of the same. And like they're not even just blockchain specific things. Like you know, taking advantage of multiple cores and like having software that can like execute stuff in parallel that is just like a general thing that you try to do in like software development. Like you don't want to have single-threaded processes cuz like it's a bottleneck. So, it's like it's borrowing a lot of like those, you know, kind of traditional things. Yeah. I think a lot of, you know, design philosophy in engineering is like moving things that don't scale into things that do scale. You know, like moving What's a good example of this? You know, maybe like it's it's the IO that that doesn't scale, but the compute does to the degree that you can parallelize it. And so, you replace try to replace like more

IO with like more compute because compute is, you know, infinitely cheaper to scale basically. And it's like affected by Moore's law and and all of those things. Yeah. Cool. I think that was a really great overview. Yeah. I think we hit everything on that. Thanks, John. Let's Let's do this again soon. Cool. Thanks, everyone. See you. See you. Thanks for joining us today. As always, nothing we say here is investment or legal advice. The views expressed by the co-hosts are their personal views alone. Please see our podcast description for more disclosures. If you enjoyed this episode, please feel free to subscribe and share it on Twitter.

Thanks, and goodbye.