Hey everyone, Today we are talking to Patrick O'Grady who is the DP of engineering. At our Labs official, we will be chatting about the Hyper SDK, which is kind of one of the ways by which the Avalanche Network will allow builders of Avalanche Subnets to have very good performance essentially on the subnets that they build. So we'll get that.
We'll get deep into that topic and then if time permits, we'll also kind of understand the messaging protocols, the Intersubnet messaging protocols that would be available in the Avalanche ecosystem. So welcome, Patrick. Thanks for having me. Excited to be here. I was telling these guys before the show that you know, Epicenter was one of the first podcasts I started listening to.
You and I first got into crypto so many years ago now, but it's been great to, you know, follow along as all the cool guests you guys had on it. Really honored to have a chance to hang out to you guys. So, Patrick, how did you end up being VP of Engineering? Our labs official building. I press the cake. Yeah, good. Good question. So I I actually grew up far away from all this stuff. I grew up in Wisconsin, you know, I didn't grow up on a farm per se, but I certainly didn't
grow up in the in the big city. And you know I had a had a great childhood there like a lot of friends and stuff and then. I watched this show when I was growing up called Chuck, if you've ever heard of it, it was like on NBC in the United States and it was about this guy that like got kicked out of Stanford, got like a computer downloaded into his head and he came like a
CIA asset or at CIA NSA asset. And but the part was he got kicked out of Stanford, which is like this alluring place to go to. And so I got this itch like maybe I should try to go to Stanford. And so, you know, one thing led to another. Unfortunately. Got in, got into Stanford and. Came to Silicon Valley and haven't to haven't left since.
But while I was here I got first chase into crypto was actually at Stanford. There was a class of a long time ago taught by Balaji actually who had the 21 company where it was like connecting Bitcoin web services to to like a web like you. Basically the whole class was like building different things that hooked up to the 21 minor. So I actually keep. Like 21 minor on my desk as a
reminder. Kind of like the trajectory of where we've all gone, but it was all about like accepting micro payments and everything on the web. And so that really is what started things. But you know, spent a while dabbling around in college on different crypto things but ended up working at Coinbase after college. And so while I was there, I worked on a project called Rosetta which is like a universal read and write. Interface or open source specification for any blockchain.
And the idea there was, you know, Coinbase wanted to list as many assets as possible, but a lot of times there was a ton of overhead of actually adding those assets, right? So could could we actually turn the tables and have the assets integrate something that would allow Coinbase to just add them automatically? And that was the idea with Rosetta. But while I was working on that, you know, my interest was always going back into L1. I really wanted to get into like protocol development.
But I felt like a lot of what happened at Coinbase really prepared me for that. So I, you know, learned a lot about what it meant to work with digital assets at scale. And we know what were the types of features that people really cared about, whether that be exchanges or or users that Coinbase had. And so funny enough, Kevin, who is the one of the cofounders of Avalanche, reached out to me on Twitter actually and was wondering like, hey, have you heard of Avalanche? Like what?
What do you think about it? And. A few of the my mentors at Coinbase actually had known Evan from previous work, you know, throughout the years. And you know, I was really interested in working with great people and so decided to chat with them and one thing went to another and joined Avalanche, actually joined Avalanche at the labs as a engineer, senior engineer and then a month end was promoted to VQ Engineering. So that was a fun.
Fun few weeks, we'll say it. But yeah, so that's that's how I got to where I am now. Awesome, very, very impactful Twitter message there. So, yeah, really cool. I think obviously I guess the main thing in Avalanche is its consensus protocol sort of the main innovation I would say and that's that's what most people rave about in the community there that this is like solving like a unique bottleneck that I guess other. Rock chains don't or you still
have. Can you just, I guess we had Amin on already and talk about this, but I guess just for the context, it would be nice to hear again from you. You know, why is avalanche consensus so important? Yeah. So I want to preface this and say like, you know, I, I definitely joined a little after this major innovation. So I don't want to take credit for any of this. But yeah, so the idea, right, is, you know, when Avalanche came out. A lot of interest had shifted towards proof of state.
So you know proof of work we we think it's interesting it has some interesting properties but the amount of like the centralization of mining parties and like how much green greenhouse submissions that were associated with the industry was not great. And so like but Proof of stake at the same time, at that around that time you know you did, you couldn't have more than a couple 100 participants without the whole network becoming really slow and unstable because of all
the overhead. Network messaging between different parties and everything along that kind of thought pattern. And so the innovation with Avalanche was what if everyone didn't have to communicate but you could still use proof stake. And so you know hearing that for the first time, many people like I'm not sure. And so after you know a good bit of research and simulation,
testing, everything. What ended up coming out was that you could have a sampling based gossip protocol that was probabilistic but pretty, you know, could be parameterized to be pretty safe that was dramatically more efficient in network complexity than traditional PBFT like applications. Where there were two interesting properties, one was that there was no. Bottleneck at any point in the protocol. So like you didn't one node didn't have to communicate with
everybody ever. The second one was that not a single party rarely had to talk to the entire network. So, like, what that meant was, OK, you know, when I'm starting the consensus process on a single node, what I'll do is instead of saying, OK, I'm going to go collect signatures for everybody or like, if there's this round Robin where you like everyone sends something to someone.
You instead say I'm going to pick 20 people at random by stake weight ask them, hey, what do you think about this block right now or like what's your preference, They send it back and if some you know, alpha of those of those folks respond the same way, I consider that to be successful. And then if I do that, you know beta times in a row, we're good.
And so people looking at that would say, well, you know, conceptually that's actually pretty straightforward and and like you know, you can follow what I just said. But what that allows right, is a totally different, like network complexity into I think what is, Forgive me if I'm mistaken, but log, log, log N of nodes. So like in the case where you have on average, let's say on main net, every sample is 20 peers and then you end up doing 20 samples.
You only end up actually ever communicating with at most 400 nodes to finalize something in the, you know, the base case or the best case, whereas you know there's over 1300 nodes on the network. So even in the current network size you can see how much more efficient it is on the networking layer. And so if you actually want to have a proof of stake network with, you know, thousands and thousands of participants, you know it. It provides that optionality without leading to a delay in
finality. So blocks on the avalanche network from time to creation to time to finality typically occurs in about one second. So the fact that you can have this like huge base of participation without giving up. What people really want, which is this really, really fast finality that is at the speed of the Internet. It offers those properties. Back when the white paper came out, I remember reading it and thinking this is like the end state of consensus algorithms. I even had the thought.
I cannot prove it, but it feels like you cannot have a consensus. I'll go more efficient than the avalanche, right? Like this was just just instinct at that time. How has the implementation actually been in practice? Has the consensus are even lived up to its expectations? Or have you had to sacrifice many elements of the initial claims in order to build a
working system? It's a really good question and I think what I've never really heard discussed on any podcast about really any of these protocols is great. You know, you proposed this paper, what does the code actually look like compared to what the paper has?
So they're actually a number of changes that were made during the protocol implementation, one of which actually a credit to Christian Koshid and his team at Uni Byrne, wrote a paper I think last year about some issue with the paper which was never actually implemented. Because that was also discovered during the protocol process, but I'm not going to cover that. You should take a look, search it if you want to check that
out. Yeah. So the paper itself was actually about a number of different sub protocols within the avalanche protocol. So we call that like the snow family of consensus. And then on top of that, the Avalanche consensus process was, which really defined how Avalanche worked over a day well. Four months ago the X chain which was the one the chain running the day was actually
fully sunset. So there are no there's no more any like actual day processes running on the network and everything actually uses a separate sub protocol that was not in the white paper called Snowman. Now without going too specifically here too too in depth cuz I don't want to, we could have hour long
conversation about this. But the idea here is that the avalanche consensus process like as defined in the white paper, really was about connecting or basically having at any particular height multiple vertices that could compose a single, you know, single four chain, let's say. So the X chain you know there were just like any day had multiple vertices at a particular height, you know, children of those vertices or children of that would then
refer to those vertices. But you could have like conflicting transactions. And as long as like transactions didn't double spend each other, like things would eventually get finalized. But like, you know, because of network synchrony and like communication properties, right, Like you may have duplicate transactions at different vertices, right? Like cuz if you had a vertex over here, you had a vertex over here, you know, and the vertexes
were seen independently. There's just a lot of really complex scenarios that that had to handle. Snowman on the other hand. Was about having a linear chain like most people understand, where there's only one particular height, one container. Now that was required for like the C chain and the P chain which just operated as normal chains on Avalanche.
And what we found was that people really used the linear chains a lot more than they used the DAG related things because you could do a lot more on it are the Avalanche DAG protocol was pretty limited. And that you couldn't have like shared state that was mutated by different transactions. So in the case of, let's say the C chain, right?
Like you have a smart contract, you know everyone's balances are in a decks and the next transaction that comes in wants to modify, you know that that operation, the decks, well, you need some shared state of which to apply that to. But if the deck never actually has like a canonical state at any point, how do you even do that? You can't, right? So you end up really limiting.
The functionality with the day, and you're sacrificing that for throughput, which is the hope that says, oh, you know, if you're just doing a ton of transfers, great a day could be more efficient because you actually can like sequence things concurrently. You don't actually have to like distribute everything to a single block and then vote on that. You can just shoot out what you got and then put that in consensus right away.
But you give up some, you know some some complexity now or complex operations you could do on chain. But you know there this is really summarizing that there are ways to try and add that functionality to a day. But we felt that instead proceeding down the path of Snowman and then adding some advancements to Snowman called Snowman Plus Plus was much better because that actually unlocked the use of warp messaging which is the cross subnet communication protocol now.
I could kind of touch on how all these are connected, but Long story short, the protocol has evolved quite a bit from the original white paper and most of those specifications of the evolutions are now in read me's in the Avalanche Go code base if you want to read about. Right. Yeah. So I guess we're already sort of dove into it, right? This episode is mostly about Hyper SDK and and subnets. Now, you already mentioned the PJ, the action, the C chain, so sort of.
Subnets that came at the launch of Avalanche sort of out-of-the-box built by Everlabs sort of for different purposes, right. The P chain sort of administering the validators and other subnets and the C chain being like sort of the first EVM chain for smart contracts. But yeah, let's maybe just take it back a bit and. Explain a bit what is a subnet and then maybe also what is unique about subnets in Avalanche versus like other application specific blockchains.
Yeah. So that I think that discussion on consensus kind of took a stab a little bit too far. We'll back it up a bit. So yeah, Avalanche has this notion of a primary network. So the primary network, if you validate or stake on Avalanche, that's what you're participating in? The primary network, actually one minor correction, what you said is not actually 3 subnets, but is 1 subnet with three chains.
Now one of the most complex parts of Avalanche is at the beginning, which is a huge bummer as you try to like help people or talk about Avalanche because it's the first thing you end up talking about. And then everyone's like, you know, there's these chains, like what is they're staking, like how is this all connected? So the whole notion of a subnet and the primary network is a subnet. Is that a subnet defines like the set of validators that are
participating. And then within a subnet you have chains. Now those chains can have independent execution, but the chains within a subnet can communicate easily between each other because they're validated by the same group. So. But the idea here is when Avalanche was launched. Or like when Avala started working on the idea of the Avalanche just having. Basic functionality in the
primary network. So in the case of maybe just staking or transfers didn't seem appealing or a way to really test out you know avalanche consensus in a in a distributed system. And so the call or decision was made that like it would make sense to have smart contract functionality too because that's really what people wanted. And you know, while an entire virtual machine could be created from scratch with your own programming language, akin to like a move or something like that.
Even at that time, there was still so much interest in the EVM that it it just didn't make sense to really go too far afield from that. So the C chain was added which you know provided the ability to deploy smart contracts. So the primary network though is just like any other chain in the sense where you have like a single state or virtual machine that everyone validates and participates in and is limited
in in scale just like. You know any like any mainframe computer would be right, like all it processes Allstate transitions and like although there's this like this cool consensus average from underneath, you know, you have to balance resource usage with like what your expectations of actual like participation are. Otherwise it becomes like the Super centralized thing really fast, right?
So, you know, if Ethereum said, hey, instead of, you know, targeting 15 million gas per 10 seconds, we're going to target 3000. For like a three 3 billion gas per 10 seconds, right? Like who would be left? A bunch of supercomputers on like a few colos around the world, right? So in the same way, like your target throughput is very correlated with the number of valuators you have and how distributed those will be. And so some networks have chosen to have like a very high minimum
throughput bar. Something like a Solana Avalanche has taken a different approach which is trying to really maximally distribute this. Like primary network and then on the side have this notion of subnets which lets people create these specialized areas for blockchain execution that maybe have very different tradeoffs, whether that be different types of virtual machines which I'll go into, or just having very different throughput targets.
So like, hey, maybe for the subnet you actually need to have a much more powerful machine than you would ever need for the primary network, but because. You know, we want to maximally distribute like the participation in the primary network. We keep the throughput much lower there, and Avalanche lets you get like actually do that distribution right? Like if you can only ever have 100 validators, you may not be as interested in like having this crazy distribution of participation, right?
Because why, right, if you have, if you're only going to have 100, but if you could have like thousands. You know, you may benefit from having like a much broader senses or broader notion of security.
Yeah. So is it is it correct to think that you know like when you look at kind of the development of Avalanche, in some senses Avalanche started our off with a time disadvantage Visa V other other ones, I mean compared to Ethereum every L1 is at a time disadvantage like 5-6 years probably for Avalanche. But even if you look at the other ones, Cosmos, Polka, dot, Solana, all of them started two or three years before Avalanche. Avalanche has been kind of like
one of the one of the late comers in that sense to the space. And and I think that the decision to just in the beginning have have an EVM chain that the C chain was, was actually really great because if Avalanche would have taken the the target of actually building a new consensus algorithm and then building like new kinds of virtual machines at the same time, something which something
like a Solana date, right. Both they were innovating both on the consensus, I will go and then on how how financial logic would work on the chain. Avalanche would have taken both of those targets simultaneously. Probably may have been too much. By just taking the EVM and doing it C chain, actually Avalanche has a small has an ecosystem already. There's people like Trader Joe's that are kind of operating across both the Etherium space and Avalanche space.
And because the code looks the same, they can deploy across both. And I think many, many initial Avalanche successes have that flavor where these are essentially projects that were trying to do something on Ethereum and then they realized, OK, we could do it on the Avalanche C chain and either get a new community or we could get cheaper transactions or faster transactions. So that feels to me like the first phase.
And now kind of the point at which you get really involved and messed into the Avalanche system is like the second phase, which is now that the consensus is stable, how do we actually build performant virtual machines different from the EVM in that ecosystem? I would say on that point, tons of pros and cons of that decision, right.
So I think in the pros camp, right, we certainly were able to minimize the number of systems we had to build from scratch and anyone that tells you like you should just do everything all the time. Has never attempted to build like a complex distributed system before, right? If you can minimize the number of things you have to build kind of to prove out the major ideas, like you should totally take that chance as long as it's differentiated at the same time
still. So I think that was something to really help us get off the ground so far behind, which I don't think many people really even realize, right? Like the Avalanche main that launched years later than a number of these other ones, right. So like when people are comparing us directly, like, oh, you know, there's still so much to do. It's like. Yeah, I wish I didn't have to sleep, but fortunately my body shuts down at some point.
But on the con side, I think at the same time people look at us and say, oh, it's just another EVM for right. Like, oh, you know, you saw a phantom, you saw punches, whatever, over the period of time. Like, it's just another one of those. And so, you know, there's a lot of work we're doing that people are just like, well, how much work is it actually to, like, maintain a fork of the EVM? Like, it seems like it shouldn't
be this hard, right? And. They're totally missing the point where most of our work goes into. So like for example on the EVM front, we actually implemented that on top of the VM interface that Avalanche Go provides for any virtual machine to use. And we figured, you know, we didn't copy any of the networking, the consensus, you know, we didn't connect any of that. We used all of our own stuff.
And the idea was if we could support Ethereum or like the EVM functionality on top of this VM interface. So we could probably support a good amount of different virtual machine interface. And so we spent years really like dog fooding that and optimizing that layer. And so I think we're currently on version 26 of the integration between a virtual machine and Avalanche Go.
And to the Hyper SDK, which we'll talk about in a bit, is that's how it actually communicates with Avalanche Go in the same way that's built on top of all the work we've done over the years to integrate all these different virtual machines into Avalanche. And so Avalanche itself, like the code now that you should think about is really just like this consensus platform you plug into as a developer.
And so when you're building a virtual machine, you're really just telling Avalanche go, hey, orchestrate this virtual machine process, handle the consensus, handle the networking. But that has been, you know, born through years of hardening the EVM integration. So, yeah, but on the note of like having projects start there, it's been great to see, you know, some of the teams that have, you know, found success
there. I think we're seeing some of that play out with some of the move chains as well. We're like, oh, you know, they tried it on Aptos, didn't work. So now they're going to try it on Sue and see if they can build a community there. And so it'll be interesting to see. I think you know the smart contract layers that are shared, how that continues to be like, especially with these Staffs moving from, you know, across to L twos now instead of, you know, other old ones.
But yeah, it was a very interesting big decision I think. And so far, I think it's still been net positive for sure. Right. So I think before we actually wanted to get into our SDK to just tease it again, we also wanted to 1st cover a bit the one of the core features that sort of this architecture brings that Avalanche has that every validator also validates the main net. You just it's warp messaging. Can you sort of talk us through a little bit what what is warp?
Messaging, Yeah. I think this also touches, you know, on a really interesting notion of like why would you even build a subnet to begin with, right? You have, like you have the cosmos of CK to build your own blockchain. You have L2 S You can just do that. You might as well just deploy a contract out like a Solana or Aptos or SUI. Like, how does subnets even fit into this and why is Avalanche really designed the way it is to begin with?
So the whole idea for a lot of this architecture was based on the assumption that people wanted to create their own blockchains. And that was the case years ago and is the case now. The language in which or like the semantics in which those blockchains exist has certainly had changed a bit as people have had different ideas.
But the notion that communities want to create their own blockchains and they want to participate them and you know, really have their own thing, but that the biggest problem. Eventually would be how you connected all of them. So you know, if you create a chain, and I create a chain, like we can have our own communities do things.
But what we've seen time and time again is like things really get supercharged and exciting when everything's connected, right When you're contracting, call another contractor. When my chain can interact with your chain, it seems to like multiply the benefit of blockchain rather than just being added or even you know, subtract like a net zero game or
something like that. And so Avalanche was designed from the beginning to have this at the core, which was if the primary network, specifically the P chain can keep track of who's participating in what subnets. It'd be really good for two things. One, making it easy for exchanges integrators to stake everywhere because you only integrate with the P chain to actually stake. But the second?
Was this idea that it could also be used as like a registry store to manage messaging throughout the network. So I'll give you one simple like kind of comparison here which is in Cosmos which was certainly a pioneer and a lot of this cross chain messaging with IDC and all the great stuff they do. There is no like center chain that is a registry.
So every zone has to communicate with every zone like a connection and channel state that they're constantly updated for every message or like whenever there's a validator change and so as a result. It's not necessarily encouraged to have like every zone talk to every other zone because there's so much overhead of passing all this like state management stuff
around. Avalanche takes a totally different approach which is you know, validate this one chain and then there is no like additive cost per message you send other than just verify the signatures because you just look it up on the primary network. And so word messaging, which we call our cross subnet messaging protocol. Is basically this way to securely send bytes whether that be an asset, a transaction, data, whatever you want from 1 subnet to another where you the the validators.
Basically on the the source subnet create a BLS multi signature and then the validators on the destination subnet just look at that BLS multi signature and say hey like what is the source subnet stake distribution or like who is participating on it. And then say you know the subnet, the destination determines if the message is valid based on the percentage that it sets. Is this valid? Is this message signed by X percent mistake? And if so, accepts it.
And so it's a very simple base protocol, but it uses the benefit of having this like registry chain kind of in the middle to like actually authenticate those messages. And so you as a VM, you know, builder or somewhat using this. You just have to really just say get the validators to sign a message and then move the message. But you, the person that actually moves a message has no additional trust in the network whatsoever.
And you could just as cheaply move from subnet A to subnet B as it is moving from subnet A to subnet C, Which is a huge benefit to avoid having like correlated risk as you take an asset and move it like further away from its origin right. Like if you have something asset to find on A. Then you move to B and then B moves it to C Now there's a problem on A, C may have no idea unless you know manual
intervention is is done. And I think a paradigm actually has a great article on this in the cosmos ecosystem like this risk of kind of asset contamination based on how many hops you are from the source and so with this you know mechanism you really just don't need to do that. So but yeah, so that's the gist, which is Avalanche was built for this multi blockchain world. And assumes that that was just inevitable. And in that world, what do you
need the most? You need a shared integration point so like all the stake is secured by the entire network and you need a really good messaging system. The actual VM building is then what makes it all come alive? So you said like the BLS signature and there's a certain percentage of stake that needs to have signed the message. Is that like? The state distribution from the specific subnet, so some some staking on that subnet. But then how much does it need to be verified by the the
avalanche validators? Like I guess in a subnet not necessarily all avalanche validators are part of it. Is there like some threshold that's also needed there or? So that's correct. Yeah. So the actual primary network has nothing to do with messaging other than like basically maintaining that registry list. So you could imagine a system where.
Hey if I want to send a message from subnet A to subnet BI have to like first send it to the primary network, it gets persisted somehow inside and then subnet B can read it. This is a point to point between the subnets themselves and the way that this kind of works is it's all opt in. So a subnet that like gets a message, there's no requirement whatsoever, it has to process it at all depending on where it
came from. So it's on the destination to say first of all, which subnets I actually want to. Accept messages from and then two, what is the stake percentage that must sign it for me to consider it to be valid. So like for example in a virtual machine that decides to integrate it where you have like a kind of like a homogeneous asset mix where like every asset looks at like the same.
You may have a very high security window and say like oh you know we 95% of stake and we only want to accept messages from subnets that have so much value like associated with their token. And then on other subnets or like for example on some other Vms we've seen where the tokens are actually prefixed by their source. You may just say across the board, like if 80% of some subnet signs this token, like, we'll accept it and then people can choose to interact with it if they want.
So you're given that option when you actually implement the virtual machine, right? So the way I'm kind of imagining it is I tend to think of block chains as. I mean, it's kind of wrong in details, but I tend to think of like scribes or accountants Maintaining an Excel sheet, right? Jointly maintaining excel sheet. That's the Roy's description of a blockchain. I have and. Just submit a Google Form and
then you're good. Yeah. Yeah, it's kind of like the easiest way to probably think of it. And so it's like the Avalanche main net, the Cchain, Pchain and Exchange. So you can think of that as like the biggest association of scribes or accountants in the Avalanche ecosystem. So anyone who wants to be an accountant anywhere in the Avalanche ecosystem you have to go and join the main net first.
So you you build up like this huge pool of 2003 thousand maybe in the future 10s of thousands of scribes that are that are kind of like maintaining that that Excel sheet of the main, the main subnet and those are the three chains there. And then whenever a subnet needs to be spun up, what that kind of main Excel sheet is kind of storing is what is the subset of accountants from that main network that will that will kind
of maintain that that subnet. So if you create subnet 37, there's a record in the main Excel sheet. OK for subnet 37 these are all the accountants and that's kind of like economical place where they are stored. So that mean this is storing who are the accountants for each of these subnets. And so when I'm subnet 36, when I get a message from subnet 21, all I need to know is that message valid and I can just consult the main.
I can consult the main network, say what's the list of scribes and what what percentage should have signed this message for me to accept it. I mean it would give you that response and then you can trust that response and accept that message based on that. Yeah, basically that's your input into like the message verification process to say what are the BLS keys of the people that are supposed to sign and what is the weight associated with each one of those BLS
public keys. And then you can just say whether or not like locally that's valid, so like. But it's really up to you how you actually want to like maintain that delivery. So like you mentioned, there's no. The main net component that it like the messages don't have to go through the main net. Secondly, one point really small to clarify, right, is that when you're talking about those scribes, they're never assigned to a subnet, everything's opt in.
So Avalanche right now is very much designed for like a sovereign world rather than a shared security world. So people that are coming at it from the world of hey, I know what L twos are. I use a theory and I put data there. Not how Avalanche works at all. Subnets maintain all their own data. The primary network just manages stake of subnets and the
validator registry for subnets. But you don't actually put data there and it does not offer any sort of like prove capability to prove that something that happened on the subnet was invalid or something like that. Now that may change in the future based on like what appetite you know people have shown for like. It'd be great if I didn't have
to provide my own security. But so far and you know how Avalanche was originally designed and at the time at which it was designed, there was no interest at all. Insurance. It's actually pretty funny how much it's like shifted entirely like shirt security seemed to like really become this thing maybe a year and a half, two years ago. Like I don't actually want to provide about security, I just want to use someone else's. Whereas before that, like it was all about this notion of.
For our own community, we have our own decentralization. We have no, you know, no master that we like kind of work with or like you know, we're our own sovereign community. We don't want to work with anybody else. We want we we define our success. So it's interesting how much that spectrum has since that time. But yeah so for people that are using subnets, you know if you were to shut off all the values
on the subnet, it's gone. So it's it's like the subnet provides its own security and it's opt in. So you you join it. Or you state to join it. But maybe also, I guess to also like Avalanche doesn't have slashing right? And there is, so there's really let's say there's a malicious subnet somehow.
There's actually no like recourse for the main NET validators that validated it. Sort of in in a way what you would do so like in the case where you had someone that wasn't participating right, you lose your reward. So like the? The penalty is really like, hey, you were going to get this staking reward, now you're not. So it's not like there's no penalty whatsoever. It's it's similar to like you just you'd get inflated out of
the system more or less. But on the subnet front, there's no load for the subnet on the main network. So like if a subnet was like, I don't even know what it would like, there's no control of the subnet, right? You can do whatever. That's the best part and most complicated. Part about it, which is where the hyper SCK like ends up coming in, is to try and bound that a bit for people that want to get started.
But you know, it really does its own thing and so if you are on a subnet that all of a sudden like goes absolutely wild, you can just stop validating it. No penalty to you other than anything related to that subnet. And so like unlike something where like a polka dot for example, where there's resource constraints per pair of chain to make sure that when you're assigned to a pair of chain. You can't just like get totally wrecked by whatever the pair chain is doing.
There is no notion of that on Avalanche because it's all opt in. So if you want to participate in the subnet, you better have the resources required to participate. But if it's malicious, you know you should just not. And there's no penalty for that outside of that community. So maybe that community will say, hey, you didn't get your reward and you'd be like file with me like I don't, I don't want to anymore based on what
your subnet is doing. So that's not necessarily a problem per se. Now the one very small side I will say is that a lot of the feedback we've gotten has been that this like kind of strict connection between the primary network and the subnet has made it much more complicated because you have to like validate the primary network and all this
stuff like that and the subnet. And so like you know, how can you possibly be efficient if you have to do so much it wants just to run a single subnet compared to like an L2 where I can just turn on a server, connect you to a serial. Good to go. And so there has been a lot of conversation in the community about changing this a bit.
And so having subnets or participants actually just like verify the P chain or what is required for like just to populate the registry and not actually validate the primary network but just read it and then store data on it. And then that would make the like subnet running process like much lighter and with that wouldn't really sacrifice any functionality so. There have been a lot of conversations about that. Nothing really has started, I
would say. But you know, I think with any network, right as the community interacts with it, there's like this constant evolution, and it's a really good metric of like how how much people actually care about what's going on is like, how far did you actually end up deviating from the original ideas based on interaction with everybody? I guess unless you're like a Satoshi's vision fan, in which
case I don't know study. But I think in the case of like Avalanche, what we're thinking about, it's how the ecosystem has continued to change and what does the community decide to do in in reflection of that based on what people are actually trying to get going. Yeah, I mean this, this, such a big variety of what I mean when you look at the entire crypto space and that includes like. Near Solana, Etherium L2 S Cosmos, Avalan, Olka, dot, maybe something even like a Celestia.
There's such a huge variety of what the Central Chain is trying to offer as as services, right? Sometimes it's Central chain isn't offering anything at all, which is the Cosmos Hub, maybe the most minimal set of services the Central Chain is trying to offer historically. Then maybe you have like an avalanche which is offering the services of OK, the string validators and tracking who validates what. Then maybe something higher would be change that off trying
to offer data availability. So if you have a subnet you wanna run your subnet we'll make sure that your data is accessible in case something goes wrong in your system. We have the data to process who didn't what wrong and start a code of some kind that's kind of like the Ethereum probably like the celestial visions are kind of there.
And then like the the poll cut out and near visions would be yes you can come and run your subnet and we will ensure that a malicious transaction never never comes in. Like the central place will kind of ensure ensure that your accounting is always right and your data is always available. And so there's this whole range. And yeah, it's kind of like market forces will ultimately decide what what model ends up
the winner. Yeah, I mean, I think the one thing I'll say in response to that is I tweeted about this a while ago too, which is I think the ecosystem generally should be supportive of this scheme like so widespread approach and like that resilience and like. Interest to go down so many different paths is what makes crypto so strong, like and resilient. If we all sent like focus so much on a particular thing and say like everything else doesn't
make any sense. Like if you're doing this like I don't know where have you been like you've been to rock ends up destabilizing everything because like if that particular approach has some sort of setback, you know whether that be like regulatory, legal, like security wise, who knows what. It ends up we gain everything because we now all made this assumption that everyone has to do this way. So when people talk to me about like, do you think there'll be a
single chain? Or like is avalanche the only way you could ever do something? I always emphatically say no. And I hope, you know, I really hope it never is right. Like, I think that the notion of having this like really interesting heterogeneity in the space, although it may seem suboptimal, is like the. Not to use like the cliche word, but like the anti fragile fragility of everything is I think what excites so many people.
But yeah, I really think that this is a great transition to to the Hyper SDK step, which is trying to, at least on the Avalanche side, make that easier to take advantage of. Right. Yeah, let's go there. We're like 40 minutes in and getting to the the meat of the conversation. So right, we talked about like.
Avalanche like sort of trade-offs, it's making the concept of subnets and now essentially what your main focus is in avalanches as far as I understand at least is this concept called like or the project called Hyper SDK. You just yeah basically tell us what is Hyper SDK? Yeah, so I mean for a long time if you wanted to interact with Avalanche in a custom way. We would say or I would say like, Oh yeah, you can do anything.
It's so flexible. Like there's so much you could possibly do. But if you want to get started quick, you know, we have the subnet EVM, which lets you like spin up an easy app really quickly. And that's really what got people's attention with Subnets in the 1st place. I like, tweeted this thing out about like, start an EVM with a single JSON file and then that, like, people love that post. But as a result, like for a long time all people ever did on subnets.
Deployed yet because it was just like this, super JSON, easy contact. And then I realized one day, I don't, I don't remember specifically what it was, but I was like, you know, I keep saying it's so easy and straight, like there's so much you could possibly do, like just go do it. I realized that, like, you know, to actually do that from scratch is not a super straightforward task and it requires like to do it really performantly.
Quite a bit of engineering work. And so I decided at one point, hey, let's just in one particular case, offer like a very opinionated view of how you could build a foundation for a blockchain that lets people go from maybe step zero to step 10 and then let them. Or like, maybe step zero to step 8 and then let them go from step 8 to step 10. Because there's a lot of functionality you want that you would want to build on top of the avalanche go process.
That is not necessarily provided out-of-the-box. One of those, for example would be something like states which we can go into later is not something provided by the core of Avalanche, but any high throughput or modern virtual machine would probably want that. So I thought about a lot of like, you know, there's a lot of things here actually that if we just implemented one time and 1 opinionated way, could make it much easier for people to build their own thing and to me avalanche, right?
If all it ever is is like, yeah, it's a great place to run like Modda DVMS. I guess to me that like is such a shortfall of like what the original hope and vision were makes me sad I guess. But generally you know if if you want to see change in the world, you got to be that change I guess sometimes. And to me like the Hyper SDK is something I'm very passionate about, it have a lot of fun working on. So the Hyper SDK in short is
it's a toolkit or framework? Really for people that are trying to build their own blockchain that takes advantage of the best Avalanche has to offer that we may not have been able to take advantage of and other virtual machines we have because we're trying to preserve maybe some sort of functionality
over performance. And I think in today's blockchain world, so many people are interested in scalability that targeting, you know, scale at all costs was really the North Star and continues to be the North Star for the hyperest Decay, is to say. If someone comes out and asks what's the fastest and scalable thing I can build on Avalanche, we wanted to have an answer. At least Avalabs did for what that would be and that's the Hyperstk.
So maybe I actually want to start with very conceptual question on like what do you mean when you say virtual machine? Yeah, that's a good place to start. Often, like our conception of virtual machine is OK, it's a Turing complete virtual machine. Where there's some kind of programming language is Solidity, with which you can write smart contracts and you can deploy them. But I think that you mean virtual machines to be something broader. What is? It yeah.
So in the context of Avalanche, a virtual machine is anything that is the subnet specific logic that is running. So that includes state management, that includes RPC. It's more of the virtual machine idea of like you run an easy two, like it's a general computing surface that you can utilize with some like functions that are provided to you. So like I agree with you, like the typical virtual machine people use is like a theory in virtual machine, right?
Like it's just the logic that executes the transaction like, hey, this is the transaction format. This is like how that transaction is actually executed. Great, now we've done the state
transition. What's next now I think because there's so much complexity here, virtual machine has kind of brought in and narrowed based on who you're talking to about what exactly it is. But in this case, you should think about it more so as specifically it's a any sort of binary that implements like the avalanche go required consensus calls, and that can be anything so. You know, you don't even need to have blocks. You don't even need to have you know any of this crazy stuff.
It's really just a binary that can run and communicate with avalanche. Now the components there just to be specific right things you may want in something like this. What is a block? So you would define a block. What is like a transaction? Look like you would define a transaction. You know what do you store? Like what if validators actually like store on their disk? You know how do you access this thing? Like what sort of API calls you want to have.
It's all up to you as a virtual machine developer, and so you have to remember right that Avalanche the goal here is how can we create as low a level framework as possible that still allows for this messaging interface and shared sticking layer that if you were going to create your blockchain from scratch, you could still do so in almost any case on Avalanche.
And so the virtual machine we're talking about here is much more like you could think of it almost like a server or like it's much more holistic than just the state transition logic that you may find in like the EVM or the VM. You can almost think of it like a mini node, kind of particular to your blockchain. And now Hyper SDK sort of is a. Like I guess toolkit and and allows you to to build this takes like some some things out of box give you something.
Could there also be essentially like another SDK like? Oh, totally. Eating things someone builds that has like, yeah, opinions about how I/O should be done. Something. Exactly. So the Hyper SDK basically says, you know, what I described is basically super, super broad, right? It could be going, could be Rust, it could be yeah, like your blocks could be potatoes like the. The whole idea with the Hyper SDK is to say, OK, you have a million options. We're going to, we're going to
choose a bunch for you. So this is what blocks look like, this is what transactions look like, this is what addresses look like. And then the whole idea is we'll give you areas where you can inject custom logic or your own design that does not impact the throughput that the network should be able to attain. So you want your own custom thing like you want your own transaction types, maybe you
want your own. You know you want to use certain types of cartography, like there's a counter abstraction, like you know you want it, you want all that, but you don't want to like actually implement, you know block distribution, You don't want to implement like statement, you don't want to implement state sinking, you don't want it like. So it takes a very particular set of tradeoffs and said we assume most people want this abstraction break, which is.
Higher than what Avalanche Go provides out-of-the-box, but lower than just deploying a smart contract somewhere and says most people want to probably start around here. And that's, that's the idea of the Hyper SDK with with the underlying assumption that you want to go fast or you want to have a lot of transactions. So one of the things that one naturally wants to compare Hyper SDK to is the Cosmos SDK, even
have similar names. But in the Cosmos SDK like you can use it to kind of bend your own application specific blockchain, implement your transaction types and what the Cosmos SDK will provide is a way to communicate with the consensus and networking that is tender meant.
But the Cosmos SDK kind of also offers opinionated ways to here's how you do staking, Here's how you do governance, Here's how you do auctions, Here's how you manage a token right Like so. But Hyper SDK, it seems like has a narrower set of focus where where you are not seeking to offer. Here's how you do governance. Here's how you do auctions. You are only saying probably like here's how you do state management, Here's how you do
block distribution. So I think like the way I would answer that would be. Here's how you offer probably some kind of RPC or API to people seeking data. But you don't want to get into the question of how to do governance, how to do, how to do staking, how to do options, or how to do token management or any of these financial logic in
a sense. It could like there's nothing that prevents it per se as much to say as we'd prefer that to kind of wrap this aspect of it. Like you could implement, you know, a separate kind of layer on top of this to say, oh, you know, here's a module store of things, you could pull it. And the idea here is that the Hyper SDK is really just concerned with this like super high throughput fabric that then you weave whatever you want into.
You also have to imagine that some of the things that the Cosmos SDK has to provide are already provided by Apple Edge, so like for example the staking module that doesn't exist on chain. So you don't actually have to worry about all that. And that's where a lot of the like bugs and complexity are for some of the other Sdk's which is just handled by Apple Edge. The one thing though, that is different just for very briefly the technical audience, is tenderment handles state. Always.
So if you want to use the Cosmos SDK, you're using tenderness state. The Hyper SDK provides its own state and it's pluggable so you don't actually have to use like Avalanche goes state orchestration at all. You can provide your out so you could hook it up to AWS if you want to, or you could just have your own high throughput store underneath. It also provides its own networking which Cosmos SDK doesn't allow.
So I think maybe there's some other ABCI plus plus stuff adds more flexibility there, but for a long time at least, you just tend to handle that for you. So it provides them, I guess in some ways less functionality on some parts and that in other ways much more controls into the core than I think there is anywhere on any blockchain building framework and so.
But to answer your question like could we shape the Hyper SDK to like have all these different modules and different things that Cosmos SDK provides which people have shown interest in. Certainly you could totally like build up that scope if you wanted to. But I think that the way that we approach it more so is we're platform and tool builders.
We want to not like build the whole thing up to the top, and we'll have examples for sure, but the value seems to come from Can we maintain with a minimal feature set? This really high throughput layer and then have all these super specific logic that you care about maintained elsewhere, otherwise it just won't be reliable. We just think there would be too much scope to actually maintain
based on what people care about. And so as a result, you know we've achieved really, really high throughput, but you know have spent less time on like extremely complicated transaction types because that's not really in the immediate scope of what our first phase is really about. Yeah. So you're mentioning a lot like obviously here performance and and that seems to be like the
core of your interest, right. And I guess also like what Hyper SDK set out to achieve to like really utilize like the potential of Avalanche, I guess in that sense. And yeah, we would like to I guess here. So what is like? Where is this optimization? Really there you know what are like the top things that Hyper SDK helps you optimize, which maybe other systems don't. Yes, I mean I think with any like thing, you're starting from
scratch, right? You you throw something on the wall based on your initial work and then anyone in performance will tell you all your original assumptions probably ended up being wrong and you just have to benchmark everything and repeat. So benchmark your ideas repeat. And if you just out of nowhere say, yeah, this is definitely going to be the most optimal, but you haven't tested every individual component, you're probably wrong. So there's no way unless you're
like I mean. Maybe I'm only a, you know, two ex engineer. There are hundred ex engineers that know exactly what part is going to be totally messed up as they build it. But my experience has been with this repeated benchmarking and so, but the the three areas we've really identified as the primary bottlenecks, at least within the context of avalanche are state management, data distribution and deferred validation or verification. And all of those are really what give it its speed.
So and like really a speed at which it assumes that people can still join the network via just the network. And I'll dig into what I'll what I mean by that. So the first thing, state management blockchains modifies state. You know that is the state transition, right? So if you can't, store and read state extremely fast and make sure that the overhead of a ton of like state transitions in a row is not well maintained. You know that's going to be your bottleneck at some point, right?
Like you're going to run into problems because you can't keep up with the transactions like the nodes unless you have like crazy disks and everything like that. And then secondly, if it's not well maintained such that people can't efficiently join the network, you're going to have problems too. Because if let's say you get 10 million blocks in and then like, you realize, oh shit, the only way to sync is to sync from scratch. But it takes longer to sync a block from scratch that we're
producing them. You're going to have problems like the the network's going to die unless you like somehow snapshot. It gets really complicated, right? And it becomes very centralized then because then you have to offer disk backups for people to go get. So the first thing that we really focused on was state management. So we built our own database from scratch. Two of them actually. One of them is released, one of them isn't. The one that's released is a
Merkel path based radix tree. And the idea there is it uses path based storage to really efficiently store the current state and then some number of diffs back. Now I have to give credit a lot of the ideas of this particular implementation and like the theoretical pittings of it came from some of the work that Peter Schlogy and the guest team has
done. So I want to say that like they definitely thought deeply about this and pioneered a lot of the ideas in this like path based architecture. So I just want to give them credit where credits to, but we implemented a different version of it from scratch. That integrates state syncing with it and then that can run on any key value underlying database.
The second thing that we implemented, which is not out yet is one that takes all of the trie management and everything related to actually doing up the stuff you would do with the Merkel cherry and actually interweaves it with the key value stored me. So instead of having to, let's say have some data structure and then you know you run Pebble or you run, you know, level DB underneath. It's one and the same, and as a result you can much more
efficiently manage that data. And so state management, again, this is not a super original idea, is one of the primary bottlenecks of these high throughput chains. And so you may have to store everything in memory, you may have to use MV and E drives whatever the second data distribution. So if you have a lot of transactions, you got to have a lot of data, and that data has to be distributed to other people.
To actually validate it and accept it in consensus if you can't distribute the data as fast as you're processing it, bottleneck so that Avalanche Go gives full control over networking to the virtual machine to the Hyper SDK. So that means you can either use standard P to P stuff, implement any P to P interaction you want on top of it. Or use something outside of P2P in general.
Let's say that you have like a permission to use case for like you have your own network and you have like a really high throughput bus you want to use, You could totally use that the Hyper SDK provides like a P2P primitive for distributing data between the participants in the Hyper SDK, like in a Hyper SDK based network. That allows for like chunking the blocks up and then distributing them in a way that is as fast hopefully as we're processing that data.
And then the last one is this notion of deferred verification. Because this is very dense, I'm expecting also to come back and maybe summarize some of this, But the last one is deferred verification. And the idea with that is, if during the consensus process you actually have to verify the block end to end, you will really slow down the ability for the network to actually finalize new data.
Because before any node can actually vote on that new data, it has to actually verify that it's correct. Otherwise it may vote on things that like are invalid, in which case it would get slashed or, you know, penalized, or the network would become unstable. So what can you, what's the absolute minimum thing you can verify such that you can still
participate in consensus? And so at the Hyper SDK breaks apart everything other than what is minimally required to derive a deterministic result and only does this preprocess step before voting before actually doing the full execution. Now in summary, right, you as a VM developer probably don't care about any of these or even know they exist. In some cases you just want like this is what I need to build and I want to hit this throughput or like this TPS target.
So the whole idea of the Hyper SDK is, let's take all these, like really useful ideas, implement them, audit them, make them production quality such that when you build in your own virtual machine, you just say, I want these types of transactions and I want them to do these things and that's it. And that's the whole premise of what we're trying to deliver with really high throughput like this kind of fabric underneath
everything. And so it changes a bit how virtual machines are designed, but you could apply, you know, all sorts of crazy transaction types on top of this as long as they're deterministic. And that's really the only requirement. Kind of like every blockchain is like every blockchain ultimately needs to do something around state management and data distribution.
The third one which is you don't need to verify the entire execution for you to sign something maybe like this is you have like optimistic verification of some kind. So, so I would clarify that particular word, optimistic because that has become very charged as well. So optimistic as far as I understand it typically means you'll like you'll basically execute something or you know maybe some form of executing it and then at a later point in time could be proven wrong by some proof.
The idea with this deferred verification is that you validate enough such that that can never happen. It can never be proven incorrect. So it's still going to be correct. You may just not know what the result is yet. But you agreed on the inputs that will lead to the result and such. If everything is deterministic, you'll get the same result everywhere. So it's a very, it's kind of a breaking apart when you need to like push these throughput right.
You end up hitting certain walls and you have to. I will say that like as you're trying to develop high throughput systems, it really requires you to take everything you know about blockchain, at least everything I knew and like really pull it apart and say like why is this done here? Was this done here for a specific reason or just because it was convenient? So like to give you some comparison. In each like, especially like the communication between the consensus layer and the
execution layer. How it works is the like the consensus layer will get a block like some consensus layer block and then it'll ask the execution layer, hey can you verify this block and make any state changes in a like pending state? And then if it can, the execution layer will then respond that like you know I've executed the block and then you know we've done this come together.
But in this case, what I'm saying is what if there was some way or like some sort of constraints you could impose such that the consensus layer would just tell like the execution client, hey, this is what you will verify, make sure these people have sufficient funds to process that that's enough. That's all I need. And you don't actually have to make the Tri U modifications. You don't actually have to like generate the next route.
All the stuffs that really take a lot of time during that process, you just don't have to deal with and then you like pre verify all the signatures. So that's also not part of that process. So, so basically you can take what is typically a monolithic verification chunk and then separate that into what its constituent components are. And the Hyper SCK really tries to be very specific about exactly what part of the verification it's doing.
When and the invariant we offer virtual machine developers, then we will ensure that this is done correctly even if we separate all these parts. But you basically give up control over how execution happens and as a result you get more throughput. So right now Hyper SDK is alpha software and it's headed towards a production release. What kind of benchmarking have you done and what do you expect to be able to deliver in production for a subnet?
Meaning like number of validators multiplied by let's say. Simple money, trans money transfer transactions. What could you give in a setting like that? Yes, I mean, I think this is The funny thing about like a TPS, right, which is depending on there's like 100 ways you could manipulate this number to serve
your interest. And I've actually been really interested in like a standardized framework that we could use or any network could use to plug into that tries to approximate like the complexity per transaction so that like the Tps's can be viewed similarly. I think Aptos also released a similar benchmarking tool so that you could use that amongst different at least move virtual machines.
But the to give you a short answer, the goal when the Hyper SDK was created was to shoot between 50 and 70,000 transactions per second of simple Verification. And as I got deeper it's like one of those things where like if you have a number you want that number to go higher. So like you just keep looking at that number, you're like, all right, I got this this time, this this time with the deferred verification stuff, we think that we'll be able to go over
100,000 TPS. And so that's now the new target for hitting when we're actually finished implementing the deferred verification because we've now removed you know all the bottlenecks we can find. And really the bottleneck now is how quickly two things, how many cores and how quickly can you move the data between nodes based on where they're located.
So naturally the TPS would be higher, let's say obviously if everyone's in the same data center, right, because like the network latency between 2 nodes instead of being you know I'm going from you know Japan to the United States is now within you know a couple feet of each other. But that's what we're targeting is in that range and so, So from a performance perspective that's really important to us.
But like I said, talking TPS is such a wild game that I've not, I very rarely say like hey we hit 65.3 transact because it just turns into war very quickly on Twitter. So I I really try to avoid that just to say that what we're trying to target here is hyper throughput, not necessarily like the throughput layer. And so this to wrap this kind of up is, it's a real set of tradeoffs you want to make,
right? Like if you need to have data availability somewhere, storing the amount of data you need to process 60 to 70,000 transactions per second, even compressed, that's a lot of data like more than any other, like more than most block chains process in their entirety. So like if you want to achieve certain throughput, you know you have to make tradeoffs or you can't. I can't store 20 megabytes per second out of serum. This is the function of the transaction size, like you can't
do anything to get around that. And so even with like some of the crazy, like some of the new like data availability things that are being added to Ethereum, it's still expensive and still would saturate all. So if you want to achieve like crazy levels, OK, well, now you're using you get into Volidium territory or like L3 territory, but you have to put
this data somewhere. And so do you want to use, you know, some other mechanism have like put that in some other things that you pay for separately? Or do you want your network, the subnet, really to own that in its entirety? And the Hyper SDK is really about providing you that option, which is maybe your community just wants to run the whole thing and they just want to achieve that throughput and they're willing to own and secure it to make that happen so.
Like my personal experiences, it's like running an organization that run loads across like 50 networks, including the Avalanche main net. My sense is, you know, like the like a subnet or? A sovereign chain or your own chain in any way starts to only make sense when your application is kind of really successful in terms of transactions per second or it needs certain high custom
features. Like you know, the perfect example is kind of like a dy DX like network processing a billion dollars in perpetual volume per per day. Already has success. Started off as a smart contract and now it makes sense to go application specific like with their own blockchain. That's when like building your own chain makes sense. It doesn't make sense if kind of you're just starting out and you hardly have any users.
And if and if you think of like that model that people are gonna be building their own chains when their applications.
Has kind of like success and the need for throughput is kind of clear then usually those kinds of parties can afford to bring 50 or 100 or 200 of their own validators, ensure data availability themselves and not need not actually even want to rely on other people for it. I totally understand your point and I think that that's why like having this spectrum that people are interested in supporting makes sense.
That being said, you know, I think there are parallels early on like other technology journeys of you know, by providing the functionality where you don't assume you need to have this like low throughput, you can just target a totally different world to begin with, can be quite an unlocking force, right. So like if I agree corralling your security, writing all these nodes cost everybody millions of dollars in USD to set up. That's quite a large commitment
for people originally. But if you can make it such that that architecture and that framework is much more compatible with like a pay as you go kind of setup as your network grows and scales such that you from the beginning can achieve a totally different world. You don't have to start like this like really slow walk on like a you know traditional L1 TPS journey if from the beginning it's just not even conceivable you could achieve that with your application use case.
So like the way I think about it sometimes and is like great if I have dial up, I'm only gonna do dial up things on the Internet. And you know you could argue that like great if broad map like broadband costs more money. I'll start with dial up make sure that people like it and then go to broadband. But if there's some things that never would look good on dial up, you gotta just go right to broadband. And so as I think about what Hyper SDK Labs, it's just a
different tradeoff, right? Maybe for like really high value D file applications, this is maybe not the best place to start. If you really prefer, maybe share liquidity and shared security.
But if you're trying to just think outside the box and do something crazy that just would never make sense economically on an L1 where you have to share all your data or whatever, I think there's a viable alternative here where you can corral security or maybe at the security at the beginning, it's just not as important to you for some reason. So I think there are tradeoffs and the whole point of my spiel
I guess is that's okay. I don't think there has to be a one thing we all agree on. Right. I guess you could also start out with like, you know, I don't know, one machine more or less like validating the subnet and then grow that over time if that's the the bottleneck. But you start with a very heavy machine there already, sort of in a way. Yeah. I mean the point here is we're providing the tool to give the, you know, virtual, the aspiring virtual machine builder choices.
That's it. All right, cool. Yeah. Patrick, thanks so much for coming on and and expanding on Hyper SDK and Never Life for us, like probably for me at least one of the most deep engineering episodes I've done. So it's super interesting and I think we hopefully we fared well maybe. Yeah, to do. Before we wrap it up, I would be great if you could like again, tell us where the Hyper SDK is right now in development and you know how how people can get involved. Yeah, great.
Yeah. Thanks again for having me. I always have a blast talking about this. Tried to cut myself off at some points, but you know, we, I love having these combos of, you know, other people want to chat about, you know, whatever is going really deep, whether that be one-on-one or whatever, very interested in in doing that. But yeah, so where we're going now is really starting that path
to production hardening. So right now as you mentioned, it's alpha level software, so you know it's not audited yet. I wouldn't say it's safe for production, but it's really fun to experiment with. So if you're a contributor, it's a great time to join the project and start contributing to it. Everything we do is fully open. So if you want to start like earning you know contributions on different projects, this is a
great one to check out. There's a lot of low, late low hanging fruit and you know, whether that be just simple testing or like kind of cleaning things up, doing basic optimization work with memory work or you know speed of execution, it's a great place to jump in. And then the other thing we're working on in association with the production hardening is adding a basic WASM executor as
a what we call programs. So although it's great to always be extremely hyperoptimized, some of the most exciting things on blockchain come from having this permissionless deployment
of programs on chain. And so we want to offer that option as well to people where maybe, you know, the vast majority of your transactions are very specific to the Hyper SDK and like implemented, but you want to offer some ability to like stitch them together or do things without guessing every possible way people may interact with your virtual machine. So that's another thing that we're really working on now. So yeah, I mean, fun time for me. A lot of coding is what that means.
And hopefully, you know, the next few months will be entering the audit process for much of this because yeah, speed doesn't mean anything if it breaks or has massive bugs, right? So that's a huge concern. All right. Then, yeah, Patrick, again, thanks so much for coming on. And yeah, hope we get to see some high performance Hyper SDK subnets when we next talk in like a few months and yeah. Thank you for to our listeners as well. 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, 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 to be behind the show and we're always happy to read them. So thanks so much and we look forward to being back next week. I want to read it.