1
00:00:13,900 --> 00:00:16,600
Welcome to epicenter the show 
which talks about the technology

2
00:00:16,600 --> 00:00:19,000
is project that people are 
driving decentralization and the

3
00:00:19,000 --> 00:00:21,100
blockchain revolution. 
I'm Felix. 

4
00:00:21,100 --> 00:00:23,200
And I'm here with mayor Roy. 
Today, we're speaking with 

5
00:00:23,200 --> 00:00:26,500
Colleen, Myers and ocean keine, 
worte cofounders of mobile apps.

6
00:00:26,500 --> 00:00:29,400
Mobile is building software to 
enable distributed operation of 

7
00:00:29,400 --> 00:00:31,300
validator. 
He's starting on aetherium. 

8
00:00:32,400 --> 00:00:33,400
Hi, ocean. 
And hi. 

9
00:00:33,400 --> 00:00:37,900
Colin and welcome to epicenter. 
Hey guys, thanks for having us 

10
00:00:38,700 --> 00:00:41,200
pledge to be here. 
Yeah. 

11
00:00:41,200 --> 00:00:46,000
So both of you actually were in 
touch for like a long time. 

12
00:00:46,000 --> 00:00:51,300
You've both been in the space 
and in staking, especially for a

13
00:00:51,300 --> 00:00:54,100
while. 
So, you know, as is customary on

14
00:00:54,100 --> 00:00:57,300
epicenter. 
We'd love to first, get an 

15
00:00:57,300 --> 00:01:00,900
introduction to how you, how you
got into crypto, and how you got

16
00:01:00,900 --> 00:01:04,599
to where you are today? 
Maybe calling you can even start

17
00:01:05,600 --> 00:01:07,800
Yeah, cool. 
Yeah, thanks, thanks for having 

18
00:01:07,800 --> 00:01:11,200
us again. 
I have been watching and 

19
00:01:11,200 --> 00:01:14,100
observing epicenter for from a 
distance and always wondered 

20
00:01:14,100 --> 00:01:17,500
when we get our shot. 
So, yeah, happy happy. 

21
00:01:17,500 --> 00:01:20,500
I finally came. 
Definitely on the longer end of 

22
00:01:20,500 --> 00:01:23,300
the spectrum, based on my 
expectation set. 

23
00:01:23,300 --> 00:01:25,200
But yeah, happy, we finally made
it happen. 

24
00:01:25,800 --> 00:01:28,200
Yeah. 
So quick, quick background on me

25
00:01:28,700 --> 00:01:31,500
actually. 
Non-developer by background used

26
00:01:31,500 --> 00:01:34,800
to work on Wall Street worked in
a variety of different banks. 

27
00:01:34,900 --> 00:01:40,000
It's mostly in like credit and 
debt and got involved with 

28
00:01:40,100 --> 00:01:44,800
etherium Community 2017. 
I was living in New York and, 

29
00:01:44,800 --> 00:01:47,300
you know, lucky for me, there 
was consensus, and there was Joe

30
00:01:47,300 --> 00:01:49,800
Lubin and there was meetups and 
you know, it was different stuff

31
00:01:49,800 --> 00:01:54,800
happening and at this point in 
my life like 2017, I was trying 

32
00:01:54,800 --> 00:01:58,000
to spend a lot of time, you 
know, trying to work at a hedge 

33
00:01:58,000 --> 00:02:01,100
fund or a private Equity Firm or
actually, honestly, just totally

34
00:02:01,100 --> 00:02:05,200
lost it still like, what I was 
supposed to do, and There was 

35
00:02:05,200 --> 00:02:07,400
two things going on at that 
point in time, one of them was 

36
00:02:07,400 --> 00:02:10,600
we work and the other one was 
crypto in New York and those 

37
00:02:10,600 --> 00:02:13,900
were like the two main things 
that everyone was buzzing about 

38
00:02:13,900 --> 00:02:18,700
and work worked in trying to get
a job there but also spent most 

39
00:02:18,700 --> 00:02:24,200
of my time on it period 2017. 
I met Joe living in a Meetup was

40
00:02:24,200 --> 00:02:27,600
inspired to quit my job. 
So I did then I joined consensus

41
00:02:27,600 --> 00:02:31,900
in 2018 and I worked there for 
about three and a half years at 

42
00:02:31,900 --> 00:02:34,800
consensus, was able to work on a
lot of different. 

43
00:02:34,900 --> 00:02:38,500
Technologies even like space and
blockchain and some crazy stuff 

44
00:02:38,500 --> 00:02:43,100
like that but primarily focused 
on staking I started a project 

45
00:02:43,100 --> 00:02:46,000
called token Foundry which was 
like an early mover in this 

46
00:02:46,000 --> 00:02:48,700
space to helping Network's 
launch and trying to do 

47
00:02:48,700 --> 00:02:52,700
compliant token launches turned 
that project into a project 

48
00:02:52,700 --> 00:02:56,700
called activate which was 
recently sunset by codify 

49
00:02:56,700 --> 00:02:58,200
something. 
We actually partnered with on 

50
00:02:58,200 --> 00:03:03,400
course one in the early days and
throughout those time periods I 

51
00:03:03,400 --> 00:03:08,500
spend a lot of Didn't time 
contributing to eat to was 

52
00:03:08,500 --> 00:03:09,900
involved in early working 
groups. 

53
00:03:09,900 --> 00:03:12,700
After Devcon for, and I 
primarily at the beginning 

54
00:03:12,700 --> 00:03:16,400
focused on the economics of E2, 
they were not very well 

55
00:03:16,400 --> 00:03:20,600
understood and my job was to 
help enable the understanding of

56
00:03:20,600 --> 00:03:23,300
the economics. 
For your at-home. 

57
00:03:23,300 --> 00:03:26,100
Validators for your larger 
scale, validators, your 

58
00:03:26,100 --> 00:03:28,300
exchanges. 
People like quite basic 

59
00:03:28,300 --> 00:03:30,900
consensus and these different 
types of actors. 

60
00:03:31,900 --> 00:03:35,100
Those initial work streams led 
to a lot of different enablement

61
00:03:35,100 --> 00:03:37,200
projects around the Genesis 
event. 

62
00:03:37,200 --> 00:03:41,300
So the majority of my time was 
spent around the Genesis event 

63
00:03:41,300 --> 00:03:44,900
and enabling that to take place 
while it consensus. 

64
00:03:44,900 --> 00:03:48,300
We built the eats you launch 
pad, which is so individual 

65
00:03:48,300 --> 00:03:49,800
place where you're at on 
validators. 

66
00:03:49,800 --> 00:03:52,500
Interact with the deposit 
contract, spent quite a bit of 

67
00:03:52,500 --> 00:03:55,700
time with the client teams and 
help them with user feedback. 

68
00:03:56,600 --> 00:04:00,700
And ultimately all of these 
research projects culminated and

69
00:04:00,700 --> 00:04:05,300
what today is Is now DBT. 2019, 
dr. 

70
00:04:05,300 --> 00:04:07,100
Fights. 
And curl be started to research 

71
00:04:07,100 --> 00:04:11,600
group focused on trust minimize 
staking and Marsh meet and 

72
00:04:11,600 --> 00:04:14,800
myself, were the first two to 
come in to help enable that. 

73
00:04:14,800 --> 00:04:19,200
After it, got completely sucked 
down the rabbit hole on DBT, 

74
00:04:19,700 --> 00:04:22,200
thought it was world changing 
technology. 

75
00:04:22,200 --> 00:04:25,300
Three years ago, no one had any 
idea what we were talking about?

76
00:04:26,100 --> 00:04:30,600
It was kind of grossly 
underfunded as an effort and 

77
00:04:30,600 --> 00:04:33,600
ultimately the The only way that
we found proper funding to turn 

78
00:04:33,600 --> 00:04:37,000
DBT into a project was by ocean 
and I both quitting our jobs 

79
00:04:37,000 --> 00:04:40,100
respectively and going out and, 
you know, raising capital on our

80
00:04:40,100 --> 00:04:43,000
own and finishing the effort and
putting the group of people 

81
00:04:43,000 --> 00:04:45,500
together to make the technology 
a reality. 

82
00:04:45,500 --> 00:04:48,800
So, yeah, that's me. 
Thanks for having me on. 

83
00:04:48,800 --> 00:04:53,300
I'm a neat Maxi, loving Cosmos 
these days though, but yeah, 

84
00:04:53,400 --> 00:04:58,600
really excited about it. 
And then yeah, to give my 

85
00:04:58,600 --> 00:05:02,200
background, I'm a software 
developer by background and in 

86
00:05:02,200 --> 00:05:05,400
fact, I'm the fortunate person 
who's like, second generation 

87
00:05:05,400 --> 00:05:07,900
internet entrepreneur. 
My parents have run web 

88
00:05:07,900 --> 00:05:12,100
companies, most of my life. 
So yeah, would have grown up 

89
00:05:12,100 --> 00:05:15,400
around kind of original website,
building web design and the like

90
00:05:15,400 --> 00:05:18,600
late 90s early noughties. 
And so, I kind of sass companies

91
00:05:18,600 --> 00:05:23,000
built in the kind of notice and 
2010's and out of college. 

92
00:05:23,000 --> 00:05:25,900
I worked as a consultant and 
kind of discovered. 

93
00:05:26,100 --> 00:05:30,700
Crypto in 2017 and got my first 
kind of full time role in 2018 

94
00:05:31,000 --> 00:05:34,900
when consensus opened an office 
in Ireland, and I did two years,

95
00:05:34,900 --> 00:05:38,500
they're in their tokenization 
Department, we did some 

96
00:05:38,500 --> 00:05:41,400
projects, very tokenized 
Securities for French real 

97
00:05:41,400 --> 00:05:45,200
estate on maenette back in 2019,
before that was prohibitively 

98
00:05:45,200 --> 00:05:51,300
expensive to do on my net, and I
left consensus in March, 20, 20,

99
00:05:51,500 --> 00:05:54,500
and I Incorporated myself as a 
self-employed kind of 

100
00:05:54,508 --> 00:05:58,300
contractor. 
Picked up by black demon to do e

101
00:05:58,300 --> 00:06:03,200
to research for them back in 
2018, when the originally two 

102
00:06:03,200 --> 00:06:07,600
specs came out my I wrote an 
article that was effectively 

103
00:06:07,600 --> 00:06:10,700
quite critical of them. 
At the time, it was 1,500 either

104
00:06:10,700 --> 00:06:12,800
minimum and Sachin was fairly 
severe. 

105
00:06:12,800 --> 00:06:15,800
And I was like really do bees 
with this was going to be safe 

106
00:06:15,800 --> 00:06:19,400
or make sense and then yeah, I 
kind of kept an eye on it. 

107
00:06:19,400 --> 00:06:24,200
Got involved with block demon 
building it along and end up 

108
00:06:24,207 --> 00:06:27,500
building out their teeth to 
stack for them. by Genesis and I

109
00:06:27,508 --> 00:06:30,400
say shortly after Genesis I was 
first introduced to the idea of 

110
00:06:30,400 --> 00:06:33,500
trust was validators by getting 
an invite to this trust was 

111
00:06:33,500 --> 00:06:37,700
validated Community Hall that 
common Ameri running and at the 

112
00:06:37,700 --> 00:06:41,600
time I was kind of agonizing 
over having no ability to run a 

113
00:06:41,600 --> 00:06:44,900
backup validator or do anything 
when one failed and I was 

114
00:06:44,900 --> 00:06:47,400
introduced to this technology 
and it's like, oh it's high 

115
00:06:47,400 --> 00:06:49,700
availability for validators, is 
definitely going to be thing 

116
00:06:49,800 --> 00:06:53,200
everything in web to does this 
and I was kind of an immediate 

117
00:06:53,200 --> 00:06:55,900
convert but yeah I think Colin 
realize it's not very many other

118
00:06:56,100 --> 00:07:00,700
Where yeah, we took me maybe a 
few more months of kind of being

119
00:07:00,700 --> 00:07:03,200
involved. 
I was trying to make an mft 

120
00:07:03,200 --> 00:07:06,000
issuance kind of Stack. 
I did some work trying to issue 

121
00:07:06,000 --> 00:07:10,400
like rugby video and ft's with 
some kind of like, famous rugby 

122
00:07:10,400 --> 00:07:12,200
players that didn't really go to
plan. 

123
00:07:12,200 --> 00:07:15,800
And then someone once approached
me and asked me to make a nearly

124
00:07:15,800 --> 00:07:19,800
20 token for to represent steak,
and I kind of counter pitch them

125
00:07:19,800 --> 00:07:22,500
and try to make like NF teeth to
represent validators. 

126
00:07:23,400 --> 00:07:27,400
And then, yeah, it, I wasn't 
Really very good at selling any.

127
00:07:27,400 --> 00:07:30,800
This idea had a product but I 
had no business Acumen and I 

128
00:07:30,800 --> 00:07:33,600
realized that I wasn't really 
very correct for the whole CEO 

129
00:07:33,600 --> 00:07:35,500
role. 
So I reached out to one of the 

130
00:07:35,500 --> 00:07:38,800
only business people I knew in 
the space, who's Colin because a

131
00:07:38,808 --> 00:07:41,200
couple of people have been kind 
of pushing my me his Direction, 

132
00:07:41,500 --> 00:07:43,300
and I was talking to about what 
I was doing. 

133
00:07:43,700 --> 00:07:45,700
Yeah, she'll be what he was 
working on and what I wanted to 

134
00:07:45,700 --> 00:07:49,500
do with oh ball took me a few 
weeks to get convinced that it 

135
00:07:49,500 --> 00:07:52,600
was not too hard to attempt. 
And yeah, I think we kind of 

136
00:07:52,600 --> 00:07:56,200
started around April 20-21 
together and here we are met. be

137
00:07:56,400 --> 00:08:01,000
2 years later, but more Awesome.
Yeah that's a rich history. 

138
00:08:01,000 --> 00:08:04,100
You both have and thanks for 
going too deep into it, I think.

139
00:08:04,300 --> 00:08:07,300
Yeah, we personally also have 
worked a little bit on high 

140
00:08:07,300 --> 00:08:10,900
availability of a validation. 
So like we're both very excited 

141
00:08:10,900 --> 00:08:14,600
about this episode so yeah I can
to get into it right? 

142
00:08:14,600 --> 00:08:16,100
So I guess maybe we can start 
there. 

143
00:08:16,100 --> 00:08:18,100
We already mentioned DVT a bit. 
Maybe. 

144
00:08:18,100 --> 00:08:20,500
Can you explain? 
You know what is distributed 

145
00:08:20,500 --> 00:08:24,500
validator technology? 
Yeah, cool. 

146
00:08:24,500 --> 00:08:28,900
I'll give kind of a more macro 
perspective, is to like the 

147
00:08:28,900 --> 00:08:32,000
difference between a normal 
validator, and then, oh, she can

148
00:08:32,000 --> 00:08:34,100
get a bit more into like 
technical architecture and 

149
00:08:34,100 --> 00:08:38,200
deployment and stuff. 
So, today, a validator consists 

150
00:08:38,200 --> 00:08:42,000
of three pizzas. 
It is a public-private key pair 

151
00:08:43,000 --> 00:08:46,700
is a machine and it is an agent,
an agent. 

152
00:08:46,700 --> 00:08:49,100
We look at is an individual or 
an entity. 

153
00:08:49,100 --> 00:08:53,000
So it's three things and all of 
those are super monolithic and 

154
00:08:53,000 --> 00:08:56,000
that's just The validator stack 
of today from an Indian 

155
00:08:56,000 --> 00:09:01,800
perspective, what DBT enables is
a more modular validator stack 

156
00:09:02,200 --> 00:09:06,900
and now what happens post DBT is
you have key shares, not just 

157
00:09:06,900 --> 00:09:09,400
one public-private key pair. 
You have a collection of key 

158
00:09:09,400 --> 00:09:13,600
shares as many as you'd like to 
create based on your trust, you 

159
00:09:13,600 --> 00:09:16,300
know, properties. 
Essentially, the next piece is 

160
00:09:16,300 --> 00:09:19,000
that those key shares then can 
go on multiple machines, not 

161
00:09:19,000 --> 00:09:22,400
just one machine, but multiple 
machines, and then third, and 

162
00:09:22,400 --> 00:09:26,500
lastly, this salad Can be run by
a group of people or a group of 

163
00:09:26,500 --> 00:09:29,300
entities. 
So it takes your modular 

164
00:09:29,300 --> 00:09:32,900
validator today, super 
monolithic and it takes it to 

165
00:09:32,900 --> 00:09:36,200
the more modular version where 
you can have multiple key 

166
00:09:36,200 --> 00:09:38,400
shares. 
It increases your security, you 

167
00:09:38,400 --> 00:09:42,300
can have multiple machines and 
increases your availability and 

168
00:09:42,300 --> 00:09:44,300
you can have multiple people or 
entities. 

169
00:09:44,300 --> 00:09:48,100
Therefore increases kind of your
game theory or decreases. 

170
00:09:48,100 --> 00:09:51,900
The chances of Byzantine 
behavior for that validator and 

171
00:09:51,900 --> 00:09:54,200
I'll give it to a sheet and you 
can go more Linda kind of 

172
00:09:54,600 --> 00:09:58,200
technical talk. 
Yeah, I think an epicenter 

173
00:09:58,200 --> 00:09:59,700
podcast. 
Maybe one of the only places 

174
00:09:59,700 --> 00:10:02,600
where I can talk about their 
like nerdier details of this 

175
00:10:02,600 --> 00:10:07,400
rather than the high-level idea.
But yeah, I think one of the 

176
00:10:07,700 --> 00:10:11,100
interesting things about it or 
what, you know, makes these 

177
00:10:11,100 --> 00:10:14,000
distributed validators more 
possible than they might, 

178
00:10:14,000 --> 00:10:18,600
otherwise be is the cryptography
that etherium to, I should 

179
00:10:18,600 --> 00:10:20,600
probably stop saying the word of
to use as proof of stake 

180
00:10:20,600 --> 00:10:23,000
etherium. 
And that's the BLS signature 

181
00:10:23,000 --> 00:10:25,600
scheme. 
What's so fancy about the BLS 

182
00:10:25,600 --> 00:10:28,600
signature scheme? 
Is it's one of the first signal 

183
00:10:28,600 --> 00:10:30,200
like elliptic curve signature 
schemes. 

184
00:10:30,200 --> 00:10:33,200
Where if you have, you know, 
independent signatures all for 

185
00:10:33,200 --> 00:10:35,600
the same. 
Hash you can actually like add 

186
00:10:35,600 --> 00:10:37,500
them together in a low trust 
environment. 

187
00:10:37,500 --> 00:10:41,100
You don't need the original 
private key to do so so what 

188
00:10:41,100 --> 00:10:43,600
happens as Colin alluded to is 
you know you want to set up a 

189
00:10:43,600 --> 00:10:46,200
distributed validator. 
The first thing you probably do 

190
00:10:46,200 --> 00:10:49,100
is a distributed key generation 
unless you want to just spit a 

191
00:10:49,108 --> 00:10:52,100
normal key locally, but it's 
better if you kind of do one 

192
00:10:52,100 --> 00:10:55,700
with the dkg, then at the end of
that process, there's you know, 

193
00:10:55,700 --> 00:10:58,600
let's call it. 
Or machines to keep it easy and 

194
00:10:58,700 --> 00:11:02,000
each with the piece of the 
private key on it and you have a

195
00:11:02,008 --> 00:11:04,800
piece of software in the middle 
of your validator stack between 

196
00:11:04,800 --> 00:11:09,700
your like consensus client and 
your validator client and it 

197
00:11:10,000 --> 00:11:12,900
these four nodes can be like 
connect to one another over like

198
00:11:12,900 --> 00:11:16,900
TCP and they more or less play a
little consensus game to decide 

199
00:11:16,900 --> 00:11:19,100
what they're going to sign. 
Every time that there's a 

200
00:11:19,100 --> 00:11:22,600
validator Duty coming up. 
They play little consensus game 

201
00:11:22,600 --> 00:11:23,700
pick. 
This is the hash we're going to 

202
00:11:23,700 --> 00:11:27,900
sign and then every valid are 
client Even the exact same, you 

203
00:11:27,900 --> 00:11:30,600
know, hash to sign. 
They all, you know, check it for

204
00:11:30,600 --> 00:11:32,500
slashing rules, do all the usual
things. 

205
00:11:32,700 --> 00:11:35,400
What's nice is everyone gets to 
keep their own private Key 

206
00:11:35,400 --> 00:11:38,500
Management. 
You know, the oval software is 

207
00:11:38,500 --> 00:11:40,300
just kind of read. 
Only the Middle where it doesn't

208
00:11:40,300 --> 00:11:42,300
actually have the power to sign 
anything. 

209
00:11:43,200 --> 00:11:45,400
So all the independent 
validators, check that nothing 

210
00:11:45,400 --> 00:11:47,400
flashable. 
Once they're happy, they sign it

211
00:11:47,400 --> 00:11:50,600
with their piece of the private 
key and they broadcast to what 

212
00:11:50,600 --> 00:11:52,300
it looks like their consensus 
client. 

213
00:11:52,500 --> 00:11:55,300
And then in the middle, there 
are software like intercepts 

214
00:11:55,300 --> 00:11:57,400
them. 
Share them around with the other

215
00:11:57,400 --> 00:11:59,500
machines. 
And once any of in this 

216
00:11:59,500 --> 00:12:03,300
instance, like a four node 
cluster, 13 of them like this. 

217
00:12:03,300 --> 00:12:05,600
Three of the signatures of 
together, you can combine them 

218
00:12:05,600 --> 00:12:08,400
into a full, valid signature, 
for the validator, and you can 

219
00:12:08,400 --> 00:12:09,700
send that on which to the 
network. 

220
00:12:09,900 --> 00:12:12,400
And what's neat about that is, 
you don't need all four 

221
00:12:12,400 --> 00:12:14,300
signatures. 
He actually can have fault 

222
00:12:14,300 --> 00:12:17,300
tolerance and this is kind of 
one of the super important 

223
00:12:17,300 --> 00:12:20,500
things about high availability 
is if you put, you know, a 

224
00:12:20,500 --> 00:12:22,800
validator and for machines, but 
you need all four of them to be 

225
00:12:22,800 --> 00:12:25,900
online, you're more brittle than
you would otherwise be, but he 

226
00:12:25,900 --> 00:12:28,700
put in for Machines and, you 
know, only need 3 to be online. 

227
00:12:29,000 --> 00:12:31,500
This is where things really 
start to change and you can have

228
00:12:31,500 --> 00:12:34,200
high uptime. 
You can do rolling restarts, you

229
00:12:34,200 --> 00:12:38,000
can replace Hardware that fails 
without downtime, and, you know,

230
00:12:38,000 --> 00:12:40,300
all of those good things and are
kind of unlocked with 

231
00:12:40,300 --> 00:12:46,600
distributed validators, So from 
a user perspective, if I 

232
00:12:46,600 --> 00:12:53,200
mistake, ER, generally the 
options I have today is I can, I

233
00:12:53,200 --> 00:12:55,600
can either put it into a liquid 
sticking protocol. 

234
00:12:55,600 --> 00:12:59,500
The line item would be the 
biggest of them I could go to a 

235
00:13:00,400 --> 00:13:04,700
specialized validator shop, like
a block demon, of course. 

236
00:13:05,400 --> 00:13:08,400
And I could spend about a P2P 
when I can spin up my evaluators

237
00:13:08,400 --> 00:13:14,300
there, or if I am usually 
technically competent than Then 

238
00:13:14,300 --> 00:13:19,700
I can run my own validator. 
I've actually curious and of in 

239
00:13:19,700 --> 00:13:22,400
these three, three, kinds of 
segments. 

240
00:13:22,400 --> 00:13:25,300
Let's imagine that being liquid 
sticking as one segment. 

241
00:13:25,300 --> 00:13:28,000
The other being the specialized 
validator, that's, like hosting 

242
00:13:28,000 --> 00:13:31,000
validators for you. 
If you have 32, eat third 

243
00:13:31,000 --> 00:13:36,900
segment, being you want to run 
your validators at home, How 

244
00:13:36,900 --> 00:13:40,200
would these three segments, kind
of use this technology? 

245
00:13:41,200 --> 00:13:42,700
And what difference would it 
make for them? 

246
00:13:44,600 --> 00:13:46,300
Yeah, it's a that's a good 
question. 

247
00:13:46,900 --> 00:13:50,400
So I'll talk a little bit about 
like our adoption path. 

248
00:13:50,400 --> 00:13:55,900
So far the earliest adoption of 
oble has been at home 

249
00:13:55,900 --> 00:13:58,400
validators. 
They're the first ones to have 

250
00:13:58,400 --> 00:14:02,900
put it on maenette, we put our 
first ones, you know, I'm a net 

251
00:14:03,000 --> 00:14:07,200
between core team members all 
running at home and now kind of 

252
00:14:07,200 --> 00:14:11,100
the adoption evolution is now 
getting into your hosted person 

253
00:14:11,400 --> 00:14:13,000
and you know your liquid steak 
pool. 

254
00:14:13,200 --> 00:14:17,200
Like what's taking place or kind
of the earliest adopters of the 

255
00:14:17,200 --> 00:14:21,000
idea and supporters of it being 
in their road map? 

256
00:14:21,900 --> 00:14:26,000
So the I'll start with the at 
home validator, which is quite 

257
00:14:26,000 --> 00:14:28,000
interesting. 
So today we got home, validator,

258
00:14:28,000 --> 00:14:31,100
for example, like pushing grunts
grunts one out of his house and 

259
00:14:31,100 --> 00:14:35,600
like, we travel a lot today for 
for, for like purposes of oble. 

260
00:14:36,800 --> 00:14:40,400
And it's always, it's like kind 
of chronically offline. 

261
00:14:40,500 --> 00:14:43,100
It's kind of this thing that you
have to worry about it. 

262
00:14:43,200 --> 00:14:45,700
You can't really have peace of 
mind for being an at-home 

263
00:14:45,700 --> 00:14:48,900
validator today, which is 
something that like DBT can 

264
00:14:48,900 --> 00:14:50,900
unlock for you, right? 
You can have your at home 

265
00:14:50,900 --> 00:14:55,400
machine, you can run backups 
inside of the cloud in an on / 

266
00:14:55,400 --> 00:14:58,800
about way so that you can ensure
you can kind of live your normal

267
00:14:58,800 --> 00:15:01,200
life. 
The other side of the at-home 

268
00:15:01,200 --> 00:15:07,600
validator is Persona type of I 
don't have 30 to eat but I trust

269
00:15:07,600 --> 00:15:10,400
myself to run my own machine and
there's actually like quite a 

270
00:15:10,408 --> 00:15:15,200
lot of those people and they can
You zobel to come together to 

271
00:15:15,200 --> 00:15:18,100
like create their own shared 
validator because they may not 

272
00:15:18,100 --> 00:15:20,400
be interested in taking on the 
risk of the pool. 

273
00:15:20,700 --> 00:15:23,300
And you know, they may not need 
a liquid stake token but they 

274
00:15:23,300 --> 00:15:26,600
don't have 32 week and that's 
kind of the squad staking 

275
00:15:26,600 --> 00:15:30,100
concept which we've seen 
honestly take off quite a bit in

276
00:15:30,100 --> 00:15:33,000
the at-home validator category 
which is you know a whole group 

277
00:15:33,000 --> 00:15:36,000
of people who's like you know 
some of my eat is in a pool. 

278
00:15:36,200 --> 00:15:38,900
The rest of it, I just want to 
run myself but I don't have a 

279
00:15:38,900 --> 00:15:42,600
full validators work which has 
been quite interesting so yeah 

280
00:15:42,600 --> 00:15:43,600
it's peace. 
Mind. 

281
00:15:43,600 --> 00:15:47,000
But then that second user group 
is actually where we think most 

282
00:15:47,000 --> 00:15:51,600
of the tail end adoption for DVT
will be in like 10 to 15 years 

283
00:15:51,600 --> 00:15:54,600
is like enabling just groups of 
people to get together to run 

284
00:15:54,600 --> 00:15:57,400
their own machines and giving 
each other fault tolerance and 

285
00:15:57,400 --> 00:16:01,800
like a human to human manner. 
So yeah, a lot of early adoption

286
00:16:01,800 --> 00:16:04,700
there but the middle adoption of
DBT won't be there in my 

287
00:16:04,700 --> 00:16:05,900
opinion. 
They're like the early 

288
00:16:05,900 --> 00:16:07,600
enthusiasts. 
They're the ones that help set 

289
00:16:07,600 --> 00:16:11,100
us up our primary duty is to 
figure out how to give you at 

290
00:16:11,100 --> 00:16:13,000
home. 
Validator more tools to get more

291
00:16:13,100 --> 00:16:16,800
Them online. 
And now we're bridging more into

292
00:16:16,900 --> 00:16:19,200
the hosted and like liquids 
taking full category. 

293
00:16:19,200 --> 00:16:22,000
So now I'll get into those two 
different types of users and you

294
00:16:22,008 --> 00:16:26,100
know why it's beneficial for 
them for your liquid staking 

295
00:16:26,100 --> 00:16:29,200
pool. 
It is actually the most 

296
00:16:29,200 --> 00:16:33,800
Innovative use case of DBT today
because most of the pools are 

297
00:16:33,800 --> 00:16:38,400
using it for its Byzantine 
properties which is quite cool. 

298
00:16:38,400 --> 00:16:41,900
So the example I like to give is
let's just, you know, use a 

299
00:16:41,900 --> 00:16:44,800
hypothetical liquid state. 
Pool today, there's 10 

300
00:16:44,800 --> 00:16:47,600
validators inside of this 
liquid, staking pool, all of 

301
00:16:47,600 --> 00:16:52,500
them are supplying their own, 
you know, keys to the system 

302
00:16:52,500 --> 00:16:55,600
keys that they create keys that 
they manage and keys that they 

303
00:16:55,600 --> 00:16:59,200
run on their machines again, in 
a very monolithic environment. 

304
00:16:59,200 --> 00:17:02,800
And the reality is, is that 
like, in each in this liquid, 

305
00:17:02,800 --> 00:17:04,900
like this hypothetical liquid 
staking pool, each of those, 

306
00:17:04,900 --> 00:17:07,200
validators would have like a 
certain amount of steak that 

307
00:17:07,200 --> 00:17:12,200
they're responsible for, and 
that person can actually self /.

308
00:17:12,400 --> 00:17:15,099
They can be You know, they can 
sabotage, they can act 

309
00:17:15,099 --> 00:17:17,099
malicious, they can't take the 
phones, right? 

310
00:17:17,099 --> 00:17:19,800
But they can shut the machines 
off, and they can like bring 

311
00:17:19,800 --> 00:17:23,900
penalty to the greater pool. 
If you will, when most of these 

312
00:17:23,900 --> 00:17:27,400
pools you social economic, so it
does mean that like it could 

313
00:17:27,400 --> 00:17:31,100
take, you know, it'll hurt every
single participant in the pool. 

314
00:17:31,700 --> 00:17:34,700
If one of these validators 
defects and it doesn't even need

315
00:17:34,700 --> 00:17:36,800
to be malicious, right? 
It could also be a bad day at 

316
00:17:36,800 --> 00:17:40,000
the office where like, you know,
all your servers crash and 

317
00:17:40,000 --> 00:17:43,000
everything goes down or it could
even be catastrophic. 

318
00:17:43,200 --> 00:17:44,700
Right? 
Like you have a rogue employee 

319
00:17:44,700 --> 00:17:47,800
who steals the keys and, you 
know, there's a variety of 

320
00:17:47,800 --> 00:17:50,700
different things that can happen
inside of that, construct. 

321
00:17:50,900 --> 00:17:54,800
So when DBT enables is that, 
that group of 10 people can, now

322
00:17:54,800 --> 00:17:58,700
just share one validator, which 
like creates this whole new 

323
00:17:58,800 --> 00:18:02,600
defect in Game Theory between 
the different operators in that 

324
00:18:02,600 --> 00:18:05,500
cluster. 
It gives fault tolerance and it 

325
00:18:05,500 --> 00:18:07,900
makes it essentially, I hate to 
use the word impossible but it 

326
00:18:07,908 --> 00:18:12,700
makes it very, very difficult 
for 81 validator in that group 

327
00:18:12,700 --> 00:18:14,300
to do. 
Do anything malicious or 

328
00:18:14,300 --> 00:18:18,200
defective to that pool. 
So that again like its 

329
00:18:18,200 --> 00:18:21,600
availability and slashing 
protection, reasons and 

330
00:18:21,600 --> 00:18:24,700
utilizing it for the fact that 
there's a consensus mechanism 

331
00:18:25,400 --> 00:18:27,500
and it prevents Byzantine 
Behavior. 

332
00:18:27,900 --> 00:18:31,000
So it's one of its true, you 
know, corporate motives the 

333
00:18:31,000 --> 00:18:34,800
other reasons that they're using
it as not only for that but 

334
00:18:34,800 --> 00:18:37,700
they're using it as well to 
decentralize their validator 

335
00:18:37,700 --> 00:18:39,700
set. 
So if you're going to build a 

336
00:18:39,708 --> 00:18:43,000
liquid, staking pool that wants 
to be very decentralized, then. 

337
00:18:43,200 --> 00:18:47,900
You're going to have to invite, 
call it middle to lower to sub. 

338
00:18:47,900 --> 00:18:51,000
Tear validators to like 
decentralize the validator set 

339
00:18:51,000 --> 00:18:54,300
over time, and you need to do. 
So, in a way that protects the 

340
00:18:54,300 --> 00:18:56,600
pool, especially if it's an 
existing pool. 

341
00:18:57,400 --> 00:19:00,200
And most of the pools today, 
like my granny DBT, our existing

342
00:19:00,200 --> 00:19:03,100
tools and there's lots of money 
inside of all the fun, right? 

343
00:19:03,500 --> 00:19:06,000
So, if you are going to let new 
validators in, you need to let 

344
00:19:06,000 --> 00:19:09,600
them enter the pool in a manner.
That does it hurt the pool and 

345
00:19:09,600 --> 00:19:12,500
DBT is a great way to do that 
because you can just build some 

346
00:19:12,500 --> 00:19:14,700
shared values. 
Alligators, you can partner, you

347
00:19:14,700 --> 00:19:18,400
know, three highly proficient 
people with one newcomer and 

348
00:19:18,400 --> 00:19:20,700
then, you know, you have some 
fault tolerance. 

349
00:19:20,700 --> 00:19:24,500
There's some give there if they 
make an error Without Really 

350
00:19:24,500 --> 00:19:27,600
harming the pool. 
So yeah, the decentralization of

351
00:19:27,600 --> 00:19:30,800
the validator said is also a 
very interesting one for pools 

352
00:19:30,800 --> 00:19:34,700
and the use of it for its 
Byzantine properties your 

353
00:19:34,700 --> 00:19:37,000
hosted. 
Service provider is actually 

354
00:19:37,000 --> 00:19:42,200
someone that we thought would 
come later in the adoption 

355
00:19:42,200 --> 00:19:44,900
cycle. 
However, they've come in quite 

356
00:19:44,900 --> 00:19:50,100
quickly and it's a factor to do 
with the centralized staking 

357
00:19:50,100 --> 00:19:53,100
product or the hosted product is
was the first product in the 

358
00:19:53,100 --> 00:19:55,900
industry. 
It's been competitive for a 

359
00:19:55,908 --> 00:19:59,800
number of years now, it's like 
entering it's fairly normal 

360
00:19:59,800 --> 00:20:03,600
maturation, cycle of compressed 
margins and increase costs. 

361
00:20:04,100 --> 00:20:08,100
And now those products like need
to mature themselves in a way 

362
00:20:08,100 --> 00:20:11,300
where they decrease their costs,
but they improve their security 

363
00:20:11,700 --> 00:20:16,400
as being a centralized for Vidor
like requires saw to Sock one 

364
00:20:16,400 --> 00:20:18,500
compliance. 
These things help to kind of 

365
00:20:18,500 --> 00:20:21,700
institutionalize yourself. 
And most of these people have to

366
00:20:21,700 --> 00:20:26,200
offer some type of off chain 
Insurance mechanism, which is 

367
00:20:26,200 --> 00:20:29,000
quite costly to do, or you just 
have to be pretty well, you 

368
00:20:29,000 --> 00:20:32,100
know, bankrolled. 
So, for these users, their 

369
00:20:32,200 --> 00:20:36,500
maturation and growth is meeting
DBT, kind of in the middle and 

370
00:20:36,500 --> 00:20:39,700
they're experimenting with it to
help scale their operations in a

371
00:20:39,708 --> 00:20:43,200
way, where they can decrease the
amount of machines, they Need 

372
00:20:43,200 --> 00:20:46,100
for a certain amount of each 
while also, increasing the 

373
00:20:46,100 --> 00:20:51,500
security profile of that setup. 
We've seen a lot of interesting 

374
00:20:51,500 --> 00:20:56,300
things recently in the insurance
and reinsurance topic around DBT

375
00:20:56,900 --> 00:21:01,000
offerings, taking insurance has 
been difficult historically 

376
00:21:01,000 --> 00:21:03,900
because, you know, the 
definition of a bad day at the 

377
00:21:03,900 --> 00:21:07,700
office is losing all your Easter
potentially, but that was just 

378
00:21:07,700 --> 00:21:10,600
at the beginning. 
And now, we're as a community 

379
00:21:10,600 --> 00:21:12,900
DBT, being one of those 
Technologies building things, 

380
00:21:13,000 --> 00:21:16,200
Like alleviate worst case 
scenario of like you know losing

381
00:21:16,200 --> 00:21:19,100
all your needs. 
So insurance providers have been

382
00:21:19,100 --> 00:21:24,700
interested in kind of including 
DDT into their criteria of 

383
00:21:24,700 --> 00:21:29,200
providing Insurance because it 
gives them more assurance that 

384
00:21:29,200 --> 00:21:31,300
like, you know, you can't lose 
all of it. 

385
00:21:31,300 --> 00:21:33,300
It's not an absolute loss 
situation. 

386
00:21:33,300 --> 00:21:35,200
So you know. 
No insurers. 

387
00:21:35,200 --> 00:21:38,800
Going to ensure something that's
an absolute law situation and 

388
00:21:38,800 --> 00:21:41,000
Technologies. 
Like DVT have now come in and 

389
00:21:41,000 --> 00:21:42,900
helps like alleviate that so 
yeah. 

390
00:21:43,100 --> 00:21:47,000
The Three core user groups. 
I think the fourth one I'll 

391
00:21:47,000 --> 00:21:53,700
mention is kind of defy and how 
defy has thought about using 

392
00:21:53,700 --> 00:21:56,400
DDT. 
So like in most D5 projects 

393
00:21:56,400 --> 00:21:59,100
today, you're like taking an 
asset in your wrapping it or 

394
00:21:59,100 --> 00:22:01,500
you're taking a collection of 
assets and you're pulling them 

395
00:22:01,500 --> 00:22:05,300
together and you may produce a 
stable coin from it, right? 

396
00:22:05,300 --> 00:22:09,200
Or you may produce other streams
of yield or income off of a 

397
00:22:09,200 --> 00:22:12,300
collection of tokens, the 
collection of tokens that people

398
00:22:12,300 --> 00:22:14,600
are using today. 
They are LST tokens like would 

399
00:22:14,600 --> 00:22:18,000
stake tokens and they're doing a
variety of different things with

400
00:22:18,000 --> 00:22:21,100
them. 
Those products since there's a 

401
00:22:21,100 --> 00:22:24,000
product built on top of it, it's
better for those products at 

402
00:22:24,000 --> 00:22:26,800
those liquid state tokens RSD 
wrist as possible. 

403
00:22:26,800 --> 00:22:30,900
And now, people are looking at 
what is their risk criteria and 

404
00:22:30,900 --> 00:22:33,900
mostly they haven't been looked 
at the only risk criteria that 

405
00:22:33,900 --> 00:22:37,500
an LST token has been looked at 
to date is liquidity because 

406
00:22:37,500 --> 00:22:39,000
that was the biggest risk. 
Right? 

407
00:22:39,000 --> 00:22:41,700
How liquid is this thing? 
Like, what does that look like? 

408
00:22:41,700 --> 00:22:44,800
But but now it's more Or less 
like okay, what are the 

409
00:22:44,800 --> 00:22:49,200
potential penalisation 
properties of these lsts and 

410
00:22:49,200 --> 00:22:51,400
under the hood? 
Like what types of security 

411
00:22:51,400 --> 00:22:53,800
protocols and parameters? 
Are they using for it? 

412
00:22:54,200 --> 00:22:58,100
So now we've seen D5 who has 
like its own interpretation of 

413
00:22:58,100 --> 00:22:59,100
bris. 
Honestly. 

414
00:22:59,100 --> 00:23:02,400
Probably a more mature 
interpretation of Chris than the

415
00:23:02,400 --> 00:23:05,800
validating community. 
And now DBT is kind of come into

416
00:23:05,800 --> 00:23:10,000
their Spectrum over the past, 
call it month or two, which has 

417
00:23:10,000 --> 00:23:12,900
been very interesting for them 
to want to include. 

418
00:23:13,000 --> 00:23:15,800
Glued it in their ecosystem and 
to learn more about it. 

419
00:23:17,600 --> 00:23:23,800
One of the downsides of a DVD 
like setup is that it adds extra

420
00:23:23,800 --> 00:23:26,500
cost. 
Meaning you know what's the 

421
00:23:26,800 --> 00:23:28,800
what's the other case? 
Let's say you have a hosted 

422
00:23:28,800 --> 00:23:35,100
service provider and they're 
running a validator on some some

423
00:23:35,100 --> 00:23:39,900
Cloud probably Amazon or Google 
and they have an engineer there 

424
00:23:39,900 --> 00:23:43,700
for up time and they're running 
it on a single machine. 

425
00:23:44,500 --> 00:23:48,400
They won't have 100% uptime, but
they will get to somewhere 

426
00:23:48,500 --> 00:23:52,300
higher than 99% of time just on 
on on that sector. 

427
00:23:52,800 --> 00:23:57,800
Now, when a, when a DVD set up 
comes into the picture, you're 

428
00:23:57,800 --> 00:24:01,400
running like three or four 
machines and usually spread 

429
00:24:01,400 --> 00:24:05,400
across different parties and 
you're also adding some kind of 

430
00:24:05,700 --> 00:24:08,200
key setup and key tear down 
cost, right? 

431
00:24:08,200 --> 00:24:11,800
Like, probably the setup of 
these systems will need some 

432
00:24:11,800 --> 00:24:15,100
extra extra work. 
It's one of these cases where 

433
00:24:15,100 --> 00:24:20,500
you are adding fault tolerance, 
but you're adding cost. 

434
00:24:21,100 --> 00:24:25,000
And sometimes the custard 
customer cannot perceive the 

435
00:24:25,000 --> 00:24:28,100
extra fault tolerance meaning 
that they will go to some kind 

436
00:24:28,100 --> 00:24:31,500
of log explorer that will say, 
hey what are the returns of the 

437
00:24:31,500 --> 00:24:34,700
validators and the evaluator, 
with 99 up percent of time 

438
00:24:34,700 --> 00:24:38,700
running on one machine, they 
return will be X and then they 

439
00:24:38,708 --> 00:24:43,600
will see the DVD set up and it 
might be marginally better like 

440
00:24:43,600 --> 00:24:47,400
X Plus in 0.1 percent or point 
zero five percent. 

441
00:24:47,900 --> 00:24:51,700
How do you have a dress that 
address that At issue. 

442
00:24:51,800 --> 00:24:56,000
And do you see that issue in in 
practice? 

443
00:24:56,000 --> 00:25:02,000
And what does it mean for the 
different parties and you might 

444
00:25:02,000 --> 00:25:07,100
end up DVD? 
I love this question because it 

445
00:25:07,100 --> 00:25:09,700
actually pushed back a little on
increasing cost. 

446
00:25:09,700 --> 00:25:11,500
You're writing that increases 
Hardware. 

447
00:25:11,800 --> 00:25:14,100
But depending on what people 
have done before hand, it 

448
00:25:14,100 --> 00:25:18,100
doesn't necessarily increase 
their cost and what I'm kind of 

449
00:25:18,100 --> 00:25:19,600
getting at you. 
Kind of talked about it in the 

450
00:25:19,600 --> 00:25:24,400
cloud is originally without 
distributed validators and the 

451
00:25:24,400 --> 00:25:26,500
real problem was that there was 
more or less. 

452
00:25:26,500 --> 00:25:29,900
No safe way to run a backup and 
the only kind of option. 

453
00:25:29,900 --> 00:25:32,800
You had was do some sort of 
monitoring game and pray that 

454
00:25:32,800 --> 00:25:35,400
you're monitoring is you know, a
perfectly reliable. 

455
00:25:35,400 --> 00:25:38,100
And there's not a scenario where
you turn onto machines the same 

456
00:25:38,100 --> 00:25:42,900
private key at the same time and
and the problem would not be 

457
00:25:42,900 --> 00:25:46,500
able to run a backup. 
Is it can be very hard to 

458
00:25:46,500 --> 00:25:49,600
recover from a failure and 
particularly if you want to use 

459
00:25:49,600 --> 00:25:52,800
something like a bare metal 
machine and like a data center 

460
00:25:52,800 --> 00:25:56,600
somewhere, that's usually one of
the more low-cost ways to run a 

461
00:25:56,600 --> 00:25:59,800
server. 
And the problem is, if you do 

462
00:25:59,800 --> 00:26:02,900
put, you know, particularly 
large amount of private keys on 

463
00:26:02,900 --> 00:26:05,600
a bare metal server, like that, 
and it just goes, Flying which 

464
00:26:05,600 --> 00:26:08,100
is regular occurrence of 
probably happen at least once or

465
00:26:08,100 --> 00:26:11,200
twice a year and you just kind 
of have to sit in your hands 

466
00:26:11,400 --> 00:26:14,200
there's more or less nothing. 
Say if he can do at that point 

467
00:26:14,200 --> 00:26:16,900
well you can try and bring up a 
backup and hope to shut down the

468
00:26:16,900 --> 00:26:18,600
back up before the primary comes
back. 

469
00:26:18,600 --> 00:26:21,500
Or you can bring up the data 
center and ask them to kind of 

470
00:26:21,600 --> 00:26:23,200
go and like pull the plug out of
the wall. 

471
00:26:23,700 --> 00:26:27,700
And but this not being able to 
like run a backup and has 

472
00:26:27,700 --> 00:26:29,600
changed a lot how people have, 
you know, build their 

473
00:26:29,600 --> 00:26:33,500
architectures in the early years
and most of these centralized I 

474
00:26:33,500 --> 00:26:36,000
say Moses not quite true. 
Lot of centralized providers at 

475
00:26:36,000 --> 00:26:39,500
least started running in the 
cloud and particularly because 

476
00:26:39,500 --> 00:26:42,600
then, if you do have a failure 
of machine, you can kind of 

477
00:26:42,700 --> 00:26:45,400
detach the disk, you know, it's 
all in software, you've a lot of

478
00:26:45,400 --> 00:26:48,400
power to kind of actually 
recover things that you don't 

479
00:26:48,400 --> 00:26:50,800
have when it's just a server 
sitting somewhere. 

480
00:26:51,400 --> 00:26:54,000
And but the problem with that 
and you kind of alluded to the 

481
00:26:54,000 --> 00:26:55,400
fact that they might run one 
machine. 

482
00:26:55,600 --> 00:26:59,100
A lot of people, they'll have at
least a few servers in the 

483
00:26:59,100 --> 00:27:00,600
cloud. 
Normally they'll have kind of, 

484
00:27:00,900 --> 00:27:04,400
at least two, the runs going to 
Els and ciel's and which is kind

485
00:27:04,400 --> 00:27:06,800
of the Meat of it, then they'll 
have a machine with their 

486
00:27:06,800 --> 00:27:10,900
validator on it and plausibly, 
they'll have some more with key 

487
00:27:10,900 --> 00:27:15,300
manager on it as well. 
So a lot of people like kind of 

488
00:27:15,300 --> 00:27:20,000
Enterprise taking validate. 
If you talking kind of 327 Cloud

489
00:27:20,000 --> 00:27:24,000
servers and Cloud Server, the 
much more expensive than a bare 

490
00:27:24,000 --> 00:27:26,700
metal server. 
Rule of thumb, think about 10x 

491
00:27:26,700 --> 00:27:30,600
more, including one of the real 
kickers is bandwidth costs which

492
00:27:30,600 --> 00:27:33,600
I'm sure you guys are familiar 
with egress but that can often 

493
00:27:33,600 --> 00:27:37,400
take up Scent of the kind of 
operating cost of a cloud 

494
00:27:37,400 --> 00:27:41,200
validator. 
So you start to pile on egress 

495
00:27:41,200 --> 00:27:43,400
multiple cloud machines and so 
on. 

496
00:27:43,400 --> 00:27:46,100
And it really starts to end up 
kind of costly. 

497
00:27:46,900 --> 00:27:50,800
And that's kind of where we one 
way to have, you know, high 

498
00:27:50,800 --> 00:27:53,400
uptime without distributed 
validators is to kind of put it 

499
00:27:53,400 --> 00:27:56,300
all in the cloud have a bit of 
failover and do things that way.

500
00:27:56,700 --> 00:27:59,800
The other option that some roots
go down, is they kind of do the 

501
00:27:59,800 --> 00:28:03,700
hardware route where they'll buy
a particular server that has 

502
00:28:04,000 --> 00:28:06,500
Jewel. 
CBS, Sockets live two CPUs. 

503
00:28:06,500 --> 00:28:10,000
They have a raid array of disks.
So if you want disk fails or 

504
00:28:10,000 --> 00:28:12,600
problem that have dual 
networking cards, so, you know, 

505
00:28:12,600 --> 00:28:15,400
if there's problems there, 
they'll survive, maybe grps use.

506
00:28:15,700 --> 00:28:19,700
But these PCS cost in the tens 
of thousands of dollars and 

507
00:28:19,700 --> 00:28:23,500
they're not particularly cheap. 
So either, you know, trying to 

508
00:28:23,508 --> 00:28:27,200
get kind of fault tolerance by 
using cloud services or fault 

509
00:28:27,200 --> 00:28:29,000
tolerance by using really 
expensive Hardware. 

510
00:28:29,500 --> 00:28:33,000
Both of these are, you know, not
the cheapest expect a lot of, 

511
00:28:33,200 --> 00:28:35,700
you know, some of these tax, if 
you're running. 7 machines in 

512
00:28:35,700 --> 00:28:37,900
the cloud, you wouldn't feel 
spending a couple thousand, 

513
00:28:37,900 --> 00:28:40,600
maybe three, four thousand a 
month, for something like that. 

514
00:28:41,300 --> 00:28:46,100
And if you then have distributed
validators and and you can have 

515
00:28:46,100 --> 00:28:49,500
private Keys like split into 
groups, it opens up the ability 

516
00:28:49,500 --> 00:28:52,800
to more safely put validators on
bare metal machines. 

517
00:28:53,000 --> 00:28:56,100
Because if one of your four 
machines dies, no big problem. 

518
00:28:56,100 --> 00:28:58,400
It will stay online. 
You can kind of wait for it to 

519
00:28:58,400 --> 00:28:59,900
come back. 
If it doesn't come back, you can

520
00:29:00,200 --> 00:29:02,600
bring up another, you know, 
partial on another note. 

521
00:29:02,600 --> 00:29:04,700
It's not going to cause a 
slashing, it doesn't have a 

522
00:29:04,700 --> 00:29:05,800
phone. 
Key on its own. 

523
00:29:06,100 --> 00:29:08,300
All of these machines are doing 
consensus beforehand. 

524
00:29:09,000 --> 00:29:12,200
So kind of what we talked, a lot
of the centralized providers 

525
00:29:12,200 --> 00:29:14,500
that are like, how could you 
know distributed validate is 

526
00:29:14,500 --> 00:29:18,000
possibly not increase my cost 
and we tell them that, you know,

527
00:29:18,000 --> 00:29:22,400
with software fault tolerance 
you can move away from like 

528
00:29:22,400 --> 00:29:25,800
cloud-based Solutions. 
You can move away from having 

529
00:29:25,800 --> 00:29:29,300
like extremely, you know, fancy 
Hardware, based Solutions / up 

530
00:29:29,300 --> 00:29:30,900
time. 
And instead, you can move 

531
00:29:30,900 --> 00:29:34,700
towards commodity bare, metal, 
and use just fault tolerance to 

532
00:29:34,900 --> 00:29:36,900
Do it. 
So instead of having, you know, 

533
00:29:37,400 --> 00:29:41,400
4274 on the books and month 
nodes that run in the cloud, you

534
00:29:41,400 --> 00:29:43,300
can have, you know, a hundred 
dollar month bare, metal 

535
00:29:43,300 --> 00:29:46,300
machines, and your full stack 
and cost 400 a month instead of 

536
00:29:46,300 --> 00:29:49,700
4K a month. 
And yeah the last kicker that 

537
00:29:49,700 --> 00:29:51,400
is, can you do it at scale with 
high load? 

538
00:29:51,400 --> 00:29:53,700
We're doing running a lot of 
good test in that regard. 

539
00:29:53,700 --> 00:29:56,800
Seeing if we can do this at like
you know, thousands of keys as 

540
00:29:56,800 --> 00:30:01,300
well to improve margins but 
yeah, naively in the scenario. 

541
00:30:01,300 --> 00:30:04,700
Yes, you running more than one 
note but bear the homestake or 

542
00:30:04,900 --> 00:30:08,400
Most Enterprises most you know, 
operators within the ESPYs, 

543
00:30:08,600 --> 00:30:10,100
they're not running a single 
machine. 

544
00:30:10,100 --> 00:30:12,000
Unless they're, you know, doing 
something with very fancy 

545
00:30:12,000 --> 00:30:13,500
Hardware. 
They're probably running at 

546
00:30:13,500 --> 00:30:16,800
least a few machines. 
So distributed validators and 

547
00:30:16,800 --> 00:30:19,100
having fault tolerance allows 
them to kind of. 

548
00:30:19,300 --> 00:30:22,500
Yeah, use cheaper servers less, 
you know, not over pretty 

549
00:30:22,500 --> 00:30:25,600
over-provision them as much. 
And we are reasonably 

550
00:30:25,600 --> 00:30:27,100
comfortable, buyer. 
You know, the people that are 

551
00:30:27,100 --> 00:30:30,100
already running on bare metal. 
Have a very low cost basis to 

552
00:30:30,100 --> 00:30:32,400
the very large amount of 
validator operators at least 

553
00:30:32,400 --> 00:30:34,700
speak to that DVT actually will 
at them. 

554
00:30:34,800 --> 00:30:36,300
Reduce the costs. 
Even if they are running more 

555
00:30:36,300 --> 00:30:42,100
Hardware, I think your question 
mayor's, well kind of present 

556
00:30:42,100 --> 00:30:47,500
the this cell of DVT, you know 
today because look at the end of

557
00:30:47,500 --> 00:30:50,900
the day, it's a security 
protocol, it's not a yield 

558
00:30:50,900 --> 00:30:54,400
protocol which is like, what 
everyone wants everything to be,

559
00:30:54,500 --> 00:30:56,600
right. 
Everyone wants to hear, like I'm

560
00:30:56,600 --> 00:30:59,600
not using your thing, unless it 
makes me more money, right? 

561
00:31:00,600 --> 00:31:03,400
And like, for us the fact of the
matter is, is that it's a 

562
00:31:03,408 --> 00:31:07,300
security protocol today, and 
maybe there is ways that it can 

563
00:31:07,300 --> 00:31:10,900
get a validator Become more 
profitable, but it's not this 

564
00:31:10,900 --> 00:31:13,500
Lottery mechanism that you 
download onto your node. 

565
00:31:13,500 --> 00:31:16,800
And then one day, you see, 200 
each sitting in your account. 

566
00:31:16,800 --> 00:31:21,600
It's not one of those things. 
So getting people to adopt it, 

567
00:31:21,700 --> 00:31:26,400
yes has taken quite some time 
but there's a reason for that 

568
00:31:26,400 --> 00:31:28,400
because it is a security 
protocol. 

569
00:31:28,400 --> 00:31:34,300
So it's supposed to give you 
other things that benefit you in

570
00:31:34,300 --> 00:31:36,600
the event, that there's an 
increased cost for it. 

571
00:31:36,700 --> 00:31:39,500
However, we think too. 
Oceans points. 

572
00:31:40,800 --> 00:31:45,400
It's not only a benefit to them 
on the security front, but it 

573
00:31:45,400 --> 00:31:48,900
will actually probably save them
money on a relative basis today.

574
00:31:49,300 --> 00:31:52,700
And then in the future time 
periods up to us to kind of 

575
00:31:52,900 --> 00:31:57,200
standardized DBT as a 
configuration. 

576
00:31:58,000 --> 00:32:00,900
And what we like to use 
internally is that we've been 

577
00:32:00,900 --> 00:32:04,800
calling this like the old bull 
inside strategy like similar to 

578
00:32:04,800 --> 00:32:07,700
in tow right? 
Like what intel was able to do 

579
00:32:07,700 --> 00:32:09,500
so I basically Really 
standardized. 

580
00:32:09,500 --> 00:32:13,000
It's the inclusion of their chip
into like everything and then 

581
00:32:13,000 --> 00:32:16,600
the machines in the software and
everyone else you know where the

582
00:32:16,600 --> 00:32:20,900
competitive market we think 
getting like oval on the inside 

583
00:32:20,900 --> 00:32:23,500
of these things is far more 
where it's it's because it's a 

584
00:32:23,508 --> 00:32:26,300
security protocol. 
So like how do you position a 

585
00:32:26,300 --> 00:32:30,500
security protocol in a Time? 
Wondering a bear Market into an 

586
00:32:30,500 --> 00:32:33,100
industry where like, you know, 
everyone's looking for yield. 

587
00:32:35,100 --> 00:32:38,300
Right there amazing I think yeah
we talked about a little bit now

588
00:32:38,300 --> 00:32:40,300
the sort of cost from the 
operator side. 

589
00:32:40,300 --> 00:32:44,900
I guess there's also double as 
this middleware that obviously 

590
00:32:44,900 --> 00:32:47,000
you guys are developing. 
You spending a lot of resources 

591
00:32:47,000 --> 00:32:50,100
on developing this and you also 
raised money. 

592
00:32:50,600 --> 00:32:54,100
So there's also like expectation
obviously of this having some 

593
00:32:54,100 --> 00:32:58,000
sort of business model, maybe if
whatever you can share in terms 

594
00:32:58,000 --> 00:33:02,900
of like how do you imagine like 
sort of oble to be adopted? 

595
00:33:02,900 --> 00:33:08,100
Is it like The Operators that 
would pay Pay to run or ball is 

596
00:33:08,100 --> 00:33:12,000
there like some other models 
that you've thought of to 

597
00:33:12,000 --> 00:33:16,900
utilize or yes. 
Yeah, it's a good question. 

598
00:33:16,900 --> 00:33:21,900
So I'll tell a little story here
and have been fortunate enough 

599
00:33:21,900 --> 00:33:26,100
to observe like how they eat 1 
and E 2 client teams like were 

600
00:33:26,100 --> 00:33:30,200
developed and hardened and 
staffed and funded. 

601
00:33:30,800 --> 00:33:34,700
And that's really kind of like 
the core of like how middleware 

602
00:33:34,900 --> 00:33:38,000
Is and oboe and others. 
You know, what types of monetary

603
00:33:38,000 --> 00:33:40,800
streams, they'll be able to, 
like, take on and work with. 

604
00:33:41,200 --> 00:33:44,400
So, like the early Foundation of
etherium was, you know, there's 

605
00:33:44,400 --> 00:33:47,200
five client teams. 
I think maybe six actually on 

606
00:33:47,200 --> 00:33:52,600
the, on the POS side and then I 
think maybe three or four on one

607
00:33:52,600 --> 00:33:54,600
side. 
But anyways, these are all kind 

608
00:33:54,600 --> 00:33:56,400
of, you know, privately 
bankrolled. 

609
00:33:56,400 --> 00:33:59,700
Now they're well funded. 
It took years to get to this. 

610
00:33:59,700 --> 00:34:02,300
They were funded by the es or 
other like, you know, large 

611
00:34:02,300 --> 00:34:06,500
donors and that software. 
Is free forever, right? 

612
00:34:06,500 --> 00:34:10,500
So it's virally free. 
It's the primary network access 

613
00:34:10,500 --> 00:34:15,300
to the etherium network. 
It has basic functionality, but 

614
00:34:15,300 --> 00:34:18,199
it's going to be free forever. 
And now like, you know, Danny 

615
00:34:18,199 --> 00:34:21,800
Ryan uses the words, like, 
ossification and crystallization

616
00:34:21,800 --> 00:34:25,699
and really what that means, is 
that, like, the amount of 

617
00:34:25,699 --> 00:34:29,100
innovation that takes place at 
that core client, level, and 

618
00:34:29,100 --> 00:34:34,199
funding is going to lessen and 
lesson over time and new 

619
00:34:34,199 --> 00:34:37,199
innovative. 
Space needs to be opened 

620
00:34:37,199 --> 00:34:39,900
elsewhere. 
And now the new in effect like 

621
00:34:39,900 --> 00:34:42,900
the new Innovative space that's 
being opened elsewhere, it is 

622
00:34:42,900 --> 00:34:44,699
being enabled in this middleware
layer. 

623
00:34:45,199 --> 00:34:48,300
So now we have this whole new 
middleware market where they'll 

624
00:34:48,300 --> 00:34:51,500
be a variety of different 
protocols who are coming to add 

625
00:34:51,500 --> 00:34:56,900
complimentary software to the 
core etherium stack and that 

626
00:34:56,900 --> 00:35:02,000
middleware layer today. 
Has private funding but tomorrow

627
00:35:02,000 --> 00:35:04,600
cannot have private funding 
forever. 

628
00:35:05,000 --> 00:35:07,200
Right. 
There's like there has to be a 

629
00:35:07,200 --> 00:35:09,500
way for these middleware 
protocols to maintain 

630
00:35:09,500 --> 00:35:14,600
themselves, but also continued 
the eat those of giving back and

631
00:35:14,600 --> 00:35:19,000
having regenerative economics. 
So today we think that optimism 

632
00:35:19,000 --> 00:35:22,200
has taken that responsibility. 
It is a responsibility at the 

633
00:35:22,200 --> 00:35:24,100
end of the day. 
If you're building at this level

634
00:35:24,400 --> 00:35:27,500
is to try to figure out how you 
can make circular economics, 

635
00:35:27,500 --> 00:35:30,100
some sort. 
So, the way that optimism has 

636
00:35:30,100 --> 00:35:33,300
like built their Network and 
started to ecosystem, having a 

637
00:35:33,300 --> 00:35:37,900
fee, which comes And it is then 
donated retroactively as a 

638
00:35:37,908 --> 00:35:42,100
community to other projects that
support, the core aetherium 

639
00:35:42,100 --> 00:35:44,800
staking stag. 
So this is, you know, people 

640
00:35:44,800 --> 00:35:47,700
like a protocol Guild. 
These are people like eat steak 

641
00:35:47,700 --> 00:35:50,900
or this is get coin. 
There's a variety of varieties 

642
00:35:50,900 --> 00:35:54,800
like projects that require 
funding to maintain themselves 

643
00:35:54,800 --> 00:35:58,900
on a different level of being 
open source, a noble and DBT. 

644
00:35:58,900 --> 00:36:01,000
Sits at this new low enough 
layer. 

645
00:36:01,000 --> 00:36:03,800
That, like, we believe it's our 
responsibility to utilize 

646
00:36:03,800 --> 00:36:07,300
retroactive public. 
Goods in some sort of way, is 

647
00:36:07,300 --> 00:36:11,300
the primary way that we start 
the economic machine where it 

648
00:36:11,300 --> 00:36:13,900
goes after that, you know, is to
be determined. 

649
00:36:15,100 --> 00:36:19,400
But there's a way for us to kind
of use that economic model with 

650
00:36:19,400 --> 00:36:22,800
every validator type, which is 
also the important thing that 

651
00:36:22,800 --> 00:36:25,800
economic model works with your 
at-home validated, the economic 

652
00:36:25,800 --> 00:36:27,600
model works with your hosted 
person. 

653
00:36:27,600 --> 00:36:30,200
And it also works with your 
liquid staking pool and what 

654
00:36:30,200 --> 00:36:33,500
other other future, you know, 
topic or use case that comes 

655
00:36:33,500 --> 00:36:35,300
about, so yeah. 
Hi today. 

656
00:36:35,300 --> 00:36:38,300
We're most focused on what is 
the version of retroactive 

657
00:36:38,300 --> 00:36:39,900
public goods? 
That works for opal? 

658
00:36:40,800 --> 00:36:43,000
Right now, we're just like 
learning and figuring this out 

659
00:36:43,000 --> 00:36:44,900
through this maenette adoption 
time. 

660
00:36:44,900 --> 00:36:47,000
Period. 
You know, all those totally free

661
00:36:47,000 --> 00:36:49,800
today, dvts, completely free, 
you can go and, you know, play 

662
00:36:49,800 --> 00:36:53,300
with it, do whatever you want. 
But like tomorrow, how do we 

663
00:36:53,300 --> 00:36:55,900
Bridge into? 
Like a circular economic system?

664
00:36:56,700 --> 00:36:58,100
And that's our biggest Focus 
today. 

665
00:36:59,900 --> 00:37:05,000
I'm I'm actually curious if if 
you think the ideal place to 

666
00:37:05,000 --> 00:37:09,100
house this kind of middleware 
Stack, I mean, the 

667
00:37:09,100 --> 00:37:11,900
specifications of it might be 
actually something like the 

668
00:37:11,900 --> 00:37:18,600
etherium foundation itself and 
then the client teams actually 

669
00:37:18,600 --> 00:37:23,100
implement this middleware as 
part of their, as part of their 

670
00:37:23,100 --> 00:37:28,300
code bases. 
Yeah, so this is, this is ABO be

671
00:37:28,300 --> 00:37:31,300
too. 
Today, we are on our roadmap to 

672
00:37:31,300 --> 00:37:35,900
be one at the moment, we're 
about 60, 70 % to be one, but 

673
00:37:35,900 --> 00:37:40,000
we've been working on a parallel
work stream, which is OB to and 

674
00:37:40,000 --> 00:37:45,400
all will be to like further 
protocol lies DVT by turning it 

675
00:37:45,400 --> 00:37:49,400
into a specification. 
So we actually partnered with 

676
00:37:49,400 --> 00:37:52,900
never mind for them. 
To be the second core 

677
00:37:52,900 --> 00:37:54,900
development team for the oval 
Network. 

678
00:37:55,600 --> 00:37:58,800
And they will be leading in 
partnering with the oboe Labs. 

679
00:37:58,800 --> 00:38:01,800
Current core development team 
for the oval Network to work on 

680
00:38:01,800 --> 00:38:06,900
the research and specification 
of the Ogilvy to protocol and we

681
00:38:06,900 --> 00:38:10,100
are pushing towards a spectrum 
and environment where we hope to

682
00:38:10,100 --> 00:38:11,700
incentivize a variety of 
different. 

683
00:38:11,700 --> 00:38:14,800
Implementations right for 
different peoples, use cases. 

684
00:38:15,900 --> 00:38:19,300
And the reason that we're also 
doing that is to kind of the 

685
00:38:19,300 --> 00:38:25,400
prior story that I told, which 
is you need to be as Most of the

686
00:38:25,400 --> 00:38:27,700
base layer from a variety of 
different perspectives as 

687
00:38:27,700 --> 00:38:30,000
possible. 
One of them is roadmap. 

688
00:38:30,000 --> 00:38:31,600
You have to keep your road map 
on. 

689
00:38:31,600 --> 00:38:34,100
You can't get in front of the 
mother ships roadmap. 

690
00:38:34,100 --> 00:38:36,400
You got to kind of hang out in 
this Goldilocks time. 

691
00:38:36,400 --> 00:38:38,800
Period. 
And yeah, those are those are 

692
00:38:38,800 --> 00:38:41,600
the most important things that 
you have to follow and kind of 

693
00:38:41,600 --> 00:38:46,200
stay on top of Yeah, the one 
extra thing I want to add 

694
00:38:46,200 --> 00:38:49,300
actually about the middle right 
side, or as you said, like, why 

695
00:38:49,300 --> 00:38:50,800
don't the client teams 
implemented? 

696
00:38:50,900 --> 00:38:53,700
You know, directly, this is 
something we looked at ourselves

697
00:38:53,700 --> 00:38:56,900
for quite a while, and it's 
actually why I touched on BLS 

698
00:38:56,900 --> 00:38:59,800
signatures being aggregated by 
being so important. 

699
00:39:00,200 --> 00:39:03,900
And I'll talk about it kind of 
by way of talking about May 

700
00:39:03,900 --> 00:39:06,200
boost and before that even might
get. 

701
00:39:06,700 --> 00:39:11,500
And so for those of you that 
aren't familiar, have boobs, 

702
00:39:11,500 --> 00:39:13,600
just now the product like run by
flash spot. 

703
00:39:13,700 --> 00:39:16,700
Is that allows, you know, people
that want to get, you know, 

704
00:39:16,700 --> 00:39:20,900
inclusion into blocks without 
getting front-run, they kind of 

705
00:39:20,900 --> 00:39:23,400
talked to validated through the 
software, but before it was 

706
00:39:23,400 --> 00:39:26,300
called move boost. 
It was called may have get, and 

707
00:39:26,300 --> 00:39:29,300
it was just like a slight 
modification to the original get

708
00:39:29,300 --> 00:39:32,800
code base. 
And they were like highly 

709
00:39:32,800 --> 00:39:36,100
successful in their roll out 
more or less all of the etherium

710
00:39:36,100 --> 00:39:39,200
miners back in the day were 
running may have get to the 

711
00:39:39,200 --> 00:39:43,600
point that people are concerned.
It was north of 90% of clients. 

712
00:39:44,100 --> 00:39:48,200
And the theorem Foundation were 
kind of concerned about this. 

713
00:39:48,200 --> 00:39:50,600
They were like, okay, if there's
anything goes wrong with the 

714
00:39:50,600 --> 00:39:52,700
software, you know, almost 
everyone is running it. 

715
00:39:53,200 --> 00:39:58,000
So when it came time to move 
towards eat to and Reinventing 

716
00:39:58,000 --> 00:40:00,200
it, to figure out how it works 
in this new paradigm with 

717
00:40:00,200 --> 00:40:04,200
validators, one of the best 
changes they made was to 

718
00:40:04,200 --> 00:40:06,800
re-architect my have get instead
of it being like a forked 

719
00:40:06,800 --> 00:40:09,400
client. 
It's an optional middleware or 

720
00:40:09,600 --> 00:40:13,500
oracular Leah, side care that 
all of the clients can add. 

721
00:40:13,800 --> 00:40:16,500
And rather than it being your 
feature that only one specific 

722
00:40:16,500 --> 00:40:18,800
client has the others don't, it 
was something that they could 

723
00:40:18,800 --> 00:40:22,100
all opt into and this, you know,
massively D. 

724
00:40:22,100 --> 00:40:24,800
Risked it and allowed it to be 
more accessible and didn't, you 

725
00:40:24,800 --> 00:40:27,200
know, prevent client diversity 
in any way. 

726
00:40:27,700 --> 00:40:30,600
And we had kind of a similar 
like issue when we were 

727
00:40:30,600 --> 00:40:32,700
developing distributed 
validators as well. 

728
00:40:33,000 --> 00:40:37,500
The easiest kind of way to make 
an MVP is to make a standalone. 

729
00:40:37,500 --> 00:40:40,300
Validator client that has, you 
know, arbitrary power to sign. 

730
00:40:40,500 --> 00:40:43,700
You can build your distributed 
system to go and run. 

731
00:40:43,900 --> 00:40:46,900
The data is this way. 
Whereas yeah. 

732
00:40:46,900 --> 00:40:49,300
Did the kind of problem here is 
either you have, you know one 

733
00:40:49,300 --> 00:40:51,000
client that super successful 
networks? 

734
00:40:51,200 --> 00:40:54,100
Are you expect that everyone has
to implement but if you do that,

735
00:40:54,100 --> 00:40:57,100
you kind of really slow your 
roadmap, you kind of have to get

736
00:40:57,100 --> 00:41:00,400
everyone to March along the same
time and you really don't have 

737
00:41:00,400 --> 00:41:04,500
much optionality if new better 
version comes along, people 

738
00:41:04,500 --> 00:41:09,000
can't switch to it very easily. 
So in the interest of, you know,

739
00:41:09,000 --> 00:41:11,900
not, you know causing harm while
trying to do good when it comes 

740
00:41:11,900 --> 00:41:15,000
to building distributed 
validators we Realize that we 

741
00:41:15,000 --> 00:41:18,100
could also build distributive 
outages and as a middleware 

742
00:41:18,100 --> 00:41:21,000
because of BLS signatures being 
aggregated level. 

743
00:41:21,000 --> 00:41:26,400
So right now all of the existing
validator clients they can add 

744
00:41:26,400 --> 00:41:29,700
our software into their stack 
and become a distributed, 

745
00:41:29,700 --> 00:41:32,000
validator more or less with no 
changes. 

746
00:41:32,400 --> 00:41:35,900
And this is super beneficial 
because it does allow, you know,

747
00:41:35,900 --> 00:41:39,300
you're not one client or you 
know, replacing them all or if 

748
00:41:39,300 --> 00:41:41,600
there is, you know, a better 
spec comes out or, you know, 

749
00:41:41,900 --> 00:41:44,100
although you know goes to 0 in 
the morning and you Can come 

750
00:41:44,100 --> 00:41:46,700
along, all the clients can just 
put in a new middleware and it's

751
00:41:46,700 --> 00:41:50,700
much more modular and it's much 
more like fault-tolerant in that

752
00:41:50,700 --> 00:41:53,000
regards that, you know, if 
something goes wrong you know, 

753
00:41:53,000 --> 00:41:55,700
no big deal. 
People can kind of pivot and 

754
00:41:56,000 --> 00:41:58,700
this, you know, design idea is 
why we kind of went towards the 

755
00:41:58,700 --> 00:42:01,100
Middle where route and it's, you
know, something that's kind of 

756
00:42:01,107 --> 00:42:03,900
served as well in that regard. 
But the last leg of it is, you 

757
00:42:03,908 --> 00:42:07,200
know, just one implementation of
the Middle where is, you know, 

758
00:42:07,300 --> 00:42:09,600
sufficient from a safety 
perspective but there could 

759
00:42:09,600 --> 00:42:12,300
still be alive - risk. 
If you know the thing has a bug 

760
00:42:12,300 --> 00:42:13,700
and it goes Offline that could 
be a problem. 

761
00:42:13,800 --> 00:42:15,700
Mm. 
So they kind of further leg of 

762
00:42:15,700 --> 00:42:19,600
the journey is after you build 
ones, get some adoption prove, 

763
00:42:19,600 --> 00:42:23,400
that it works, then it starts to
become more sensible to protocol

764
00:42:23,400 --> 00:42:25,100
eyes. 
It make a spec have a couple 

765
00:42:25,100 --> 00:42:29,100
implementations, but even if 
there is just one, it is still 

766
00:42:29,400 --> 00:42:32,900
modular replaceable and is this,
you know, nice thing that if a 

767
00:42:32,908 --> 00:42:34,600
better, one comes along, no big 
deal. 

768
00:42:34,600 --> 00:42:38,600
You know, it can be swapped out.
So I think that is kind of an 

769
00:42:38,607 --> 00:42:42,600
important design decision versus
why isn't this, you know, a spec

770
00:42:42,600 --> 00:42:45,900
that all of the clients To 
because you can iterate, faster,

771
00:42:45,900 --> 00:42:49,300
you can try more things, you can
have more optionality and that's

772
00:42:49,300 --> 00:42:51,400
kind of the way we've designed 
the software so far. 

773
00:42:53,000 --> 00:42:56,300
Okay cool. 
I guess we also wanted to sort 

774
00:42:56,300 --> 00:43:00,200
of talk about how mobile 
interacts with other middlewares

775
00:43:00,200 --> 00:43:04,800
in the etherium stack so you 
already mentioned like meth 

776
00:43:04,800 --> 00:43:06,500
boost here. 
I guess that that might be a 

777
00:43:06,508 --> 00:43:09,700
good place to start. 
We're like in my imagination, 

778
00:43:09,700 --> 00:43:11,000
right? 
Like I guess now, we run this 

779
00:43:11,000 --> 00:43:14,600
opal. 
Cluster, like all of these nodes

780
00:43:14,600 --> 00:43:16,700
in the cluster also run meth 
boost. 

781
00:43:17,500 --> 00:43:20,500
Do they have to make basically 
consensus on in terms of like 

782
00:43:20,500 --> 00:43:23,300
what sort of block you accept 
their or can you Talk a little 

783
00:43:23,300 --> 00:43:25,700
bit about how how this 
interaction works. 

784
00:43:28,300 --> 00:43:30,600
Yeah. 
And so it's relatively 

785
00:43:30,600 --> 00:43:34,800
straightforward because may have
peace talks to the consensus 

786
00:43:34,800 --> 00:43:39,000
clients, whereas, we're almost a
little layer lower down talking 

787
00:43:39,000 --> 00:43:42,400
to kind of validate your clients
and you ask a good question 

788
00:43:42,400 --> 00:43:43,600
about. 
Do you have to kind of come to 

789
00:43:43,600 --> 00:43:47,800
consensus on what's provided and
Maeve? 

790
00:43:47,800 --> 00:43:52,300
Boost is a bit different to, you
know, a normal block proposal in

791
00:43:52,300 --> 00:43:57,200
that and the fear is that if you
have, you know, a block that's 

792
00:43:57,200 --> 00:43:59,000
extracting out of V that's, you 
know. 

793
00:44:00,000 --> 00:44:02,200
Yeah. 
Taking I can emphasize rewards 

794
00:44:02,600 --> 00:44:06,700
and the Searcher, doesn't want 
to show the proposer. 

795
00:44:06,700 --> 00:44:08,900
Exactly. 
The full block because then the 

796
00:44:08,900 --> 00:44:10,500
pros will be like, oh thanks for
the alpha. 

797
00:44:10,500 --> 00:44:12,900
I'm just going to rewrite this 
to send it to my address and I'm

798
00:44:12,908 --> 00:44:16,600
just going to propose it and 
this was actually one of the 

799
00:44:16,700 --> 00:44:20,500
reasons around the kind of 
redesign of meth boost. 

800
00:44:20,500 --> 00:44:25,200
Now, when I move towards proof 
of stake was, if we want this to

801
00:44:25,200 --> 00:44:29,600
be available to every proposer, 
we needed to Helo trust because 

802
00:44:29,600 --> 00:44:32,900
you know in the eat one world 
there was only a handful of 

803
00:44:32,900 --> 00:44:36,000
minors so you could kind of 
trust them whereas in you know 

804
00:44:36,000 --> 00:44:39,100
eats do the hope is that there's
a huge amount of validators so 

805
00:44:39,400 --> 00:44:41,100
you do this does need to be low 
trust. 

806
00:44:41,100 --> 00:44:45,400
So what actually happens is the 
relay in the situation is 

807
00:44:45,400 --> 00:44:46,900
actually the kind of trusted 
party. 

808
00:44:47,100 --> 00:44:49,400
They have the full block, they 
know, you know what it is and 

809
00:44:49,400 --> 00:44:52,200
they promise, you know, not to 
Rogue or like undermine the 

810
00:44:52,200 --> 00:44:54,400
Searchers and you know, school 
with them. 

811
00:44:54,700 --> 00:44:57,900
So they just provide hash like 
are like the header of a block 

812
00:44:58,300 --> 00:45:01,100
To the actual distributed 
validator. 

813
00:45:01,600 --> 00:45:06,000
So at that point yes the nodes 
and do come to consensus on, you

814
00:45:06,008 --> 00:45:09,900
know what one to pick, but there
is, you know, there's not too 

815
00:45:09,900 --> 00:45:12,300
much that can go wrong. 
There's not a full block there, 

816
00:45:12,300 --> 00:45:13,500
they cannot reorder 
transactions. 

817
00:45:13,500 --> 00:45:16,300
They can just say, hey, you 
know, this is a Blog header, 

818
00:45:16,300 --> 00:45:18,300
it's going to pay us. 
This reward, are we cool with 

819
00:45:18,300 --> 00:45:21,100
this and everyone says? 
Yep, cool. 

820
00:45:21,100 --> 00:45:24,400
That sign it and send it back to
the relay who then brought pens 

821
00:45:24,400 --> 00:45:27,800
the real block and sends it on 
words and say, yeah, that that 

822
00:45:27,800 --> 00:45:31,600
would be How the men have Boost 
kind of integration works and do

823
00:45:31,600 --> 00:45:32,800
you want to talk about some of 
the other ones? 

824
00:45:32,800 --> 00:45:36,500
Maybe? 
Yeah, I guess the other thing we

825
00:45:36,500 --> 00:45:41,500
want to talk about here is also 
like, sort of a trend that kind 

826
00:45:41,500 --> 00:45:44,300
of coming up any Theory. 
I like Reese taking and I'm 

827
00:45:44,300 --> 00:45:48,400
layer like sort of re utilizing 
your collateral or it if you're 

828
00:45:48,400 --> 00:45:52,100
in validators to offer 
additional services like let's 

829
00:45:52,100 --> 00:45:56,900
say it may be Oracle or whatnot 
and I guess that's also like 

830
00:45:57,200 --> 00:46:00,800
first of all is very The hyped, 
I guess, but also seems to 

831
00:46:00,800 --> 00:46:03,200
interact with with, oh, ball on 
the front. 

832
00:46:03,200 --> 00:46:05,000
That, you know. 
Yeah. 

833
00:46:05,000 --> 00:46:07,900
How how could like Reese taking 
service will be offered through 

834
00:46:07,900 --> 00:46:09,400
a bowl? 
I guess that that would be 

835
00:46:09,400 --> 00:46:13,500
something that I'm personally 
very interested in, for sure. 

836
00:46:14,400 --> 00:46:17,400
Yeah, it's a great question and 
something we're chatting quite a

837
00:46:17,408 --> 00:46:19,100
lot about at the moment, these 
days. 

838
00:46:19,100 --> 00:46:24,100
So I talked about, so we're 
talking to them for the most 

839
00:46:24,100 --> 00:46:26,800
part, about a project called 
eigen layer is introduced, this 

840
00:46:26,800 --> 00:46:31,100
idea of restoring, Taking. 
And as far as how old ball fits 

841
00:46:31,100 --> 00:46:35,500
into the equation, this kind of 
two ways that we fit in first as

842
00:46:35,500 --> 00:46:38,600
a Staker, which is, you know, 
the kind of Crux. 

843
00:46:38,600 --> 00:46:41,500
These are the people that are, 
you know, pointing their 

844
00:46:41,500 --> 00:46:44,000
withdrawal. 
Address of their validator, at 

845
00:46:44,000 --> 00:46:47,800
a, you know, an igon layer, 
smart contract and opting in to 

846
00:46:47,800 --> 00:46:50,400
be the reef takers. 
Like, yes, you know, we will 

847
00:46:50,400 --> 00:46:54,000
provide Economic Security for 
some extra I think additional 

848
00:46:54,000 --> 00:46:57,900
validated Services, what they're
calling that the other thing and

849
00:46:59,100 --> 00:47:02,200
From mistaking perspective we 
think distributed validated 

850
00:47:02,200 --> 00:47:06,100
snowball is super important 
because if you are trying to you

851
00:47:06,100 --> 00:47:09,700
know sell your Reese taking 
solution to these other services

852
00:47:09,700 --> 00:47:12,400
that are you buying Economic 
Security from you? 

853
00:47:13,400 --> 00:47:16,800
You want to be extremely sure 
that the steak underneath you is

854
00:47:16,800 --> 00:47:20,500
safe and secure, because if 
something goes wrong and they 

855
00:47:20,500 --> 00:47:24,500
all get slashed, your Economic 
Security kind of disappears. 

856
00:47:25,900 --> 00:47:29,300
Technically, you know, they'll 
be able to, you know, Charge the

857
00:47:29,300 --> 00:47:31,700
person to get slashed and 
they'll get penalized for it. 

858
00:47:31,800 --> 00:47:34,700
But if you're, you know, maybe 
running an oracle or something 

859
00:47:34,700 --> 00:47:37,100
and depending on this, if 
there's a mass slashing under 

860
00:47:37,100 --> 00:47:40,300
you all the validated get 
exited. 

861
00:47:40,500 --> 00:47:44,200
So your Economic Security just 
kind of disappears on you all of

862
00:47:44,207 --> 00:47:47,900
a sudden and that's you know 
something that you can't really 

863
00:47:47,900 --> 00:47:50,200
are you really don't want to 
happen if you're trying to you 

864
00:47:50,200 --> 00:47:53,300
know, if you're you know 
additional validating service 

865
00:47:53,300 --> 00:47:55,700
looking for you know Economic 
Security you want to be sure 

866
00:47:55,700 --> 00:47:57,500
that the validated need this 
Rock Solid. 

867
00:47:57,800 --> 00:48:01,700
So this is where Distributed 
validated is really kind of add 

868
00:48:01,700 --> 00:48:03,900
benefit for the kind of Reese 
taking Paradigm. 

869
00:48:03,900 --> 00:48:07,300
It's like, yes, you know, this 
steak is run by groups of 

870
00:48:07,300 --> 00:48:09,600
people. 
The odds of it being slashed or 

871
00:48:09,600 --> 00:48:12,800
quite low, the odds of it going 
offline are quite low and that 

872
00:48:12,800 --> 00:48:15,300
kind of gives you a more firm 
based actually provide 

873
00:48:15,300 --> 00:48:19,700
guarantees to extra services. 
And then, you know, going a 

874
00:48:19,707 --> 00:48:24,200
little further or ball itself 
could reward and penalize people

875
00:48:24,200 --> 00:48:27,300
within a distributed validator 
by using this kind of reef 

876
00:48:27,300 --> 00:48:30,600
taking and Economic Security. 
T and this is, you know, the 

877
00:48:30,600 --> 00:48:33,700
kind of further version of Leo 
in the near term mobile can be a

878
00:48:33,700 --> 00:48:37,100
Staker for something like I can 
layer, but in the longer term it

879
00:48:37,100 --> 00:48:39,800
can also be an additional 
validated service that, you 

880
00:48:39,808 --> 00:48:43,700
know, being the one paying for 
economic security or for Reese, 

881
00:48:43,700 --> 00:48:47,900
take to keep it, you know, 
protocol running and CI weirdo. 

882
00:48:47,900 --> 00:48:50,900
Quite bullish on the idea of 
having distributed validators, 

883
00:48:50,900 --> 00:48:58,000
be a safe base to Reese take on 
Yeah, that's that's really cool.

884
00:48:58,000 --> 00:49:01,800
I like personally was thinking, 
you know, also since you know I 

885
00:49:01,800 --> 00:49:06,600
guess there could be a lot of 
additional services that are 

886
00:49:06,600 --> 00:49:09,600
offered through angle, a right 
and maybe for a single node, 

887
00:49:09,600 --> 00:49:13,100
operator can be hard to run so 
many additional services. 

888
00:49:13,400 --> 00:49:15,800
So I guess. 
Do you think it's possible that?

889
00:49:15,800 --> 00:49:18,800
Like for example a oboe cluster 
sort of shares, these 

890
00:49:18,800 --> 00:49:22,000
responsibilities like one guy 
runs their Oracle the other. 

891
00:49:22,000 --> 00:49:23,800
That's a hundred percent, right?
Yeah. 

892
00:49:25,200 --> 00:49:27,500
In the, in the near term, the be
bit of trust involved. 

893
00:49:27,500 --> 00:49:30,400
If you're a, you know, saying 
hey we will put our withdrawal 

894
00:49:30,400 --> 00:49:33,000
contract, you note or 
diagonally, I will trust my hair

895
00:49:33,000 --> 00:49:34,400
is going to run that Oracle for 
us. 

896
00:49:34,400 --> 00:49:36,700
He's not going to get a slashed.
You can do that. 

897
00:49:36,700 --> 00:49:38,600
Absolutely. 
And you know we could all be 

898
00:49:38,800 --> 00:49:41,300
taking the risk of, you know, 
doing that extra additional 

899
00:49:41,300 --> 00:49:44,600
voluntary service each and put 
going even further. 

900
00:49:44,600 --> 00:49:47,700
We're working on the 
cryptography to make kind of 

901
00:49:48,000 --> 00:49:51,400
proofs of kind of, you know, 
Fair participation more, easily 

902
00:49:51,400 --> 00:49:53,900
provable. 
And here's a scent that they're 

903
00:49:53,900 --> 00:49:55,000
like the longer term. 
Goal. 

904
00:49:55,000 --> 00:49:58,400
Is that, you know, one piece of 
this distributed validator could

905
00:49:58,400 --> 00:50:00,300
opt into this service for 
everyone? 

906
00:50:00,500 --> 00:50:03,800
And if they do screw up there, 
the one that takes the hit or 

907
00:50:03,800 --> 00:50:06,400
eats, you know, most of the 
blame rather than the whole 

908
00:50:06,400 --> 00:50:09,900
group sharing in the, like, 
slashing, if, you know, one 

909
00:50:09,900 --> 00:50:12,800
person who they like trusted to,
you know, do some extra service 

910
00:50:12,800 --> 00:50:16,600
for them doesn't like match. 
But yes, you absolutely can 

911
00:50:16,600 --> 00:50:18,400
have. 
You know, one person in your 

912
00:50:18,400 --> 00:50:22,100
cluster doing all of these extra
validating services for you 

913
00:50:24,300 --> 00:50:28,400
Yeah, maybe this eigen little 
ecosystem would be so large that

914
00:50:28,700 --> 00:50:34,500
specialization of Labor will 
emerge, meaning some validators,

915
00:50:34,500 --> 00:50:37,900
do some things, and other 
evaluators, do other things. 

916
00:50:38,500 --> 00:50:41,700
And if that kind of 
specialization of Labor, emerges

917
00:50:41,700 --> 00:50:45,300
then, o ball, is kind of 
perfectly fit for for 

918
00:50:45,300 --> 00:50:48,400
exploiting, that specification, 
be specialization. 

919
00:50:49,300 --> 00:50:51,100
But it's still early days, 
right? 

920
00:50:51,100 --> 00:50:54,500
Like there is not not a single 
service that's actually running 

921
00:50:54,500 --> 00:50:58,900
on this Reese taking model in 
product 10. 

922
00:50:59,000 --> 00:51:01,700
I think they announced their no 
not in production, they 

923
00:51:01,707 --> 00:51:04,700
announced their spec and stuff, 
I think this week so shout out 

924
00:51:04,700 --> 00:51:06,400
to them for that. 
So yeah, they're working away in

925
00:51:06,400 --> 00:51:08,900
it. 
We're keeping an eye shadow way 

926
00:51:09,700 --> 00:51:14,100
is is the overall concept only 
applicable to etherium because 

927
00:51:14,100 --> 00:51:19,900
of its special staking model or 
is it also applicable All to 

928
00:51:20,200 --> 00:51:23,700
other chains. 
Could you expand to other chains

929
00:51:24,500 --> 00:51:28,700
and deliver utility? 
Yeah, it's a good question. 

930
00:51:28,700 --> 00:51:32,500
So what we've been thinking 
about DBT for aetherium, 

931
00:51:32,500 --> 00:51:35,300
validators for three and a half 
years at this point. 

932
00:51:35,300 --> 00:51:39,200
So I made it a pretty large 
effort at the end of last year 

933
00:51:39,200 --> 00:51:42,700
to be like, hey guys, it's time.
We have to go look at where else

934
00:51:42,700 --> 00:51:45,400
we can go right? 
Like this technology, most 

935
00:51:45,400 --> 00:51:48,400
likely will benefit other 
ecosystems or other layers of 

936
00:51:48,400 --> 00:51:51,200
the theory of, for example. 
So we went on this effort to 

937
00:51:51,200 --> 00:51:53,500
kind of go find problems 
recently. 

938
00:51:53,900 --> 00:51:56,700
So we spent the entire fourth 
quarter. 

939
00:51:57,300 --> 00:52:00,800
Um, and a good portion of the 
first quarter on a cosmos 

940
00:52:00,900 --> 00:52:04,100
effort, which, you know, the 
team at course, one was very 

941
00:52:04,100 --> 00:52:07,300
helpful with and a lot of the 
other causal is ecosystem as 

942
00:52:07,300 --> 00:52:09,500
well. 
We've also over time when we'd 

943
00:52:09,500 --> 00:52:11,700
like our first and second 
fundraising round kind of had 

944
00:52:11,700 --> 00:52:15,200
this emphasis on like what is 
the second ecosystem that we 

945
00:52:15,200 --> 00:52:17,900
think they're smart people. 
Working in that have the right, 

946
00:52:17,900 --> 00:52:20,600
you know Mission and like the 
right vision and that was caused

947
00:52:20,600 --> 00:52:24,300
most investors. 
So the ecosystem itself already 

948
00:52:24,300 --> 00:52:26,800
has a pretty actually large 
Cosmos presence in. 

949
00:52:26,900 --> 00:52:32,200
It today as a zobel. 
So we decided to double down on 

950
00:52:32,200 --> 00:52:35,300
that fact because we had the 
best access to information and 

951
00:52:35,300 --> 00:52:38,400
we figured we could like learn 
as quickly as possible succeed. 

952
00:52:38,400 --> 00:52:40,200
Quickly fail. 
Quickly, kind of one of those, 

953
00:52:40,200 --> 00:52:42,700
you know, mindsets. 
So we went into Cosmos and we 

954
00:52:42,700 --> 00:52:46,600
started looking for problems. 
We spoke to the validators, we 

955
00:52:47,000 --> 00:52:49,000
spoke to the liquid staking 
projects. 

956
00:52:49,000 --> 00:52:51,500
We spoke to the ICF, the folks 
at the builders program, we kind

957
00:52:51,500 --> 00:52:54,100
of did this whole Loop of going 
through the whole Cosmos 

958
00:52:54,100 --> 00:52:56,600
ecosystem and speaking to people
and looking for problems. 

959
00:52:56,900 --> 00:53:00,300
And we were able to identify, 
you know, a couple structural 

960
00:53:00,300 --> 00:53:05,300
problems is to how DVT could be 
useful for smaller. 

961
00:53:05,300 --> 00:53:08,100
Validators, for example, in 
Cosmos to team up to get more 

962
00:53:08,100 --> 00:53:10,000
delegation to enter the active 
set. 

963
00:53:10,000 --> 00:53:13,600
There's kind of like this larger
portion of Cosmos validators 

964
00:53:13,600 --> 00:53:15,200
that are like chronically 
unprofitable. 

965
00:53:15,200 --> 00:53:18,500
Even like some of the largest, 
you know, cause most alligators 

966
00:53:18,500 --> 00:53:21,100
aren't necessarily that 
profitable today either. 

967
00:53:21,100 --> 00:53:23,700
So the smaller to, you know, 
middle tier ones, there's really

968
00:53:23,700 --> 00:53:26,400
no game for them unless they 
could maybe team up together, 

969
00:53:26,400 --> 00:53:27,200
right? 
Right? 

970
00:53:27,200 --> 00:53:30,200
And attract delegation through, 
you know, means using DDT. 

971
00:53:31,100 --> 00:53:33,200
So yeah, we found some good 
problems in Cosmos. 

972
00:53:33,200 --> 00:53:36,800
We published a blog post on it 
recently, you know, there is 

973
00:53:36,808 --> 00:53:40,400
coordination difficulties to 
making it a reality there's 

974
00:53:40,400 --> 00:53:42,600
protocol difficulties. 
There's cryptography, 

975
00:53:42,600 --> 00:53:47,100
differences for example, Cosmos 
does not use BLS signatures, but

976
00:53:47,100 --> 00:53:49,200
we also learned through that 
effort that if you wanted to get

977
00:53:49,200 --> 00:53:53,100
it done you could and there's 
kind of like a existing versions

978
00:53:53,100 --> 00:53:56,200
in the cosmos ecosystems that 
are about, you know, a third of 

979
00:53:56,200 --> 00:53:58,800
what DVT. 
Is but there would be a lot of 

980
00:53:58,800 --> 00:54:01,900
builds inside a cosmos. 
That would be necessary. 

981
00:54:02,900 --> 00:54:04,700
One of the most interesting 
things that we found about 

982
00:54:04,700 --> 00:54:11,300
Cosmos was actually the kind of 
social threshold of the value of

983
00:54:11,300 --> 00:54:17,100
DVT and inside of Cosmos, what 
we realized is that there wasn't

984
00:54:17,100 --> 00:54:22,300
enough value at risk for people 
to think that it was something 

985
00:54:22,300 --> 00:54:25,000
that shouldn't just be, you 
know, an open-source primitive. 

986
00:54:25,300 --> 00:54:29,300
They couldn't believe that it 
needed to be a network with all 

987
00:54:29,300 --> 00:54:33,000
these, you know, tools and 
education and funding and 

988
00:54:33,000 --> 00:54:37,400
ecosystem around it. 
But our take from that was that 

989
00:54:37,500 --> 00:54:41,300
the cosmos ecosystem is almost 
mature enough to have enough 

990
00:54:41,300 --> 00:54:44,300
value at risk for everyone to 
say like, hey, we think this is 

991
00:54:44,300 --> 00:54:46,800
a good technology to adopt into 
our community. 

992
00:54:47,600 --> 00:54:51,500
So, for us, we believe that it's
a little bit early for DBT in 

993
00:54:51,500 --> 00:54:55,400
Cosmos, but we are still 
actively, like working on 

994
00:54:55,400 --> 00:54:58,100
implementation based research 
now, So we like stated the 

995
00:54:58,107 --> 00:55:00,700
problems and now what we want to
present to everyone is kind of 

996
00:55:00,707 --> 00:55:03,000
like here's how it could be 
implemented. 

997
00:55:03,600 --> 00:55:06,500
So yeah that's like one area of 
alternative layer ones outside 

998
00:55:06,500 --> 00:55:08,500
of it. 
The area where are our 

999
00:55:08,500 --> 00:55:12,000
communities aligned and we're 
experimenting to see if the 

1000
00:55:12,000 --> 00:55:14,600
compost Community Values, it and
then will, you know, collaborate

1001
00:55:14,600 --> 00:55:17,100
with it. 
The other area, which is 

1002
00:55:17,100 --> 00:55:20,700
actually super exciting segment.
Just put out a piece yesterday 

1003
00:55:20,700 --> 00:55:23,100
around distributed sequencer 
technology. 

1004
00:55:23,700 --> 00:55:27,100
A new term that we're trying to 
coin and this is the Then the 

1005
00:55:27,100 --> 00:55:31,700
other research area for us at 
opal, is just going up the stack

1006
00:55:31,900 --> 00:55:33,900
and looking at your other 
actors, right? 

1007
00:55:33,900 --> 00:55:37,200
So today we've spent all this 
time on the validator. 

1008
00:55:37,200 --> 00:55:38,600
Well, let's go up to the block 
Builder. 

1009
00:55:38,600 --> 00:55:41,000
Let's see if there's like 
centralization problems around 

1010
00:55:41,000 --> 00:55:43,600
block building people talk about
MVC block building, right? 

1011
00:55:43,600 --> 00:55:46,700
All these different constructs. 
And then we've also been looking

1012
00:55:46,700 --> 00:55:50,400
at the sequencer and like the 
approver, the verifier, all of 

1013
00:55:50,400 --> 00:55:53,100
these new actors that are 
becoming more and more important

1014
00:55:53,100 --> 00:55:56,000
in the core etherium 
infrastructure stack and looking

1015
00:55:56,000 --> 00:55:58,800
at their adoptions. 
Eagles and saying like is there 

1016
00:55:58,800 --> 00:56:03,800
a need or is there a re use case
for the work that we've done for

1017
00:56:03,800 --> 00:56:06,200
distribute validators and all 
the stuff that we know we've 

1018
00:56:06,200 --> 00:56:09,100
learned from an external project
building it not from a 

1019
00:56:09,107 --> 00:56:11,900
foundation perspective actually 
which is the reality of where 

1020
00:56:11,900 --> 00:56:14,800
layer 2 is there a bit more 
mature and there we sit outside 

1021
00:56:14,800 --> 00:56:17,700
the foundation. 
We do our own things and we do 

1022
00:56:17,700 --> 00:56:20,100
whatever. 
So you know flab rating with 

1023
00:56:20,100 --> 00:56:23,100
those new groups of people has 
been quite an interesting 

1024
00:56:23,100 --> 00:56:26,400
experience for us so yeah we're 
we're actively looking. 

1025
00:56:26,800 --> 00:56:29,800
Two different growth strategies 
for DVT to see if I can be 

1026
00:56:29,800 --> 00:56:32,700
helpful elsewhere. 
One of them is horizontal, 

1027
00:56:33,100 --> 00:56:35,900
that's Cosmos. 
One of them is vertical that's 

1028
00:56:35,900 --> 00:56:38,600
going into the sequence or topic
and seeing if our technology 

1029
00:56:38,600 --> 00:56:42,300
could be helpful there, Yeah, 
very interesting. 

1030
00:56:42,300 --> 00:56:46,000
I guess I would also like, just 
like to hear your thoughts. 

1031
00:56:46,000 --> 00:56:49,900
I guess you're like, very close 
in the end to like both the 

1032
00:56:49,900 --> 00:56:53,700
validator ecosystem and sort of 
the other protocols. 

1033
00:56:53,700 --> 00:56:57,600
And and I would just like sort 
of like to hear how you 

1034
00:56:57,600 --> 00:57:00,300
currently think of the validator
ecosystem. 

1035
00:57:00,300 --> 00:57:03,400
And how do you see it evolving? 
I mean, obviously sort of like 

1036
00:57:03,400 --> 00:57:07,300
one of the core ideas of the 
theorem is that there are these 

1037
00:57:07,300 --> 00:57:10,200
homes takers. 
Like do you do you think that 

1038
00:57:10,500 --> 00:57:13,900
like they're you Are much of 
those and will this grow 

1039
00:57:13,900 --> 00:57:17,400
obviously a global potentially 
might help increase that, but I 

1040
00:57:17,408 --> 00:57:20,400
guess just generally what's your
view of the space. 

1041
00:57:22,200 --> 00:57:28,800
Yeah, I've been surprised 
thoroughly at the number of 

1042
00:57:28,800 --> 00:57:33,900
like, hybrid at home validators,
I would call them, right. 

1043
00:57:33,900 --> 00:57:36,100
They're basically like small 
groups of at home. 

1044
00:57:36,100 --> 00:57:39,700
Validators who are starting 
small companies together and 

1045
00:57:39,700 --> 00:57:42,400
there are tens and 20s and 
they're like growing by the 

1046
00:57:42,400 --> 00:57:44,500
number, right? 
We kind of call them like the 

1047
00:57:44,500 --> 00:57:48,500
tail end, validator segment and 
that's probably growing the 

1048
00:57:48,500 --> 00:57:50,600
most, right? 
We're seeing a variety of new 

1049
00:57:50,600 --> 00:57:53,700
and small value or entity. 
These pop-up we're starting to 

1050
00:57:53,707 --> 00:57:57,600
see people from other ecosystems
come to etherium and by means of

1051
00:57:57,600 --> 00:58:00,300
coming to etherium. 
They're doing so through DBT as 

1052
00:58:00,300 --> 00:58:03,600
actually their first knowledge 
base which was also like a very 

1053
00:58:03,600 --> 00:58:06,000
interesting thing is in our 
onboarding validators from other

1054
00:58:06,000 --> 00:58:09,900
ecosystems, not into the core 
configuration but into the DVT 

1055
00:58:09,900 --> 00:58:14,500
base configuration from from the
very beginning but are probably 

1056
00:58:14,500 --> 00:58:16,900
some of the most like bullish 
honestly and exciting 

1057
00:58:16,900 --> 00:58:19,600
conversations. 
We have with people are in the 

1058
00:58:19,600 --> 00:58:21,800
like, hey me and my three 
friends just got together. 

1059
00:58:22,000 --> 00:58:24,500
We started a company we're 
looking to like you know get 

1060
00:58:24,500 --> 00:58:25,900
involved as a validator and 
light. 

1061
00:58:25,900 --> 00:58:27,700
Oh we're looking to try to 
qualify. 

1062
00:58:28,200 --> 00:58:30,900
There's there's a variety of 
small and mid, tier validators 

1063
00:58:30,900 --> 00:58:33,400
that are trying to get voted 
into light. 

1064
00:58:33,400 --> 00:58:37,100
Oh, and by means of increasing 
their chances, they're spending 

1065
00:58:37,100 --> 00:58:39,400
a lot of time with Oberlin DDT, 
to make sure that they're 

1066
00:58:39,400 --> 00:58:42,100
proficient and that make sure 
that they're educated by it. 

1067
00:58:43,000 --> 00:58:46,300
So honestly, there's a lot of 
really good inertia at the 

1068
00:58:46,300 --> 00:58:51,200
smaller end of the validator of 
embracing DDT and like using it 

1069
00:58:51,200 --> 00:58:53,500
too. 
Advance themselves so they can 

1070
00:58:53,500 --> 00:58:56,900
become more professional. 
And this is surprised me. 

1071
00:58:57,400 --> 00:59:01,200
This is not, you know, like like
a segment that I thought would 

1072
00:59:01,200 --> 00:59:05,400
be such a core user and like, 
Pusher of the protocol, but I 

1073
00:59:05,400 --> 00:59:09,100
think it's really like a. 
It's a sign of like the ethos of

1074
00:59:09,100 --> 00:59:11,700
the theory. 
Mm, it's like kind of crazy to 

1075
00:59:11,700 --> 00:59:15,200
see actually write like that 
group of people feels empowered 

1076
00:59:15,200 --> 00:59:17,500
to go build companies. 
So that's what they're doing. 

1077
00:59:17,500 --> 00:59:20,700
And then they're using obol as a
further like empowering 

1078
00:59:20,700 --> 00:59:23,700
mechanism. 
To achieve those goals and it's 

1079
00:59:23,700 --> 00:59:28,200
quite fascinating. 
So in the etherium roadmap, we 

1080
00:59:28,200 --> 00:59:33,300
have this, this dank sharding 
concept that's coming in where 

1081
00:59:34,000 --> 00:59:38,300
essentially these validators 
will end up becoming responsible

1082
00:59:38,300 --> 00:59:43,800
for data availability. 
So if you have like a single 

1083
00:59:43,800 --> 00:59:47,400
centralized validator, it's kind
of probably easy to understand, 

1084
00:59:47,400 --> 00:59:51,800
we have to store some some kind 
of data on our side but how does

1085
00:59:51,800 --> 00:59:55,300
it interact with a no-ball 
cluster with there might be 

1086
00:59:55,300 --> 00:59:58,600
three we're like three different
parody does does it data? 

1087
00:59:58,600 --> 01:00:00,800
Now need to be replicated across
all three? 

1088
01:00:02,500 --> 01:00:05,200
Good really Niche. 
Technical question, mayor. 

1089
01:00:05,200 --> 01:00:11,000
And so on, this tank sharing is 
coming out in two phases, the 

1090
01:00:11,000 --> 01:00:13,300
first one being prototyping 
sharding, and the second one 

1091
01:00:13,300 --> 01:00:19,300
being folding shouting in Frodo 
dank shouting, they don't go to 

1092
01:00:19,300 --> 01:00:22,200
the extreme where they don't 
have every node in the 

1093
01:00:22,200 --> 01:00:25,000
blockchain kind of keeping and 
gossiping like all the data 

1094
01:00:25,000 --> 01:00:27,100
availability. 
It's still, you know, everyone 

1095
01:00:27,100 --> 01:00:31,800
sends everything everywhere. 
And If eventually with, you know

1096
01:00:31,800 --> 01:00:36,100
folder, Shouting you're signing 
data, availability witnesses to 

1097
01:00:36,107 --> 01:00:38,100
prove that. 
Yes you know I did see this data

1098
01:00:38,100 --> 01:00:43,600
was available and oh yeah over 
the longer run there starts to 

1099
01:00:43,600 --> 01:00:47,300
be you know trust assumptions 
between the the four nodes trust

1100
01:00:47,300 --> 01:00:48,800
them strong word but they have 
to decide. 

1101
01:00:48,900 --> 01:00:52,700
Did we all see the surgeon at 
least any of us see the speed of

1102
01:00:52,700 --> 01:00:56,300
data blob so that we can include
it in our block and like sign to

1103
01:00:56,300 --> 01:00:58,700
it. 
But in the near term and 

1104
01:00:58,700 --> 01:01:01,700
prototyping shouting when it 
first comes in, it's more as a 

1105
01:01:01,700 --> 01:01:03,500
best. 
Effort data availability. 

1106
01:01:03,500 --> 01:01:06,300
It's done at the consensus layer
and it's not, you know, you 

1107
01:01:06,300 --> 01:01:08,500
won't be slashed or to my 
understanding or at least 

1108
01:01:08,900 --> 01:01:12,300
they're not putting, they're not
going to the side where, you 

1109
01:01:12,300 --> 01:01:14,900
know, all nodes don't store 
everything which is the first 

1110
01:01:14,900 --> 01:01:17,000
wave comes in. 
So yeah, when it comes in a 

1111
01:01:17,000 --> 01:01:19,300
prototype sharding, not 
currently problem. 

1112
01:01:19,600 --> 01:01:22,500
When it goes to folding 
sharding, the nodes do have to 

1113
01:01:22,500 --> 01:01:25,500
say have we really seen this and
you know we have to kind of 

1114
01:01:25,700 --> 01:01:28,500
prove yourself at or as you said
if you don't trust one another 

1115
01:01:28,900 --> 01:01:31,500
everyone see the date 
availability before we sign off 

1116
01:01:31,500 --> 01:01:34,000
if you want to be More cautious 
rather than more trusting. 

1117
01:01:34,500 --> 01:01:37,400
But yeah, it's in the near term.
It should be problem. 

1118
01:01:37,400 --> 01:01:40,100
And then also, we proposed a 
builder separation. 

1119
01:01:40,400 --> 01:01:44,600
A lot of the complexities of 
dang sharding is on the Builder 

1120
01:01:44,900 --> 01:01:47,800
and the proposers it keeps the 
proposes relatively simple. 

1121
01:01:47,800 --> 01:01:50,400
They just have to kind of 
propose the really fancy block 

1122
01:01:50,400 --> 01:01:54,700
that a builder made for them. 
Maybe I like to end with kind of

1123
01:01:54,700 --> 01:01:59,000
one of the conceptual doubts I 
have with this entire aetherium 

1124
01:01:59,000 --> 01:02:05,500
Elder roadmap, which is that 
sometimes I feel that via 

1125
01:02:05,500 --> 01:02:08,500
meaning like ZZ validators and, 
like, you all of these 

1126
01:02:08,500 --> 01:02:13,700
middleware Builders. 
We spent so much time and effort

1127
01:02:14,500 --> 01:02:18,000
building various products to 
make the etherium, validation 

1128
01:02:18,700 --> 01:02:21,000
system work and be 
decentralized. 

1129
01:02:21,800 --> 01:02:23,900
So many thought Cycles have been
spent here. 

1130
01:02:25,200 --> 01:02:29,100
And now when it comes to the 
question of scaling ethereum, 

1131
01:02:30,100 --> 01:02:35,700
most of our effort is kind of it
feels useless because it's going

1132
01:02:35,700 --> 01:02:37,500
to be scaled through the L2 is 
now. 

1133
01:02:37,500 --> 01:02:40,100
These Elders are going to be 
running sequencers, and that's 

1134
01:02:40,100 --> 01:02:44,700
like a completely different kind
of validation stack, that's 

1135
01:02:44,700 --> 01:02:49,200
that's being built. 
And like now you have noun, for 

1136
01:02:49,200 --> 01:02:54,500
example, overall instead of 
reusing your work for etherium 

1137
01:02:54,500 --> 01:02:59,000
directly to scale is helium in 
L2, you now have to go and think

1138
01:02:59,000 --> 01:03:02,000
of this new concept of a 
distributor sequence and wrongly

1139
01:03:02,000 --> 01:03:05,100
Android new software. 
Same for us extra. 

1140
01:03:06,900 --> 01:03:11,700
Do you in some sense, think 
you're all our efforts are kind 

1141
01:03:11,700 --> 01:03:15,300
of like not being wasted but 
being underutilized by the 

1142
01:03:15,300 --> 01:03:19,800
theorem ecosystem. 
Yet throwing all my favorite 

1143
01:03:19,800 --> 01:03:24,100
questions, my hair because I 
actually would suggest that we 

1144
01:03:24,100 --> 01:03:27,100
don't have to throw stuff away 
and, you know, build new 

1145
01:03:27,100 --> 01:03:31,100
software and stuff. 
And this is the idea of a 

1146
01:03:31,107 --> 01:03:34,600
theorem equivalents that I think
was kind of first coined Again, 

1147
01:03:34,600 --> 01:03:39,500
by optimism, but they kind of 
astutely realize that if they 

1148
01:03:39,500 --> 01:03:43,200
stay as close to the etherium 
execution architecture as 

1149
01:03:43,200 --> 01:03:45,600
possible. 
It's easier for, you know, to 

1150
01:03:45,600 --> 01:03:48,800
gain adoption and network 
effects and be able to reuse all

1151
01:03:48,800 --> 01:03:52,900
of the existing L1 stack. 
And for example, their very 

1152
01:03:52,900 --> 01:03:56,700
first kind of MVP will call it 
was, you know, a modified, get 

1153
01:03:57,500 --> 01:03:59,800
not unlike maybe get to some 
extent. 

1154
01:04:00,200 --> 01:04:03,400
And then recently, or just in 
the coming weeks, they're moving

1155
01:04:03,400 --> 01:04:07,300
over to optimism bedrock and the
main difference, there is David 

1156
01:04:07,600 --> 01:04:11,300
abstracted all of their kind of 
code for the optimism kind of 

1157
01:04:11,300 --> 01:04:14,300
fraud proof game, and into what 
they're kind of calling a 

1158
01:04:14,300 --> 01:04:16,700
consensus client. 
And they talk only through 

1159
01:04:16,800 --> 01:04:18,800
Engine API. 
The standard one that all of the

1160
01:04:18,800 --> 01:04:22,600
execution clients use and 
adopting, this kind of 

1161
01:04:22,600 --> 01:04:26,600
standardized API for them, has 
allowed them to go from having, 

1162
01:04:26,600 --> 01:04:29,800
you know, Opie get to also 
having Opie Aragon and 

1163
01:04:29,800 --> 01:04:33,800
ultimately, probably all of the 
existing L1 execution clients in

1164
01:04:33,800 --> 01:04:38,000
the optimism world. 
And we recently like, announced 

1165
01:04:38,000 --> 01:04:40,700
a Blog with segment just 
yesterday on distributed 

1166
01:04:40,700 --> 01:04:43,200
sequencers. 
And the Crux of the argument is 

1167
01:04:43,200 --> 01:04:46,600
exactly, I'm yeah, altitudes of 
already. 

1168
01:04:46,700 --> 01:04:49,500
You've competed only theorem 
equivalents at the execution 

1169
01:04:49,500 --> 01:04:52,800
layer. 
The next step in our head is to 

1170
01:04:53,300 --> 01:04:56,900
add and etherium equivalent 
Beacon API to their code base of

1171
01:04:56,908 --> 01:04:59,700
the. 
So adopt PLS signatures adopted 

1172
01:04:59,700 --> 01:05:02,200
API, dumb it down a little. 
It doesn't need that to take 

1173
01:05:02,300 --> 01:05:05,800
attestations because it's not a 
proof of stake game but just 

1174
01:05:05,800 --> 01:05:09,900
have, you know, proposals using 
that standardized API and the 

1175
01:05:09,908 --> 01:05:12,900
benefit of that is you do get to
reuse more or less everything 

1176
01:05:12,900 --> 01:05:16,600
from the L1 particularly from 
the L1 staking side. 

1177
01:05:17,200 --> 01:05:20,800
The ones probably most important
is the private Key Management 

1178
01:05:20,800 --> 01:05:23,600
side of things. 
So, you know, private keys are 

1179
01:05:23,600 --> 01:05:27,800
always the most important thing.
So if you if let's say optimism 

1180
01:05:27,800 --> 01:05:32,300
for Simplicity, they add a 
beacon API to their L2 lycopene 

1181
01:05:32,300 --> 01:05:35,600
owed stuck. 
They can reuse web three signer,

1182
01:05:35,600 --> 01:05:39,800
they can reuse Dirk and you know
the benefit for all us they can 

1183
01:05:39,800 --> 01:05:43,800
reuse distributed validators 
because it uses the same API and

1184
01:05:43,800 --> 01:05:45,600
they can more or less use it all
out of the box. 

1185
01:05:45,600 --> 01:05:48,200
So yeah, I I hear where you're 
coming from being, like, should 

1186
01:05:48,200 --> 01:05:50,800
I choose really invent the wheel
and I agree with you, they 

1187
01:05:50,800 --> 01:05:53,500
probably shouldn't they should, 
you know, copy the L1 apis, as 

1188
01:05:53,500 --> 01:05:56,000
much as possible. 
And then they get to kind of tap

1189
01:05:56,000 --> 01:05:57,300
into the network effects of 
code. 

1190
01:05:57,300 --> 01:05:59,100
It's already built and already 
been used. 

1191
01:05:59,100 --> 01:06:02,500
So yeah, pitch to them is you 
don't have to do all of the 

1192
01:06:02,500 --> 01:06:04,400
decentralizing, sequencer work 
yourselves. 

1193
01:06:04,400 --> 01:06:05,700
You can keep it a little 
simpler. 

1194
01:06:05,900 --> 01:06:09,500
Have it be kind of a round-robin
thing with BLS signatures but 

1195
01:06:09,500 --> 01:06:13,200
then use distributed validator 
to actually go from, you know, 

1196
01:06:13,200 --> 01:06:16,200
10 entities and round-robin to 
actually 10 distributed 

1197
01:06:16,200 --> 01:06:18,800
sequence, Errors in round-robin 
type of setup. 

1198
01:06:18,800 --> 01:06:23,400
So yeah, I agree that, you know,
L 2, I think, you know, 

1199
01:06:23,400 --> 01:06:25,200
generally will adopt this. 
They kind of see the network 

1200
01:06:25,200 --> 01:06:27,400
effect trying to build something
new and convince everyone to 

1201
01:06:27,400 --> 01:06:28,000
come. 
Easy stuff. 

1202
01:06:28,000 --> 01:06:30,800
Is hard trying to, you know, 
stay aligned with the existing 

1203
01:06:30,800 --> 01:06:33,900
apis more work for them, but, 
you know, more Network effects 

1204
01:06:33,900 --> 01:06:36,400
and easier adoption for their 
customers, and for everyone 

1205
01:06:36,400 --> 01:06:39,600
else, right? 
So actually, actually, this then

1206
01:06:39,600 --> 01:06:43,900
seems very powerful for the old 
bowling Network that You can 

1207
01:06:43,900 --> 01:06:46,100
effectively go to an L2 that 
has. 

1208
01:06:46,200 --> 01:06:49,700
Let's say a centralized 
sequencer and maybe your product

1209
01:06:49,700 --> 01:06:52,900
is simply that instead of now 
this being a centralized 

1210
01:06:52,900 --> 01:06:56,400
sequencer, it's actually 
distributed across five parties 

1211
01:06:56,400 --> 01:07:01,300
or six parties and then if they 
can work out how to go from one 

1212
01:07:01,300 --> 01:07:04,700
centralized sequencer to five 
and each of them now is a 

1213
01:07:04,707 --> 01:07:06,900
no-ball validator with like five
or seven. 

1214
01:07:06,900 --> 01:07:11,700
Then you can Autumn easily get 
to 25 or 35 people running the 

1215
01:07:11,700 --> 01:07:13,900
infrastructure eggs. 
Likely right. 

1216
01:07:13,900 --> 01:07:20,100
So so all of your work done for 
is helium, kind of Yeah. 

1217
01:07:20,200 --> 01:07:26,400
Scales like probably is more 
useful on the L2 layer, then, 

1218
01:07:26,400 --> 01:07:27,900
maybe you're even on this idiom 
mean. 

1219
01:07:27,900 --> 01:07:30,900
Net like that, could be a future
for that. 

1220
01:07:30,900 --> 01:07:32,600
Could happen for the overall 
project. 

1221
01:07:33,800 --> 01:07:35,100
Yeah. 
That was actually something I 

1222
01:07:35,100 --> 01:07:39,100
also pitched where seek like in 
the L1 is normally very small 

1223
01:07:39,100 --> 01:07:42,200
machines and there's technically
you know, 500,000 validators, 

1224
01:07:42,400 --> 01:07:45,200
but sequencers, they often will 
be running like very large 

1225
01:07:45,200 --> 01:07:48,400
machines. 
So you know five very large 

1226
01:07:48,400 --> 01:07:52,100
machines run in a distributed 
sequencer setup makes a lot of 

1227
01:07:52,107 --> 01:07:54,900
sense rather than you know, 
thousands of small machines. 

1228
01:07:54,900 --> 01:07:58,200
The l2's. 
Mostly won't optimized for like 

1229
01:07:58,200 --> 01:08:00,600
running on consumer Hardware. 
There, you know, meant to be a 

1230
01:08:00,607 --> 01:08:03,400
scaling solution, but they do 
want to be, you know, as Trust. 

1231
01:08:03,600 --> 01:08:07,300
- as possible. 
So yeah, big sequencers that are

1232
01:08:07,300 --> 01:08:10,900
running a distributed validator 
type of setup where if one of 

1233
01:08:10,900 --> 01:08:13,800
them becomes malicious nothing 
happens they just you know like 

1234
01:08:13,800 --> 01:08:15,700
stay online like a multisig, is 
it? 

1235
01:08:15,700 --> 01:08:18,899
Yeah as I actually agree I think
really makes more sense it out 

1236
01:08:18,899 --> 01:08:22,000
to than either one and by others
majority side of things. 

1237
01:08:23,000 --> 01:08:24,800
Perfect. 
Yeah. 

1238
01:08:24,899 --> 01:08:27,300
Awesome. 
That we went very deep. 

1239
01:08:27,899 --> 01:08:30,899
Thanks so much for a dank 
episode emotionally Colin. 

1240
01:08:30,899 --> 01:08:33,399
And yeah, thanks for for coming 
on the epicenter. 

1241
01:08:33,500 --> 01:08:38,300
Maybe add, before we wrap up. 
You wanna shout out where people

1242
01:08:38,300 --> 01:08:40,700
can learn more about, oh, bowl 
or yeah? 

1243
01:08:40,700 --> 01:08:42,200
How they can find you and they 
are. 

1244
01:08:42,300 --> 01:08:43,700
Again, thanks so much for coming
on. 

1245
01:08:45,100 --> 01:08:46,500
Yeah, thank you guys for having 
us. 

1246
01:08:46,500 --> 01:08:50,500
It's been a great discussion. 
He had to find out more about 

1247
01:08:50,500 --> 01:08:53,500
obol, best place to probably 
linked into the communities 

1248
01:08:53,500 --> 01:08:55,300
through Twitter. 
You can just find us a doable 

1249
01:08:55,300 --> 01:08:58,000
Network and we have a cool 
ambassador program. 

1250
01:08:58,000 --> 01:09:00,899
We have a great Discord, we just
well tomorrow. 

1251
01:09:00,899 --> 01:09:04,000
We're actually launching our 
Research Forum with the 

1252
01:09:04,000 --> 01:09:07,899
distributed sequencer. 
Peace, as first one for people 

1253
01:09:07,899 --> 01:09:10,399
to get some debate on and then 
we'll actually build out the 

1254
01:09:10,399 --> 01:09:12,200
cosmos section of the Research 
Forum. 

1255
01:09:12,200 --> 01:09:15,600
So if you guys are interested in
getting involved there, In the 

1256
01:09:15,600 --> 01:09:17,300
next. 
Well this proposal. 

1257
01:09:17,500 --> 01:09:19,399
Yeah. 
In the coming days, you'll be 

1258
01:09:19,399 --> 01:09:22,300
able to see it. 
And yeah, I'll pitch the sheen 

1259
01:09:22,300 --> 01:09:25,000
but thank you guys for having us
and really appreciate it. 

1260
01:09:26,700 --> 01:09:27,800
Yeah. 
And nothing. 

1261
01:09:27,800 --> 01:09:29,100
Major. 
Dad, thank you very much. 

1262
01:09:29,100 --> 01:09:31,700
This has been super fun to talk 
in the nitty-gritty of 

1263
01:09:31,700 --> 01:09:34,300
validators because normally we 
don't get to talk about. 

1264
01:09:34,300 --> 01:09:37,600
You know bare metal version of 
cloud versus Cosmos or L2 and 

1265
01:09:37,600 --> 01:09:39,899
their architecture. 
So I'm going to be a grateful of

1266
01:09:39,899 --> 01:09:42,500
this chance for to get really 
into the technical nitty-gritty 

1267
01:09:42,500 --> 01:09:44,500
and podcast. 
I hope they're all as technical 

1268
01:09:44,500 --> 01:09:48,399
as this one. 
Thank you for joining us on this

1269
01:09:48,399 --> 01:09:50,800
week's episode. 
We release new episodes every 

1270
01:09:50,800 --> 01:09:52,800
week. 
You can find And subscribe to 

1271
01:09:52,800 --> 01:09:56,300
the show on iTunes Spotify, 
YouTube SoundCloud or wherever. 

1272
01:09:56,400 --> 01:09:59,000
Every listen to podcast. 
And if you have a Google home or

1273
01:09:59,000 --> 01:10:01,800
Alexa device, you can tell it to
listen to the latest episode of 

1274
01:10:01,800 --> 01:10:05,700
the epicenter podcast, go to 
epicenter, .t V /, subscribe for

1275
01:10:05,700 --> 01:10:08,300
a full list of places where you 
can watch and listen, while 

1276
01:10:08,300 --> 01:10:10,600
you're there, be sure to sign up
for the newsletter so you get 

1277
01:10:10,600 --> 01:10:12,900
new episodes in your inbox as 
they're released. 

1278
01:10:13,600 --> 01:10:16,000
If you want to interact with us 
guests or other podcast 

1279
01:10:16,000 --> 01:10:18,800
listeners, you can follow us on 
Twitter and please leave us a 

1280
01:10:18,808 --> 01:10:21,600
review on iTunes helps people 
find the show and we're always 

1281
01:10:21,600 --> 01:10:24,500
happy to read them. 
Well thanks so much and we look 

1282
01:10:24,500 --> 01:10:25,700
forward to being back next week.