Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Patrick O'Grady: Avalanche – Building High Performance VMs With HyperSDK

Episode Date: July 28, 2023

The recent history of L2s has shown that there doesn’t need to be ‘one chain to rule them all’ or an ‘ETH killer’. Instead, a healthier approach would be to find the best solution for a specific need, taking into consideration any potential tradeoffs. Avalanche has done just that, focusing from the get-go on delivering high transaction throughput, using their unique subnet architecture, consensus protocol and warp messaging. HyperSDK continues this conviction, offering a framework for developers to spin up customisable, high performance virtual machines.We were joined by Patrick O’Grady, VP of Engineering at Ava Labs, to discuss HyperSDK and how it enables building customisable, high performance VMs on Avalanche subnets.Topics covered in this episode:Patrick’s backgroundAvalanche’s consensus protocolSubnetsAvalancheGo design conceptsWarp messagingStaking and subnet validatorsHyperSDKHyperSDK vs. Cosmos SDKAvalanche throughput parametersCustom solutions for developersEpisode links: Patrick O'Grady on TwitterAva Labs on TwitterAvalanche on TwitterThis episode is hosted by Meher Roy & Felix Lutsch. Show notes and listening options: epicenter.tv/506

Hey everyone. Today we are talking to Patrick O'Grady, who is the DP of Engineering at Ava Labs official. We'll 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 will also kind of understand the messaging protocols, the intersubnet messaging protocols that would be available in the Amlans ecosystem. So welcome Patrick. Thanks for how out of me. Excited to be here. I was telling these guys before the show that, you know, Episeter 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 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 IPRA SDK? Yeah, good question. So 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 big city. and you know, I 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. I don't if you 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 became 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 left since. But while I was here, I got first taste into crypto was actually at Stanford, there was a class of a long time ago, taught by Bology, actually, who had the 21 company where it was like connecting Bitcoin web services 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

cheap 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 micropayments 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 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 I meant to work with digital assets at scale. And 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's one of the co-founders of Avalinge, reached out to me on Twitter, actually, and was wondering like, 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 Eben 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, Avalabs as a engineer, senior engineer. And then a month then was promoted to VGVEV engineering. So That's a fun, fun few weeks, we'll say it. But yeah, so 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 what most people rave about in the community there, that this is like solving like a unique bottleneck that I guess other rockchains don't or still have. Can you just, I guess we had him in 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 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 interests had shifted to its proof of stake. So, you know, proof of work, 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 house emissions 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 couldn't have more than a couple hundred participants without the whole network becoming really. slow and not stable because of all the overhead of 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 of state? And so, you know, hearing that for the first time, many people are like, I'm not sure. And so after 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, okay, you know, when I'm starting a consensus process on a single node, what I'll do is instead of saying, okay, I'm going to go collect signatures for everybody. like if there's this round robin where 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 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 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 and 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 1,300 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 of thousands of participants, you know, 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 could have this 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. You know, back when the white paper came out, I remember reading it and thinking, oh, 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. census algo more efficient than the Navarance, right? Like this was just, just instinct at that time. How has the implementation actually been in practice? Has the consensus Algo lived up to its expectations or have you had to sacrifice many elements of the initial claims in the building a working system? It's a really good question. And I think what I've never really heard to discussed on any podcast about really any of these protocols is great. You know, you propose this paper.

Well, what does the code actually look like compared to what the paper has? So there are actually a number of changes that were made during the protocol implementation, one of which actually credit to Christian Kachid and his team at Unity 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 in 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, 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 more any actual day process he's running on the network. And everything actually uses a separate sub-proticle that was not in the white paper called Snowman. Now, without going too specifically here, two in-depth, because I don't want to, we could have an hour-long conversation about this. But the idea here is that the avalanche consensus process, like as to find 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, because 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 Appalange. 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. The Amalage DAG protocol is pretty limited in 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. actually that Cubs-in wants to modify, you know, that operation, the decks. Well, you need some shared state of which to apply that to. But if the Deg 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 Deg 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 DEC 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 complexity now or complex operations you could do on chain. But, you know, 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 can 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 readmese and the avalanche go code base, if you want to read about it. Right, yeah. So I guess we're already sort of dove into it, right? This episode is mostly about hyper SDK and subnets. Now, you already mentioned the P-J, the X chain, the C-chain. So sort of subnets that came at the launch of Avalanche, sort of out-of-the-box built by Avalabs, sort of for different purposes, right? The P-chain sort of ministering 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 of what is the subnet and maybe also what is unique about subnets in Avalanche versus like other application-specific

blockchains. Yeah, so I think that discussion around consensus kind of took a step 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 just fading in. The primary network, actually one minor correction of what you said is not actually three subnets, but is one subnet with three chains. Now, one of the most complex parts of Avalage is at the beginning, which is a huge bummer

as you try to help people or talk about Avalanche because it's the first thing you end up talking you at and then everyone's like, you know, there's these chains, like, 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 Avalov started working on the

idea of 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 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, but it's your own programming language akin to like a move or something like that, even at that time, there were still so much interest in the EVM that it just didn't make sense to really go too far field from that.

So the C chain was added, which provided the ability to deploy smart contracts. So the primary network, though, is just like any other chain in a sense where you have like a single state or virtual machine that everyone validates and participates in and is limited in scale just like any mainframe computer would be, right? It processes all state transitions. And although there's this like this cool consensus algorithm 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 3,000 or like 3 billion gas per 10 seconds. right, like who would be left, a bunch of supercomputers on like a few co-laws around the world, right? So in the same way, like your target throughput is very correlated with the number of values you have and how distributed those would be. And so some networks have chosen to have like a very high minimum throughput bar, something

like a salina. Avalanche has taken a different approach, which is trying to really maximally distribute this 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 circuit much lower there. And Avalanche lets you 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 only can have 100. But if you could have like thousands, you know, you may benefit from having like a much broader sense of or broader notion of security. Yeah. So is it, is it, 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 off with a time disadvantage vis-a-vis other L-1. I mean, compared to Ethereum, every L-1 is at a time disadvantage, like five, six years probably for Avalanche. But even if you look at the other ones, Cosmos, Polka-Dort, Solana, all of them started two or three years before Avalanche. Avalanche. Avalanche has been kind of like one of the late comers in that sense to the space. And I think that the decision to just in the beginning have an EVM chain, the C chain, was actually really great because if Avalanche would have taken 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 awaiting both on the consensus Aalvo and then on 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 its C chain, actually Avalanche has a small, like, has an ecosystem already. There's people like Trader Joe's that are kind of operating across

both the Ethereum space and Avalan space and because the code looks the same they can deploy across both and I think many initial Avalanche successes have that flavor where these are essentially projects that were trying to do something on Ethereum

and then they realized okay 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 that the first phase and now kind of

the point at which you get really involved and messed into the average ecosystem is like the second phase which is now that the consensus is stable how do we actually

build performance virtual machines that different from the EVM in that ecosystem yeah I would say on that point tons of pros and cons of that decision right so like I think

in the pros camp right we certainly were able to minimize the number of systems we had to build from scratch. And, you know, anyone that tells you like, oh, you know, you should just do everything all the time, like, has never attempted to build like a complex or super good system before. Right. But you can minimize a 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? The Avalage Mainnet launched years later than a number of these other ones, right? So 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 unfortunately 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 fan tape, you saw a bunch of 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 of 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 this VM interface, we could probably support a good amount of different virtual machine interface. And so we spent years really like dogfooding 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.

It'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. It didn't work. So now they're going to try it on suey 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 steps moving from, you know, across to L2s now instead of, you know, other alt ones.

But, yeah, it was a very interesting big decision, I think, and so far I think it's still been net positive for, for sure. Right. So I think before we actually wanted to get into high-R-S-DK, like, to just tease it again, we also wanted to first cover a bit the, like, one of the core features that sort of this architecture brings that Avalanche has that every validator also validates the main net, which is warp messaging. Can you sort of talk us through a little bit? What is word 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 costas of CK to build your own blockchain, you have L2s, you can just do that. You might as well just deploy a contract out like a Salana or Aptos or Sui. Like, how? How does some that's even fit into this? And why is Evalange 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 kind of 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 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 your contract can 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 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 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

kind of comparison here, which is in Cosmos, which was certainly a pioneer and a lot of this cross-chain messaging with IBC 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 updating for every message or like whenever there's a validator chain. 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 war 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 one subnet to another, where the validators basically on 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 summit, 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 of stake? 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 lose 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 an asset defined 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 manual intervention is done. And I think a Pyranaim 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 mechanism, you really just don't need to do that. So, but yeah, so that's the gist, which is Adelance 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 stake distribution from the, specific subnet, so some staking on that subnet, but then how much does it need to be verified by 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?

So that's correct. Yeah, so the actual primary network has nothing to do with messaging other than like basically maintain that registry list. So you could imagine a system where, hey, if I want to send a message from Subnet A to Subnet B, I have to 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 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 like the same, you may have a very high security window and say like, oh, you know, we need 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 interact with it if they want. So you're given that option when you actually implement the virtual machine. Right. So we am kind of imagining it is, you know,

I tend to think of blockchains as I mean it's kind of wrong in detail but I tend to think of like you know scribes or accountants maintaining an Excel sheet right

jointly maintaining an accent sheet that's the rawest description of a blockchain I have and just submit a Google form and then you're good. Yeah it's kind of like the easiest way to probably think of it and

so it's like the Amlanche main net, the C-chain, P-chain 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 mean net first. So you build up like this huge pool of 2000, 3,000, maybe in the future, tens of thousands of scribes

that are kind of like maintaining that that Excel sheet of the main, the main subnet, and those are like 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 kind of maintain that subnet. So if you create subnet 37, there's a record in the main Excel sheet. okay for subnet 37 these are all the accountants and that's kind of like a canonical place

where they're stools so that main place is storing who are the accountants for each of these subnets and so when I am subnet 36 and 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 percentage should have signed this message for me to accept it. It will 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. But it's really up to you how you actually want to like maintain that delivery. So like you mentioned, there's no mainnet component that 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 out of from the world of, hey, I know what L2s are, I use it's earium, 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 a subnet was invalid or something like that. Now that made change in the future based on 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 how Avalent 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 amount security. I just want to use someone else's. Whereas before that, like it was all about this notion. We're 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,

or our own sovereign community, we don't want to work with anybody else. We define our success. So it's interesting how much that spectrum has evolved since that time. But yeah, so for people that are using subnets, if you were to shut off all the values on the subnet,

it's gone. So the subnet provides its own security and it's opt-in. So 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 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 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 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 sum net was like, I don't even know what it would, like there's no control of the sunnet right. You can do whatever.

That's the best part and most complicated part about it, which is where the hyper S.K 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. 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 Pocodot, for example,

where there's resource constraints per perichain to make sure that when you're assigned to a parochane, you can't just like get totally wrecked by whatever the parochane is doing. There is no notion of that on Avalanche because it's all opt-in. So if you want to participate in a subnet, you better have the resource. is 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, fine 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 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 at once just to run a single subnet compared to like an L2 where I can just turn on a server, connect it to Ethereum, 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 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? You know, I guess unless you're like a Satoshi's vision fan in which case, I don't know to study. But I think in the case of like avalanche, what we're thinking about it, how the ecosystem has continued to change and what does the community decide to do in reflection of that based on what people are actually trying to get going. Yeah, I mean, this is such a big variety of what, I mean, when you look at the entire crypto space, and that includes like near Solana, Ethereum, L2s, Cosmos, Avalat, Olka, Dot,

maybe something even like a celestial, there's such a huge variety of what the central chain is trying to offer as synubis is, 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, okay, registering validators and tracking who validates what.

Then like maybe something higher would be chains that are trying to offer data availability. So if you have a subnet, you go and run your subnet, we'll make sure that your data is accessible will, 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 poll cutout and near regions would be, yes, you can come and run your subnet, and we will ensure that a malicious transaction never comes in. Like a central place will kind of 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 model ends up the winner. Yeah, I mean, I think the one thing I'll say in response to that is, I tweet 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 sense 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 got 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 weakening 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 Abilange 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 the anti-fragileity of everything is, I think, what excites so many people. But, yeah, I really think that this is a great transition, too, to the hyper-C-K 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 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 Avalanche, as far as I understand, at least, is this concept called, or the project called Hyper SDK. Can you just, yeah, basically tell us what is Hyperstaking? 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 this subnet EVM, which lets you like spin up an EVM. And that's really what got people's attention with submits in the first 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 EVM because it was just like this super JSON

easy concept. And then I realized one day, I don't remember specifically what it was, was. But I was like, you know, I keep saying it's so easy and straightforward. Like there's so much you could possibly do, like just go do it. I realize 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 eight and then let them go from step eight 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 statesing, which you 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 Alana's like, you know,

there's a lot of things here actually that if we just implemented one time and one opinionated way, could make it much easier to be able 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 moded EVMs, I guess. To me, that, like, is such a short fall of like what the original hope and vision were. makes me sad, I guess, but generally, you know, 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 and 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 in other of large 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 scale at all costs was really the North Star and continues to be the North Star for the hyper SDK is to say, if someone comes up and asks, what's the fastest and most scalable thing I can build on Avalange? We wanted to have an answer, at least Avalabst did.

for what that would be, and that's the hyper SDK. So maybe I actually want to start with any 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, okay, it's a Turing complete virtual machine where there's some kind of programming language

is severity with which you can write smart contracts and you can deploy them. But I think, like, you mean virtual machine. machines to be something broader. What is it? Yeah. So in the 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 Ethereum 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 broadened 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, you could say any sort of binary that implements like the avalanchego required consensus calls, and that can be anything. So you don't even need to have blocks. You don't even need to have any of this crazy stuff.

It's really just a binary that can run and communicate with avalangeco. 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 do validators actually, like, store on their disks?

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-level framework as possible that still allows for this messaging interface and shared-staking 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, 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 allows you to build these takes like some something like some things out of the blocks give you something could there also be essentially like another SDK like eating things someone built that has like print opinions about

how IEO should be done something exactly so the hyper SDK basically says you know what I described is basically super broad right it could be going could be rust it could be yeah your blocks could be potatoes like the whole idea with the hyper S K is to say, okay, you have a million options.

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 account extraction.

Like, you know, you want to, 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 syncing. You don't want to, 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 the idea of the hyper SDK with the underlying assumption that you want to go fast or you want to have a lot of transaction.

So one of the things that one naturally wants to compare hyper SDK to is the KOS SDK. You even have similar names. But in the Cosmos SDK, 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 tendermint. 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 do auctions,

here's how you manage your token but hyper-sdkate seems like has a narrower set of focus where you're not seeking to offer here's how you do governance here's how you do auctions you only say probably like

here's how you do state management here's how you do block distribution 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 staking, how to do auctions, or how to do token management or any of these financial logic in a sense. Yeah, so I think like the way I would answer that would be it could. Like there's nothing that prevents it per se, as much just. say as we would 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 in. And the idea here is that the hyper SDK is really just concerned with this like super high throughput fabric that 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 athlete. 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 SDKs, which is just handled by Athlade. The one thing, though, that is different just for very briefly, the technical audience is tendermint handles state always. So if you want to use the

Cosmosisd SDK, you're using tendermint's state. The hyper SDK provides its own state. And it's plugable. So you don't actually have to use like Avalanche Goes state orchestration at all. You can provide your own. 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 Cosmosistic key 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 tenderman handled that for you. So it provides them, I guess in some ways, less functionality on some. parts and that in other ways much more control 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 hybrid 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 that seems to be like core of your interest, right? And I guess

also like what hypersticate 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 studying from scratch, right, 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 idea is 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 somewhere. There's no way, unless you're like, I mean, maybe I'm only a 2x engineer. There are 100x engineers that know exactly what part is going to be totally my stuff as they build it. But my experience has been that this repeated benchmarking.

But 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 a network. And I'll dig into what I mean by that. So the first thing, state management. Blockchains modify 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 state transitions in a row is not well maintained, you know, that's going to be your bottle deck at some point, right? 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 sink is to sink from scratch but it takes longer to sink a block from scratch than we're producing them you're going to have problems like the network's going to die unless you like somehow snapshot it gets really complicated right and it becomes very centralized because then you have to offer disc 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 pinnings of it came from some of the work that Peter Schlaugge 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 do. 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 tri-e management and everything related to actually doing enough of the stuff you would do with the Merkel-Therty. and actually interweaves it with the key value store underneath. 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 know, you may have to store everything in memory, you may have to use NBMU 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, so like to the hyperst decay. So that means you can

either use standard P2P stuff, implement any P2P 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 where 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 SDC, like in a hyper SDC 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.

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 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 the hyper SDK breaks apart everything other than what is minimally required. to derive a deterministic result and only does this pre-process 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 TARC. 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 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 virtual machines are designed, but you could apply 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 I would clarify that particular word optimistic, that has become very charged as well. So optimistic, as far as I understand, it typically means you'll valid, 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 bridging 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 try 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 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 execute, 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 kind 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-e modifications. You don't actually have to generate the next route. All the stuff 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 basically you can take what is typically a monolithic verification, chunk and then separate that into what its constituent components are.

And the hyperccc really tries to be very specific about exactly what part of the verification it's doing when and the invariant we offer of virtual machine developers, then we will ensure that this is done correctly even if we separate all these parts. You basically give up control over how execution happens and as a result, you get more throughput. So right now, hyper-sd-k is, you know, 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, for a subnet, meaning like number of validators multiplied by, let's say, simple 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 a hundred 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 TPSs 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 high breast K 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 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 finish implementing the deferred verification. Because we've now removed 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 two nodes instead of being, you know, I'm going from. from, you know, Japan to the United States is now within, you know, a couple of feet of each other. But that's what we're targeting is in that range. And so, um, so from a performance perspective, that's really important to us. But like I said, talking TPS is such a wild game that I'm not, I very rarely say like, hey, we hit 65.3 transact because it just turns into war very quickly on Twitter. So I really try to avoid that.

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 blockchance process in their entirety. So like if you want to achieve certain throughput, you know, you have to make tradeoffs. I can't, I can't store 20 megabytes per second on Ethereum. And there's just a function of the transaction size. 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 alt. So if you want to achieve like crazy levels, okay, well, now you're using, you get into Validium territory or like L3 territory. But you have to put this data somewhere. And so do you want to use some other mechanism, have 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. My personal

experience is like learning and organizing that run nodes across like 50 networks including the avalanche main net. My sense is, you know, that 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 DYDX. like a network processing of billion dollars in perpetual volume per day,

already has success, started off as a smart contract, and now it makes sense to go application specific, right, 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 okay people are going to 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 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, corraling 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 set up 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 really

slow walk on like a traditional L1 TPS journey. If from the beginning is just not even conceivable you could achieve that with your application use case. So like the way I think about it sometimes is like great, if I have dial up, I'm only going to do dial up things on the internet. And you could argue that like great if 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 got to just go right to broadband. And so as I think about what hyper SDK allows, it's just a different trade-off, right? Maybe for like really high-value defy 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 is 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 guess I don't think there has to be 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 bottleneck. But you start with a very heavy machine there already sort of in a way. I mean, the point here is we're providing a tool to give the, you know, the aspiring virtual machine builder choices. That's it. All right, cool. Yeah, Patrick, thanks so much for coming on and expanding on hyper SDK and

Everland 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, before we wrap it up, it would be great. if you could like, again, tell us where the hyper SDK is right now in development and, you know, how people can get involved. Yeah, great.

Yeah, thanks again for having me. I always have a blast talking about this. I 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 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-hanging fruit. 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 what we call programs. So although it's great to always be extremely hyper-optimized, some of the most exciting things on blockchain come from having this, like, 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 all. audit process for much of this because, you know, speed doesn't mean anything if it breaks

or has massive bugs, right? So, you know, 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 hyperperformance hyper-sdK subnets when we next talk in like a few months. And yeah, thank you for 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 slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter.

And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.