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.