Anatoly Yakovenko: Solana – Reaching for the Limits of Blockchain Performance (#312)

Transcript

[Music] hi welcome to epicenter my name is sue best anchor Joe and I'm here with Bryan fatty and crane how are you Brian I'm very good excited to give a little intro about Solana which was an interesting episode and a project that up and you know kind of connect away for quite a while yeah I've been listening to the interview that you and Mayor did and trying to wrap my head around this before we start recording this we're trying to figure out like what will be the best way to explain this and I think

I think we've kind of figured it out so I'll let you run run us through the key points about Solana which will frame this discussion yeah so Solana is really not an easy project to understand so we we have we were introduced to the Solana team I think a bit over a year ago and so when I was in I said I would like work from the Solana office and like hang out with them and had quite a few conversations with them just trying to understand how this works and it is probably the hardest block chain that I have tried to understand maybe the other ones are they're equally hard but I haven't sort of like tried to dig into it into this extent but basically what Solana is

right Solana is building kind of a next generation smart contract blockchain right so they're they're trying to solve the same problem that you know Hume is China 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 in 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 they're differing from you know most of these other novel approaches you know whether it's cosmos or polkadot or a Hume 2.0 or near you know they all have some sort of all

right they all have some concept of in there and so they're different in this way one of the things that we talked quite a bit in the episode that's a sort of key innovation key approach to solana is the consensus and the consensus taft is 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 knows the other violators can kind of afterwards verify those blocks and then come to agreement on what's the

canonical chain but the this consensus process isn't sort of slowing down the network and so that's one of their key approaches and it's very very interesting how they do that too they have this idea of a decentralized clock where basically kind of everyone is running this sort of like a verifiable delay function all about that us to help with that but we'll go into much more detail on that in the episode and and another thing that you know probably and a core approach a core aspect to how solana approaches this problem is through the parallelization of you know smart contract execution so if you if you look at something like a

theorem you know the challenge is even if you kind of speed up the hume consensus a lot you know if if a validator if the full node has to execute all these smart contracts and you know if the EVM that's becomes the bottleneck pretty quickly and so for example in curium 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 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 of GPU cores so that's also one of their sort of one if they're interesting approaches and then they have a lot of other stuff there's something 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 the it's a proof of State Network but then also leverages GPU so the validation doesn't actually happen as like a function of proof of work it happens as stake but the smart contracts are still run on on GPUs and until we also it's just as some disclaimer here right so we have as you know as many of you know my hair 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 out it is in the in the Solana test nets and they are gearing up to something like the cosmos game of stakes thing and you know the 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 you a valid it could run like multiple notes and then have like automated failover so if one node goes down the other one kind of takes on so we have been digging into Solana quite a bit from that aspect and and just sort

of a final disclaimer on that node to which was that my hair and I both participated in the Solana kind of the token sale they both there was a sort of a private token sale so yeah that's this is some 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 gotta say there's still some some areas or 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 you know 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 boxes so everyone understand how these systems work and that's definitely something hard in the Solano case one thing that I hadn't realized is that well I thought that Solana was somehow like a Cosmo 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 brought chain but as you were saying as we were talking about earlier is that it's possible that Solana might be for IBC compatible and could connect to a 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 and different chains I think the main the main constraints and IBC is that a particular chain has some concept of finality which Solana does and that it has you know some kind of smart contract capabilities you know that a lot of point is it maybe doesn't have to be like full 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 out about like clients and that I think that's that's a little

bit underdeveloped today and Solana but yeah I mean it's actually something we've been exploring as well is like okay how would that work so yeah you you've been you're still in San Francisco last week there were 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 defy hackathon so as a question we started last week first with Cesc and then SF watching me epicenter which was later in the week and then the hackathon over the weekend so I got here in the middle of CES see I didn't get much of that but it was more

of the technical conference so a lot more technical talks and in fact the talaq also gave a talk at the very end and then the SF watching week epicenter which was organized by Dieker 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 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 you know speaking remotely but you know it was speaking at the conference there were some you know US Congress people here as well and people from Libra so it was like there's 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 M seeing that conference on day one on the main stage and then day 2 on the second stage so yeah I was I was kind of running around herding cattle as they say getting the speakers to you know line up and come on stage so I was really fun and and then the hackathon was over the weekend I was kind of in and out and yeah I was quite big six

hundred people and that ended last night so it's 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 or what do you main takeaways that my main takeaways are a little I'm a little divided about them so one thing is for sure I mean D Phi is kind of like the big trend at the moment and that was really obvious at the D Phi hackathon and D Phi is no longer just constrained

to aetherium I mean most of the projects were at the D Phi hackathon we're building on the cosmos SDK and so D Phi is growing outside of the etherium 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 we kind of feel that the Crippler winter a little bit although there's a lot of new projects coming out and on the dphi side a lot of innovation happening it's a bit flat at the moment you mean flat in terms of there's no that enthusiasm or oh what's flat yeah the enthusiasm is somewhat lacking I don't remember we were in Berlin once for this inside bitcoins conference

during the crypt of 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 bitcoins conference in 20 in like early 2014 this kind of feels like that little bit although there's a lot more people in this space the ecosystem especially 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 you know we're well accustomed to at this point yeah absolutely you know I've no doubt but the excitement will come back but what's great is that there are you know a

growing number of people in the space and I think once more like tangible use cases start emerging then excitement might come again also I think like the price method makes it it makes a big difference to 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 our unique breed of software because they can hold an astronomical amount of value and as dphi 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 trail fits that have that real security expertise drill bits 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 just was around things like key storage and DevOps and your website and your application and 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 TRO 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 it's 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 drill 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 trail of bits comm so learn more about trail of bits go to the website drill 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 valle Toro 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 a hedging against the traditional financial system in an epicenter we've been friends and clients of volt row 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 dphi 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 Volturi 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 in the thing that I like the most above all Toro 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 vault Rose brand new v2

platform which includes a new interface and trading in - as well as in Bitcoin go to vault or comm and when you create your account do me a favor click a little yellow support icon at the bottom of the dashboard and just let them know that you came from epicentre let's go to our interview with Anatoly so we're here today with Anatoly Yakov anchor who's the founder and CEO of solana so my hair and I we've been following solana for quite a long time we spent favourite of time hanging out in San Francisco at the Solana office working with Solana we 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 on a totally 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 it's I think already when we we talked in the beginning I knew okay at some point we've got to do a solana episode but the challenging thing is explaining Solana is just you know it's it's a challenge so hopefully we will manage it today Solana is a beach in San Diego County but that's the explanation how did you

originally become interested in blocked in a thermal engineer right have been it's been most of my career Qualcomm working on one form of another of a distributed system but really like majority of my life were working on semiconductors like the chip level operating system firmer 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 oh this is just kind of a toy didn't really think too much about it now remember the etherium ICO and looking at the EVM and thinking okay this is more interesting but it's still

kind of JavaScript for for Bitcoin and really missed the whole kind of revolutionary part about it that you once you have this secure computer that's globally available to everybody that you know interesting things can start happening so and around like I think early 2017 I was in San Francisco and uh with a friend of mine were thinking about actually starting a startup or we would mind 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 them crypto at the

time and a way to offset the cost of building out rax the GPUs right is to let people mine it look hurt oh but that's what really started me like digging through the protocols and started thinking about like okay what are people actually doing why scaling such a problem and obviously at the same time 2017 at this amazing bull run and transaction fees were like $60 a transaction or something crazy like that I'm Bitcoin and I started kind of thinking about how did we solve scaling for these kinds of problems that Qualcomm with wire and wireless protocols and that's what really got me like to go deep down the rabbit hole and so I know a lot of people right at the

solana team come from Qualcomm so what's what's Qualcomm like whence special about that place so I graduated in 2003 from the University of Illinois and this was post.com crash so a couple friends of mine were actually at a start-up if you guys ever remember Grand Central Dispatch or vonage so we were building these voice over IP software systems but insult central Illinois Illinois there was like after the.com crash there was zero funding kind of zero interest in like new tack and while we build this really cool thing the project kind of died but turned out Qualcomm was using similar technology stack and kind of hard 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 dump surfing so it was kind of smitten by the the culture there like it was very laid back kind of people if that work there the COS san diego is the beach town there's really nothing else to do there besides you know do yoga go to the beach and like you know I haven't owned a dog but 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 like

crazy evolution if you guys ever remember what phones were like in 2003 - what like iPhone 6 iPhone 8 is like we went from running at a microcontroller basically a 16-bit like single cord 400 megahertz like dinky chip to eight cores like 64-bit desktop like great or server great Hardware with like 20 different subsystems like GPUs DSPs modems all those other stuff all in the same die so it was really crazy basically in ten years every year we had a insane architecture revolution 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 server great computer so you know coming with that kind of background an 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 soft 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 like the whole point of hardware design is you you build

something that can scale up as you add more basically more you know lines to memory more higher frequency to memory and like more area that can be used like 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 they're straightforward they're not designed revisions so the kind of hardware you want to chip is the kind that when you do have cheaper available dies 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 and hard work so because software takes so much longer to build because it's an

it's an iterative process we ship it customers hates it we have to rewrite it like there's like farmer requirements it's a much broader set of api's 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 like 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 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 gonna be faster how do I make

sure that it it gets faster right how do how do I make sure that the software doesn't get in the way the hardware it's gonna one of one of my quotes so when I started thinking about block you know I've already been doing that approach for 10 years so really like the first thing that I thought I was is what what are 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 that's kind of where the design started from you know if you have like one megabit of bandwidth you can stuff about 5,000 transactions in there if you have 100 megabits of bandwidth that's 50,000 transactions right so that that's that you can think of it as is 100

megabits of bandwidth a lot your 4G phones the standard for 40 is point-to-point and it were global e 100 megabits yeah I mean being from India I doubt I debate that point but I have the first project that I worked on we got pushed to talk to work from San Francisco to Hyderabad and I think under 150 milliseconds on this thing that was precursor to LT even it's called a video if I remember correctly so I mean but stating the broader point the broader point is that if I have a hundred megabit connection which I do at my home and presumably many people do at their homes then we could get and 50,000

transactions a second in to our systems somehow all right that's sort of the amount of our system right and so your perspective would be that if we were to be a full node and we're 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 increase the bandwidth would allow that would be the ideal blockchain you could you could engineer yeah that was basically the premises start but 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 fill this as fast as possible because everyone's gonna do the same thing and it would be to like get ahead of them yeah I mean it's interesting you coming from this outside perspective if this completely because if you sort of approach it from like the Bitcoin side right then you be like okay you know there are all of these variances in bandwidth but we almost have to sort of adapt to the the least common denominator right because otherwise they fall behind and in cents is right and I know there's like this well-known pecan developer no Greg Maxwell who lives somewhere in the bush

and he has like a super terrible connection so you know he'll be like no it can't be too big two big blocks he can't mine there and and I you know I guess there was this philosophy there which then carried over to theorem 2 cos basically the same proof of work but of course it's interesting I asked you know it's not 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 yes so the trade-off is definitely that you need those 100 megabit connections every four years bandwidth basically drops in price by 50% so if people think that 100 megabits is expensive now it's gonna 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 then the amount of bandwidth available to the design has what is it eight times more right eight X amount of bandwidth you have two to the sixth so 32 times more compute available to each node when the design started but no like aspect of Bitcoin is leveraging that it's not 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 gonna be what kills it honestly like I think if they're really

focused on going the other direction then kind of like you know build something like bunker coin it's 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 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 a line towards or I would say competing with in a way is the theorem knowing that salon as a full smart contract platform we're open

source projects competing to the death yes there's no such thing as competition in the boxing world I know but if you look at it here iam why do you think are the biggest problems and shortcomings there so I wanna say that like I actually I mean I am a huge supporter of a theory but the theorem fails we're doomed my project is doomed everyone else's projects assume so we all depend on etherium 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 etherium dies because it has so much momentum and community it can't just die for the for failure right it's technology will ship

eventually right so I'm I'm very much hopeful that etherium succeeds and the problem that they're solving it 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 that is the trade-off right is what we're doing is a hard engineering problem you know it's just if 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 cerium and these like near and these other like other Charlotte solutions are trying to build a computer that is you

know you have this massive 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 aetherium you know they're iterating and their designs pretty frequently still it's not like a you know set in stone the number of charge changes that when you have a design that's computer science design and then you try to make it convert that the papers into engineering use that's one like the rubber hits the road and that's you started raining back right oh this is not gonna work this is going to be too expensive you know so that's I think is the main the main

challenge with aetherium but to kind of speak broadly why why is charting such a such a huge trade off 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 Sharks 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 their own weird attack vectors from one from for data availability between shards there's a bunch of really complex algorithms that folks have designed and protocols nobody

knows if they're gonna work right if the incentives are gonna 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 that even needed right yeah I mean any tedium in one of the recent designs they're like 1,024 shards and there are like 600,000 validation slots that that you can all you can occupy and I think like each idiom is targeting the world where I have my laptop and I should be able to put my 32 East on it and go and validate maybe one shard or one-and-a-half shards or two shards out of the e 1024 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 secure across all the amazing right right that's that's like an amazing design go like this is no doubt about that yeah that's an amazing design goal whereas now we done validators at chorus right so we we see the underlying systems of 10 demand and solana at close.i and there the assumption is is different then the world the imagined world is different the imagined world is there's maybe like two hundred

professional validators you can assume that these professional validators will go and source like good bandwidth connections they can they will go and source really great in-depth hardware individually so you can rely on the evaluators to have really performant hardware and really good bandwidth and there's 200 of them that 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 tender main goal and the salon ago yeah so one caveat there is that 100 megabits is not high

powered right that's the home connection right now in your little States data centers will give you 10 gigabits 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 for the transactions is like $5,000 gamer machine like 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 aetherium at home it's kind of typically around that amount so anyone that's mining aetherium can actually mine on solana right and we can have a very large set of validators you know we've designed the software like the the

algorithms to go to 20,000 computers it's kind of in our like kind of designed goal because realistically I don't think we'll see 20,000 computers for like 5 years the best 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 enough money to compensate me for all the weekends that I'm going to to this validation and this economic trade-off I don't think blockchains have solved this economic trade-off for a thousand validators deep even with cosmos D 60 its validator does not make enough money to justify their effort they're putting into validation today so some somehow there's this economic barrier that would prevent a system from going to 10,000 validators today in my opinion what's the splashing percentage in cows was 5% for double signing so I think slashing needs to get to 100% and then used you guys as investors in

Solana if we have a hundred percent slashing how many validators are going to distribute your investors investment - you mean that would lead to a more distributed like that would kind of split of a more regulators and you have to and validators like you guys will run more notes you will actually like I think what I want to see is operationally like you have separate notes 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 its investors even like you know a small

network 200 million dollar market cap network that's 200 million dollars for the value how many nose would you distribute it to if a hundred percent it can't be splashed right I think the economics there I think will will work out because I think what we see now is that like the top 20 validators & Kosmos have like 80% of the stake right for what I can tell west um it looks that's kind of the problem there definitely they I think their whole economics around proof is sake is a very interesting and largely you know 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 - there's no way finance wants to have a mega interface that all other users - against from what the like from one issue other validator right there's no way yeah it's a good point absolutely and if it happens that they like that's that's their fault right for not being decentralized right I'm really excited if you know Solana goes ahead and and you guys get gonna have 100% slashing penalty not from day one but 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 a hundred percent slashing of networks it's just it's brand new code right we

need we need some time for it to actually run out there and see what the bugs are that costs these accidental slashing or operational failures I think in these initial days a lot of the folks that participated in these networks are you know they're cooperative an adversarial we want to make sure that when there is operational failures that we can recover from them and fix them and then people can have like high standards for how they run these things yeah I mean if you do want to have you know start low and go 200 percent over time I do think you have to basically kind of like programming in from the start that like you know automatically maybe it goes from five percent in the start you know every month it goes up

some amount because otherwise you know 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 half-inning you know you can have a doubling of the thing at some predetermined 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 ante and versus off key and governance thing we have a very firm governance model we have a motto which is optimize everything of 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 and so how is that related to governance so very suggesting is we encode this kind of increased slashing percentage unchain 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 gonna 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 attack it's the people involved right and if this is what we're saying every day then the the community were 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 stop like that would be too hard to change that contract if all the validators really wanted to yeah no that's that's a fair point well so what Solanas don't know is that basically sort of took the blockchain what you do it's kind of a smart contract blockchain and then you can went through like every part of the system and says like okay how can we optimize that how can we optimize that how can you optimize that and then what you've ended up with is a system that really looks very different I did 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 and you know we can maybe speak about a few of them like one is this thing of a pipeline VM all right can you talk about about that I think it's about parallelization right as one feature when you're dealing with operating systems when you have 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 like 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 needed 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 like 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 gonna be rut and which memory is gonna 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 that like I haven't have a remote device right like at the GPU user space sends me a program hey go run this in the GPU I in parallel in the in the kernel a clear out memory and then send the job to the GPU the GPU does this 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

makes 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 it did was designed the transaction format such that it can tell the chain ahead of time hey I'm gonna do a bunch of instructions you know execute a bunch of different contracts and I'm gonna read all these memory locations and I'm gonna write to all these other memory locations so that's our transaction format is it's a vector of instructions hey I'm gonna 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 in operating system that's that's their way of optimizing our virtual machine layer so pipeline BM is this we call it really the runtime pipeline runtime and I think we're gonna ran this whole thing and call it C level because we're in an alt beach-themed and the goal of it is to run arbitrary

transactions as many as we can that are language agnostic and parallel so this runtime allows us to hoist additional virtual machines like we just Libre released move and it's a kind of cool language so we ported it over its just rust so we can run move transactions in parallel alongside Russ C 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 they're written in the move thing right Libre 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 bounce buffer is that you'd call a move program and then you can read it state from the native russ code you can read the state of everything and then you you know you copy it over and convert it from move into the format that you're evm contract is gonna can expect and then you pass that memory into the EBM so that would be an approach to do that and you can do this all atomically because transactions are Atomics you have an instruction vector that says you know runs the move stuff do some you know memory formatting and the data then pass that into the VM

and then that does the state transitions and what's cool is that the virtual machines are not loaded by us their user loaded so move is compiled into effectively a shared object and elf and that elf is loaded into Solana as Brookley packet of filter byte code that bytecode is marked as executable now you have a virtual machine and you can do the same thing with EVM and us as the company over working about you know us as like the project we're just trying to make that faster but we 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 are would work well in an embedded system so you can load one of those yeah so just trying to translate the key insight here so maybe the one way to imagine this key insight is in aetherium you have this 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 is this it stores this data for each of the accounts in the in the etherium system and so maybe you can

start to think of this the state as some kind of like chess board like a normal chess board is eight cross eight you don't need an 8 cross 8 you'll probably need a massive chess board maybe that 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 corresponds to account 1 and it stores the balances and code effect on 1 the next Square stores stuff related to account 2 and and so on so each of these squares of this massive chess board a storing data corresponding to a different account now any cerium the nature of an aetherium transaction is that when a transaction comes in I as evaluator cannot predict which so any

transaction is going to alter some squares some detained some of these squares but as Annie's helium validator when a transaction comes in I cannot predict which of these squares of on the chess board this transaction is going to alter but in solana somehow when a transana 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 these thousand impact different parts of the state they impact different squares so essentially if let's say transaction one 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 in 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 Atheneum because you cannot predict what squares the transactions are gonna 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 eighties right this isn't like new you can actually predict what addresses what state etherium transactions will touch and it's a very simple way to do it you just run the

etherium transaction locally in your client and then it gives you the 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 so 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 in CPU you might have only four cores or eight

chords so you can execute only those many things in parallel but in a GPU where you can execute like thousands of things in parallel as long as they do the same thing so there is a carrier but GPUs it's not a free lunch so you have you have 60 threads that can take different branches and GPUs you basically have 60 different threads and each one maybe controls 80 different same D 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 if we're running a decentralized exchange and solana what does an exchange do I sent 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 says whether I've won the bid or not but all the exchange transactions I do the exact same thing right just over a different memory so colonel like that you can load it on the GPU and then you can process on every different thread you can do a tea price updates at the same time right and 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 what is the contracts like that the 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 gonna be complicated it's gonna be a couple branches maybe a cryptographic operation and a one or two memory updates and those kinds of things if there's a spike in usage like this crazy crypto kiddies brief spike that everybody wants to read their caps we can run all of those the exact same contract on GPUs in parallel at the same time so what what the GPU is helped with is in some sense burst capacity so when there's a very successful die upon solana and suddenly you you get like 10,000 transactions a second for that particular depth and all of these transactions the internal logic of all these transactions is kind of shared and you can in some way ship that 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 different use cases can actually scale higher and everybody else that's participating the network is sharing the same security that's coming from this right so I think it's a it's a really awesome powerful thing to have and in the system so that's not done yet TP offloading is not done yet but Plan B M that's totally done and that's running and you can go run move contracts if you want to along side a

rust and if you want to help an EVM we're starting connect the work amount so just in terms of performance right I think you guys have intestine eights now what was it sort of a hundred thousand 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 at eight hundred megabits which and that was going about 200 thousand TPS when we added fault tolerance and rotation that's no performance tikka hit so I think right now we're seeing about fifty thousand 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 we'll

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 this quote I think 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 violators

have a kind of a shared agreement on time and why is it difficult to do this like in a distributed system when people trust each other it's not that hard so people can use that an atomic clock like they do in Google for spanner they just synchronize atomic clocks by hand not by hand but like with into trusted engineers that make sure that they're synchronized or you can use like a time server like NTP but the problem is when you have a system where nobody trusts each other to that we don't have a common source of time and you know when you have two different watches you don't 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 submitters clock either so the way that like tenorman deals with us and correct me if I'm wrong if this is like the latest design but tenements 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 right get to the point or whatever the timestamp 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 rate that means consensus and messages and state transitions between all these validators have to occur as fast as possible you know tender minute 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 lumen by Nance that I think are running like with like one second okay but the notes are typically like co-located right not co-located but a few notes I think in a loom case you have around twenty five but they're still globally distributed okay so we're trying to cut down our time to forty milliseconds and lower and

that's when those those things start making it a huge difference is if any time like the car clocks drifts is you know fifty milliseconds that's extra fifty milliseconds that every state transition has to pay in the network and that means we can't start from sending data right ahead of time one way to think about clocks is just from that approach is how fast can the system responds if and that's going to be based on the error between all the clocks in 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 on this difficulty adjustment where you have a node that

can come into the network randomly every ten minutes and because ten a long time there's a lower probability of two notes trying to produce at the same time right so you're kind of creating this like 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 in the air and they interfere with each other and nobody can understand what the

transmission is that's the exact same problem I was with Bitcoin to 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 synchronize clocks and then alternate it 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 out second Brian gets every even second every time we transmit the data it 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 then right now with one second resolution right I can fit 60 block producers in a minute 60 different nodes can be the block producer and transmit and that's kind of the importance of clocks for our specific system is that we are trying to rotate liters every slot and a slot is 400 milliseconds right now the best we can do is rotating them every four slots so about 1.6 seconds under load right so imagine you

have one block produced every 10 minutes versus I don't know this is 600 block producers in though in those 10 minutes though which system has like more censorship resistance the one that there's 600 notes that get a chance to add transactions or only one okay so said yeah year of rotating leaders often is because you think that makes a system like more censorship resistant it's actually the main benefit of it is responsiveness when a user submits a transaction in a foreign a millisecond 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 is 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 in the podcast so early in the podcast we talked about we imagined this person with a with a home connection of hundred megabits and we said well with hundred megabits you can get fifty thousand transactions into your node now you need a way of processing those fifty thousand 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 like something like 200 milliseconds or something like that to process that block violate that block and then yes my Asics are going to mine but then this machine that is like processing transactions it's going to wait ten minutes to hear the next block and then ten 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 rates ten minutes

sits there idle and then spikes up for 200 milliseconds and then site sits then sits 10 minutes idle so if you have a system like that on the one hand you are getting fifty thousand 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 4x time and maybe has a short delay and then gets another block process it 4x time and it's nearly at hundred-person 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 that's the nature of a validator right so every 400 milliseconds it's getting a block and so my machine shoots up 200 performance for and milliseconds for every seconds it validates the block but then as 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 percent so the 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 clock producers over 10 minutes you do have more censorship resistance because there's 600 block producers they get a chance to incur 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 Ana Tony is the leader first and it binds the leader second and Mayor's 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 deven is is obvious it's like when you receive a block from a different miner with the right roof of work that is when I have to try to produce in Enderman the vein is like when the previous block has been confirmed that is when I need to try to produce so the question of this ven is the on the consensus algorithm when the consensus I gotta finalize is something that is when the next person in line produces something so Brian needs to wait for the consensus on anatoly's block before band can produce and so this introduces delay between the production of two blocks in 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 right if we could give Brian like a sub-second clock so I don't want to say accurate I think that the challenge here isn't the Brian is a cracker clock probably needs to convince the rest of the network that he's actually wait at the correct amount of time sabri needs to provide a proof that time has passed and that's where our clock comes in is that we don't have a like a NTP style clock or like a 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 am if I am 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 which verifies that proof and then takes action on your block immediately but it doesn't actually have this delay of waiting like hey did the appropriate timeout actually occur in your in the network it's simply just very validates your proof right and if you if you compare that to tenement right so in tenement you have this whole communication right at the end of it you know block people 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 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 this rounds of communication around that yep exactly and so so let's talk about how this clock actually works this was like my 2017 for your dream I had too much coffee and it was like talking to like the friend of mine that we were building this like deep learning thing with about you know perform work sucks

it's 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 of the universe right and the world and it's really really cool but that is the 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 like can you build something like single-threaded mining so that's when I had like I had too much coffee I was like and a beer and I was up to like 4:00 a.m. and this like weird alpha

state and I realized that you can fill that recursive shout 256 function and it'll generate data structure that represents a time has passed right to you you have shout 256 same as proof of work Bitcoin proof for work and you used 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 1 million it was state X's count 2 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 256 recursively but you can take

all the samples in parallel right so GPUs or your phone have like over a thousand sim delay ins these days so my phone has over a thousand Cindy Lantz GPUs a 4,000 so one second can be verified and stuff one 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 off the the block data right I 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 that's the same thing but 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 yeah 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 good explanation so a verifiable delay function there's a set of algorithms that do this technically I think ours is not in the family of EDF because the same amount of computational power is necessary for verification as generation so more sophisticated we DFS have these cryptographic properties that allow the verification to be maybe the logs time of verification computationally but they have trade-offs so our vdf or if you want to call it a

PDF I just don't have a better acronym at delay function we can verify DF e is probably the most secure constructs because it's based on the preimage resistance of shout 256 and it requires no trusted setup and it's just guaranteed to not be parallelizable so it is very very simple to think about Indiana Code around what 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 like the book the white paper stitch and I would love to switch to those when when they're ready but what we have right now is just works really really well

yeah and Dana I guess did hood the sort of idea is that because you know the existing hardware is pretty good HR 256 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 hashes these chains are generated so how can you make a kind of a global clock when they are exist these differences so Intel and AMD just defined shout 256 in specific instructions for the AMD 64 platform so thread Ripper has shot 256 specific

instructions which perform a round of shout 256 and 1.75 cycles so and the speed of the cycle is really based on the cure manufacturing process so we get at a TSMC or Intel's fab so no matter what chip 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 aetherium research and I have argued about this but and 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 shout 256 so it's

optimizing for 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 256 instruction that ran faster for power than Bitcoin then somebody would take that set up and use it in Bitcoin right so what you have with Intel is shout 256 that does one round in 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's may be possible but you'd have to design something that is super esoteric

optimized for cooling and extracting heat under this thing and any trade-off you make in space you'd make those trade-offs with time because the circuits get longer since if 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 beat up doesn't really get you anything so we are not like worried about an attack vector coming from the faster ASIC but we're more concerned is that we want the network to be somewhat homogeneous on the speed of the shout 256 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 an unreal 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 am running and you know how fast do the clock may be in the beginning of the start of a difference you used but CPUs but in over time they're going to naturally synchronize around the same speech and every two years is tsmc 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 a something that is really really hard to optimize how do we make it a faster clock chip is isn't an 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 well but then an alien from Tau Ceti comes to us and they have hundred X faster hashing and they get five percent of the voting power what could they do so here's the thing is we would have this show into hurt our 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 like generate a proof that they wait at the appropriate amount of time but because they're ASIC is so much faster it means that they didn't from the perspective of the client they will see the network behaving this 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 form choice rule but if you try to produce a block that is contentious like in this case right Brian out Rand and it's Olli 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 stop what we're doing I think we'll figure that out right as we go along from my perspective what your 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 fester a sick and the network can respond we can then take action it makes sense ideas there is a whole other part to the Consensus but which is basically people or rather the sort of

betting on the forks or like on which chain will persist yeah so the problem with consensus rate is that you receive a block and foreign in milliseconds you have no clue what the rest of the network thinks about this block whether they're gonna vote in it or not or they they receive this 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 do 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 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 vs. liveness like there's always this trade-off when I vote on a block I commit for two slots for if they're 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 it can be slashed if I do so but every time I do this vote all the parents all the parent votes they double and their commitment to safety so that commitment doubles and that's the exponential curve so after 32 votes right due to the 32 at 400 milliseconds as 53 years worth of of commitment to

safety effectively infinite because there's no way I'm gonna 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 like 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 make sure that the rest of the network is at least on you know 10 minutes or 5 minutes like I can figure some threshold where so threshold function that I observed the rest of the network is done five minutes therefore I go from 10 to 20 yes so you almost have this kind of like a shelling point right where you say okay we're trying to agree on a particular a particular block and if I'm sort of early and I say I think it's gonna be this block right then I I earn a little bit more money and and 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 gonna be the block right so yeah that's great

so let's let's talk about you know a little bit more on a high level stuff so like 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 block that's a nice article so they they face it like okay Solana creates abundance where there is currently scarcity which is this trust minimize computation so we were thinking about this my Herron and I we had a company retreat where thing is okay let's say you wanted to build on a small contract in today like what is there there honestly is almost nothing right that's currently life out there proven work so at the etherium and and obviously

there's an overcapacity right and struggling so but you know many people working on this on bring more capacity online let's say you guys bring a huge amount of capacity online I'm curious is is the idea for sole the Solana token to kind of a crew 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 gonna be really low that's honestly like that is like an unknown how does how does a token accrue value I don't know I think that's that's like a fundamental problem with the space that maybe we'll 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 in the high level is like 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 know you run your home node let's say it's a hundred megabits and your steady-state maybe the query widely successful in the network is doing 5,000 TBS 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 spaces 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 the data

and then come back to your note you can just scale up and 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 like the more expensive hardware when you need it but that 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 and that's what the fees should be priced at right because we want to fill it up so effectively there's this like 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 barrier 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 capacities 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 and AWS and Google Cloud right there's nothing we can do to stop people from doing that so what does that mean is they 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 defy applications but this underlying collateral let's right now driving the security 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 the high-frequency people are trying to you know 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 like we'll start seeing more realistic models but so somebody is saying is seoul 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 you try

surprise feeding 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 block sure network I mean presumably they could do something similar right like let's say the solana is able to process transaction at you know a thousandth 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 they could potentially be sort of revenue captured that way except that at any time people can take our open source code and our community a third-party validators and tell them to

run solana X right sure Solana fasting prey so effectively and like get everybody to switch right if the business the uses have a cost associated to them that's so high that it's above that threshold and they'll switch well you can say I mean if you look at aetherium today I mean you do sort of have that situation where you have your theorem 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 as secure but you do kind of have that but people still building on a serum so I think you have certain network effects at still difficult I think the markets basically will decide

if fees can be been 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 built up the next generation things because I think those are more interesting because the cost of hardware so low right like in the end as soon as we saw it solve the software like problems with that make operations low the bet also becomes cheap and then like if we have this you know amazing state machine that's globally distributed that 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 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 like I'm this is what I'm gonna drive is 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 it's an interesting question it's thick it's the question of you know now you have like lots of block chains with capacity and if Solana could like some way in short of monopoly everybody wants to come here and then maybe you know the optimal might be oh we use only 37% of the capacity but we charge high and that's

that's the business model if if they could be a monopoly but then the opposite world is there's so many chains open source the different designs our etcetera it's very hard to secure a monopoly and then there's like it tends to it's perfect competition in in a perfect competition space well it's very hard to preserve any kind of possession field levels and so their transaction fees cannot be a business model I think monopoly is very hard to build in the space for prefers take networks especially with like with Bitcoin mining we have a six that are and like this community it's really optimized for this one kind of business plan they have a

business right the mining like everything can it 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 it's hard and what they're maximizing is not throughput it's security which is totally fine right have the most amount of security in a single chain that's a really also 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 decentralized exchange in Solana so curious about like

what your plans are and what what kind of decks would you like to build because the interesting thing in the crypto space appears to be there is not one but there is like five or ten interesting decks designs nobody seems to know which one is going to win out yeah I think there is like there's kind of two designs that are like one is ours and the other one is like t BTC which is where you have a like a distributed group that takes custody of assets and then it's then it could behave like a centralized network with some different security properties but 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 that's it's like in a real-time high frequency and matching agents run off chain but matching occurs on chain so you have an audit trail of a 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 for an audit trail and better tools for building something that is more fair to the 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 like that built as part of our github and there's a bench client that we ran that we could demonstrate like thirty thousand price updates per second cool so I know originally you guys were planning to launch around now of course as all plotting never would it always stays long but so what are the main things remaining that kind of you know block or

you know to get done until Solana maenette launches so there's some tail and 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 it I think we should have expected it to take longer because it's when you think about it and 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 so why companies like Big O or one of those that there's they support it is that the idea or so so that's one of the

one of the approaches but we need to give people like a way to do it on their own right in a secure way that doesn't involve them storing plain texts private keys in their computer right and then who do we trust we trust ledger or treasure or do do a paper wallet how does that interface with it like our command-line client that actually does all the staking operations and things like that so that's one of those things and that we want to make sure we get it right even if basically optimized storage security there and less convenience because that's more important than the 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 you know Google cloud-based network or aw us and then we boot with a validated community and a bunch of stuff falls over so like what assumptions that we made early on was that we would have high MTU paths so like we'd be able to send reliably like jumbo frames across the internet and that assumption was wrong so we had to go from the assumption of being able to send 64 kilobyte packets down to you know 500 to a thousand 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 a dry run 5 where we want people to boot with GPUs and then we'll see what falls over we're gonna ramp up the transaction throughput and then see if we can match what we see internally which is 50 to 60 K sometimes and so what's there what's a goal in terms of their launch date and timeline I think I'll probably announce the dry run at the validator meeting in like a half hour anyways so I think it's gonna be October 29th so we'll do a dry run 5 and if that works because we want to launch with at least 50,000 TPS capacity that will do our stage 1 of TDs which stress tests

the network for about a week and then I think we're ready for may not support maybe sometime q1 probably I think I mean like the earliest I think we can do it as frie run run runs fine right 29th and then November next week we do stage one that runs fine and then end in November launched that would be the fastest time line with no failures okay cool I'd love to set up an auger pad on the like engineering time lines based of blockchain projects is there gonna be a made up 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 for coming on I have you taken quite a bit of time but I think this there was so much to dive into yeah I mean we're really excited to see solana 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 released new episodes every week you can find and subscribe to the show on iTunes Spotify YouTube SoundCloud or wherever your 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 while you 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 to be behind the show and we're always happy to read them well thanks so much and we look forward to being back next week [Music] [Music]