Multiple Concurrent Proposers on Solana and Ethereum | Anatoly & Max

Transcript

The original goal of this whole blockchain experiment was to remove centralized intermediaries and one way to do that is just break up this natural monopoly that forms as a consequence not of any deep reasoning or efficiency or anything. It's just the things that the consensus protocol engineers were optimizing for did not include censorship resistance or distributed information collection. All right, everyone. This is a message for my Degen listeners out there. If you are getting scalped, paying expensive fees to perp DEXs, I highly recommend that you check out Index Co-op's new leverage suite. Now, whenever it comes to leverage, do your own research. This is not financial advice. Don't bet more than you can lose. All that good stuff.

But, if you are going to lever up, you might as well not pay an arm and a leg for it. You can get leverage on BTC and ETH with built-in liquidation protection, now available on Base, mainnet, and Arbitrum. So, click the link in the bottom of the show notes and head over and check them out today. And you'll hear more from them later in the program. Hey everyone, this episode is brought to you by Supra, the vertically integrated L1 for super dApps. They've a very cool new product coming out called Supra Containers, so head over to supra.com, that's supra.com/containers. So, if you're building on an L1 and it feels a little bit crowded or the complexity of L2 and L3s are getting you down, just head over to Supra. They'll get you sorted. Thank me later. Hey everyone, this episode is brought to you by Fuel Labs who's launching Fuel

Ignition, a new high-performance Ethereum L2 powered by the Fuel VM. Now, you're going to be hearing all about Ignition later in the program, but for now, what you need to know is they are launching phase two of their points program. So, click the link at the bottom of the show notes and head over, start experimenting, messing around on Fuel today. Thank me later. All right, everyone. Welcome back to another episode of Bell Curve. Before we jump in, quick disclaimer, the views expressed by my co-hosts today are their personal views and they do not represent the views of any organization with which the co-hosts are associated with. Nothing in the episode is construed or relied upon as financial, technical, tax, legal, or other advice. You know the deal. Now, let's jump into the episode.

All right, everyone. Welcome back to another episode of Bell Curve. Today, I'm joined by Anatoly Yakovenko and Max Resnick. Guys, welcome to the program. Thanks for having me. Thanks for having me. All right, this is going to be a very fun episode. We're going to be talking about multiple concurrent proposers. And just to caveat to listeners up front, this is going to be a relatively 301 uh style episode, and we're going to peel back the layers of the onions and get into the specific designs that Anatoly you've spoken about over in Solana land. And Max, behind your plan to make Ethereum great again. But before we start getting into the weeds, I I want to just set a little bit of groundwork and lay a little bit of groundwork for the audience. So, Max, maybe I can kick it over to you here first. You were the

first person that I heard use this term, the proposer monopoly. So, can you describe what is the proposer monopoly and why should we break this up with multiple concurrent proposers? Yeah. So, the the proposer monopoly is something that arises from this kind of accident of the architecture of the blockchain. And in most blockchains today, we have this single proposer architecture, especially the proof-of-stake blockchains. That means there's only one proposer who, within their slot, has the power to include and order transactions however they see fit.

That allows them to charge monopoly rent on the state. It also allows them to do certain things like censor transactions, which can really affect a lot of financial applications that you would want to build on chain. And we kind of stumbled across this fundamental truth of blockchains through a very deep dive into how to mitigate these this LVR concept. So, LVR is loss versus rebalancing. And it basically talks about the fact that on-chain exchanges have quotes available for the taking and because block times are much longer than the ordinary time windows in high-frequency trading, the prices on say Binance might move and the prices on

Ethereum would be stale and then that difference is there for arbitrageurs. We wanted to basically hold an auction that would allow you to take that arbitrage and auction off the arbitrage to reduce it dramatically. Reason we wanted to do that is because we wanted to create lower spreads on chain. And ultimately all of this came down to basically trying to create lower spreads on chain, going super deep and then finding out that a fundamental reason that spreads were so deep is because of this proposal proposal monopoly getting in the way of a lot of the easy mitigations that you might try to do.

All right, so I just want to recap for the audience here. When you're looking at a proposer, what they're really doing is they are running an auction for access to block space and the prerequisite of hosting a good auction, which is not maximally extractive, is this concept of censorship resistance. That's the base fundamental building block of hosting a good auction. So, if you're a proposer and you have monopoly control of the block, you can do all sorts of these extractive things that result in negative externalities such as lever, right? So, Anatoly, can I actually just kick it over to you here because you've actually been talking about multiple concurrent proposers from for a long time. So, do you come at it from the same angle or from a slightly different angle from Max or why is this design exciting to you?

I mean very kind of similar point, but way less academic and kind of more gut product instinct. So, our silly tagline is blockchain and Nasdaq speed and what I thought was really cool about these systems is that they can replicate state globally. And this is a issue with finance is that costs an arm and a leg to get like tier one data feeds from NASDAQ. Like you have to pay them a lot and then you have to pay somebody else a lot of money to be put in the Equinox uh bunker with all the other trading systems to get the exact same censorship resistance to trade at a fair way in in these exchanges.

And you know, my experience I was an amateur trader, wrote these stupid bots uh did weird things on Interactive Brokers and went out on a whole bunch of things. And at that time, this was pre This is around the time of Flash Boys, so it was way worse on on normal markets, but you literally like if you had a strategy the data that when that strategy would work in backtesting, when you went to deploy it in real markets the data would slow down or your submission of your transactions would slow down and somebody else would take that opportunity. It would just like happen over and over. It was It was pretty funny. So

when I started building Solana, that like experience was very much rooted in in my understanding of how markets are unfair because of centralization. And I wanted to fix that and the thought that I had was that you can't you know, the advantage that these systems have that are in NASDAQ is that they're super highly optimized and they can have sub one millisecond matching and the algorithms can be co-located with these with the the matching engine. Just by physics, they're very very close together. So the amount of time to send those bits to the matching engine is just very short. Um and that's impossible to beat with a global system.

But the things that actually matter to the world, the events that move markets, happen everywhere in the world at the same time. So, what you could do instead is you could build block producers next to where those events happen. Since we can't predict where they happen, we just have to have a lot of concurrent block producers at the same time everywhere. So, when a news-worthy event that's going to move market happens, the latency from that event to the local block producer is shorter than the latency to New York. So, by the time that information hits New York, that arbitrage that he's talking about with Binance doesn't really exist because there's already transaction propagating to hit that market on Solana. So, you can't go get that free arbitrage between the two systems.

And while they're going to be different and weird and it's not going to be the same as trading in Nasdaq and you still have these block times that are limited by global, you know, decimation of information, if you can eliminate that free arbitrage, you can make that case that it's as good as price discovery as decentralized systems. And to me, that was just really, really freaking cool because even if Solana hardware is expensive, it's still hardware that's available to anyone in the world. It's still open-source software, effectively volunteers running the stuff, you know, as hobbyists can compete with these very, very expensive centralized systems. That to me is a very disruptive thing. So, that was a dream, the goal,

it still is, and it's a it's a day-to-day engineering grind to kind of make progress towards it. Yeah, maybe we can dive a bit deeper onto this point. Like, why shouldn't we have nodes all over the place doing exactly what you're describing in the single proposer world? Um the reason is what matters is not just your proximity to the information source. So, say the thing there's an earthquake in Tokyo and so, I want my node in Tokyo to be the first to pick that up, for example.

Now, I need to also get to enough other nodes in the network to get my block to be valid. And in a single proposer world, we are actually doing the math right now, writing a paper on this. That just the fact that you have to get to the other nodes means that proximity to the other nodes matters just as much. So, you can be indifferent between moving closer to the other nodes, say those are in AWS East 1, you can just move over to AWS East 1. It'll take you longer to get the information from Tokyo, but it will take you less time to get to the other nodes to get your block validated.

But in a multi-proposer world, that isn't necessarily the case. And so, the theorem that we're showing, the main theorem of the paper that is coming out soon, is basically in a multi-proposer world, you natively get geographic decentralization for exactly the reason that Anatoly mentioned, which is you want to be near the information sources. And that same thing doesn't happen in a single proposer world because it's just better to be as close as possible to the other nodes and just wait as long as possible to propose your block and propose it with as much information from around the world as possible. And you can't do that same thing if other people are located elsewhere, also able to add information to the block,

then that's when you get exactly the phenomenon that Anatoly was talking about, where you have co-location around the world with different information sources and native geographic decentralization just from the structure of the market itself. All right. So, Max, it seems like you've arrived at this architecture of multiple concurrent proposers from the vantage point of maximizing censorship resistance. And Anatoly, you've actually arrived at this architecture from your North Star of decentralized Nasdaq. And Anatoly, I've heard you articulate the point before that this system could actually compete successfully with something like Nasdaq. And something that you often hear is that no decentralized system will ever be able to compete with NASDAQ because it's just

a centralized box and nothing can be faster than that. But, there's this really nice alignment actually in between the decentralized design here and performance because you can actually input system information into the system faster. So, if there's an event that's happening in Tokyo and you need to transmit it all the way over to NASDAQ, you're kind of subject to the speed of light, but if you have local producers, the system can actually ingest that more quickly. Is that accurate? Uh so, this is my engineering gut level thing. There's no paper. Max is going to write the paper if is that the markets are all intertwined and they're all global and it's uh

their purpose is like if it they have like a set of state. The the the set of bits that represent them in any given moment in time. And then there's a set of bits that's on chain and the delta between them that entropy, if you can shrink it and reduce it as much as possible, you end up with a better representation of the world on chain. So, that problem like the only way to solve it is to just start dumping that information that is happening globally around the world as fast as possible into the into the chain state. The only way to do that is with multiple concurrent, you know, consumers of that information that are producing it, right? Like so, you need that's just a very, very dumb gut level

thing, but if you think about it from like we need to take all of this information around the world and go synchronize it. Just start doing it everywhere at the same time at once. Um And it should result in better pricing than a centralized system. And if that's true, I think it's like kind of a miracle because it means that decentralization has a product advantage over a centralized one. And there's no cost to make it permissionless, like that the extra signature checks and all this other stuff, the cryptography and the consensus protocols have gotten sophisticated enough that they're not going to add overhead to like actually make it price competitive to run a

centralized version of that that removes some of the safety that you get. In fact, if I was Nasdaq and I wanted to replicate this, I would force my engineers to go make it as safe as possible, which means copy all the that the decentralized people are doing, right? Because like so this is kind of like a miracle in my eyes, the fact that this is so aligned with permissionless and decentralized values, but it's also a better product, um means it'll survive as an open-source thing. Um and it's really, really rare that that happens.

Most open-source projects die or end up being like a weird SaaS company trying to like, you know, arm arm arm, you know, arm twister their open-source users into paying them like a ransom or whatever. Um so, it's kind of really, you know, a beautiful thing if it works and uh obviously creates value for the world because open fair markets that are globally distributed just create, you know, better pricing for consumers and and that's awesome. It saves saves people's money.

Yeah, I mean, and the the goal of this whole thing was to create finance without centralized intermediaries. And if you actually look at what a blockchain is today, it isn't that. Like, there are centralized intermediaries. If you zoom in enough to the time scale where trading actually happens, then it looks like there's like very few participants in the system because it's like going from the user to the wallet RPC to the builder to the proposer who is, you know, 20% of the time is Coinbase.

And that the number of actual steps there and the number of actual ways to get on chain narrows a lot once you zoom in onto a time scale that the trading actually happens on. The original goal of this whole blockchain experiment was to remove centralized intermediaries and one way to do that is just break up this natural monopoly that forms as a consequence not of any deep reasoning or efficiency or anything, just the things that the consensus protocol engineers were optimizing for did not include censorship resistance uh or distributed information collection. And so they had their table of things that they were trying to build a protocol to do. One of them was low

latency, one of them was high throughput. Uh one of them was communication complexity. And they never added in the like censorship resistance thing, which is super important. And so they just optimized for that and then we ended up with a single proposer architecture, which turned out to just not be a great system for the main use case of blockchains, which is decentralized Nasdaq, hopefully eventually decentralized Nasdaq. Awesome, guys. Well, this is really exciting so far. And now what I want to do is actually unpack some of the early implementation details that both of you have put forward. And I think there's a lot of overlap in the Venn diagram in between both of your designs or how you're conceptualizing actually implementing this in practice.

So some parts look pretty similar, but I think there are other parts that look pretty different and distinct as well. So Max, why don't we start with you? I'd love to kick it over to you and could you just give us an overview of your design, which is braid? Um so give us the kind of 10,000 foot vantage point and then we can drill down into some of the specifics. Yes, I think there are multiple ways to implement multi-proposer. I'll talk a little bit about first before I get into the design what we were trying to do with our implementation. Which was first we wanted people to release at the same time because we didn't want people seeing the contents of other people's blocks or having significantly more information about which events took place.

So, we wanted to try and get something like a synchronous release property of the mechanism. And the other thing we wanted was we wanted this to kind of be compatible enough with Ethereum or with other chains that it had a chance of actually being implemented cuz you could say like here's a brand new consensus mechanism and it has nothing to do with LMD Ghost, it has nothing to do with um Tower BFT, whatever. And try to get that through core devs and you would have like a really hard time and so this was something that we wanted a similarity between this and LMD Ghost for a possibility of being included in Ethereum or in other

systems. So, we started with that goal in mind. And then we came up with something which is consensus agnostic. Basically, you take an existing consensus protocol, whether that's Tendermint, HotStuff Tower BFT or um LMD Ghost, Goldfish, all of these things are possible. You put many instances of them side by side. So, you put K of those side by side, that's how many proposers you have. Each of those chains runs independently but are interpreted together.

And that's you produce an unfinalized head of the chains like that and then trailing that you have a finalization gadget similar to uh what we have on Ethereum that is what produces the finality and so you have these kind of unfinalized head chains that are all running in parallel independently and then an execution client and a finality gadget that are interpreting those things, executing them all, and producing state root, producing finality and consensus on that.

Awesome. I am and I didn't I didn't invite you here to ask any questions as well as I'm just going to drill down and ask a whole bunch of questions on this, but um you know, in terms of could you just say a little bit more Max about the finality gadget, how that actually works in practice, and then what does it ordering policy going to look like once these different strands end up getting unified? Yeah, so we have like uh I'm not sure if this is like exactly the venue to get into like the the specific details of how the finality gadget would work, but we have a finality gadget right now on Eth. Kind of the way it works is we wait until we have a consistent view of the chain, so several blocks, and then once all of the people have a consistent view of the chain,

we can just run like a BFT consensus, and because we have the consistency, all of the replicas have the same input and therefore the output of the BFT consensus, as long as it's a correct consensus algorithm, will produce that that same input. And so the the reason that we're able to do this braid architecture with any consensus underlying it as as the parallel chains is because if those parallel chains achieve eventual consistency, then anybody who's looking at this process will see, okay, chain one is eventually consistent, chain two is eventually consistent, chain three is eventually consistent, and so on. And so the whole list of chains is eventually consistent, and we eventually have a shared view on what all of the chains

look like, and then we can just run a BFT consensus to say, okay, we all have the same view of these things that happened, say a few slots ago. We've had time for that to settle down and resolve. Now we can just run a finalization protocol, agree on everything. We we have the same input, so we're going to get the right output. And that's basically how it works. So, it's similar to how Ethereum works today. How do you anticipate this changing the time to finality? I know that single slot finality has been one of those items that's been on the Ethereum roadmap forever. It's incredibly crucial to composability, especially at the L2 level. So, how long is it going to take to come to finality in braid versus the status quo?

So, right. So, we have this eventual consistency property. The consistency of the whole thing, the all of the set of K chains running side by side is the pace of the slowest chain. If the slowest chain has single slot finality, then the whole thing can have single slot finality because the worst case is we have single slot finality. If the slowest chain has 32 slot finality, um then we are going to have 32 slot finality.

And if there's something fuzzy in there where we don't necessarily know, sometimes you have to do this if you want certain other assumptions like the sleepy model, which is called like World War III resistance by Vitalik. If you want to include some other things, sometimes you have to sacrifice. And so, if you want to do something like LMD ghost, which doesn't necessarily have uh concrete finality until you get to the finality gadget, then you do have to go at the pace of the slowest chain. That can slow things down slightly, although it's not it's not that you slow things down in the worst case, you may slow things down slightly in the average case for finality.

Uh but it doesn't it does like really depend on the underlying protocol. Hey everyone, this episode is brought to you by Index Co-op and their new product the leverage suite, which I highly recommend you check out. Click the link in the bottom of the show notes. Now, disclaimer, whenever it comes to leverage, do your own research. This is not financial advice, all of that good stuff. Don't bet more than you can lose. But, if you are going to lever up, you might as well not pay an arm and a leg and save a ton of money and use Index Coop's Levered Suite. So, the way that they actually achieve these savings is pretty cool. They leverage the power of money Legos, DeFi, uh in this case Uniswap and Aave. So, the cost of carry for this trade is actually based on the funding rate of Aave as opposed to perp

DEXes, which tend to be much more variable and higher overall. Additionally, perp DEXes will also charge you usually based on the entire uh open interest, so the leverage exposure that you have as opposed to just the amount of money that you put in, which is what Index Coop is doing here. And the result of what you get is just an ERC-20, which gives you something like 2x ETH. So, you want to lever up and you want to save money doing it, I highly recommend that you go check out the Index Coop Levered Suite. Very, very cool. Thank you very much, Index Coop, for making this episode possible. Everyone, this episode is brought to you by Supra, the new blazing-fast, vertically-integrated L1, which helps you scale your dApp. If you are a builder, you're probably dealing with some combination of cost, complexity, and fragmentation of

existing solutions. So, you're building over in ETH L2 land, everything's feeling a little bit fragmented at the moment, and if you're building in Solana, everything is fast and on one layer, but maybe you're limited in terms of what you can do with your app space. So, Supra is rolling out a new product called Supra Containers. So, you can head over to supra.supra.com/containers um to learn more. They offer dedicated, customizable app spaces running on Supra's 500,000 TPS layer one blockchain. That gives you complete control over gas tokens and fees. So, some cool things you can do, you get the freedom to you can use your own token, create local fee markets, or even go gasless, whatever you want. So, this product isn't live yet, but because you are a faithful listener of Bellcurve, you get notified first. So, head over to supra.com/containers.

Thank me later. Everyone, this episode is brought to you by Fuel Labs, who's unveiling their new high-performance Ethereum L2, Fuel Ignition. Many of you know Fuel as the launcher of the first optimistic stage two roll-up on Ethereum with Fuel V1. And now they're launching Ignition to address some of the creeping centralization concerns around some L2 architectures today. And if you like nerding out about the tech, there's a lot of reasons to get excited about Ignition, including how they solve state sustainability and perform an execution. They have this UTXO asset centric architecture that's very, very cool. But there's a lot of other reasons to love it. Super easy to use. You can either use a Fuellet wallet or your existing Ethereum or Solana based wallet like

Phantom or MetaMask or whatever it is. There are cool apps that you can experiment with. And again, like I said at the top of the program, they're launching phase two of their points program. So, click the link at the bottom of the show notes, head over, start having fun on Fuel Ignition today. And just tell them that I sent you. At what layer or stage in this process are you enforcing the gas limit? Because it seems to me that you could either enforce the gas limit at the individual proposer level where you could give everyone a gas limit of 5 million gwei or something like that. Or you could try to enforce it at the union level once you're actually trying to come to consensus and finality on each of these different strands. And if you enforce it at the union stage, you have a better global view of how much

gas is actually being used because you're de-duping transactions, stuff like that. The challenge is a proposer, you could play these sort of weird MEV games where a proposer fills up their strand with a whole bunch of different transactions and actually prices out other chains. And so you get these you might actually lose some of those censorship resistance quality and there yeah, new weird MEV games that you could play. But the challenge of enforcing it at the individual proposer level is that you're going to get a lot of variability and it's very difficult to capacity plan because you can imagine these two different situations, right? One in which there are 10 different chains and there is zero overlap in between all the different transactions in these chains.

And then another scenario where there is 100% overlap in between the transactions in all of these different chains. And so the block that you build at the end of this process is I is 10 times larger than, you know, the block where there's 100% overlap. So, how is that going to work? You should also have fee spikes there because the that that limit at that particular proposer is going to get saturated and then it reverts to global pricing, which which sucks. So, this is the million-dollar question, honestly. It's not how you how you order things together. That part almost doesn't matter which thing you use. It's how you split the resources between the concurrent proposers is is the toughest nut to crack here.

I think, yeah, the ordering rule there's plenty of ordering rule I think there's like several ordering rules that probably work fine. You You could get a really bad ordering rule if you like did random or something. You would have a ton of spam from that. But, if you as long as you're trying, you'll probably get a pretty good ordering rule. The how do how do we deal with spam and free data availability is really important. We have kind of results and kind of time spent on this. Let me give you a few options to choose from. One of them is we have a global amount of gas that we can process on our replicas. The minimum node requirement specify that we're allowed to do this many compute units.

And or maybe this many consecutive compute units or something like this. And we just make sure that no uh one of the K uh chains submits more than that limit over K. So, each we divide the total capacity that we have and we give an equal share to each of the proposers. So, that's like one thing. I think that can limit capacity. Here's another thing we could do. We could say we have a certain amount of compute capacity. We have a certain amount of bandwidth capacity, which is higher than the compute capacity that we have. We will let people produce, therefore, larger blocks.

And then, we will take everything in, order it, and execute until we get to the limit. And then the things that are not executed from below that limit just are not considered valid transactions. They don't affect the state. Uh I think I'm leaning kind of more in the direction of the second one because it allows us, if we have much more bandwidth than we have compute, then we can use that compute as optimally as possible and get a bunch of like avoid that bottlenecking that can happen.

Where do you get the sense that the other stakeholders like client teams, etc., like where they falling on this question? Is there broad agreement? On ETH or on Solana? Maybe maybe ETH I suppose, yeah. But uh Solana I'd be curious too, yeah. Yeah, I want to hear what what Anatoly thinks about the the Solana thing. But let me say on ETH I think there's um we're in a bit of a weird spot in ETH development where we have a lot of different people who want different things. And we need to at least decide what the objective function is cuz I don't think we even know what the objective function is. There's people who want ETH to be money, there's people who want ETH to be a settlement layer, people like me who

want ETH to be the future of finance and forever finance happen on the L1, there's people who want to optimize for the L2, and people who want to optimize for the L1. And people who want to optimize for for optimistic rollups versus ZK rollups. Anyway, we're like incredibly fragmented at the moment and I hope that we can converge and I think the convergence has sort of started. There's a broad agreement among researchers at least that there needs to be more than one person having a say in the block because we think even if you don't think censorship resistance is super important for finance, like even if you don't think finance is super important to have on the chain, which I think is an absurd opinion, but there are people who are very smart who have that opinion.

Um then you still want censorship resistance because you don't want a situation like the Canadian truckers not being able to use their bank account and not being like that that's not blockchain, right? So, having censorship resistance is super important for everybody on ETH and so for that reason I think there's broad agreement that within a single slot there needs to be multiple people who can commit transactions. Where the disagreement starts to happen is whether those transactions should be MEV relevant or not. Um I think there's a tendency to be very afraid that if MEV starts to happen in the validator it can it can start start to spread. It's kind of viewed as like this corrupt thing that is uh likely to spread and cause problems elsewhere.

Um and I don't view it that way necessarily. I think once you start to realize what it is and why people are doing it it doesn't like it loses that mystique and that corrupting vibe about it once you start to look at the details, but uh there is that view and the reason that they don't want MEV transactions to come in through these inclusion lists is because they're worried that the inclusion lists might be become corrupted by the MEV. And so the the main contention which Vitalik wrote about in his um his most recent post about the roadmap is basically do we want the multiple people contributing to be contributing MEV relevant transactions

or not and that's I think where the the breakdown is happening at least among researchers. I don't know about the core devs. I think core devs might just not want to do anything ever again, but we'll see. What do you think, Tolley? Um I think Solana devs are more likely to be open to doing the wrong thing and learning and iterating. That's just I think just bigger part of the culture. I think. Just they expect to be wrong in their first implementation of anything.

And it's almost like part of part of the process is to ship literate. The design is slightly different in the the way that we hope to achieve this is um if we're lucky and this works. Like Max's design actually makes makes a ton of sense. If you think from a very high level, if you get consensus between key chains, it's very easy to keep track of where you're at by just waiting for the last chance to move forward. Um for the furthest behind being your your your checkpoint. Um because of how Solana's designed and we were really kind of performance maximalist. Um the way that we tried to achieve it is

by understanding that like whenever you're forking consensus has to resolve it and that's the slowest part of the of the systems. You want to avoid forks as much as possible. So, we added a lot of kind of like smarts into block propagation um to make sure that forks are unlikely. And there's straight-off there and you can talk about like resiliency and stuff but the way that the internet works is you basically have sup- far- the internet is super connected between the tier one ISPs. And not only is there always an um minimal spanning tree between all of them, it is a very dense minimal spanning tree. And

partitioning that spanning tree is like you got to have NATO involved. It's like an act of war effectively to cut a bunch of cables. So, you can rely on that for liveness uh fairly okay, right? And have very high resiliency. So, the way Turbine works is it spreads the it spreads the block out in a bunch of pieces with erasure codes and a vector commitment to that whole thing. And when you receive the block, you receive a threshold of retransmitted shreds from randomly selected nodes in the network.

And what that does is it creates a view from a near node of a sample of all the partitions in the network. You have 64 nodes that are supposed to give you all the shreds. You wait for 32 of them to arrive. It means you picked 32 random parts of the network and saw that they're all consistently seeing the exact same block with no duplicates. And therefore, you are have a very high confidence that you're voting on the exact same view as everyone else. And it's not part of consensus, but it eliminates a whole bunch of forks because if you have blocks that have failed or blocks that are didn't fully propagate, you don't get to that threshold and you don't vote on them.

And if you're wrong, you're in the minority that can repair that data and then continue and catch up to the rest of the of of the network, but the vast majority of the network gets the exact same view and things move forward um very reliably. So, we have multiple concurrent block producers. They can basically follow the exact same logic. They spray the network with a whole bunch of shreds and then each one of them that's receiving those shreds waits for the same threshold across all blocks in a in a very very similar kind of high-level idea waiting for consensus between K forks between K K things.

You're waiting for this threshold of of retransmitters around the world to send you pieces of the block. And if you if you receive the threshold from each of the proposers, you have very high confidence that everyone else also received the same thing and you can all vote on that ordering of that that mixed merged ordering of of those transactions. And if we're lucky, then we can increase reliability by just increasing that vector commitment by adding more eraser codes and maybe tweaking the threshold from 50% to 2/3 or whatever.

Um, and why I say we're lucky is because the cost of increasing that commitment and the threshold is just bandwidth and cores and more signature checks. And like that's easy. That's that's free. Right? Like if it if it's a little bit more expensive now, it's going to be half the price in two years and effectively like hardware will catch up to where it's insignificant. Um, and that's kind of like the the V0 approach that's kind of exploiting some of Solana's designs. If it works, it works really well because as soon as you receive that block, you have this optimistic view of the rest of the world. You as a finance application like trader, you can construct the ordering yourself

optimistically and you can take action on trades and have very high reliability that everyone's going to vote on that view and it'll come to consensus and stuff like that. Um, so it kind of has all all those properties that we really want to like deliver to to customers in in terms of like um, reliability of the information that they're seeing as as being final even before you actually see all the votes. So, Anatoly, my understanding of the way that the early design that you've put forward in Solana differs from braid is that in your view, you've kind of you're geographically partitioning the world where a set of local proposers has exclusive rights to the transactions that are submitted within their economic zone, so to speak. So, I know you're a

phone salesman now. What this looks like a little bit from the perspective of the users is area codes for phone numbers. And basically what would happen is these local producers would have exclusive rights to receive these transactions. They'd build a block or part of a block and then that's get what gets uh through turbine. Is that Is that accurate? Um you could do it like that. Like I think the dumb way is that um you simply the number of proposers is like that you have that are allocated is large enough to where they're randomly anyways picked in the regions that people care about. Like you can force it. You can go through some kind of like the the problem with actually like

embedding the smarts of geographic distribution of the network is somebody needs an oracle for that. And that means that everyone in the world decides this is the distribution. They all submit their information, their own checks. Okay, we're this is the median value where we think all the proposers are and then you do that. It's just a pain in the ass to do that. You can do that. But implementing that, even if it's straightforward, is just sucks. It's like a year-long project. So the dumb way to do it is you just have a big enough random set to where very very large percentage of the blocks have a random distribution that's good enough. And that that's like a good enough V0 and then maybe you tweak it to where it's geographically aware in V2.

Um but my my view is that like just a V V0 where you have at least two proposers would be such a dramatic difference because on average the user latency is cut by 50% or on average the user selection of a proposer that isn't maliciously sandwiching is now 2x higher. And that is such a huge difference that it'll completely change the equilibrium of how MEV works and and all that stuff. So the the dumb approach just in your leader in your set of validators of forum of proposers just always pick two at random is good enough. Um and even um like so right now a single Solana

leader schedule for four blocks in a row and this is to amortize the switching cost between them. What you can do is you can stagger them where proposer A switches at a different point than proposer B, and that eliminates a whole bunch of other overhead of even the cost of that switch now between the four points like is amortized away. Um so there's just everything gets better with just even two two concurrent proposers and you can kind of like punt on solving the next set of problems uh in the future which is like the the geographic co-location and things like that.

And part of the geographic location like that geographic stuff is solved endogenously by the incentives created by multi-proposer because if you have enough proposers, then people just want to be in places where the information that they have is unique to them. And so they just kind of tend like, "Hey, the information from my city might be more important than the information from Tokyo." Okay, right? But if all the other nodes are at the New York Stock Exchange and maybe there's a few in Frankfurt, then you know, you could be the one node that has Tokyo data and whenever the Central Bank of Japan announces something, you're going to be the one that gets that huge arb. And so

that forces through just the incentives the geographic decentralization that you want and then uh if you have enough proposers, then you should get roughly the distribution geographically that you want. Another point that you raised is like this point of the switching cost of switching from validator to validator and it's like I also think that cost is the limiting factor that means we can't go below 200 ms block time or 200 ms block time times three because that's like basically the round trip New York City to Tokyo today on the internet. And you can't go below that if you want to switch because when you

switch to a new proposer, he has to catch up to the old proposer's latest block. And you actually see this in the Solana data, not as much in the Ethereum data because we we rotate every block, but in the Solana data, the rotation step, so the fourth block, is more likely to be reorg, much more likely to be reorg than the other blocks, which of course, I mean, I know what block I propose myself. So, I can just build off that head right away, but if I'm the next proposer, I have to wait until I'm sure what block you propose, whether you proposed the fourth block or not, wait till it gets to me. And so, eliminating that overhead is important. But we need that overhead for in the single proposer case because otherwise, the proposer

monopoly just builds up and builds up and builds up. We can't just have a centralized sequencer because then that sequencer will have a huge monopoly rent that it can charge, which is exactly what is happening. New York Stock Exchange is charging for data, but they also charge for co-location, etc. In like L2 world, there are sequencers charging for priority access to one person through time boost. There are others charging in priority auctions. Anyway, so we need to do this rotation, but what if we didn't need to do the rotation as often because we had another way of economically addressing this monopoly, which is through multi-proposer. And then we could even get to like 20 millisecond block times

because there's no need to wait for 200 milliseconds. You can just keep building off your own blocks. And eventually, everybody will have a consistent view and we can finalize on that. So, I have a question for the two of you in terms of how the geographic decentralization element might work here. It seems pretty likely to me that interesting information that we want these blockchains to ingest does not occur in a perfectly distributed fashion throughout the world, right? It's probably a pretty likely outcome that a lot of interesting information as it pertains to markets actually happens in a very select number of places. So, maybe that's New York, Frankfurt, Tokyo, something like that. And so, I could actually see a world where you're incentivizing validators to group in

these very small number of important zones, and it could actually work against geographic decentralization. And there's also a little bit of an engineering load balancing question as well if you have all of these different nodes balanced in in a small number of places. So, you know, what what's your response to that? I think Max, the way Max described that um the stake is going to basically the the interesting thing that's going to happen is that when you have uh global markets are going to get more and more connected. The economy is going to grow, and it's just going to get more important to find those points in the world that are under staked, so you

can get the arbitrage is there. So, I think in a in a very very natural way the the stake should shift and kind of follow the economic centers around the world um to where it's almost priced exactly at the value of the of the latency of that particular market's importance to the rest of the world. So, you should see higher concentration around New York and Tokyo because those markets are important, but the there should be some concentration basically everywhere, Singapore, Hong Kong, and whatever. And that the fact that it's tied to economics and the fact that your distribution follows the economic centers in the world is almost as like what you could dream for

decentralization, right? Because uh decentralization isn't just like laying out a grid around the world and sticking a node everywhere. It's there's an economic incentive to keep that node up and running and live and secure and all those things that actually kind of make the entire network network effects of that make the entire network, you know, exponentially more secure than any centralized one. So, having it tied to like actual economic activity around the world, I think um is probably the best outcome you could dream of. Um even if it means that there's higher weight in New York and Tokyo, but that's just representative of the economic importance of those zones.

I don't know if you agree or disagree there, but that that's kind of how I feel about it, too. Yeah, I would agree. I think like exactly as you said, putting a grid around the world and having nodes there is not You want nodes where people live, where economic activity is happening. I also would say if you look at the Ethereum node map today, it is a lot in the US East Coast, a lot in Central Europe and in Western Europe, and a lot in Japan and the rest of East Asia. And that's basically where all the nodes are. And there's a few There's one node in like Johannesburg. I looked in the data. I posted a chart of this on my Twitter

because I was looking at some of the solo staker bandwidth constraint questions. But if you It's just like there aren't that many nodes in places where people can't run a solo staker because of the the cost-prohibitive side of things. And that's fine. I I don't think it would make decentralization worse. I think it would make it better. Um maybe we can talk a little bit about the Solana nodes. I think there's like a lot of Solana nodes near Amsterdam. Is that correct? And like probably this would incentivize those nodes to spread out. I think the Solana nodes are a little bit more like uh centralized right now geographically than the Ethereum nodes just because the protocol has lower latency and currently

is a single leader and that's a kind of exactly what we would expect given our model that that's in the paper that I was talking about earlier. But if you had this, I would assume you would see a bunch of Solana nodes moving their hosting to Tokyo from the kind of central cluster of nodes in in Europe. And I think that's like directionally good. And then from Ethereum, I think there would be not very much change either. So, I want to get a sense of the trade-offs that you view each of your designs are making. And we haven't talked about some of the the downsides of multiple concurrent proposers or what you'd be trading off versus the status quo but my understanding at least in the braid

design Max that you've outlined is there's a little bit of a loss of welfare. And what I mean by that is a little bit less efficiency, a little bit less throughput, things like that. And we haven't talked too much about how multiple concurrent proposers would disrupt the current Ethereum roadmap and some of the features that we've been talking about for a while like EPBS, right? And you know, builder centralization and you know, what that role would look like in in a multiple concurrent proposer world. And you know, I get that there are a lot of really good reasons why we don't want builders to be as central as they are in the current state, but they are really efficient and they do pack together very profitable blocks, right? So, we're removing that, you know, you are kind of losing out a little bit at least from

one perspective. And then the other thing is there's a little bit of additional overhead um just in terms of this entire system. And so, maybe you're trading off a little bit of efficiency there in the braid implementation. Whereas my understanding in Anatoly in your design is because you as a you as an actor only get to submit to one proposer, they have exclusive rights to uh a local set of transactions, you don't get some of the censorship resistance properties because as Max outlined at the top of the episode, what we do is, you know, it's good it's a good idea to break up the proposal monopoly, but in the Solana system you still only have one proposer that you can actually submit transactions to.

Yeah the the reason why we'd want to have a a fee pair logically tied to a single proposer is that that proposer can then deterministically decide that that fee pair is valid and and decide that that priority fee or MEV tip or whatever is actually going to get paid on and during the final execution. Um so it's harder to like do denial-of-service on the network, but the sender can logically generate infinite number of fee pairs and spam the network with the same logical transaction anyways, but they can't do that with a uh with only paying once. Um I'm sure there's like a solution that's very similar in the Ethereum land that that's basically the same thing, but you

kind of like the the larger question that kind of goes back to how do you split resources is is the hard part. Is that um if you split them by N, you're limiting the capacity at any given proposer uh of the entire block and that's that limit might get hit first. And the really crappy part here is that uh if you have uh like the the localized fee markets like you do in Solana that are based on state locks, like writable locks, the the amount of single-threaded lock time you can have also has to be divided by the

number of proposers. And this is the part that really really sucks is that once you start shrinking all those pipes, the probability of any one of them getting saturated in any given proposer goes up. And once one is saturated, fees goes up and when the global one gets saturated, the fees go go up for the for everyone in that batch. And this is what we really really want to avoid. And this The idea that I had is kind of very similar to what Max had. It's that we're on track to kind of implement asynchronous execution, which is that you let nodes vote on forks without waiting for execution of the final state occur.

And you can basically after you do the merge, you can deterministically compute how much resources that block used, how much compute they requested, and stuff like that. Um if it's under the global limit, you can effectively increase the local limits on all the proposers in the future. Um because on average, you All you care about is the average execution load is is about what the network can handle. And if it spikes up in any given moment, it's fine. Like you So you can amortize the effectively the underutilization of all these things, but I don't know if that's enough to deal with the kind of

the limits being shorter on both local thread time and global thread time. That's kind of like my biggest concern is that the more proposers you add, the you're dividing the that block by N every time you increase the proposer set, and the probability of of um that local fee market like getting saturated goes up. And the user experience is worse. And maybe to human users, it doesn't matter, but like the traders and everyone else, that becomes a big problem.

Yeah, I would say like the braid design I think has some similar ideas that the user can specify in their transaction that this is a transaction which is only going to proposer one at in this block. Um and that way they have that tighter relationship between the fee that they say they're going to pay and what they're going to pay. There's still some free data availability problems here, and so you need some escrowed fees to make sure that they they will actually pay that. I think that's important. The problem of I think in Ethereum we have gas, which is like the single dimensional unit, which is very nice for saying we're only going to execute 30 million gas, so whatever you put in, make sure it has a

high enough priority fee that it will be executed in that 30 million gas. So that's like one way to deal with it. And then I think the the multi-dimensional case, the local fee markets, is a more complicated case. I don't think it's in any way impossible. I think you could go by, say, like maximum tree depth on the scheduler that uh Shout out to Andrew who made the changes on the scheduler recently, right? But the basically maximum tree depth of sequential compute, which is what I said earlier, could be what you you pipe everything into the scheduler from all the blocks and then you just run it until you hit the maximum compute unit depth on the same

right lock and at that point you cut off everything. That's like one way to to do this as well. So I don't think it's like impossible with the multi-dimensional stuff. It just needs to be a little bit more uh thought through in the in the specifics of the multi-dimensional case. So I I want to go back to you and and get a sense here of the trade-offs that each of you see in each other's designs and get you to comment a little bit and tell your perspective on Brad and Max your perspective on Anatoly's design and you know, again, Anatoly, it seems like in the in the Solana implementation of this, we don't get some of the censorship resistance benefits that Max talked about at the top of this episode where you break up the proposer monopoly because again, from the perspective of a

fee payer, you only have one proposer that you can submit transactions to. A user A user can generate multiple fee pairs, right? That's just another derivation of the of the same key. So, that part I think is is like pretty trivial. Um Yeah, I think it's basically up to the user. If the user wants censorship resistance, then they would generate a transaction that says, "I'd like to be included by everybody." Sends it to everybody and pay a higher fee for that because they're using more uh data availability, so they have to pay for that. And if they're like, "Hey, I'm sending I'm just sending money to totally like nobody cares about that right lock other than I don't know, maybe somebody else is sending, but say

I'm just sending to somebody who nobody cares about the right lock, nobody is going to try and censor that transaction, then I just send it to one party and I pay the fee for one party. And I think that's pretty similar in both designs. I wouldn't say that there's like a although maybe in the maybe we've converged to a similar thoughts on that, but I think we Like the vast majority of users would be like what? have one fee pair that they always go to the same validator because the the 99% of users don't really care about any of this stuff. It's when you're talking about like trading and finance and you really, really care about MEV and all these other things is when you start pricing that opportunity cost to pick validator A over B and the

latency between them. And those systems are automated and they can manage multiple keys really easily. Um So, from from that perspective, any single entity you can have arbitrary number of keys or pick to submit their transaction logically to as many entities as they want and have logic in that transaction to only execute once and stuff like that. All all that stuff is kind of like more application user space. Um it's just at the network level when the block producer sees a whole bunch of transactions to pick, they have to pick the highest paying ones. And what you don't want is a denial of service where an attacker has barely enough fees in their fee pair to pay for one, but they submit to N.

And then everyone picks that transaction as the highest one, but only one of them pays, right? So, they effectively wasted a whole bunch of high priority bandwidth for everyone. So, you want to force them to commit some amount of effectively escrowed value to to make sure that they can't do that attack. And there's the solution that I had is one idea. It's good enough on first glance, but you could There's a whole bunch of ways to kind of solve that. Yeah, and the user like the average user probably not going to care too much about this, but they will see the benefits of it in the fact that their spreads will be lower and they will have faster execution.

So, I think for them for most users it will send to one party and then the stuff that happens on the MEV side on the trading side will not be visible to the users, but will be very important for them cuz it will lower their spreads and lower the frictions for trading for them. So, question to both you guys here. How likely is multiple concurrent proposers to actually get implemented? Like, is this really going to happen? And then what do timelines look like? I think the benefit that we have is basically everyone is aligned on that this is a good idea and that it overall increases bandwidth and censorship resistance in the network.

The downside is There's a whole bunch of other problems that are higher priority. Um I think once Firedancer lands in terms of like it has significant stake, like, you know, people are going to start looking at like the next big pieces and the prerequisite to to making it easier to implement multiple concurrent leaders is um async execution. Um I think that would probably be an excellent on MCL. It's not as big of a fire I think on Solana as it is on Ethereum because of the faster block times.

If you have at least one honest participant within that time, you can kind of get some of the similar benefits, but um eventually, I think kind of everyone agrees with the vision. This is the way that you beat Nasdaq or NYSE or whatever, and um like the Solana ecosystem wants to win, so that that's uh My guess is probably is definitely in '25. If we can get a sync like firedancer and a sync execution out by by the end of '25, then this would be the next thing in like probably '26.

Realistic and and timelines, but take those with a grain of salt. So, Maxim, question to you here, and I would actually be curious, just, you know, I know you've been doing this push recently to make Ethereum great again. How's that going? Do you feel like you're you're winning that? Are you you know, are people relatively receptive, or how has that entire push gone from your perspective? Yeah, it's I think there's been a lot of positive movement. There was a proposal, not by me, but by some other folks to reduce the block time. There was another proposal to uh increase the gas limit, also not by me.

Uh so, that shows that there's and and these things were discussed actively on core devs. Uh I think the problem is that there's this L2 roadmap construction going on. And there's a bunch of things scheduled for that that also use a bunch of dev resources and even like resources just like bandwidth and things. And so, um it's, you know, this is also like, "Hey, I've been saying like, hey, is this L2 roadmap really make sense?" Because we need to decide which one of these things we're going to prioritize. Uh we don't have the same culture of move fast, break things, uh try something that if it doesn't work, it's not the end of the world because that's not the way that Ethereum

development works, uh which is, you know, a benefit in the fact that we have a lot of stability and we don't have outages, but it's a a drawback in that we can't move as fast. And I think we also just have um an issue that it just, you know, there's a lot of things in the queue and we're not popping fast enough from the queue and we're having issues where hard forks are getting split. I think I I was talking to somebody here who I respect a lot who said, I I won't reveal who it was, but he said basically, the fact that we split the hard fork made it so that all of the energy and the the kind of deadline of the hard fork got delayed and so we split the hard fork into two and then

all of the things that were supposed to go in part one that are now in part two are going to ship much slower and the rational for splitting the into two hard forks was that it would actually allow us to ship faster. I'm not sure if that's the case, but one hard fork a year or one hard fork every five quarters is going to be we're going to be a long time before we get there. And what I've been saying is you know, Ethereum developed at this time when there weren't very many credible competitors. And it was basically like Bitcoin was clearly not going to do anything.

Everyone else just kind of floundered and for a long time or Ethereum was like the only place where serious web three activity was happening. And now we're in a situation where we have like an actual credible competitor that is trying to win. And so the the like open source infinite garden we'll ship it when we ship it approach isn't going to work because by the time we get to these things on Ethereum, if we don't make a change to the meta governance process, by the time we get to anything useful like multi-proposer or even that even if the L2 roadmap is right, which I don't think it is, but if it was right, the time we would take to get to the end of the L2 roadmap,

Celestia or EigenDA is already going to have beat us because we're not going to we're not shipping fast enough on anything. And so, we need to kind of go into war mode, I think, and part of that starts from the top of like Purge the sleeper agents. Purge the sleeper agents. Purge like the people who are not shipping fast enough. Uh maybe drop a few clients with like 0.1 0.01% share. Um and just go as fast as possible towards one of the direction. I don't I don't care if it's this direction. I just I want us to actually ship as fast as possible in one direction cuz I mean even recently Vitalik himself went on All Core Devs and asked for

a 33% increase in the number of blobs. And the reaction was from all these solo stakers was like, "Hey, like we're going to we're going to miss our blocks. We're not going to be able to do anything." We're right now we're at three uh blob limit. We just hit saturation on that today because of the Scroll airdrop. And the goal of the L2 roadmap is to get to 64. And going to four was like a big issue that we're we've been debating for weeks and weeks and finally they're going to make a decision on Thursday about So, I just think we just need to like get that like zealotry uh out and get the like shipping culture

in and just start to actually do at least like let's make a bet and actually go all in on the bet instead of trying to to play all sides and be the second best at everything. We can't be the second best DA layer, the second best settlement layer, the second best, you know, DeFi layer. I want us to be at least the at one thing. All right, I've got a follow-up question for you here, Max, and then one for you, Toly. So, Max, you've expressed that you're not a huge fan of the roll-up centric mode roadmap, and you view L2s as being parasitic to Ethereum. So, my question to you here is, what is the bigger competitive threat to Ethereum, L2s or Solana?

Oof. I think that the question worried about the Solana team and the like overall vision. I kind of feel like the ETH roll-ups, I don't see them saying, "Hey, we like want to be New York Stock Exchange. We we have a plan to get to multi-proposer, which I think is one of the necessary components to get there. So, I'm in the long run, I'm more worried about Solana. In the short term, I'm worried about the ETH L2s because the ETH L2s are like taking more users directly from the L1.

And like, you don't bridge on Wormhole. I know you said this on Twitter, Toly, but you don't bridge on Wormhole from Solana to Arbitrum. You bridge on the from Ethereum L1 to Arbitrum, and you take your DeFi activity there. And we have all of our big It's not like Jupiter decided to launch an L2 on ETH to take ETH users for their exchange. It was Uniswap that decided to do that. And so, our apps are defecting, our users are defecting. I In the short term, I think the L2s are a bigger issue. In the long run, I'm not sure the L2s have a long enough roadmap for that to be a real threat, although I think some of them are are very sharp people that

maybe they haven't revealed all their cards on the table in the same way that Solana has. All right, so, Toly, my question to you is, and I don't really know what your thoughts are on the roll-up centric roadmap and L2s in general, but why would this outcome that's playing out on Ethereum be any different on Solana? And even if it's not L2s, which are siphoning activity off, what you do actually have is apps which might end up with the same result because you're still siphoning user activity and transactions, etc., away from the main chain. So, why would it be any different on Solana than it is on Ethereum currently?

Yeah, the the difference is that um the goal of mainnet is to provide no engineering reason to do that. It's to like increase block space, execution capacity to the point that the users are not going to get a better experience on an alternative network or an alternative layer. Um and they can get marginally better. Like you can you kind of like you know, a single a single server could get better latency in some cases and things like that, but it shouldn't be the like the killer part that drives PMF. I think mainnet can be competitive there.

And basically everyone is aligned there. Like the work that the Fire Dancer folks have done to prove out that the same protocol can like be juiced up with a whole bunch of hardware to like dump a whole million TPS or whatever. It means that we just have like a we just need to execute and deliver the those features on mainnet. It's not a There's no computer science problems left. It's it's just purely engineering. So, in that sense, that means that like the the advantage that Solana had against Ethereum is that there was a order of magnitude improvement in latency and fees. Now, all the L2s and all the applications that want to fork are competing with Solana, which is

fairly big, but also with each other. And there's that fee and latency is just marginal improvement at this point for the users. Um so, if the network can keep up and maintain it's like, you know, keep increasing block space or whatever, there shouldn't be like that shouldn't be a driver. So, that leaves everyone else that's like, I want to launch an L1 or L2 because the token has higher value or whatever. That's fine. People chase that dream. The prices will collapse. 1 in 20 will survive, right? And then like that's that's part of life.

One thing about the reason that we have so many L2s, part of it is because we've said, "Hey, we're not going to try and scale, so you can take our users and do what you want with them." Um that's that's one reason. Another reason that we started down this road map, I think is we didn't pay core devs to work on the protocol. Like there was people that wanted to work on the protocol who you know, like if you went to Ed Felten and said, "Hey, Ed, like we really think you're a really smart guy. We want you to work on the protocol.

Here's a million dollars a year." While he was a professor at Princeton, I'm not sure he goes out and starts Offchain Labs and launches Arbitrum token. I don't know. I would If it's it's I don't want to speak for him, but I'm saying there would be a lot fewer people launching tokens if there was a incentive to work on the core protocol. And I think that's something that just ETH has just gone so wrong and the EF has just failed completely at doing, which is compensating people appropriately.

And there's a whole drama about the conflict of interest going on right now, which I won't get into too much, but it's it's potentially making the problem even worse. And I think we've made some attempts to do it with Protocol Guild, but has has not been enough of a movement in that direction, and I think it's something we really need to get right. Uh we're going to do our best at SMG for people that are working on the protocol to make sure that they're compensated appropriately for their level of talent and what their outside options are. And I think there's other people that are doing that, too. Paradigm is one of them with the people who are working on Reth, but we need to do that like like I think the Ethereum Foundation should probably commit to Reth is zero now.

I mean, there's all these people that have got that are billionaires from ETH. And like then there's these people who are like working on the protocol for $200,000. And and and shipping it and making sure it works. And I think that doesn't necessarily work in the long run. All right. So, my final question to the two of you is, do you see Ethereum and Solana converging on design? So, here we are. We're talking about multiple concurrent proposers, and I know that there's no guarantee that this ends up happening. Let's just use the optimistic scenario that this ends up taking place. And what I'm hearing from the two of you is that both of the designs, there are minor differences, but there's an enormous amount of overlap in between how you see the future of both Ethereum and Solana. And so,

are we on this are we on this convergence course here, or is there the possibility that because the chains have such different cultures, which Ethereum's, from my understanding, is a little bit more academic, a little bit more research-oriented, and in Solana, it's a little bit more engineering-driven, a little bit more product-focused, is are those cultural differences enough to keep the chains meaningfully separate or distinct? I think if you got to pick your lane, I think um because I'm just my background and whatever, I I understand the engineering that problem of the world computer and the value that it can deliver to users.

So, that's the lane that Solana is optimizing for. It's just make this synchronized dance state machine as fast as possible. So, there's kind of like the other use cases, while maybe important, um we culturally have given them up. We don't really care if SOL is money or not. Like it just doesn't matter. Um so, I think this is something that is a like in a weird way, right? Your competitors define you. Ethereum is defined by Bitcoin as a competitor and there's a lot of like they just haven't given up on on that on that dream and that's going to drive a lot of the decision-making where and Solana in a way is defined by Ethereum

but only the world computer part. Like and and that's the only thing that Solana really cares about. I think a lot of designs for world computer will converge. I think the money one is is is not an engineering problem. So it's just really really hard for me to to wrap my head around it. I think the I watched Manhattan pro- projects the the Oppenheimer movie on a plane. Great movie. ride recently. Great movie. And yeah, it's a great movie. And they have like all these different they have like the theorists, they have the chemists, they have the like applied physicists and they all come together and they like go to

uh the national lab and like build these bombs. And I kind of feel like there's a similar thing that has to happen in blockchain itself. We have four pillars of blockchain, cryptography, incentives and algorithmic game theory, engineering and consensus. And there are experts in all four areas. And then you go look at like where blockchains have built like their mode around. Like you have like these engineering powerhouses like Solana.

You have the kind of places like Ethereum that have tried to build around incentives and mechanism design. Although I I would argue that they haven't necessarily done the best job of that so far but but we're working on it. Then you have places like I would say Aptos and Sui that have started from a and maybe Avalanche as well that have started from like we're consensus experts. Here's what a optimal consensus engine looks like. And my thinking is either one of the chains that exist today is going to recruit all these people and say we want to build the blockchain which has the best engineering, the best VM, has the best incentives, has the best uh consensus algorithm, and has the best cryptography. And like that blockchain will just win.

Or that will be a new blockchain that's formed and and that blockchain will win. And like whichever blockchain gets the right four people to head those things and the right people to support them and gets them all working on problems and working together, not just on their own separate problem in their own separate corner, but actually together and and talking to each other and working with each other and using each other's tools to solve each other's problems, that blockchain is going to win. And this has been like a really interesting experiment on the braid paper is we have like cryptographers, we have game theorists, and we have consensus experts all working together on the paper and we're like learning a lot from each other because we're going

back and forth and trying to solve each other's problems with each other's tools. And I think that's going to be the next unlock, and whether that happens on an existing chain or on a new chain remains to be seen. But uh I hope it happens soon cuz that's how we get to decentralized Nasdaq, I think. All right, guys. Well, I really appreciate you coming on the pod. Both of you have been super generous with your time. I know that anyone listening to Bel Curve will already know who the two of you are, but if folks want to stay up-to-date with the latest on multiple concurrent proposer designs, what's the best way for them to do that?

I mean, follow me on Twitter, but I don't know if that's at your own risk. That that's how you get like hear more about the stuff, but generally uh probably the you know, the Discord and the core devs calls and stuff are pretty good place, but um that's pretty low in the weeds. I don't know. It's all on a research Telegram group, too. Yeah. Uh yeah. So, you can find me on Twitter at maxresnick1. The place where you can find all of our papers uh that are out now and that will be out in the future is on mechanism.org.

And I think that's where you'll find the meat of the questions, but also if you DM me on Twitter, I'll probably respond or on Telegram. Cuz uh I spend way too much time thinking about these things. And I'm giving a talk on braid at Devcon, as well. All right, incredible. Well, thank you so much for your time, guys. Uh this was great. We will have to do this again in maybe end of 2025, hopefully around the time they were actually implementing multiple concurrent proposers. So, thanks very much, and uh we'll see you then. Okay. See you, guys.