That was weird. Like I didn't expect NFTS to take off. I didn't expect meme coins to take off. I think the big innovation in blockchain is actually that you can create programmatic market makers through Amms and all these kind of clever curves that eliminate a lot of the layers that you have in Trad 5 that are necessary to get to run Trad 5 based trading. My feeling with MEV was that we need to maximize competition so users always have the option to go to the best source force for
their trade. Whether that means that validator is maximum sandwiching and I'm giving everybody a rebate, that could be one model that actually works. If there's truly an exploit and you continue running the chain, even if you allow like define liquidations to run, they're mixed in with exploited transactions as as Ethereum folks, I don't know if you're around for the Dow hack. The only reason they were able to deal with the hard fork is
because it was locked. All that, all those funds were locked up in the smart contract that connects it. If they started getting mixed with a whole bunch of things like it's just impossible to unravel. You can't roll back the real world. There's action that's taking in the real world based on the chain state Circle is sending funds out based on like mint and
burns, right? I think once you have 4 clients, you could say that the probability of a bug in three is so much smaller than the probability in bug in two that it's fine for one to be down. And then you can do this kind of maintain some lightness while while one is down and and rotate. Welcome to Epicenter, the show which talks about the technologies, projects and people driving decentralization and the blockchain revolution.
I'm Brian Crane and today I'm joined with my guest host, Martin Krapplemann, who is the founder of Gnosis. And we have a very special returning guest today, Anatoly, the Co founder of Solana. Of course, Solana needs needs no introduction. So we're excited today to talk, you know, get into the wheeze a little bit of where Solana is at, what's coming for Solana, some of the challenges.
So really excited for that. And now, just before we go into it with Anatoly, I want to share a few words from our sponsors this week. If you're looking to stake your crypto with confidence, look no further than Course one. More than 150,000 delegators, including institutions like Bit Gold, Pantera Capital and Ledger. Trust. Course one with the assets. They support over 50 block chains and are leaders in governance or networks like Cosmos, ensuring your stake is
responsibly managed. Thanks to the advanced MEV research, you can also enjoy the highest staking rewards. You can stake directly from your preferred wallet, set up a white label note, restake your assets on Eigenia or Symbiotic, or use the SDK for multi chain staking in your app. Learn more at Chorus .1 and start staking today. This episode is proudly brought to you by Gnosis, a collective dedicated to advancing a decentralized future.
Gnosis leads innovation with Circles, Gnosis Pay and Metri reshaping open banking and money. With Hashi and Gnosis VPN, they're building a more resilient, privacy focused Internet. If you're looking for an L1 to launch your project, Gnosis Chain offers the same development environment as Ethereum with lower transaction fees. It's supported by over 200,000 ballot errors, making Gnosis Chain a reliable and credibly neutral foundation for your
applications. Gnosis Dow drives Gnosis governance, where every voice matters. Join the Gnosis community in the Gnosis Dow forum today. Deploy on the EVM compatible Gnosis Chain or secure the network with just one GNO and affordable hardware. Start your decentralization journey today at gnosis dot IO. Cool. Well, thanks so much for coming on and totally, it's really great to have you back.
Yeah, thanks for having me. So I wanted to start off with, so the original Solana vision right from, you know, now it's like 7 years ago or so was to have blockchain at NASDAQ speed. And you know, at the time, Solana was really pretty alone in trying to do a blockchain, you know, a single chain, high throughput, maximum performance speed, the time sharding was like the hot thing when it came to how to scale blockchains and,
and you guys were kind of alone. Of course, today, you know, Solana has gotten lots of traction and also the idea of single throughput chain has is something that's gotten a lot more traction with a lot of other companies pursuing something similar. But just just sort of zooming out, like when you think back to your vision at the beginning and where it's at right now, how do you feel about it? What do you think is are some things that you know happened
like you planned? What are some things that maybe haven't worked out? Yeah. I mean a lot of stuff kind of came true that I thought would, but just in different order. Like the, the order was unpredictable and the applications are also were unpredictable. You know, we, we thought that trading was going to be a really important use case, but we didn't think it was going to be the most important use case.
I think to me that's pretty obvious that like execution of and launching assets and execution of the trades between them is what's driving most of the volumes and revenues for across all the applications and block and, and layer ones and layer twos. This is where all the fees come from. And if you don't have revenues, you can't, no matter how many tokens you launch, you can't afford to pay all the all six engineers. Somebody somewhere has to figure out how to, how to make
revenues. And I, I think that came true. But what surprised me was that how slow Trat 5 was adopting this stuff. I expected like stocks and all of these things to be the main usage. But right now it's basically like gaming. Like it's an NFTS and meme coins are like, if you look at Twitch streamers that are streaming trading it, it's exactly the same content as when they're streaming mobile gaming or any kind of game. It is effectively gaming. It's just kind of PvP loot boxes.
This is what I kind of how I think of it. That was weird. Like I didn't expect NF TS to take off. I didn't expect meme coins to take off, but they're using the same technology. It's the same kind of escrow auction processes on chain. I thought like central limit order books would be the killer
way to run markets on chain. But I think the big innovation in blockchain is actually that you can create programmatic market makers through Amms and all these kind of clever curves that eliminate a lot of the layers that you have in Stradfight that are necessary to get to run like tradfight based trading. And that's pretty interesting.
And even if the Amms are less efficient, the cost that you spent on professional market makers like citadels and jumps are still large that you might actually as a early stage company, you might be better off using an AM to be honest versus like the the more professional Triadfi approach. That was unexpected. And I think that's a legitimate
innovation. I think where you see the explosion of assets and how they're traded, it's primarily through automatic based kind of market making approaches like curves and bonding curves and AM Ms. and stuff like that. I I would like to jump in on a topic you you hinted at and I think it's people have very different opinions about it. What makes blockchain valuable? Where does or you, you mentioned fees and said, yeah, somewhere there needs to be fees.
And I think at least in Ethereum land, there is kind of this, this, this debate between should either be just money and somehow that's where the value comes from or should should there be transaction fees? Seems like you have a very clear clear answer here. I'm traditional conservator. You have, you know, discounted future cash flows that would give stuff value. There's exceptions to that, but I think they're the outliers. You can't engineer for them.
This is the problem that I have with like, oh, Bitcoin is so successful, therefore we must build a better a better Bitcoin. I don't understand the engineering reasons why Bitcoin is successful. So therefore I cannot build a better Bitcoin. So would it be fair to say the number one or you could have one absolutely crucial success metric for Solana is overall fees. Yeah, I think the the network needs 7 of fees to pay for all the engineering effort and the validators and all this stuff.
If it doesn't have that, I think they will eventually die that that's kind of my belief. So where do you think fees will? What will be the scarce thing that people will pay fees for? So I mean, generally speaking there is, is it just general block space or you would say block space in general will be more or less free and it's specifically congestion block space or congested block space or?
Yeah, I think what the value that these systems provide is the F state that has an economic opportunity with cost and the pre organization to access that state. And this is where you can charge more than the, the hardware and the bandwidth and all the, the nuts and bolts. And if you're purely, purely selling hardware, you know, 1000 replicated amount of storage or whatever, you can only charge so many more multiples off the cost of the hardware, like maybe 10X.
Otherwise a competitor will just underbid you and you will lose this way because hardware just constantly keeps getting cheaper and cheaper. And your dominant costs are always going to be the people, right? Like it's just the at the end of the day, it's the you got to pay for the, all the, all the engineering stuff.
So this is where I think like probably again, why Solan is so has such a different road map than Ethereum is that I, I think that the network cannot survive without the execution layer also paying for, for the all the cost to build the data availability and all this other stuff. The execution layers where you can charge real real fees based on content and everything else has to support that. So the, I mean what you just said kind of priority access to, to yeah, economically important
content kind of mev, right. Yeah, yeah, absolutely. SO11 theory people have been discussing is that MEV was or definitely in Ethereum for a while it was very much captured by the chain and and by validators. But to some extent now it seems to be moving more towards the applications or in principle applications have the power to yeah to kind of add extra rules on top and and kind of protect their MEV. Do you see that as a as a danger
for Solana in that case? No, no. I think it's the goal for Solana is to so there's designs for application sequencing. I actually proposed 1A while back called program writable accounts. I don't know Brian, if you were involved as shooting down that's empty. But basically the idea is that I felt that it's important to for apps to be able to set the cost to, to take a right lock on their state. So that economically important state that's important to
access. If the application can say, hey, to be able to write to the state cause access really means right to modify it to take that offer. I want to set the fee and have that fee be application specific and dynamic and controlled by the business logic of the app that would eat into some of the fees that the chain captures. But what's good for the goose is
good for the gander. Basically that system would preserve atomic composition between applications and the cross atomic all the arbitrage between all the apps that are extremely profitable that you cannot remove, right. If if each application then moves off chain and runs their own L1 or L2 or whatever their own separate environment per app, then you lose that atomic composition and you effectively
lose those revenues. So what I want to see is the L1 Solana, this giant, one giant atomic state machine, its revenue to be mostly driven by this, the, the opportunities that arise from having everything in one, one's giant state machine that's synchronous, that's fast, that that's as cheap as possible. And then give the application the tools to capture whatever, whatever fees they want.
And they can tune them, set them higher, lower, distributed them to the token holders, distributed to the makers instead of takers, you know, prioritize cancels instead of other orders. So a bunch of whatever they want to do, I want to leave that to the application layer.
And this is I think where Max Resnick and I like really mind melded because at a gut level, I, I thought that we need multiple block producers at the same time to create a dynamic market that's competitive for people to accept these
transactions. And he kind of came, came for a from a more economics research angle where he saw that if you don't have multiple proposers, then applications cannot really build these value capturing systems at all because the validator will be able to effectively censor. And if you, if you're censoring all the inputs that are going into this application specific sequencing thing, then you can effectively control the fees that the app sets anyways.
So what you need is like you need both of those pieces. You need the hooks and the system for apps to be able to set their own fees. And you need the competition between block producers. And I'm 100% on board with all those changes, even though on the surface they seem to give up some of the economics of the apps. But the goal is if we have all the apps in one giant system, the economics between all the cross application arbitrages are going to be way more than enough.
So with regards to MEVI think you've always had, you know, in many ecosystems people have been like, oh, MEV is a bad thing. You need to minimize MEVI think you've always had a a more positive view on MEV or like how do you view MEV and how do you think ME VS going to develop with those changes in the future? A market maker submitting their cancel before everyone else is MEV.
They're they're getting priority access to state the head of everyone else, they're paying for it to the exchange or to the whoever right that is MEV. But that creates better markets because then the market makers can have tighter spreads. So my feeling with MEV was that we need to maximize competition so users always have the option to go to the best source for
their trade. And whether that means that the validator is maximum sandwiching and I'm giving everybody a rebate, that could be one model that actually works. That's fine as long as it's competitive and the users can make that decision. And I suspect that each individual users are likely to make that decision unless
they're pro. But like Phantom that wants to serve the best possible blockchain to their users, that's competing with Sol. Flare with Backpack will make the informed decision to go with a particular solution for how they route their transactions and stuff. But we need competition for that, for all that to work out. So my view is that like the stuff isn't all that different than a you're I'm selling block space, I'm buying block space.
For me to get the best offer, I need a healthy market of buyers and sellers that that's kind of the basics that we need. So in Ethereum proposed a builder separation, right was like chosen a few years ago and it's it's the state today. What do you think about Solana? Do you think we will also end up with proposed a builder separation and is is it something desirable? I don't know if there's anything we need to enshrine for that to work. Like it's kind of happening right now.
I don't, I don't know if there's changes to the like if you need like enshrined bundles, I don't have any objections to those. What I do care about is concurrent block producers. So multiple concurrent proposers or multiple concurrent leaders that we have like 2 validators, 1 in Singapore, one in New York that are running there that are both accepting transactions. And the user can has the option, do I send to the closest one in New York or maybe one that's further away that's offering a
better deal? And if I'm a market maker and I need my cancel to to land, what that means is that I can send to the one that isn't censoring and I can. And the network the the actual enshrined protocol needs to support an ordering mechanism where I can pay the network within this block. I'm paying a fee to go first. So does that make sense? Yeah, I think that's definitely
one of the topics. I know there's a huge focus for you and and I think currently in the Solana developer thing is this multiple concurrent proposer. So for you, the main reason why you want that is because you want competition between validators and you want basically less ability for validators to kind of, you know, gouge the users or like. It's also a beautiful thing because this is a way for a truly decentralized global blockchain to beat Stradfi, to beat NASDAQ on actual pricing.
And this is a very subtle thing that the changes here is that if like the how like you think of the network or any exchange or any of these systems as reflecting of the world state and it has, there's an error between that state and the real world. And constantly people are trying to reduce the, that error by submitting trades. They see something, a price that's offered, they have information in the real world, they're trying to close that
that error. And if like some event happens in Singapore and there's a local leader there in Singapore, the latency for me to submit that trade is much, much shorter than to send it all the way to New York. So for Solana as a blockchain TQB with NASDAQ, we need a block producer in every spot in the world that has any economic activity. So then the user can submit that transaction locally and cut that latency.
But. I, I, I, I want to understand that because, because, or at least in, in Ethereum you have for an upcoming block, you have exactly 1 proposal and, and that one might sit in New York, they might sit in, in, in, in Singapore. So in Solana it sounds different or or is is it still the same? Now that right now that's that's exactly how Solana works. But there's no reason why you can't have two proposers or N. OK.
But then let's say, OK, so now on the same, yeah, slot height, block height, you have now 2, one in New York, one in Singapore. So now let's say they would have two conflicting transactions here in one. Then how? How is this merged or how is this resolved this this conflict? There's a deterministic merge, so we need that it has to have that property. And two, if I want to go first, I should burn some soul to be ahead of somebody else.
It this merge will be on on the whole block level or an individual state? Probably. I mean, probably. You you can think of it as a block that is a chunk of data, right? One MB, 2 megabytes, and the first half is written by proposer A, the second-half is written by proposer B. The network receives the entire block and then has runs a deterministic merge to compute the results. I see. But you can have any number of
these proposers. The main constraint is basically we think we don't know until we test is how many shreds we can propagate through the network, and shreds is our term for erasure coded chunks of the block. But, but it also means that if you if you hit, if the transaction hits your local proposal at that moment, you do not, you don't know exactly what happens. You then need to wait for kind of some second round. Or is the merge round essentially to to? It's not. It's not a round once you
receive the data from the. Yeah, that's right. Then you can locally. Yeah, I see. Yeah. So the network could effectively the latency there is isn't really lost because as soon as the network receives the data, it can vote on confirming that the data has landed. So as soon as you see the confirmation, you can compute the results and you don't need to wait for everybody to compute the results and confirm that because that part is deterministic.
You obviously like, if you're a professional like system like that's like a custodian or or a bridge, you might want to run different boxes with different one fire dancer, one Anza. Make sure all of them agree on the results. Essentially. Essentially the blockchain would then become a a deck, right? Or I mean that what is directed a cyclic graph? No, it's different from a DAG.
Dags resolve their ordering based on the next, well producer that then decides the ordering of the previous transactions. This you have literally concurrent leaders. It's no different. It it is like leader one writes the first page, leader 2 writes the second page, and then you mix them together. The the shuffling here is enshrined and deterministic, and that's different from the tag. It's not dependent on the next producer.
So if if you have these two proposers and let's say there's some arbitrage opportunity and now people they've both proposals put in transactions that both try to capture the same arbitrage opportunity, then basically it will get merged and then whichever is the first one actually gets executed. Yep, so the highest burned one the the one with the highest burned for fees will execute first. OK, OK, OK. What's the? Hardest thing about making multiple concurrent proposals
happen though. What? What are the problems that you need to solve? The stability of consensus basically like it's just the implementation is like prone to outages I would say, but isn't. I don't think it's design wise any worse for the worst case because consensus mechanisms all deal with a single leader that produces two different blocks. They all have to resolve that. Even if you slash that leader right? Do you still don't want to have an outage in case that you have
a bad leader? So the worst thing that you want to do is have a, is have a performance segregation and slashing for performance segregation is fine because then you reduce them in practice. But you cannot, you still have to deal with it no matter what. So in an environment where you have two leaders, the the network will see four different views potentially of the results of the block only leader A, only
leader B, neither or both. So and the deterministic shuffle would be different for each one, right? If you only see data from leader A, then you just stick leader A's block. If you see both, then you shuffle. If you see neither, then you skip. And this is the complex part. What you want to do is you want to make sure that there is no partition in these views. So every time they vote, they
take the happy path. It doesn't matter what partition they see, as long as everybody in the network sees the same thing. If everybody sees that leader B failed, that's great. It means that they all agree on the vote and that you continue doing the on the happy path of, of the consensus rules. And Solana, like we, we built
our consensus. It's very complicated and a pain in the ass to work with, but the properties that it has that previous systems didn't have is that it was bandwidth efficient, that you have a block on every point in time, that there was no stalls waiting for rounds to to finish before the next block starts. You start. We now see systems like I think Aptos and Zui have gotten that to work with more modern consensus algorithms.
It's a whole team from Zurich optimizing and basically getting rid of all my technical debt to to have like a a better version of of consensus on Solana. And again, we can maintain a bandwidth efficiency and we can deal with all the partitions. Then talking about yeah, efficiencies, what are currently the bottlenecks or yeah, what, what's currently the bottleneck
for scaling in Salon? It is basically you've seen like I think like Eclipse and a bunch of other kind of Solana SVM base layer twos to tune up the compute units. So basically the the bottlenecks is making. Sure that you need to you need to help me here so say again. There's a whole bunch of not Solana layer twos, but layer twos that use SVM. Some may even be Solana layer twos. I don't even know what what the marketing, I, I don't know. I don't know.
I I don't even know which state route they're looking at. Is it Ethereums or Solanas? It doesn't matter. I treat them all as competitors 'cause if the fees accrued, they are not accruing on mainnet, they're not paying for mainnet development. So and they're fine. We're all, it's all, it's all good. We're all building open source software. So it's like Red Hat versus Ubuntu.
It's, it's healthy competition. But they've been able to increase their block capacity, I think by factors of 5 to 10. So it is basically the blockers are is just testing. It's just making sure that when we, when ONS are in Fire Dancer, increase the capacity that there isn't some, I call them like they're denial of service attacks.
There isn't some metering problem in the VM or in the block or whatever that an attacker can exploit and create a block that takes 10 times more to process than normal. But these are basically like the the the worst case kind of scenarios that they're pain in the ass to find. Let me just repeat because I'm not that deep into Solana.
So you're saying yes, there are. There are versions essentially of Solana, the SVM, that already run at 5X capacity of what Solana does right now, and it kind of works, but you are slightly more conservative and and. We have to be right. Those are not decentralized, right? They're basically roll up like. But even doesn't matter there earlier they can take more risk.
That's the difference. If if we if we were just starting out, I would I would tune the network to 10X performance and deal with the fires like that's the difference. So I mean the other, the other point you were making is that you would say kind of L2's are not really interesting you would say to Solana from from from an economic or fee perspective. So, so you're. Interesting to me, yes, those people that they're interesting too and that's fine. But what I want is mainland to
succeed, right? So to me what matters is activity on mainland trading and mainland. So essentially the whole idea that I kind of kind of the Ethereum idea that somehow you would provide BLOB space or kind of data availability or transaction ordering and then other use it for other space that that you don't. Ordering. If you could do ordering then
yes, but there isn't. I think the base roll up thing is still not fully defined and if the chain is doing ordering and DA the based roll up the only difference is then like a different virtual machine or something like that. I, I, I do very much agree with you. So there. So I am also in the, I'm kind of in the Etherium camp of if, if roll ups, then it, it should be based roll ups because I feel like if Etherium is trying to sell something, it cannot just be generic data availability
because that's a commodity. It needs to be specifically transaction ordering. We we already have based roll ups done like there's there's already like ZK proved Merkel trees or like classically proved Merkel trees book leaves for for spade. To me, the interesting thing about based roll ups is that they kind of still have this atomic composability. Or you can have atomic transactions that touch A1 and A2 state. And, and the advantage is I, I, I think it's fair.
It's fair to say, OK, you still have some validators that have all the state. And then it almost doesn't matter whether that's on the L2 or on the L1. But if you care about being able to have lower performance or it kind of have validators, I mean, well, here's my debt note sitting next to me that runs Ethereum and I can still do this
from home. If you care about that, then it does make sense to say OK, some state that kind of exists, but it doesn't have to be available to anyone who's who's running a validator on the other one. There's already sort of stuff like that running on Solana. So Metaplex built this thing
called compression. I don't know if you saw this terrible marketing name, I came off the bat, but it's basically a Merkel. It's a Merkel root that's on chain, and you can atomically prove the data exists in this tree and another piece of data exists in a totally separate tree, push them to the L1 state-run a computation on them through a program like a token swap, and then push them back into the trees. All of this in a single atomic
transaction. So the state that is effectively cold can be offloaded and run programmatically in these Merkel trees. And the primary thing that they're used for is like NFT, like you, you mint your 20,000 NF TS. You can instantly like mint them in one batch or one Merkel tree. And you just register the leaves with the chain so wallets and stuff can pick him up. And there's now ZK based approach to make the proof smaller and and a bit more composable.
But that part is is like the easy part. I think the based roll up is a bit more a a bigger piece of technology than that. It involves developers defining their virtual machine and the the state transition function that connects their VM to the state root on the L1. My problem with those is that there's just no need for that many re amps like I'm sorry. Frankly, frankly, I, yeah, frankly I I would also kind of for the base roll up say just do
EVM and. Kind of just what's the point to have like a dozen different EVM based roll ups? The the point might be to reduce to kind of still allow people to, I mean run relatively lightweight L1 validators and kind of say if you if you want to do the full thing, then you run the L1 and and the L twos and have the full state
available. But how's that any any different from like I have a like a program that has like a dedicated circuit, like AZK circuit, and I just proved that program like I don't need any VM general purpose CVMI have like my my minimize whatever the like Lego piece of of a smart contract. I just prove that smart contract only. And now I have a way to route data through that thing through the L1.
So you have your transaction approves the state calls the contract, right with approve calls another one and then like a a series and then it's done. So that's effectively like the old stateless like design, right? Like like what? What is the difference between that and the base roll up? Like why? Why aren't base roll ups just simply smart contracts?
I think you can view it as that. Yeah, then like those already in fact kind of exist with some traction like they're useful for I think like large like if you're trying to air drop to a very large user base and that kind that kind of thing.
People have found tractions with that, but they haven't found traction with like like what what I think is, is kind of interesting that you see that works well is like Jupiter, Radium, like even pump, all these things are all really, really tied together and the execution and you can see in the transaction that a single transaction will hit like 5 different markets all at the same time.
And we haven't seen like anyone be able to build AZK based or something that is truly off chain that still plugs into the atomic execution piece for trading. So let's talk about fired answer and sort of Solana clients, right? So fired answer's been in the works for a long time aiming to, you know, speed up and remove a lot of performance bottlenecks in the client.
What are your thoughts on, you know what the impact will be on the network and you see in the future you want to see a bunch of different clients running in maintenance at the same time? Do we need a bunch? I think 4 is what people it's like 4 or 5 is like you kind of need. Technically you should have 5 for BFT so you can do maintenance on one and then you still have reliability of 1 going down without a liveness failure.
That's like the dream, but the you just get an astronomical improvement on safety when you have two like because it, it's just such a, this is the, the thing that keeps me up at night is like some bug that auditors and testing and all that stuff missed. That's a critical vulnerability. That's a zero day that could steal everyone's funds. That's the scary part. You have two separate teams that
built the same code. It's very unlikely that they would have the same bug in both code bases that can be executed the same way at the same time. So you have some redundancy there that that's just really, really critical for these systems. But if fired answer now is, you know can process more transactions then I mean I would expect that all of the validators will switch to that, no, because they will earn more fees so.
No, it's the the limits of set network wise to make sure that both clients can can run it. And Agave is not a slow client. He can actually just you can literally just remove our limits and then run it at like 10X capacity. Right now. There's no, the, the limits are there to kind of slowly, like there's no fire to increase block space because even like during the, the crazy, the worst case day with like Trump coin launching the fees, the median fee was like 15 cents a transaction.
And this is when the network is doing 40 billion. Now that's high. And if that was sustained, they would become fire. But that being the worst case, you know, like peak demand, that was, you know, 10% of Nasdaq's volume. That's actually really, really good in terms of, in terms of fees. So there isn't a fire. There is a like, there's a reason to increase block space that I think is more long term.
And what I care more about is that like every release in bumps block space by 2040% versus them getting 10X in two years. Like as long as the developers are pushing themselves like, hey, what is the, what is the bottleneck that is keeping them up at night that could be exploited or whatever.
They write the test, they get comfortable with it, and then they tune that parameter up. This is what I want to see more so than like let's 10X and then see what breaks and have like a bunch of weekends everyone has to go like fight fires. You you mentioned the security improvements from having a second client. So how would the network behave in different scenarios? Let's say 10% of the validators
would run. Or let's say Fire Dance is new and only 10% run it. We need more than 33% run by the minority clients, so some it doesn't matter where it's but as long as the the smallest client has more than 33% then the network would halt. Right. It would halt. OK, I see. And that's OK. We're not at the area this. Yeah, yeah. And you, you see this as preferable. So you would say if, if, if there is a buck, then it should halt.
Yeah. And people can quickly fix it and it's a nega on everyone's face and it sucks and it should never happen. And there's a lot of effort to put in to make sure it never happens. But if there is a exploit, then yeah, please halt like right away. And then people can go fix it. That that's the preferable outcome to anything else 'cause like, I mean, if there's truly an exploit.
And you continue running the chain even if you allow like define liquidations to run, they're mixed in with exploited transactions. You fucking that state, the resulting that state is a nightmare. It's like it's worse than a 18 hour average or whatever. Like as as Ethereum folks, I don't know if you're around for the Dow hack. There was the only reason they were able to deal with the the Dow with the state, like with a hard fork is because it was locked.
All that all those funds were locked up in a smart contract that couldn't exit once if they started getting mixed with a whole bunch of things like it's just impossible to unravel. You have like somebody launches a meme coin, the attacker launches a meme coin, buys it with the funds it's mixed in with a whole bunch of liquidity. Like you cannot like, really untangle that in any sane way and. You'd have to like actually. Roll back.
I think you know and reset from an earlier state probably. Yeah, to me that is far worse than just a hard line is failure because that like not you can't roll back the real world. There's action that's taking in the real world based on the chain state, like Circle is sending funds out or based on like mints, like mint and burns, right? You can't like tell them, hey, go rollback his transfers.
It's better to halt this. This is like I, I think in all these cases, like it's basically better to halt. I think once you have 4 clients, you could say that like the probability of a bug in three is so much smaller than the probability in, you know, bug in two that it's fine for one to be down. And then you can do this kind of maintain some lineness while while one is down and and rotate. But yeah, the the terrifying this is the this is like the worst nightmare.
Well, I, I, I want to, I want to ask another maybe a little bit more on the scaling thing before we go to security. What do you think is, is possible here? Like if you think of like, I don't know, 5-10 years ahead, where do you want to see Solana in terms of throughput? And do you think it's feasible to basically have Solana scale to such a level that it can absorb, you know, kind of like or you can satisfy like all the demand of the world in terms of
block space? Our blocks right now are like 2 to 4 megabytes in size. The New York Times website is like 20 megabytes, but my my very mediocre goal is to get blocks to the size of the New York Times website. Like you don't even need the crazy 2D erasure code sampling for light clients when your blocks are the size of the New York Times website. People can just download full blocks to their phone and nobody like you. You don't need these like next generation technologies yet.
So, and that would be like a 10X increase and is, is that enough to handle the, the entire world? I think somewhere between 10:10 X to like my, my belief is that like you look at Google, they when the their estimated searches per second is somewhere like around 50,000 to 80,000. That's a fully globally scaled web application that is fully permeated the entire world that people use constantly and people use finance a lot less often
than not. So like 100,000 TPS in a single O1 would cover the 99% of the most important financial transactions for sure. So somewhere between like, you know, 1-10 X and another 10 XI. Think that is actually probably as far as crypto needs to scale. It sucks to put limits on it and people feel like oh you're being so pessimistic but like I pray that all my competitors are designing for infinite demand. That is like the worst, worst engineering trap.
And I don't even tell lots of people to 10X the capacity. What I tell them is like just two X at this year. Just think incremental improvements a year that you can ship confidently and then 2X it again next year. And just like that, that's so you get to like the the scale that isn't needed for demand. So 1, I know one project has gotten a little bit of attention. I think still, still very, very early, it's 00.
So where they're trying to create this, you know, private fiber network, do you think that's going to be needed? Yeah, it's not, it's not really fiber. And this is maybe I can explain to folks why how it works and why it's not scary. Basically there's there's nothing you need to change about fiber. The cables are all basically the same for like the last, you know, 30 years and light is very fast. What, what the differences are is the signal processing in each
hand. The switches that like handle the, that load the way they're designed for throughput is with big buffers and those buffers increase latency and finance and US right, like effectively part of the, the finance world, we want to have the lowest latency possible. So what we need is different kinds of switches. So every data center in the world, you can just go and tell them, hey, give me this switch, I want a super low latency
switch. I want this dedicated lane and somebody has to go do that work to go do those deals, talk to the people and stuff. And but in and of itself, it can be very decentralized. All these switches are in different parts of the world and different data centers under different ISPs. They can all be owned by different providers or whatever. So that part could actually be very decentralized. The fiber, no one's going to change that. It's already laid.
So a, a bunch of the stuff is very much like in spirit of the Internet and and crypto, I think, but it is one protocol. And the goal is to use 00 as an overlay just to have a, if the network is running in the fast happy path that all the messages like when we need to send out votes that can all go through the multicast super fast path for 00. If that fails, they're still going to arrive over the Internet, you know, 4500 milliseconds later.
But what we want is for the happy path when everything is working, for things to be as fast as possible. Cool. On the topic of then security, so on Ethereum over the many years there have been, yeah, kind of a number of of huge hacks and yeah, ways where people lost money. How so far has this been on Solana? What has been the biggest security incidents? I think wormhole was the biggest one and that was really unfortunate bug there was. This bug didn't exist in World War One.
And then in the second version they introduced this bug where you could fake the proof that there was a mint on the other side and an attacker exploited it right when they posted the fix for it in their public GitHub. So the attacker was watching their GitHub and waiting for the balances and wormhole to increase up to the mat. You know, as as much as they could before they did the bug. So this is like a professional attacker.
I don't remember for sure, but it might have been Lazarus Group that sucks like this. This, this stuff sucks. It's hard to really fix. There's formal verification companies that I think similar. Similar approach to how they formally verify stuff in Ethereum is typically you recompile the code through LLVM and you can use the intermediate output and run. There's formal provers that can run on top about to to test some properties I have thought of
like adding like the. The nice thing about Solana is the code is separated from state. So you could actually load, in theory, separate programs that implement the exact same state transition function, run them both and then see if they disagree and then abort. Do we need that level of redundancy? So we have redundant implementations for smart contracts too. And obviously the user will need to pay for twice as much compute and stuff.
But like compute is one of the easiest, much easier to scale than bandwidth. So like to me that that's almost like a no brainer if it would help. So that that's scary. I, I don't think Solana is any safer than Ethereum for new code. One advantage that that's kind of weird is that because of some idiosynchronicies of SVM, people don't really write interfaces for smart contracts. So there's no ERC 20 interface. There's an implementation of the token program, and everybody
uses that program. So it's like as if you had one canonical ERC 20. So that means that if you're a default protocol and you only accept SPL tokens, there's no way for the attacker to make to create a bad implementation of your C20 and steal funds from your users. So that has reduced a bunch of the kind of attacks that you see sometimes with like pool exploits or like bugs in the the RC 20s are legitimately like people making bad ERC 20s to
track to to trick users. And that has reduced I think a lot of the composability friction because then like you can build a company that doesn't write any smart contracts at all. You simply just reuse all these already pre built Lego pieces and they're all composable because everyone accepts the exact same implementations. And that's been interesting to see. So I don't know if Pomp wrote their own bonding curve. They might have, but they didn't build the AMM, they didn't write
the the token contract. All those have been standard. Like I think they use the Radium AMM so that that's kind of like one of the examples about. Yeah. In Ethereum, I think we had seen first this class of our kind of bunch of, well, smart contract hacks. But very recently there was, yeah, kind of a new very, very large hack that was not related to smart contracts directly, but rather to, yeah, interfaces being compromised.
And because, I mean, the reality is if you interact with a somewhat more complex program, then yeah, go to some interface, it essentially triggers a transaction that kind of on the interface promises you, you to do something. But of course, unfortunately, if the website is the interface is hacked in some form, it is absolutely or at least in Ethereum. And I kind of would be curious. About talking about buy bit. For example, yeah.
Or I mean, for sure, yeah, so. It was actually UI interface, right? The user interface, not the programmatic interface of the. Yeah, yeah. It's the user interface. User interface shows you you're doing transaction A, but to the wallet it's sending some malicious payload. And the question is now do you have any chance to understand in the wallet what, what the state change of the transaction will be? And yeah, kind of is. Is there a realistic chance to?
I don't actually think that this, I imagine this should be possible to do on Ethereum, but maybe easier on Solana. Is that like, because you know which accounts are token accounts and the implementation of those tokens, they're all the same. What I've been recommending people and there's a project called Lighthouse Protocol is they add guard instruction that aborts if the resulting state at the end of the transaction is different than the user expects.
So this would also protect you from like the you write a do you write a transaction? Do you think you're hitting an AMM attacker does a program upgrade that just steals your your coins, right? So they fake the simulation like this is kind of like a classic attack. You simulate your transaction looks fine, you submit it, but then something, something changes in the in the chain attacker sets a bit right? And it does something different.
So to protect against that, you can add that guard transaction and then your like your cold storage system should have effectively rules and policies in the cold implemented in the cold storage. Not relying on the human to go look at the trusted display and parse that string that actually checks for that guard transaction and checks that the spending limits and all the policies that you want are not
exceeded. This is what I have been like pushing people to do. And if you can kind of get there, I think with Keystone Wallet, they have a developer API where you can programmatically sets and rules sets and stuff. But yeah, this is I, I think this particular UI hack issues are solvable through kind of more robust security policies around cold signing and stuff.
I don't know if simulation is much more complicated than Ethereum, but if you know this is a cold storage system, you know that it should only be doing simple transfers. You know the accounts passed to it should only be token accounts. You can then add guard transactions that assert all that and restrict the balances. And then when you hit the chain, it'll abort. Attacker did something or screwed up the thing aborts, pager duty goes off. Everyone figures out that's like
what happened, right? I think that that is solvable with technology. I think stuff that's really hard, I think it's just smart contracts in general because the the more interesting ones are like risk systems like Ave. or Perps or any of these systems that are not just purely trading, they're managing risk. They have a lot of inputs like oracles and the attack vectors there are not obvious, right?
You have like there's latency games and exit games between the liquidity bots and the capital and the contracts. Those are those are very, very hard to get right and proving systems can't help there. But I, I think that these kind of high level smart contracts that manage risk, if they can scale, they're probably the most destructive part to traditional finance because this is the entire function of any bank or any, any fund or anything is managing risk.
If you can automate it, you've and you can scale it up, I think that's very, very disruptive and and very valuable. So with regards to smart contract security, I think today in Solana a lot of smart contracts are upgradable and it's also pretty common for smart contracts to be closed source. What do you? Follow those, just don't use them. Still do it. You have the power as a user to
not use those. But if you do have to use them, there's a difference between being an LP into a closed source smart contract versus trading in it. If you're trading in it, then use Lite protocol which will guard your transaction. If that closed source contract does something wacky, whereas there's or there's an upgrade that happens in the middle of your transaction, you can actually protect yourself against that.
If you're an LP, you are moving your funds into that thing and you're letting in custody your funds. You should know what who the hell you're giving your funds to. Don't do that. Look for open source contracts, look for formally verified smart contracts. Look for like multi sigs with time locks. If they have to have a multi sig for upgrade to make sure there's time locks on on those things.
Like, there's a whole bunch of things you can do to defend yourself, and you should ask the companies that provide these services to go do that and advertise what they are. But yeah, like, I think that part sucks. And the part of it is I think developers being lazy or probably not lazy. They're just, you know, limited runway, limited time trying to get traction.
But I think as protocols mature like I think you really need to demand for them to kind of put in the work to to level up their OPSEC and the security that and the rest they expose their users to do. You think there's anything that can be done, I don't know from your side or the OR you know like what can be done to try to accelerate this and try to get more open source immutable contracts or is it just a user demand type thing that you know, it's hopefully comes with time
maturity. It'd be good if there were like groups in the ecosystem that could kind of make a list of all the all the best practices who's following them. Neodime tried this with like security dot TXT and the and the and the GitHub and that that had some some limited positive impact. Yeah, it's probably should be like a group ecosystem effort. It's hard to maintain those systems and and like keep them up to date. So it needs, I think, like input from a lot of folks.
So we we talked about economics a little bit before, but you know, right now I feel like we've seen actually the most vibrant sort of governance discussion that at least I'm aware of in Solana with this SIMT 228, right? That multi coin proposed change to the inflation, which would make it dependent on how much is being staked. Because I think right now, right, we've had this inflation that kind of gradually, slowly goes down with time.
What are your thoughts first of all on on this specific proposal? Yeah. So I think the perfect way to have inflation is that like the network needs to get some stakers to run boxes and pay for the boxes running. And the only thing that the network can really sell is more tokens. So this is what the inflation piece. So if you were to run an auction, you can take the top best bids that are sufficient for you to to run a secure
network. And you don't know what those are, you kind of guess what that number is. But effectively you can kind of run this algorithm. You start with 50%, you take the top best 50% bids to stake and only those and you offer everybody the same price to run like a Dutch auction. And if that price is below 0, because people can bid a negative interest rate that they're willing to burn some of their tokens for the right to make blocks, you then increase the amount of stake that you
want. So you're targeting zero. And if the bid is above 0, then you decrease within some limits that at a high level people think are safe. We've seen Ethereum run at like 20 to 30% stake without any problems at all, like in the security side. So I think having the lowest limit of 20 would be reasonable. And I don't, I don't see any marginal benefit above like 80%.
So between 20 and 80%, right. This thing is bouncing around and people are bidding those bids have actually create a curve that looks very similar to the curve proposed in 228. Now there's an error there because the curve in 228 is fixed. There is this curve that you know, Max and a bunch of other smart people thought would be
the best approximation. But that error between the market rate in all these dynamic environments and the proposed curve is going to show up as the network over paying for steak. It's much, much smaller than the current setup. So my view is that like running these auctions and the complexity of telling users, oh, you need to pick a price and maybe you need to pick a negative price because there's a
lot of block rewards. It's just so complicated that there's no way to really scale it up outside of like a few small professionals. And it's a pain in the ass to run. Imagine you as a validator that your stakers constantly have to bid, like every epoch no matter how long it is right, Every 10. Months you could be the validator was bidding. Sure, could be the validator's bidding, but it's still like a pain and pain to run and manage
that. I think my view is like, don't let the perfect be the enemy of the good. This curve is a the proposed curve is a pretty good approximation of that process, and it's much, much simpler to implement. There's no auction. There's no like auctions themselves have a whole bunch of complexity that's gnarly and running them is gnarly. So in general, I'm I'm very supportive to 228.
What I want to emphasize is that like Solana has never been a money like the the point of soul is to disincentivize spam. If that we have another 97% negative downturn in the market and it's the bottom of the bear and this curve is not working out, people will change it. That's OK like that, right? I think people need to understand that there isn't like this Bitcoin ask we, we don't care about our grandfather. The sense of our grandfather don't bother us.
Like it doesn't matter what Bitcoin did in their monetary policy. Solana can do a whole bunch of stuff that I think Ethereum is still stuck on in this trying to be money and and like compete with Bitcoin that the Solana
ecosystem is not. So I think this curve is an improvement and I'm supportive and I'm, I'm encouraging people to vote for it and I think it'll reduce emissions And emissions are in a perfect world, emissions don't matter because the, there is no taxes and there's no middle men that can take a cut. But in the reality, you know, like you look at fees from custodians and centralized exchanges on the rewards, it's just like a huge subsidy.
And that's not even counting the the average global tax rate on on those earnings. Maybe, maybe on this note, would would you agree with with with the statement to say emissions are a tax on on everyone who's not staking? Oh yeah, the the emissions themselves, it's just money moving around the black box. But it's not like the group of users that are staking and not staking are different people. You can literally be both at the same.
Time, right. Well, yeah, certainly in in Ethereum there are some people that that have a strong feeling there should be reasons for ESA to not be staked and just be held in ESA and they see kind of staked ESA potentially as a threat to the whatever money Ness of those. So things again you don't really care about or yeah.
So would, would would you say 90 or even close to 100% Solana staked or or be be in the form of some stake Solana or something like that took a nice stake Solana that you wouldn't see as an issue? If there's like UX issues around it like that's what I would care more I think. I I don't like when things hit the limit like it it seems like there's a bug somewhere incentives wise like it did. You don't need 100% stakes. Sure, yeah.
Yeah, you don't need it, but but the question is, wouldn't it be rational or if, if if staked kind of a tokenized stake version is just so easy to access, then why not get the addition of the 1% essentially or whatever it is? Well then why isn't the rate negative would be my question? Like if it's at 100% then people should be then somebody's overpaying, right? So to me it bugs my market like free market thing more than like whether it's usable as money or
not. It's like it seems like the whatever curve you picked, it has a bug in it and has caused the IT to hit the limit point, right? So that's what you want to avoid. You want the parameters to be set somewhere where you're not at 0 or 100%. But like, if in general, like I don't, I don't think there's any threat to the muddiness of it. And I don't really care if Seoul is used as money.
If, you know, if there's ten billion per day volume of ETH versus everything else on Solana, it's great we hit PMF. There's real activity. Like why? Why would anyone be upset? Shade, Maury, I don't care. Cool. I think you started, you started with with saying that, yeah, some things came as expected. Other things specifically the use cases did not came as
expected. So maybe making an outlook for yeah the next couple of years, do you, do you think that those finance use cases that you initially expected or what are the blockers there and how how do you see that or are too difficult to guess? These unexpected use cases surfaced a lot of problems that I think are real.
I think there's like I, I think we need multiple concurrent leaders and like the, the ability for applications to prioritize market maker cancels before takers, like all that stuff that needs to be implemented before Tradfi really takes the system seriously. Because the like not even like the the launches themselves. Like I think are like Abd problem. Like you've seen a lot of like really extractive launches launched by like terrible people that should all be nude from orbit.
Like that stuff I feel like is is like business development. You just need more robust platforms that have better enforcement and stuff like that. But on the network layer itself, there's a whole bunch of microstructure problems with the way that transaction land and how MEV works that I think need to be fixed and addressed for me to feel comfortable with like people's 401 KS running in these things like that. That's like, I think with meme coins and NFTS, it's like the
stakes are medium. Like the volumes are real and the numbers are real, and there's real, real money at stake and people really need to take it seriously. But we're not yet like, dealing with like people's savings, right? And I want the network to be so robust that I can tell, like you should, you know, don't trade on NASDAQ, trade on Solana. Like it's going to be better pricing for people. It's more fair and more transparent that that's the ultimate goal.
Because but like, there's a whole I was more, I was more and I, I thought it would take four years ago, I would have said we're ready in the year. Now I'm like, shit, this is going to take five years to fix. Just those problems are are so
hard. Then maybe just one more push back on the on the on the on the thesis of it needs to be faster and it needs to be. I have an alternative thesis that they I think there is pretty good literature that shows that at some point, yeah, faster, faster systems do not lead to to more efficiency, but that there are alternative market structures, namely batch auctions or or yeah, micro batch auctions. And to me that seems like a very
interesting approach. That has been the approach that I have always been pushing for blockchain because if you have a block, then in a way that is kind of you can see it as a batch and you can try to do things like single price clearing in this in in, in this block. So that is in my view kind of a counter grout to this. We just need to be faster to to to solve things. I actually agree with you, but I think my batch auction is 100
milliseconds not not fair. Not, not, not 12 seconds, Yeah, but I mean, I mean, I think my my counterpoint would be how many real world events really happen in in in in 12 seconds. So I mean a thesis theoretical argument that that if if. Well, to be NASDAQ, I think we need like the latency to be basically the round trip around the world and for the inclusion latency to be shorter. So local block producers that are concurrently within this 120 millisecond auction.
I think at that point you can reasonably argue that it's as good as price discovery, assuming there's no like MEV extraction. We solve that. Throw some salt over a knock on wood. If we solve those problems, I think it's very hard to argue that a faster system is more than marginally better.
I think at 12 seconds you have like this information games that are that are still harder to solve because you literally can go to NASDAQ, take the trade and then Arby against the chain and like that that's the opportunity that I wanna like. Once you eliminate that for the most part, then trader that sees that newswire and Bloomberg, they look at the chain price or NASDAQ price, it's the same price. Then it's as good, you know, but like I I agree with you.
You don't need to go to like below that latency for a global system because the world's you still have like the event that happens in Singapore still has to go travel to New York, right? So you have still these embedded latencies that are on the order of, you know, round trip time around the world.
Yeah. And I mean, I think the, with regards to the whole, you know, finance coming on chain and stuff, I, I, I, I do think there's a huge upside even with all of this, you know, mean coin defy stuff is that, you know, in the end, a lot of the, the infrastructure, right, the applications, the ability to compose different protocols to collateralize one thing and the other. And I think there's just so much happening there and so much
progress there. And then I think once you plug in more traditional financial assets in there, you'll just have a very powerful system. Yeah, on the on the plus side, your if your risk engine survives meme coins and crypto, it can deal with like field world assets that are much more stable. But that's the the hope, at least. Is it fair to say for you blockchain means financial applications or do you see other things? It's a good question.
I think like I think this, it is like kind of melted with the Internet. Like if you have truly globally, global payments with no friction, every, everyone can pay every, everywhere. That's very different than the the the way the Internet works now, because you effectively, because you don't have money on the Internet, you have all these subscriptions and all this kind of friction that created the silos and. Around ads. Ads as a business model instead of just yeah.
So like, and that model silos everything, right? YouTube wants its own silo, like Facebook wants its own silo and they're very, they're fighting each other right to for market share. You still have some of that, but I I feel like just making it easy to pay everywhere and everyone could start unraveling it in in a more open way. And I like the web. I like the idea of like, you know, minimize the cost of publishing and like let the free world's free market figure it out, right?
Like I, I think that that's cool and, and kind of a, a really cool, beautiful thing. I think the finance will unlock a lot of other use cases, but I'm hoping are are disruptive to the big kind of big tech monopolies. But we'll see. Cool, you want to share anything else that's like on your mind at the moment? It's a lot of mobile's coming out soon, so stay tuned. Oh yeah, the. The Seeker. The phone. Yeah, Seeker. We'll try to disrupt the duopoly.
What's your hope for the phone on like how what? What do you see as the role of the phone? So the goal is to get enough crypto people in the same ecosystem to where developers have like a distribution channel and there's like 150,000 pre-orders. That's a reasonably sized group for a crypto app that's actually like 50,000 daily active users is huge.
So if we have the, if we were able to capture the right kind of audience and there's a high probability that we were because people have to pay 500 bucks for a crypto phone. Those are kind of the users that you want as a developer in crypto. So they have money and they're already crypto native. If you can build apps for them that keep their attention and they're like super cool, you're saving money on the 20 to 30% rake that Apple and Google charge. You know, we talk about
disrupting finance. They charge basis points. Apple and Google charge thousands of basis points. What is that like 3000 basis points, right or whatever.
It's absurd rake. It's just crazy that for like 20, you know, 20 years now that they been able to get away with it. So to me that like massive, massive rake that they take seems like an opportunity because if devs have can't distribute to crypto users and there's enough high spending users in that distribution channel, they will actually look at their like top 1% users that are the spendiest users in iOS or Android.
I'll literally give them a the phone for free or like offer them incentives like through air drops or whatever. That that's the hope that we can get that flywheel work working. If it if it works, then that's like a huge opportunity. How how strong will be the connection between the phone and the chain? I mean I assume there will be by default wallet on the on the phone.
Yeah, there's there's an embedded wallet and an enclave to run the seed phrase and there's a bunch of work to kind of unify the experience so people don't have to switch UI. It's more like Apple Pay that that's the goal. I'm actually not like opposed to adding Ethereum support or anything else in the future. It's just these are like iteration times with hardware so long. So it seems like we've been at it for a while, but this is just
like the second release. It's in got it to keep the team focused and and ship, you know. And I assume technically it's it's it's based on Android or. Yeah, it's Android. Yeah, vanilla Android with the enclave kind of wallet signing feature at it. Yeah, I know. I mean, good luck with this initiative. Certainly think the reserves, yeah, should get more competition. If we lose because they compress their fees, then that's the beauty of capitalism.
Then that worked, right? Like a competitor was able to change the equilibrium in the market and that that's an awesome outcome. Cool. Well, thank you so much for coming on and totally it was really great to have you and super excited about the Solana Road map and the pace at which the ecosystem is moving and you know all of the things that are ahead. Thanks for having me, this was super fun.