Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Anatoly Yakovenko: Solana - Reaching for the Limits of Blockchain Performance

Episode Date: November 6, 2019

The vision of a world computer on which anyone can deploy smart contracts has captured our imagination since the publication of the Ethereum whitepaper. But while Ethereum demonstrated the viability of the concept, its shortcomings in terms of capacity and throughput prevent it from realizing the vision. Today, throughput has become a major bottleneck for widescale adoption of decentralized technologies.Many projects have set out to deliver where Ethereum 1.0 falls short. Most projects, including Ethereum 2.0, aim to create some kind of sharded network with many interoperable chains. Solana may be the only project that went the other way. Through identifying every performance bottleneck for a single blockchain and developing novel ways of removing them, they target to achieve throughput of 50,000 tps.We were joined by Solana creator and CEO Anatoly Yakovenko to discuss Solana's approach to building a web-scale blockchain. We covered some of their novel ideas including proof-of-history and parallelizing smart contract execution.Topics covered in this episode:The performance-obssessed engineering background of the Solana teamThe arguments against sharding for scalabilityThe value of a shared sense of time in a distributed systemHow Solana's Proof-of-History creates a global clock for the networkHow Solana uses GPUs to parallelize smart contract executionHow value could be accrued for the native token if transaction throughput is abundantSolana's upcoming Tour de Sol testnets and launch timelineEpisode links: Solana WebsiteProof of History: A Clock for BlockchainThe World Computer Should Be Logically Centralized - Multicoin CapitalMulticoin Capital: The Separation of Time and State - Multicoin CapitalHow Solana's Proof of History is a Huge Advancement for Block TimeTower BFT: Solana’s High Performance Implementation of PBFTSponsors: Trail of Bits: Trust the team at the forefront of blockchain security research - https://trailofbits.comVaultoro: Trade gold to Bitcoin instantly and securely starting at just 1mg - http://vaultoro.comThis episode is hosted by Meher Roy & Brian Fabian Crain. Show notes and listening options: epicenter.tv/312

Hi, welcome to Epicenter. My name is Sebast Sankutur, and I'm here with Brian Fabian Crane. How are you, Brian? I'm very good. I'm excited to give a little intro about Salana, which was an interesting episode and a project that I've been kind of connected with for quite a while. Yeah, I've been listening to the interview that you and Meher did and trying to wrap my head around this. Before we start recording this, we were trying to figure out what would be the best way to explain this. and I think we've kind of figured it out. So I'll let you run us through the key points about Salana, which will frame this discussion. Yeah, so Solana is really not an easy project to understand.

So we were introduced to the Salana team, I think, a bit over a year ago. And so when I was in SF, I would work from the Salana office and hang out with them and had quite a few conversations with them just trying to understand how this thing works. and it is probably the hardest blockchain that I have tried to understand. Maybe the other ones that are equally hard,

but I haven't sort of like tried to dig into it to this extent. But basically what Solana is, right? Solana is building kind of a next generation smart contract blockchain, right? So they're trying to solve the same problem that, you know, Ethereum is trying to solve, basically have smart contracts, have it scalable, have it decentralized, you know, based on kind of like proof of stake. And where they are taking a quite different approach is that they're, you know, they don't believe in sharding, right?

They're basically trying to build a single chain that's just hyper optimized for performance and throughput and speed. And so I think in that way, they're differing from, you know, most of these other novel approaches, you know, whether it's Cosmos or PolkaDot or Ethereum 2.0 or Near. you know, they all have some sort of of Ava, right? They all have some concept of sharding in there. And so they're different in this way.

One of the things that we talk quite a bit in the episode, that's a sort of key, innovation, key approach to Solana is the consensus. And the consensus they have this thing they call proof of history. And it's basically the idea

here is that you separate the block production and the kind of verification of transactions. from the consensus so that you always have somebody producing blocks and they can kind of produce blocks as fast as they can and then the other nodes the other validators can kind of afterwards verify those blocks and then come to agreement on what's the canonical chain but this consensus process isn't sort of slowing down the network and so that's one of their key approaches and it's a very, very interesting how they do that to the after this idea of a decentralized clock

where basically kind of everyone is running this sort of like a verifiable delay function, all the validators to help of that. But we go into much more detail on that in the episode. And another thing that's, you know, probably kind of a core approach, a core aspect to how Solana approaches this problem is through the paralyzation of, you know, smart contract execution. So if you look at something like Ethereum, you know, the challenge is even if you kind of speed up the Ethereum consensus a lot,

you know, if a validator, if a full note has to execute all these smart contracts and, you know, with the EVM, that becomes the bottleneck pretty quickly. And so, for example, Ethereum today, even if, you know, you could have massive blocks from a from a consensus layer basis, you wouldn't be able to do that because the nodes can't keep up with it. And so they're focused a lot on how you can basically paralyze the execution of it.

So they're using GPUs. So each validator, when you run a full node, you have to run GPUs. And then, you know, you could have potentially these smart contracts run, you know, executed simultaneously in parallel and cross thousands of GPU cores. So that's also one of their interesting approaches.

And then they have a lot of other stuff that some of them we didn't get into. But they've really been very innovative in trying out a lot of radical new ideas. Yeah, that's interesting that it's a proof of stake network, but then also leverages GPU. So the validation doesn't actually happen as a function of proof of work. It happens as proof of stake. But the smart contractors still run on GPUs. And so we also, just there's some disclaimer here, right? So we have, as many of you know, Meher and I, we have been running a company that's been doing a lot of work around proof of stake, including running validators.

And so we have been actually running validators in the in the Solana test nets. And they are gearing up to something like the Cosmos game of stakes thing. And, you know, they're very close to that. And so we've been running on these test nets. And we've also been building some staking infrastructure for Solana. So we basically have a high availability solution where a validator could run like multiple notes and then have like automated failover. So if one note goes down, the other one kind of takes on. So we have been digging into Solana quite a bit from that aspect.

And just sort of a final disclaimer on that note too, which was that Meher and I both participated in the Solana kind of the token sale. There was a sort of a private token sale. So yeah, there's just some information about our, you know, some bias and involvement that we have in the project. Regardless of that, it's still a very interesting project and looking forward to learning more and understanding more about how this works. Because after listening to the interview, I got to say, there's still some areas that are very shady in my understanding about this. To be honest, I think that's assuming Solana really works the way it's meant to work. And I'm optimistic on that side. I think their biggest struggle is going to be just the complexity of the system and people understanding it.

That's going to be a real challenge for them. Hopefully, when it comes to people actually developing applications on top, they don't have to really understand and worry about it so much. But of course, here in the blocks, you want to understand how these systems work. And that's definitely something hard in the Solano case. One thing that I hadn't realized is that I thought that Solano was somehow like, a cosmos zone or like somehow closely related to like the cosmos ecosystem, but that's not the case. They haven't built on the cosmos SDK actually. It's a totally separate blockchain.

But as you were saying, as we were talking about earlier, is that it's possible that Solana might be sort of IBC compatible and could connect to the cosmos ecosystem sometime in the future. Sure, totally. I mean, I think the idea of IBC in any case is that it's basically kind of agnostic and compatible with all kinds of consensus mechanisms. and different chains. I think the main constraints on IBC is that a particular chain has some concept of finality, which Solana does, and that it has some kind of smart contract capabilities,

you know, that a lot of point is it maybe doesn't have to be like full type of smart contrast. But so both of those are the case. So yeah, I think it's possible. There's also some requirements not about like clients. And I think that's a little bit underdeveloped today and Solana. But yeah, it's actually something we've been exploring as well. It's like, okay, how would that work?

So yeah, you've been, you're still in San Francisco last week. There was San Francisco Blockchain Week, you know, big event with all of the blockchain people congregating in the city. Tell us, how was it? It was interesting. It was really exciting. So as we're recording this, it's the day after the DFI. hackathon. So SF Blachian Week started last week, first with CESC, and then SF Blachian Week Epicenter, which was later in the week, and then the hackathon over the weekend. So I got here in

the middle of CESC. I didn't get much of that, but it was more of the technical conference. So a lot more technical talks. In fact, Vitalik also gave a talk at the very end. And then the SF Blachamik Epic Center, which was organized by DECRIP Capital, was more of a business conference, although somewhat technical, but it's my first time here in San Francisco. So I was getting to discover also that ecosystem. And there are a lot of people. So the epicenter conference attracted, I think, over 2,500 people. There were a lot of, a lot of the talks and mostly panels, I guess, were with people from like the Bay Area, so like investors, a lot of the projects also in the Bay Area. And what was also interesting was that they managed to attract

one of the commissioners of the SEC who was speaking remotely, but it was speaking at the conference. There were some U.S. Congress people here as well and people from Libra. So it was a good mix of like blockchain people, but also people on a regulatory side, a lot of investors and people from Libra as well.

So I was emceeing that conference on day one on the main stage and then day two on the second stage. So yeah, I was I was kind of running around. hurting cattle, as they say, getting the speakers to, you know, line up and come on stage. So that was really fun. And then the hackathon was over the weekend. I was kind of in and out. And yeah, it was quite big, 600 people.

And that ended last night. So it was still kind of recovering from all that. As you can hear my voice, I've got a little bit of cold. But yeah, I'm here for the next couple days and looking forward to coming back to Europe. So I can take a week off. Any sort of interesting insights about where the blockchain space is at or what exciting new projects or kind of trends? What do you main takeaways? My main takeaways are a little, I'm a little divided about them.

So one thing is for sure. I mean, defy is kind of like the big trend at the moment. And that was really obvious at the defy hackathon. And defy is no longer just constrained to Ethereum. I mean, most of the projects were at the Defy Harkathon we're building on the Cosmos SDK. And so, Defi is growing outside of the Ethereum ecosystem. The main takeaways from the conference, I think,

I felt that there was maybe a lack of excitement that the space is, you know, we kind of feel that the crypto winter a little bit, although there's a lot of new projects coming out and on the Defi side, like a lot of innovation happening. It's a bit flat at the moment. You mean flat in terms of there's no enthusiasm or what's flat? Yeah, the enthusiasm is somewhat lacking. I don't know if you remember we were in Berlin once for this Inside Bitcoin's conference

during the Crypto Winter in, I think, 2014, 2015. And one of the things that we had remarked at the end of that conference was like, things were very different from like the first Inside Bitcoin's conference in early 2014. This kind of feels like that little bit. Although there's a lot more people in this space. The ecosystem is much much bigger, a lot more projects, a lot more attention on blockchain. But generally, the excitement level is a little bit attenuated. Yeah, I guess that's the natural cycle of ups and downs that we're well accustomed to at this point.

Yeah, absolutely. I have no doubt that the excitement will come back. But what's great is that there are a growing number of people in the space. and I think once more like tangible use cases start emerging, then, you know, excitement might come again. Also, I think like the price makes a big difference too in people's excitement level. Cool. Well, awesome. Before we go to the interview, I'd like to tell you about our sponsors for this week's episode, starting with Trail of Bits. And smart contracts are a unique breed of software because they can hold an astronomical amount of value.

And as Defi continues to grow and defy applications become more and more leveraged, the risk just goes up tremendously. And this is why getting your systems audited and creating robust security processes and specifically maintaining and fostering a culture of security in your organization is really important. And to do this, you should only trust experts like TrilfBits that have that real security expertise. TrilfBits works with your team to audit every aspect of your project. They check your code, but that's just the beginning. because what they also help you do is implement best practices around things like key storage and DevOps and your website and your application. But it doesn't stop there because once they've reviewed your code, they'll provide you the tools to make sure that it remains safe after every new commit.

And they can even put a software security expert at your team's disposal so you can ask him for advice and he'll answer your questions when you need them. Tril of Bits is at the forefront of security research and their research goes well beyond smart contract security. In fact, if you go to their blog, you can check out a recent article that they've posted about safe browsing. Safe browsing is that feature in a browser like Google Chrome, for instance, that when you go to a malicious website, you'll see this red browser window that alerts you that this is a malicious website and you shouldn't go forward. This feature leverages basically a database that's held by companies like Google and your browser sends a little piece of encrypted data or hashed data to Google and then Google sends. back a confirmation of whether or not this website is okay. And although they've implemented best

practices around security, Trail of Bits has found that this process can actually put a user's privacy at risk. So you should definitely check it out. It's at blog.trialofbits.com. So learn more about Trail of Bits. Go to the website, Trail of Bits.com. And if you decide to reach out, make sure to let them know you heard about them on Epicenter. We're also brought to you by Voltoro, the leading gold hedging solution for the crypto community. Gold is a stable asset. It's been trusted for millennia. And it's a great long-term hedging solution, hedging against the crypto market volatility,

but also hedging against the traditional financial system. And at Epicenter, we've been friends and clients of Voltoro since 2014, and we've held a portion of our company's crypto assets in their vaults to protect against volatility. Now, if there's a lot of things you can use out there to protect against volatility and stable coins are one of them, and they're great for usage in defy applications. But if you want a long-term hedging solution against volatility in crypto, you really want to turn to something like gold that has that track record as a long-term stable asset. With Voltoro, your gold is secured and stored deep in the Swiss mountains in vaults that are protected by Brinks. Every single gram of gold is audited and holdings are transparently available on their website for anyone to verify. And most importantly, and the thing that I like the most about Voltoro is that it's quite literally your gold.

It's contractually yours. It belongs to you. And you can choose to have it delivered at any time. To learn more and to get access to Voltoro's brand new V2 platform, which includes a new interface and trading in Dash, as well as in Bitcoin, go to Vortoro.com. And when you create your account, do me a favor, click on the little yellow support icon at the bottom of the dashboard and just let them know that you came from Epicenter. Let's go to our interview with Anatoly. So we're here today with Anatoly Yakuenko, who's the founder and CEO of Solana. So Meher and I, we've been following Salana for quite a long time. We spent a fair bit of time hanging out in San Francisco at the Salana office, working with Salana. you know, both invested in Solana.

So it's a project that we've been following for a long time. And I'm really excited that we have Anatolia on today. It's a complicated project, hard to explain, but also infinitely interesting. So yeah, thanks so much for joining us, Anatoly. I'm super excited to be here. Yeah, I've been like a huge fan of you guys for a long time as well. Thanks so much for coming on. I mean, I think already when we talk in the beginning,

you, okay, at some point we've got to do a Solana episode. But the challenging thing is explaining Solana. It's just, you know, it's a challenge. So hopefully we'll manage it today. Salana is a beach in San Diego County. That's the explanation. So tell us, how did you originally become interested in blockchain? So I'm an engineer, right?

I've been, I spend most of my career Qualcomm working on. one form of another of a distributed system. But really, like, majority of my life, working on semiconductors, like the chip level operating system firmware stuff. And when Bitcoin came out, it was kind of a curiosity. Like, oh, wow, this is, like, a totally different way to solve this problem. I even, like, tried mining it with CPUs, but, you know, kind of like, this is just kind of a toy.

Didn't really think too much about it. And I remember the Ethereum, my CEO, and looking at the EVM and thinking, okay, this is more interesting, but it's still kind of JavaScripts for Bitcoin and really missed the whole kind of revolutionary part about it, that once you have this secure computer that's globally available to everybody that, you know, interesting things can start happening. So in around like I think early 2017, I was in San Francisco and with a friend of mine we were thinking about actually starting a startup where we would mine crypto with GPUs, but then offer those GPUs for deep learning, like, jobs.

So kind of offset the cost of, we were actually more interested in deep learning than crypto at the time. And a way to offset the cost of building out racks of GPUs, right, is to let people mine it with crypto. But that's what really started me, like, digging through the protocols and started thinking about, like, okay, what are people like? actually doing, why scaling such a problem? And obviously at the same time, 2017 had this amazing bull run. And transaction fees were like $60 a transaction or something crazy like that

in Bitcoin. And I started kind of thinking about how did we solve scaling for these kinds of problems at Qualcomm in wireless protocols. And that's what really got me to go deep down the rabbit hole. And so I know a lot of people, right, that the Solana team come from Qualcomm. So what's Qualcomm like? What's special about that place? So I graduated in 2003

from University of Illinois and this was post.com crash. So a couple friends of mine, we actually had a startup if you guys ever remember Grand Central Dispatch or Vonage. So we were building these voice over AP software

systems. But in Central in Illinois, there was like after the dot-com crash there was zero funding kind of zero interest in like new tech and while we built this really cool thing the project kind of died but turned out qualcomm was using similar technology stack and kind of hired me in the spot and I interviewed a bunch of places but the interview there everybody was wearing flip-flops and board shorts and had their own office and it was just like done surfing so it was kind of smitten by the culture there like it was very laid back kind of people that work there. Because San Diego is a beach town. There's really

nothing else to do there besides, you know, do yoga, go to the beach and like, you know, have own a dog. That's literally like what everybody does there. But it turned out that on the tech side, it was really, really kind of an insane breakneck speed from 2003 up until I would say 2012 when mobile phones went through this crazy evolution. If you guys ever remember what phones were like in 2003 to what iPhone 6, iPhone 8 is like, we went from running on a microcontroller, basically a 16-bit, like single-core, 400 megahertz like dinky chip to 8-core, like 64-bit desktop grade or server grade. hardware with like 20 different subsystems like GPUs DSBs modems all this other stuff all in the same die so it was really crazy basically in 10 years every year we had a insane architecture evolution on the chip side just things just changed so it kind of learned a lot about how fast technology can move like it was really like not something anybody could have predicted in 2003 that right now in your hand you hold like a certain

a great computer. So, you know, coming with that kind of background and approaching blockchain, coming with that history, how do you think that changes your perspective relative to kind of the rest of the field? You know, software actually takes longer to build than hardware. People think that hardware is a huge investment, but the way hardware works is once you have a design, you can scale it up. The whole point of hardware design is you build something that can scale up as you add more basically more lines to memory, more higher frequency to memory, and more area that can be used for caches and stuff like that.

Those kinds of tweaks that you do are very easy to do. I mean, not easy, but they're kind of straightforward. They're not design revisions. So the kind of hardware you want to ship is the kind that when you do have cheaper available dyes to you, you can tweak those numbers and just get more performance. And then you do kind of start optimizing for power and stuff like that. And power management is probably the hardest part in hardware. So because software takes so much longer to build, because it's an iterative process, we ship it,

customer hates it, we have to rewrite it. There's like farmer requirements. It's a much broader. set of APIs to fill. The way to design it is to build it such that when those hardware improvements happen, that you don't have to do a lot of work, especially in the upper layers. So your lower layers, you really want them to kind of scale up with hardware. So the way I started thinking about software, especially the part that I was working on

in the operating system, is that how do I make sure that when this hardware eventually changes and literally next year, right, I'm working on something that I'm shipping today that will have to run a new hardware next year that I know is going to be faster. How do I make sure that it gets faster, right? How do I make sure that the software doesn't get in the way of the hardware? It's kind of one of my quotes. So when I started thinking about blockchain, I've already been doing that approach for 10 years. So really, like, the first thing that I thought of is, is what are our constraints? So the obvious one, the main constraint is bandwidth. So given that we have X amount of bandwidth, how do we utilize all of it? And that's kind of where the design

started from. If you have like one megabit of bandwidth, you can stuff, you know, about 5,000 transactions in there. If you have 100 megabits of bandwidth, that's 50,000 transactions, right? So that's how you can think of it. Is 100 megabits of bandwidth a lot? Your 4G phones, the standard for 4G is point to point anywhere globally, 100 megabits. Yeah. I mean, being from India, I doubt, debate that point. I have the first project that it works on. We got pushed to talk to work from San Francisco to Hyderbod and I think under 150 milliseconds on this thing that was precursor to LTE even.

It's called EVDO if I remember correctly. So, I mean, but stating the broader point, the broader point is that if I have a 100 megabit connection, which I do at my home, and presumably many people do at homes, then we could get, I don't know, 50,000 transactions a second into our systems somehow. That's sort of the mouth of our system, right? And so your perspective would be that if we were to be a full node and we are going to process these transactions, that somehow the software running on our systems has to be designed in a way that it can consume all of those 50,000 transactions and process them and validate.

them. If you could build your software in a way that you could consume whatever ingress the bandwidth would allow, that would be the ideal blockchain you could engineer. Yeah, that was basically the premise that I started with.

I didn't even think of sharding as an option. You know, I thought that every team out there is doing the exact same thing. It was like, we have to build this as fast as possible because everyone's going to do the same thing and we need to get ahead of them. Yeah, I mean, it's interesting. you coming from this outside perspective if there's completely, because if you sort of approach

it from like the Bitcoin side, right, then you'd be like, okay, you know, there are all of these variances in bandwidth, but we almost have to sort of adapt to the least common denominator, right, because otherwise they fall behind and incentivizes, right? And I even know there's like this well-known Bitcoin developer, no Greg Maxwell, who lives somewhere in the bush. And he has like a super terrible connection. So, you know, he would be like, no, it can't be too big blocks. He can't mind there. And, you know, I guess there was this philosophy there, which then carried over to Ethereum, too, because basically the same proof of work. But of course, it's interesting to ask, you know, is that necessary at all? And then I guess you have to come up with something very

different, right, if you want to get rid of that constraint. Yeah, so the trade-off is definitely that you need those 100-mabit connections. Every four years, bandwidth basically drops in price by 50%. So if people think that 100 megabits is expensive now, it's going to be twice as cheap, four years from now. If you look at Bitcoin, it's been around for, what, 12 years now, something like that. The price for the original design, right, the amount of bandwidth available to the design has, what is it, eight times more, right? 8x amount of bandwidth. You have 2 to the 6,

so 32 times more compute available to each node when the design started. But no aspect of Bitcoin is leveraging that. It doesn't have more throughput. It's not better latency. It's not more censorship resistant.

So there's a design mismatch between Bitcoin and hardware, right, and the real world. And that design mismatch is, I think, is going to be what kills it, honestly. Like, I think if there, really focused on going the other direction, then kind of like, you know,

built something like bunker coin, it's a project that doesn't exist, but, you know, imagine blocks that are transmitted over shortwave radio that cannot be censored because there's no network infrastructure. You're using, like, you know, bouncing the data off the ionosphere. So you'll need six-hour blocks, but then it's as decentralized as possible, right? But yeah, I think it's a great point about Bitcoin. Now, of course, the thing that Solana is more kind of aligned towards or, I would say, competing with in a way is Ethereum, knowing that Solana is a full smart contract platform. We're open source projects competing to the death. Yes, yes. There's no such thing as competition in the blockchain world, I know. But if you look at Ethereum, what do you think are the biggest problems and shortcomings there?

So I want to say that, like, I actually, I mean, I'm a huge supporter of Ethereum. If Ethereum fails, we're doomed. My project is doomed. Everyone else's projects is doomed. So we all depend on Ethereum 2.0 succeeding, like it or not. I don't know if that's true. I think to some extent. Like, I think a lot of gas will go out of the space if Ethereum dies.

Because it has so much momentum and community, it can't just die for failure, right? technology will ship eventually, right? So I'm very much hopeful that Ethereum succeeds. And the problem that they're solving with sharding is trying to build a system that is as decentralized as possible. And that's a really hard computer science problem. And that's, I think, that is the trade-off, right? Because what we're doing is a hard engineering problem. You know, it's just we have bandwidth, we have computers, we have, you know,

SSDs and GPUs, how do we write the code that just makes them work, right? Engineers can do that. Ethereum and these like NIR and these other sharded solutions are trying to build a computer that is, you know, you have the smash network of arbitrary machines with arbitrary profiles that are all interconnected and somehow contributing to the security of the network. That's a computer science problem that hasn't been solved yet. and there's a lot of designs and design trade-offs and as you see, like, if you've been following Ethereum,

they're iterating and their designs pretty frequently still. It's not like a set on stone. The number of shards changes. When you have a design that's computer science design and then you try to make it convert the papers into engineering, that's when the rubber hits the road and you start iterating back, right? Oh, this is not going to work.

This is going to be too expensive. of, you know, so that's, I think, is the main challenge with Ethereum. But to kind of speak broadly, why is sharding such a huge tradeoff? The kind of fundamental problem in blockchain is this like thing, this trust thing. I don't trust you. You don't trust anybody else. And when you shard the chain, the shards don't trust each other. And verifying and the consistency of all the other shards in the system, that's the real.

hard problem. And how do you do that efficiently? How do you do that such that the network does install? They're weird attack vectors for data availability between shards. There's a bunch of really complex algorithms that folks have designed in protocols. Nobody knows if they're going to work, right? If the incentives are going to align well. And the reality may be that there's, you know, what, two, three hundred professional validators out there right now at most. So is it even needed, right? Yeah, I mean, in Ethereum, in one of the recent designs, there are like 1,024 shards, and there are like 600,000 validation slots that you can occupy.

And I think, like, Ethereum is targeting the world where I have my laptop and I should be able to put my 32Eth on it and go and validate maybe one shard or one and a half shards or two shards out of the 10024 and the assumption appears to be that lots of people are going to do this on their laptops and somehow you want to add

the security of all of these machines together to have a very secure machine that's secure across all That would be amazing, right? That's like an amazing design goal. Like there's no doubt about that. Yeah, that's an amazing design goal whereas now

we run validators at KORUS So we see the underlying systems of tendermint and Solana at close eye. And there the assumption is different. Then the imagined world is different. The imagined world is there's maybe like 200 professional validators. You can assume that these professional validators will go and source good bandwidth connections. They can. They will go and source really great hardware individually.

So you can rely on the validators to have really performant hardware and really good bandwidth. And there's 200 of them that the network can source. And so how do we make these 200 high-powered, well-connected machines work together really well and process as many transactions as possible? That seems to be the tenderment goal and the Solana goal. Yeah. So one caveat there is that 100 megabits is not high-powered. right? That's a home connection right now in the United States. Data centers will give you 10 gigabytes. A lot of data centers now will give you one gigabit for free. And the amount of compute you need to actually process 100 megabits worth of transactions is like a $5,000 gamer machine. We use off-the-shelf GPUs. So that barrier to entry is actually quite low. If you look at how much people invest in mining Ethereum at home,

It's kind of typically around that amount. So anyone that's mining Ethereum can actually mine on Solana, right? And we can have a very large set of validators. We've designed the software, like the algorithms to go to 20,000 computers. It's kind of been our kind of design goal. Because realistically, I don't think we'll see 20,000 computers for like five years at best, right? At like crazy exponential growth. at some level running these validators,

you start to realize that the barrier to having a lot of validators isn't hardware. It's economics. It's the fact that if I am, let's say, the thousand validator in the system in terms of stake, I still need to invest all my weekends to get the machine up and running well.

But is it going to produce, use enough money to compensate me for all the weekends that I'm going to lose to this validation. And this economic trade-off, I don't think blockchains have solved this economic trade-off for a thousand validators. Even with Cosmos, the 60th validator does not make enough money to justify their effort they're putting into validation today. So somehow there's this economic barrier that would prevent a system from going to 10,000 validators today, in my opinion. What's the slashing percentage in Cosmos?

5% for double signing. So I think slashing needs to get to 100%. And then use you guys as investors in Solana, if we have 100% slashing. How many validators are you going to distribute your investment to? You mean that would lead to more distributed, like people would kind of split over more validators? You have to. And validators like you guys will run more nodes.

I think what I want to see is operationally, you have separate nodes, geographical location, and that separate humans have access to the keys. Like you have some firewalls operationally between those. And building out those processes and launching more nodes will be worthwhile because the market will demand it because investors, even like a small network $200 million market cap network

that's $200 million for the value how many knows would you distribute it to if 100% it can be slashed right I think the economics there I think will work out because I think what we see now is that like the top 20 validators and Cosmos have like

80% of the stake right for what I can tell last time I looked that's kind of the problem there definitely I think the whole economics around proof of stake is a very interesting and largely unsolved issue also of course with the challenge of like exchanges coming in and staking and allowing trading at the same time so i honestly think that 100% slashing will push exchanges to stake across

the network too there's no way binance wants to have a nag in their face that all of their users tokens can slashed from one bit like from one issue of their validator right there's no way Yeah, it's a good point. Absolutely. And if it happens, then they, like, that's their fault, right, for not being decentralized, right? I'm really excited if, you know, Solana goes ahead and you guys are going to have 100% slashing penalty. Not from day one. It's, I think, so we need, like, soak time.

And I think Cosmos folks as well, I think that's why we don't have 100% slashing on networks. It's just, it's just brand new code, right? We need some time for it to actually run out there and see what the bugs are that cause these accidental slashing or operational failures. I think in these initial days, a lot of the folks that participate in these networks are, you know, they're cooperative and non-adversarial. We want to make sure that when there's operational failures that we can recover from them and fix them, and then people can have, like, high standards or how they run these things. Yeah. I mean, if you do want to have, you know, start low and go to 100% over time, I do think you have to basically kind of like program it in from the start that like, you know, automatically maybe it goes from 5% in the start, you know, every month it goes up some amount.

Because otherwise, you can just have, you know, it's almost like a parameter choice, right, that's there from the start, you know, it's like in Bitcoin, you have your block reward and the happening, you know, you can have a doubling of the thing at some predeterminate. and schedule and then, okay, you can change it, but it's always a question where is sort of the default, and it's hard to move from the default. So that's like an on-chain versus off-chain governance thing. We have a very firm governance model. We have a motto, which is optimize everything about the system that doesn't sacrifice performance. So the direction of where the project is going is based on that. How do we make any parameter better

as long as it doesn't sacrifice performance, meaning that everything maximizes performance? performance. And so how is that related to governance? So you're suggesting is we encode this kind of increased lashing percentage on-chain, effectively making a kind of an on-chain governance decision that is programmatically encoded in there versus us just having an off-chain governance model where everybody knows that that's what's going to happen. And the reasoning for that is because it maximizes decentralization. Yeah. Which is, I think, works just the same, right? Because part of these networks is not just the tech, it's the people involved, right? And if this is what we're saying every day, then the community we're building around us is that community that believes in it, and that's what will happen.

Because even if we encoded it and there was a misalignment between the community and the code, they would just, you know, they would remove it. It's not like that would be too hard to change that contract if all the validators really wanted to. Yeah, no, that's a fair point. Well, so what Solana has done knows that basically sort of took the blockchain, right? You took kind of a smart contract blockchain and then you kind of went through like every part of the system and says like, okay, how can we optimize that? How can we optimize that? How can we optimize that?

How can optimize that? And then what you've ended up with is a system that really looks very different, right? There's a lot of these innovations and novel approaches to like lots of different things. So it makes it not easy to wrap your head around. I think one of the things that's particularly interesting is the consensus. So we will dive into that in depth. There's a bunch of other stuff that you're doing. You know, we can maybe speak about a few of them.

Like one is this thing of pipeline VM, right? Can you talk a bit about that? I think it's about paralyization as one feature. When you're dealing with operating systems, when you have this distinction between user space, which is where your regular programs run and the kernel. And when you transition between the two, you pay this penalty.

Because the kernel doesn't trust any of the data from user space. It needs to do a bunch of verifications and kind of also guard itself from any registers, any memory that's coming out from the user side, right? There's this transition between user space to the kernel. So how operating systems deal with this problem is bashing. So when I make a system call

and I need it to be high performance, I send in a bunch of memory at the same time, and the kernel does a bunch of these operations in a row. So only pay for this penalty once. So that's kind of this very simple technique. It's also kind of, if you can expand that into something called DMA,

where you also do, you reorganize the memory, and you can know ahead of time which memory is going to be rud, and which memory is going to be written. So if you know that ahead of time, then you can flush some of the caches and clear out some of the other ones

such that when the memory comes back to the user space, that all those operations can be done in parallel. Like I have a remote device, right? Like the GPU, user space sends me a program. Hey, go run this in the GPU. In parallel in the kernel, I clear out memory and then send the job to the GPU. The GPU does its job.

By the time it comes back, everything's ready to go. So those techniques is what you kind of just do as your bread and butter to make things faster on your mobile phone or desktop or server. So that was actually my job for like 10 years. It's working in that layer. When we built this thing, the natural thing that I did was design the transaction format such that it can tell the chain ahead of time. Hey, I'm going to do a bunch of instructions,

execute a bunch of different contracts. and I'm going to read all these memory locations and I'm going to write to all these other memory locations. So that's our transaction format. It's a vector of instructions, hey, I'm going to run these contracts. And to execute them, I need to read this memory from the state machine. And I'm going to commit these results to the state machine.

Once you have that, you can look at a bunch of transactions and basically analyze or find all the ones that don't read and write the same memory. So you have a million transactions, you sort them by the memory addresses that are going to read and write. And all the stuff that doesn't collide, you execute all of it in parallel. And you have this guaranteed isolation. And that's really like very kind of standard approach to optimizations and operating system. That's their way of optimizing our virtual machine layer. So pipeline VM is this, we call it really the runtime, pipeline runtime.

And I think we're going to brand this whole thing and call it C level because we're in an alt-be. each themed. And the goal of it is to run arbitrate transactions as many as we can that are language agnostic in parallel. So this runtime allows us to hoist additional virtual machines. Like we just Libra released Move and it's a kind of cool language. So we ported it over. It's just Rust. So we can run move transactions in parallel alongside Rust C++. And we are agnostic to the language that's executing. All we really care about is that this format is so explicit about everything an instruction or transaction is going to do that we can analyze it and execute everything in parallel. So let's say you have these contracts there written in the MOOF thing, right, that Libra released

and some are written in some other language. And they can all talk with each other as well. They're all fully interoperable or are there limits on that? So the way you would do this is you would kind of use a balance. buffer is that you'd call a MOVE program and then you can read its state from the native rust code. You can read the state of everything. And then you, you know, you copied over and converted from MOVE into the format that your EVM contract is going to expect. And then you pass that memory into the EVM. So that would be an approach to do that. And you can do this all atomically because transactions are atomic. You have an instruction vector that says, you know,

run some move stuff, do some memory formatting and the data, then pass that into the VVM, and that does the state transitions. And what's cool is that the virtual machines are not loaded by us. They're user loaded. So Move is compiled into effectively a shared object and elf. And that elf is loaded into Solana as Berkeley packet filter bytecode. That bytecode is marked as executable. Now you have a virtual machine. And you can do the same thing with And us as the company, all we're working about, you know, us as the project, we're just trying to make that faster, but we don't really care what languages are run on there. So it's a multi-execution environment that's user like self-serving. If you want to run Python, there's a hundred different Python implementations that would work well in an embedded system.

So you can load one of those. yeah so just trying to translate the the key insight here so maybe the one way to imagine this key insight is in ethereum you have the state right you can think of this the state as you know the quote unquote the ledger it's the state stores what account has how much balance and what code that account runs if it's a smart contract and and things like that. And so the state it stores this data for each of the accounts in the

Ethereum system. And so maybe you can start to think of this state as some kind of like chessboard. Like a normal chess board is 8 cross 8. You don't need an 8 cross 8. You'll probably need a massive chessboard. Maybe 3,000 cross 3,000.

And maybe like each square on that chess board corresponds to some part of that state. So maybe the first square correspond to account one and it stores the balances and code of account one. The next square stores stuff related to account two and so on. So each of the squares of this massive chessboard, a storing data corresponding to a different account.

Now in Ethereum, the nature of an Ethereum transaction is that when a transaction comes in, I as a validator cannot predict which, so any transaction is going to alter some squares, the data in some of these squares. But as an Ethereum validator, when a transaction comes in, I cannot predict which of these squares on the chess board this transaction is going to alter. But in Solana, somehow when a Solana transaction comes in, I know which part, which square, which part of the state this transaction is going to alter. And I can do that for each transaction that comes in. So if a thousand come in, I know that these thousand impact different parts of the state.

they impact different squares. So essentially, if let's say transaction 1 comes in and it's impacting square 10, then I can take transaction 1 and I can take that part of square 10, and I can ship those two to one element of the GPU. And some other transaction, transaction 100 comes in and impact square 100. I can ship those to a different element of the GPU. And these two elements of the GPU can process these two transactions in parallel, whereas in Ethereum, because you cannot predict what squares the transactions are going to impact,

you need to do all of them serially one by one. So databases do this technique. They've been doing this, I think, since the 80s, right? This isn't like new. You can't actually predict what addresses, what state Ethereum transactions will touch. And it's a very simple way to do it. You just run the Ethereum transaction locally in your client, and then it gives you all the addresses

it'll read and write to and you submit that along with the transaction. So you can kind of optimistically guess that the state of the system will kind of remain the same and you submit this data alongside of it. So you pay a bit of bandwidth for this parallel execution.

Yeah. So the neat thing here is because A, first of all, you can execute them in parallel, but then, of course, when you can execute things in parallel, you want hardware that is designed to efficiently execute things in parallel. And that's not the CPU, that's the GPU.

Because in CPU, you might have only four codes or eight codes. So you can execute only those many things in parallel. But in a GPU, maybe you can execute thousands of things in parallel. As long as they do the same thing. So there's a caveat with GPUs. It's not a free launch. So you have 60 threads that can take different branches. GPUs, you basically have 60 different threads and each one maybe controls 80 different

SIMD lines. So each thread can execute 80 different things, but all those 80 different things have to do the exact same thing. So for example, like if we're running a decentralized exchange in Solana, what does an exchange do? I send a price, right? There's memories loaded for the current price. It compares against the price that I just set, right?

And there's a branch. And then it sets whether I've won the bid or not. But all the exchange transactions do the exact same thing, right, just over different memory. So a kernel like that, you can load it on the GPU and then you can process on every different thread. You can do 80 price updates at the same time, right, on every cycle. So that's really the power of the GPU is that when you have, like, contracts. I don't know what people think of what is the contracts, like that they imagine will run on chain. I think the way people design the stuff is it'll be the smallest amount of code in the system will probably run on chain.

So it's not going to be complicated. It's going to be a couple branches, maybe a cryptographic operation and one or two memory updates. And those kinds of things, if there's a spike in usage, like this crazy crypto kitties spike that everybody wants to breed their cats, we can run all of those, the exact same contract on GPUs in parallel at the same time. So what the GPUs help with is in some sense burst capacity. So when there's a very successful DAP on Solana and suddenly you get like 10,000 transactions a second for that particular DAP and all of these transactions, the internal logic of all these transactions is kind of shared, then you can in some way ship the internal logic to the GPU and execute these 10,000 transactions in parallel GPU. So that's what gives Solana burst. Yep, which is really cool because then you have this like compute capacity for the most important use cases, right?

Like the most important use cases can actually scale higher. And everybody else that's participating in the network is sharing the same security that's coming from this, right? So I think it's a really awesome, powerful thing to have in the system. So that's not done yet. DPP offloading is not done yet. But pipeline VM, that's totally done and that's running. And you can go run move contracts if you want to, alongside a Rust. And if you want to help an EVM, we're starting kind of the work on that.

So just in terms of performance, right, I think you guys have in test nets now, what is it sort of 100,000 or a bit less? We can talk about like the design. In a configuration where we don't rotate the block producer, we could saturate an 800 megabit switch, and that was going about 200,000 TPS. When we added fault tolerance and rotation, that's when performance took a hit.

So I think right now we're seeing about 50,000 on our internal networks. And we've been doing dry runs. You guys have participated in four dry runs, I think, so far. The next one will see if those numbers hold on the open network. Let's talk about what's one of the most interesting aspects of Solana and one that's not easy to wrap your head around, which is the consensus layer. So one of the key ideas that you seem to have there is this idea of having a distributed

clock. And I saw there was this quote, I think it was in an article or a blog post, which is that one of the most difficult problems in distributed systems is agreement on time. So can you explain, first of all, why is this so valuable to have this, you know, that all of these different validators have a kind of shared agreement on time? And why is it difficult to do this? Like in a distributed system where people trust each other, it's not that hard. So people can use like an atomic clock like they do in Google for Spanner. They just synchronize atomic locks by hand. Not by hand, but with trusted engineers that make sure that they're synchronized. Or you can use a time server like NTP.

But the problem is when you have a system where nobody trusts each other that we don't have a common source of time. And when you have two different watches, you never know what time it is. And if there's an opportunity to be malicious and lie about time, then you can't really trust the submiters' clock either. So the way that like Tenderman deals with us, and correct me if I'm wrong, if this is like the latest design, but tendermint receives messages, and if the time in those

messages is marked ahead of what I think the real time is, I queue them up, right? I basically wait to process those messages until my clocks get to the point where whatever the time stamp in this message is. So this introduces delays, obviously. And you may think that those delays are not important, but where these delays start having an effect is when you're trying to make sure that the system has the most kind of fastest possible response, right? That means consensus and messages and state transitions between all these validators have to occur as fast as possible. You know, Tenderman, I think, is what, three second block times, right? If I'm correct. Depends. On Cosmos, I think right now it's like five or six seconds. There are some

tenement networks like Lume and Binance that I think are running with like one second. Okay. But the notes are typically like collocated, right? Not collocated, but a few notes. I think in the Lume case, you have around 25, but they're still globally distributed. Okay. So we're trying to cut down our time to 400 milliseconds and lower, and that's when those things start making a huge difference. Is if any time, like our clock drifts is, you know, 50 milliseconds, that's extra 50 milliseconds that every state transition has to pay in. the network. And that means we can't start sending data ahead of time. One way to think about clocks is just from that approach is how fast can the system respond if, and that's going to be based on the air between all the clocks and the network, the drift. The other way to think about it

is the classic problem in Bitcoin is like block production, right? How fast can we produce blocks? and that's based in this difficulty adjustment where you have a node that can come into the network randomly every 10 minutes and because 10 minutes is such a long time there's a lower probability of two notes trying to produce at the same time. So you're kind of creating this very slow resolution clock

where you get a, you know, the second thing ticks once every 10 minutes. Right? Your smallest resolution is 10 minutes effectively on average. So imagine, like, you know, first time people started building radios and radio towers, two radios transmitting over the same frequency at the same time, you get noise. The radio waves collide in the air, and they interfere with each other, and nobody can understand what the transmission is.

That's the exact same problem as with Bitcoin, two block producers produce at the same time. Nobody knows what's the fork, right? What is the actual best fork right now? So how people solve this with radios is they synchronized clocks and then alternated based on how well those clocks were synchronized of when somebody can transmit. So if we had like, let's say, one second resolution clocks, right, we could rotate like once every two seconds. So I get like, you know, let's just make it simpler. I get every odd second. Brian gets every even second every time we transmit.

The data doesn't collide in the air, right? there's no interference, and everybody can hear our transmissions. So we now have scaled the number of participants based on kind of this one second slot. So you can have more notes transmitting, more block producers. Because right now with one second resolution, right, I can fit 60 block producers in a minute. 60 different notes can be the block producer and transmit. And that's kind of the importance of clocks for our specific system is that, we're trying to rotate leaders every slot, and a slot is 4 in a milliseconds.

Right now, the best we can do is rotating them every four slots, so about 1.6 seconds. Underload, right? So imagine you have one block producer every 10 minutes versus, I don't know, this is 600 block producers in those 10 minutes now. Which system has, like, more censorship resistance, right? the one that there's 600 nodes that get a chance to add transactions are only one. Okay, so the idea of rotating leaders often is because you think that makes the system more censorship resistant. It's actually, the main benefit of it is responsiveness. When a user submits the transaction, in a 4.2nd block time, we get a confirmation for this block.

and then the application can take action. And with one confirmation, we can actually calculate a very high probability that the block will be confirmed fully by the network. So the way I tend to see this need for very small block times and therefore a clock is, you know, like it harks back to what we talked about earlier in the podcast. So earlier in the podcast we talked about,

we imagined this person with a home connection. of 100 megabits. And we said, well, with 100 megabits, you can get 50,000 transactions into your node. Now, you need a way of processing those 50,000 transactions. Now, if you look at Bitcoin,

what's the nature of Bitcoin? So if I have one of these nodes, I might get a block. And then I might spend, my machine might spend something like 200 milliseconds or something like that, to process that block, validate that block.

And then, yes, my A6 are going to mine, but then this machine that is like processing transactions, it's going to wait 10 minutes to hear the next block. And then 10 minutes later, it hears the next block and then it spends 200 milliseconds processing that block. So if you imagine the utilization of this machine that is processing transactions, it's like it spikes up for 200 milliseconds, then goes to zero, waits 10 minutes, sits there idle, and then spikes up for 200 milliseconds and then sits 10 minutes idle.

So if you have a system like that, on the one hand, you are getting 50,000 transactions a second, yet you have a transaction processing system in which most of the time the transaction processing element is sitting there idle. So what you want is a system in which the transaction processing element never sits idle. it's almost a system where it gets a block process it for X time and maybe has a short delay and then gets another block process it for

X time and it's nearly at 100% utilization. The machine is always thrashing, trying to keep up with all of the transactions that are coming in with the bandwidth. That is Solana. In Solana that's the nature of a validator, right? So

every 400 milliseconds it's getting a block and so my machine shoots up to 100% performance, 400 milliseconds, 400 milliseconds, it validates the block. But then as soon as that block is done, maybe in 20 or 30 milliseconds, the next block has come in. So the utilization again shoots up to 200%. So the machines are always at like full capacity.

That is the thing that you're trying to do by like shortening down the block times to 400 milliseconds. And I mean, actually having a larger group, right, if you have 600 block producers over 10 minutes, you do have more censorship resistance because there's 600 block producers that get a chance to encode transactions. It becomes much harder to censor any particular client. And the need for the clock in this system is that because these leaders are rotating so quickly, it's almost like, let's say there's like, you know, Anatoly is the leader first

and then Brian is the leader second and mayor is the leader third. There is an inherent problem in this system where, like, when does Brian know that he has to produce? Brian needs to know when he has to produce. So in Bitcoin, the when is obvious. It's like when you receive a block from a different miner with the right proof of work.

That is when I have to try to produce. in tenderment, the when is like when the previous block has been confirmed, that is when I need to try to produce. So the question of this when is dependent on the consensus algorithm. When the consensus algorithm finalizes something, that is when the next person in line produces something. So Brian needs to wait for the consensus on Anatolius block

before Brian can produce. And so this introduces delay between the production of two blocks. invariably will introduce delay. And what Solana appears to say is that Brian should be able to produce without there being consensus on Anatoly's block. But in order for that, Brian needs an accurate clock.

If we could give Brian like a sub-second clock. I don't want to say accurate. I think that the challenge here isn't that Brian needs an accurate clock. Brian needs to convince the rest of the network that he's actually waited the correct amount of time. So Brian needs to provide a proof that time has passed. And that's where a clock comes in, is that we don't have like an NTP style clock or like an atomic clock

where everybody knows the time. What we have is a way to prove that time is elapsed. And can you explain why is that the important part? Like, why is this proof that time is elapsed so valuable? Right. So if I'm taking too long to produce my block, you don't have to wait. You simply prove that you waited the appropriate amount of time,

and then you submit yours to the network. And the network verifies that proof, and then takes action on your block immediately, that it doesn't actually have this delay of waiting, like, hey, did the appropriate time out actually occur anywhere in the network? It simply just validates your proof. Right. And if you compare that to tenement, right?

So in tenement, you have this whole communication, right, at the end of a block, the proposal sends the block and people have to vote on it and commit. And, you know, let's say there is a timeout or like it's too late, right? Again, you have to kind of have this round of voting on it. Whereas in Solana, because I can prove I have waited that long, I can just move ahead and there's no need to have these rounds of communication around that. Yep, exactly. And so let's talk about how this clock actually.

actually works. This was like my 2017 fever dream. I had too much coffee and it was like talking to like the front of mine that we were building this like deep learning thing with about, you know, proof of work sucks. It's mining. It's using all this horrendous amount of energy. But it has this amazing like feature to it that it's based in a real world physical constant. That's physics, right?

It's amount of electricity is bounded by the physics. in the universe, right, and the world. And it's really, really cool, that that is the civil resistant mechanism. And we're trying to figure out, is there another physical constant that we can use? And we kind of started thinking about time. Like, okay, so time is one.

Can you build something like single threaded mining? So that's when I had like, I had too much coffee. It was like, end of beer and it was up to like 4 a.m. And this like weird alpha state. And I realized that you can build a regular recursive shout to 56 function, then it'll generate data structure that represents the time has passed.

You have shot to 56, same as proof of work, Bitcoin proof of work, and you use its output as the next input. So because it's recursive, you can't predict any other future states, but if you sample it, if you just simply record,

count one million, it was state X, it count two million, it was state Y. You generate these samples, you have a data structure that represents time passing somewhere for somebody,

and you can verify this data structure faster because you can take the start and end of every sample and run that shout to 56 recursively, but you can take all those samples in parallel, right? So GPUs or your phone have like over 1,000 SIMD lanes these days. So my phone has over 1,000 SIMD lanes. GPUs of 4,000. So one second can be verified in sub 1 millisecond.

Right. And so in a way, the interesting thing here is that in Bitcoin, right, I'm a miner and I'm trying to find a block. And I basically have this input of the block data, right? They add some sort of random nonce. And then I'm trying to create a hash, right, that has enough zeros in it. And so I can do that in parallel, right, like on a million times, right? So I can have this huge farm that all does the same thing, right? in parallel. But what you guys are doing is, okay, I'm doing this once and I'm using the hash of that

and as the input for the other thing. So obviously you can't paralyze that, right? Because you have to sort of, you know, build on top of itself. But then when it comes to the verification of it, let's say you have these 4,000 iterative loops. In the end, what you have to verify is every single sort of jump from one to the next, right? So if you can just verify all of the individual jumps, then you know that the entire history is correct. So you can basically take that and split it up. So what you do is you paralyze the verification, which in Bitcoin you don't have to paralyze

because there's only one hash you have to verify. But the production, you cannot paralyze. But in Bitcoin, the production is exactly what you paralyze. So it's almost the exact opposite of Bitcoin. Yeah, that's a good explanation. So a verifiable delay function is a set of algorithms that do this. Technically, I think ours is not in the family of, because the same amount of computational power is necessary for verification as generation.

So more sophisticated VDFs have these cryptographic properties that allow the verification to be maybe the log time of verification computationally. But they have tradeoffs. So our VDF, or if you want to call it a VDF, I just don't have a better acronym. The delay function we can verify at DFV. is probably the most secure construct because it's based on the pre-image resistance of shot to 56,

and it requires no trusted setup, and it's just guaranteed to not be parallelizable. So it is very, very simple to think about and code around with because things with trusted setups and those more complex cryptographic configurations are just, they're hard, right? This is just brand-new research

that's still in the white paper stage. and I would love to switch to those when they're ready. But what we have right now is just works really, really well. Yeah. And then I guess the sort of idea is that because, you know, the existing hardware is pretty good at Charlotte 356 hashes. Yeah. The system sort of works, you know,

even if somebody is a little bit faster than others, but maybe you can explain that a bit, right? Because in the end, you still have differences in the speed that these hasches, these chains are generated. So how can he make a kind of a global clock when there exist these differences? So Intel and AMD defined shot to 56 in specific instructions for the AMD 64 platform. So Thread Ripper has shout to 56 specific instructions, which perform a round of shout to 56 and 1.75 cycles. and the speed of the cycle is really based on the cure in manufacturing process.

So we get out of TSM or Intel's FAB. So no matter what ship you have, you basically are bound by the speed of this physical process, right, this physical bound. And because these are hardware instructions, they're basically running as fast as possible. So Justin Drake from Ethereum research and I have argued about this, but we disagree a bit. my view is that the high-level way you can think about it is Bitcoin is like the driving force to optimizing Shoutto 56. So it's optimizing for a slightly different thing, right? Performance over power.

So you're trying to get the most dollars out of your electricity. If you had a Shout to 56 instruction that ran faster per power than Bitcoin, then somebody would take that setup and use it in Bitcoin, right? So what you have with Intel is shout to 56 that does one round and 1.75 cycles. If you could speed it up by 10x, that means that you're driving 10 times more power through this circuit. And that is like a physically impossible thing to do right now. It may be possible, but you have to design something that is super esoteric,

optimized for cooling and extracting heat out of this thing, and any trade-off you make in space, you make those trade-offs with time because the shortcuts get longer. So it's, I think, a design that would be super, super hard to pull off. And the way our consensus model is set up is that 10x speed-up doesn't really get you anything. So we are not worried about an attack vector

coming from a faster ASIC. But we're more concerned is that we want the network to be somewhat homogenous on the speed of the shot to 56. So we would like everybody in the network to have CPUs that have those hardware instructions because then they all roughly run about the same time and then the network behaves well.

In terms of when messages are delivered, they're delivered on time, like on real time, right? In some sense, like in a production Solana network, it's like you have a bunch of validators and they're saying, hey, this is the CPU I'm running and you know how fast do the clock. Maybe in the beginning, I did the start of it,

different CPUs, but over time, they're going to naturally synchronize around the same speeds. And every two years, as TSM improves their process, everybody will upgrade, right? And we get more performance, and the clocks will basically stay about the same speed. And clock speeds haven't really changed much in the last, you know, like 10 years. So that's like something that is really, really hard to optimize. How do we make a faster clock chip isn't on anyone. It's just not something we're seeing improvements on.

And so now, okay, so these validators, at least the honest validators, which presumably is actually a high percentage of the network, end up synchronized and we have synchronized law. But then an alien from Tau SETI comes to Earth and they have 100x faster hashing, and they get 5% of the voting power. What could they do?

So here's the thing, is we would have to jump into how tower consensus works, but basically they could potentially censor the previous validator, or maybe the previous two, but really no more than that. And they could try to propose blocks that censor the previous validator. They basically generate a proof that they waited the appropriate amount of time, but because their ASIC is so much faster, it means that they didn't. From the perspective of the client, they will see the network behaving exactly the same way, right? Because blocks are generated at a high rate no matter what, so they submit a transaction gets encoded.

Clients don't see like real-time drops. The previous validators that this producer censoring will see a reduction in reward because they're missing the reward that comes from being a block producer. Right now, we burn half of the fees and the other half goes to the validator. The reason we burn half of the fees is partly for this attack vector, that burning the fees basically rewards everybody in the system, right? And it's our secondary fork choice rule that if you try to produce a block that is contentious, like in this case, right, Brian outran Anatoli. I'm still producing my block, but Brian is a faster ASIC. So now we have two concurrent blocks. So how does the network choose between mine and Brian's is based on the amount of weight that

each block is proposing for consensus. And the secondary choice rule is how many fees are burned in each one. So that's how we're able to do that determination. So is this censorship attack vector terrible that we should stop what we're doing? I think we'll figure that out as we go along. From my perspective, what you're censoring is a small number of rewards because every block has a very small amount of rewards, right? and for Brian to be effective at this attack,

he has to reveal what he's doing and do it for a long time. And therefore, everybody knows that Brian is a faster ASIC and the network can respond. We can then take action. It makes sense. There is a whole other part to the consensus,

which is basically people are valid sort of betting on the forks or like on which chain will persist. Yeah. So the problem with consensus, right, is that you receive a block, and 400 milliseconds, you have no clue what the rest of the network thinks about this block, whether they're going to vote in it or not,

or they receive all of this data or not, right? And you have to make a decision, do I vote on it or not? And if you make the wrong decision, then you pay a penalty, right? Because maybe you're now in a minority partition, and if you would have waited a little bit, you would have seen the real, like, the better block that the network is voting on. So how we deal with this is that whenever you vote, you have a small commitment to safety. You know, cap theorem is safety versus liveliness.

Like, there's always a straight-off. When I vote on a block, I commit for two slots worth or two blocks worth of safety that in the next two blocks, I will only vote if those blocks are children of this current block that I voted on. If they're not children of this block, then I can't vote. and then I can be slashed if I do so. But every time I do this vote, all the parents, all the parent votes, they double in their commitment to safety. So that commitment doubles, and that's an exponential curve. So after 32 votes, right, 2 to the 32, at 400 milliseconds, it's 53 years worth of commitment to safety, effectively infinite.

Because there's no way I'm going to stop my node for 53 years and then wait for an alternative fork. and switch, right? That's effectively how our consensus mechanism works. It's this very small amount of risk for any decision that you currently make when you have zero information, but then that risk increases as you get more information from the network, right? Because as you see the future blocks being produced, all those blocks contain votes that are representing everybody else's commitment to safety in the network for all the parents. And that's how you make progress. right. When I choose to increase my commitment from like 10 minutes to 20 on any particular block, I want to make sure that the rest of the network is at least on, you know, 10 minutes or 5 minutes.

Like I configure some threshold where some threshold function that I observe the rest of the network is on 5 minutes, therefore I go from 10 to 20. Yeah, so you almost have this kind of like a shelling point, right, where you say, okay, we're trying to agree on a particular block. And if I'm sort of early and I say, I think it's going to be this block, right? Then I earn a little bit more money. And then if other people see that and they follow that and then everyone follows that, then very quickly, the cost of changing your mind is so high that you know this is going to be the block.

Right. So that's great. So let's talk about, you know, a little bit more on the high level stuff. So what you guys are trying to do is create a smart contract blockchain with, you know, huge amount of capacity. And so, of course, one of the interesting thing is, and I think I read this in the multi-coin blog, they had some nice articles.

So they phrased it like, okay, Solana creates abundance where there is currently scarcity, which is this trust, minimized computation. So we were thinking about this, Maheran and I, we had our company retrieving. My thing is, okay, let's say you wanted to build on a smart contract chain today.

Like, what is there? There honestly is almost nothing, right? That's currently live out there, proven works, right? There's Ethereum and obviously there's an overcapacity right and struggling. So, but, you know, many people working on this on bringing more capacity online. Let's say you guys bring a huge amount of capacity online. I'm curious is, is the idea for Seoul, the Solana token, to kind of accrue value because people needed to pay for transaction fees. And if if the supply of transaction space is so massive, doesn't that kind of mean,

the fees are going to be really low? That's honestly that is like an unknown. How does a token accrue value? I don't know. I think that's like a fundamental problem with the space that maybe will be the first to break it and then see what happens.

And like I think better economic models need to be built. This is kind of how I think of it on the high level. What we're trying to do, right, is build a network that basically scales up with bandwidth. And the scary part about it is

that you run your home node, let's say it's 100 megabits, and your steady state, maybe that we're widely successful in the network is doing 5,000 TPS, steady state, right? That's the crazy amount of transactions, honestly, right? That is absurd amount of transactions right now

for crypto because of how small the space is. And all of a sudden there's a spike that requires, you know, 200 megabits. You can switch to a cloud provider like within seconds, right? And then process that data and then come back to your note. You can just scale up on demand. So the costs of actually running the validator are going to be the lowest cost possible, right,

for the steady state, with spikes up to the more expensive hardware when you need it. But the price for the fees are going to be based on the maximum capacity of the network. Because if we can actually handle two, 300 megabits, then that's what the fees should be priced at, right? Because we want to fill it up. So effectively, there's this almost like, two, forces pushing at it, that it's cheap to run the hardware. So the barriers to entry, if you do the software right, like if you do the auto-scaling well, are pretty low.

There's the high barriers to entry or the know-how, right? How to run the system is a lot more harder than, you know, running like something in your laptop that is just like a desktop app, right? You actually have to build it, configure it, and do some monitoring, right? So maybe the operational costs are higher. But the actual hardware barriers to entry, I think, are low. and the capacity is high, right? As high as we can get people to auto-scale up

to the best available hardware to them, which is 10-gigabit connections in AWS and Google Cloud, right? There's nothing we can do to stop people from doing that. So what does that mean is I think fees can be basically at the lowest possible point above spam. So how does the value accrue into the token? I think ultimately there has to be a better business model in the space for economics in the network that depend more on the volume of what's actually being done on the network.

And I think part of that is going to come from basically program stakes being treated as collateral in DFI applications. That this underlying collateral that's right now driving the security of the network, that can't be just stationary and static, right? It can't just be staked and do nothing. We actually have to start using it for collateralizing like BTC channels, right, building all these more complicated applications to where it's being utilized for something more. And then if I have like 10 BTC that's being transferred through Solana, right,

at a high frequency, people are trying to do high frequency price discovery for this BTC, then the collateral that ensures that once the price is agreed upon, that it's going to go through, right? That has to be based on the amount, the volume. And that's where I think we'll start seeing more realistic models. So what you're saying is soul is money. Sure. I don't know, right?

This is like, I have no clue, right? I'm just being honest. I mean, if you look at a traditional business, right? So then a traditional business doesn't try to price things based on, how much does it cost to produce the thing, right? It tries the price thing on like how much value is it is being delivered and trying to, you know, capture a significant portion of that value being delivered. So if you think of this as a, you know, blockchain network, I mean, presumably it could do something similar, right? Like, let's say the Salon is able to process transaction at,

you know, a thousandths of a cent, but there's no good alternative when people want to use that system and, you know, it's secure enough and people are willing to pay a hundredth of a cent, you know, then there could potentially be sort of revenue captured that way. Except that at any time, people can take our open source code and our community of third-party validators and tell them to run Solana X, right? Sure. Solana Classic. So effectively and like get everybody to switch, right?

if the businesses that uses have a cost associated to them, that's so high that it's above that threshold, then they'll switch. Well, you can say, I mean, if you look at Ethereum today, I mean, you do sort of have that situation, right? You have Ethereum Classic, which is, you know, technically, I think for the most part, probably equivalent network, but with, like, much more throughput available. And, okay, it may not be a secure,

but you do kind of have that, but people still building on Ethereum. So I think you have certain network effects. that's still difficult. I think the markets basically will decide if fees can be in revenue or not. I don't know. Honestly, my perspective is, again,

our goal is to drive the fees to the lowest possible point and then build up the next generation things because I think those are more interesting. Because the cost to hardware is so low, right? And as soon as we solve the software, like problems that make operations, low, that that also becomes cheap.

And then, like, if we have this, you know, amazing state machine that's globally distributed, that is as cheap as possible for trust minimizing computation, then let's do cool things there, right? Let's see, like, how far we can actually take the space. So to me, that's kind of my dream. Obviously, it's a open source project with an open community and, like, a lot of input from a lot of different people with their own, what they want to do. but at least for myself, this is what I'm going to drive.

That's increased capacity to the point where it's ridiculous. Yeah. But I wanted to be absurd how many transactions we can process and how fast we can do it. Yeah, it's an interesting question. It's the question of,

you know, now you have like lots of blockchains with capacity. And if Solana could, like, some way, ensure a monopoly, everybody wants to come here. Then maybe, you know, the optimal might be oh, we use only 37% of the capacity,

but we charge high, and that's the business model, if there could be a monopoly. But then the opposite world is there's so many chains, open source, with different designs, AOI, etc, that it's very hard to secure a monopoly. And then there's like, it tends towards perfect competition. In a perfect competition space,

it will be very hard to preserve any kind of transaction fee levels. and so their transaction fees cannot be a business model. I think monopoly is very hard to build in this space, for proof of stake networks especially. With Bitcoin mining, where you have A6 that are in this community that's really optimized for this one kind of business plan, they have a business, right? The mining, like everything kind of depends on this mining capital investment cycle.

That's very hard to compete with. because you need so much folks to be on board with this new idea. So there I think it's hard. And what they're maximizing is not throughput, its security, which is totally fine, right? Have the most amount of security in a single chain. That's also a really cool thing to have. But with proof of stake networks,

I think you have to maximize utility, and I think the only way to do it is to make it as cheap as possible to utilize. Yeah. So speaking of utilization, one keeps, hearing about plans for a decentralized exchange in Solana. So curious about what your plans are and what kind of decks would you like to build? Because the interesting thing in the crypto space appears to be,

there's not one, but there's like five or ten interesting decks designs. Nobody seems to know which one is going to win out. Yeah, I think there's like, there's kind of two designs that are like, one is ours. And the other one is like TBTC. which is where you have a distributed group that takes custody of assets, and then it can behave like a centralized network with some different security properties.

And that's kind of cool. What we're doing is, like, it's pretty simple. We're on the order book and matching engine on chain. So execution and clearing can occur on chain, right? Your traders can submit price updates at this, like, in a real-time, high-frequency, and matching agents runoff chain, but matching occurs on chain. So you have an auto trail of what things were matched.

So one thing that's very apparent is very easy to do is that you can guarantee that the matching engine will match the first order entered before anyone else or they get slashed. So things like that you can build. Because all the trading is occurring on chain, you have some better properties for an auto trail and better tools for building something that is

more fair to the traders involved. You still have this problem of block producers that can basically censor transactions or insert their own ones ahead of time if there's an opportunity for them to do so. That one is hard to fix. There's some cool designs out there. Maybe we can talk about them. So we actually have a bent that built as part of our GitHub. And there's a bench client that we ran that we could demonstrate like 30,000.

price updates per second. Cool. So I know originally you guys were planning to launch around now, of course, as all blockchain networks, always stays long. So what are the main things remaining that kind of, you know, block or, you know, to get done until Solana mainnet launches? So there's some tail in the stuff that we're working on, which is making sure that when we launch, we have like a secure custody solution for everybody that's been taking longer than

expected. Honestly, I think we should have expected it to take longer because it's when you think about it on the surface, it's an easy problem. But then when you really think about it, it's a very hard problem. Just delivering the tokens to people, right, and having them a secure way to take custody of them. So the custody solution means they're, I don't know, it's one of a company's like Big Go or one of those that they support it? Is that the idea? So that's one of the approaches, but we need to give people a way to do it on their own in a secure way that doesn't involve them storing plain text private keys in their computer, right? And then who do we trust? Do we trust ledger or treasurer or do we do a paper wallet? How does that interface with our command line client that actually does all the staking operations and things like that? So that's one of those things. And we want to make sure.

sure we get it right even if basically optimized towards security there and less convenience because that's more important in the early days and then like start making things more convenient. And the other one is the real delay is so we've been doing dry runs where we fix a bunch of stuff on our Google Cloud-based network or AWS and then we boot with the validator community and a bunch of stuff falls over. One assumptions that we made early on was that we would have high MTEU paths. So we'd be able to send reliably jumbo frames

across the internet. And that assumption was wrong. So we had to go from the assumption of being able to send 64-kilobite packets down to 500 to 1,000 byte packets. So the networking stack is effectively doing 50x more work, roughly, about 50 times.

more work. So we had to optimize the hell out of that. And that's done. So now we want to do our dry run 5 where we want people to boot with GPUs and then we'll see what falls over. And we're going to ramp up the transaction throughput and then see if we can match what we see internally, which is 50 to 60K sometimes. And so what's the goal in terms of the launch date and timeline? I think I'll probably announce the dry run at the validator meeting and like a half hour anyways. So I think it's going to be October 29th. So we'll do dry run 5. And if that works, because we want to launch with at least 50,000 TPS capacity, that we'll do our stage 1 of TDS, which stress tests the network for about a week. And then I think we're ready for maintenance.

So maybe sometime, Q1 probably. I think, I mean, like the earliest I think we can do it is dry run runs fine, right? 29th. And in November next week. we do stage one, that runs fine, and then in the November of the launch. That would be the fastest timeline with no failures. Okay, cool. I'd love to set up an auger bat on the engineering timelines based of blockchain projects. Is there going to be a main net by date X for any team? But we're doing everything open so you guys can actually go to Discord and bug us about what's taking so long.

We can point you to the remaining issues. Yeah. Absolutely. Well, Anatoly, thanks so much for coming on. We've taken quite a bit of time, but I think there was so much to dive into. Yeah, I mean, we were really excited to see Solano go live and to see what kind of will be, you know, how the network will evolve, how it will play out in reality. So, super excited for that. And yeah, thanks so much for joining us. Yeah, yeah, this was super fun. Thank you so much. Thank you for joining us on this week's episode.

We release new episodes every week. you can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy.

happy to read them. So thanks so much and we look forward to being back next week.