1
00:00:13,920 --> 00:00:17,800
Hey everyone, Today we are 
talking to Patrick O'Grady who 

2
00:00:17,800 --> 00:00:22,000
is the DP of engineering. 
At our Labs official, we will be

3
00:00:22,000 --> 00:00:27,460
chatting about the Hyper SDK, 
which is kind of one of the ways

4
00:00:27,460 --> 00:00:32,659
by which the Avalanche Network 
will allow builders of Avalanche

5
00:00:32,659 --> 00:00:38,100
Subnets to have very good 
performance essentially on the 

6
00:00:38,100 --> 00:00:41,260
subnets that they build. 
So we'll get that. 

7
00:00:41,260 --> 00:00:46,420
We'll get deep into that topic 
and then if time permits, we'll 

8
00:00:46,420 --> 00:00:50,580
also kind of understand the 
messaging protocols, the 

9
00:00:50,620 --> 00:00:53,780
Intersubnet messaging protocols 
that would be available in the 

10
00:00:53,780 --> 00:00:56,550
Avalanche ecosystem. 
So welcome, Patrick. 

11
00:00:58,790 --> 00:01:00,630
Thanks for having me. 
Excited to be here. 

12
00:01:00,630 --> 00:01:04,069
I was telling these guys before 
the show that you know, 

13
00:01:04,069 --> 00:01:07,350
Epicenter was one of the first 
podcasts I started listening to.

14
00:01:07,350 --> 00:01:10,590
You and I first got into crypto 
so many years ago now, but it's 

15
00:01:10,590 --> 00:01:13,870
been great to, you know, follow 
along as all the cool guests you

16
00:01:13,870 --> 00:01:17,110
guys had on it. 
Really honored to have a chance 

17
00:01:17,110 --> 00:01:21,550
to hang out to you guys. 
So, Patrick, how did you end up 

18
00:01:21,550 --> 00:01:25,310
being VP of Engineering? 
Our labs official building. 

19
00:01:25,310 --> 00:01:27,750
I press the cake. 
Yeah, good. 

20
00:01:28,150 --> 00:01:32,830
Good question. 
So I I actually grew up far away

21
00:01:32,830 --> 00:01:36,350
from all this stuff. 
I grew up in Wisconsin, you 

22
00:01:36,350 --> 00:01:39,190
know, I didn't grow up on a farm
per se, but I certainly didn't 

23
00:01:39,190 --> 00:01:43,590
grow up in the in the big city. 
And you know I had a had a great

24
00:01:43,590 --> 00:01:45,990
childhood there like a lot of 
friends and stuff and then. 

25
00:01:46,600 --> 00:01:50,280
I watched this show when I was 
growing up called Chuck, if 

26
00:01:50,360 --> 00:01:53,200
you've ever heard of it, it was 
like on NBC in the United States

27
00:01:53,680 --> 00:01:56,640
and it was about this guy that 
like got kicked out of Stanford,

28
00:01:56,640 --> 00:01:59,560
got like a computer downloaded 
into his head and he came like a

29
00:01:59,600 --> 00:02:04,800
CIA asset or at CIA NSA asset. 
And but the part was he got 

30
00:02:04,800 --> 00:02:07,480
kicked out of Stanford, which is
like this alluring place to go 

31
00:02:07,480 --> 00:02:09,440
to. 
And so I got this itch like 

32
00:02:09,440 --> 00:02:11,160
maybe I should try to go to 
Stanford. 

33
00:02:11,160 --> 00:02:13,800
And so, you know, one thing led 
to another. 

34
00:02:13,800 --> 00:02:15,920
Unfortunately. 
Got in, got into Stanford and. 

35
00:02:16,280 --> 00:02:19,200
Came to Silicon Valley and 
haven't to haven't left since. 

36
00:02:20,000 --> 00:02:24,400
But while I was here I got first
chase into crypto was actually 

37
00:02:24,400 --> 00:02:26,920
at Stanford. 
There was a class of a long time

38
00:02:26,920 --> 00:02:32,840
ago taught by Balaji actually 
who had the 21 company where it 

39
00:02:32,840 --> 00:02:37,560
was like connecting Bitcoin web 
services to to like a web like 

40
00:02:37,560 --> 00:02:38,520
you. 
Basically the whole class was 

41
00:02:38,520 --> 00:02:41,240
like building different things 
that hooked up to the 21 minor. 

42
00:02:41,520 --> 00:02:47,160
So I actually keep. 
Like 21 minor on my desk as a 

43
00:02:47,160 --> 00:02:49,040
reminder. 
Kind of like the trajectory of 

44
00:02:49,040 --> 00:02:52,080
where we've all gone, but it was
all about like accepting micro 

45
00:02:52,080 --> 00:02:54,600
payments and everything on the 
web. 

46
00:02:54,600 --> 00:02:56,520
And so that really is what 
started things. 

47
00:02:56,520 --> 00:02:59,680
But you know, spent a while 
dabbling around in college on 

48
00:02:59,680 --> 00:03:02,000
different crypto things but 
ended up working at Coinbase 

49
00:03:02,520 --> 00:03:05,240
after college. 
And so while I was there, I 

50
00:03:05,240 --> 00:03:07,360
worked on a project called 
Rosetta which is like a 

51
00:03:07,360 --> 00:03:11,930
universal read and write. 
Interface or open source 

52
00:03:11,930 --> 00:03:13,850
specification for any 
blockchain. 

53
00:03:14,450 --> 00:03:17,850
And the idea there was, you 
know, Coinbase wanted to list as

54
00:03:17,850 --> 00:03:20,690
many assets as possible, but a 
lot of times there was a ton of 

55
00:03:20,690 --> 00:03:23,370
overhead of actually adding 
those assets, right? 

56
00:03:23,370 --> 00:03:26,970
So could could we actually turn 
the tables and have the assets 

57
00:03:27,290 --> 00:03:29,690
integrate something that would 
allow Coinbase to just add them 

58
00:03:29,690 --> 00:03:32,130
automatically? 
And that was the idea with 

59
00:03:32,130 --> 00:03:33,970
Rosetta. 
But while I was working on that,

60
00:03:34,130 --> 00:03:37,170
you know, my interest was always
going back into L1. 

61
00:03:37,250 --> 00:03:40,250
I really wanted to get into like
protocol development. 

62
00:03:41,010 --> 00:03:43,890
But I felt like a lot of what 
happened at Coinbase really 

63
00:03:43,890 --> 00:03:46,930
prepared me for that. 
So I, you know, learned a lot 

64
00:03:46,930 --> 00:03:49,330
about what it meant to work with
digital assets at scale. 

65
00:03:49,810 --> 00:03:51,930
And we know what were the types 
of features that people really 

66
00:03:51,930 --> 00:03:54,850
cared about, whether that be 
exchanges or or users that 

67
00:03:54,850 --> 00:03:58,610
Coinbase had. 
And so funny enough, Kevin, who 

68
00:03:58,610 --> 00:04:02,210
is the one of the cofounders of 
Avalanche, reached out to me on 

69
00:04:02,210 --> 00:04:05,250
Twitter actually and was 
wondering like, hey, have you 

70
00:04:05,250 --> 00:04:06,770
heard of Avalanche? 
Like what? 

71
00:04:06,970 --> 00:04:08,370
What do you think about it? 
And. 

72
00:04:09,530 --> 00:04:13,810
A few of the my mentors at 
Coinbase actually had known Evan

73
00:04:14,570 --> 00:04:17,010
from previous work, you know, 
throughout the years. 

74
00:04:17,250 --> 00:04:19,730
And you know, I was really 
interested in working with great

75
00:04:19,730 --> 00:04:23,050
people and so decided to chat 
with them and one thing went to 

76
00:04:23,050 --> 00:04:26,370
another and joined Avalanche, 
actually joined Avalanche at the

77
00:04:26,370 --> 00:04:31,490
labs as a engineer, senior 
engineer and then a month end 

78
00:04:31,490 --> 00:04:36,210
was promoted to VQ Engineering. 
So that was a fun. 

79
00:04:36,910 --> 00:04:40,110
Fun few weeks, we'll say it. 
But yeah, so that's that's how I

80
00:04:40,110 --> 00:04:43,750
got to where I am now. 
Awesome, very, very impactful 

81
00:04:43,750 --> 00:04:46,830
Twitter message there. 
So, yeah, really cool. 

82
00:04:46,830 --> 00:04:53,270
I think obviously I guess the 
main thing in Avalanche is its 

83
00:04:53,270 --> 00:04:57,270
consensus protocol sort of the 
main innovation I would say and 

84
00:04:58,550 --> 00:05:01,950
that's that's what most people 
rave about in the community 

85
00:05:01,990 --> 00:05:05,590
there that this is like solving 
like a unique bottleneck that I 

86
00:05:05,590 --> 00:05:09,680
guess other. 
Rock chains don't or you still 

87
00:05:09,680 --> 00:05:12,400
have. 
Can you just, I guess we had 

88
00:05:12,400 --> 00:05:14,680
Amin on already and talk about 
this, but I guess just for the 

89
00:05:14,680 --> 00:05:16,600
context, it would be nice to 
hear again from you. 

90
00:05:17,000 --> 00:05:20,960
You know, why is avalanche 
consensus so important? 

91
00:05:21,840 --> 00:05:24,240
Yeah. 
So I want to preface this and 

92
00:05:24,240 --> 00:05:27,360
say like, you know, I, I 
definitely joined a little after

93
00:05:27,360 --> 00:05:30,280
this major innovation. 
So I don't want to take credit 

94
00:05:30,280 --> 00:05:33,000
for any of this. 
But yeah, so the idea, right, 

95
00:05:33,000 --> 00:05:35,240
is, you know, when Avalanche 
came out. 

96
00:05:35,960 --> 00:05:38,120
A lot of interest had shifted 
towards proof of state. 

97
00:05:38,360 --> 00:05:41,680
So you know proof of work we we 
think it's interesting it has 

98
00:05:41,680 --> 00:05:44,680
some interesting properties but 
the amount of like the 

99
00:05:44,680 --> 00:05:48,800
centralization of mining parties
and like how much green 

100
00:05:48,880 --> 00:05:51,280
greenhouse submissions that were
associated with the industry was

101
00:05:51,280 --> 00:05:54,480
not great. 
And so like but Proof of stake 

102
00:05:54,480 --> 00:05:57,320
at the same time, at that around
that time you know you did, you 

103
00:05:57,320 --> 00:05:59,520
couldn't have more than a couple
100 participants without the 

104
00:05:59,520 --> 00:06:02,960
whole network becoming really 
slow and unstable because of all

105
00:06:02,960 --> 00:06:05,410
the overhead. 
Network messaging between 

106
00:06:05,410 --> 00:06:09,770
different parties and everything
along that kind of thought 

107
00:06:09,770 --> 00:06:13,010
pattern. 
And so the innovation with 

108
00:06:13,010 --> 00:06:19,010
Avalanche was what if everyone 
didn't have to communicate but 

109
00:06:19,010 --> 00:06:24,090
you could still use proof stake.
And so you know hearing that for

110
00:06:24,090 --> 00:06:26,610
the first time, many people like
I'm not sure. 

111
00:06:27,450 --> 00:06:32,610
And so after you know a good bit
of research and simulation, 

112
00:06:32,610 --> 00:06:35,690
testing, everything. 
What ended up coming out was 

113
00:06:35,690 --> 00:06:42,090
that you could have a sampling 
based gossip protocol that was 

114
00:06:42,090 --> 00:06:45,850
probabilistic but pretty, you 
know, could be parameterized to 

115
00:06:45,850 --> 00:06:50,210
be pretty safe that was 
dramatically more efficient in 

116
00:06:50,210 --> 00:06:54,450
network complexity than 
traditional PBFT like 

117
00:06:54,770 --> 00:06:57,810
applications. 
Where there were two interesting

118
00:06:57,810 --> 00:07:00,250
properties, one was that there 
was no. 

119
00:07:00,680 --> 00:07:02,520
Bottleneck at any point in the 
protocol. 

120
00:07:02,520 --> 00:07:05,040
So like you didn't one node 
didn't have to communicate with 

121
00:07:05,040 --> 00:07:11,080
everybody ever. 
The second one was that not a 

122
00:07:11,080 --> 00:07:14,240
single party rarely had to talk 
to the entire network. 

123
00:07:14,840 --> 00:07:18,800
So, like, what that meant was, 
OK, you know, when I'm starting 

124
00:07:18,800 --> 00:07:22,240
the consensus process on a 
single node, what I'll do is 

125
00:07:22,240 --> 00:07:24,720
instead of saying, OK, I'm going
to go collect signatures for 

126
00:07:24,720 --> 00:07:27,200
everybody or like, if there's 
this round Robin where you like 

127
00:07:27,200 --> 00:07:28,480
everyone sends something to 
someone. 

128
00:07:28,840 --> 00:07:31,480
You instead say I'm going to 
pick 20 people at random by 

129
00:07:31,480 --> 00:07:34,800
stake weight ask them, hey, what
do you think about this block 

130
00:07:34,800 --> 00:07:37,720
right now or like what's your 
preference, They send it back 

131
00:07:37,760 --> 00:07:41,480
and if some you know, alpha of 
those of those folks respond the

132
00:07:41,480 --> 00:07:44,000
same way, I consider that to be 
successful. 

133
00:07:44,520 --> 00:07:48,240
And then if I do that, you know 
beta times in a row, we're good.

134
00:07:49,000 --> 00:07:50,960
And so people looking at that 
would say, well, you know, 

135
00:07:51,360 --> 00:07:54,400
conceptually that's actually 
pretty straightforward and and 

136
00:07:54,400 --> 00:07:56,760
like you know, you can follow 
what I just said. 

137
00:07:57,480 --> 00:08:01,360
But what that allows right, is a
totally different, like network 

138
00:08:01,360 --> 00:08:05,200
complexity into I think what is,
Forgive me if I'm mistaken, but 

139
00:08:05,200 --> 00:08:08,960
log, log, log N of nodes. 
So like in the case where you 

140
00:08:08,960 --> 00:08:12,320
have on average, let's say on 
main net, every sample is 20 

141
00:08:12,320 --> 00:08:15,560
peers and then you end up doing 
20 samples. 

142
00:08:15,840 --> 00:08:18,720
You only end up actually ever 
communicating with at most 400 

143
00:08:18,720 --> 00:08:22,360
nodes to finalize something in 
the, you know, the base case or 

144
00:08:22,360 --> 00:08:26,640
the best case, whereas you know 
there's over 1300 nodes on the 

145
00:08:26,640 --> 00:08:29,640
network. 
So even in the current network 

146
00:08:29,640 --> 00:08:32,000
size you can see how much more 
efficient it is on the 

147
00:08:32,000 --> 00:08:34,039
networking layer. 
And so if you actually want to 

148
00:08:34,039 --> 00:08:37,039
have a proof of stake network 
with, you know, thousands and 

149
00:08:37,039 --> 00:08:39,679
thousands of participants, you 
know it. 

150
00:08:39,799 --> 00:08:43,919
It provides that optionality 
without leading to a delay in 

151
00:08:43,919 --> 00:08:45,800
finality. 
So blocks on the avalanche 

152
00:08:45,800 --> 00:08:49,000
network from time to creation to
time to finality typically 

153
00:08:49,000 --> 00:08:52,840
occurs in about one second. 
So the fact that you can have 

154
00:08:52,840 --> 00:08:56,160
this like huge base of 
participation without giving up.

155
00:08:56,760 --> 00:08:59,320
What people really want, which 
is this really, really fast 

156
00:08:59,320 --> 00:09:01,680
finality that is at the speed of
the Internet. 

157
00:09:02,520 --> 00:09:09,360
It offers those properties. 
Back when the white paper came 

158
00:09:09,360 --> 00:09:14,560
out, I remember reading it and 
thinking this is like the end 

159
00:09:14,560 --> 00:09:18,120
state of consensus algorithms. 
I even had the thought. 

160
00:09:18,720 --> 00:09:21,360
I cannot prove it, but it feels 
like you cannot have a 

161
00:09:21,360 --> 00:09:24,970
consensus. 
I'll go more efficient than the 

162
00:09:24,970 --> 00:09:27,570
avalanche, right? 
Like this was just just instinct

163
00:09:27,570 --> 00:09:31,050
at that time. 
How has the implementation 

164
00:09:32,010 --> 00:09:35,130
actually been in practice? 
Has the consensus are even lived

165
00:09:35,130 --> 00:09:39,530
up to its expectations? 
Or have you had to sacrifice 

166
00:09:39,530 --> 00:09:46,730
many elements of the initial 
claims in order to build a 

167
00:09:46,730 --> 00:09:49,880
working system? 
It's a really good question and 

168
00:09:49,880 --> 00:09:53,200
I think what I've never really 
heard discussed on any podcast 

169
00:09:53,200 --> 00:09:55,200
about really any of these 
protocols is great. 

170
00:09:55,200 --> 00:09:59,600
You know, you proposed this 
paper, what does the code 

171
00:09:59,600 --> 00:10:01,720
actually look like compared to 
what the paper has? 

172
00:10:02,560 --> 00:10:05,960
So they're actually a number of 
changes that were made during 

173
00:10:05,960 --> 00:10:09,800
the protocol implementation, one
of which actually a credit to 

174
00:10:10,480 --> 00:10:14,040
Christian Koshid and his team at
Uni Byrne, wrote a paper I think

175
00:10:14,040 --> 00:10:16,680
last year about some issue with 
the paper which was never 

176
00:10:16,680 --> 00:10:19,730
actually implemented. 
Because that was also discovered

177
00:10:19,770 --> 00:10:22,770
during the protocol process, but
I'm not going to cover that. 

178
00:10:22,770 --> 00:10:25,210
You should take a look, search 
it if you want to check that 

179
00:10:25,210 --> 00:10:25,970
out. 
Yeah. 

180
00:10:25,970 --> 00:10:29,410
So the paper itself was actually
about a number of different sub 

181
00:10:29,410 --> 00:10:31,530
protocols within the avalanche 
protocol. 

182
00:10:31,690 --> 00:10:34,010
So we call that like the snow 
family of consensus. 

183
00:10:34,290 --> 00:10:37,010
And then on top of that, the 
Avalanche consensus process was,

184
00:10:37,010 --> 00:10:40,130
which really defined how 
Avalanche worked over a day 

185
00:10:40,610 --> 00:10:44,140
well. 
Four months ago the X chain 

186
00:10:44,140 --> 00:10:46,540
which was the one the chain 
running the day was actually 

187
00:10:46,540 --> 00:10:49,940
fully sunset. 
So there are no there's no more 

188
00:10:49,940 --> 00:10:54,300
any like actual day processes 
running on the network and 

189
00:10:54,300 --> 00:10:57,380
everything actually uses a 
separate sub protocol that was 

190
00:10:57,380 --> 00:10:59,220
not in the white paper called 
Snowman. 

191
00:10:59,740 --> 00:11:03,140
Now without going too 
specifically here too too in 

192
00:11:03,140 --> 00:11:05,860
depth cuz I don't want to, we 
could have hour long 

193
00:11:05,860 --> 00:11:09,730
conversation about this. 
But the idea here is that the 

194
00:11:09,850 --> 00:11:13,250
avalanche consensus process like
as defined in the white paper, 

195
00:11:13,570 --> 00:11:17,570
really was about connecting or 
basically having at any 

196
00:11:17,570 --> 00:11:21,650
particular height multiple 
vertices that could compose a 

197
00:11:21,650 --> 00:11:25,170
single, you know, single four 
chain, let's say. 

198
00:11:25,410 --> 00:11:28,090
So the X chain you know there 
were just like any day had 

199
00:11:28,090 --> 00:11:30,650
multiple vertices at a 
particular height, you know, 

200
00:11:30,850 --> 00:11:33,970
children of those vertices or 
children of that would then 

201
00:11:33,970 --> 00:11:35,770
refer to those vertices. 
But you could have like 

202
00:11:35,770 --> 00:11:39,800
conflicting transactions. 
And as long as like transactions

203
00:11:39,800 --> 00:11:42,920
didn't double spend each other, 
like things would eventually get

204
00:11:42,920 --> 00:11:45,040
finalized. 
But like, you know, because of 

205
00:11:45,040 --> 00:11:48,000
network synchrony and like 
communication properties, right,

206
00:11:48,000 --> 00:11:50,320
Like you may have duplicate 
transactions at different 

207
00:11:50,320 --> 00:11:52,520
vertices, right? 
Like cuz if you had a vertex 

208
00:11:52,520 --> 00:11:56,600
over here, you had a vertex over
here, you know, and the vertexes

209
00:11:56,600 --> 00:11:58,440
were seen independently. 
There's just a lot of really 

210
00:11:58,440 --> 00:12:00,520
complex scenarios that that had 
to handle. 

211
00:12:01,080 --> 00:12:04,230
Snowman on the other hand. 
Was about having a linear chain 

212
00:12:04,230 --> 00:12:06,510
like most people understand, 
where there's only one 

213
00:12:06,510 --> 00:12:08,590
particular height, one 
container. 

214
00:12:09,270 --> 00:12:11,950
Now that was required for like 
the C chain and the P chain 

215
00:12:11,950 --> 00:12:14,430
which just operated as normal 
chains on Avalanche. 

216
00:12:15,590 --> 00:12:20,150
And what we found was that 
people really used the linear 

217
00:12:20,150 --> 00:12:24,150
chains a lot more than they used
the DAG related things because 

218
00:12:24,150 --> 00:12:28,230
you could do a lot more on it 
are the Avalanche DAG protocol 

219
00:12:28,230 --> 00:12:30,970
was pretty limited. 
And that you couldn't have like 

220
00:12:30,970 --> 00:12:33,850
shared state that was mutated by
different transactions. 

221
00:12:34,370 --> 00:12:36,610
So in the case of, let's say the
C chain, right? 

222
00:12:36,610 --> 00:12:39,090
Like you have a smart contract, 
you know everyone's balances are

223
00:12:39,090 --> 00:12:42,410
in a decks and the next 
transaction that comes in wants 

224
00:12:42,410 --> 00:12:46,810
to modify, you know that that 
operation, the decks, well, you 

225
00:12:46,810 --> 00:12:49,250
need some shared state of which 
to apply that to. 

226
00:12:50,010 --> 00:12:53,730
But if the deck never actually 
has like a canonical state at 

227
00:12:53,730 --> 00:12:55,930
any point, how do you even do 
that? 

228
00:12:55,930 --> 00:12:58,610
You can't, right? 
So you end up really limiting. 

229
00:12:58,970 --> 00:13:02,090
The functionality with the day, 
and you're sacrificing that for 

230
00:13:02,090 --> 00:13:05,130
throughput, which is the hope 
that says, oh, you know, if 

231
00:13:05,130 --> 00:13:07,690
you're just doing a ton of 
transfers, great a day could be 

232
00:13:07,690 --> 00:13:09,930
more efficient because you 
actually can like sequence 

233
00:13:09,930 --> 00:13:12,890
things concurrently. 
You don't actually have to like 

234
00:13:13,010 --> 00:13:15,210
distribute everything to a 
single block and then vote on 

235
00:13:15,210 --> 00:13:17,250
that. 
You can just shoot out what you 

236
00:13:17,250 --> 00:13:19,810
got and then put that in 
consensus right away. 

237
00:13:20,770 --> 00:13:25,530
But you give up some, you know 
some some complexity now or 

238
00:13:25,530 --> 00:13:27,330
complex operations you could do 
on chain. 

239
00:13:27,960 --> 00:13:31,960
But you know there this is 
really summarizing that there 

240
00:13:31,960 --> 00:13:35,280
are ways to try and add that 
functionality to a day. 

241
00:13:35,760 --> 00:13:39,800
But we felt that instead 
proceeding down the path of 

242
00:13:39,800 --> 00:13:44,000
Snowman and then adding some 
advancements to Snowman called 

243
00:13:44,000 --> 00:13:47,520
Snowman Plus Plus was much 
better because that actually 

244
00:13:47,520 --> 00:13:50,600
unlocked the use of warp 
messaging which is the cross 

245
00:13:50,600 --> 00:13:52,920
subnet communication protocol 
now. 

246
00:13:53,300 --> 00:13:57,020
I could kind of touch on how all
these are connected, but Long 

247
00:13:57,020 --> 00:14:00,140
story short, the protocol has 
evolved quite a bit from the 

248
00:14:00,140 --> 00:14:03,220
original white paper and most of
those specifications of the 

249
00:14:03,260 --> 00:14:07,740
evolutions are now in read me's 
in the Avalanche Go code base if

250
00:14:07,740 --> 00:14:11,220
you want to read about. 
Right. 

251
00:14:11,220 --> 00:14:13,260
Yeah. 
So I guess we're already sort of

252
00:14:13,260 --> 00:14:15,780
dove into it, right? 
This episode is mostly about 

253
00:14:16,140 --> 00:14:20,260
Hyper SDK and and subnets. 
Now, you already mentioned the 

254
00:14:20,260 --> 00:14:22,580
PJ, the action, the C chain, so 
sort of. 

255
00:14:24,130 --> 00:14:28,690
Subnets that came at the launch 
of Avalanche sort of 

256
00:14:28,850 --> 00:14:33,770
out-of-the-box built by Everlabs
sort of for different purposes, 

257
00:14:33,770 --> 00:14:34,690
right. 
The P chain sort of 

258
00:14:34,690 --> 00:14:38,810
administering the validators and
other subnets and the C chain 

259
00:14:38,810 --> 00:14:42,490
being like sort of the first EVM
chain for smart contracts. 

260
00:14:43,690 --> 00:14:46,890
But yeah, let's maybe just take 
it back a bit and. 

261
00:14:47,410 --> 00:14:51,330
Explain a bit what is a subnet 
and then maybe also what is 

262
00:14:51,330 --> 00:14:54,810
unique about subnets in 
Avalanche versus like other 

263
00:14:55,250 --> 00:14:57,530
application specific 
blockchains. 

264
00:14:58,530 --> 00:15:00,450
Yeah. 
So that I think that discussion 

265
00:15:00,450 --> 00:15:03,410
on consensus kind of took a stab
a little bit too far. 

266
00:15:03,490 --> 00:15:06,730
We'll back it up a bit. 
So yeah, Avalanche has this 

267
00:15:06,730 --> 00:15:09,770
notion of a primary network. 
So the primary network, if you 

268
00:15:09,770 --> 00:15:12,330
validate or stake on Avalanche, 
that's what you're participating

269
00:15:12,330 --> 00:15:14,450
in? 
The primary network, actually 

270
00:15:14,450 --> 00:15:17,250
one minor correction, what you 
said is not actually 3 subnets, 

271
00:15:17,490 --> 00:15:19,730
but is 1 subnet with three 
chains. 

272
00:15:20,530 --> 00:15:23,010
Now one of the most complex 
parts of Avalanche is at the 

273
00:15:23,010 --> 00:15:27,410
beginning, which is a huge 
bummer as you try to like help 

274
00:15:27,410 --> 00:15:30,050
people or talk about Avalanche 
because it's the first thing you

275
00:15:30,050 --> 00:15:31,730
end up talking about. 
And then everyone's like, you 

276
00:15:31,730 --> 00:15:34,370
know, there's these chains, like
what is they're staking, like 

277
00:15:34,370 --> 00:15:37,370
how is this all connected? 
So the whole notion of a subnet 

278
00:15:37,490 --> 00:15:39,290
and the primary network is a 
subnet. 

279
00:15:39,750 --> 00:15:42,670
Is that a subnet defines like 
the set of validators that are 

280
00:15:42,670 --> 00:15:45,190
participating. 
And then within a subnet you 

281
00:15:45,190 --> 00:15:47,310
have chains. 
Now those chains can have 

282
00:15:47,310 --> 00:15:50,990
independent execution, but the 
chains within a subnet can 

283
00:15:50,990 --> 00:15:54,150
communicate easily between each 
other because they're validated 

284
00:15:54,150 --> 00:15:56,510
by the same group. 
So. 

285
00:15:56,990 --> 00:15:59,910
But the idea here is when 
Avalanche was launched. 

286
00:15:59,910 --> 00:16:02,150
Or like when Avala started 
working on the idea of the 

287
00:16:02,150 --> 00:16:06,280
Avalanche just having. 
Basic functionality in the 

288
00:16:06,280 --> 00:16:08,360
primary network. 
So in the case of maybe just 

289
00:16:08,360 --> 00:16:13,080
staking or transfers didn't seem
appealing or a way to really 

290
00:16:13,360 --> 00:16:17,960
test out you know avalanche 
consensus in a in a distributed 

291
00:16:17,960 --> 00:16:20,960
system. 
And so the call or decision was 

292
00:16:20,960 --> 00:16:23,240
made that like it would make 
sense to have smart contract 

293
00:16:23,240 --> 00:16:26,200
functionality too because that's
really what people wanted. 

294
00:16:26,440 --> 00:16:30,560
And you know, while an entire 
virtual machine could be created

295
00:16:30,560 --> 00:16:32,840
from scratch with your own 
programming language, akin to 

296
00:16:32,840 --> 00:16:34,240
like a move or something like 
that. 

297
00:16:35,030 --> 00:16:37,110
Even at that time, there was 
still so much interest in the 

298
00:16:37,190 --> 00:16:40,350
EVM that it it just didn't make 
sense to really go too far 

299
00:16:40,350 --> 00:16:42,990
afield from that. 
So the C chain was added which 

300
00:16:43,510 --> 00:16:46,430
you know provided the ability to
deploy smart contracts. 

301
00:16:46,790 --> 00:16:50,590
So the primary network though is
just like any other chain in the

302
00:16:50,590 --> 00:16:53,390
sense where you have like a 
single state or virtual machine 

303
00:16:53,390 --> 00:16:56,870
that everyone validates and 
participates in and is limited 

304
00:16:56,910 --> 00:17:01,170
in in scale just like. 
You know any like any mainframe 

305
00:17:01,170 --> 00:17:04,050
computer would be right, like 
all it processes Allstate 

306
00:17:04,050 --> 00:17:06,530
transitions and like although 
there's this like this cool 

307
00:17:06,530 --> 00:17:10,089
consensus average from 
underneath, you know, you have 

308
00:17:10,089 --> 00:17:14,930
to balance resource usage with 
like what your expectations of 

309
00:17:15,530 --> 00:17:18,690
actual like participation are. 
Otherwise it becomes like the 

310
00:17:18,690 --> 00:17:20,650
Super centralized thing really 
fast, right? 

311
00:17:20,650 --> 00:17:23,970
So, you know, if Ethereum said, 
hey, instead of, you know, 

312
00:17:23,970 --> 00:17:27,250
targeting 15 million gas per 10 
seconds, we're going to target 

313
00:17:27,250 --> 00:17:31,350
3000. 
For like a three 3 billion gas 

314
00:17:31,630 --> 00:17:33,550
per 10 seconds, right? 
Like who would be left? 

315
00:17:33,710 --> 00:17:36,590
A bunch of supercomputers on 
like a few colos around the 

316
00:17:36,590 --> 00:17:40,110
world, right? 
So in the same way, like your 

317
00:17:40,110 --> 00:17:44,230
target throughput is very 
correlated with the number of 

318
00:17:44,230 --> 00:17:46,630
valuators you have and how 
distributed those will be. 

319
00:17:46,910 --> 00:17:50,670
And so some networks have chosen
to have like a very high minimum

320
00:17:50,790 --> 00:17:52,670
throughput bar. 
Something like a Solana 

321
00:17:53,030 --> 00:17:55,350
Avalanche has taken a different 
approach which is trying to 

322
00:17:55,350 --> 00:17:57,750
really maximally distribute 
this. 

323
00:17:58,220 --> 00:18:02,620
Like primary network and then on
the side have this notion of 

324
00:18:02,620 --> 00:18:07,140
subnets which lets people create
these specialized areas for 

325
00:18:07,140 --> 00:18:10,340
blockchain execution that maybe 
have very different tradeoffs, 

326
00:18:10,340 --> 00:18:13,860
whether that be different types 
of virtual machines which I'll 

327
00:18:13,860 --> 00:18:17,580
go into, or just having very 
different throughput targets. 

328
00:18:17,580 --> 00:18:21,300
So like, hey, maybe for the 
subnet you actually need to have

329
00:18:21,300 --> 00:18:23,500
a much more powerful machine 
than you would ever need for the

330
00:18:23,500 --> 00:18:27,780
primary network, but because. 
You know, we want to maximally 

331
00:18:27,780 --> 00:18:31,140
distribute like the 
participation in the primary 

332
00:18:31,140 --> 00:18:32,820
network. 
We keep the throughput much 

333
00:18:32,820 --> 00:18:36,700
lower there, and Avalanche lets 
you get like actually do that 

334
00:18:36,700 --> 00:18:38,940
distribution right? 
Like if you can only ever have 

335
00:18:38,940 --> 00:18:42,660
100 validators, you may not be 
as interested in like having 

336
00:18:42,660 --> 00:18:45,300
this crazy distribution of 
participation, right? 

337
00:18:45,300 --> 00:18:48,140
Because why, right, if you have,
if you're only going to have 

338
00:18:48,140 --> 00:18:51,340
100, but if you could have like 
thousands. 

339
00:18:52,130 --> 00:18:54,530
You know, you may benefit from 
having like a much broader 

340
00:18:54,530 --> 00:18:56,970
senses or broader notion of 
security. 

341
00:18:58,690 --> 00:19:01,930
Yeah. 
So is it is it correct to think 

342
00:19:01,930 --> 00:19:05,170
that you know like when you look
at kind of the development of 

343
00:19:05,170 --> 00:19:10,290
Avalanche, in some senses 
Avalanche started our off with a

344
00:19:10,290 --> 00:19:16,810
time disadvantage Visa V other 
other ones, I mean compared to 

345
00:19:16,810 --> 00:19:20,730
Ethereum every L1 is at a time 
disadvantage like 5-6 years 

346
00:19:20,730 --> 00:19:23,190
probably for Avalanche. 
But even if you look at the 

347
00:19:23,190 --> 00:19:29,790
other ones, Cosmos, Polka, dot, 
Solana, all of them started two 

348
00:19:29,790 --> 00:19:33,630
or three years before Avalanche.
Avalanche has been kind of like 

349
00:19:33,630 --> 00:19:37,390
one of the one of the late 
comers in that sense to the 

350
00:19:37,390 --> 00:19:40,630
space. 
And and I think that the 

351
00:19:40,670 --> 00:19:45,670
decision to just in the 
beginning have have an EVM chain

352
00:19:45,670 --> 00:19:52,260
that the C chain was, was 
actually really great because if

353
00:19:52,260 --> 00:19:55,580
Avalanche would have taken the 
the target of actually building 

354
00:19:55,580 --> 00:19:58,900
a new consensus algorithm and 
then building like new kinds of 

355
00:19:58,900 --> 00:20:01,700
virtual machines at the same 
time, something which something 

356
00:20:01,700 --> 00:20:05,020
like a Solana date, right. 
Both they were innovating both 

357
00:20:05,020 --> 00:20:10,220
on the consensus, I will go and 
then on how how financial logic 

358
00:20:10,220 --> 00:20:13,060
would work on the chain. 
Avalanche would have taken both 

359
00:20:13,060 --> 00:20:17,700
of those targets simultaneously.
Probably may have been too much.

360
00:20:18,280 --> 00:20:22,200
By just taking the EVM and doing
it C chain, actually Avalanche 

361
00:20:23,360 --> 00:20:26,320
has a small has an ecosystem 
already. 

362
00:20:26,320 --> 00:20:29,880
There's people like Trader Joe's
that are kind of operating 

363
00:20:29,880 --> 00:20:33,040
across both the Etherium space 
and Avalanche space. 

364
00:20:33,040 --> 00:20:35,880
And because the code looks the 
same, they can deploy across 

365
00:20:36,440 --> 00:20:39,680
both. 
And I think many, many initial 

366
00:20:39,680 --> 00:20:43,520
Avalanche successes have that 
flavor where these are 

367
00:20:43,520 --> 00:20:45,720
essentially projects that were 
trying to do something on 

368
00:20:45,720 --> 00:20:48,560
Ethereum and then they realized,
OK, we could do it on the 

369
00:20:48,560 --> 00:20:53,240
Avalanche C chain and either get
a new community or we could get 

370
00:20:53,240 --> 00:20:55,480
cheaper transactions or faster 
transactions. 

371
00:20:56,080 --> 00:20:58,760
So that feels to me like the 
first phase. 

372
00:20:58,800 --> 00:21:03,800
And now kind of the point at 
which you get really involved 

373
00:21:03,800 --> 00:21:06,400
and messed into the Avalanche 
system is like the second phase,

374
00:21:06,400 --> 00:21:11,120
which is now that the consensus 
is stable, how do we actually 

375
00:21:11,120 --> 00:21:15,290
build performant virtual 
machines different from the EVM 

376
00:21:15,290 --> 00:21:19,490
in that ecosystem? 
I would say on that point, tons 

377
00:21:19,490 --> 00:21:21,770
of pros and cons of that 
decision, right. 

378
00:21:21,770 --> 00:21:27,210
So I think in the pros camp, 
right, we certainly were able to

379
00:21:27,450 --> 00:21:30,850
minimize the number of systems 
we had to build from scratch and

380
00:21:31,250 --> 00:21:33,970
anyone that tells you like you 
should just do everything all 

381
00:21:33,970 --> 00:21:36,930
the time. 
Has never attempted to build 

382
00:21:36,930 --> 00:21:38,970
like a complex distributed 
system before, right? 

383
00:21:38,970 --> 00:21:41,970
If you can minimize the number 
of things you have to build kind

384
00:21:41,970 --> 00:21:45,010
of to prove out the major ideas,
like you should totally take 

385
00:21:45,010 --> 00:21:48,690
that chance as long as it's 
differentiated at the same time 

386
00:21:48,690 --> 00:21:51,370
still. 
So I think that was something to

387
00:21:51,370 --> 00:21:54,010
really help us get off the 
ground so far behind, which I 

388
00:21:54,010 --> 00:21:56,130
don't think many people really 
even realize, right? 

389
00:21:56,130 --> 00:21:59,650
Like the Avalanche main that 
launched years later than a 

390
00:21:59,650 --> 00:22:00,930
number of these other ones, 
right. 

391
00:22:00,930 --> 00:22:03,330
So like when people are 
comparing us directly, like, oh,

392
00:22:03,330 --> 00:22:04,610
you know, there's still so much 
to do. 

393
00:22:04,610 --> 00:22:06,610
It's like. 
Yeah, I wish I didn't have to 

394
00:22:06,610 --> 00:22:09,810
sleep, but fortunately my body 
shuts down at some point. 

395
00:22:10,010 --> 00:22:13,970
But on the con side, I think at 
the same time people look at us 

396
00:22:13,970 --> 00:22:16,450
and say, oh, it's just another 
EVM for right. 

397
00:22:16,450 --> 00:22:18,770
Like, oh, you know, you saw a 
phantom, you saw punches, 

398
00:22:19,010 --> 00:22:20,730
whatever, over the period of 
time. 

399
00:22:20,730 --> 00:22:22,090
Like, it's just another one of 
those. 

400
00:22:22,570 --> 00:22:27,010
And so, you know, there's a lot 
of work we're doing that people 

401
00:22:27,010 --> 00:22:29,370
are just like, well, how much 
work is it actually to, like, 

402
00:22:29,370 --> 00:22:31,930
maintain a fork of the EVM? 
Like, it seems like it shouldn't

403
00:22:31,930 --> 00:22:33,050
be this hard, right? 
And. 

404
00:22:34,140 --> 00:22:37,300
They're totally missing the 
point where most of our work 

405
00:22:37,300 --> 00:22:39,980
goes into. 
So like for example on the EVM 

406
00:22:39,980 --> 00:22:44,420
front, we actually implemented 
that on top of the VM interface 

407
00:22:44,420 --> 00:22:47,380
that Avalanche Go provides for 
any virtual machine to use. 

408
00:22:47,940 --> 00:22:51,020
And we figured, you know, we 
didn't copy any of the 

409
00:22:51,020 --> 00:22:54,140
networking, the consensus, you 
know, we didn't connect any of 

410
00:22:54,140 --> 00:22:55,900
that. 
We used all of our own stuff. 

411
00:22:56,020 --> 00:23:00,340
And the idea was if we could 
support Ethereum or like the EVM

412
00:23:00,340 --> 00:23:02,620
functionality on top of this VM 
interface. 

413
00:23:03,130 --> 00:23:05,610
So we could probably support a 
good amount of different virtual

414
00:23:05,610 --> 00:23:08,210
machine interface. 
And so we spent years really 

415
00:23:08,210 --> 00:23:10,890
like dog fooding that and 
optimizing that layer. 

416
00:23:10,890 --> 00:23:16,290
And so I think we're currently 
on version 26 of the integration

417
00:23:16,410 --> 00:23:19,170
between a virtual machine and 
Avalanche Go. 

418
00:23:19,370 --> 00:23:22,970
And to the Hyper SDK, which 
we'll talk about in a bit, is 

419
00:23:22,970 --> 00:23:24,810
that's how it actually 
communicates with Avalanche Go 

420
00:23:24,810 --> 00:23:27,930
in the same way that's built on 
top of all the work we've done 

421
00:23:27,930 --> 00:23:31,130
over the years to integrate all 
these different virtual machines

422
00:23:31,130 --> 00:23:34,110
into Avalanche. 
And so Avalanche itself, like 

423
00:23:34,270 --> 00:23:37,510
the code now that you should 
think about is really just like 

424
00:23:37,510 --> 00:23:40,830
this consensus platform you plug
into as a developer. 

425
00:23:41,510 --> 00:23:43,510
And so when you're building a 
virtual machine, you're really 

426
00:23:43,510 --> 00:23:46,630
just telling Avalanche go, hey, 
orchestrate this virtual machine

427
00:23:46,630 --> 00:23:49,830
process, handle the consensus, 
handle the networking. 

428
00:23:50,950 --> 00:23:55,470
But that has been, you know, 
born through years of hardening 

429
00:23:55,510 --> 00:23:59,150
the EVM integration. 
So, yeah, but on the note of 

430
00:23:59,150 --> 00:24:01,630
like having projects start 
there, it's been great to see, 

431
00:24:01,630 --> 00:24:04,150
you know, some of the teams that
have, you know, found success 

432
00:24:04,150 --> 00:24:05,550
there. 
I think we're seeing some of 

433
00:24:05,550 --> 00:24:07,710
that play out with some of the 
move chains as well. 

434
00:24:07,710 --> 00:24:10,390
We're like, oh, you know, they 
tried it on Aptos, didn't work. 

435
00:24:10,390 --> 00:24:12,470
So now they're going to try it 
on Sue and see if they can build

436
00:24:12,470 --> 00:24:15,390
a community there. 
And so it'll be interesting to 

437
00:24:15,390 --> 00:24:17,150
see. 
I think you know the smart 

438
00:24:17,150 --> 00:24:20,150
contract layers that are shared,
how that continues to be like, 

439
00:24:20,150 --> 00:24:23,430
especially with these Staffs 
moving from, you know, across to

440
00:24:23,430 --> 00:24:25,910
L twos now instead of, you know,
other old ones. 

441
00:24:27,090 --> 00:24:30,250
But yeah, it was a very 
interesting big decision I 

442
00:24:30,250 --> 00:24:31,650
think. 
And so far, I think it's still 

443
00:24:31,650 --> 00:24:36,010
been net positive for sure. 
Right. 

444
00:24:36,010 --> 00:24:40,970
So I think before we actually 
wanted to get into our SDK to 

445
00:24:40,970 --> 00:24:45,130
just tease it again, we also 
wanted to 1st cover a bit the 

446
00:24:45,770 --> 00:24:49,610
one of the core features that 
sort of this architecture brings

447
00:24:49,610 --> 00:24:54,250
that Avalanche has that every 
validator also validates the 

448
00:24:54,250 --> 00:24:56,660
main net. 
You just it's warp messaging. 

449
00:24:56,660 --> 00:25:00,300
Can you sort of talk us through 
a little bit what what is warp? 

450
00:25:00,300 --> 00:25:03,780
Messaging, Yeah. 
I think this also touches, you 

451
00:25:03,780 --> 00:25:06,460
know, on a really interesting 
notion of like why would you 

452
00:25:06,460 --> 00:25:09,260
even build a subnet to begin 
with, right? 

453
00:25:09,260 --> 00:25:11,660
You have, like you have the 
cosmos of CK to build your own 

454
00:25:11,660 --> 00:25:13,660
blockchain. 
You have L2 S You can just do 

455
00:25:13,660 --> 00:25:15,020
that. 
You might as well just deploy a 

456
00:25:15,020 --> 00:25:17,860
contract out like a Solana or 
Aptos or SUI. 

457
00:25:18,100 --> 00:25:21,940
Like, how does subnets even fit 
into this and why is Avalanche 

458
00:25:21,940 --> 00:25:24,700
really designed the way it is to
begin with? 

459
00:25:25,300 --> 00:25:30,100
So the whole idea for a lot of 
this architecture was based on 

460
00:25:30,100 --> 00:25:32,860
the assumption that people 
wanted to create their own 

461
00:25:32,860 --> 00:25:35,380
blockchains. 
And that was the case years ago 

462
00:25:35,380 --> 00:25:38,020
and is the case now. 
The language in which or like 

463
00:25:38,020 --> 00:25:41,060
the semantics in which those 
blockchains exist has certainly 

464
00:25:41,540 --> 00:25:43,580
had changed a bit as people have
had different ideas. 

465
00:25:43,580 --> 00:25:46,540
But the notion that communities 
want to create their own 

466
00:25:46,540 --> 00:25:49,620
blockchains and they want to 
participate them and you know, 

467
00:25:49,620 --> 00:25:53,980
really have their own thing, but
that the biggest problem. 

468
00:25:55,100 --> 00:25:57,100
Eventually would be how you 
connected all of them. 

469
00:25:58,340 --> 00:26:00,980
So you know, if you create a 
chain, and I create a chain, 

470
00:26:00,980 --> 00:26:02,900
like we can have our own 
communities do things. 

471
00:26:03,580 --> 00:26:06,860
But what we've seen time and 
time again is like things really

472
00:26:06,860 --> 00:26:09,980
get supercharged and exciting 
when everything's connected, 

473
00:26:09,980 --> 00:26:12,180
right When you're contracting, 
call another contractor. 

474
00:26:12,180 --> 00:26:15,060
When my chain can interact with 
your chain, it seems to like 

475
00:26:15,060 --> 00:26:18,020
multiply the benefit of 
blockchain rather than just 

476
00:26:18,100 --> 00:26:21,420
being added or even you know, 
subtract like a net zero game or

477
00:26:21,420 --> 00:26:24,370
something like that. 
And so Avalanche was designed 

478
00:26:24,370 --> 00:26:28,530
from the beginning to have this 
at the core, which was if the 

479
00:26:28,530 --> 00:26:33,210
primary network, specifically 
the P chain can keep track of 

480
00:26:33,370 --> 00:26:35,410
who's participating in what 
subnets. 

481
00:26:36,290 --> 00:26:39,290
It'd be really good for two 
things. 

482
00:26:39,570 --> 00:26:44,090
One, making it easy for 
exchanges integrators to stake 

483
00:26:44,170 --> 00:26:47,170
everywhere because you only 
integrate with the P chain to 

484
00:26:47,170 --> 00:26:49,490
actually stake. 
But the second? 

485
00:26:50,380 --> 00:26:54,340
Was this idea that it could also
be used as like a registry store

486
00:26:54,340 --> 00:26:56,540
to manage messaging throughout 
the network. 

487
00:26:57,020 --> 00:27:00,660
So I'll give you one simple like
kind of comparison here which is

488
00:27:00,860 --> 00:27:03,660
in Cosmos which was certainly a 
pioneer and a lot of this cross 

489
00:27:03,660 --> 00:27:06,300
chain messaging with IDC and all
the great stuff they do. 

490
00:27:06,900 --> 00:27:09,620
There is no like center chain 
that is a registry. 

491
00:27:09,780 --> 00:27:12,580
So every zone has to communicate
with every zone like a 

492
00:27:12,580 --> 00:27:15,300
connection and channel state 
that they're constantly updated 

493
00:27:15,500 --> 00:27:17,540
for every message or like 
whenever there's a validator 

494
00:27:17,540 --> 00:27:22,000
change and so as a result. 
It's not necessarily encouraged 

495
00:27:22,160 --> 00:27:25,320
to have like every zone talk to 
every other zone because there's

496
00:27:25,320 --> 00:27:28,320
so much overhead of passing all 
this like state management stuff

497
00:27:28,320 --> 00:27:31,080
around. 
Avalanche takes a totally 

498
00:27:31,080 --> 00:27:34,000
different approach which is you 
know, validate this one chain 

499
00:27:34,360 --> 00:27:37,680
and then there is no like 
additive cost per message you 

500
00:27:37,680 --> 00:27:40,760
send other than just verify the 
signatures because you just look

501
00:27:40,760 --> 00:27:44,280
it up on the primary network. 
And so word messaging, which we 

502
00:27:44,280 --> 00:27:46,720
call our cross subnet messaging 
protocol. 

503
00:27:47,090 --> 00:27:51,090
Is basically this way to 
securely send bytes whether that

504
00:27:51,090 --> 00:27:54,730
be an asset, a transaction, 
data, whatever you want from 1 

505
00:27:54,730 --> 00:27:58,330
subnet to another where you the 
the validators. 

506
00:27:58,330 --> 00:28:02,050
Basically on the the source 
subnet create a BLS multi 

507
00:28:02,050 --> 00:28:05,810
signature and then the 
validators on the destination 

508
00:28:05,810 --> 00:28:10,170
subnet just look at that BLS 
multi signature and say hey like

509
00:28:10,170 --> 00:28:14,330
what is the source subnet stake 
distribution or like who is 

510
00:28:14,330 --> 00:28:16,720
participating on it. 
And then say you know the 

511
00:28:16,720 --> 00:28:19,000
subnet, the destination 
determines if the message is 

512
00:28:19,000 --> 00:28:21,160
valid based on the percentage 
that it sets. 

513
00:28:21,840 --> 00:28:24,280
Is this valid? 
Is this message signed by X 

514
00:28:24,280 --> 00:28:26,200
percent mistake? 
And if so, accepts it. 

515
00:28:27,320 --> 00:28:31,320
And so it's a very simple base 
protocol, but it uses the 

516
00:28:31,320 --> 00:28:34,120
benefit of having this like 
registry chain kind of in the 

517
00:28:34,120 --> 00:28:36,960
middle to like actually 
authenticate those messages. 

518
00:28:37,520 --> 00:28:41,040
And so you as a VM, you know, 
builder or somewhat using this. 

519
00:28:41,570 --> 00:28:44,450
You just have to really just say
get the validators to sign a 

520
00:28:44,450 --> 00:28:46,050
message and then move the 
message. 

521
00:28:46,370 --> 00:28:49,210
But you, the person that 
actually moves a message has no 

522
00:28:49,210 --> 00:28:51,570
additional trust in the network 
whatsoever. 

523
00:28:51,930 --> 00:28:56,370
And you could just as cheaply 
move from subnet A to subnet B 

524
00:28:56,650 --> 00:29:00,170
as it is moving from subnet A to
subnet C, Which is a huge 

525
00:29:00,170 --> 00:29:03,450
benefit to avoid having like 
correlated risk as you take an 

526
00:29:03,450 --> 00:29:06,890
asset and move it like further 
away from its origin right. 

527
00:29:06,890 --> 00:29:08,810
Like if you have something asset
to find on A. 

528
00:29:09,280 --> 00:29:12,560
Then you move to B and then B 
moves it to C Now there's a 

529
00:29:12,920 --> 00:29:16,200
problem on A, C may have no idea
unless you know manual 

530
00:29:16,480 --> 00:29:20,040
intervention is is done. 
And I think a paradigm actually 

531
00:29:20,040 --> 00:29:22,800
has a great article on this in 
the cosmos ecosystem like this 

532
00:29:22,800 --> 00:29:26,760
risk of kind of asset 
contamination based on how many 

533
00:29:26,760 --> 00:29:30,520
hops you are from the source and
so with this you know mechanism 

534
00:29:30,520 --> 00:29:31,680
you really just don't need to do
that. 

535
00:29:31,960 --> 00:29:35,880
So but yeah, so that's the gist,
which is Avalanche was built for

536
00:29:35,880 --> 00:29:39,040
this multi blockchain world. 
And assumes that that was just 

537
00:29:39,040 --> 00:29:41,200
inevitable. 
And in that world, what do you 

538
00:29:41,240 --> 00:29:44,200
need the most? 
You need a shared integration 

539
00:29:44,200 --> 00:29:48,360
point so like all the stake is 
secured by the entire network 

540
00:29:49,480 --> 00:29:51,680
and you need a really good 
messaging system. 

541
00:29:53,000 --> 00:29:56,280
The actual VM building is then 
what makes it all come alive? 

542
00:29:57,640 --> 00:30:02,320
So you said like the BLS 
signature and there's a certain 

543
00:30:02,320 --> 00:30:05,800
percentage of stake that needs 
to have signed the message. 

544
00:30:06,120 --> 00:30:09,200
Is that like? 
The state distribution from the 

545
00:30:09,200 --> 00:30:12,680
specific subnet, so some some 
staking on that subnet. 

546
00:30:12,680 --> 00:30:17,080
But then how much does it need 
to be verified by the the 

547
00:30:17,280 --> 00:30:19,920
avalanche validators? 
Like I guess in a subnet not 

548
00:30:19,920 --> 00:30:23,080
necessarily all avalanche 
validators are part of it. 

549
00:30:23,360 --> 00:30:25,720
Is there like some threshold 
that's also needed there or? 

550
00:30:26,200 --> 00:30:27,680
So that's correct. 
Yeah. 

551
00:30:27,680 --> 00:30:31,360
So the actual primary network 
has nothing to do with messaging

552
00:30:31,400 --> 00:30:34,240
other than like basically 
maintaining that registry list. 

553
00:30:34,800 --> 00:30:36,560
So you could imagine a system 
where. 

554
00:30:36,920 --> 00:30:39,840
Hey if I want to send a message 
from subnet A to subnet BI have 

555
00:30:39,840 --> 00:30:43,280
to like first send it to the 
primary network, it gets 

556
00:30:43,280 --> 00:30:46,200
persisted somehow inside and 
then subnet B can read it. 

557
00:30:46,720 --> 00:30:51,080
This is a point to point between
the subnets themselves and the 

558
00:30:51,080 --> 00:30:54,000
way that this kind of works is 
it's all opt in. 

559
00:30:54,520 --> 00:30:58,280
So a subnet that like gets a 
message, there's no requirement 

560
00:30:58,560 --> 00:31:01,480
whatsoever, it has to process it
at all depending on where it 

561
00:31:01,480 --> 00:31:04,120
came from. 
So it's on the destination to 

562
00:31:04,120 --> 00:31:06,560
say first of all, which subnets 
I actually want to. 

563
00:31:06,890 --> 00:31:11,090
Accept messages from and then 
two, what is the stake 

564
00:31:11,090 --> 00:31:14,050
percentage that must sign it for
me to consider it to be valid. 

565
00:31:14,530 --> 00:31:16,970
So like for example in a virtual
machine that decides to 

566
00:31:16,970 --> 00:31:21,170
integrate it where you have like
a kind of like a homogeneous 

567
00:31:21,170 --> 00:31:24,210
asset mix where like every asset
looks at like the same. 

568
00:31:24,210 --> 00:31:26,970
You may have a very high 
security window and say like oh 

569
00:31:26,970 --> 00:31:30,770
you know we 95% of stake and we 
only want to accept messages 

570
00:31:30,770 --> 00:31:34,210
from subnets that have so much 
value like associated with their

571
00:31:34,210 --> 00:31:37,170
token. 
And then on other subnets or 

572
00:31:37,170 --> 00:31:40,370
like for example on some other 
Vms we've seen where the tokens 

573
00:31:40,370 --> 00:31:42,410
are actually prefixed by their 
source. 

574
00:31:43,330 --> 00:31:45,850
You may just say across the 
board, like if 80% of some 

575
00:31:45,850 --> 00:31:48,450
subnet signs this token, like, 
we'll accept it and then people 

576
00:31:48,450 --> 00:31:50,090
can choose to interact with it 
if they want. 

577
00:31:51,250 --> 00:31:54,210
So you're given that option when
you actually implement the 

578
00:31:54,450 --> 00:31:59,490
virtual machine, right? 
So the way I'm kind of imagining

579
00:31:59,490 --> 00:32:03,330
it is I tend to think of block 
chains as. 

580
00:32:04,450 --> 00:32:07,490
I mean, it's kind of wrong in 
details, but I tend to think of 

581
00:32:07,490 --> 00:32:12,810
like scribes or accountants 
Maintaining an Excel sheet, 

582
00:32:12,810 --> 00:32:15,650
right? 
Jointly maintaining excel sheet.

583
00:32:15,650 --> 00:32:18,330
That's the Roy's description of 
a blockchain. 

584
00:32:18,570 --> 00:32:20,770
I have and. 
Just submit a Google Form and 

585
00:32:20,770 --> 00:32:21,730
then you're good. 
Yeah. 

586
00:32:21,850 --> 00:32:24,930
Yeah, it's kind of like the 
easiest way to probably think of

587
00:32:24,930 --> 00:32:28,810
it. 
And so it's like the Avalanche 

588
00:32:28,810 --> 00:32:32,770
main net, the Cchain, Pchain and
Exchange. 

589
00:32:32,770 --> 00:32:36,750
So you can think of that as like
the biggest association of 

590
00:32:37,310 --> 00:32:40,670
scribes or accountants in the 
Avalanche ecosystem. 

591
00:32:40,670 --> 00:32:43,830
So anyone who wants to be an 
accountant anywhere in the 

592
00:32:43,830 --> 00:32:47,630
Avalanche ecosystem you have to 
go and join the main net first. 

593
00:32:47,630 --> 00:32:53,710
So you you build up like this 
huge pool of 2003 thousand maybe

594
00:32:53,710 --> 00:32:59,230
in the future 10s of thousands 
of scribes that are that are 

595
00:32:59,230 --> 00:33:02,310
kind of like maintaining that 
that Excel sheet of the main, 

596
00:33:03,050 --> 00:33:05,970
the main subnet and those are 
the three chains there. 

597
00:33:06,770 --> 00:33:12,130
And then whenever a subnet needs
to be spun up, what that kind of

598
00:33:12,130 --> 00:33:16,810
main Excel sheet is kind of 
storing is what is the subset of

599
00:33:16,810 --> 00:33:20,730
accountants from that main 
network that will that will kind

600
00:33:20,730 --> 00:33:24,770
of maintain that that subnet. 
So if you create subnet 37, 

601
00:33:25,170 --> 00:33:27,410
there's a record in the main 
Excel sheet. 

602
00:33:27,410 --> 00:33:31,800
OK for subnet 37 these are all 
the accountants and that's kind 

603
00:33:31,800 --> 00:33:33,520
of like economical place where 
they are stored. 

604
00:33:33,520 --> 00:33:38,480
So that mean this is storing who
are the accountants for each of 

605
00:33:38,480 --> 00:33:43,400
these subnets. 
And so when I'm subnet 36, when 

606
00:33:43,400 --> 00:33:47,600
I get a message from subnet 21, 
all I need to know is that 

607
00:33:47,600 --> 00:33:50,360
message valid and I can just 
consult the main. 

608
00:33:50,680 --> 00:33:55,400
I can consult the main network, 
say what's the list of scribes 

609
00:33:55,440 --> 00:33:59,120
and what what percentage should 
have signed this message for me 

610
00:33:59,120 --> 00:34:01,520
to accept it. 
I mean it would give you that 

611
00:34:01,520 --> 00:34:05,400
response and then you can trust 
that response and accept that 

612
00:34:05,400 --> 00:34:08,600
message based on that. 
Yeah, basically that's your 

613
00:34:08,639 --> 00:34:12,560
input into like the message 
verification process to say what

614
00:34:12,560 --> 00:34:15,520
are the BLS keys of the people 
that are supposed to sign and 

615
00:34:15,520 --> 00:34:18,159
what is the weight associated 
with each one of those BLS 

616
00:34:18,159 --> 00:34:20,120
public keys. 
And then you can just say 

617
00:34:20,120 --> 00:34:22,800
whether or not like locally 
that's valid, so like. 

618
00:34:23,120 --> 00:34:26,159
But it's really up to you how 
you actually want to like 

619
00:34:26,159 --> 00:34:28,239
maintain that delivery. 
So like you mentioned, there's 

620
00:34:28,239 --> 00:34:30,500
no. 
The main net component that it 

621
00:34:30,500 --> 00:34:32,340
like the messages don't have to 
go through the main net. 

622
00:34:32,860 --> 00:34:36,179
Secondly, one point really small
to clarify, right, is that when 

623
00:34:36,179 --> 00:34:39,420
you're talking about those 
scribes, they're never assigned 

624
00:34:39,460 --> 00:34:42,420
to a subnet, everything's opt 
in. 

625
00:34:43,340 --> 00:34:47,580
So Avalanche right now is very 
much designed for like a 

626
00:34:48,179 --> 00:34:51,219
sovereign world rather than a 
shared security world. 

627
00:34:51,460 --> 00:34:53,500
So people that are coming at it 
from the world of hey, I know 

628
00:34:53,500 --> 00:34:55,620
what L twos are. 
I use a theory and I put data 

629
00:34:55,620 --> 00:34:58,540
there. 
Not how Avalanche works at all. 

630
00:34:58,540 --> 00:35:00,900
Subnets maintain all their own 
data. 

631
00:35:00,900 --> 00:35:05,980
The primary network just manages
stake of subnets and the 

632
00:35:06,300 --> 00:35:10,300
validator registry for subnets. 
But you don't actually put data 

633
00:35:10,300 --> 00:35:14,180
there and it does not offer any 
sort of like prove capability to

634
00:35:14,220 --> 00:35:16,420
prove that something that 
happened on the subnet was 

635
00:35:16,420 --> 00:35:19,140
invalid or something like that. 
Now that may change in the 

636
00:35:19,140 --> 00:35:22,100
future based on like what 
appetite you know people have 

637
00:35:22,100 --> 00:35:23,940
shown for like. 
It'd be great if I didn't have 

638
00:35:23,940 --> 00:35:27,690
to provide my own security. 
But so far and you know how 

639
00:35:27,690 --> 00:35:29,770
Avalanche was originally 
designed and at the time at 

640
00:35:29,770 --> 00:35:32,570
which it was designed, there was
no interest at all. 

641
00:35:32,570 --> 00:35:34,890
Insurance. 
It's actually pretty funny how 

642
00:35:34,890 --> 00:35:38,570
much it's like shifted entirely 
like shirt security seemed to 

643
00:35:38,570 --> 00:35:40,690
like really become this thing 
maybe a year and a half, two 

644
00:35:40,690 --> 00:35:42,610
years ago. 
Like I don't actually want to 

645
00:35:42,610 --> 00:35:44,690
provide about security, I just 
want to use someone else's. 

646
00:35:45,050 --> 00:35:47,490
Whereas before that, like it was
all about this notion of. 

647
00:35:48,160 --> 00:35:50,480
For our own community, we have 
our own decentralization. 

648
00:35:50,480 --> 00:35:53,920
We have no, you know, no master 
that we like kind of work with 

649
00:35:53,920 --> 00:35:56,120
or like you know, we're our own 
sovereign community. 

650
00:35:56,200 --> 00:35:58,080
We don't want to work with 
anybody else. 

651
00:35:58,080 --> 00:35:59,880
We want we we define our 
success. 

652
00:36:00,840 --> 00:36:04,560
So it's interesting how much 
that spectrum has since that 

653
00:36:04,560 --> 00:36:07,680
time. 
But yeah so for people that are 

654
00:36:07,680 --> 00:36:10,520
using subnets, you know if you 
were to shut off all the values 

655
00:36:10,520 --> 00:36:14,200
on the subnet, it's gone. 
So it's it's like the subnet 

656
00:36:14,200 --> 00:36:16,480
provides its own security and 
it's opt in. 

657
00:36:16,560 --> 00:36:19,840
So you you join it. 
Or you state to join it. 

658
00:36:21,440 --> 00:36:25,240
But maybe also, I guess to also 
like Avalanche doesn't have 

659
00:36:25,240 --> 00:36:28,200
slashing right? 
And there is, so there's really 

660
00:36:28,840 --> 00:36:31,280
let's say there's a malicious 
subnet somehow. 

661
00:36:31,800 --> 00:36:36,600
There's actually no like 
recourse for the main NET 

662
00:36:36,600 --> 00:36:40,600
validators that validated it. 
Sort of in in a way what you 

663
00:36:40,600 --> 00:36:43,720
would do so like in the case 
where you had someone that 

664
00:36:43,720 --> 00:36:46,080
wasn't participating right, you 
lose your reward. 

665
00:36:46,080 --> 00:36:49,200
So like the? 
The penalty is really like, hey,

666
00:36:49,200 --> 00:36:51,240
you were going to get this 
staking reward, now you're not. 

667
00:36:52,080 --> 00:36:54,120
So it's not like there's no 
penalty whatsoever. 

668
00:36:54,200 --> 00:36:57,240
It's it's similar to like you 
just you'd get inflated out of 

669
00:36:57,240 --> 00:37:01,520
the system more or less. 
But on the subnet front, there's

670
00:37:01,520 --> 00:37:03,840
no load for the subnet on the 
main network. 

671
00:37:05,040 --> 00:37:07,360
So like if a subnet was like, I 
don't even know what it would 

672
00:37:07,720 --> 00:37:09,560
like, there's no control of the 
subnet, right? 

673
00:37:09,560 --> 00:37:11,920
You can do whatever. 
That's the best part and most 

674
00:37:11,920 --> 00:37:13,850
complicated. 
Part about it, which is where 

675
00:37:13,850 --> 00:37:16,690
the hyper SCK like ends up 
coming in, is to try and bound 

676
00:37:16,690 --> 00:37:18,330
that a bit for people that want 
to get started. 

677
00:37:18,890 --> 00:37:23,130
But you know, it really does its
own thing and so if you are on a

678
00:37:23,130 --> 00:37:26,650
subnet that all of a sudden like
goes absolutely wild, you can 

679
00:37:26,650 --> 00:37:30,930
just stop validating it. 
No penalty to you other than 

680
00:37:31,050 --> 00:37:35,690
anything related to that subnet.
And so like unlike something 

681
00:37:35,690 --> 00:37:38,090
where like a polka dot for 
example, where there's resource 

682
00:37:38,090 --> 00:37:41,170
constraints per pair of chain to
make sure that when you're 

683
00:37:41,170 --> 00:37:44,520
assigned to a pair of chain. 
You can't just like get totally 

684
00:37:44,520 --> 00:37:46,280
wrecked by whatever the pair 
chain is doing. 

685
00:37:47,000 --> 00:37:49,920
There is no notion of that on 
Avalanche because it's all opt 

686
00:37:49,920 --> 00:37:51,800
in. 
So if you want to participate in

687
00:37:51,800 --> 00:37:54,800
the subnet, you better have the 
resources required to 

688
00:37:54,800 --> 00:37:57,360
participate. 
But if it's malicious, you know 

689
00:37:57,360 --> 00:37:59,960
you should just not. 
And there's no penalty for that 

690
00:38:00,760 --> 00:38:03,280
outside of that community. 
So maybe that community will 

691
00:38:03,280 --> 00:38:07,240
say, hey, you didn't get your 
reward and you'd be like file 

692
00:38:07,240 --> 00:38:11,000
with me like I don't, I don't 
want to anymore based on what 

693
00:38:11,000 --> 00:38:13,700
your subnet is doing. 
So that's not necessarily a 

694
00:38:13,700 --> 00:38:16,940
problem per se. 
Now the one very small side I 

695
00:38:16,940 --> 00:38:21,100
will say is that a lot of the 
feedback we've gotten has been 

696
00:38:21,100 --> 00:38:24,740
that this like kind of strict 
connection between the primary 

697
00:38:24,740 --> 00:38:28,220
network and the subnet has made 
it much more complicated because

698
00:38:28,220 --> 00:38:30,180
you have to like validate the 
primary network and all this 

699
00:38:30,180 --> 00:38:33,580
stuff like that and the subnet. 
And so like you know, how can 

700
00:38:33,580 --> 00:38:36,580
you possibly be efficient if you
have to do so much it wants just

701
00:38:36,580 --> 00:38:39,780
to run a single subnet compared 
to like an L2 where I can just 

702
00:38:40,020 --> 00:38:41,660
turn on a server, connect you to
a serial. 

703
00:38:42,130 --> 00:38:44,370
Good to go. 
And so there has been a lot of 

704
00:38:44,530 --> 00:38:47,210
conversation in the community 
about changing this a bit. 

705
00:38:47,250 --> 00:38:51,170
And so having subnets or 
participants actually just like 

706
00:38:51,170 --> 00:38:54,170
verify the P chain or what is 
required for like just to 

707
00:38:54,170 --> 00:38:57,690
populate the registry and not 
actually validate the primary 

708
00:38:57,690 --> 00:39:00,370
network but just read it and 
then store data on it. 

709
00:39:00,770 --> 00:39:04,250
And then that would make the 
like subnet running process like

710
00:39:04,330 --> 00:39:08,010
much lighter and with that 
wouldn't really sacrifice any 

711
00:39:08,010 --> 00:39:10,860
functionality so. 
There have been a lot of 

712
00:39:10,860 --> 00:39:15,140
conversations about that. 
Nothing really has started, I 

713
00:39:15,140 --> 00:39:17,740
would say. 
But you know, I think with any 

714
00:39:17,740 --> 00:39:20,380
network, right as the community 
interacts with it, there's like 

715
00:39:20,380 --> 00:39:24,220
this constant evolution, and 
it's a really good metric of 

716
00:39:24,540 --> 00:39:27,100
like how how much people 
actually care about what's going

717
00:39:27,100 --> 00:39:31,020
on is like, how far did you 
actually end up deviating from 

718
00:39:31,020 --> 00:39:33,540
the original ideas based on 
interaction with everybody? 

719
00:39:34,120 --> 00:39:36,480
I guess unless you're like a 
Satoshi's vision fan, in which 

720
00:39:36,480 --> 00:39:39,000
case I don't know study. 
But I think in the case of like 

721
00:39:39,000 --> 00:39:42,240
Avalanche, what we're thinking 
about, it's how the ecosystem 

722
00:39:42,240 --> 00:39:46,240
has continued to change and what
does the community decide to do 

723
00:39:46,240 --> 00:39:48,440
in in reflection of that based 
on what people are actually 

724
00:39:48,440 --> 00:39:53,240
trying to get going. 
Yeah, I mean this, this, such a 

725
00:39:53,240 --> 00:39:58,360
big variety of what I mean when 
you look at the entire crypto 

726
00:39:58,360 --> 00:40:03,990
space and that includes like. 
Near Solana, Etherium L2 S 

727
00:40:03,990 --> 00:40:08,710
Cosmos, Avalan, Olka, dot, maybe
something even like a Celestia. 

728
00:40:08,710 --> 00:40:13,070
There's such a huge variety of 
what the Central Chain is trying

729
00:40:13,070 --> 00:40:17,190
to offer as as services, right? 
Sometimes it's Central chain 

730
00:40:17,190 --> 00:40:21,150
isn't offering anything at all, 
which is the Cosmos Hub, maybe 

731
00:40:21,150 --> 00:40:25,870
the most minimal set of services
the Central Chain is trying to 

732
00:40:25,870 --> 00:40:28,740
offer historically. 
Then maybe you have like an 

733
00:40:28,740 --> 00:40:33,020
avalanche which is offering the 
services of OK, the string 

734
00:40:33,020 --> 00:40:36,740
validators and tracking who 
validates what. 

735
00:40:37,100 --> 00:40:41,300
Then maybe something higher 
would be change that off trying 

736
00:40:41,300 --> 00:40:44,180
to offer data availability. 
So if you have a subnet you 

737
00:40:44,180 --> 00:40:48,020
wanna run your subnet we'll make
sure that your data is 

738
00:40:48,020 --> 00:40:51,420
accessible in case something 
goes wrong in your system. 

739
00:40:52,020 --> 00:40:57,080
We have the data to process who 
didn't what wrong and start a 

740
00:40:57,080 --> 00:41:00,680
code of some kind that's kind of
like the Ethereum probably like 

741
00:41:00,680 --> 00:41:03,200
the celestial visions are kind 
of there. 

742
00:41:03,800 --> 00:41:09,600
And then like the the poll cut 
out and near visions would be 

743
00:41:10,200 --> 00:41:16,200
yes you can come and run your 
subnet and we will ensure that a

744
00:41:16,200 --> 00:41:19,280
malicious transaction never 
never comes in. 

745
00:41:19,280 --> 00:41:23,410
Like the central place will kind
of ensure ensure that your 

746
00:41:23,410 --> 00:41:26,850
accounting is always right and 
your data is always available. 

747
00:41:27,890 --> 00:41:31,130
And so there's this whole range.
And yeah, it's kind of like 

748
00:41:31,210 --> 00:41:34,890
market forces will ultimately 
decide what what model ends up 

749
00:41:34,890 --> 00:41:37,250
the winner. 
Yeah, I mean, I think the one 

750
00:41:37,250 --> 00:41:40,530
thing I'll say in response to 
that is I tweeted about this a 

751
00:41:40,530 --> 00:41:45,170
while ago too, which is I think 
the ecosystem generally should 

752
00:41:45,290 --> 00:41:49,530
be supportive of this scheme 
like so widespread approach and 

753
00:41:49,530 --> 00:41:52,550
like that resilience and like. 
Interest to go down so many 

754
00:41:52,550 --> 00:41:55,750
different paths is what makes 
crypto so strong, like and 

755
00:41:55,750 --> 00:41:58,630
resilient. 
If we all sent like focus so 

756
00:41:58,630 --> 00:42:01,590
much on a particular thing and 
say like everything else doesn't

757
00:42:01,590 --> 00:42:03,550
make any sense. 
Like if you're doing this like I

758
00:42:03,550 --> 00:42:07,390
don't know where have you been 
like you've been to rock ends up

759
00:42:07,510 --> 00:42:10,870
destabilizing everything because
like if that particular approach

760
00:42:10,870 --> 00:42:13,390
has some sort of setback, you 
know whether that be like 

761
00:42:13,390 --> 00:42:16,710
regulatory, legal, like security
wise, who knows what. 

762
00:42:17,550 --> 00:42:19,710
It ends up we gain everything 
because we now all made this 

763
00:42:19,710 --> 00:42:21,790
assumption that everyone has to 
do this way. 

764
00:42:22,070 --> 00:42:26,030
So when people talk to me about 
like, do you think there'll be a

765
00:42:26,030 --> 00:42:27,950
single chain? 
Or like is avalanche the only 

766
00:42:27,950 --> 00:42:31,230
way you could ever do something?
I always emphatically say no. 

767
00:42:31,230 --> 00:42:33,830
And I hope, you know, I really 
hope it never is right. 

768
00:42:33,830 --> 00:42:36,870
Like, I think that the notion of
having this like really 

769
00:42:36,870 --> 00:42:40,150
interesting heterogeneity in the
space, although it may seem 

770
00:42:40,150 --> 00:42:44,430
suboptimal, is like the. 
Not to use like the cliche word,

771
00:42:44,430 --> 00:42:48,110
but like the anti fragile 
fragility of everything is I 

772
00:42:48,110 --> 00:42:49,750
think what excites so many 
people. 

773
00:42:50,830 --> 00:42:54,710
But yeah, I really think that 
this is a great transition to to

774
00:42:54,710 --> 00:42:57,230
the Hyper SDK step, which is 
trying to, at least on the 

775
00:42:57,230 --> 00:43:00,230
Avalanche side, make that easier
to take advantage of. 

776
00:43:01,630 --> 00:43:02,630
Right. 
Yeah, let's go there. 

777
00:43:02,630 --> 00:43:06,830
We're like 40 minutes in and 
getting to the the meat of the 

778
00:43:06,830 --> 00:43:10,670
conversation. 
So right, we talked about like. 

779
00:43:11,190 --> 00:43:14,150
Avalanche like sort of 
trade-offs, it's making the 

780
00:43:14,470 --> 00:43:18,470
concept of subnets and now 
essentially what your main focus

781
00:43:18,470 --> 00:43:23,350
is in avalanches as far as I 
understand at least is this 

782
00:43:23,350 --> 00:43:25,910
concept called like or the 
project called Hyper SDK. 

783
00:43:26,190 --> 00:43:29,550
You just yeah basically tell us 
what is Hyper SDK? 

784
00:43:30,790 --> 00:43:34,590
Yeah, so I mean for a long time 
if you wanted to interact with 

785
00:43:34,590 --> 00:43:39,220
Avalanche in a custom way. 
We would say or I would say 

786
00:43:39,220 --> 00:43:40,620
like, Oh yeah, you can do 
anything. 

787
00:43:40,620 --> 00:43:42,660
It's so flexible. 
Like there's so much you could 

788
00:43:42,660 --> 00:43:45,100
possibly do. 
But if you want to get started 

789
00:43:45,100 --> 00:43:48,180
quick, you know, we have the 
subnet EVM, which lets you like 

790
00:43:48,180 --> 00:43:49,980
spin up an easy app really 
quickly. 

791
00:43:49,980 --> 00:43:52,220
And that's really what got 
people's attention with Subnets 

792
00:43:52,220 --> 00:43:54,260
in the 1st place. 
I like, tweeted this thing out 

793
00:43:54,260 --> 00:43:57,900
about like, start an EVM with a 
single JSON file and then that, 

794
00:43:57,900 --> 00:44:01,540
like, people love that post. 
But as a result, like for a long

795
00:44:01,540 --> 00:44:03,460
time all people ever did on 
subnets. 

796
00:44:03,930 --> 00:44:07,130
Deployed yet because it was just
like this, super JSON, easy 

797
00:44:07,130 --> 00:44:09,650
contact. 
And then I realized one day, I 

798
00:44:09,650 --> 00:44:12,610
don't, I don't remember 
specifically what it was, but I 

799
00:44:12,610 --> 00:44:16,490
was like, you know, I keep 
saying it's so easy and 

800
00:44:16,490 --> 00:44:19,210
straight, like there's so much 
you could possibly do, like just

801
00:44:19,210 --> 00:44:21,770
go do it. 
I realized that, like, you know,

802
00:44:21,810 --> 00:44:25,890
to actually do that from scratch
is not a super straightforward 

803
00:44:26,250 --> 00:44:30,490
task and it requires like to do 
it really performantly. 

804
00:44:30,850 --> 00:44:35,320
Quite a bit of engineering work.
And so I decided at one point, 

805
00:44:35,600 --> 00:44:39,640
hey, let's just in one 
particular case, offer like a 

806
00:44:39,640 --> 00:44:44,320
very opinionated view of how you
could build a foundation for a 

807
00:44:44,320 --> 00:44:49,280
blockchain that lets people go 
from maybe step zero to step 10 

808
00:44:49,280 --> 00:44:51,560
and then let them. 
Or like, maybe step zero to step

809
00:44:51,560 --> 00:44:53,720
8 and then let them go from step
8 to step 10. 

810
00:44:54,240 --> 00:44:56,960
Because there's a lot of 
functionality you want that you 

811
00:44:56,960 --> 00:44:59,880
would want to build on top of 
the avalanche go process. 

812
00:45:00,280 --> 00:45:02,240
That is not necessarily provided
out-of-the-box. 

813
00:45:02,240 --> 00:45:04,600
One of those, for example would 
be something like states which 

814
00:45:04,600 --> 00:45:07,480
we can go into later is not 
something provided by the core 

815
00:45:07,480 --> 00:45:10,400
of Avalanche, but any high 
throughput or modern virtual 

816
00:45:10,400 --> 00:45:11,840
machine would probably want 
that. 

817
00:45:12,280 --> 00:45:15,600
So I thought about a lot of 
like, you know, there's a lot of

818
00:45:15,600 --> 00:45:18,600
things here actually that if we 
just implemented one time and 1 

819
00:45:18,600 --> 00:45:21,960
opinionated way, could make it 
much easier for people to build 

820
00:45:21,960 --> 00:45:24,880
their own thing and to me 
avalanche, right? 

821
00:45:25,690 --> 00:45:28,690
If all it ever is is like, yeah,
it's a great place to run like 

822
00:45:28,690 --> 00:45:32,010
Modda DVMS. 
I guess to me that like is such 

823
00:45:32,010 --> 00:45:35,490
a shortfall of like what the 
original hope and vision were 

824
00:45:36,450 --> 00:45:39,890
makes me sad I guess. 
But generally you know if if you

825
00:45:39,890 --> 00:45:42,490
want to see change in the world,
you got to be that change I 

826
00:45:42,490 --> 00:45:44,930
guess sometimes. 
And to me like the Hyper SDK is 

827
00:45:44,930 --> 00:45:47,490
something I'm very passionate 
about, it have a lot of fun 

828
00:45:47,490 --> 00:45:50,490
working on. 
So the Hyper SDK in short is 

829
00:45:50,810 --> 00:45:54,030
it's a toolkit or framework? 
Really for people that are 

830
00:45:54,030 --> 00:45:58,030
trying to build their own 
blockchain that takes advantage 

831
00:45:58,030 --> 00:46:00,950
of the best Avalanche has to 
offer that we may not have been 

832
00:46:00,950 --> 00:46:03,710
able to take advantage of and 
other virtual machines we have 

833
00:46:03,710 --> 00:46:07,270
because we're trying to preserve
maybe some sort of functionality

834
00:46:07,270 --> 00:46:09,910
over performance. 
And I think in today's 

835
00:46:09,910 --> 00:46:13,150
blockchain world, so many people
are interested in scalability 

836
00:46:13,430 --> 00:46:18,310
that targeting, you know, scale 
at all costs was really the 

837
00:46:18,310 --> 00:46:20,950
North Star and continues to be 
the North Star for the hyperest 

838
00:46:20,950 --> 00:46:24,430
Decay, is to say. 
If someone comes out and asks 

839
00:46:25,110 --> 00:46:28,470
what's the fastest and scalable 
thing I can build on Avalanche, 

840
00:46:29,270 --> 00:46:32,990
we wanted to have an answer. 
At least Avalabs did for what 

841
00:46:32,990 --> 00:46:34,870
that would be and that's the 
Hyperstk. 

842
00:46:36,390 --> 00:46:41,150
So maybe I actually want to 
start with very conceptual 

843
00:46:41,150 --> 00:46:44,030
question on like what do you 
mean when you say virtual 

844
00:46:44,030 --> 00:46:46,350
machine? 
Yeah, that's a good place to 

845
00:46:46,350 --> 00:46:49,850
start. 
Often, like our conception of 

846
00:46:49,850 --> 00:46:54,010
virtual machine is OK, it's a 
Turing complete virtual machine.

847
00:46:54,010 --> 00:46:56,810
Where there's some kind of 
programming language is 

848
00:46:56,810 --> 00:47:00,090
Solidity, with which you can 
write smart contracts and you 

849
00:47:00,090 --> 00:47:02,170
can deploy them. 
But I think that you mean 

850
00:47:02,170 --> 00:47:03,730
virtual machines to be something
broader. 

851
00:47:04,210 --> 00:47:05,210
What is? 
It yeah. 

852
00:47:05,210 --> 00:47:10,730
So in the context of Avalanche, 
a virtual machine is anything 

853
00:47:11,050 --> 00:47:16,970
that is the subnet specific 
logic that is running. 

854
00:47:18,430 --> 00:47:22,710
So that includes state 
management, that includes RPC. 

855
00:47:22,710 --> 00:47:25,670
It's more of the virtual machine
idea of like you run an easy 

856
00:47:25,670 --> 00:47:28,910
two, like it's a general 
computing surface that you can 

857
00:47:28,910 --> 00:47:32,190
utilize with some like functions
that are provided to you. 

858
00:47:32,590 --> 00:47:35,270
So like I agree with you, like 
the typical virtual machine 

859
00:47:35,270 --> 00:47:37,430
people use is like a theory in 
virtual machine, right? 

860
00:47:37,430 --> 00:47:41,270
Like it's just the logic that 
executes the transaction like, 

861
00:47:41,270 --> 00:47:42,990
hey, this is the transaction 
format. 

862
00:47:43,230 --> 00:47:45,350
This is like how that 
transaction is actually 

863
00:47:45,350 --> 00:47:47,310
executed. 
Great, now we've done the state 

864
00:47:47,310 --> 00:47:51,180
transition. 
What's next now I think because 

865
00:47:51,180 --> 00:47:54,140
there's so much complexity here,
virtual machine has kind of 

866
00:47:54,380 --> 00:47:57,060
brought in and narrowed based on
who you're talking to about what

867
00:47:57,060 --> 00:47:59,500
exactly it is. 
But in this case, you should 

868
00:47:59,500 --> 00:48:04,300
think about it more so as 
specifically it's a any sort of 

869
00:48:04,300 --> 00:48:09,220
binary that implements like the 
avalanche go required consensus 

870
00:48:09,220 --> 00:48:12,740
calls, and that can be anything 
so. 

871
00:48:13,310 --> 00:48:14,870
You know, you don't even need to
have blocks. 

872
00:48:14,870 --> 00:48:17,510
You don't even need to have you 
know any of this crazy stuff. 

873
00:48:17,510 --> 00:48:20,430
It's really just a binary that 
can run and communicate with 

874
00:48:20,430 --> 00:48:23,790
avalanche. 
Now the components there just to

875
00:48:23,790 --> 00:48:26,830
be specific right things you may
want in something like this. 

876
00:48:27,230 --> 00:48:29,630
What is a block? 
So you would define a block. 

877
00:48:29,670 --> 00:48:32,030
What is like a transaction? 
Look like you would define a 

878
00:48:32,030 --> 00:48:34,750
transaction. 
You know what do you store? 

879
00:48:34,790 --> 00:48:37,750
Like what if validators actually
like store on their disk? 

880
00:48:38,790 --> 00:48:40,390
You know how do you access this 
thing? 

881
00:48:40,390 --> 00:48:42,550
Like what sort of API calls you 
want to have. 

882
00:48:42,970 --> 00:48:46,810
It's all up to you as a virtual 
machine developer, and so you 

883
00:48:46,810 --> 00:48:51,010
have to remember right that 
Avalanche the goal here is how 

884
00:48:51,010 --> 00:48:55,450
can we create as low a level 
framework as possible that still

885
00:48:55,450 --> 00:48:58,210
allows for this messaging 
interface and shared sticking 

886
00:48:58,210 --> 00:49:01,410
layer that if you were going to 
create your blockchain from 

887
00:49:01,410 --> 00:49:06,690
scratch, you could still do so 
in almost any case on Avalanche.

888
00:49:07,450 --> 00:49:11,090
And so the virtual machine we're
talking about here is much more 

889
00:49:11,210 --> 00:49:13,850
like you could think of it 
almost like a server or like 

890
00:49:13,850 --> 00:49:17,930
it's much more holistic than 
just the state transition logic 

891
00:49:17,930 --> 00:49:20,450
that you may find in like the 
EVM or the VM. 

892
00:49:20,450 --> 00:49:24,650
You can almost think of it like 
a mini node, kind of particular 

893
00:49:24,650 --> 00:49:30,010
to your blockchain. 
And now Hyper SDK sort of is a. 

894
00:49:31,240 --> 00:49:34,440
Like I guess toolkit and and 
allows you to to build this 

895
00:49:34,440 --> 00:49:36,680
takes like some some things out 
of box give you something. 

896
00:49:36,760 --> 00:49:40,400
Could there also be essentially 
like another SDK like? 

897
00:49:40,400 --> 00:49:42,400
Oh, totally. 
Eating things someone builds 

898
00:49:42,800 --> 00:49:46,320
that has like, yeah, opinions 
about how I/O should be done. 

899
00:49:46,320 --> 00:49:48,000
Something. 
Exactly. 

900
00:49:48,040 --> 00:49:51,480
So the Hyper SDK basically says,
you know, what I described is 

901
00:49:51,480 --> 00:49:53,800
basically super, super broad, 
right? 

902
00:49:53,800 --> 00:49:56,520
It could be going, could be 
Rust, it could be yeah, like 

903
00:49:56,520 --> 00:49:59,400
your blocks could be potatoes 
like the. 

904
00:50:00,410 --> 00:50:04,050
The whole idea with the Hyper 
SDK is to say, OK, you have a 

905
00:50:04,050 --> 00:50:06,290
million options. 
We're going to, we're going to 

906
00:50:06,290 --> 00:50:09,530
choose a bunch for you. 
So this is what blocks look 

907
00:50:09,530 --> 00:50:12,210
like, this is what transactions 
look like, this is what 

908
00:50:12,250 --> 00:50:17,570
addresses look like. 
And then the whole idea is we'll

909
00:50:17,570 --> 00:50:21,970
give you areas where you can 
inject custom logic or your own 

910
00:50:21,970 --> 00:50:27,370
design that does not impact the 
throughput that the network 

911
00:50:27,370 --> 00:50:30,780
should be able to attain. 
So you want your own custom 

912
00:50:30,780 --> 00:50:33,820
thing like you want your own 
transaction types, maybe you 

913
00:50:33,820 --> 00:50:35,700
want your own. 
You know you want to use certain

914
00:50:35,700 --> 00:50:38,060
types of cartography, like 
there's a counter abstraction, 

915
00:50:38,060 --> 00:50:40,260
like you know you want it, you 
want all that, but you don't 

916
00:50:40,260 --> 00:50:43,180
want to like actually implement,
you know block distribution, You

917
00:50:43,180 --> 00:50:45,660
don't want to implement like 
statement, you don't want to 

918
00:50:45,660 --> 00:50:47,660
implement state sinking, you 
don't want it like. 

919
00:50:48,020 --> 00:50:51,580
So it takes a very particular 
set of tradeoffs and said we 

920
00:50:51,580 --> 00:50:55,700
assume most people want this 
abstraction break, which is. 

921
00:50:56,050 --> 00:50:59,970
Higher than what Avalanche Go 
provides out-of-the-box, but 

922
00:50:59,970 --> 00:51:04,090
lower than just deploying a 
smart contract somewhere and 

923
00:51:04,090 --> 00:51:07,770
says most people want to 
probably start around here. 

924
00:51:09,330 --> 00:51:12,690
And that's, that's the idea of 
the Hyper SDK with with the 

925
00:51:12,730 --> 00:51:15,570
underlying assumption that you 
want to go fast or you want to 

926
00:51:15,570 --> 00:51:20,490
have a lot of transactions. 
So one of the things that one 

927
00:51:20,930 --> 00:51:26,860
naturally wants to compare Hyper
SDK to is the Cosmos SDK, even 

928
00:51:26,860 --> 00:51:31,420
have similar names. 
But in the Cosmos SDK like you 

929
00:51:31,420 --> 00:51:35,060
can use it to kind of bend your 
own application specific 

930
00:51:35,060 --> 00:51:38,420
blockchain, implement your 
transaction types and what the 

931
00:51:38,420 --> 00:51:41,500
Cosmos SDK will provide is a way
to communicate with the 

932
00:51:41,500 --> 00:51:43,980
consensus and networking that is
tender meant. 

933
00:51:45,460 --> 00:51:50,900
But the Cosmos SDK kind of also 
offers opinionated ways to 

934
00:51:51,370 --> 00:51:54,770
here's how you do staking, 
Here's how you do governance, 

935
00:51:54,890 --> 00:52:00,450
Here's how you do auctions, 
Here's how you manage a token 

936
00:52:00,690 --> 00:52:05,050
right Like so. 
But Hyper SDK, it seems like has

937
00:52:05,050 --> 00:52:12,330
a narrower set of focus where 
where you are not seeking to 

938
00:52:12,330 --> 00:52:14,490
offer. 
Here's how you do governance. 

939
00:52:14,490 --> 00:52:20,210
Here's how you do auctions. 
You are only saying probably 

940
00:52:20,210 --> 00:52:24,290
like here's how you do state 
management, Here's how you do 

941
00:52:24,290 --> 00:52:49,170
block distribution. 
So I think like the way I would 

942
00:52:49,690 --> 00:52:27,850
answer that would be. 
Here's how you offer probably 

943
00:52:27,850 --> 00:52:31,570
some kind of RPC or API to 
people seeking data. 

944
00:52:32,850 --> 00:52:37,130
But you don't want to get into 
the question of how to do 

945
00:52:37,130 --> 00:52:42,130
governance, how to do, how to do
staking, how to do options, or 

946
00:52:42,130 --> 00:52:47,010
how to do token management or 
any of these financial logic in 

947
00:52:47,010 --> 00:52:52,840
a sense. 
It could like there's nothing 

948
00:52:52,840 --> 00:52:57,400
that prevents it per se as much 
to say as we'd prefer that to 

949
00:52:57,400 --> 00:53:01,560
kind of wrap this aspect of it. 
Like you could implement, you 

950
00:53:01,560 --> 00:53:05,080
know, a separate kind of layer 
on top of this to say, oh, you 

951
00:53:05,080 --> 00:53:07,320
know, here's a module store of 
things, you could pull it. 

952
00:53:07,840 --> 00:53:11,160
And the idea here is that the 
Hyper SDK is really just 

953
00:53:11,160 --> 00:53:15,160
concerned with this like super 
high throughput fabric that then

954
00:53:15,160 --> 00:53:16,960
you weave whatever you want 
into. 

955
00:53:18,070 --> 00:53:20,150
You also have to imagine that 
some of the things that the 

956
00:53:20,150 --> 00:53:24,070
Cosmos SDK has to provide are 
already provided by Apple Edge, 

957
00:53:24,550 --> 00:53:27,550
so like for example the staking 
module that doesn't exist on 

958
00:53:27,550 --> 00:53:28,910
chain. 
So you don't actually have to 

959
00:53:28,910 --> 00:53:30,430
worry about all that. 
And that's where a lot of the 

960
00:53:30,510 --> 00:53:34,630
like bugs and complexity are for
some of the other Sdk's which is

961
00:53:34,630 --> 00:53:38,070
just handled by Apple Edge. 
The one thing though, that is 

962
00:53:38,070 --> 00:53:41,310
different just for very briefly 
the technical audience, is 

963
00:53:41,310 --> 00:53:45,090
tenderment handles state. 
Always. 

964
00:53:45,210 --> 00:53:48,250
So if you want to use the Cosmos
SDK, you're using tenderness 

965
00:53:48,250 --> 00:53:51,770
state. 
The Hyper SDK provides its own 

966
00:53:51,770 --> 00:53:57,210
state and it's pluggable so you 
don't actually have to use like 

967
00:53:57,210 --> 00:53:59,570
Avalanche goes state 
orchestration at all. 

968
00:53:59,570 --> 00:54:01,970
You can provide your out so you 
could hook it up to AWS if you 

969
00:54:02,290 --> 00:54:04,890
want to, or you could just have 
your own high throughput store 

970
00:54:04,890 --> 00:54:06,890
underneath. 
It also provides its own 

971
00:54:06,890 --> 00:54:09,450
networking which Cosmos SDK 
doesn't allow. 

972
00:54:09,880 --> 00:54:13,200
So I think maybe there's some 
other ABCI plus plus stuff adds 

973
00:54:13,200 --> 00:54:17,200
more flexibility there, but for 
a long time at least, you just 

974
00:54:17,200 --> 00:54:21,640
tend to handle that for you. 
So it provides them, I guess in 

975
00:54:21,640 --> 00:54:24,800
some ways less functionality on 
some parts and that in other 

976
00:54:24,800 --> 00:54:29,120
ways much more controls into the
core than I think there is 

977
00:54:29,120 --> 00:54:33,280
anywhere on any blockchain 
building framework and so. 

978
00:54:34,130 --> 00:54:37,090
But to answer your question like
could we shape the Hyper SDK to 

979
00:54:37,090 --> 00:54:39,330
like have all these different 
modules and different things 

980
00:54:39,330 --> 00:54:42,170
that Cosmos SDK provides which 
people have shown interest in. 

981
00:54:42,370 --> 00:54:45,290
Certainly you could totally like
build up that scope if you 

982
00:54:45,290 --> 00:54:48,050
wanted to. 
But I think that the way that we

983
00:54:48,050 --> 00:54:50,930
approach it more so is we're 
platform and tool builders. 

984
00:54:51,410 --> 00:54:54,490
We want to not like build the 
whole thing up to the top, and 

985
00:54:54,490 --> 00:54:58,490
we'll have examples for sure, 
but the value seems to come from

986
00:54:59,410 --> 00:55:02,010
Can we maintain with a minimal 
feature set? 

987
00:55:02,450 --> 00:55:06,170
This really high throughput 
layer and then have all these 

988
00:55:06,170 --> 00:55:09,450
super specific logic that you 
care about maintained elsewhere,

989
00:55:09,890 --> 00:55:11,410
otherwise it just won't be 
reliable. 

990
00:55:11,410 --> 00:55:14,210
We just think there would be too
much scope to actually maintain 

991
00:55:14,210 --> 00:55:18,530
based on what people care about.
And so as a result, you know 

992
00:55:18,650 --> 00:55:21,770
we've achieved really, really 
high throughput, but you know 

993
00:55:21,770 --> 00:55:24,450
have spent less time on like 
extremely complicated 

994
00:55:24,890 --> 00:55:27,530
transaction types because that's
not really in the immediate 

995
00:55:27,530 --> 00:55:30,010
scope of what our first phase is
really about. 

996
00:55:31,270 --> 00:55:32,990
Yeah. 
So you're mentioning a lot like 

997
00:55:32,990 --> 00:55:36,670
obviously here performance and 
and that seems to be like the 

998
00:55:36,670 --> 00:55:39,350
core of your interest, right. 
And I guess also like what Hyper

999
00:55:39,350 --> 00:55:43,830
SDK set out to achieve to like 
really utilize like the 

1000
00:55:43,830 --> 00:55:45,550
potential of Avalanche, I guess 
in that sense. 

1001
00:55:46,030 --> 00:55:48,310
And yeah, we would like to I 
guess here. 

1002
00:55:48,510 --> 00:55:51,590
So what is like? 
Where is this optimization? 

1003
00:55:51,590 --> 00:55:55,030
Really there you know what are 
like the top things that Hyper 

1004
00:55:55,030 --> 00:55:59,510
SDK helps you optimize, which 
maybe other systems don't. 

1005
00:56:00,870 --> 00:56:03,590
Yes, I mean I think with any 
like thing, you're starting from

1006
00:56:03,590 --> 00:56:06,070
scratch, right? 
You you throw something on the 

1007
00:56:06,070 --> 00:56:09,510
wall based on your initial work 
and then anyone in performance 

1008
00:56:09,510 --> 00:56:12,430
will tell you all your original 
assumptions probably ended up 

1009
00:56:12,430 --> 00:56:16,350
being wrong and you just have to
benchmark everything and repeat.

1010
00:56:16,470 --> 00:56:20,830
So benchmark your ideas repeat. 
And if you just out of nowhere 

1011
00:56:20,830 --> 00:56:23,550
say, yeah, this is definitely 
going to be the most optimal, 

1012
00:56:23,550 --> 00:56:27,110
but you haven't tested every 
individual component, you're 

1013
00:56:27,110 --> 00:56:29,630
probably wrong. 
So there's no way unless you're 

1014
00:56:29,630 --> 00:56:31,930
like I mean. 
Maybe I'm only a, you know, two 

1015
00:56:31,930 --> 00:56:33,730
ex engineer. 
There are hundred ex engineers 

1016
00:56:33,730 --> 00:56:36,890
that know exactly what part is 
going to be totally messed up as

1017
00:56:36,890 --> 00:56:38,850
they build it. 
But my experience has been with 

1018
00:56:38,850 --> 00:56:42,530
this repeated benchmarking and 
so, but the the three areas 

1019
00:56:42,530 --> 00:56:45,490
we've really identified as the 
primary bottlenecks, at least 

1020
00:56:45,490 --> 00:56:49,290
within the context of avalanche 
are state management, data 

1021
00:56:49,290 --> 00:56:52,810
distribution and deferred 
validation or verification. 

1022
00:56:52,850 --> 00:56:55,010
And all of those are really what
give it its speed. 

1023
00:56:55,530 --> 00:56:59,610
So and like really a speed at 
which it assumes that people can

1024
00:56:59,610 --> 00:57:02,130
still join the network via just 
the network. 

1025
00:57:02,250 --> 00:57:04,650
And I'll dig into what I'll what
I mean by that. 

1026
00:57:04,690 --> 00:57:08,930
So the first thing, state 
management blockchains modifies 

1027
00:57:08,930 --> 00:57:10,570
state. 
You know that is the state 

1028
00:57:10,570 --> 00:57:14,610
transition, right? 
So if you can't, store and read 

1029
00:57:14,610 --> 00:57:20,690
state extremely fast and make 
sure that the overhead of a ton 

1030
00:57:20,690 --> 00:57:24,090
of like state transitions in a 
row is not well maintained. 

1031
00:57:25,510 --> 00:57:27,750
You know that's going to be your
bottleneck at some point, right?

1032
00:57:27,750 --> 00:57:30,110
Like you're going to run into 
problems because you can't keep 

1033
00:57:30,110 --> 00:57:32,710
up with the transactions like 
the nodes unless you have like 

1034
00:57:32,710 --> 00:57:34,310
crazy disks and everything like 
that. 

1035
00:57:35,270 --> 00:57:39,190
And then secondly, if it's not 
well maintained such that people

1036
00:57:39,190 --> 00:57:42,590
can't efficiently join the 
network, you're going to have 

1037
00:57:42,590 --> 00:57:44,830
problems too. 
Because if let's say you get 10 

1038
00:57:44,830 --> 00:57:48,750
million blocks in and then like,
you realize, oh shit, the only 

1039
00:57:48,750 --> 00:57:50,830
way to sync is to sync from 
scratch. 

1040
00:57:50,830 --> 00:57:54,190
But it takes longer to sync a 
block from scratch that we're 

1041
00:57:54,190 --> 00:57:57,210
producing them. 
You're going to have problems 

1042
00:57:57,210 --> 00:58:00,290
like the the network's going to 
die unless you like somehow 

1043
00:58:00,290 --> 00:58:02,330
snapshot. 
It gets really complicated, 

1044
00:58:02,330 --> 00:58:03,770
right? 
And it becomes very centralized 

1045
00:58:03,770 --> 00:58:06,290
then because then you have to 
offer disk backups for people to

1046
00:58:06,290 --> 00:58:08,410
go get. 
So the first thing that we 

1047
00:58:08,410 --> 00:58:09,970
really focused on was state 
management. 

1048
00:58:10,610 --> 00:58:12,730
So we built our own database 
from scratch. 

1049
00:58:13,210 --> 00:58:15,290
Two of them actually. 
One of them is released, one of 

1050
00:58:15,290 --> 00:58:18,690
them isn't. 
The one that's released is a 

1051
00:58:18,690 --> 00:58:23,940
Merkel path based radix tree. 
And the idea there is it uses 

1052
00:58:23,940 --> 00:58:27,020
path based storage to really 
efficiently store the current 

1053
00:58:27,020 --> 00:58:28,860
state and then some number of 
diffs back. 

1054
00:58:28,940 --> 00:58:32,460
Now I have to give credit a lot 
of the ideas of this particular 

1055
00:58:32,460 --> 00:58:35,340
implementation and like the 
theoretical pittings of it came 

1056
00:58:35,340 --> 00:58:37,980
from some of the work that Peter
Schlogy and the guest team has 

1057
00:58:37,980 --> 00:58:40,580
done. 
So I want to say that like they 

1058
00:58:40,580 --> 00:58:43,820
definitely thought deeply about 
this and pioneered a lot of the 

1059
00:58:43,820 --> 00:58:46,060
ideas in this like path based 
architecture. 

1060
00:58:46,060 --> 00:58:49,260
So I just want to give them 
credit where credits to, but we 

1061
00:58:49,260 --> 00:58:51,460
implemented a different version 
of it from scratch. 

1062
00:58:51,820 --> 00:58:55,540
That integrates state syncing 
with it and then that can run on

1063
00:58:55,580 --> 00:58:58,420
any key value underlying 
database. 

1064
00:58:59,580 --> 00:59:01,740
The second thing that we 
implemented, which is not out 

1065
00:59:01,740 --> 00:59:06,180
yet is one that takes all of the
trie management and everything 

1066
00:59:06,180 --> 00:59:08,420
related to actually doing up the
stuff you would do with the 

1067
00:59:08,420 --> 00:59:12,220
Merkel cherry and actually 
interweaves it with the key 

1068
00:59:12,220 --> 00:59:14,780
value stored me. 
So instead of having to, let's 

1069
00:59:14,780 --> 00:59:17,860
say have some data structure and
then you know you run Pebble or 

1070
00:59:17,860 --> 00:59:20,140
you run, you know, level DB 
underneath. 

1071
00:59:20,870 --> 00:59:23,390
It's one and the same, and as a 
result you can much more 

1072
00:59:23,390 --> 00:59:27,630
efficiently manage that data. 
And so state management, again, 

1073
00:59:27,630 --> 00:59:30,230
this is not a super original 
idea, is one of the primary 

1074
00:59:30,230 --> 00:59:32,510
bottlenecks of these high 
throughput chains. 

1075
00:59:32,510 --> 00:59:34,710
And so you may have to store 
everything in memory, you may 

1076
00:59:34,710 --> 00:59:38,710
have to use MV and E drives 
whatever the second data 

1077
00:59:38,710 --> 00:59:40,830
distribution. 
So if you have a lot of 

1078
00:59:40,950 --> 00:59:45,150
transactions, you got to have a 
lot of data, and that data has 

1079
00:59:45,150 --> 00:59:46,830
to be distributed to other 
people. 

1080
00:59:47,650 --> 00:59:50,490
To actually validate it and 
accept it in consensus if you 

1081
00:59:50,490 --> 00:59:54,490
can't distribute the data as 
fast as you're processing it, 

1082
00:59:55,170 --> 00:59:59,970
bottleneck so that Avalanche Go 
gives full control over 

1083
00:59:59,970 --> 01:00:03,650
networking to the virtual 
machine to the Hyper SDK. 

1084
01:00:03,770 --> 01:00:07,690
So that means you can either use
standard P to P stuff, implement

1085
01:00:07,770 --> 01:00:10,530
any P to P interaction you want 
on top of it. 

1086
01:00:11,280 --> 01:00:14,240
Or use something outside of P2P 
in general. 

1087
01:00:14,240 --> 01:00:16,800
Let's say that you have like a 
permission to use case for like 

1088
01:00:16,800 --> 01:00:18,960
you have your own network and 
you have like a really high 

1089
01:00:18,960 --> 01:00:21,800
throughput bus you want to use, 
You could totally use that the 

1090
01:00:21,800 --> 01:00:26,040
Hyper SDK provides like a P2P 
primitive for distributing data 

1091
01:00:26,040 --> 01:00:29,880
between the participants in the 
Hyper SDK, like in a Hyper SDK 

1092
01:00:29,880 --> 01:00:32,360
based network. 
That allows for like chunking 

1093
01:00:32,360 --> 01:00:35,680
the blocks up and then 
distributing them in a way that 

1094
01:00:35,680 --> 01:00:38,240
is as fast hopefully as we're 
processing that data. 

1095
01:00:39,450 --> 01:00:42,290
And then the last one is this 
notion of deferred verification.

1096
01:00:42,530 --> 01:00:45,650
Because this is very dense, I'm 
expecting also to come back and 

1097
01:00:45,650 --> 01:00:48,970
maybe summarize some of this, 
But the last one is deferred 

1098
01:00:48,970 --> 01:00:52,690
verification. 
And the idea with that is, if 

1099
01:00:53,010 --> 01:00:57,050
during the consensus process you
actually have to verify the 

1100
01:00:57,050 --> 01:01:01,370
block end to end, you will 
really slow down the ability for

1101
01:01:01,370 --> 01:01:05,210
the network to actually finalize
new data. 

1102
01:01:05,410 --> 01:01:08,910
Because before any node can 
actually vote on that new data, 

1103
01:01:08,910 --> 01:01:10,950
it has to actually verify that 
it's correct. 

1104
01:01:11,350 --> 01:01:15,270
Otherwise it may vote on things 
that like are invalid, in which 

1105
01:01:15,270 --> 01:01:17,590
case it would get slashed or, 
you know, penalized, or the 

1106
01:01:17,590 --> 01:01:21,190
network would become unstable. 
So what can you, what's the 

1107
01:01:21,230 --> 01:01:26,270
absolute minimum thing you can 
verify such that you can still 

1108
01:01:26,270 --> 01:01:30,870
participate in consensus? 
And so at the Hyper SDK breaks 

1109
01:01:30,870 --> 01:01:36,230
apart everything other than what
is minimally required to derive 

1110
01:01:36,230 --> 01:01:41,020
a deterministic result and only 
does this preprocess step before

1111
01:01:41,020 --> 01:01:43,780
voting before actually doing the
full execution. 

1112
01:01:45,220 --> 01:01:49,580
Now in summary, right, you as a 
VM developer probably don't care

1113
01:01:49,580 --> 01:01:51,780
about any of these or even know 
they exist. 

1114
01:01:51,780 --> 01:01:55,900
In some cases you just want like
this is what I need to build and

1115
01:01:55,900 --> 01:01:58,700
I want to hit this throughput or
like this TPS target. 

1116
01:01:59,580 --> 01:02:02,540
So the whole idea of the Hyper 
SDK is, let's take all these, 

1117
01:02:02,540 --> 01:02:07,000
like really useful ideas, 
implement them, audit them, make

1118
01:02:07,000 --> 01:02:09,720
them production quality such 
that when you build in your own 

1119
01:02:09,720 --> 01:02:13,320
virtual machine, you just say, I
want these types of transactions

1120
01:02:13,960 --> 01:02:17,080
and I want them to do these 
things and that's it. 

1121
01:02:17,800 --> 01:02:20,320
And that's the whole premise of 
what we're trying to deliver 

1122
01:02:20,640 --> 01:02:25,200
with really high throughput like
this kind of fabric underneath 

1123
01:02:25,200 --> 01:02:27,240
everything. 
And so it changes a bit how 

1124
01:02:27,240 --> 01:02:30,840
virtual machines are designed, 
but you could apply, you know, 

1125
01:02:31,160 --> 01:02:34,390
all sorts of crazy transaction 
types on top of this as long as 

1126
01:02:34,390 --> 01:02:36,030
they're deterministic. 
And that's really the only 

1127
01:02:36,030 --> 01:02:40,590
requirement. 
Kind of like every blockchain is

1128
01:02:41,750 --> 01:02:44,550
like every blockchain ultimately
needs to do something around 

1129
01:02:44,550 --> 01:02:47,070
state management and data 
distribution. 

1130
01:02:47,150 --> 01:02:52,430
The third one which is you don't
need to verify the entire 

1131
01:02:52,430 --> 01:02:55,870
execution for you to sign 
something maybe like this is you

1132
01:02:56,590 --> 01:02:59,350
have like optimistic 
verification of some kind. 

1133
01:03:00,210 --> 01:03:03,970
So, so I would clarify that 
particular word, optimistic 

1134
01:03:03,970 --> 01:03:06,570
because that has become very 
charged as well. 

1135
01:03:06,810 --> 01:03:09,970
So optimistic as far as I 
understand it typically means 

1136
01:03:10,010 --> 01:03:14,090
you'll like you'll basically 
execute something or you know 

1137
01:03:14,090 --> 01:03:18,250
maybe some form of executing it 
and then at a later point in 

1138
01:03:18,250 --> 01:03:20,930
time could be proven wrong by 
some proof. 

1139
01:03:22,130 --> 01:03:25,210
The idea with this deferred 
verification is that you 

1140
01:03:25,210 --> 01:03:28,130
validate enough such that that 
can never happen. 

1141
01:03:28,750 --> 01:03:30,670
It can never be proven 
incorrect. 

1142
01:03:30,670 --> 01:03:32,070
So it's still going to be 
correct. 

1143
01:03:32,870 --> 01:03:34,910
You may just not know what the 
result is yet. 

1144
01:03:35,750 --> 01:03:41,870
But you agreed on the inputs 
that will lead to the result and

1145
01:03:41,870 --> 01:03:43,670
such. 
If everything is deterministic, 

1146
01:03:44,830 --> 01:03:46,390
you'll get the same result 
everywhere. 

1147
01:03:46,750 --> 01:03:50,190
So it's a very, it's kind of a 
breaking apart when you need to 

1148
01:03:50,190 --> 01:03:51,470
like push these throughput 
right. 

1149
01:03:51,470 --> 01:03:53,550
You end up hitting certain walls
and you have to. 

1150
01:03:54,110 --> 01:03:56,150
I will say that like as you're 
trying to develop high 

1151
01:03:56,150 --> 01:03:59,350
throughput systems, it really 
requires you to take everything 

1152
01:03:59,350 --> 01:04:02,270
you know about blockchain, at 
least everything I knew and like

1153
01:04:02,270 --> 01:04:05,310
really pull it apart and say 
like why is this done here? 

1154
01:04:05,310 --> 01:04:07,710
Was this done here for a 
specific reason or just because 

1155
01:04:07,710 --> 01:04:10,230
it was convenient? 
So like to give you some 

1156
01:04:10,230 --> 01:04:13,710
comparison. 
In each like, especially like 

1157
01:04:14,030 --> 01:04:16,150
the communication between the 
consensus layer and the 

1158
01:04:16,150 --> 01:04:18,790
execution layer. 
How it works is the like the 

1159
01:04:18,790 --> 01:04:22,590
consensus layer will get a block
like some consensus layer block 

1160
01:04:23,150 --> 01:04:27,400
and then it'll ask the execution
layer, hey can you verify this 

1161
01:04:27,400 --> 01:04:30,400
block and make any state changes
in a like pending state? 

1162
01:04:30,440 --> 01:04:33,360
And then if it can, the 
execution layer will then 

1163
01:04:33,360 --> 01:04:39,280
respond that like you know I've 
executed the block and then you 

1164
01:04:39,320 --> 01:04:41,720
know we've done this come 
together. 

1165
01:04:43,000 --> 01:04:46,600
But in this case, what I'm 
saying is what if there was some

1166
01:04:46,600 --> 01:04:49,040
way or like some sort of 
constraints you could impose 

1167
01:04:49,400 --> 01:04:52,640
such that the consensus layer 
would just tell like the 

1168
01:04:52,680 --> 01:04:58,030
execution client, hey, this is 
what you will verify, make sure 

1169
01:04:58,030 --> 01:05:05,070
these people have sufficient 
funds to process that that's 

1170
01:05:05,070 --> 01:05:05,950
enough. 
That's all I need. 

1171
01:05:06,470 --> 01:05:08,750
And you don't actually have to 
make the Tri U modifications. 

1172
01:05:08,750 --> 01:05:10,590
You don't actually have to like 
generate the next route. 

1173
01:05:11,270 --> 01:05:14,230
All the stuffs that really take 
a lot of time during that 

1174
01:05:14,230 --> 01:05:17,870
process, you just don't have to 
deal with and then you like pre 

1175
01:05:17,870 --> 01:05:20,230
verify all the signatures. 
So that's also not part of that 

1176
01:05:20,230 --> 01:05:23,260
process. 
So, so basically you can take 

1177
01:05:23,260 --> 01:05:28,260
what is typically a monolithic 
verification chunk and then 

1178
01:05:28,260 --> 01:05:31,500
separate that into what its 
constituent components are. 

1179
01:05:31,860 --> 01:05:35,860
And the Hyper SCK really tries 
to be very specific about 

1180
01:05:35,860 --> 01:05:38,740
exactly what part of the 
verification it's doing. 

1181
01:05:38,740 --> 01:05:42,540
When and the invariant we offer 
virtual machine developers, then

1182
01:05:42,740 --> 01:05:48,300
we will ensure that this is done
correctly even if we separate 

1183
01:05:48,300 --> 01:05:51,620
all these parts. 
But you basically give up 

1184
01:05:51,740 --> 01:05:56,020
control over how execution 
happens and as a result you get 

1185
01:05:56,020 --> 01:06:02,180
more throughput. 
So right now Hyper SDK is alpha 

1186
01:06:02,180 --> 01:06:05,740
software and it's headed towards
a production release. 

1187
01:06:06,380 --> 01:06:09,780
What kind of benchmarking have 
you done and what do you expect 

1188
01:06:09,780 --> 01:06:13,820
to be able to deliver in 
production for a subnet? 

1189
01:06:13,820 --> 01:06:17,220
Meaning like number of 
validators multiplied by let's 

1190
01:06:17,220 --> 01:06:19,920
say. 
Simple money, trans money 

1191
01:06:19,920 --> 01:06:23,400
transfer transactions. 
What could you give in a setting

1192
01:06:23,400 --> 01:06:25,960
like that? 
Yes, I mean, I think this is The

1193
01:06:25,960 --> 01:06:30,080
funny thing about like a TPS, 
right, which is depending on 

1194
01:06:30,080 --> 01:06:34,240
there's like 100 ways you could 
manipulate this number to serve 

1195
01:06:34,240 --> 01:06:36,480
your interest. 
And I've actually been really 

1196
01:06:36,480 --> 01:06:38,680
interested in like a 
standardized framework that we 

1197
01:06:38,680 --> 01:06:42,040
could use or any network could 
use to plug into that tries to 

1198
01:06:42,040 --> 01:06:45,320
approximate like the complexity 
per transaction so that like the

1199
01:06:45,320 --> 01:06:49,430
Tps's can be viewed similarly. 
I think Aptos also released a 

1200
01:06:49,430 --> 01:06:52,310
similar benchmarking tool so 
that you could use that amongst 

1201
01:06:52,310 --> 01:06:54,150
different at least move virtual 
machines. 

1202
01:06:54,910 --> 01:06:58,270
But the to give you a short 
answer, the goal when the Hyper 

1203
01:06:58,270 --> 01:07:01,830
SDK was created was to shoot 
between 50 and 70,000 

1204
01:07:01,830 --> 01:07:05,150
transactions per second of 
simple Verification. 

1205
01:07:05,430 --> 01:07:08,270
And as I got deeper it's like 
one of those things where like 

1206
01:07:08,270 --> 01:07:11,710
if you have a number you want 
that number to go higher. 

1207
01:07:12,750 --> 01:07:14,870
So like you just keep looking at
that number, you're like, all 

1208
01:07:14,870 --> 01:07:17,870
right, I got this this time, 
this this time with the deferred

1209
01:07:17,870 --> 01:07:20,950
verification stuff, we think 
that we'll be able to go over 

1210
01:07:20,950 --> 01:07:25,470
100,000 TPS. 
And so that's now the new target

1211
01:07:25,470 --> 01:07:27,830
for hitting when we're actually 
finished implementing the 

1212
01:07:27,830 --> 01:07:31,430
deferred verification because 
we've now removed you know all 

1213
01:07:31,430 --> 01:07:34,230
the bottlenecks we can find. 
And really the bottleneck now is

1214
01:07:34,230 --> 01:07:39,190
how quickly two things, how many
cores and how quickly can you 

1215
01:07:39,190 --> 01:07:41,750
move the data between nodes 
based on where they're located. 

1216
01:07:42,250 --> 01:07:45,610
So naturally the TPS would be 
higher, let's say obviously if 

1217
01:07:45,610 --> 01:07:48,050
everyone's in the same data 
center, right, because like the 

1218
01:07:48,370 --> 01:07:52,370
network latency between 2 nodes 
instead of being you know I'm 

1219
01:07:52,370 --> 01:07:56,490
going from you know Japan to the
United States is now within you 

1220
01:07:56,490 --> 01:07:57,690
know a couple feet of each 
other. 

1221
01:07:58,050 --> 01:08:02,450
But that's what we're targeting 
is in that range and so, So from

1222
01:08:02,450 --> 01:08:05,050
a performance perspective that's
really important to us. 

1223
01:08:05,450 --> 01:08:11,450
But like I said, talking TPS is 
such a wild game that I've not, 

1224
01:08:11,490 --> 01:08:16,930
I very rarely say like hey we 
hit 65.3 transact because it 

1225
01:08:16,930 --> 01:08:21,170
just turns into war very quickly
on Twitter. 

1226
01:08:21,170 --> 01:08:24,210
So I I really try to avoid that 
just to say that what we're 

1227
01:08:24,210 --> 01:08:28,210
trying to target here is hyper 
throughput, not necessarily like

1228
01:08:28,210 --> 01:08:31,170
the throughput layer. 
And so this to wrap this kind of

1229
01:08:31,170 --> 01:08:34,210
up is, it's a real set of 
tradeoffs you want to make, 

1230
01:08:34,450 --> 01:08:37,330
right? 
Like if you need to have data 

1231
01:08:37,330 --> 01:08:41,060
availability somewhere, storing 
the amount of data you need to 

1232
01:08:41,060 --> 01:08:44,180
process 60 to 70,000 
transactions per second, even 

1233
01:08:44,859 --> 01:08:49,540
compressed, that's a lot of data
like more than any other, like 

1234
01:08:49,540 --> 01:08:51,979
more than most block chains 
process in their entirety. 

1235
01:08:52,380 --> 01:08:55,460
So like if you want to achieve 
certain throughput, you know you

1236
01:08:55,460 --> 01:08:56,899
have to make tradeoffs or you 
can't. 

1237
01:08:56,899 --> 01:08:59,700
I can't store 20 megabytes per 
second out of serum. 

1238
01:09:00,220 --> 01:09:03,180
This is the function of the 
transaction size, like you can't

1239
01:09:03,180 --> 01:09:07,000
do anything to get around that. 
And so even with like some of 

1240
01:09:07,000 --> 01:09:09,680
the crazy, like some of the new 
like data availability things 

1241
01:09:09,680 --> 01:09:12,000
that are being added to 
Ethereum, it's still expensive 

1242
01:09:12,000 --> 01:09:15,439
and still would saturate all. 
So if you want to achieve like 

1243
01:09:15,439 --> 01:09:17,960
crazy levels, OK, well, now 
you're using you get into 

1244
01:09:17,960 --> 01:09:21,760
Volidium territory or like L3 
territory, but you have to put 

1245
01:09:21,760 --> 01:09:24,720
this data somewhere. 
And so do you want to use, you 

1246
01:09:24,720 --> 01:09:27,560
know, some other mechanism have 
like put that in some other 

1247
01:09:27,560 --> 01:09:29,080
things that you pay for 
separately? 

1248
01:09:29,240 --> 01:09:32,880
Or do you want your network, the
subnet, really to own that in 

1249
01:09:32,880 --> 01:09:35,210
its entirety? 
And the Hyper SDK is really 

1250
01:09:35,210 --> 01:09:38,370
about providing you that option,
which is maybe your community 

1251
01:09:38,370 --> 01:09:40,410
just wants to run the whole 
thing and they just want to 

1252
01:09:40,410 --> 01:09:43,569
achieve that throughput and 
they're willing to own and 

1253
01:09:43,569 --> 01:09:45,930
secure it to make that happen 
so. 

1254
01:09:47,170 --> 01:09:51,770
Like my personal experiences, 
it's like running an 

1255
01:09:51,770 --> 01:09:54,850
organization that run loads 
across like 50 networks, 

1256
01:09:54,850 --> 01:09:56,690
including the Avalanche main 
net. 

1257
01:09:57,090 --> 01:10:02,170
My sense is, you know, like the 
like a subnet or? 

1258
01:10:02,730 --> 01:10:07,210
A sovereign chain or your own 
chain in any way starts to only 

1259
01:10:07,210 --> 01:10:12,250
make sense when your application
is kind of really successful in 

1260
01:10:12,650 --> 01:10:18,130
terms of transactions per second
or it needs certain high custom 

1261
01:10:18,130 --> 01:10:19,970
features. 
Like you know, the perfect 

1262
01:10:19,970 --> 01:10:24,130
example is kind of like a dy DX 
like network processing a 

1263
01:10:24,130 --> 01:10:29,290
billion dollars in perpetual 
volume per per day. 

1264
01:10:30,340 --> 01:10:33,500
Already has success. 
Started off as a smart contract 

1265
01:10:33,500 --> 01:10:37,900
and now it makes sense to go 
application specific like with 

1266
01:10:37,900 --> 01:10:42,060
their own blockchain. 
That's when like building your 

1267
01:10:42,060 --> 01:10:46,540
own chain makes sense. 
It doesn't make sense if kind of

1268
01:10:46,540 --> 01:10:49,580
you're just starting out and you
hardly have any users. 

1269
01:10:50,580 --> 01:10:54,300
And if and if you think of like 
that model that people are gonna

1270
01:10:54,300 --> 01:10:56,620
be building their own chains 
when their applications. 

1271
01:10:56,920 --> 01:11:00,120
Has kind of like success and the
need for throughput is kind of 

1272
01:11:00,120 --> 01:11:06,640
clear then usually those kinds 
of parties can afford to bring 

1273
01:11:06,840 --> 01:11:11,880
50 or 100 or 200 of their own 
validators, ensure data 

1274
01:11:11,880 --> 01:11:16,120
availability themselves and not 
need not actually even want to 

1275
01:11:16,120 --> 01:11:19,920
rely on other people for it. 
I totally understand your point 

1276
01:11:20,040 --> 01:11:23,280
and I think that that's why like
having this spectrum that people

1277
01:11:23,280 --> 01:11:25,160
are interested in supporting 
makes sense. 

1278
01:11:25,820 --> 01:11:29,380
That being said, you know, I 
think there are parallels early 

1279
01:11:29,460 --> 01:11:33,260
on like other technology 
journeys of you know, by 

1280
01:11:33,260 --> 01:11:36,420
providing the functionality 
where you don't assume you need 

1281
01:11:36,420 --> 01:11:38,500
to have this like low 
throughput, you can just target 

1282
01:11:38,500 --> 01:11:41,740
a totally different world to 
begin with, can be quite an 

1283
01:11:41,740 --> 01:11:44,860
unlocking force, right. 
So like if I agree corralling 

1284
01:11:44,860 --> 01:11:48,460
your security, writing all these
nodes cost everybody millions of

1285
01:11:48,460 --> 01:11:52,940
dollars in USD to set up. 
That's quite a large commitment 

1286
01:11:53,060 --> 01:11:57,300
for people originally. 
But if you can make it such that

1287
01:11:57,300 --> 01:11:59,500
that architecture and that 
framework is much more 

1288
01:11:59,500 --> 01:12:02,660
compatible with like a pay as 
you go kind of setup as your 

1289
01:12:02,660 --> 01:12:06,540
network grows and scales such 
that you from the beginning can 

1290
01:12:06,540 --> 01:12:08,260
achieve a totally different 
world. 

1291
01:12:09,540 --> 01:12:12,500
You don't have to start like 
this like really slow walk on 

1292
01:12:12,500 --> 01:12:16,460
like a you know traditional L1 
TPS journey if from the 

1293
01:12:16,460 --> 01:12:19,780
beginning it's just not even 
conceivable you could achieve 

1294
01:12:19,780 --> 01:12:21,620
that with your application use 
case. 

1295
01:12:22,060 --> 01:12:25,760
So like the way I think about it
sometimes and is like great if I

1296
01:12:25,760 --> 01:12:28,760
have dial up, I'm only gonna do 
dial up things on the Internet. 

1297
01:12:29,200 --> 01:12:32,360
And you know you could argue 
that like great if broad map 

1298
01:12:32,360 --> 01:12:36,200
like broadband costs more money.
I'll start with dial up make 

1299
01:12:36,200 --> 01:12:38,400
sure that people like it and 
then go to broadband. 

1300
01:12:38,880 --> 01:12:41,640
But if there's some things that 
never would look good on dial 

1301
01:12:41,640 --> 01:12:44,680
up, you gotta just go right to 
broadband. 

1302
01:12:45,120 --> 01:12:48,760
And so as I think about what 
Hyper SDK Labs, it's just a 

1303
01:12:48,760 --> 01:12:51,200
different tradeoff, right? 
Maybe for like really high value

1304
01:12:51,200 --> 01:12:54,760
D file applications, this is 
maybe not the best place to 

1305
01:12:54,760 --> 01:12:56,800
start. 
If you really prefer, maybe 

1306
01:12:56,920 --> 01:12:59,160
share liquidity and shared 
security. 

1307
01:12:59,960 --> 01:13:02,320
But if you're trying to just 
think outside the box and do 

1308
01:13:02,320 --> 01:13:05,560
something crazy that just would 
never make sense economically on

1309
01:13:05,560 --> 01:13:08,600
an L1 where you have to share 
all your data or whatever, I 

1310
01:13:08,600 --> 01:13:11,680
think there's a viable 
alternative here where you can 

1311
01:13:11,680 --> 01:13:14,680
corral security or maybe at the 
security at the beginning, it's 

1312
01:13:14,680 --> 01:13:16,400
just not as important to you for
some reason. 

1313
01:13:16,840 --> 01:13:20,240
So I think there are tradeoffs 
and the whole point of my spiel 

1314
01:13:20,240 --> 01:13:24,180
I guess is that's okay. 
I don't think there has to be a 

1315
01:13:24,180 --> 01:13:26,860
one thing we all agree on. 
Right. 

1316
01:13:26,860 --> 01:13:31,140
I guess you could also start out
with like, you know, I don't 

1317
01:13:31,140 --> 01:13:35,220
know, one machine more or less 
like validating the subnet and 

1318
01:13:35,220 --> 01:13:38,540
then grow that over time if 
that's the the bottleneck. 

1319
01:13:38,740 --> 01:13:42,980
But you start with a very heavy 
machine there already, sort of 

1320
01:13:43,140 --> 01:13:43,900
in a way. 
Yeah. 

1321
01:13:43,900 --> 01:13:46,940
I mean the point here is we're 
providing the tool to give the, 

1322
01:13:47,420 --> 01:13:51,340
you know, virtual, the aspiring 
virtual machine builder choices.

1323
01:13:52,020 --> 01:13:54,450
That's it. 
All right, cool. 

1324
01:13:54,450 --> 01:13:56,570
Yeah. 
Patrick, thanks so much for 

1325
01:13:56,570 --> 01:13:59,890
coming on and and expanding on 
Hyper SDK and Never Life for us,

1326
01:13:59,890 --> 01:14:03,770
like probably for me at least 
one of the most deep engineering

1327
01:14:03,770 --> 01:14:07,490
episodes I've done. 
So it's super interesting and I 

1328
01:14:07,490 --> 01:14:10,610
think we hopefully we fared well
maybe. 

1329
01:14:10,610 --> 01:14:12,970
Yeah, to do. 
Before we wrap it up, I would be

1330
01:14:12,970 --> 01:14:17,490
great if you could like again, 
tell us where the Hyper SDK is 

1331
01:14:17,490 --> 01:14:20,970
right now in development and you
know how how people can get 

1332
01:14:20,970 --> 01:14:23,410
involved. 
Yeah, great. 

1333
01:14:23,810 --> 01:14:25,010
Yeah. 
Thanks again for having me. 

1334
01:14:25,010 --> 01:14:27,170
I always have a blast talking 
about this. 

1335
01:14:27,850 --> 01:14:32,010
Tried to cut myself off at some 
points, but you know, we, I love

1336
01:14:32,010 --> 01:14:34,450
having these combos of, you 
know, other people want to chat 

1337
01:14:34,450 --> 01:14:37,130
about, you know, whatever is 
going really deep, whether that 

1338
01:14:37,130 --> 01:14:40,490
be one-on-one or whatever, very 
interested in in doing that. 

1339
01:14:41,290 --> 01:14:45,410
But yeah, so where we're going 
now is really starting that path

1340
01:14:45,410 --> 01:14:47,530
to production hardening. 
So right now as you mentioned, 

1341
01:14:47,530 --> 01:14:50,660
it's alpha level software, so 
you know it's not audited yet. 

1342
01:14:50,660 --> 01:14:53,060
I wouldn't say it's safe for 
production, but it's really fun 

1343
01:14:53,060 --> 01:14:56,100
to experiment with. 
So if you're a contributor, it's

1344
01:14:56,100 --> 01:14:59,100
a great time to join the project
and start contributing to it. 

1345
01:14:59,100 --> 01:15:02,980
Everything we do is fully open. 
So if you want to start like 

1346
01:15:03,060 --> 01:15:06,660
earning you know contributions 
on different projects, this is a

1347
01:15:06,660 --> 01:15:09,700
great one to check out. 
There's a lot of low, late low 

1348
01:15:09,700 --> 01:15:12,370
hanging fruit and you know, 
whether that be just simple 

1349
01:15:12,370 --> 01:15:15,490
testing or like kind of cleaning
things up, doing basic 

1350
01:15:15,490 --> 01:15:18,330
optimization work with memory 
work or you know speed of 

1351
01:15:18,330 --> 01:15:20,130
execution, it's a great place to
jump in. 

1352
01:15:21,210 --> 01:15:23,850
And then the other thing we're 
working on in association with 

1353
01:15:23,850 --> 01:15:29,090
the production hardening is 
adding a basic WASM executor as 

1354
01:15:29,090 --> 01:15:32,650
a what we call programs. 
So although it's great to always

1355
01:15:32,650 --> 01:15:36,130
be extremely hyperoptimized, 
some of the most exciting things

1356
01:15:36,130 --> 01:15:38,970
on blockchain come from having 
this permissionless deployment 

1357
01:15:38,970 --> 01:15:41,890
of programs on chain. 
And so we want to offer that 

1358
01:15:42,290 --> 01:15:44,850
option as well to people where 
maybe, you know, the vast 

1359
01:15:44,850 --> 01:15:47,770
majority of your transactions 
are very specific to the Hyper 

1360
01:15:47,770 --> 01:15:51,370
SDK and like implemented, but 
you want to offer some ability 

1361
01:15:51,370 --> 01:15:56,290
to like stitch them together or 
do things without guessing every

1362
01:15:56,290 --> 01:15:59,130
possible way people may interact
with your virtual machine. 

1363
01:16:00,010 --> 01:16:02,650
So that's another thing that 
we're really working on now. 

1364
01:16:02,650 --> 01:16:05,130
So yeah, I mean, fun time for 
me. 

1365
01:16:05,130 --> 01:16:06,770
A lot of coding is what that 
means. 

1366
01:16:06,850 --> 01:16:10,320
And hopefully, you know, the 
next few months will be entering

1367
01:16:10,320 --> 01:16:15,960
the audit process for much of 
this because yeah, speed doesn't

1368
01:16:15,960 --> 01:16:19,200
mean anything if it breaks or 
has massive bugs, right? 

1369
01:16:19,200 --> 01:16:24,480
So that's a huge concern. 
All right. 

1370
01:16:24,480 --> 01:16:27,160
Then, yeah, Patrick, again, 
thanks so much for coming on. 

1371
01:16:27,680 --> 01:16:33,800
And yeah, hope we get to see 
some high performance Hyper SDK 

1372
01:16:33,840 --> 01:16:37,840
subnets when we next talk in 
like a few months and yeah. 

1373
01:16:39,080 --> 01:16:40,440
Thank you for to our listeners 
as well. 

1374
01:16:42,640 --> 01:16:44,360
Thank you for joining us on this
week's episode. 

1375
01:16:44,760 --> 01:16:46,360
We release new episodes every 
week. 

1376
01:16:46,960 --> 01:16:49,720
You can find and subscribe to 
the show on iTunes, Spotify, 

1377
01:16:49,800 --> 01:16:53,440
YouTube, SoundCloud or wherever 
you listen to podcasts and if 

1378
01:16:53,440 --> 01:16:55,000
you have a Google Home or Alexa 
device. 

1379
01:16:55,430 --> 01:16:57,590
You can tell it To listen to the
latest episode of the EPICENTER 

1380
01:16:57,590 --> 01:17:01,590
podcast, go to Epicenter TV, 
subscribe for a full list of 

1381
01:17:01,590 --> 01:17:02,790
places where you can watch and 
listen. 

1382
01:17:02,790 --> 01:17:05,710
And while you're there, be sure 
to sign up for the newsletter so

1383
01:17:05,710 --> 01:17:08,030
you get new episodes in your 
inbox as they're released. 

1384
01:17:08,030 --> 01:17:11,350
If you want to interact with us 
guests or other podcast 

1385
01:17:11,350 --> 01:17:12,990
listeners, you can follow us on 
Twitter. 

1386
01:17:13,390 --> 01:17:14,870
And please leave us a review on 
iTunes. 

1387
01:17:14,870 --> 01:17:17,350
It helps to be behind the show 
and we're always happy to read 

1388
01:17:17,350 --> 01:17:19,750
them. 
So thanks so much and we look 

1389
01:17:19,750 --> 01:17:30,670
forward to being back next week.
I want to read it.