1
00:00:00,000 --> 00:00:03,680
like the falling inside of your room instead of a dark background.

2
00:00:03,680 --> 00:00:06,320
I know it's too bright here. Stupid.

3
00:00:10,080 --> 00:00:16,000
Welcome to Game of Nodes, a weekly podcast on the cosmos from independent validated teams.

4
00:00:19,680 --> 00:00:23,200
Okay, hello and welcome to Game of Nodes, a weekly podcast

5
00:00:23,200 --> 00:00:30,960
by independent validators on the cosmos. This week we have Asaf from Secret with us,

6
00:00:30,960 --> 00:00:34,960
and we're going to ask him probably some really basic questions about what he does

7
00:00:34,960 --> 00:00:41,840
and what Secret do, despite the fact that, wait, two, three of the people on this podcast validate

8
00:00:41,840 --> 00:00:47,360
Secret? Two, I think. Probably two at the moment. You don't, Serp? I do not.

9
00:00:47,360 --> 00:00:51,200
You don't? Okay, that's my mistake then. So apologies.

10
00:00:51,200 --> 00:00:53,040
He wants to be in the Secret game, but he's not there yet.

11
00:00:53,040 --> 00:00:54,000
The next expansion.

12
00:00:55,040 --> 00:01:01,200
Yeah, okay. So apologies in advance for that, Serp. First off, no, we have some,

13
00:01:02,080 --> 00:01:03,920
although I'm guessing actually you don't have the spreadsheet up.

14
00:01:05,120 --> 00:01:06,560
Oh, no, I do not.

15
00:01:09,440 --> 00:01:16,720
We have some follow-ups. We had a lot of questions over the last week, and our new format,

16
00:01:16,720 --> 00:01:20,160
our continuing changing the format every week so that we don't actually have any kind of

17
00:01:20,160 --> 00:01:25,040
regularity dictates that we're now going to do some of the follow-ups for previous weeks right

18
00:01:25,040 --> 00:01:31,120
at the top of the show before doing questions at the end. So we have quite a few follow-ups

19
00:01:31,120 --> 00:01:40,960
related to what happened with Prop 21 on Juneau, but also some questions about what that means for

20
00:01:40,960 --> 00:01:50,480
the centralization of validator sets as well. So I will read through these, and you will answer them

21
00:01:50,480 --> 00:01:55,040
other people who aren't me. So you have to understand.

22
00:01:55,040 --> 00:01:56,800
That's one way to get out of answering the questions.

23
00:01:57,520 --> 00:02:02,080
You have to understand that I am so incredibly fucking tired right now that I'm running on like,

24
00:02:04,080 --> 00:02:06,880
I don't know, something that's not energy.

25
00:02:06,880 --> 00:02:07,680
Vegemite?

26
00:02:08,560 --> 00:02:10,400
Yeah, something for you to feel.

27
00:02:10,400 --> 00:02:11,360
Why are you so tired?

28
00:02:12,240 --> 00:02:18,560
Because everyone has now, everyone's taken to doing upgrades in the middle of the night and

29
00:02:18,560 --> 00:02:24,800
podcasts early in the morning. It's 7am. And for some reason, everyone decided to string

30
00:02:24,800 --> 00:02:30,480
upgrades together last night. So eventually, I just left it up to Cosmovisor.

31
00:02:31,840 --> 00:02:32,320
Don't we all?

32
00:02:34,800 --> 00:02:37,600
Right. So follow-up questions from last week.

33
00:02:37,600 --> 00:02:45,280
So the first one we have is, how could it be that 125 validators didn't thoroughly check the code

34
00:02:45,280 --> 00:02:45,760
properly?

35
00:02:47,760 --> 00:02:53,760
I mean, I can touch on this one a little bit. So there are a handful of us that are on the

36
00:02:53,760 --> 00:02:56,240
testnet and are very committed to running on the testnet.

37
00:02:56,240 --> 00:02:57,200
Did anyone hear the question?

38
00:02:58,400 --> 00:03:00,240
Yeah. Can you hear the answer?

39
00:03:00,880 --> 00:03:01,680
You're not hearing us?

40
00:03:01,680 --> 00:03:03,040
No. Is someone talking?

41
00:03:03,040 --> 00:03:03,280
Yeah.

42
00:03:04,400 --> 00:03:05,680
Can I be? Am I heard right now?

43
00:03:05,680 --> 00:03:06,480
Yeah, I can hear you.

44
00:03:06,480 --> 00:03:07,840
Yeah, you're good.

45
00:03:08,480 --> 00:03:14,320
Okay. Okay. So from my perspective, there's a handful of us that are really committed to running

46
00:03:14,320 --> 00:03:18,160
on the testnet. And we make sure that everything happens correctly on the testnet.

47
00:03:18,160 --> 00:03:23,440
And that's kind of what happened here. We had ran like, basically did a dry run on the testnet to

48
00:03:23,440 --> 00:03:29,120
make sure that everything worked as it should. And admittedly, due to a lack of due diligence, I

49
00:03:29,120 --> 00:03:37,760
suppose, I didn't confirm that may not have the exact same functionality as the testnet. That's

50
00:03:37,760 --> 00:03:39,840
basically how it went awry from my perspective.

51
00:03:43,200 --> 00:03:47,120
Yeah. So I think also just the context in this question, I think, is about what we're talking

52
00:03:47,120 --> 00:03:55,680
about here. So this is on the basis of prop 20, where within the upgrade, the aforementioned

53
00:03:55,680 --> 00:04:00,960
funds were sent to the incorrect address through just a basic, a basic mistake, a pretty complicated

54
00:04:00,960 --> 00:04:06,320
mistake, right? In terms of trying to be able to identify or be able to paste in the hex code

55
00:04:06,320 --> 00:04:10,720
associated to the right contract address or the right wall address or something similar to that,

56
00:04:10,720 --> 00:04:14,960
right? So I think that's what that's going on. And so the question here is the prop 21 was to

57
00:04:14,960 --> 00:04:20,080
be able to go fix that mistake. And so the idea would be how come 125 validators did not review

58
00:04:20,080 --> 00:04:32,320
that code in prop 20 for that error, right? Yeah, that context sounds right to me. Yeah.

59
00:04:32,320 --> 00:04:32,640
Checking.

60
00:04:35,680 --> 00:04:37,760
Frey, you're going to give an answer for this?

61
00:04:38,640 --> 00:04:44,400
Yeah. Well, I think there's also, and then there's also a final, I think prop 21 is unusual in the

62
00:04:44,400 --> 00:04:49,520
sense that there are also developers who had, and we're one of them who had recused themselves

63
00:04:49,520 --> 00:05:00,080
from working on that code for legal and regulatory reasons. And literally, we don't have get commits

64
00:05:00,080 --> 00:05:04,480
against it, haven't reviewed the code. We've helped run test nets and done all the things that were

65
00:05:04,480 --> 00:05:10,160
the kind of the normal stuff that we do for Juno. We've helped run test nets. We helped stage and

66
00:05:10,160 --> 00:05:15,840
write instructions and coordinate the validator set and whatnot. But insofar as actually working on

67
00:05:15,840 --> 00:05:22,720
checking, being responsible for the merging, tagging, and QA on that piece of code,

68
00:05:24,960 --> 00:05:31,200
we left it to other people. And so that didn't mean that there were radically fewer eyes on that

69
00:05:31,200 --> 00:05:34,720
particular piece of code and that particular handler than there would have been otherwise,

70
00:05:34,720 --> 00:05:41,600
but there were fewer. And so things, things unfortunately got missed from, I think,

71
00:05:41,600 --> 00:05:48,880
from the developer end because of, in some cases, just being very tired after the preceding 10 weeks

72
00:05:48,880 --> 00:05:57,120
and also just being a bit fast and loose with the actual merge itself, which we've had a talk

73
00:05:57,120 --> 00:06:02,080
about how that happened. And we've done some, we've done a little bit of, we've done, there's

74
00:06:02,080 --> 00:06:08,880
a whole bunch of root cause analysis that will come out on everything from the chainhole

75
00:06:08,880 --> 00:06:17,600
to Prop 21. There's a lot to cover because it's been an insane period of time. But that we've

76
00:06:17,600 --> 00:06:21,680
already had a discussion about that and what steps we need to take to avoid it in future.

77
00:06:22,560 --> 00:06:26,480
But because it's such an unusual situation, it's also very hard to see how we would

78
00:06:28,400 --> 00:06:32,960
end up in that situation again, effectively, where there were people who were sort of out of

79
00:06:32,960 --> 00:06:40,960
the equation in terms of manpower as well. So that's going to presumably, and kind of quite

80
00:06:40,960 --> 00:06:45,040
fairly piss off some people who are like, well, you should be looking at this code or you, or

81
00:06:45,040 --> 00:06:48,960
nothing, you should either be working on everything or nothing. But, you know, it's easy to say that

82
00:06:48,960 --> 00:06:54,880
until you have potentially regulated breathing down your neck. So that's the kind of important

83
00:06:54,880 --> 00:07:03,200
date to point, I think on that one. I think 21 was pretty unique in that a lot of us didn't

84
00:07:03,200 --> 00:07:09,920
want to be working on it just because of other reasons other than the network. So it was left to

85
00:07:10,800 --> 00:07:16,960
the people who could work on it. But also keep in mind that it's hexing coded. So it's not only

86
00:07:16,960 --> 00:07:23,840
looking at the code. It's, I think it was an assumption that it was the right address. So

87
00:07:23,840 --> 00:07:28,320
like it's not just reading the code, then you have to then extract that and then decode it

88
00:07:29,120 --> 00:07:35,920
and then check it, assuming that you know what that address is supposed to be. Like making sure

89
00:07:35,920 --> 00:07:41,760
that address is correct is like a bit of a task. And you need to know that the address is what the

90
00:07:41,760 --> 00:07:48,480
address is. And maybe I'm not sure if the address was published before. There were instructions,

91
00:07:48,480 --> 00:07:53,200
but they were not well circulated. So that's another thing I think that contributed.

92
00:07:53,200 --> 00:07:58,320
Yeah. So that was probably a falling over in itself that if there was an intention, I mean,

93
00:07:58,320 --> 00:08:04,000
it probably should have been in the proposal to put that address so that people could check.

94
00:08:05,200 --> 00:08:10,160
Yeah. And I think there is actually also one more thing, which is that the hex was used rather

95
00:08:10,160 --> 00:08:16,880
than just the back 32, which is a bit of a weird design decision. But again, like, I'm not going

96
00:08:16,880 --> 00:08:20,880
to throw stones about it because we literally didn't work on that code. We didn't look at that

97
00:08:20,880 --> 00:08:25,600
code. We didn't help review it. And so we can't turn around and say, oh, we wouldn't have designed

98
00:08:25,600 --> 00:08:30,240
it that way because, well, we could have chipped in and helped, but we decided not to for the reasons

99
00:08:30,240 --> 00:08:37,360
mentioned above. So yeah, it is a bit of a tricky one, I think. And there's no one personal group

100
00:08:37,360 --> 00:08:43,200
of people to blame. I think it's a collective failure of, do you know, in a pretty tough situation?

101
00:08:43,200 --> 00:08:46,880
But it does, I think there are a lot of interesting things here around like, you know,

102
00:08:46,880 --> 00:08:51,520
the Valset checking code, right? And this is not just this is kind of why I thought this was a

103
00:08:51,520 --> 00:08:55,280
particularly interesting one, because obviously Stargaze has got some upgrades coming up now,

104
00:08:55,280 --> 00:08:59,360
and they have governance controlled smart contracts, right? So, you know, what's the

105
00:08:59,360 --> 00:09:05,120
betting that every validate there is check the hex on, sorry, there's a hash of those smart contracts.

106
00:09:06,880 --> 00:09:11,680
Yeah. But also, like, it kind of leads into the next question here.

107
00:09:11,680 --> 00:09:18,240
Well, I mean, and we've got a surface. So like, you know, on secret, when you run a when you run

108
00:09:18,240 --> 00:09:23,040
an upgrade, like, what's your expectation there for your validator set, you know, in terms of

109
00:09:23,040 --> 00:09:25,440
checking the code before they run it, they can't check the code.

110
00:09:28,080 --> 00:09:28,720
Well, it's not close.

111
00:09:33,120 --> 00:09:35,120
Isn't it? I thought it's all pre-composed, isn't it?

112
00:09:35,120 --> 00:09:42,080
What is it? Is the I thought the secret code was all just pre-compiled.

113
00:09:43,680 --> 00:09:47,120
Yeah, it's pre-compiled, but the code is open source.

114
00:09:47,840 --> 00:09:54,720
Oh, is it? Okay. Because because all the instructions were just downloading the

115
00:09:54,720 --> 00:10:00,800
binaries, I think I just assumed that for security reasons, it was closed source.

116
00:10:00,800 --> 00:10:07,440
So, I'm wrong, but I believe the reason why we download the binary set of compiling ourselves

117
00:10:07,440 --> 00:10:13,600
is because it's because of SGX. In order to actually compile an SGX binary, it requires

118
00:10:13,600 --> 00:10:19,760
having like a certain enclave permissions or Intel permissions that average validators just

119
00:10:19,760 --> 00:10:25,280
won't have. And so my understanding is secret labs compiles them for us so that not all of us need our

120
00:10:25,280 --> 00:10:31,360
own SGX T effectively. That doesn't have to do with the code itself. Is that correct or so? Is that

121
00:10:31,360 --> 00:10:36,720
at least in spitting distance? Yeah, yeah. And also the code is open source for security reasons.

122
00:10:38,480 --> 00:10:45,360
Yeah, totally. I mean, I just assumed that there must have been some encryption key or

123
00:10:45,360 --> 00:10:51,920
something associated with it that would prevent it from being open sourced. But, you know,

124
00:10:51,920 --> 00:10:59,440
we're still very new. I only entered the set last week, still very new to secret. So, that's good to know.

125
00:11:01,840 --> 00:11:04,400
Yeah, so, where'd it come? Nice. Yeah, thank you.

126
00:11:08,080 --> 00:11:13,840
So, do we want to move on to the next question, which sort of leads into that in that, is it safe

127
00:11:13,840 --> 00:11:20,640
that validators don't have any program experience? I think that should read. Is it safe that some

128
00:11:20,640 --> 00:11:28,160
validators don't have any programming experience? I think a lot of them do, but perhaps there are also

129
00:11:29,200 --> 00:11:38,880
percentage of people who can't read code or maybe aren't proficient in that type or language. So,

130
00:11:41,120 --> 00:11:45,120
yeah, anyone want to grab onto that one or want to listen to me ramble for like 10 minutes?

131
00:11:45,920 --> 00:11:50,160
I could touch on that one. I don't think that having program experience necessarily benefits

132
00:11:50,160 --> 00:11:55,200
you much really at all. What really benefits you is having, you know, Linux experience,

133
00:11:55,200 --> 00:12:01,680
having sysadmin experience, experience with distributed systems. Knowing code only helps

134
00:12:01,680 --> 00:12:05,920
insofar as because you're a software engineer or have software experience, you probably are more

135
00:12:05,920 --> 00:12:12,400
acclimated to Linux and other distributions just by virtue of that. But really, that's the only leg

136
00:12:12,400 --> 00:12:18,400
up that being a software person gives you when running validators. I don't think there's inherently

137
00:12:18,400 --> 00:12:24,880
some magical key that being an engineer or software person gives you in the validator game.

138
00:12:24,880 --> 00:12:32,000
I think in terms of the previous question, though, if you're expected to check the code, you do need,

139
00:12:33,440 --> 00:12:40,480
so I guess there is a sub question within these two questions, which is that do you need enough

140
00:12:40,480 --> 00:12:46,480
technically experience to read the code and to determine what it's going to do to a reasonable

141
00:12:46,480 --> 00:12:52,240
satisfaction in order to be a validator? And is that something that foundations and teams should

142
00:12:52,240 --> 00:12:59,920
be looking for as a qualification for a validator? Yeah, I think it's fair to say that,

143
00:13:00,560 --> 00:13:05,440
you know, as time goes by, you probably, and if when you're recruiting, you should be looking

144
00:13:05,440 --> 00:13:11,840
for someone with those kinds of skills in addition to like DevOps. I think in terms of

145
00:13:11,840 --> 00:13:19,920
actually running a validator, that, you know, being a bash engineer is probably more important than

146
00:13:19,920 --> 00:13:24,800
being able to read the code. But at the same time, there needs to be enough eyes across the

147
00:13:24,800 --> 00:13:31,920
validator set that can read code to make sure that we're not injecting malicious code into the

148
00:13:31,920 --> 00:13:42,320
validator set. So I think is it important for every validator to have coders in their team?

149
00:13:42,320 --> 00:13:49,120
I don't think so. Is it important that there is a decent amount of coders across the VAL set?

150
00:13:49,120 --> 00:13:56,160
I think it's beneficial if you don't fully, you know, because we shouldn't put our entire trust

151
00:13:56,160 --> 00:14:01,760
in the team because A, they make mistakes and B, it's crypto, anyone can be, you know, trying

152
00:14:01,760 --> 00:14:06,240
to rug everybody or anything like that. So they definitely should be people checking it and they

153
00:14:06,240 --> 00:14:12,000
definitely should be coders that can check it. But I don't think everyone should be or needs to be.

154
00:14:12,640 --> 00:14:18,320
So then just becomes what a question of, you know, how big does your VAL set need to be

155
00:14:19,360 --> 00:14:26,240
statistically to make it likely that one team has definitely checked the code or two teams or

156
00:14:26,240 --> 00:14:32,080
three teams or whatever your metric is for a reasonable amount of checking, right? Yeah,

157
00:14:32,080 --> 00:14:38,880
and I think like this is a thing where it can help that people advertise, you know, their

158
00:14:38,880 --> 00:14:44,800
capabilities. And if that's something that they engage in, then people should be supporting them

159
00:14:44,800 --> 00:14:51,920
for that work as well. So with delegations, you know, because people have to realise that

160
00:14:51,920 --> 00:14:59,680
there's teams out there that are just barely hanging onto a validator so that they can make more

161
00:14:59,680 --> 00:15:04,720
money off their other scheme that they're running. That's not the case for all those types of things,

162
00:15:04,720 --> 00:15:08,720
but there's certainly ones out there that is aping to running a validator code

163
00:15:10,080 --> 00:15:17,520
to, you know, coincide with their marketing. So if you think that actually running non-malicious

164
00:15:17,520 --> 00:15:22,560
code is important, then you should support validators who undertake that work on behalf of

165
00:15:22,560 --> 00:15:29,920
the rest of the validator set. Cool. Yeah. Go back to that question. I think we glossed over a

166
00:15:29,920 --> 00:15:36,080
little bit, but on secret, like when you guys are producing, you know, builds or you're producing,

167
00:15:36,080 --> 00:15:42,560
you know, tags for releases, what is your expectation in terms of what is your expectations

168
00:15:42,560 --> 00:15:48,960
from testing or from validation or from quality control from the validator set? Or who do you

169
00:15:48,960 --> 00:15:56,080
look to for those types of roles? Yes. Up until recently, no one really looked at the

170
00:15:56,960 --> 00:16:04,400
actual code from the validator set. I think it's a pretty new movement that validators also

171
00:16:04,400 --> 00:16:13,680
develop the code and test the code themselves. Like in a deep manner, not just like running it

172
00:16:13,680 --> 00:16:20,560
on test methods and stuff. Right. So how to do that right now? Yeah.

173
00:16:23,120 --> 00:16:29,680
Well, that's because a lot of times people are able to just do that and get away with it because

174
00:16:29,680 --> 00:16:34,160
there's been no consequences. So it's interesting to see a time when there have been consequences

175
00:16:34,160 --> 00:16:39,920
because people haven't checked the code. I think when we had Shane and Cistler on here,

176
00:16:39,920 --> 00:16:46,000
we also talked about there was a early Stargaze testnet where they snuck something into an

177
00:16:46,000 --> 00:16:53,040
upgrade handler. And it said, if you've read this code, contact the team. Right. And then it was like

178
00:16:53,040 --> 00:16:58,400
one person out of 50 or something actually looked in the code and was just like, oh,

179
00:16:58,400 --> 00:17:07,280
hang on a minute. What's this? That's pretty good. So yeah. Like you say, maybe that's the thing

180
00:17:07,280 --> 00:17:11,040
that wasn't really expected in the past, but is expected now for the purposes of decentralization.

181
00:17:11,040 --> 00:17:21,760
I don't know. Yeah. So for Cic, for example, we've been on for like two years now.

182
00:17:21,760 --> 00:17:32,240
And at first the variator set was like only DevOps guys and then teams that are building on

183
00:17:32,240 --> 00:17:40,160
secret started to join the variator set to raise money that way. But they were building their

184
00:17:40,160 --> 00:17:46,960
own project on top of secret and not building the protocol itself. So I don't think that they

185
00:17:46,960 --> 00:18:02,400
are looking closely at that. Yeah. So I think that covers all of our follow ups. So we have a

186
00:18:02,400 --> 00:18:09,200
topic of the week as people were probably guessed from our choice of guest. It's secret. And obviously,

187
00:18:09,200 --> 00:18:15,440
first of all, we have a big thank you to Saf for being the one who bottomed out the root cause on

188
00:18:15,440 --> 00:18:22,720
the Juno chainholt. You may remember him from such cosmos incidents as the Juno chainholt

189
00:18:24,800 --> 00:18:27,680
where he came through as a bit of a hero of the whole episode.

190
00:18:29,200 --> 00:18:34,880
But so I'll kick off here because I've noticed the first question on our list is the explain

191
00:18:34,880 --> 00:18:39,360
like I'm five and I do that role pretty well because I am genuinely pretty clueless about the

192
00:18:39,360 --> 00:18:48,320
benefits of secret. So imagine I'm a newcomer to the cosmos ecosystem, be that a user or maybe a

193
00:18:48,320 --> 00:18:53,840
developer. What are the primary benefits of secret as compared to say, well, I mean, before today,

194
00:18:53,840 --> 00:18:59,680
maybe terror or I suppose you know, equally Juno has cosmism, but the use case I think for Juno

195
00:18:59,680 --> 00:19:06,640
and secret is very different. So maybe terror is a fair comparison, I don't know. So explain

196
00:19:06,640 --> 00:19:11,840
like I'm five. What is like the big draw for secret for developers and for users?

197
00:19:13,520 --> 00:19:19,280
Yeah, so secret network is a cosmos based chain with permissionless cosmism.

198
00:19:20,720 --> 00:19:27,680
With the only difference of having private inputs, outputs and state for contracts. So

199
00:19:27,680 --> 00:19:35,040
you can build pretty cool stuff like private dollars with private voting private private

200
00:19:35,040 --> 00:19:44,640
governance. And for example, dollars can store private keys in the contract state, and then sign

201
00:19:44,640 --> 00:19:56,400
transactions on other blockchains or validate validate blocks on other chains, for example.

202
00:19:56,400 --> 00:20:07,520
And you can store, for example, private entropy in contracts and then generate random numbers

203
00:20:07,520 --> 00:20:14,960
on the fly. So it's very good for games. For example, you can generate like random mazes and

204
00:20:16,000 --> 00:20:22,320
in a shuffle like a deck of cards, something that you can do anywhere else, because you just see

205
00:20:22,320 --> 00:20:30,560
the entire deck on chain. Right. So you could do like a generative NFTs or something like that

206
00:20:30,560 --> 00:20:35,200
without needing an Oracle or some other source of randomness. Yeah.

207
00:20:40,880 --> 00:20:47,440
Wait a minute. Storing entropy? How does that work? Can you explain that just a little bit more to me?

208
00:20:47,440 --> 00:20:55,120
Yeah. So for example, let's say that you want a shuffle a deck of cards for poker. Okay.

209
00:20:56,640 --> 00:21:06,480
So you have, let's say two players joined to the table and each player, when they join,

210
00:21:06,480 --> 00:21:11,600
they input a secret number. They can do that because inputs to

211
00:21:11,600 --> 00:21:23,200
to contracts are encrypted. The input parameters, the variables. So the contract receives two secret

212
00:21:23,200 --> 00:21:32,480
numbers from two players. And then it can use that with a pseudo random number generator to

213
00:21:32,480 --> 00:21:43,040
generate random number and for example, to shuffle a deck of cards and then give cards to the players,

214
00:21:43,040 --> 00:21:54,720
for example. Yeah. So yeah, I'm a little confused about where the entropy comes from originally,

215
00:21:54,720 --> 00:22:02,640
like to be stored in the first place. So you say it's secret, but it has to be generated initially,

216
00:22:02,640 --> 00:22:13,040
right? Yeah. So everything that happens on chain must reach consensus. So you can just generate

217
00:22:13,040 --> 00:22:19,040
a random number from like nowhere, I don't know, from the nodes themselves. You have to

218
00:22:19,040 --> 00:22:30,080
to input the entropy from users inside transactions. So it's cool. If for example, two players join in,

219
00:22:30,080 --> 00:22:40,240
each of them input a private like secret number or something like that. Assuming at least one of

220
00:22:40,240 --> 00:22:48,960
them is honest, then you can take both numbers and hash them together. And then none of them

221
00:22:48,960 --> 00:22:57,520
know the output of the hash. Yeah. So the benefit of secret being that neither party can see what's

222
00:22:57,520 --> 00:23:06,160
in there. It's like the black box, which is another cool application of secret, which is kind of on

223
00:23:06,160 --> 00:23:14,880
topic. Is the black box stock cash? Is that what it's called? Yeah, that sounds right. Yeah. That

224
00:23:14,880 --> 00:23:21,280
was a pretty cool project that I used the other day. It was not clear to me initially how the

225
00:23:21,280 --> 00:23:33,200
hell it was operated. But after about half an hour, I asked someone and then it was pretty good.

226
00:23:33,200 --> 00:23:40,480
Yeah. It's nice to, if you need to seed new wallets anonymously or anything, it's like a

227
00:23:40,480 --> 00:23:46,000
good little application for that and entirely wouldn't be possible if secret didn't exist.

228
00:23:46,000 --> 00:23:52,000
I don't, there's no other way that you can anonymize a wallet anywhere else in the Cosmos that I know

229
00:23:52,000 --> 00:23:58,640
of like that. Well, I guess you could do it with Snarks, right? But it's the approach is different

230
00:23:58,640 --> 00:24:03,760
on secrets, right? It's not using ZK Snarks or Circle or something like that. It's using

231
00:24:03,760 --> 00:24:11,520
different. No, but are there Snarks in the Cosmos at the moment? Well, I mean, there is

232
00:24:11,520 --> 00:24:16,560
supposedly a tornado cash clone coming to June at some point, but there's no reason why you can't

233
00:24:17,520 --> 00:24:23,520
compile Circom circuits. And then it's just requires quite a bit of fiddling to actually

234
00:24:23,520 --> 00:24:31,360
wrangle them into a smart contract layer, basically. I won't pretend that I'm fully

235
00:24:31,360 --> 00:24:34,800
up to speed on the details of how that actually works. I just know that you can do it. You can

236
00:24:34,800 --> 00:24:38,160
compile the circuits, there are Rust libraries for doing it. And obviously, then you can

237
00:24:38,800 --> 00:24:44,960
actually interpret what is happening to say that input does actually match output.

238
00:24:44,960 --> 00:24:50,080
Thus, the two did happen. Thus, you can release funds or take some further action or whatever.

239
00:24:51,920 --> 00:24:59,360
But I suppose my question would be like the approach that secret uses for like,

240
00:24:59,360 --> 00:25:04,480
you know, the built-in security of the smart contract layer and where it fits users,

241
00:25:04,480 --> 00:25:08,160
presumably doesn't require lots of extra developer effort. Is that like the,

242
00:25:08,880 --> 00:25:13,840
because obviously ZK Snarks is a lot of overhead if you want to actually work with them, right?

243
00:25:16,480 --> 00:25:22,160
Yeah, so for Secret, it's just like as a developer, as a contract developer, it's just like

244
00:25:22,160 --> 00:25:32,000
a version of Cosmos and just a few tweaks. Also, it's a bit of an outdated version of

245
00:25:32,000 --> 00:25:36,640
Cosmos and because we're running it since like September of 2020.

246
00:25:41,360 --> 00:25:47,120
But as a developer, you don't need to do anything special. You just need to take into

247
00:25:47,120 --> 00:25:55,920
consideration the privacy model of your contract. So what you want to keep private and what you

248
00:25:55,920 --> 00:26:04,080
want to expose via queries and whether you want to implement like an access control mechanism

249
00:26:04,080 --> 00:26:13,120
in your contract and stuff like that. For example, CW20 contract on Secret,

250
00:26:13,120 --> 00:26:20,480
we call it Snip20 contract, is a privacy token because balances are private and when you transfer

251
00:26:20,480 --> 00:26:35,200
a token, the recipient is private too. By default, unless you expose the details we acquire it.

252
00:26:35,200 --> 00:26:44,560
Right. And how is practically speaking, how is that encryption at work arrest kind of done?

253
00:26:44,560 --> 00:26:49,040
Like again, explain like I'm like I'm five, I'm not a crypto expert.

254
00:26:50,880 --> 00:27:00,800
Yeah, so we're using something called SGX, which is a hardware chip inside like every

255
00:27:00,800 --> 00:27:14,000
Intel CPU today. And what it does, it allows you to run the computations on encrypted data

256
00:27:14,960 --> 00:27:24,240
and we require every validator every node on the network to have an updated SGX hardware.

257
00:27:24,240 --> 00:27:31,920
And it means that they are running computations like Cosmos and computations without seeing the

258
00:27:31,920 --> 00:27:40,000
actual data that they are running. But the output is also encrypted, but they reach consensus only

259
00:27:40,000 --> 00:27:45,360
because it's exactly the same for each of them because the computation is deterministic.

260
00:27:47,680 --> 00:27:53,520
So there's two layers to it. There's encryption at effectively the programming layer,

261
00:27:53,520 --> 00:27:58,960
where you're essentially building in developer tooling that says use this API, your inputs will

262
00:27:58,960 --> 00:28:05,040
be encrypted, they'll be decrypted at the output, don't worry about it, just use the API. And then

263
00:28:05,040 --> 00:28:11,120
there's also the hardware, which is ensuring that node operators effectively can't be

264
00:28:12,240 --> 00:28:14,960
inspecting that data as it's in flight or as it's at rest, right?

265
00:28:14,960 --> 00:28:25,680
Yeah. Yeah, so outside of consensus, the users encrypt and decrypt the inputs and outputs.

266
00:28:26,720 --> 00:28:32,720
But obviously we do that for them with the CLI and with the JavaScript and Python libraries.

267
00:28:34,480 --> 00:28:39,120
Right, okay, cool. So yeah, it's a combination of the hardware and like thinking about the

268
00:28:39,120 --> 00:28:41,840
developer, like the holistic developer experience and stuff, that's cool.

269
00:28:41,840 --> 00:28:49,120
Okay, I've seen some of the, again, like from talking to other Cosmos teams or interact with

270
00:28:49,120 --> 00:28:55,440
other people who are using Cosmos, I've seen some of the secret tooling around like

271
00:28:55,440 --> 00:29:02,560
essentially developer tooling and like bootstrapping and whatnot. And it's all pretty slick and

272
00:29:02,560 --> 00:29:08,480
joined up. So I kind of had guessed that you guys had spent a reasonable amount of time sort of

273
00:29:08,480 --> 00:29:12,960
focusing on that side of things and the ergonomics of it. So that kind of does make sense.

274
00:29:14,720 --> 00:29:19,600
So what's it like working on the core team and stuff? Like what's your involvement,

275
00:29:19,600 --> 00:29:23,440
what's your speciality like there? What's the thing that you kind of work on the most?

276
00:29:24,880 --> 00:29:32,640
So we are like a pretty small team. We were four engineers up until recently. And now we're on

277
00:29:32,640 --> 00:29:44,400
board in formal. So we all did everything. And we built like the since like February of 2020,

278
00:29:44,960 --> 00:29:55,440
we started to work with the Cosmos team to bring Cosmos into a state where it production ready.

279
00:29:55,440 --> 00:30:07,600
And pretty early on we discovered that we need to rewrite the entire core of Cosmos to work

280
00:30:07,600 --> 00:30:12,800
inside SGX. So we kept the APIs of Cosmos but

281
00:30:14,960 --> 00:30:21,520
rewrote everything inside. And all along the way, we shared feedback and code with the

282
00:30:21,520 --> 00:30:33,680
Confio team, Dayton and Simon. And then back in I think September of 2020, we upgraded mainnet with

283
00:30:34,800 --> 00:30:41,360
the version of Secret Contracts we called it, the Cosmos inside the SGX.

284
00:30:41,360 --> 00:30:51,840
And I think all of 2021 we worked on like building blocks for contracts. So

285
00:30:54,480 --> 00:31:05,920
the CW20 equivalent, which is the 20 token and then SNP721, which are private entities,

286
00:31:05,920 --> 00:31:20,640
which have public and private metadata. We also built an AMM and bridges to

287
00:31:20,640 --> 00:31:36,480
Ethereum and Binance matching. So yeah, because we were just four people, we worked on everything together.

288
00:31:39,600 --> 00:31:45,360
Nice. And what's your background as an engineer? Like before Secret, what did you do?

289
00:31:45,360 --> 00:31:51,840
You like mainly a kind of low level protocol guy or you're going to tell me you sort of

290
00:31:51,840 --> 00:31:56,800
worked on mobile apps before this or something or did advertising bots or something.

291
00:31:59,520 --> 00:32:07,440
I was in the Israeli military for six years. I was doing cybersecurity work, mostly defending

292
00:32:07,440 --> 00:32:17,520
against the nation state actors and mostly building the infrastructure of the team that

293
00:32:19,520 --> 00:32:25,920
is supposed to research malware. So my toddler is waking up.

294
00:32:25,920 --> 00:32:38,400
So just a second. Do you need to go for a second?

295
00:32:40,000 --> 00:32:44,320
Yeah, maybe. We can wait, mate. We'll talk amongst ourselves.

296
00:32:45,360 --> 00:32:45,840
Thank you.

297
00:32:45,840 --> 00:32:58,000
I remember those days. Well, I guess we should wait before continuing the Secret conversation,

298
00:32:58,000 --> 00:33:08,000
but how about that UST back to 70 cents? We have on the sheet UST, I'm not saying all caps,

299
00:33:08,000 --> 00:33:11,840
but then obviously it's an acronym. So it would be an all caps anyway, but it does have a lot of

300
00:33:11,840 --> 00:33:17,520
exclamation marks after it. Yeah, and it's just scattered around the sheet everywhere. It's like

301
00:33:18,800 --> 00:33:29,120
links to Duma, YouTube videos and just UST and Scribble across this spreadsheet. How did it come

302
00:33:29,120 --> 00:33:38,640
like this? Yeah, well, Luna looks like it's at $1.03 at the moment.

303
00:33:38,640 --> 00:33:48,000
Yeah, it seems to be. I imagine that is how the UST is making a very slow recovery. I guess

304
00:33:48,000 --> 00:33:53,840
they whoever was trying to push the UST and to the dirt ran out of powder.

305
00:33:55,440 --> 00:34:02,160
Yeah, something like that. Or maybe the goal was to just buy some cheap Luna.

306
00:34:02,160 --> 00:34:09,280
I mean, do you buy the conspiracy theory that it's somebody trying to make

307
00:34:11,200 --> 00:34:20,720
money on shorting it or whatever? Do I buy that? No. I think the legs just,

308
00:34:21,920 --> 00:34:28,960
it's had an incredible pump in the last preceding months. I think maybe it just ran out of steam

309
00:34:28,960 --> 00:34:37,520
and then it had a hiccup. Do you remember the iron finance fiasco last year? Oh, yeah, absolutely.

310
00:34:38,080 --> 00:34:41,360
It's outside of the cosmos, so you guys might not be familiar with it.

311
00:34:41,360 --> 00:34:46,560
Yeah, no idea. That's not the cosmos. I've got no clue. Obviously, I don't own or hold any crypto

312
00:34:46,560 --> 00:34:52,800
outside of the cosmos. The idea that I would is completely ridiculous. So basically, I mean,

313
00:34:52,800 --> 00:34:59,840
it's going back a bit now, but I think it did get a mild attack on it and it busted its peg

314
00:34:59,840 --> 00:35:08,960
and lost confidence immediately. But it was an Algo stablecoin and it was pumped by one of those

315
00:35:08,960 --> 00:35:14,160
football guys, right? Or maybe one of those, Schiltz, was it a football guy or was it like

316
00:35:14,160 --> 00:35:19,120
one of those sharp guys or something like that? I don't remember. I just remember it was some

317
00:35:19,120 --> 00:35:26,080
external personality. Yeah, so some dude was pumping it and then it had a hiccup and went to

318
00:35:26,080 --> 00:35:36,080
zero incredibly fast. So it was a mint. I think there was too much lag in the mint algorithm,

319
00:35:36,080 --> 00:35:43,440
which was meant to increase the price of one. I can't remember exactly how it worked, but I think

320
00:35:43,440 --> 00:35:53,760
it's similar to how USD works, but it had a bad oracle and there was too much lag in it.

321
00:35:53,760 --> 00:35:58,080
And if you attacked it quick enough with a flash loan, you could send it to zero, apparently.

322
00:35:58,080 --> 00:36:00,000
It just lost confidence and everyone bailed on it.

323
00:36:00,800 --> 00:36:07,840
Yeah. Well, isn't it more that there is a piece of price action that changes, that initiates the

324
00:36:07,840 --> 00:36:14,400
attack, but isn't the fundamental issue that as soon as an algorithmic stable dpegs enough,

325
00:36:15,040 --> 00:36:19,680
that people just fundamentally lose confidence and that's just like a bank run effectively?

326
00:36:19,680 --> 00:36:25,440
I don't know if that's fair though, because if you look at the charts, almost every stablecoin

327
00:36:25,440 --> 00:36:29,760
has dpegged at some point. Like, Tether went down to like 60 cents at some point, right?

328
00:36:29,760 --> 00:36:38,160
Right. Because there's no algorithm keeping them pegged on Binance and Kraken and Dex's,

329
00:36:38,720 --> 00:36:44,000
they have their mechanism where people can ARB to. But if there's no ARBs or if there's not enough

330
00:36:45,840 --> 00:36:52,000
liquidity in the pools where they're being smashed, they'll go down anyway. So it all

331
00:36:52,000 --> 00:36:59,120
sort of relies on being able to make ARBs back to the original algorithm that actually stabilizes it.

332
00:36:59,120 --> 00:37:07,520
And for all of those places where it's traded to have enough liquidity to be able to sustain a

333
00:37:09,760 --> 00:37:18,000
prolonged attack on it. So I think that even though there was UST as high as it was,

334
00:37:19,440 --> 00:37:25,200
still not deep enough liquidity to defend against something like that. And I think the same thing

335
00:37:25,200 --> 00:37:36,160
could happen with Tether and the USD and the rest of them. It's just that people are of the belief

336
00:37:36,160 --> 00:37:42,720
that they're backed one to one. So they will ARB between pools, not necessarily back to the

337
00:37:45,120 --> 00:37:50,720
algorithmic pool, which actually keeps the peg. So I think there's something to be said for the

338
00:37:50,720 --> 00:37:58,480
belief in a system as well that will keep people. So because people believe that, and it might be,

339
00:37:59,280 --> 00:38:07,040
Tether is backed one to one with a US dollar, then if between Kraken and Binance, there's

340
00:38:07,040 --> 00:38:13,920
a difference, they'll arbitrage it to bring the peg back. But if there's a system which doesn't have

341
00:38:13,920 --> 00:38:24,080
100% confidence like UST seems to have shown, once you break the peg, if there's not enough

342
00:38:25,280 --> 00:38:30,720
arbitrage back to get it back to $1 quickly, people can lose confidence and then just start

343
00:38:30,720 --> 00:38:38,080
bailing out of it. And then you get an avalanche of volume. So you need really deep liquidity to

344
00:38:38,080 --> 00:38:47,120
absorb it and a lot of arbiters. And when you then can't access back to the original pegging

345
00:38:47,120 --> 00:38:53,520
pool, as was the case, because the bridges were clogged, then that causes another problem.

346
00:38:55,840 --> 00:39:01,120
If I can reduce a very complicated situation down to like a literal five-second meme,

347
00:39:02,240 --> 00:39:07,600
do we think the peg is going to be regained? I think so. I think the longer you leave it,

348
00:39:07,600 --> 00:39:12,400
it'll just regain from the algo. Yeah, I think you'll still regain.

349
00:39:14,640 --> 00:39:20,560
I think it will as well. I do question. One of the big points of faith behind it was the

350
00:39:20,560 --> 00:39:27,600
fact that Luna was above UST and market cap rate. I'm starting to wonder if maybe it was a wrong

351
00:39:27,600 --> 00:39:33,120
decision for it to be tied one to one. So if you look at Silk and Shade, which are on secret

352
00:39:33,120 --> 00:39:40,000
networks, so it's a little appropriate, they're looking at actually having a different system for

353
00:39:40,000 --> 00:39:46,480
it's still going to be an algorithmic stablecoin. But the peg isn't going to be just to their

354
00:39:46,480 --> 00:39:51,680
Shade derivative, which would be like Luna. It would be, let's say you can swap secret for

355
00:39:51,680 --> 00:39:56,720
the UST as well. And so if you try in multi-different cryptocurrencies, one dropping doesn't

356
00:39:56,720 --> 00:40:02,880
necessarily undo the system. And so I'm wondering to what extent that's true. The fact that there

357
00:40:02,880 --> 00:40:05,920
were covering the peg right now and there's such a discrepancy between the two.

358
00:40:05,920 --> 00:40:10,480
But if they're all positively correlated with one other, then one dropping does bring them all down.

359
00:40:10,480 --> 00:40:16,080
So you're back in the same, you know? It's true. But a reduction in the pool of money.

360
00:40:16,080 --> 00:40:21,040
Well, central banks do this with credit issuance and they do it with, well, historically, they did

361
00:40:21,040 --> 00:40:27,680
it with gold or dollars or whatever. They actually held the money somewhere because they knew that

362
00:40:27,680 --> 00:40:32,720
there was a fundamental difference between the two types of things. Like one of them is

363
00:40:32,720 --> 00:40:40,480
one of them is essentially, well, it's real. It's real. It can be used as an actual store of value.

364
00:40:42,000 --> 00:40:48,960
So like there's, or I guess to bail out 2008 or to bail out during wartime, long-term government

365
00:40:48,960 --> 00:40:53,600
bonds, long-term government loans are also used. So there's like a variety of different

366
00:40:54,240 --> 00:40:58,960
tools in the toolbox, which are all about, well, increasing liquidity, right?

367
00:40:58,960 --> 00:41:06,480
But not all of those things are positively correlated with one another, right? So it means you have

368
00:41:06,480 --> 00:41:13,920
different tools available to you. So I guess that's the question. I'm kind of wondering whether a

369
00:41:13,920 --> 00:41:20,160
algorithmic stable doesn't yet have all of the tools it would need to actually

370
00:41:23,440 --> 00:41:26,560
grab something out of Finnair that's not positively correlated, right? Because that's also the

371
00:41:26,560 --> 00:41:31,280
problem with Luna here. As soon as you lose confidence in UST, you lose some confidence in

372
00:41:31,280 --> 00:41:39,520
Luna and Luna is trying to dig UST out of the hole, right? Yeah, I think Luna's taken the brunt of it,

373
00:41:41,760 --> 00:41:47,520
for sure. So I mean, Asaf, do you think UST is going to regain its peg?

374
00:41:47,520 --> 00:42:00,720
Yes. Okay, so we're five for five on the call. So there you go. I mean, this is not

375
00:42:00,720 --> 00:42:05,840
investment advice, but five out of five members of the Game of Nones podcast tonight,

376
00:42:05,840 --> 00:42:11,280
I think UST is going to regain its peg given time. Well, now let's throw a little bit of a

377
00:42:11,280 --> 00:42:16,720
hardball in there, right? So Osmosis just put out their update, right? And they're considering

378
00:42:16,720 --> 00:42:23,200
hard forking so that people can pull out their UST and their Luna pools. So there's going to be

379
00:42:23,200 --> 00:42:28,000
a governance program for that now. If suddenly another three or 400 million enters the market,

380
00:42:28,960 --> 00:42:33,920
what happens then? I mean, that's going to be even more difficult. Explain that again,

381
00:42:33,920 --> 00:42:39,520
Chelsea. What are they putting a proposal for? Yes, they put up a proposal to fork Osmosis such

382
00:42:39,520 --> 00:42:46,640
that they all the pools and all the bondings within their UST Osmo, Luna Osmo, and one other

383
00:42:46,640 --> 00:42:51,840
pool become unbonded so people can immediately pull them out and sell them if they want to.

384
00:42:52,800 --> 00:42:57,360
Right now, you're tied into your one day, seven day, four day bonding, and they want to undo that.

385
00:42:58,640 --> 00:43:01,280
So what you're saying is Luna price is going to go down even more?

386
00:43:02,640 --> 00:43:08,720
I'm saying it's a possibility. So it's actually pretty interesting. I think I'm against them

387
00:43:08,720 --> 00:43:15,440
doing that. Like we took the risk in bonding. But basically the idea is if so we're trying to get

388
00:43:15,440 --> 00:43:21,200
all the values in on it and voting if it hits 66%, they're just going to cut it early and hard fork

389
00:43:21,200 --> 00:43:28,240
Osmosis with all the tokens unbonded. Is that something that's come from the team or is that

390
00:43:28,240 --> 00:43:34,240
something that's come from users? Oh, no, that's come from the team. I'll post the, well, I guess

391
00:43:34,240 --> 00:43:37,920
it can't, you're also into the discord and then you guys can post it in YouTube chat so you can

392
00:43:37,920 --> 00:43:44,080
read up about it. Yeah, I mean, I think essentially the damage is done there. All that can really

393
00:43:44,080 --> 00:43:53,200
happen now is that UST can slowly regain its peg. Luna's done in terms of price for the time being.

394
00:43:54,080 --> 00:43:56,560
So, you know, I don't see the point now.

395
00:44:01,200 --> 00:44:06,000
I mean, unless Luna's going to zero, what do you think it's up?

396
00:44:06,000 --> 00:44:13,760
I think like they can probably land in the top 50 on point market cap after regaining the peg.

397
00:44:13,760 --> 00:44:17,280
So not a bad spot to land on, I think.

398
00:44:19,760 --> 00:44:26,960
Do you think Luna will have a substantial recovery or do you think we're going to see it

399
00:44:26,960 --> 00:44:30,080
pretty low for a long time? I think the confidence is pretty busted in

400
00:44:30,640 --> 00:44:38,240
terror at the moment. I don't know. It's like purely speculation at this point, but after looking at

401
00:44:38,240 --> 00:44:46,160
their market code and seeing that they're willing to sacrifice Luna for regaining the peg. So I

402
00:44:46,160 --> 00:44:52,320
think that Luna eventually will bounce back. I don't know if in a week or in a year, but I think

403
00:44:52,320 --> 00:45:00,080
that it has a good chance. So I don't think, you know, the turmoil over the last couple of days

404
00:45:00,080 --> 00:45:04,960
doesn't change the fact that terror have a good product and good marketing. So.

405
00:45:04,960 --> 00:45:10,400
And good developers. I think within the cosmos, they have the most developers.

406
00:45:10,960 --> 00:45:14,000
And I mean, that can't be understated how important that is.

407
00:45:17,280 --> 00:45:18,480
Sorry, I'm just reading comments.

408
00:45:18,480 --> 00:45:23,120
Yeah, just because I think Asaf was saying earlier, right, you guys are four and you've

409
00:45:23,120 --> 00:45:29,200
just added four more developers, right? So to give an idea, like for the listeners,

410
00:45:29,200 --> 00:45:37,840
eight developers would be quite typical for a very small startup, maybe a couple of hundred

411
00:45:37,840 --> 00:45:43,200
thousand dollars annual recurring revenues, something like that that's just received a series A,

412
00:45:43,200 --> 00:45:46,880
or like a very, very first seed round or something like that, a few million dollars,

413
00:45:46,880 --> 00:45:51,280
a couple of million dollars from a few investors to see if the product has legs.

414
00:45:51,840 --> 00:45:54,720
Typically, then you would go from like two to four developers to

415
00:45:54,720 --> 00:46:03,360
six to eight developers, something like that. So eight developers is a small but decent, smart

416
00:46:03,360 --> 00:46:11,200
startup team, right? And secret is quite a bit bigger and more substantial a product than like

417
00:46:11,200 --> 00:46:17,200
an early stage startup. So, you know, obviously, I mean, the staff correct me if I'm wrong, I don't

418
00:46:17,200 --> 00:46:21,840
know if that's because it's hard to hire or if that's because of, you know, it's difficult to

419
00:46:21,840 --> 00:46:26,880
bring new people on and not be unproductive. I don't know what's been the reason that you've

420
00:46:29,360 --> 00:46:39,600
scaled in that way. So it's hard to hire. And I'm not sure if you're familiar with the secret

421
00:46:39,600 --> 00:46:52,720
history. Like it started as an IGMA and they did an ICO back in 2017. They raised like 45 million.

422
00:46:52,720 --> 00:47:00,800
Then like when I joined back in 2019, they were building a layer to privacy solution for Ethereum

423
00:47:00,800 --> 00:47:12,160
and it was not going that well. So they decided to start fresh on Cosmos. And they also had like a

424
00:47:12,160 --> 00:47:20,560
very, I think they had like 10 or 15 developers. And they decided to scale back because it wasn't

425
00:47:20,560 --> 00:47:29,280
working for them. Right. So, okay, that makes a bit more sense in terms of in terms of developer

426
00:47:29,280 --> 00:47:35,760
size. But this, I guess, bringing us back to why it's important that Terra has so many developers

427
00:47:36,400 --> 00:47:39,520
is that most of the other teams in the Cosmos are operating on probably

428
00:47:40,800 --> 00:47:46,480
a similar number of devs to what secret were before the scale up that as staff says, they're just

429
00:47:46,480 --> 00:47:52,400
doing at the moment, right? Which is three or four engineers who are practically doing the

430
00:47:52,400 --> 00:47:59,440
day to day. I think Stargaze is about four. Most of the other teams I can think of are between four

431
00:47:59,440 --> 00:48:06,480
and maybe 10 if they have a lot of people. And given the market cap of a lot of the chains in

432
00:48:06,480 --> 00:48:13,040
Cosmos, I know obviously Cosmos is a lot smaller than some other ecosystems, but those are very

433
00:48:13,040 --> 00:48:18,320
small numbers for team sizes given the scale of these companies. If they were traditional companies,

434
00:48:18,320 --> 00:48:30,480
they would have 100 engineers, you know. Speaking of Terra, are you guys familiar with

435
00:48:30,480 --> 00:48:45,120
the mentor mint? I'm not familiar with it. With what, sir? A mentor mint. No. So, mentor mint is a

436
00:48:45,120 --> 00:48:57,200
special node that Terra developed. It's essentially a node without a tender mint. It sinks state

437
00:48:58,640 --> 00:49:06,240
and they replace the entire tender mint stack with a much faster DB database engine. And

438
00:49:06,240 --> 00:49:16,000
I was talking with one of the engineers a few hours before she hit the fence. And he was saying

439
00:49:16,000 --> 00:49:24,560
that they're serving constantly like 1.4 million requests per year for Terra. Yeah. So,

440
00:49:27,600 --> 00:49:32,880
do you think that other projects should try and pick that up or try and include something like

441
00:49:32,880 --> 00:49:40,480
that into the SDK? Yes. I was talking with him about trying to port this to Secret.

442
00:49:43,120 --> 00:49:47,440
And he said that it will help like a week after they...

443
00:49:47,440 --> 00:50:04,560
Can you tell me the reason that, for example, when you jump onto Mint Scan and go to the Secret page,

444
00:50:04,560 --> 00:50:09,360
there's a delay in loading it? Is that something to do with Secret itself or is that a Mint Scan thing?

445
00:50:09,360 --> 00:50:23,200
Yeah. Okay. I know it's only seems to be on Secret just talking about RP season stuff. So,

446
00:50:24,000 --> 00:50:30,240
this is like a kind of light node that you're talking about with all the tender mint stripped

447
00:50:30,240 --> 00:50:34,960
out, all the consensus stuff stripped out. It's basically just... Does it still check hashes against

448
00:50:34,960 --> 00:50:46,400
the validator set? Yeah. It's still like receiving state and validating the headers, but it doesn't

449
00:50:46,400 --> 00:50:53,360
run transactions in blocks. It just sinks the state and then you can query it really fast.

450
00:50:53,360 --> 00:51:07,360
And I think that he said that they have a cluster of 35 nodes and they serve like 20k queries per second.

451
00:51:08,400 --> 00:51:16,400
Wow. That is decent. Is that... What kind of load balancer did they get into that type of discussion

452
00:51:16,400 --> 00:51:26,720
with you as well? No? Because I know that I think Stargaze is now using... And Serpent might be

453
00:51:26,720 --> 00:51:32,400
able to help out with this. I think they're using the Cloudflare smart load balancer now. Is that

454
00:51:32,400 --> 00:51:42,240
right? Yeah. We use regional setups that are both pruned as well as full nodes across a couple

455
00:51:42,240 --> 00:51:47,040
different regions and then Cloudflare bounces based off of geography and other types of things.

456
00:51:47,040 --> 00:51:57,040
Yeah. So if you have pruned nodes along with full nodes behind a load balancer, how does it

457
00:51:57,040 --> 00:52:01,840
figure out where to send the requests? Is that programmable or... It doesn't. It doesn't.

458
00:52:01,840 --> 00:52:04,320
So it just throws them around until it gets the one that...

459
00:52:05,600 --> 00:52:10,480
Sort of. But I think the goal is not so much around being able to provide archive nodes to

460
00:52:10,480 --> 00:52:16,080
the community. It's really more that... I think with so many validators running prune nodes now

461
00:52:16,080 --> 00:52:21,280
that the chain is obviously wants to make sure that there's plenty of archives. So

462
00:52:22,480 --> 00:52:28,960
there's such a race on the validator side to bring it down and to make sure that we have

463
00:52:28,960 --> 00:52:33,520
a short block times and things like that. There's some concerns that how many archive nodes are out

464
00:52:33,520 --> 00:52:40,160
there. So for Stargaze, I think they have a couple... I think there's like four or five

465
00:52:40,160 --> 00:52:43,520
that the team runs that are out there. Then we take backups and all that kind of stuff too.

466
00:52:44,560 --> 00:52:52,000
Yeah. I think that's sort of getting lost in the soup, the fact that one of the jobs of a

467
00:52:52,000 --> 00:53:02,000
validator is to maintain the history. Yeah. So I know almost everyone's running a prune setup

468
00:53:02,000 --> 00:53:07,360
because otherwise, it's a way to help making sure that you sign all the blocks and that type of

469
00:53:07,360 --> 00:53:15,200
stuff. But definitely in your infrastructure stack, you should be keeping history as well

470
00:53:15,200 --> 00:53:25,200
if at all possible. So I know that we're working on having hosted hardware elsewhere

471
00:53:26,240 --> 00:53:32,080
to make it cheaper for us to be able to keep a lot of state on slower drives and stuff. It

472
00:53:32,080 --> 00:53:41,040
wouldn't be able to keep up with validating, but it'll be good enough to put lower cost drives,

473
00:53:41,040 --> 00:53:46,960
just fill it up with the data forever, sitting in a colo somewhere where it doesn't matter

474
00:53:46,960 --> 00:53:53,680
if it goes offline. Just like cheaper setup on your own hardware just so that people can

475
00:53:53,680 --> 00:53:58,640
sync from it if they need to someday. Yeah. I think it's becoming more important. I think

476
00:53:58,640 --> 00:54:03,280
I think also change is trying to figure out a way to incentivize that as well because there's

477
00:54:04,400 --> 00:54:13,360
so many valuable roles for validators to play from RPC and API nodes as well as archive and

478
00:54:13,360 --> 00:54:17,120
other types of things. And there's not really a clear incentive structure around that, at least

479
00:54:18,720 --> 00:54:23,120
not on chain at least, right? Everything else becomes off chain, which becomes more difficult

480
00:54:23,120 --> 00:54:28,880
to track and everything else. But yeah, it's important, I think. It is important and it's a huge

481
00:54:28,880 --> 00:54:35,840
problem that in proof of stake, it's not incentivized by the chain and somehow natively.

482
00:54:41,920 --> 00:54:47,120
It's a shame that there's not an easy way to make sure that the people who are contributing to the

483
00:54:47,120 --> 00:54:53,440
health of the network get the delegations instead of people who have the best marketing or something

484
00:54:53,440 --> 00:55:01,840
like that. That is a totally different topic. Yeah, yeah. But it ties in that we can all go

485
00:55:01,840 --> 00:55:08,000
to the effort to ensure the health of the chain as is our responsibility. It doesn't necessarily

486
00:55:08,000 --> 00:55:14,640
mean that you get rewarded for it. So it's good to see that Stargaze are working in that direction.

487
00:55:14,640 --> 00:55:18,240
Yeah, for sure. This is also something we talked about in a previous episode. I remember it was

488
00:55:18,240 --> 00:55:25,600
the one with actually with Shane or whether it's a different one, but it's all about incentives.

489
00:55:25,600 --> 00:55:30,480
And I think the way incentives have been designed in Cosmos for a variety of things

490
00:55:32,400 --> 00:55:40,720
were effectively a good first attempt and need to be upgraded. Governance is a prime example

491
00:55:40,720 --> 00:55:46,720
of it. It's the first stab at governance and it doesn't work. Sorry, it's done fine up to now

492
00:55:46,720 --> 00:55:51,200
and it's now at the point where it's creaking and it's breaking because 10x users, everything breaks.

493
00:55:52,480 --> 00:55:56,240
And another thing is the economic incentives around the validator set in

494
00:55:56,240 --> 00:56:01,040
distributive proof stake do not scale for the long-term health of the network, I think.

495
00:56:01,600 --> 00:56:05,840
And I think there's something that we seem to come back to quite often on this.

496
00:56:05,840 --> 00:56:09,920
We seem to come back to that topic in one shape or another quite often. And I think that's also

497
00:56:09,920 --> 00:56:13,840
something that we found very interesting. I saw there was a comment about Akash down

498
00:56:13,840 --> 00:56:19,440
a minute ago. And I think it's also something that came out with, although I was in a bit of

499
00:56:19,440 --> 00:56:26,160
delirium of sleep deprivation thanks to the hospital and whatnot last week, but that came

500
00:56:26,160 --> 00:56:30,320
out with our conversation with Greg is like, there are a bunch of ways that you can start to

501
00:56:30,320 --> 00:56:32,720
devise more interesting incentive mechanisms. And I think that's something that we found very

502
00:56:32,720 --> 00:56:37,600
interesting. We need to devise more interesting incentive mechanisms using the code inherent

503
00:56:37,600 --> 00:56:41,760
in a blockchain and then go to a different chain that has an infrastructure provider and

504
00:56:42,400 --> 00:56:45,360
do things based on those incentives. And there's other ways we can cut this.

505
00:56:47,280 --> 00:56:52,560
But to bring it back to our guest who I realise is actually that way,

506
00:56:53,920 --> 00:56:57,840
is we were just talking about query speedups and we were talking about the speedup stuff that

507
00:56:57,840 --> 00:57:04,400
Ter had been doing. I gather there's been a substantial query speed increase on

508
00:57:05,760 --> 00:57:10,880
secret. Is that something you guys have done just for secret or is that something that can be applied

509
00:57:10,880 --> 00:57:19,200
to any Cosmos chain? I'm sorry, why do I talk about it all the time?

510
00:57:20,880 --> 00:57:24,000
This is actually a short question, so perhaps you can take that one.

511
00:57:24,000 --> 00:57:30,320
Yeah, so the question is about the 500X speed increase for query nodes. I guess what's the root

512
00:57:30,320 --> 00:57:36,000
cause of that? Is that secret specific? Is it just from adding threading? Can it be translated to

513
00:57:36,000 --> 00:57:39,520
Juno and to Terra? What kind of cross-pollination can happen with that?

514
00:57:39,520 --> 00:57:54,880
Actually, I think Juno already had this feature. We back-ported some new APIs from Cosmos in version 1.

515
00:57:56,000 --> 00:58:02,880
The crypto APIs for verifying signatures, like cryptographic signatures.

516
00:58:02,880 --> 00:58:11,840
Because on secret, we're doing a lot of cryptographic operations inside secret contracts for access

517
00:58:11,840 --> 00:58:22,720
control purposes. For example, when you query a SNP20 token for your balance, it's private,

518
00:58:22,720 --> 00:58:29,920
so you have to prove to the contract that you are the owner of the account.

519
00:58:29,920 --> 00:58:39,360
The way that you do that is by signing something off-chain and then sending it to the contract

520
00:58:39,360 --> 00:58:47,920
to verify. Inside the contract, it verifies the signature, which is a very expensive thing to do

521
00:58:47,920 --> 00:59:00,480
inside of Cosmos. What we did is we added an API for the contracts to offload that computation to

522
00:59:00,480 --> 00:59:11,280
the chain itself instead of doing it inside the contract. Right now, it should be much, much faster.

523
00:59:11,280 --> 00:59:22,720
This is something that came about. It can't be translated, is what you're saying, because it is

524
00:59:22,720 --> 00:59:29,440
effectively a reuse of something that already exists and was created previously. Is that right?

525
00:59:31,280 --> 00:59:39,680
Yeah, it already exists with newer versions of Cosmos. But I'm not sure if the use case

526
00:59:39,680 --> 00:59:47,680
translates to June, for example, because you don't have to implement the access control mechanism

527
00:59:48,320 --> 00:59:58,000
to access your data. But for example, to verify blocks inside of contracts,

528
00:59:59,280 --> 01:00:05,600
that is something that can be translated to June. For example, if you would write a contract that

529
01:00:05,600 --> 01:00:14,640
is essentially a permissionless bridge, for example, just like IBC, that needs to verify

530
01:00:15,360 --> 01:00:24,000
blocks on other blockchains, then that contract would need to do a lot of cryptographic

531
01:00:24,000 --> 01:00:34,240
computations, which in Cosmos version one, we already have that. We didn't have that because

532
01:00:34,240 --> 01:00:40,720
we were in with Cosmos in 0.10, which was released back in September of 2020.

533
01:00:44,320 --> 01:00:46,000
Got it. That makes a lot of sense.

534
01:00:49,200 --> 01:00:54,560
Cool. I think we've got one more question for yourself, which is a big picture stuff.

535
01:00:54,560 --> 01:01:07,040
What's the vision for how secrets are going to grow and change and how the use of it

536
01:01:08,080 --> 01:01:14,880
also might evolve over that time? Where do you see the network going on a five-year horizon,

537
01:01:14,880 --> 01:01:22,160
like if you guys even plan that far ahead? Yeah. Hopefully by then, we will not have to rely on

538
01:01:22,160 --> 01:01:32,880
secrets or any other hardware solution because it's very expensive to run an order right now

539
01:01:32,880 --> 01:01:46,240
compared to other chains. It's a vendor locking, which makes us dependent on Intel right now.

540
01:01:46,240 --> 01:01:59,600
I guess with secrets, there are a lot of use cases that you can't do anywhere else on blockchain.

541
01:02:00,320 --> 01:02:04,880
For example, build games with incomplete information,

542
01:02:04,880 --> 01:02:13,600
or build DAOs with private voting, which I think is very important.

543
01:02:15,840 --> 01:02:23,120
Hopefully, we will see a lot of novel blockchain applications built on secrets,

544
01:02:23,760 --> 01:02:29,360
but half of it to imagine right now what these use cases will be.

545
01:02:29,360 --> 01:02:34,720
What are you most excited for that's coming up on the secret roadmap?

546
01:02:38,240 --> 01:02:42,400
In terms of apps or infrastructure?

547
01:02:46,560 --> 01:02:52,800
I'm excited about bringing the newer version of Cozenwaz into secret,

548
01:02:52,800 --> 01:03:06,000
like having IBC contracts. Then I would want to see apps built on secrets.

549
01:03:06,000 --> 01:03:11,440
I think games have a lot of potential on secrets because of the privacy aspect.

550
01:03:11,440 --> 01:03:22,400
I have a private voting which I already mentioned a couple of times.

551
01:03:24,880 --> 01:03:30,880
Hopefully, we will see a bunch of them this year, maybe in the next six months.

552
01:03:32,080 --> 01:03:34,000
Private voting, something you're working on, is it?

553
01:03:34,000 --> 01:03:42,720
It's something that already exists, like the CIFI DAO, they have a private voting, I think,

554
01:03:42,720 --> 01:03:45,440
for over modern...

555
01:03:47,440 --> 01:03:54,240
So, you plan to implement that on secret, so the validators or anyone can vote

556
01:03:55,440 --> 01:03:59,520
on governance proposals with anonymity?

557
01:03:59,520 --> 01:04:04,720
I think that we are also discussing, but maybe further ahead.

558
01:04:08,000 --> 01:04:14,240
Because I think that's... I'm probably going to crucify myself here.

559
01:04:14,240 --> 01:04:19,440
I think that's important because a validator doesn't necessarily...

560
01:04:19,440 --> 01:04:23,920
What's best for the network? Is it necessarily always the popular vote?

561
01:04:24,960 --> 01:04:26,400
I completely agree here.

562
01:04:26,400 --> 01:04:30,880
Yeah. When you couple that with public forums like Twitter,

563
01:04:32,560 --> 01:04:35,200
people's businesses just get ravaged when they...

564
01:04:36,080 --> 01:04:39,200
A lot of times, you can't make the right decision. You're damned if you're doing,

565
01:04:39,200 --> 01:04:46,960
you're damned if you don't. I think a lot of countries have anonymous voting,

566
01:04:46,960 --> 01:04:53,520
like Australia does, so you can't be discriminated against for your vote preference.

567
01:04:53,520 --> 01:04:54,480
Right.

568
01:04:55,440 --> 01:05:04,560
And I think in terms of proof of stake, a validator's preferences, like I already said,

569
01:05:04,560 --> 01:05:10,400
aren't always aligned with the community because community tends to be more emotionally driven

570
01:05:12,320 --> 01:05:20,960
in a lot of instances, whereas a validator has, in a lot of cases, a set of values that they apply

571
01:05:20,960 --> 01:05:26,400
to blockchain or whether they're blockchain purists or just want to do what's best for the

572
01:05:26,400 --> 01:05:32,720
blockchain doesn't always align. And I think to be able to have the ability to

573
01:05:35,040 --> 01:05:38,480
vote anonymously is important, actually.

574
01:05:39,040 --> 01:05:44,960
I also think even during the vote, away from even that, even to see somewhat results posted

575
01:05:44,960 --> 01:05:49,120
as the vote is going, I think completely sues people in terms of how they're going to vote.

576
01:05:49,120 --> 01:05:54,720
So getting a proposal that's open, and if you have a huge amount of people that vote one way,

577
01:05:54,720 --> 01:05:59,520
to turn that tide, I think is really difficult unless you have obviously validators who are

578
01:05:59,520 --> 01:06:03,600
looking at maybe a little bit deeper than maybe the community. But I think from a community

579
01:06:03,600 --> 01:06:10,160
perspective, if they see 97% of voting positive, even if it's only 2% of quorum, guess what? A

580
01:06:10,160 --> 01:06:15,200
lot of people look at, that's what I should be doing, right? So that's also what I think is a

581
01:06:15,200 --> 01:06:20,720
real benefit here. Even if post-vote, those results are public, I think that still gives

582
01:06:20,720 --> 01:06:28,720
it some options in there. Yep, absolutely. So I mean, most democracies for a very,

583
01:06:28,720 --> 01:06:35,040
very long time have had private ballots. And that's been traditionally, I think,

584
01:06:35,040 --> 01:06:42,400
to avoid the coercion of the upper class or your employer saying, tapping you on the shoulder and

585
01:06:42,400 --> 01:06:48,560
saying, this is how you should vote. And that's before you even get into the inherent problems

586
01:06:48,560 --> 01:06:53,520
of the tyranny of the majority and whatnot, which I think you just identified, you said,

587
01:06:53,520 --> 01:06:57,680
but which is that if you see that a certain number of people have voted a certain way,

588
01:06:57,680 --> 01:07:04,160
it makes it more difficult to form some kind of an objective view. I mean, none of us vote

589
01:07:04,160 --> 01:07:06,720
objectively, right? That's a complete fallacy anyway.

590
01:07:06,720 --> 01:07:13,120
But people, it's weird that even in situations like that, you don't want to be in the losing side,

591
01:07:13,120 --> 01:07:16,400
which like even for votes that don't directly affect you or they get else,

592
01:07:16,400 --> 01:07:22,080
like people don't want to vote the loser. So it's that type of thing, I think, is a huge thing.

593
01:07:22,080 --> 01:07:27,280
Well, so at a case in point, we got asked a couple of times, what we think of Prop 22, right?

594
01:07:27,280 --> 01:07:30,320
And that's an example of one where it is overwhelmingly positive.

595
01:07:31,600 --> 01:07:36,480
But what do we think of that prop and how we vote? Because I mean, from our point of

596
01:07:36,480 --> 01:07:43,600
view, we think it's probably not economically viable with the market downturn we're now seeing

597
01:07:44,240 --> 01:07:51,520
for those final 10 validators to actually break even. But it's like 90 something percent positive.

598
01:07:51,520 --> 01:07:59,600
And it's like, well, do I want to die on a hill of validator expansion? No, I've done

599
01:07:59,600 --> 01:08:05,040
on a hill the last 10 weeks over the CCN drama. I'm done with that, you know?

600
01:08:05,040 --> 01:08:10,480
Well, and those that do have the dissenting opinion during a vote, they are expected to put

601
01:08:10,480 --> 01:08:15,760
out a message on why they have a dissenting opinion. And so it becomes you have to put so much more

602
01:08:15,760 --> 01:08:22,800
energy in to not go with the crowd. Look at Cosmos had Prop 69 with adding Cosmos into the hub.

603
01:08:22,800 --> 01:08:28,080
I had to flood a lot of questions and put out a statement about why I voted yes on it,

604
01:08:28,080 --> 01:08:34,720
because everyone else is voting no. And so that dissenting opinion, it shouldn't matter until

605
01:08:34,720 --> 01:08:42,400
the die is cast. Right. Yeah. And I think the overall fallacy of increasing validator sets

606
01:08:42,400 --> 01:08:45,680
equals decentralization, I think is a different topic that we should talk about also.

607
01:08:46,480 --> 01:08:53,840
I think going from 125 to 135 does absolutely f all for decentralization, but that's a different

608
01:08:53,840 --> 01:09:01,040
topic. We're going from 125 to 225 does the same thing. Exactly. It's literally the same amount

609
01:09:01,040 --> 01:09:07,600
of decentralization. So speaking of decentralization, I saw I know Secret keeps the validator set

610
01:09:07,600 --> 01:09:12,000
pretty small. Like I think you guys just went to 80, right? It was at 70 or it started at 50.

611
01:09:12,000 --> 01:09:18,640
I don't know the history here, but why do you guys, why do you guys kept that tight? I don't know.

612
01:09:18,640 --> 01:09:25,360
Like I'm not involved in this type. Maybe shorty, we'll know more about this.

613
01:09:25,360 --> 01:09:31,120
Yeah, I can, I can throw a lot of heat in that direction. I was probably the cardinal dissenting

614
01:09:31,120 --> 01:09:40,800
opinion about expanding the set recently. So the cardinal reason was when the network is under

615
01:09:40,800 --> 01:09:49,680
load, you start to see a lot of like pairing off of missed blocks. And the reason why I

616
01:09:49,680 --> 01:09:55,280
dissented from increasing was because we don't know the root cause yet. There are, there was a

617
01:09:55,280 --> 01:10:00,320
bunch of work that chill validation and I did kind of doing a B testing on for what all the

618
01:10:00,320 --> 01:10:06,080
different things, peering, different hardware types, different locations, all sorts of stuff.

619
01:10:06,080 --> 01:10:10,720
And we never like all these different things we were, were changing. We like it into a

620
01:10:10,720 --> 01:10:15,840
mental improvements, but we had no good final solution of this. This was the cause. And

621
01:10:15,840 --> 01:10:24,400
because we haven't had a big load event since us, do having done this testing, I was resistant to

622
01:10:25,360 --> 01:10:30,720
this set actually being increased until then, because during, I think it was during the shade

623
01:10:31,280 --> 01:10:36,080
meant a couple of months ago, block times, I think we're approaching 10 minutes. And

624
01:10:37,040 --> 01:10:41,040
that doesn't seem huge. And yeah, increasing set by 10 won't change that too much,

625
01:10:41,040 --> 01:10:47,440
but it's still that much more risk. 10 seconds. No, no, no. It hit 10 minutes per block.

626
01:10:48,320 --> 01:10:50,240
Really? Oh yeah. Okay.

627
01:10:52,640 --> 01:10:55,360
That's insane. I didn't realize it was. I didn't realize it either.

628
01:10:56,080 --> 01:11:00,400
Yeah. Yeah. Now, I mean, it was for like a full day or two that it, that it slowed down to that

629
01:11:00,400 --> 01:11:06,000
point. And so there was a lot of effort that I wanted to try and figure out what the cause was,

630
01:11:06,000 --> 01:11:11,760
right? Yeah. But I mean, maybe, maybe because all the effort that we've put into resolving the issues

631
01:11:11,760 --> 01:11:15,360
is why there hasn't been a huge event like that since, because there have been multiple

632
01:11:15,360 --> 01:11:18,080
entertainment since then and things like that, but still.

633
01:11:22,000 --> 01:11:28,560
The block state was because of that. Because of the size of the monitor set.

634
01:11:28,560 --> 01:11:35,120
Yeah. So it seemed like one of the core issues was when the block started going down,

635
01:11:36,480 --> 01:11:40,880
because it takes so long that like they're became like consensus hubs, you would see them

636
01:11:40,880 --> 01:11:46,640
rotating who was actually getting consensus. Yeah. And I think that was, that was the biggest

637
01:11:46,640 --> 01:11:51,840
issue. And then hardware improvements or like hardware optimization was, was, was the next big,

638
01:11:51,840 --> 01:12:01,440
big answer. Do you think like, I know is a stuff, how much overhead is there in the,

639
01:12:04,320 --> 01:12:10,000
in the encryption? Because yesterday, I switched over, like I'm running bare metal,

640
01:12:10,000 --> 01:12:16,880
like decent hardware. And I switched over to Cosmovisor, right? So I left.

641
01:12:16,880 --> 01:12:25,760
Well, actually, I switched over to Cosmovisor and a remote signer for secret. And I had just

642
01:12:25,760 --> 01:12:35,520
the hardest time catching back up to the head. So I initially switched over to the remote signer

643
01:12:35,520 --> 01:12:43,360
and kept the just running the, the daemon normally. And I was able to catch up, but it was slow.

644
01:12:43,360 --> 01:12:48,880
And then I switched over to Cosmovisor. I missed far fewer blocks when I switched over to Cosmovisor.

645
01:12:49,600 --> 01:12:57,280
But it took, I couldn't catch the head by the time there was the upgrade. And that was probably

646
01:12:59,280 --> 01:13:05,840
a good few hundred blocks out. Is there like lots of overhead in the encryption that makes

647
01:13:06,240 --> 01:13:10,400
bringing the blocks in slow? And should that matter when you're just trying to sync state?

648
01:13:10,400 --> 01:13:17,040
Or is there like some other issue that makes syncing slow? Because I know that I wasn't the

649
01:13:17,040 --> 01:13:25,280
only one who had that problem yesterday. Yes. So there's of course overhead with the encryption

650
01:13:25,280 --> 01:13:34,080
and with running inside of SGX. And because it's running on encrypted memory. I'm not sure of the

651
01:13:34,080 --> 01:13:43,600
recent figures, but I think the bigger overhead is with the WebAssembly engine.

652
01:13:45,600 --> 01:13:53,840
So Cosmovisor are using a WebAssembly engine that's called WASME. And back in 2020, it was not

653
01:13:53,840 --> 01:14:01,920
compatible with SGX. So we went with a WebAssembly engine called WASME, which is a lot more

654
01:14:01,920 --> 01:14:10,720
slower, like 200, maybe 300 times slower than what's currently in Cosmovisor.

655
01:14:12,240 --> 01:14:18,000
We were just trying to make, to implement like secret contracts, you know, making contracts running

656
01:14:18,000 --> 01:14:28,400
SGX. So right now, WASME engine is far slower than the vanilla Cosmovisor was the engine.

657
01:14:28,400 --> 01:14:36,720
And for example, with what shade we're doing, they were doing a cross-chain

658
01:14:36,720 --> 01:14:46,640
add-on. And because they were doing a cross-chain add-on with secret, the hub and the atom and

659
01:14:46,640 --> 01:14:55,680
Luna. And because each of the chain has different coin types, then you can just like convert between

660
01:14:55,680 --> 01:15:06,400
addresses. The same seed would produce different addresses on secret, on Terra, and on the hub.

661
01:15:07,280 --> 01:15:15,280
So what they had to do is have the, if you want to claim the shade airdrop from your

662
01:15:15,840 --> 01:15:22,480
Terra address, you have to sign a proof that you own the Terra address and send it to the shade

663
01:15:22,480 --> 01:15:30,160
contract. And then the shade contract had to do some heavy cryptographic computations to verify it.

664
01:15:31,200 --> 01:15:39,440
And when a lot of people were claiming a lot of shade at the same time, it made like blocks

665
01:15:40,320 --> 01:15:46,560
stretch to be like 10 minutes. So is there any light at the end of that tunnel? Is there any

666
01:15:46,560 --> 01:15:54,320
plan to move to a different WebAssembly engine or is there development in the WOSMA that maybe

667
01:15:54,320 --> 01:16:01,600
will allow use with SGX later on? Yeah, so since then, WOSMA completely reward the code base.

668
01:16:02,400 --> 01:16:08,240
And now that we're finished with the upgrade, that was like a few hours ago, we're going to

669
01:16:08,240 --> 01:16:16,480
start working on migrating our WOSMA engine to be just like what Cousin was using right now.

670
01:16:18,160 --> 01:16:25,760
We should be 200 to 300 expester. That's a pretty big speed up.

671
01:16:29,200 --> 01:16:33,760
So did you say, sorry, sorry, I was just ready comments. Did you say that

672
01:16:33,760 --> 01:16:38,960
it's what was going to produce that 200 to 300 time speed up?

673
01:16:39,600 --> 01:16:40,480
Switching to WOSMA.

674
01:16:41,360 --> 01:16:48,880
So they are switching to WOSMA. So there is like SGX available on that now? Are you guys going to

675
01:16:50,320 --> 01:16:50,960
do that work?

676
01:16:51,840 --> 01:17:00,880
Yeah, we are going to do that work. Like I said, they completely reward the entire WOSMA code base

677
01:17:00,880 --> 01:17:06,640
like in the past year. And it should be compatible with SGX now.

678
01:17:08,560 --> 01:17:09,920
Awesome. That's great news.

679
01:17:13,440 --> 01:17:19,280
Just had a message from usurper saying they've just had a power cut. So that's why he suddenly

680
01:17:19,280 --> 01:17:27,440
has disappeared from the call. So I've just looked just double checking what we've got through all

681
01:17:27,440 --> 01:17:34,640
our questions here. So we've talked about increasing the VALSET. The other question I think that we

682
01:17:34,640 --> 01:17:40,720
this is kind of interesting from the perspective of we've already talked about secret voting,

683
01:17:41,280 --> 01:17:46,480
which is that does it make validators uncomfortable in the community, asking for reasons

684
01:17:46,480 --> 01:17:51,440
on the way they vote on proposals? And I think you've shortly made an interesting point on this

685
01:17:51,440 --> 01:17:58,800
one already when he said that generally speaking, I think people generally only ask you to justify

686
01:17:58,800 --> 01:18:04,800
your position if you are offering a dissenting view, which I mean, I guess makes sense, right?

687
01:18:07,360 --> 01:18:14,960
I can maybe add input on this. We had a couple of projects building the staking derivatives

688
01:18:14,960 --> 01:18:27,280
on secret, which will make you a staking private. And the contract will stake the secret for you.

689
01:18:30,080 --> 01:18:37,840
They also implemented private voting inside the contract to let you validate or know what you

690
01:18:37,840 --> 01:18:54,400
want to vote or to let the contract vote with the voting power, like in the direction that the

691
01:18:54,400 --> 01:19:05,440
stakers are wanting to vote. So that sounds like almost like a contract version of like

692
01:19:05,440 --> 01:19:15,440
orth Z or that kind of functionality, except secret. Yeah, sort of like it's a contract that

693
01:19:15,440 --> 01:19:28,640
that takes the secret for you privately. And then you can for each governance on chain proposal,

694
01:19:28,640 --> 01:19:36,800
you can vote in the contract, what the contract should vote on with the main governance.

695
01:19:39,920 --> 01:19:44,800
Right. That's really cool. I didn't know that that existed on secret, learning a lot tonight.

696
01:19:46,560 --> 01:19:53,840
So I think we've trying to keep it to 90 minutes, I think now is our optimistic goal,

697
01:19:53,840 --> 01:19:58,880
because we like to chat too much to our guests. So we've got one last question, we've got a wrap

698
01:19:58,880 --> 01:20:03,920
up question, which is, what are you most excited about this week in the cosmos?

699
01:20:04,720 --> 01:20:09,840
Shorty, do you want to kick off first? Because you're usually the most positive and least tired

700
01:20:09,840 --> 01:20:19,120
sounding out of all of us. Yeah, I mean, I hear first, let's see. I can't tell you how excited

701
01:20:19,120 --> 01:20:24,240
I am for the improvements from shockwave. I know I've been saying shockwave upgraded for the last

702
01:20:24,240 --> 01:20:29,520
couple of weeks, but secret networks like my home network. So anytime I see improvement there, I'm

703
01:20:29,520 --> 01:20:40,080
like, yes. So I guess there's that for now. I'm also hopeful about UST coming back up. I think

704
01:20:40,080 --> 01:20:45,120
that within a week, it's going to be back up. I've got some strong hope, even though, like I can,

705
01:20:45,120 --> 01:20:50,480
I have that just directed, a direct inject into my veins. So don't listen to me. But I think it'll

706
01:20:50,480 --> 01:20:56,720
be back up. I think that by that time, the market is going to recover, not recover like

707
01:20:56,720 --> 01:20:59,040
stable, but I think that it's going to at least level out, there's going to be less,

708
01:21:00,720 --> 01:21:03,280
people are going to be more happy to be here again.

709
01:21:07,760 --> 01:21:13,040
I think you're right about the, I think USC will definitely repag. I think it will have

710
01:21:13,040 --> 01:21:20,160
probably more volatility going forward though, because of thinner pulls and less backing.

711
01:21:21,920 --> 01:21:26,400
But I definitely think it'll repag. I know we didn't sell anything of our UST

712
01:21:27,360 --> 01:21:33,760
that we still had when it started to depag. We had fortunately, from a risk perspective,

713
01:21:34,560 --> 01:21:40,720
actually sold almost all of our UST just the day before this whole thing kicked off. So we were

714
01:21:40,720 --> 01:21:48,800
lucky in that regard. But that was basically just a, we do like a bit of a risk mitigation

715
01:21:49,440 --> 01:21:54,800
rebase every couple of weeks, just to see where our assets are sitting and what the

716
01:21:54,800 --> 01:22:04,080
risk of that is to our business. So in my case, it's better to move our risk over into our fiat

717
01:22:04,080 --> 01:22:11,520
and let our government have a chance to bugger it up for us instead of a non.

718
01:22:15,680 --> 01:22:26,480
But actually, my thing, we have released our King airdrop. So that's nice. We have been waiting

719
01:22:26,480 --> 01:22:34,800
for Juno Tools all this time. And I'm pretty excited about its release. It was incredibly easy to use

720
01:22:34,800 --> 01:22:43,920
and super smooth. So congratulations to the team who built that. And yeah, so that's

721
01:22:45,040 --> 01:22:51,600
my thing that I'm pretty happy about. If anyone wants to do an airdrop, recommend using Juno

722
01:22:51,600 --> 01:23:00,560
Tools with the Merkle route. It's cheap on gas. It's very easy to use. You can put tens of thousands

723
01:23:00,560 --> 01:23:06,960
of addresses into it. So it's very good. Nice. Yeah. Asaf, what are you most excited about in the

724
01:23:06,960 --> 01:23:15,200
coming week in the course of our launch? Obviously seeing how the Lunar UST situation evolves.

725
01:23:15,200 --> 01:23:22,320
And I'm hopeful that the Lunar community can come together and

726
01:23:24,800 --> 01:23:32,160
interested to see what's going to happen with Lunar. I'm pretty sure that UST will repack, but

727
01:23:33,920 --> 01:23:36,640
pretty interested to see what's going to happen with Lunar.

728
01:23:36,640 --> 01:23:47,760
And yes, super excited to be done with Shockwave after edge and started to work on new things

729
01:23:47,760 --> 01:23:53,120
like Cosmos and V1 and IBC contract and stuff like that.

730
01:23:54,640 --> 01:24:01,440
Must be a huge load off having the work completed on Shockwave.

731
01:24:01,440 --> 01:24:10,800
Yeah. So actually it was the first time that we used the upgrade module up until now we exported

732
01:24:10,800 --> 01:24:19,200
and imported. And it was pretty painful every time and now it was super smooth. It took like

733
01:24:19,840 --> 01:24:26,480
nine and a half minutes to upgrade, which was really nice compared to other times.

734
01:24:26,480 --> 01:24:37,200
Quick question. Do you have a repo that we can do PRs to fix some of the documentation around

735
01:24:38,080 --> 01:24:41,840
Cosmovisor having now implemented it? We've got a few fixes to those docs.

736
01:24:43,440 --> 01:24:48,480
Yeah, I can also just say. Yeah, good. That's cool.

737
01:24:50,640 --> 01:24:52,640
We're happy to go through and fix that up Asaf.

738
01:24:52,640 --> 01:24:57,120
I think that I fixed your comments. But you've already hit it.

739
01:24:58,560 --> 01:25:02,000
Happy if you can make more PRs and make it better. Yeah.

740
01:25:02,960 --> 01:25:06,560
Yeah, might just have another look at it and see if there's any improvements we can make anyway.

741
01:25:07,440 --> 01:25:15,520
To anybody listening, cool people do PRs, cool people fix docs. Be more like Null, fix documentation.

742
01:25:16,560 --> 01:25:21,440
Be more like everyone here. We all hack on documentation in our spare time.

743
01:25:21,440 --> 01:25:26,080
I think that's true. Yeah, as soon as the upgrade finished, the first thing I do is start modifying

744
01:25:26,080 --> 01:25:31,920
the documents, making more accurate. So yeah, people love to have a pedantic streak.

745
01:25:33,280 --> 01:25:36,880
People love. I love to be able to make docs that people can just copy paste.

746
01:25:38,720 --> 01:25:43,440
We should do a whole segment on copy pasting docs and whether or not that's a good thing or a bad

747
01:25:43,440 --> 01:25:49,280
thing. Couldn't we? I think we've talked about it previously about the copy paste glory.

748
01:25:49,280 --> 01:25:56,640
Yeah. It's the new Nomes Blackboard. It's just copy paste question marks and shit in the middle.

749
01:25:56,640 --> 01:26:02,560
I think every copy paste documentation should have rf slash in it and just

750
01:26:04,400 --> 01:26:10,640
to see who's awake. Hold on a second. I'm not going to do that.

751
01:26:11,760 --> 01:26:18,080
One of the most insane things. I'll tell this story and then I think that's pretty much all

752
01:26:18,080 --> 01:26:22,720
the time we have. But one of the most insane things I've ever seen on the internet was back in

753
01:26:23,680 --> 01:26:31,360
over 10 years ago on IRC, I saw on a chat room somebody looking for tech support. They just

754
01:26:31,360 --> 01:26:34,720
logged it. They just started, I think this was pre Docker. They were running on bare metal. They

755
01:26:34,720 --> 01:26:40,160
were trying to redeploy a Ruby on Rails application. They didn't really know what they were doing in

756
01:26:40,160 --> 01:26:47,600
terms of running on Linux and they were having a hard time. A couple of people tried to help and

757
01:26:47,600 --> 01:26:53,920
they'd been kind of an ass about it. The helpful people had gone, okay, you can get on with it.

758
01:26:55,200 --> 01:27:00,240
Essentially a troll had started helping them and just been telling them garbage. Everybody has

759
01:27:00,240 --> 01:27:06,160
been like, well, when you root the people trying to help you, whatever, let's just see how this

760
01:27:06,160 --> 01:27:13,360
plays out. Then it suddenly escalated where this troll was literally like rmr slash kind of thing.

761
01:27:13,360 --> 01:27:23,360
Then the person on IRC who was obviously there was like, it's asking for my password. What should I do?

762
01:27:23,360 --> 01:27:28,320
We're all like, scrabbling for the keyboard being like, don't do it. Then they just connected from

763
01:27:28,320 --> 01:27:33,520
IRC or whatever. It was like, what the hell happened there? I really want to know what the

764
01:27:33,520 --> 01:27:38,800
hell happened there. It's like, was that it? Did they just accidentally trash their laptop? Were

765
01:27:38,800 --> 01:27:45,520
they not even SSHed onto them? What was going on? Then everybody was just sat around and be like,

766
01:27:45,520 --> 01:27:50,560
hey, did that guy just wipe his hard drive or something? I think he said he was on a server.

767
01:27:50,560 --> 01:27:56,240
Can anybody remember what he said 10 minutes ago? This troll also just disconnects as well. It was

768
01:27:56,240 --> 01:28:02,960
like, wow, that was really weird. It was like the UK Ruby or UK Rails IRC a long time ago. I was like,

769
01:28:02,960 --> 01:28:10,160
wow. Maybe he was just trolling himself for shits and giggles. I mean, it might have been a piece

770
01:28:10,160 --> 01:28:16,800
of kind of performance comedy via IRC. That would be a lot of effort again to do that whole kind

771
01:28:16,800 --> 01:28:23,680
of thing. Do a kind of skit. I mean, if it was very well executed, I believed it. I was bought in.

772
01:28:23,680 --> 01:28:28,560
I felt the emotion and I very much enjoyed it. 10 out of 10. We would go and see that

773
01:28:28,560 --> 01:28:34,720
Edinburgh Fringe show again. Do you think that would be quite good? You could do it. You could

774
01:28:34,720 --> 01:28:40,480
do a very avant-garde Edinburgh Fringe comedy festival thing where you did the entire show via

775
01:28:40,480 --> 01:28:46,160
IRC or something like that. But then nobody would get it because who even knows what IRC is anymore?

776
01:28:46,960 --> 01:28:51,760
Hello. Hi. Nice to meet you. That's Discord, right? Basically.

777
01:28:51,760 --> 01:28:58,960
Discord is basically just like IRC without any of the freedom. That's Slack.

778
01:29:01,520 --> 01:29:07,280
Slack was IRC for business, which I thought of literally 25 years ago, but sorry. I only

779
01:29:07,280 --> 01:29:13,600
missed out a few billion there. Yeah, but did you make it? No. There you go. Too early.

780
01:29:14,480 --> 01:29:18,640
Yeah, too early. What's the quote? There's nothing more infuriating than being

781
01:29:18,640 --> 01:29:25,600
10 years too late, except being one year too early. Something like that, right?

782
01:29:27,440 --> 01:29:31,120
So what is your most excited about in the cosmos this coming week?

783
01:29:32,240 --> 01:29:36,240
Shit. Yeah, come back just in time for the final question. Come back just in time.

784
01:29:37,200 --> 01:29:40,080
Come back to me. Let me give me a second. Okay. Well, you got a little bit of time.

785
01:29:40,080 --> 01:29:41,120
Well, I can't come back to you.

786
01:29:41,120 --> 01:29:47,920
My last one because it's me. So I'm going to go, I'm planning on, well, we are planning on

787
01:29:49,040 --> 01:29:54,480
setting up on a cache in the coming weeks and we're going to go because we're obviously moving to using

788
01:29:55,840 --> 01:30:00,240
like Null has and like King Nodes have. We're moving to remote silence across the board.

789
01:30:00,960 --> 01:30:06,160
We're also going to look at moving some of our infrared to a cache. So that's been pretty exciting.

790
01:30:06,160 --> 01:30:10,640
And I think we'll probably do the first, the first one we'll do in that structure will be

791
01:30:10,640 --> 01:30:16,000
the a cache validator. So assuming I have time to do it in between stuff and obviously Prague

792
01:30:16,000 --> 01:30:22,800
is next week, which was very exciting. But I'm more excited about the a cache validator than Prague.

793
01:30:23,920 --> 01:30:26,160
Yeah, it's pretty cool, man. Maybe. Maybe I am.

794
01:30:27,280 --> 01:30:31,360
Are you going to attempt the cache on a cache?

795
01:30:31,360 --> 01:30:37,520
Yeah. Yeah. Yeah, we're going to do it. We're going to do it. We're going to do it. We're going to

796
01:30:38,400 --> 01:30:40,960
we're going to live in glory or we're going to double sign.

797
01:30:42,160 --> 01:30:49,040
Are you going to? Are you going to? Sorry, what was that? Is that a thing? And I keep,

798
01:30:49,040 --> 01:30:52,080
can you run like in a cache validator or in a cache info?

799
01:30:52,880 --> 01:30:58,000
Oh my god. Yeah, I think can now as of, especially as of the most recent upgrade where

800
01:30:58,000 --> 01:31:03,200
they've the storage story has got a lot better. Well, you have been able to do it for a very

801
01:31:03,200 --> 01:31:09,280
long time now. It's just that you had to. Sorry. The way

802
01:31:13,520 --> 01:31:15,840
God, that was going to be interesting. I know. It's interesting.

803
01:31:17,440 --> 01:31:23,920
You're back. He's frozen. Nope. He's frozen again. So you set up your times up.

804
01:31:23,920 --> 01:31:29,680
Oh, I'll go. I'll go up. Yeah. So we're, we're, I was just actually rebuilding

805
01:31:29,680 --> 01:31:35,440
some of the structure this week. So we're also moving to away from just validator signing nodes.

806
01:31:35,440 --> 01:31:44,720
We're, we're going to do a Horcrux based swarm. That swarm is going to be across three vendors

807
01:31:44,720 --> 01:31:53,120
in the U.S. So that's going to be an OVH on AWS. And we have a colo that we run and that we run a

808
01:31:53,120 --> 01:31:58,000
ton of hardware in our own colo. So that's a third note. And so those are all connected. We were,

809
01:31:58,000 --> 01:32:02,240
I was doing a lot of work with like wire garden, some different types of easy management tools of

810
01:32:02,240 --> 01:32:05,760
that like net maker and things like that actually went away from that. And we're going to use Nebula,

811
01:32:05,760 --> 01:32:10,640
which is a, if you guys have heard of Nebula, it's like a kind of like a peer to peer mesh

812
01:32:10,640 --> 01:32:15,040
network built by some of the, some of the groups at Slack initially, because I think they use that

813
01:32:15,040 --> 01:32:20,400
a tremendous amount to be able to do kind of internal routing across a lot of cloud providers.

814
01:32:20,400 --> 01:32:23,840
And then now it's being spawned off. I think some of the either engineering team left or that's a

815
01:32:23,840 --> 01:32:27,760
business with the business or something called defined. So that's, I'll put links in the show

816
01:32:27,760 --> 01:32:33,440
notes around that. It's still pretty early, but man, is it stable. So I had a lot of issues with

817
01:32:33,440 --> 01:32:37,440
wire guard appearing out, starting to do a lot of things where I would drop ports and other types

818
01:32:37,440 --> 01:32:42,960
of things to make sure that those, that swarm would reconnect and everything else and, and just

819
01:32:42,960 --> 01:32:47,520
kind of struggling with that. But so that'll be on three different networks, all 20 milliseconds

820
01:32:47,520 --> 01:32:53,040
away. And so I kind of done some testing to be able to say, I can have a major outage on AWS

821
01:32:53,040 --> 01:32:58,480
or somewhere else and, and still be able to sign. So once I do that, and I need to build some

822
01:32:58,480 --> 01:33:04,640
ansible structures around that for the signing piece of things, then that allows the nodes to

823
01:33:04,640 --> 01:33:10,480
really do anything. And so I think the Akash structure is something that after talking about

824
01:33:10,480 --> 01:33:16,080
that is, is really, really interesting. We still run a ton of Colo, you know, we have a lot of

825
01:33:16,080 --> 01:33:21,040
nodes in our Colo, but, but to be able to spread that out a little bit and reduce that need and then

826
01:33:22,000 --> 01:33:28,320
those types of things. So my goal is that, that away from like some massively something horrible

827
01:33:28,320 --> 01:33:34,000
at messing it happening in the North American East, away from that, that there could be a massive

828
01:33:34,000 --> 01:33:40,880
vendor outage on any one of three or four really large, you know, bare metal hosting providers

829
01:33:40,880 --> 01:33:46,800
and not miss a block. That's really my goal. And so, so anyway, it's just, you know, a lot of testing

830
01:33:46,800 --> 01:33:50,640
kind of structure around that, but that's, I'm getting ready to be able to at least move some,

831
01:33:51,440 --> 01:33:55,600
some stuff over and get that going, just to be able to do some testing and things like that. And

832
01:33:55,600 --> 01:34:00,560
then, then hopefully we'll move some of the more important chains over and yeah, so that's kind of

833
01:34:00,560 --> 01:34:08,000
what I'm working on. Cause more so many bus man is what I was, I was going to say before, but

834
01:34:08,000 --> 01:34:17,040
you've been able to, to use it for validators for a very long time. It's just that you sort of,

835
01:34:17,040 --> 01:34:41,120
the way it's set up, you have to put your keys in.