与 Max Resnick 一起构建全球金融基础设施｜EP 162

We’re going to build a global decentralized blockchain. We’re going to try and be a decentralized Nasdaq. So how do we fit those all together? Now we’re at a point where we can make that happen. We’ve learned a lot, and we know what that looks like.

We have these new technologies of proprietary AMMs, which we think are maybe better than the order books and fit better into an on-chain environment. The pieces are falling into place on the regulatory side, too, where it looks within reach now if we do the right thing.

The idea for me of MCP is not what exact design is best for the application, but how I can give the applications a toolbox to build whatever they want and whatever they think is best. I think if you ask 99 market makers out of 100, probably 99 of them will say they don’t want this design, kind of going back to the faster horse, because all they know is co-location.

Cool. How are you doing, Max?

Good. Thanks for having me here in New York.

Yeah. Beautiful day at this Atlanta skyline here. It is warm. It’s colder than Miami, but we make do.

Yeah, it’s good. We’re in March. It’s a good day in March for New York. Not too bad. Could be colder.

Cool. Well, we have lots to talk about. This is maybe a disclaimer: I’m a big bullish fan of MCP and all the work that you guys have been doing. I’ve been a big MCP maxi because I believe it’s almost existential. We had these low-throughput chains, and then we had to graduate to high-throughput chains, which really enabled scale.

But now, in my mind, you almost need MCP for us to cross the chasm and compete with these more global exchanges, because it’s about inventing a new market structure. I’ve been joking with you that we don’t need faster horses in terms of co-location. I think we need a new design that can really be competitive on a global stage.

So maybe I should give the broad backdrop: I’m bullish on what you’re doing and excited about all the things that you’ve been publishing recently.

Yeah, I think that’s exactly my thinking, too. In order to compete as a decentralized blockchain with centralized exchanges, it’s not going to look like putting all the nodes in one place and making a slightly worse version of the centralized exchange.

There are chains that have tried that. I won’t name any competitors, but we all know that people have been trying that for a while. It either ends up as basically a centralized exchange, which is fine if you want to compete with a centralized exchange as a centralized exchange. But we’re not doing that.

Solana is a decentralized blockchain. We have 800 validators. We don’t want to have everybody in the same place, so it’s not really an option for us. That means we need to do something different. Hopefully, that something different can actually end up being better. That’s what I think we have a chance to do.

1. Multi-Proposer Designs: Solving the Single-Leader Bottleneck

I agree. Maybe before we get into the nitty-gritty of the actual design components, I would love, for all the people watching too, to hear about your idea maze. Obviously, Toly has been talking about this for quite some time, but you’ve also been thinking about this pretty deeply. How did you personally arrive at multiple proposers or multiple leaders through your research?

Broadly, Toly and I are very different thinkers, so it’s often interesting when we arrive at the same place. I think Toly is an incredibly intuitive person. The way I describe him is that he holds all these variables in his head, simulates them, and then something pops out. It’s totally unclear where it came from, but sometimes it’s a genius thing like Turbine, something nobody has ever thought of before.

I’m much more of a structural, first-principles thinker. I go from A to B to C to D, and then when I get there, I’m like, “Okay, I got all the way from A to B to C to D, all the way to Z.” Sometimes I’m not great at communicating all the intermediate steps, so this is a good opportunity for me to do that here.

Sometimes I’ll say, “We need Z,” and people are like, “What are you talking about? We don’t need Z.” Then I have to go back and lay it out for everyone. But I’m much more of a structural, first-principles thinker.

This was about 2023, maybe 2022, during the depths of the FTX crash. I started looking at MEV for the first time and thinking through all these problems from square one. I didn’t really know anything. I didn’t know what PBS was at the time, I didn’t know what Flashbots was, and I certainly didn’t know anything about the Solana block-builder stuff.

We started thinking about the fact that the leader in a single-leader blockchain has a lot of power. The leader can choose to reorder, which was what all of the literature on MEV up until that point focused on: the leader could reorder.

I asked, “Why does the leader need to reorder? Why don’t we just put the ordering rule in the protocol?” Once you do that, the leader can censor. It turned out that censorship was load-bearing, in some sense, as to why the leader had so much power.

The protocol designers said, “We’ll let the leader choose the order,” but there was no structural reason why you couldn’t have a single-leader blockchain where the protocol chose the order. The real issue was that then the leader would choose the order by censoring transactions.

So we wrote this paper called “Censorship Resistance in On-Chain Auctions,” which basically said, “If you have a single-leader blockchain, you can’t really do an auction that well.” A lot of things that we do in finance look like an auction. That was the start.

After that, it was, “Okay, if you have a single-leader blockchain, it doesn’t work great for auctions. Are we cooked?” Maybe not. The answer was that maybe we could just have more than one leader.

That was a very nascent idea for me. This was around the time that Toly was writing a lot about multi-leader as well. My idea was more like, “A single-leader blockchain can’t do this thing, which I think is really important. Multi-leader is a potential solution.”

It’s been a long road from there across many different designs, starting with something called Multiplicity, which is sort of the parent protocol of Fossil, which they’re discussing a lot on Ethereum. Then we talked about Braid and a protocol that we didn’t give a name: the Multiple Concurrent Proposer Protocol. The paper was called “MCP: Why and How.”

Then there was a protocol called Supernova. The research team also proposed a protocol called Spectral. Finally, we arrived here at Constellation.

At each step, we made some improvements. We lowered the bandwidth overhead and reduced the latency by a few rounds. Now we’re at a place where we think the bandwidth and latency overhead are pretty minimal, and we’re confident that we can build the Constellation design. That’s how we got here, basically: many years of grinding it out.

A lot of work. A lot of iterations. They say it’s not 10,000 hours; it’s 10,000 iterations, and you guys have definitely put the work in there.

I got super interested in it after talking with Anatoly, primarily from the trading side. His classic, famous example was the boat with a bunch of iPhones that goes down to Singapore. The trader can make a trade based on being first to that information, versus having it propagate through a fiber line to the New Jersey data center and then trading on that information.

Ever since then, it seemed like the first-principles solution in my mind to actually enable global trading. I think this design is strange, broadly. If you ask 99 market makers out of 100, probably 99 of them will say they don’t want this design, going back to the faster horse, because all they know is co-location.

Some things we’ve really been trying to push a little more are co-location versus localized ingestion, especially on the trading side. I think it’s different, and I’m excited because I think this enables a new paradigm of trading that isn’t these regional exchanges around the world, like the New York Stock Exchange, CME, or the London Stock Exchange. You can truly have global trading.

To me, that was always the most interesting aspect. It’s almost like blockchain, in some sense: you have engineers who nerd out on the details, finance people who get excited about it, and NFT people who come in excited about crypto for the sake of crypto.

I feel like people on the MCP or multi-leader side have approached it from censorship resistance, the trading aspect, or just cool engineering. It’s been cool to watch the different iterations and see how people have approached it.

2. Constrained Optimization: Balancing Decentralization with Reality

My perspective is very much practical: What can we actually do? This is Solana. It already exists. We have 800 validators and a bunch of apps on top of the chain already. We have the constraint that we’re going to build a global decentralized blockchain, and we’re going to try and be a decentralized Nasdaq. So how do we fit those all together?

I think there’s obviously been a lot of controversy about this.

Internally, I think some of that is motivated by financial interest from the people who are saying these things. I think part of it is also just a difference in worldview. My thing that I'm trying to do is constrained optimization: What can we do within the bounds of what is possible? And then other people are sort of asking, what is the optimal market structure if you could wave your wand and make this thing do whatever you want? And we know that you can't do that, right?

We know that the design of blockchains is all about Byzantine behavior and rational agents. You don't get to tell everybody exactly what you want them to run. If you do, then it's a centralized exchange, basically. And so we're not operating within that framework. We don't have those tools.

A lot of the design choices that we made are sort of—if you're a trader, you're like, "Well, I want everywhere in the world to be able to get information instantly with a perfectly fair, first-come, first-served system." And I'm like, that's great.

That's great. I want something like that, too. That'd be great, but I'm not God. I don't get to tell the validators exactly what to run. We can give them some defaults, but if they can make money running something else, then they're going to do it. And really, we built the system that evolves from what the validators do in their own self-interest.

If that happens, what we really need to understand is: Is the resulting market structure good, not the perfect, idealized market structure that we come up with in our head? But then when we put pen to paper and actually try to write out a protocol that's robust against Byzantine adversaries, we can't do it.

So, yeah. I keep coming back to this idea: Hey, this thing is kind of new and weird, and people are probably going to kick and scream. That's totally fine, and I understand change is not always fun, but I do think this is the kind of first-principles, cracked solution and, ultimately, as you mentioned in the beginning, really getting away from the current monopoly.

I have now chatted with a lot more institutional people, and one question they always ask is generally around MEV and transaction reordering. I frame it as: There's arbitrage that exists in the world, and that's always going to exist, but maybe we can do more to eliminate the reordering. I think, to your point, reducing that monopolistic power is really a great first step.

3. FCFS vs. Priority Ordering: The Future of High-Throughput Finance

Yeah, and even just arbitrage, it’s not like some constant that’s derived by a universal system prompt that says this amount of arbitrage will exist, right? Arbitrage is something that we can structurally measure. We know exactly how it arises. One person is quoting at a price that somebody else thinks is a good price to take, so we know exactly the path of how that arbitrage arises, and then we can try to tweak the system to make it lower because it’s deadweight loss. Those things are available, and often I feel like, you know, we didn’t put a man on the moon with intuition. We didn’t put a man on the moon by doing exactly what we’ve been doing for years with somebody who has a lot of intuition about building wheels for wagons. We actually did a lot of math and figured out some fundamental theories of how the world works. We used that and built up on top of it until we could figure out, okay, if we burn this gas, then we can make this huge explosion. We point it in the right direction, we get the rocket. If we point it in exactly the right direction, maybe the rocket can land safely on the moon. And so that’s sort of the approach that I have to all this: these things are not ephemeral, they’re not unknown things that we can just write out a mathematical model that predicts pretty well what’s going to go on. And when we do that, we can start to see how some inefficiencies arise from these legacy systems and try to improve them.

[snorts]

Math is good. Maybe one way that we can start taking this is really around determinism. I think as blockchains have gotten more performant and people start to trade more—even with Ethereum, I mean, you know much better than I—there is a lot of MEV, especially when you have longer block times of 12 seconds.

But I guess one question that continuously came up when I was talking with different market makers or traders around these decentralized systems was really along the lines of: How do we increase determinism? I was always optimistic that this MCP proposal could increase determinism and make it easier to market-make, allowing people to build models to ultimately build their—

[laughter]

own ideas of how to trade. And so maybe we can start off with how you think about increasing determinism on, I would say, broadly, the MCP design, and then maybe we can get into some of the more nuanced details of the paper that you just published.

Yeah, and before we get into that, you mentioned Ethereum, which I think is a useful point of study of what happens when you just let these things sit—these single-leader blockchains with a lot of activity on them. Recently, a trade on Ethereum resulted in the largest, most valuable Ethereum block in proposer-builder separation ever.

A user on the Aave front end traded $50 million of Tether into AAVE, but it wasn't actually the Tether token; it was the Aave aUSDT token, the Tether-wrapped token for deposits in Aave. Something went wrong in the routing. I think it didn't realize that you could withdraw from Aave and then trade on the Tether-AAVE pool. It tried to go directly on the aUSDT pool on Aave.

Anyway, this created a really bad route and a massive backrun opportunity, and a lot of that was captured by the MEV supply chain. I was looking through it recently, and just looking at the details of it, it's so interesting what happened. The user trades on the front end, and the front end takes a fee. Then it went to the CoW Swap auction, where the CoW Swap auction takes a fee, and the winning searcher on the CoW Swap auction fills it and takes a fee.

Then they make that transaction, and it gets sent to the Blink auction, which is some other backrun auction, and that backrun auction takes a fee. It gets sent to Titan Builder, and the Titan Builder has its own internal backrun auction, which also takes a fee. Somehow, the searcher on that auction bid up and paid $30 million to Titan, and kept $10 million for themselves.

Then you go to the PBS auction. The Ultrasound Relay takes a small fee through some structural way that they take a fee, and the validator gets some money too. What are we actually doing here? This sounds even worse than traditional finance.

We're starting to see it on Solana too, where there are 6 different landing services and each of them takes a fee, and you have to send to all of them. You've got Jito, Harmonic Bundles, and it's just so complicated and so many middlemen. That's how it builds up over time when you leave it. Doing nothing is like not weeding your garden for a long time.

Anyway, sorry—you said Ethereum, and I was just thinking about this: 10 intermediaries all taking a fee on this trade.

That is crazy. I'm personally now super bearish on block builders. I think it was mostly a relic of single-leader design, where they did have God mode and, as you're describing on Ethereum, almost acted as this middleman that made a lot of money for a while. But I now think with MCP it's more going to be focused on the market-making side, and I'm excited about that because I think hopefully it should result in better execution for users versus just paying, essentially, as a gatekeeper to access blocks.

I don't have any comments on the block builders. I think these things are natural: They arise from the deficiencies of the single-leader design. They're not good for the user of the chain, but that's where the incentives are, and so that's what happens when you leave it. It doesn't make somebody evil for trying to do this thing, because that's what the incentives are. Somebody leaves some money on the table, then somebody's going to go pick it up, even if that action of picking it up causes some downstream impact to other people.

Yeah.

Even if that action of picking it up causes some downstream impact to other people.

Yeah. Even broader, I think there was a lot of confusion originally, or maybe optimism, around what blockchains were. Originally, it was like, "Oh, it's Web3. It was the next evolution of the internet. Everything's going—"

Our own.

Exactly. And I think, in large part, what we have come to appreciate—or at least for us, I'll speak for Frictionless—is just that these blockchains are ledgers. They're good at moving value around, and as they get more performant, they get better at things like trading.

But to your point, this single-leader design has given specific parties monopolistic power for a certain period of time, which has really distorted some of the markets. I've been a big proponent of trying to remove that, and it's why I think the MCP design is so elegant. Now, there are a lot of details, as you know, to make that happen, but I'm excited that the market broadly has realized that blockchains are ledgers.

As they get more performant, they get better and better for things like trading. Now we just need to figure out these minute engineering details to make them even better for trading.

Yeah, and if you study the anthropology of how PBS came into existence on Ethereum, I think they kind of knew that it was not great for trading. They just thought that Ethereum was for something else. They thought that Ethereum was an infinite garden; it was for Farcaster, it was for—I don't even know—but they thought it was for something other than trading. They actually thought the trading side was kind of a bit slimy.

4. Why Solana? High-Performance Trading & T+0 Settlement

They recognized the threat of the MEV supply chain and the direct integration with validators as a centralizing risk that could harm the Farcaster application, and not as a fundamental design flaw that could harm trading, because they didn't actually care about trading. At least that's my read on it. And we're not like that in Solana, I think. I think most people in Solana understand that Solana is for trading. It was designed to do trading.

It was originally designed to have an order book on-chain. That vision has evolved a lot as we learn more, but that was the first idea. It was like this was a decentralized Nasdaq. And now we're at a point where we can make that happen. We've learned a lot. We know what that looks like.

We have this new technology of proprietary AMMs, which we think are maybe better than the order books and fit better into an on-chain environment. The pieces are falling into place, and on the regulatory side, too, it looks within reach now if we do the right things.

Yeah, and I think the exciting thing is, we kind of started with monkey pictures and JPEGs, and then we evolved to meme coins and, I would say, broadly, crypto assets. But it was really all a stress test and liveness test just to make sure that these systems work, and then hopefully we can get equities, FX—really, all markets.

I was just looking at global trading volumes, and it's trillions across everything a day. I think it's $20 trillion if you include all derivatives and FX, but these things are growing. There's a little bit of financial nihilism around the world, and I think people are increasingly trading for a variety of reasons.

I expect trading to become more commonplace and more people to start investing. It excites me to have this global, single source of liquidity that people can tap into.

The global securities market is $500 trillion. About half of that is in the US. About half of that, again, is the US equity market cap. So when we think about market sizing, the total crypto industry as a whole—all of the assets, including Bitcoin—is $3 trillion or $4 trillion right now. You've got hundreds of trillions of dollars of stuff just in securities.

My hope for Solana, and the vision that I'm working towards, is that securities especially will be issued, traded, and then eventually settled on Solana without ever leaving the chain. I do think we actually have a path towards that right now with the way that regulation is shaking out in the US, at least, and also abroad. It actually looks like we might get there. It's certainly not a 100% chance that we can get there, but there are moves on the chessboard that can get us closer to that goal.

Yeah. It's an exciting future. I think the original thing that got me into crypto was the idea that the accredited investor law was a little bit outdated and that these crypto assets, so to speak, would allow the everyday person to buy things at a more modest valuation than they would when they IPO, and you can build wealth through that. I think maybe we've done that, but if we have more guidelines and also the tech to be able to actually scale these things, and then point revenues at tokens or do tokenized equities, whatever that does look like, I think that future is very exciting.

Yeah. And it's even just a massive efficiency improvement. If you look at what the securities chain of intermediaries looks like, you can do a similar exercise to what we did with the Ethereum block builders. You go trade on Robinhood, and then they take your order and either fill it on a lit book, but usually they'll fill it against somebody who internalizes it, like Citadel or Virtu or whatever. That's already 2 intermediaries.

Now that that's been settled, they have to clear the trade, right? So they have to go to the transfer agent who holds the shareholder registry, and that shareholder registry has to be changed. Usually, it's not held in Logan's name; it's held in street name. So some custodian, like BNY Mellon, holds your stock for you—or holds your stock for Robinhood, who holds it for you—which is called beneficial ownership.

So now we've got 4 already. Then you've got the DTCC, who finally clears this whole thing. Along the way, the SEC is charging you fees per share. It costs you 6¢ just to enter the entry in the DTCC ledger—a number that they change in their computer—and it costs you 6¢. They charge you to hold it at the DTCC. All these people are charging fees along the way.

They're making it more complicated. It doesn't settle right away. It's a legacy system built off this path dependence from back when we were trading things by paper, when we couldn't settle them right away. So it's going to have to get replaced, or at least it would be really good if it got replaced with something better.

Yeah. I mean, the cool thing that we've been saying is, you kind of went from T+5 and general settlement. I think now it's T+2 or T+1, but soon we'll be able to do T+150 milliseconds. Really, it is the speed of light. Hopefully—

Zero, right?

Yeah, but I think T+0 sounds better than T+150 milliseconds. This is good. T+0 is good. We can roll with that.

That's the one that the SEC likes. So I like to say the one that the SEC likes: T+0.

But yeah, to your point, if finance was one of the few industries that hasn't really been fully upgraded by the internet—and there are a variety of reasons why, with the Byzantine Generals Problem and everything—I don't know. I'm excited that crypto at least has found its niche and has also been able to figure out that trading is profitable. You can take 1 or 2 pips generally, and on large volumes that's a big number.

Especially with applications tapping into this global liquidity source, we've seen companies like Axiom scale to hundreds of millions of dollars in revenue fairly quickly by focusing on unique trading front ends. I'm broadly very excited to continue to see how that happens, especially if we get more liquidity and more trading volumes.

Yeah, to be honest, the popularity of meme coins is surprising to me. People like trading. I go on these front ends and I'm looking at this thing, and I'm like, wow, there are a lot of people who use this thing. That's not anything against the meme coins, but I just think that the market for real companies is already here. People are already here to trade a fake Pepe coin, you know?

Imagine if they could trade Apple or Nvidia or SpaceX—real Class A securities that you actually get to own and can actually trust with your net worth. That's another level of capacity. We only have probably a few hundred thousand meme coin traders right now, and almost every American owns some kind of stock.

5. Deep Dive: The Constellation Proposal & 50ms Economic Ticks

I'm not bullish on all assets, whether memes, equities, derivatives, whatever. But I appreciate what Solana and Anza are doing to push the ball forward and make Solana a better place for trading.

So maybe on that front, I'd love to dive into more about the paper that you guys just published. Congrats on getting that out and shipping. I know you've gone through a lot of different iterations, so how are you thinking about the current proposal with MCP?

Yeah, so we just announced this Constellation proposal, and we're pretty happy with this design. I think Brandon said, “We're ready to build this thing,” and that's why we're putting it out now, because we want people to take a look, make sure we didn't miss anything, and let us know if they have any ideas.

I think it's really time to start committing code and moving us towards this from a practical, code-checked-into-master perspective, rather than just a symbols-on-the-whiteboard perspective. So that's why we're announcing it. I can say a little bit about the design in broad strokes.

We're trying to achieve this property that we call selective censorship resistance, but we're trying to do that without compromising on safety and liveness, the core consensus principles. We need to do that without having too much network traffic to support this and without too much network delay. All those things—I think we're pretty happy with where we ended up here.

The core headline feature is that we have these 50-ms, protocol-enforced economic ticks. As much as everybody's talking about first-come, first-served, 50-ms protocol-enforced economic ticks is actually the fastest blockchain protocol in production. There's no faster blockchain protocol that's a globally distributed network. Obviously, if you put all the nodes in one place, you can make it faster than this.

But from a globally distributed network with nodes in the US, Japan, and Europe, this is the fastest protocol that anybody will have when it goes out. There’s a kind of sound barrier that we’ve been able to pass. The round-trip network delay—if you send a message from New York City to Tokyo—is about 200 milliseconds, and we’re doing 50-millisecond protocol-enforced ticks. That’s a huge barrier that we’ve passed, like breaking the sound barrier in terms of how fast we can tick through these economic ticks.

That’s awesome. One of the key things that stood out to me, just because I’ve talked with Toly on the podcast for many years, was these timestamps. I knew Proof of History was, I would say, maybe inspired by Google Spanner and some of the stuff they were doing to keep track of time, and I believe Proof of History got ripped out—it’s getting ripped out. So, I think my eye was drawn to the timestamping aspect of it.

Yeah, so we’re not trying to timestamp every trade. We’re trying to timestamp the batches. We’re not even trying to put a stamp on those; we’re trying to put a deadline on them, so that people can’t cheat and delay their submission of transactions and get them into an earlier batch than the one that they actually submitted them in.

The timestamps are really local. If they’re off by a little bit, it doesn’t cause the end of the world. It just causes you to have a little bit of an extension, or maybe a little bit less time to get there. Basically, every node that is what we call an attester acts as this timeliness committee. Their job is to say, “Okay, I received the shred in time,” or, “I didn’t receive the shred in time.”

They run a local clock that is synchronized with the other attesters, and that clock goes every 50 milliseconds. Every 50 milliseconds, they send a message to the leader that says, “These are the shreds I’ve received from these blocks.” That’s just to make sure that people don’t delay and hold all the commits for a while. It’s just continuing the network to keep pushing things through.

Yeah, I mean, it’s to make sure that people who submit transactions in earlier batches aren’t competing with people who submit transactions in later batches. Nice. Yeah. Awesome.

How did you, out of curiosity, end up at the 50-millisecond mark? I know you’ve had different ideas in the past about what block times could be. Is this the starting point, and do you want to continue to shrink them? How are you thinking about that 50 milliseconds?

Yeah, I think that’s a great question. There’s this Budish paper that people have been talking about. It’s a 2014 paper, which is apparently the only paper that people have read in Crypto Twitter land. I’ve read a few more papers than that.

Is that the one on the batch auctions?

Yeah, that was the one that sort of introduced it. As you can imagine, it’s a pretty famous paper. I’ve been one of those Twitter guys showing that paper recently. It’s a great paper.

There’s also a lot of follow-on work, which is really interesting. There’s a paper—I’m forgetting the author’s name right now—but in 2021, there was a paper that explored a modified version of that and tried to answer the question: What is the optimal batch time?

In the Budish 2014 paper, they discussed 200 milliseconds, and they just didn’t justify it at all. In their model, they did this sort of cutesy thing where, whenever information arrives, everybody gets it at exactly the same time, which, of course, we know is not accurate.

What these people in the 2021 paper did was say, “Let’s extend that model. Let’s put in some more realistic assumptions. There are people who are faster, people who are slower, and there’s jitter. Information can arrive, and it can be staggered a little bit.” They tried to relate how staggered that information is, sum it up as one parameter, and then vary that parameter to see what the optimal batch time is.

It sort of depends on the underlying asset that you’re trading. If you’re trading SOL, it’s going to be different than if you’re trading the S&P, because SOL is a lot more volatile than the S&P.

The main takeaway for me is that, as people get more sophisticated with their landing, we can bring the time down, and it makes it better. Right now, I think if we went to 20 milliseconds, first of all, it would be a little hard with the amount of clock drift that we expect to maintain that. If you have 20 milliseconds and you have plus or minus 1 millisecond of clock drift, it’s a little bit less fair than 50 milliseconds with plus or minus 1 millisecond of clock drift.

We’re going to get better at the clock-drift stuff over time. That’ll allow us to shrink it. People are going to get better at landing and targeting these things, and then we can lower it over time. So, yeah, I think the plan is that we probably want to get this down even further.

I try to monitor how much of a difference there is between the really sophisticated senders and the unsophisticated senders. I think now it’s on the order of 10, 20, maybe even 30 milliseconds of difference between sophisticated and unsophisticated senders. If you have a 20-millisecond batch, that’s a little bit too fast for that.

As that gap closes—and I think it will—if you need to get in within 50 milliseconds, you’re not going to be okay with a 25-millisecond delay. Then we can go shorter and keep iterating on that process.

Makes sense. It’s kind of like when we transitioned from low throughput to high throughput. Everybody was like, “Oh, no, the storage is going to get bigger, and you’re going to have to spend more money on the nodes and infrastructure, and the bandwidth pipes are going to need to be bigger.” It was like, “Yeah, that’s all true, but we can do it.”

On the multi-proposers, I know V1 and the early versions were really about having a certain number of proposers around the world. Those get aggregated into a master block, so to speak, and then get sorted by priority fees. In the new paper, is that the same, or has it been iterated on or adjusted?

Yeah, it’s basically that—just that core design. I think most of the paper is about how we actually do that. How do we prevent people from submitting their blocks late and still making it in? How do we prevent the leader from doing bad stuff and still censoring people? How do we make sure it’s 100% safe and live? How do we get the bandwidth overhead from 20× to 5× to 2×, where it’s at now?

All of these things are important. One more point on the last thing: Currently, our batch time, implicitly, just based on the way we do dissemination, is about 32 milliseconds. We actually send shreds every 32 milliseconds on average right now. That’s the modal distance between shreds right now, so it’s not like we’re changing too much about how the validator works.

Anyway, sorry for the detour, but I think the design that we released is about how we do this and how we close the loop on things like fee-payer denial of service—the things that only core devs care about but are super important for keeping the chain up.

Yeah, makes sense. Very interesting. I think, as with anything, you guys have been iterating on this for quite some time. Step one is to get something out and testnet or production, and then we can start iterating and cranking on it. But I’m very excited. I think this is, again, the first-principles-correct design. I do expect some kicking and screaming, but with all things new, so it goes.

At a high level, is there any kind of upper bound to the number of leaders that can be propagated in the world? When I initially started speaking about this with Toly, he was like, “Hey, leaders will just propagate toward where newsworthy information would generally be generated.” That would have a natural decentralizing effect on the network, because you could own the order flow, so to speak, for a certain geographic part of the world.

The way to answer this question from an engineering perspective is: Which parameters depend on the number of proposers in this design? The answer is not a whole lot.

Obviously, the more proposers you have, the more shreds you’re going to have going through the system, and you can’t really add more transactions without increasing the bandwidth. But that’s to be expected, and it’s not a super-high overhead from each additional proposer. It’s basically just the cost of the transactions that they’re sending into the system.

We have a very clever way to interleave the attestations such that no one attester, or even f attesters, can mess with inclusion. We can extend that to as many proposers as we want.

What does that look like in practice? What am I thinking about?

I think we’re thinking about 16 in the design of the paper, but we could feasibly go up from there if we wanted to. One nice thing would be for everybody to be a leader—for every validator to be a leader—and for them to get a percentage of the bandwidth proportional to their stake. We could do that eventually. We’ll start with 16 and see where we go from there.

Maybe we'll start with 4, then we'll go to 16, and then we'll see where we go.

6. Market Making & Dual-Flow Batch Auctions

Nice. Very cool. I'm very interested just to watch the progression of this. Obviously, as soon as you go from 1 to 2, a lot of the market design and structure changes because you naturally have competition, which I think is going to be very bullish. But as we continue to add more and more leaders, how stake moves around in the network and where people place leaders are all very interesting questions.

Yeah, I think we have 7% in Japan right now. I expect to see that go up because that's where Binance is.

Makes sense. Interesting. Specifically on the market-making side, there have been some ideas floated around with Jump on dual-flow batch auctions. I don't know how much you have or haven't thought about the dual-flow batch-auction side, but I wanted to get your thoughts on the evolution of market making and how this potentially fits in with MCP.

Yeah. This dual-flow batch-auctions idea—I think Jeff Bizar at Financer wrote that post. Jeff is an interesting character in that I got a lot of pushback initially from the Financer guys on this design. I wrote up the first paper, and Jeff really dug into it. He was like, “Oh, this is starting to make a lot of sense to me.” I'll have to ask him if he's okay with me saying this, but he was sort of the guy who internally was like, “This nice guy is not totally full of it. I read the paper, and a lot of the things he's saying here make a lot of sense,” partly because of his years-long experience trading. So, I think it's a good idea.

The idea for me of MCP is not what exact design is best for the application, but how I can give the applications a toolbox to build whatever they want and whatever they think is best. If you want to build dual-flow batch auctions in MCP, you can do that. That's awesome. If you want to build prop-MM-style competition, which is probably what's going to be there initially, that's great. If you want to do flow trading, which is another paper that talks about continuous-time trading, you should do that. We should just have them all there, see which one's the best, and see which one takes off.

On the prop-MM side, I totally subscribed to the idea of a decentralized Nasdaq. For a variety of reasons, order books on-chain did not take off. Now we almost have the blockchain-native way of order books with prop MMs. Has that been surprising to you? How have you viewed the evolution of on-chain trading with the rise of the prop MMs?

Yeah, it's certainly been surprising. If you look back, it makes sense: “Oh, yeah, this happened, and then this happened, and this happened. Obvious, right?” But I don't think you could have predicted it in 2022 or whenever. So, it's nice to see that we're still getting this organic evolution. It's a sign of an ecosystem that's alive, right? You have a bunch of people who are all checked in and dialed in. They're like, “Oh, this is cool. Let me do that.” Then, “Let me try to figure out who's the toxic trader trading against me. Maybe I don't want to trade against him.” Or maybe I can see exactly which pools the trader is trying to touch, and maybe that's the arbitrage.

All of these things are really cool. There's obviously some growing pains with prop AMMs right now, but I'm pretty confident that we know what to do about them. It's just that we have these routers that existed for dumb AMMs, and now we have smart AMMs, so the routers need to get smarter.

And by routers, you mean the aggregators?

Yeah. The Jupiter aggregator, Titan, DFlow, the OKX Router, Fluid—who else? I don't want to miss anybody. These guys are smart people, too. They know the problem, and they're working on it, so that'll be fixed. I think the sort of dark side of prop AMMs will be fixed.

I'm pretty bullish on them. They have a lot of advantages, but you can't have a completely new market structure without some growing pains, so that makes sense.

How do you think the market structure will broadly change within Solana as trading continues to rise? The thought process, at least originally with order books, was that priority fees would pay for things and then ultimately be passed back, I guess, to stakers. I don't know if there are potentially different options now with dual-flow batch auctions or prop AMMs. Has your thinking evolved on that at all?

No, this has always been one of the things that I think about a lot as an economist. It's actually a little taboo to talk about: Should the chain make money? I think the chain should make money, and I think the validators on the chain should make money. I don't mind saying that I think it's really important for the chain to make revenue. Anybody who says otherwise is either not a SOL holder or basically has no idea what they're talking about.

That's one of my strongest beliefs, and I do spend a lot of time thinking about how we make sure that Solana continues to make revenue and how revenue increases. There are a few things we can do here, but first let me describe the broad framework. You want a revenue split with the apps, but you don't want that revenue split to be so cumbersome that they leave, right? AWS charges a lot of fees, but not so much that people leave.

From a chain perspective, you want the app developers to begrudgingly accept the fees that you're charging on your product. Right now, we haven't done any work on that, to be candid. Basically, there are just some fees that were set many years ago, and they never get touched. You don't really have a lot of people thinking, “How do I optimize this here and there?” Maybe that's not the best approach, but really, you need to find that sweet spot.

I have a few ideas for that, particularly for the prop AMMs. One of the things that the prop AMMs rely on is this priority-per-CU ordering. Right now, the oracle update, which is also like the cancel, is way cheaper than the trade. It'll be something like a 42-CU oracle update, a 200-CU cancel, and a 200K-CU trade.

What that translates into is that, in the scheduler, the oracle update gets a massive boost in priority. The oracle updates don't really have to pay a very high priority fee, and we don't want them to have to pay the same as the taker, because that's really bad. That's the PBS market structure. We also don't necessarily want them to pay zero, because if it's zero, then we're not making any money. The chain isn't making any money.

How do we pin it to be 50 times cheaper and not 5,000 times cheaper? One idea is to make a minimum transaction size. You have to be at least 5,000 CU or something. You have to be at least 2,000 CU for the purpose of the scheduler. They actually have that on the EVM, where they have a minimum transaction size. It does change the economics of the base perp AMMs a little bit that they have that minimum.

Another thing would be to charge based on CU used. You have to solve the problem of the oracle updates being way too cheap and the problem of the trades getting too expensive. Right now, we only charge a base fee on the signature. Maybe the base fee should be charged more based on how many CUs get executed.

I think these are problems that are not critical to solve today because Solana is a growth business. But it's important to know that we can solve them at some point in the future. Right now, the most important thing is growing the pie. Eventually, it will be important to make sure that we have some way of securing revenue for the chain that won't make the pie shrink.

You could turn on maximum extraction, and you could make some revenue for a year, and then all the apps would leave and there would be no revenue left. That's what's happening on ETH, right? Look at ETH MEV. They've had maximum extraction on. They made a lot of money in DeFi summer.

Yeah, 2020 and 2021.

There was no more activity because it was so extractive that nobody wanted to use it. That could happen, right? We know how to go to 100%. We know how to go to 0%. We've got to figure out how to set that dial to 10%.

Yeah. To me, the interesting thing is that it's all trading volume—or at least the majority of the revenue on the MEV side, or at least pertaining to trading. Taking a bit or 2, especially—the hard part is how you decide how much to charge, but also how enforceable it is.

Given that Binance's VIP fee is 2 bps, and I think Hyperliquid is taking 4 or 5 bps—correct me if I'm wrong—generally, within trading, it's fairly well practiced that you're going to get charged at least 1 or 2 bps, and people are fairly okay with that. That number can be a fairly large quantum of revenue when you hit pretty large scale in terms of trading volume.

Yeah, this is the ideal way to charge fees on exchanges: by volume. Unfortunately, it doesn't work that well for an L1 that doesn't own the app, right? It works if you're Hyperliquid because you are the app. We're not the app; we're Solana. So, we don't get to charge fees the same way on volume. That's where we need to do our knob-tuning exercise.

It makes our job a lot harder, but I think that is the difficulty, right? The classical, best, and least distortionary way to do this is just charge bips on trading volume. For Solana, a $100,000 SOL transfer and a $1 SOL transfer look exactly the same in terms of the fees they pay right now. It’s almost impossible to get them to look different in terms of fees, because then you could put the SOL in an account.

Say you said every SOL transfer would incur a very small fee on the volume of the SOL transfer. Then you put your Solana in some account and transfer the account instead of the SOL, right? Same thing they did with the NFTs to bypass that. So we actually have a really hard time charging basis-point fees on volume as a chain. I don’t really see a great solution after thinking a long time about it.

Yeah. Well, I’m sure you guys will continue to iterate. Don’t get dissuaded by the idea that revenue is bad. Revenue is good.

Revenue is very good.

So keep doubling down on the revenue side. But it’s not revenue today that’s the objective; it’s expected future revenue on a long horizon. Discounted cash flows. Discounted future cash flows. Yeah, that’s the thing that matters. So we can sacrifice some revenue today if it means a lot more revenue tomorrow.

True. We should be willing to do that.

Cool. I mean, we’ll talk a lot about trading, MCP, and the high-level design. I’m sure we could do another 3 hours if we went super deep into it, but is there anything else specific outside of what we’ve talked about in terms of the broad design? Anything else in the paper? We should talk about attestations, the timestamps, and sorting by priority fees. I think it’s useful to discuss this priority-fees thing.

Sure. Now that we just talked about revenue, I think one of the biggest debates internally that we had was: should we try to go for a first-come, first-served design? Should we try to go for this sort of priority-order design?

Broadly, though, I think it just comes back to this point: in the past, we had a lot of ideas and experimentations of what this could be. Now, whether it’s more sobering or just being realistic, these are very good for trading assets and moving assets. That’s totally fine, but this also, in my opinion, should be a business that makes revenue. I think it should be a business that makes revenue.

I think validators ultimately—it can’t be something that’s so unpopular with the validators that they’re going to say no to it. What’s really misunderstood is that if we did go to a first-come, first-served-style design, which we don’t even know how to do—but if we did know how to do it—then it would mute revenue to zero overnight. Most of our revenue is from priority fees, not from base fees. Base fees are negligible: 0.04 cents per transaction. These things don’t add up to a whole lot right now, especially if you take out the ones that are used for votes.

So again, it comes back to this idea of constrained versus unconstrained optimization. You have these people who are like, “What is the best possible thing that I can come up with that meets my ideological standards?” And then I’m over here like, “Hey, guys, we have 800 validators. They have an existing revenue stream. We can’t just nuke that to zero overnight. We can’t nuke the revenue stream of a $50 billion asset to zero overnight just because you have an epiphany that first-come, first-served is the best ordering rule based on your extreme knowledge of trading.”

You know, this kind of stuff isn’t in a lot of people’s objective function or in their constrained optimization problem. And so they’re very confused when you say, “Oh, well, actually, no. We can’t just try to come up with the best possible imaginary market structure. We have other considerations, too.”

And again, maybe if we could charge fees on volume—if we had a magic wand we could wave so that we could charge fees on volume—we could try to go for something different. Again, we don’t get to do that. We’re living in the world as it is, not as we would like it to be. Therefore, we need to make decisions based on the facts, not on what we’d like the facts to be.

Yeah. I mean, I think I’ve not done a 180, but I’ve just very much become more of a product maxi. I’m like, all right, you build a cool product, and in the case of Solana, maybe you build this global exchange, so to speak, that has these localized injection points, and ultimately that does, hopefully, trillions in daily trading volume, and people find that useful. It does price discovery. It does global trading 24/7. We have equities, tokens, FX, whatever—all of it.

I feel like that’s a valuable product, and that should make money. But to your point, the nuances of exactly how to do that and how to make the revenue, I think, are continuing to evolve. These are discussions that are very worthwhile to have. At the end of the day, you want the boat to be pointed in a certain direction and just herd all the cats to make sure everybody’s aligned and running the boat in the same direction.

I think in a decentralized setting, where you don’t have a benevolent dictator—as much as I would like to have one—it’s a little bit hard herding cats. It’s definitely tough, but that’s part of the job description.

Yeah. Well, I think that’s it, unless there’s anything else. I really appreciate the time, Max, and congratulations on posting a paper. The debate, I know, will continue, but keep fighting the good fight. I’m excited for what you guys are doing, because I truly believe this is as important as going from low throughput to high throughput, going from single leader to multi-leader. This really is the future of trading, and I hope we look back on this conversation in a couple of years as the jumping-off point. We’re doing hundreds of billions a day, and then hopefully trillions.

Yeah, trillions. 500 trillion. Let’s do it.

Cool. Well, thank you, Max.