1
00:00:02,000 --> 00:00:04,320
Speaker 1: All right, cool. What a way to start an episode,

2
00:00:05,519 --> 00:00:08,199
just leading off with our technical prowess and expertise.

3
00:00:08,560 --> 00:00:13,640
Speaker 2: Hey Warren, Yeah, I really set that up nicely because

4
00:00:14,000 --> 00:00:17,760
I've for sure been having any issues. But maybe I'll

5
00:00:17,800 --> 00:00:20,719
just ignore that for a second. Jump straight to the point.

6
00:00:21,239 --> 00:00:23,760
We have a survey going for the podcast. It's of

7
00:00:23,839 --> 00:00:26,839
an Adventures in DevOps dot com slash survey, but you

8
00:00:26,839 --> 00:00:31,879
can see it everywhere. Please submit responses because it's a

9
00:00:31,920 --> 00:00:35,479
good feedback for us, something critical and thoughtful. If you'll

10
00:00:35,520 --> 00:00:41,960
win some a Tobos credits. And if it's not, well,

11
00:00:42,000 --> 00:00:43,439
there's not a lot that I can do about it

12
00:00:43,479 --> 00:00:45,560
at that point.

13
00:00:47,520 --> 00:00:52,320
Speaker 1: If it's not helpful feedback, then just put some contact

14
00:00:52,320 --> 00:00:54,399
details in there and I will contact you and we'll

15
00:00:54,399 --> 00:00:57,359
have a good chat about it if you're so interested.

16
00:00:57,759 --> 00:01:01,439
I'm pretty excited today because we've got Paul Marston here

17
00:01:01,479 --> 00:01:03,600
with this as well. Paul, Welcome to the show.

18
00:01:04,599 --> 00:01:07,239
Speaker 3: Hello, thank you for affording me the time. Yeah, So

19
00:01:07,879 --> 00:01:10,959
just to introduce myself, So, I work for Anchor slash

20
00:01:10,959 --> 00:01:15,879
Web three. I head up the note operations, so basically

21
00:01:15,959 --> 00:01:19,000
twenty four to seven running of blockchain nodes for integration

22
00:01:19,079 --> 00:01:22,400
partners that we've brought on board and also running you know,

23
00:01:22,480 --> 00:01:25,599
other nodes that we run specifically for our enterprise customers

24
00:01:25,599 --> 00:01:29,599
and other customers to access other blockchains of the networks. So, yeah,

25
00:01:29,640 --> 00:01:31,640
thank you for having me. Nice to be here, nice

26
00:01:31,680 --> 00:01:32,120
to meet you all.

27
00:01:32,239 --> 00:01:36,400
Speaker 1: Yeah, for sure, I'm looking forward to this conversation because, well,

28
00:01:36,439 --> 00:01:39,599
for many reasons. One, I think it's super interesting to

29
00:01:39,760 --> 00:01:42,680
understand or just like to get some insight into what

30
00:01:43,120 --> 00:01:47,959
running infrastructure for Web three looks like when you have

31
00:01:48,079 --> 00:01:52,200
like a Web two background, because there are some different challenges.

32
00:01:52,280 --> 00:01:54,719
And I'm particularly excited to have you on the show

33
00:01:54,799 --> 00:01:58,040
because I'm very familiar with your work because a Polygon,

34
00:01:58,159 --> 00:02:01,439
we're a customer of yours, and you run a pretty

35
00:02:01,439 --> 00:02:05,560
significant amount of infrastructure on our behalf and do a

36
00:02:05,599 --> 00:02:08,680
fantastic job of it. I'll be upfront with that, like

37
00:02:09,599 --> 00:02:12,360
we Yeah, we don't even give a second thought to

38
00:02:12,439 --> 00:02:16,280
the infrastructure that y'all run for us, because it's just

39
00:02:16,400 --> 00:02:20,639
always there. And so I think that was one of

40
00:02:20,680 --> 00:02:22,439
the reasons I was excited to have you on this show,

41
00:02:22,479 --> 00:02:26,599
because you've clearly put the time and effort into the

42
00:02:26,639 --> 00:02:29,280
project to figure out how to make these things run

43
00:02:29,360 --> 00:02:35,599
at scale. So there we go. So give us a

44
00:02:35,639 --> 00:02:39,560
little bit about your background before you got into Web three,

45
00:02:39,639 --> 00:02:42,319
what like, what choices you make in life that brought

46
00:02:42,360 --> 00:02:43,159
you to this moment.

47
00:02:44,159 --> 00:02:47,800
Speaker 3: Yeah, that's a great question. So yeah, similar to us.

48
00:02:48,199 --> 00:02:50,479
I've been in ANKA for a year now and similar

49
00:02:50,479 --> 00:02:53,000
to as I mentioned in my interview before I joined,

50
00:02:53,280 --> 00:02:57,360
so I've had quite a different ten years doing one

51
00:02:57,400 --> 00:02:59,680
thing ten years doing another. So yeah, I started out

52
00:03:00,479 --> 00:03:04,120
as an underwriter of all things, working in a call center,

53
00:03:04,400 --> 00:03:09,360
working on mainframe based you know, black and green screen

54
00:03:09,800 --> 00:03:14,560
terminals effectively for a retail company in the UK, taking

55
00:03:14,599 --> 00:03:17,120
applications and then deciding if people got loans or not

56
00:03:17,199 --> 00:03:20,000
based on some score that was spat out of you know,

57
00:03:20,879 --> 00:03:24,080
let's call it an arbitrary scoring algorithm for people's credit scores.

58
00:03:26,080 --> 00:03:28,240
And then then sort of slowly moved on from there

59
00:03:28,240 --> 00:03:31,599
doing more in depth and more technical elements. It was

60
00:03:31,680 --> 00:03:33,759
mainly an operational role that was to start with, but

61
00:03:33,800 --> 00:03:37,080
more technical elements in the let's call it Web two

62
00:03:37,360 --> 00:03:40,599
but specifically sort of financial services, moving on to doing

63
00:03:40,639 --> 00:03:45,120
testing and analytics, you know, requirements gathering for software builds,

64
00:03:45,120 --> 00:03:49,240
et cetera. And then I think that the main the

65
00:03:49,319 --> 00:03:52,039
main takeaway from like about three or four years of

66
00:03:52,080 --> 00:03:55,280
that period was I started working on migrations for customers.

67
00:03:55,719 --> 00:03:57,879
So they would come to where I was working at

68
00:03:57,879 --> 00:04:01,240
the time, first data, and we we would effectiveably do

69
00:04:01,360 --> 00:04:04,319
gap analysis between what they ran today for credit card processing,

70
00:04:04,680 --> 00:04:07,800
loan processing, et cetera, and how different our system was

71
00:04:07,840 --> 00:04:09,840
and what we needed to do in order to uplift

72
00:04:09,840 --> 00:04:12,280
our system or change their processes to bring them on board.

73
00:04:12,680 --> 00:04:15,919
And I think one thing I will say is even

74
00:04:15,919 --> 00:04:18,040
said this to my wife at the weekend. Working in

75
00:04:18,079 --> 00:04:23,079
a fast paced environment like you know, financial services migrations

76
00:04:23,079 --> 00:04:28,079
and i'm sure other migrations for other software, it really

77
00:04:28,120 --> 00:04:30,959
gives you a great background in dealing with things that

78
00:04:31,040 --> 00:04:34,759
you just cannot plan for. Every single event that we had,

79
00:04:34,800 --> 00:04:36,639
there was always something that came up that we've forgotten

80
00:04:36,639 --> 00:04:39,680
about or hadn't been captured as a requirement, et cetera.

81
00:04:40,079 --> 00:04:42,959
And being able to think quickly and because you have

82
00:04:43,000 --> 00:04:45,279
a set period where you need to migrate these things right,

83
00:04:45,319 --> 00:04:47,399
people want to use their credit cards to pay for things,

84
00:04:48,199 --> 00:04:50,920
you know, being able to being in that position having

85
00:04:50,959 --> 00:04:54,279
to think quickly, act quickly, resolve issues and move forward.

86
00:04:54,319 --> 00:04:55,920
It was always fixed forward. You know, there was never

87
00:04:56,000 --> 00:04:59,720
any going back. Yeah, I think it sets you up

88
00:04:59,759 --> 00:05:02,319
for for any role that you do in the future.

89
00:05:02,360 --> 00:05:04,800
So yeah, that's that was like migrations, and then I

90
00:05:04,879 --> 00:05:07,720
moved on to working on more digital focused products. That

91
00:05:07,839 --> 00:05:10,920
was the later part of my financial services background. I

92
00:05:10,920 --> 00:05:13,600
was working at Visa, I was looking enough to work

93
00:05:13,639 --> 00:05:15,839
on the Apple payroll out in the UK when they

94
00:05:15,839 --> 00:05:18,759
came to the UK, working with Apple and various other

95
00:05:18,800 --> 00:05:21,759
tokenization providers after that as well, So that was good.

96
00:05:21,759 --> 00:05:24,480
And then yeah, on the on the web free side,

97
00:05:24,519 --> 00:05:28,240
So it's it's almost I shouldn't say this, but I'll

98
00:05:28,279 --> 00:05:30,279
say it anyway, but it's almost like a love story

99
00:05:30,319 --> 00:05:33,639
between me and this guy I met in Discord and

100
00:05:33,720 --> 00:05:37,000
he's gonna hate that I've said that, but yeah, so

101
00:05:37,000 --> 00:05:39,879
so me and me and Pische or Peter. You may

102
00:05:39,879 --> 00:05:42,720
see him in Telegram and he's all over web free.

103
00:05:43,000 --> 00:05:46,920
But we we met. I think it's probably twenty seventeen,

104
00:05:46,920 --> 00:05:49,360
back end of twenty seventeen or twenty eighteen. We met

105
00:05:49,360 --> 00:05:54,360
in Discord for Horizon, you know, the crypto, and from

106
00:05:54,360 --> 00:05:56,199
there just hit it off, you know. We we had

107
00:05:56,399 --> 00:06:01,720
similar opinions, not the Peter would say necessarily that my

108
00:06:01,759 --> 00:06:04,360
opinion would be correct against his, but we had similar

109
00:06:04,360 --> 00:06:07,519
opinions in how we should be setting up servers, provisioning

110
00:06:07,560 --> 00:06:10,800
Linux running nodes, and you know that back then it

111
00:06:10,879 --> 00:06:14,279
was it was the secure node that Horizon had launched

112
00:06:14,319 --> 00:06:16,720
at that time, and yeah, we just we just had

113
00:06:16,959 --> 00:06:20,240
you know, very similar approaches to things, and naturally that

114
00:06:21,279 --> 00:06:23,720
came together and we actually ran a small startup for

115
00:06:23,800 --> 00:06:26,720
us a short time and then you know, i'd life

116
00:06:26,720 --> 00:06:28,040
got in the way of that and that kind of

117
00:06:28,120 --> 00:06:30,480
dwindled out. Peter moved on and continued to work in

118
00:06:30,519 --> 00:06:34,360
web Free, came to Anchor. I was at the time,

119
00:06:34,399 --> 00:06:37,720
I was finishing golf a contract for a UK based acquirer,

120
00:06:37,759 --> 00:06:40,600
so still doing some financial services work. And then I

121
00:06:40,639 --> 00:06:45,000
did another startup just a year prior to coming to Anchor,

122
00:06:45,199 --> 00:06:47,519
and then Peter got in touch and he was like, hey,

123
00:06:47,600 --> 00:06:50,120
there's a great opening here. It's very similar to what

124
00:06:50,160 --> 00:06:51,839
we've done previously. Why don't you come and join me?

125
00:06:52,680 --> 00:06:54,079
And yeah, and that's how I ended up here. And

126
00:06:54,120 --> 00:06:56,199
I'm just coming up to a year being in to

127
00:06:56,319 --> 00:06:58,079
Anchor right on.

128
00:06:58,720 --> 00:07:02,839
Speaker 1: Very cool. So for someone who's not spent a lot

129
00:07:02,879 --> 00:07:07,000
of time working in web three specific to like the

130
00:07:07,079 --> 00:07:12,120
infrastructure that powers it. What would you say are the

131
00:07:12,160 --> 00:07:16,959
most significant holly shit factors that they experience.

132
00:07:19,600 --> 00:07:24,600
Speaker 3: So from an infrastructure perspective, probably the scale. You know,

133
00:07:25,000 --> 00:07:28,040
certainly where we are, the number of bed and you

134
00:07:28,079 --> 00:07:32,040
know we're our selling point. Our USP is run it

135
00:07:32,079 --> 00:07:36,720
on bear metal, get the best performance possible, have many

136
00:07:36,920 --> 00:07:40,199
independently working systems, so you're not going to worry about

137
00:07:40,199 --> 00:07:45,279
what're losing one, three, five, whatever, your services stormline and yeah,

138
00:07:45,319 --> 00:07:46,920
you know, do it at a cost, do it at

139
00:07:47,079 --> 00:07:50,279
at the right cost to me all those factors, and yeah,

140
00:07:50,319 --> 00:07:54,279
so really the scale at which we have we provisioned

141
00:07:54,319 --> 00:07:56,879
hardware or anchor versus any of the organizations I've worked

142
00:07:56,920 --> 00:07:59,319
for in the past, with the exception of probably Visa,

143
00:07:59,439 --> 00:08:02,680
I would say, yeah, the scale of the hardware, the

144
00:08:02,680 --> 00:08:05,720
the not so much the effort in managing it, but

145
00:08:05,839 --> 00:08:08,319
ensuring that you have you know, the right rollouts, the

146
00:08:08,399 --> 00:08:11,120
right answer will playbooks to configure this host, that host,

147
00:08:11,120 --> 00:08:14,959
et cetera. On the right infrastructure's code in place. You know,

148
00:08:15,000 --> 00:08:18,439
it's significant, And yeah, I think that's the main difference.

149
00:08:18,519 --> 00:08:21,519
I think the other element to it as well is

150
00:08:22,079 --> 00:08:24,879
just the sheer overhead of managing that on a twenty

151
00:08:24,920 --> 00:08:27,959
four to seven three sixty five basis. We don't have

152
00:08:28,040 --> 00:08:30,439
bank holidays in Web three. We did, we did in

153
00:08:30,480 --> 00:08:32,919
financial services, and we used to have this think called

154
00:08:33,240 --> 00:08:35,360
we used to have this think call the weekend. That

155
00:08:35,399 --> 00:08:39,320
doesn't seem to make sist in Web three. So yeah,

156
00:08:39,919 --> 00:08:40,519
scale maintenance.

157
00:08:40,559 --> 00:08:42,440
Speaker 1: And I didn't realize that was specific to Web three.

158
00:08:42,480 --> 00:08:45,200
I thought that got killed by COVID. That's that's my

159
00:08:45,279 --> 00:08:46,519
misunderstanding there.

160
00:08:49,159 --> 00:08:49,279
Speaker 3: Now.

161
00:08:49,320 --> 00:08:52,559
Speaker 1: I think when it talked, when you're talking about scale, like,

162
00:08:52,600 --> 00:08:59,559
one of the things that really sync in for me

163
00:09:00,919 --> 00:09:02,799
was each of the nodes. You know, because when you're

164
00:09:02,799 --> 00:09:06,879
talking about high availability, fault tolerance, redundant see that sort

165
00:09:06,919 --> 00:09:11,600
of stuff in a decentralized environment, what you're actually talking

166
00:09:11,639 --> 00:09:15,879
about there is every single node has to have a complete,

167
00:09:16,799 --> 00:09:20,679
accurate copy of the entire blockchain.

168
00:09:21,240 --> 00:09:24,480
Speaker 3: To the extent that it needs to to serve its requirement. Right,

169
00:09:24,559 --> 00:09:27,559
So so we run different types of nodes. We have

170
00:09:28,240 --> 00:09:31,120
which mainly mainly come down as free categories, full node,

171
00:09:31,120 --> 00:09:34,120
which is you know, limited states at the you know,

172
00:09:34,559 --> 00:09:37,519
generally serves requests at the tip of the chain. And

173
00:09:37,559 --> 00:09:39,720
then we have the archive nodes, which, as you point

174
00:09:39,759 --> 00:09:42,039
out there, yeah, all required to store states all the

175
00:09:42,039 --> 00:09:43,799
way back to the genesis block and be able to

176
00:09:43,840 --> 00:09:46,720
serve that on you know, all day, every day twenty

177
00:09:46,799 --> 00:09:48,000
you know, three sixty five.

178
00:09:50,000 --> 00:09:50,799
Speaker 1: Yeah, for sure.

179
00:09:51,320 --> 00:09:52,720
Speaker 3: Just to add on to that as well, that the

180
00:09:52,840 --> 00:09:54,720
amount of data you have to store, you know, for

181
00:09:54,799 --> 00:09:59,919
an archive node, we're talking terabytes and terabytes, which for

182
00:10:00,080 --> 00:10:03,480
an independent service would be unheard of in the Web

183
00:10:03,559 --> 00:10:07,759
two world, right, you would probably have many services consuming

184
00:10:07,799 --> 00:10:10,919
from an enormous database as opposed to that note over

185
00:10:10,960 --> 00:10:13,759
there having five terabytes, that note over there having five terabytes,

186
00:10:13,799 --> 00:10:15,799
et cetera. So that's another good difference.

187
00:10:17,600 --> 00:10:22,720
Speaker 2: So having transition from global payments infrastructure working with like

188
00:10:22,919 --> 00:10:28,399
Visa and some other payments companies into the Web three world, like,

189
00:10:28,440 --> 00:10:30,759
what sort of environment where you met with like is

190
00:10:30,799 --> 00:10:35,000
it common for people to transition from Web two? I mean,

191
00:10:35,080 --> 00:10:37,519
I see there's a lot of overlap in payments and

192
00:10:37,559 --> 00:10:42,039
financial structures within the Web three ecosystem, so you know,

193
00:10:42,080 --> 00:10:44,960
maybe there's some alignment there or was it completely different,

194
00:10:45,000 --> 00:10:47,120
you know, unexpected things coming up left and right that

195
00:10:47,440 --> 00:10:51,759
you just hadn't had experience with having been onside before.

196
00:10:51,919 --> 00:10:55,919
Speaker 3: Yeah, So a great, great question. I think there's like two.

197
00:10:56,039 --> 00:10:59,279
There's probably two areas where it differs quite a bit.

198
00:10:59,360 --> 00:11:02,600
So like in the Web two space, a lot of

199
00:11:02,600 --> 00:11:06,759
the time there are there are lockins with vendors who

200
00:11:06,840 --> 00:11:10,759
sold your product, and with that comes additional bolt on

201
00:11:10,799 --> 00:11:15,000
products that you take as an organization because because you

202
00:11:15,039 --> 00:11:18,360
know you can, you can build a cohesive and hopefully

203
00:11:18,399 --> 00:11:22,240
you know, coherent platform to serve credit card traffic, loan traffic,

204
00:11:22,279 --> 00:11:24,360
you know, whatever you need to debit card traffic, et cetera.

205
00:11:24,679 --> 00:11:28,159
And in doing that, you almost make a decision about

206
00:11:28,960 --> 00:11:31,679
a lot of your infrastructure based on one key product

207
00:11:31,720 --> 00:11:34,240
that you need, and then as a result of taking

208
00:11:34,279 --> 00:11:36,240
that key product, you get all these other things as well.

209
00:11:36,320 --> 00:11:40,120
So you kind of mold yourself to working within those

210
00:11:40,159 --> 00:11:42,639
constraints of what those products have and what you've got

211
00:11:42,639 --> 00:11:44,080
off the shelf, and what is the key product that

212
00:11:44,120 --> 00:11:46,720
you've usually bought, whereas in Web three I would say

213
00:11:46,720 --> 00:11:51,320
there's there's there's less of that obviously, you know from

214
00:11:51,960 --> 00:11:54,720
we're not buying it in the Web three space, we're

215
00:11:54,759 --> 00:11:57,879
not buying in products that we run as such, or

216
00:11:58,399 --> 00:12:01,120
let's say a billing platform that we need to implement

217
00:12:01,200 --> 00:12:03,720
and run as part of some kind of processing platform.

218
00:12:04,039 --> 00:12:06,720
It's more that we're you know, our vendors primarily are

219
00:12:06,919 --> 00:12:10,639
our bare metal hosting providers who we deal with and

220
00:12:10,720 --> 00:12:13,799
you know, maintain good relationships with. So I would say

221
00:12:14,440 --> 00:12:18,039
there's more, there's more freedom to choose in the web

222
00:12:18,080 --> 00:12:23,039
free space, and we can dictate our own path more.

223
00:12:24,840 --> 00:12:28,399
I think the main differences between the approach to let's

224
00:12:28,399 --> 00:12:34,600
say development, release management and let's say notification of changes

225
00:12:34,639 --> 00:12:36,960
and version increments, et cetera in the Web two space

226
00:12:37,039 --> 00:12:41,120
versus Web three is web Web three. It happens instantly, right,

227
00:12:41,159 --> 00:12:43,559
you know, we can we can come in on a

228
00:12:43,600 --> 00:12:46,159
morning and a blockchain team that we've worked with can

229
00:12:46,200 --> 00:12:49,000
announce there's a hard falk tomorrow, and we've got to

230
00:12:49,000 --> 00:12:51,240
be ready. It doesn't matter if you're on in ten nodes,

231
00:12:51,840 --> 00:12:55,200
forty eight nodes, however many nodes. You know, the expectation

232
00:12:55,320 --> 00:12:58,080
is that you're ready. To Contrast that with what would

233
00:12:58,080 --> 00:13:00,879
have happened in Web two, we would have tested that

234
00:13:00,919 --> 00:13:03,200
for weeks. You know. I was just joking on a

235
00:13:03,240 --> 00:13:06,759
call with some guys the other day. They they were

236
00:13:06,799 --> 00:13:10,799
talking to someone loosely links to banking. Let's say, I

237
00:13:10,840 --> 00:13:13,320
can't say more than that, and they were saying, oh, yeah,

238
00:13:13,440 --> 00:13:16,159
so they said it's a six month project. I was like, whoa, whoa,

239
00:13:16,360 --> 00:13:18,720
I don't know you, you've not worked in this industry before.

240
00:13:18,720 --> 00:13:22,320
Then every finance project starts out as a six month project,

241
00:13:23,000 --> 00:13:25,879
and then three years later we're still working on implement

242
00:13:26,000 --> 00:13:29,120
to get VP and and and a lot of that is,

243
00:13:29,200 --> 00:13:31,679
you know, obviously there's there's decision making and you know,

244
00:13:31,799 --> 00:13:34,759
changes attack et cetera, and general evolution of what it

245
00:13:34,840 --> 00:13:37,399
is that you want to deploy and offer to your customers.

246
00:13:38,000 --> 00:13:41,840
But in some cases, you know your your timeline for development.

247
00:13:42,279 --> 00:13:44,679
In let's say the Web two space, the finance space

248
00:13:44,840 --> 00:13:48,039
will be shortened and you will have this huge chunk

249
00:13:48,080 --> 00:13:50,879
of testing that happens before things go into production. And

250
00:13:50,960 --> 00:13:54,840
I'm talking you know, business system testing, user acceptance testing,

251
00:13:55,279 --> 00:14:00,840
operational acceptance testing, et cetera, et cetera. So I think, yeah,

252
00:14:01,039 --> 00:14:04,159
I think there's more flexibility. We have more say over

253
00:14:04,240 --> 00:14:06,360
where we want to drive things in the web free space.

254
00:14:07,200 --> 00:14:08,879
In the Web two, I would say it's more rigid,

255
00:14:08,919 --> 00:14:12,519
but I wouldn't necessarily say that's all bad. I think

256
00:14:12,600 --> 00:14:15,360
there are good practices and processes that we can overlay from.

257
00:14:16,000 --> 00:14:18,759
Certainly my experience in Web two slash finance with what

258
00:14:18,919 --> 00:14:22,399
we do and how we approach the web free space.

259
00:14:24,879 --> 00:14:28,080
Speaker 2: Makes sense. So just to get a better understanding of

260
00:14:28,639 --> 00:14:30,840
what it is that you're sort of doing. Would it

261
00:14:30,919 --> 00:14:33,480
be accurate to say you're like a cloud provider for

262
00:14:34,039 --> 00:14:36,600
web three companies that are running their own chains and

263
00:14:36,919 --> 00:14:39,840
you're hosting the nodes for them, or there's a gross

264
00:14:39,879 --> 00:14:42,559
oversimplification of what I'm sure you're actually doing.

265
00:14:43,399 --> 00:14:47,519
Speaker 3: I mean, that doesn't that's not half bad in terms

266
00:14:47,559 --> 00:14:50,559
of the description. I think, you know, if you coming

267
00:14:50,600 --> 00:14:52,799
in cold and taking that away, I think I think

268
00:14:52,840 --> 00:14:56,360
that's pretty accurate. My only aversion is the cloud thing.

269
00:14:56,480 --> 00:14:59,039
So yes, it's cloud because it's not at your home,

270
00:15:00,279 --> 00:15:03,000
but we explicitly, don't you know, we have some critical

271
00:15:03,080 --> 00:15:07,440
services running in cloud infrastructure, AWS, GCP, etc. That's generally

272
00:15:07,519 --> 00:15:11,879
what I think people think of as cloud. But we're

273
00:15:11,919 --> 00:15:14,799
all about bare metal, least latency and highest performance.

274
00:15:14,840 --> 00:15:19,679
Speaker 2: If so, now this is my own for my own understanding,

275
00:15:20,039 --> 00:15:22,960
Like what's the benefit of using a provider that offers

276
00:15:23,039 --> 00:15:26,120
dedicated nodes for the chain that you're developing, Like don't

277
00:15:26,159 --> 00:15:28,960
you have some sort of consensus protocol and so all

278
00:15:29,039 --> 00:15:30,799
of your users are going to be well, some set

279
00:15:30,799 --> 00:15:32,279
of the users are going to be running their own

280
00:15:32,360 --> 00:15:35,720
nodes anyway, how does that work? Like, what's the benefit?

281
00:15:35,759 --> 00:15:37,799
And I've seen, like some of the cloud writers a

282
00:15:38,000 --> 00:15:42,039
ws et cetera, have pretty bad versions of managed blockchain things,

283
00:15:42,120 --> 00:15:44,559
and I have yet to understand why they do that.

284
00:15:45,399 --> 00:15:47,320
I'm sure they're not good. I'm sure you have some

285
00:15:47,759 --> 00:15:50,000
opinions about that as well, but like I just don't

286
00:15:50,039 --> 00:15:51,200
understand what the point is.

287
00:15:52,120 --> 00:15:54,840
Speaker 3: Yeah, So to come back to the point that was

288
00:15:54,879 --> 00:15:58,360
made earlier on actually, you know, the if you take

289
00:15:58,480 --> 00:16:00,600
a source, the fact that let's say for a developer,

290
00:16:00,639 --> 00:16:04,399
they have to firstly understand whatever this git repository is

291
00:16:04,440 --> 00:16:06,200
selling them in terms of how to set up a node.

292
00:16:06,600 --> 00:16:10,120
You know, I think there are there are a lot

293
00:16:10,159 --> 00:16:12,279
of good developers out there who have that skill set

294
00:16:12,320 --> 00:16:15,759
who can go from you know, like bootstrapping a Docker environment,

295
00:16:15,879 --> 00:16:18,519
running something in kumerinettes, et cetera, to then actually doing

296
00:16:18,919 --> 00:16:22,919
the code they want to do. But I think certainly

297
00:16:23,000 --> 00:16:26,080
there's there's a number of developers and I don't want

298
00:16:26,080 --> 00:16:28,200
to generalize anyone here, but there are certainly a number

299
00:16:28,240 --> 00:16:31,519
of developers who simply want to hid an API, and

300
00:16:32,399 --> 00:16:34,879
you know, let's say you need an Ethereum archive node

301
00:16:35,080 --> 00:16:39,159
or a Polygon archive node, you're talking about downloading for

302
00:16:39,320 --> 00:16:42,840
many days terabytes worth of data before your node is

303
00:16:42,879 --> 00:16:45,960
even ready to serve those requests. So yeah, So the

304
00:16:46,039 --> 00:16:49,600
simple answer is from from a developer standpoint, it's it's

305
00:16:49,720 --> 00:16:51,600
just plug and play. You know, you come up, you

306
00:16:51,679 --> 00:16:55,679
come up to our anchor website, you register, you start

307
00:16:55,720 --> 00:16:58,159
consuming traffic. If you want a higher rate limit, you

308
00:16:58,240 --> 00:17:00,559
pay a little bit of money. If you want lots

309
00:17:00,600 --> 00:17:02,159
of traffic, then you know, you come and talk to

310
00:17:02,240 --> 00:17:04,480
us about having an enterprise contract. So I think I

311
00:17:04,559 --> 00:17:06,720
think that's the main benefit for a developer. The other

312
00:17:07,759 --> 00:17:12,599
the other benefit, I guess is that ongoing maintenance version upgrades.

313
00:17:13,359 --> 00:17:16,279
You know, the redundancy that we offer and the latency

314
00:17:16,359 --> 00:17:19,519
that we offer, you know that that leads itself to

315
00:17:19,640 --> 00:17:23,480
an easier, let's say development and testing time frame for

316
00:17:23,599 --> 00:17:24,599
that specific development.

317
00:17:25,160 --> 00:17:27,839
Speaker 2: So just you know something that I'll basically there's a

318
00:17:27,920 --> 00:17:30,519
lot of parts that go from doing this, like from

319
00:17:30,599 --> 00:17:34,519
the software development to actually running the nodes, like for

320
00:17:34,720 --> 00:17:36,799
the network, for the for the chain that's out there,

321
00:17:36,960 --> 00:17:39,759
and that's a lot of infrastructure, a lot of process,

322
00:17:39,920 --> 00:17:42,720
and that's what's being automated, either helping with the development

323
00:17:42,839 --> 00:17:45,640
side or the testing or rolling out for what the

324
00:17:45,720 --> 00:17:48,039
new versions are that users should pull down and start

325
00:17:48,119 --> 00:17:51,839
running within their Whoever the node hosting providers are, you know,

326
00:17:51,880 --> 00:17:55,920
whether they're general population or whether they're independent companies or whatever. Okay,

327
00:17:55,920 --> 00:17:57,400
so there's a lot of work that actually needs to

328
00:17:57,440 --> 00:18:00,440
be done there make this work effectively, and you're solving

329
00:18:00,720 --> 00:18:01,640
everything in that space.

330
00:18:03,599 --> 00:18:08,960
Speaker 3: Absolutely, we are. Yeah, I like to think so. Yeah.

331
00:18:08,960 --> 00:18:10,839
Speaker 1: I think really good perspective to put on that is

332
00:18:10,920 --> 00:18:13,960
if you are, like, if you're a developer who wants

333
00:18:14,079 --> 00:18:18,920
to create the like a cryptopunk n FT, you know,

334
00:18:19,039 --> 00:18:23,400
the only thing you're interested in is selling cool little

335
00:18:23,599 --> 00:18:27,279
eight bit graphics, and the barrier to entry to that

336
00:18:27,960 --> 00:18:31,519
without having access to hosted RPC nodes, the barrier to

337
00:18:31,759 --> 00:18:34,519
entry is you've got to set up a node that

338
00:18:34,720 --> 00:18:38,079
has terabytes and terabytes of data on it just to

339
00:18:38,319 --> 00:18:44,920
generate your your NFTs. And that's where services like anchor

340
00:18:44,960 --> 00:18:49,319
come in and take take that barrier away from you

341
00:18:50,720 --> 00:18:54,200
or remove that barrier for you. One question I want

342
00:18:54,240 --> 00:18:56,160
to ask, just to elaborate on it a little bit.

343
00:18:56,200 --> 00:18:59,880
You mentioned hard for earlier. Can you elaborate a little

344
00:18:59,880 --> 00:19:01,400
bit on what a hard fork is.

345
00:19:03,079 --> 00:19:07,440
Speaker 3: Yeah, So, in the simplest terms, it's a breaking change

346
00:19:07,799 --> 00:19:13,839
which requires a version upgrade. So essentially, a blockchain will

347
00:19:13,920 --> 00:19:18,039
run to a particular block, and at that block time,

348
00:19:19,079 --> 00:19:22,000
the protocol is in the network, how it talks, how

349
00:19:22,039 --> 00:19:23,960
the notes talk to one another. They will undergo a

350
00:19:24,039 --> 00:19:28,200
breaking change, which means unless you're running this new version

351
00:19:28,279 --> 00:19:31,240
of software, your node is basically going to sit there

352
00:19:31,279 --> 00:19:33,759
stalled and isn't able to communicate with the others here

353
00:19:33,839 --> 00:19:38,000
with them and then you know, propagate blocks and receive transactions,

354
00:19:38,039 --> 00:19:38,480
et cetera.

355
00:19:39,480 --> 00:19:42,960
Speaker 2: So I've always looked at this as imagine the blockchain

356
00:19:43,079 --> 00:19:45,720
is your database, and so of hard work is where

357
00:19:45,720 --> 00:19:48,519
you make a non back whards compatible change to the

358
00:19:48,599 --> 00:19:50,920
schema of the database, and all of the clients of

359
00:19:50,960 --> 00:19:53,119
the world need to decide how they're going to interpret

360
00:19:53,240 --> 00:19:56,519
that new new schema of the database. I don't know

361
00:19:56,599 --> 00:19:59,640
that's always worked for me. I don't know if that's accurate, but.

362
00:20:01,880 --> 00:20:04,440
Speaker 3: No, there's no harm in that description. Yeah, absolutely. I

363
00:20:04,480 --> 00:20:06,799
think the key element you've got there, right, is that

364
00:20:06,880 --> 00:20:10,480
it's a breaking change, and yeah, that's the main thing.

365
00:20:12,279 --> 00:20:14,359
Speaker 1: Yeah, and I think the unique constraint to it is

366
00:20:14,480 --> 00:20:20,599
that the decentralized aspect of it, because when you hit

367
00:20:20,720 --> 00:20:26,160
that block, you're now dependent on everyone who operates a

368
00:20:26,319 --> 00:20:30,559
node on that network, or not everyone, but a majority

369
00:20:30,599 --> 00:20:33,680
of the node operators on that network to adopt that

370
00:20:33,960 --> 00:20:39,079
change and implement it. Otherwise you end up with a

371
00:20:39,160 --> 00:20:43,440
network that now has multiple people claiming that they have

372
00:20:44,400 --> 00:20:45,240
the latest block.

373
00:20:46,519 --> 00:20:47,960
Speaker 3: Yeah, yeah, absolutely.

374
00:20:48,440 --> 00:20:50,640
Speaker 2: I mean that's an interesting thing here because let's say

375
00:20:50,640 --> 00:20:54,480
the Web two world, if you've exposed your internal database

376
00:20:54,519 --> 00:20:57,400
to your customers and they're you know, making I mean,

377
00:20:57,519 --> 00:20:59,440
no one would ever do this, right, No one ever

378
00:20:59,519 --> 00:21:03,240
did this history of the world, for sure. But you know,

379
00:21:03,400 --> 00:21:06,119
your customers have access to the schema, to the underlying

380
00:21:06,200 --> 00:21:07,960
data that you have in your database, maybe with their

381
00:21:08,000 --> 00:21:11,519
own special user name and password, and you make a

382
00:21:11,559 --> 00:21:13,960
schema change there. I mean, in the Web two world,

383
00:21:14,079 --> 00:21:16,440
I just can't ever fathom a story where you like

384
00:21:16,519 --> 00:21:18,799
go around to each of your customers are like, Okay,

385
00:21:18,839 --> 00:21:20,559
we're going to make a change. I need you to,

386
00:21:21,160 --> 00:21:25,119
you know, change your software to actually support this. And

387
00:21:25,400 --> 00:21:27,279
having worked in a bunch of these companies where we

388
00:21:27,279 --> 00:21:29,799
even had an API, you know, rest or you know

389
00:21:29,920 --> 00:21:32,799
something else, Getting your customers to actually make a change

390
00:21:32,839 --> 00:21:36,480
and start using the latest version is I mean, that's

391
00:21:36,559 --> 00:21:38,880
a gargratuan task that I don't think I ever saw

392
00:21:38,920 --> 00:21:41,200
a company actually do successfully. Oh yeah, we'll just make

393
00:21:41,240 --> 00:21:43,640
a breaking change and get all our customers to update.

394
00:21:43,880 --> 00:21:47,440
Was easier said than done. And I feel like in

395
00:21:47,559 --> 00:21:50,839
the blockchain world you actually end up in this state

396
00:21:51,000 --> 00:21:54,240
where you have customers I'll call them customers, not really customers. Right,

397
00:21:54,400 --> 00:21:58,160
the end users who are using utilizing the chain will

398
00:21:58,240 --> 00:22:01,319
have still been using the previous software version, which doesn't

399
00:22:01,400 --> 00:22:04,160
understand what happens after the fork, and that's sort of

400
00:22:04,200 --> 00:22:09,559
what creates this maybe two future chains or whatever you're utilizing.

401
00:22:11,079 --> 00:22:13,839
Speaker 3: Yeah, it's kind of a leader follower mentality, isn't it.

402
00:22:13,839 --> 00:22:18,759
I think? And ultimately the developers and the foundations of

403
00:22:18,839 --> 00:22:21,519
these networks are free to choose how they want to

404
00:22:22,599 --> 00:22:26,359
how they want to push the protocol, and really who

405
00:22:26,519 --> 00:22:30,160
is it is their choice, whereas in the web two

406
00:22:30,240 --> 00:22:33,880
space and a financial setting, you know you possibly have

407
00:22:34,359 --> 00:22:37,640
shareholders and who are big customers and all this kind

408
00:22:37,640 --> 00:22:41,240
of stuff. So it is Yeah, that's another good point.

409
00:22:41,400 --> 00:22:45,480
Change management and management of external customers who consume your service.

410
00:22:46,880 --> 00:22:49,720
It's much more it was much more complex to manage

411
00:22:49,720 --> 00:22:52,279
a much more bigger a task to get them ready

412
00:22:52,319 --> 00:22:55,400
for those new releases, as you've alluded to, than in

413
00:22:55,440 --> 00:22:58,519
the Web three space. You know, you're either on the

414
00:22:58,559 --> 00:22:59,960
train or you're on the train unfortunately.

415
00:23:00,599 --> 00:23:02,319
Speaker 2: I mean there's like a huge I feel like there's

416
00:23:02,319 --> 00:23:04,799
actually quite a difference in perspective here because in Web

417
00:23:04,880 --> 00:23:08,799
two the customers don't really necessarily influence each other, right,

418
00:23:08,920 --> 00:23:12,400
Like what one customer is hitting your version one API

419
00:23:12,440 --> 00:23:14,799
and different cstomers hitting your version two API. There's not

420
00:23:15,119 --> 00:23:17,720
motivation for them to switch other than the value of

421
00:23:17,880 --> 00:23:21,240
using a later version. But in the Web three space,

422
00:23:21,960 --> 00:23:24,559
they likely want to be on the same network or

423
00:23:24,640 --> 00:23:27,079
within the same network on the latest version because there

424
00:23:27,240 --> 00:23:30,599
is cross communication between different users of the nose. I mean,

425
00:23:30,640 --> 00:23:34,440
they're all contributing to the same ledger or chain in

426
00:23:34,519 --> 00:23:37,240
a way, so they're not doing it in isolation. And

427
00:23:37,319 --> 00:23:40,839
that pretty much means as a blockchain company that's or

428
00:23:40,920 --> 00:23:44,000
creating anyone who's creating a chain. You're just writing the

429
00:23:44,119 --> 00:23:47,960
software that you think a majority of your customers want,

430
00:23:48,359 --> 00:23:50,799
which I hope you're doing. If you're not in the

431
00:23:51,359 --> 00:23:54,200
blockchain world. But you almost have to be doing it

432
00:23:54,279 --> 00:23:56,359
because if you do it and they and the majority

433
00:23:56,400 --> 00:23:59,279
don't accept the whatever happens after the hard fork, you

434
00:23:59,680 --> 00:24:01,440
did all that work for sure, now that you can't

435
00:24:01,519 --> 00:24:02,599
force them to migrate.

436
00:24:03,480 --> 00:24:06,640
Speaker 3: Yeah, yeah, indeed, I think I think the main the

437
00:24:06,759 --> 00:24:11,240
main difference to call out here is that generally when

438
00:24:11,279 --> 00:24:14,920
the when the breaking changes come, they will impact an

439
00:24:14,960 --> 00:24:17,799
element of the network or the way a certain way

440
00:24:17,839 --> 00:24:19,880
that you could figure a node, or that you can

441
00:24:21,480 --> 00:24:24,200
how you stake tokens for that particular network or that

442
00:24:24,359 --> 00:24:29,200
kind of thing, whereas something customer facing is much less

443
00:24:29,319 --> 00:24:31,039
likely to happen. And what I mean is, you know

444
00:24:31,799 --> 00:24:36,319
it's there are far there are fewer changes for the

445
00:24:36,440 --> 00:24:40,759
API that faces the customers that they're consuming, you know, individually, Generally,

446
00:24:41,000 --> 00:24:43,240
you know, if it's going to be EVM compatible, it's

447
00:24:43,319 --> 00:24:46,920
always going to be VM compatible. And all those methods

448
00:24:46,960 --> 00:24:50,200
available in various name spaces generally perpetuate, you know, and

449
00:24:50,240 --> 00:24:53,000
they don't change what you will sometimes see. And again,

450
00:24:53,119 --> 00:24:56,240
as you mentioned, you may see you may see a

451
00:24:56,359 --> 00:24:58,720
new method or a new name space open which gives

452
00:24:58,759 --> 00:25:00,880
you some other a yeah that you can play with,

453
00:25:01,119 --> 00:25:03,880
you know, that can happen. But yeah, I think generally

454
00:25:03,960 --> 00:25:07,240
the hard fault changes aren't things that our customers would

455
00:25:07,559 --> 00:25:10,319
see or be aware of unless we missed one, and

456
00:25:10,400 --> 00:25:13,160
our you know knows will stop runt. Yeah.

457
00:25:13,160 --> 00:25:16,039
Speaker 1: I think another way to think about that is that

458
00:25:16,359 --> 00:25:20,480
it's much more community driven for Web three. You know,

459
00:25:20,720 --> 00:25:24,720
as a Web two business. It's probably a horrible example,

460
00:25:24,799 --> 00:25:27,240
but like Visa could say, you know what, we're not

461
00:25:27,400 --> 00:25:31,680
going to support the US dollar anymore on April first,

462
00:25:32,799 --> 00:25:37,400
will deny all transactions priced in US dollars, And as

463
00:25:37,440 --> 00:25:42,880
a customer of Visa, you can go damn okay, and

464
00:25:43,160 --> 00:25:45,039
you can look for someone else, you can train take

465
00:25:45,039 --> 00:25:47,079
your business somewhere else, but that's your only option. And

466
00:25:47,200 --> 00:25:50,240
in a Web three world, you can propose a hard

467
00:25:50,319 --> 00:25:53,839
fork saying hey, we're dropping support for this, and the

468
00:25:53,960 --> 00:25:57,079
Web three community can look at that hard fork, can

469
00:25:57,599 --> 00:26:01,559
either adopt it or say, you know, I don't think

470
00:26:01,599 --> 00:26:03,640
we're going to go that direction, and the community just

471
00:26:03,720 --> 00:26:07,759
doesn't adopt the chain the change and goes off and

472
00:26:07,799 --> 00:26:08,720
operates on their own.

473
00:26:10,559 --> 00:26:13,200
Speaker 3: I think I think I can see I can see

474
00:26:13,240 --> 00:26:16,960
the argument there. I think the contrast of what you're

475
00:26:17,000 --> 00:26:19,839
suggesting in Web two versus what you're suggesting webs free

476
00:26:19,960 --> 00:26:23,960
is significantly different, Like we're not going to do us

477
00:26:24,079 --> 00:26:28,240
already more of visa. I mean I actually want.

478
00:26:29,559 --> 00:26:31,480
Speaker 2: Yeah, I actually do. Wonder if you have any like

479
00:26:31,640 --> 00:26:34,240
statistics or no information about this, because I mean, I

480
00:26:34,319 --> 00:26:37,119
think the world has seen enough public hard forks and

481
00:26:37,440 --> 00:26:39,839
the way most of them as far as my experience

482
00:26:39,960 --> 00:26:42,039
is gone, I guess the hard works I know of

483
00:26:42,400 --> 00:26:45,799
primarily are the ones in ethereum. The world pretty much

484
00:26:45,839 --> 00:26:49,640
adopts the majority of the change. And I wonder how

485
00:26:49,720 --> 00:26:53,440
many companies that are running chains end up doing some

486
00:26:53,559 --> 00:26:56,960
sort of hard fork where it's got rejected by the community,

487
00:26:58,000 --> 00:27:00,720
Like does that? Does that ever happen that the majority

488
00:27:00,759 --> 00:27:02,079
and we just don't hear about it.

489
00:27:02,680 --> 00:27:04,920
Speaker 3: I don't know, I don't think so. I mean, isn't

490
00:27:04,960 --> 00:27:08,440
that the isn't that the background of ethereum versus ethereum

491
00:27:08,720 --> 00:27:11,480
classic of sorts? Obviously, I don't know. That was so

492
00:27:11,599 --> 00:27:13,400
long ago. I can't remember exactly how that happened.

493
00:27:13,400 --> 00:27:16,880
Speaker 2: But that's definitely the community saying you know, what happened

494
00:27:16,920 --> 00:27:20,759
here is not okay and just rejecting out and arguably

495
00:27:20,759 --> 00:27:22,400
it's the same thing that happens with any hard work

496
00:27:22,480 --> 00:27:26,960
though that goes through. There's also still the proof of

497
00:27:27,039 --> 00:27:30,240
work Ethereum chain that's out there that you people are

498
00:27:31,200 --> 00:27:34,839
performing work to mine the coins and get value out.

499
00:27:34,920 --> 00:27:38,039
But it's such a small part of the majority of

500
00:27:39,200 --> 00:27:41,519
compared to the size the number of nodes that are

501
00:27:41,559 --> 00:27:45,039
being added to the current Ethereum network.

502
00:27:45,519 --> 00:27:48,640
Speaker 3: Yeah, indeed, so, I mean we had the pectoralup grade

503
00:27:48,640 --> 00:27:54,839
recently on Aleski, one of the Ethereum test nets. Sorry

504
00:27:54,839 --> 00:27:57,960
I should mention if if people don't know, so, I

505
00:27:58,000 --> 00:28:01,960
mean that was problematic because there were there are multiple

506
00:28:02,039 --> 00:28:05,599
different client options you can run. This is another rabbit

507
00:28:05,640 --> 00:28:08,480
hole that we can run down and just give you

508
00:28:08,480 --> 00:28:11,079
a bit of background there. So primarily we run Aragon

509
00:28:11,200 --> 00:28:14,079
clients what's called Aragon to run our archive nodes, and

510
00:28:14,200 --> 00:28:17,279
then full notes we generally run you know, geth which

511
00:28:17,319 --> 00:28:20,519
is as you're probably aware that the main Ethereum client

512
00:28:21,000 --> 00:28:24,200
or Maine. I guess it's debatable based on what side

513
00:28:24,240 --> 00:28:26,680
of the fence you're on, but yeah, there there were

514
00:28:26,960 --> 00:28:31,440
there are essentially three. There were. There were a number

515
00:28:31,440 --> 00:28:34,440
of changes that happened for Pectra which were implemented correctly

516
00:28:34,480 --> 00:28:36,960
in some clients and not in others. Now, the deep

517
00:28:37,039 --> 00:28:39,480
technical understanding of it all, I couldn't go into and

518
00:28:39,559 --> 00:28:41,519
tell you, but but we ended up in a position where,

519
00:28:43,079 --> 00:28:45,119
you know, for a couple of weeks, probably slightly longer,

520
00:28:45,559 --> 00:28:47,559
we had notes that were going off in one direction

521
00:28:48,440 --> 00:28:50,920
and others were going in another direction. And I think

522
00:28:52,440 --> 00:28:54,319
it was a difficult time put it that way, And

523
00:28:54,519 --> 00:28:56,839
so I think it's I think the most important thing

524
00:28:57,039 --> 00:28:59,759
for these foundations is that they have, you know, all

525
00:28:59,839 --> 00:29:04,640
of the distributed or decentralized developers, even if they're generating,

526
00:29:04,720 --> 00:29:07,640
you know, even if they're developing clients, not just running nodes,

527
00:29:08,319 --> 00:29:11,240
you know, singing from the same hymnsheet and you know,

528
00:29:11,359 --> 00:29:13,319
taking the same root forward if you will. So yeah,

529
00:29:13,319 --> 00:29:15,640
I think that's a good example of where we've seen

530
00:29:15,720 --> 00:29:18,920
problems on a hard walk. And there are other examples where,

531
00:29:19,839 --> 00:29:22,400
you know, some other chains are like the Cosmos SDK

532
00:29:22,519 --> 00:29:27,000
based chains where you can't actually you can't upgrade them

533
00:29:27,000 --> 00:29:30,000
ahead of time. It's like another thing. Contrast it to

534
00:29:30,039 --> 00:29:32,519
Web two. Right, So in Web two you've got like

535
00:29:32,599 --> 00:29:34,440
eight weeks, I don't know something to test your new

536
00:29:34,519 --> 00:29:38,559
client version. Cosmos SDK, it's like on this block you upgrade,

537
00:29:39,240 --> 00:29:41,839
so I can't do it two blocks before, ten blocks before,

538
00:29:41,880 --> 00:29:45,680
a week before. No, on this block you upgrade. So

539
00:29:45,839 --> 00:29:48,160
it's you know, you don't get the benefit of testing

540
00:29:48,200 --> 00:29:50,880
and seeing how resilient that latest version of code is.

541
00:29:51,559 --> 00:29:53,720
Speaker 2: Do you you know the thing that keeps going around

542
00:29:53,720 --> 00:29:55,880
in the back of my mind right now is security.

543
00:29:56,279 --> 00:30:00,599
H No, I think I am that's sort of my specialty,

544
00:30:00,720 --> 00:30:02,640
so I tend to get in this area very quickly.

545
00:30:02,759 --> 00:30:04,960
But I know that there's a lot of madness in

546
00:30:05,000 --> 00:30:07,240
the world right now, with things like s bombs and

547
00:30:07,480 --> 00:30:10,559
supply chain attacks. But so whether or not or how

548
00:30:10,640 --> 00:30:13,400
bad it is is a separate question. But I'm sort

549
00:30:13,440 --> 00:30:16,759
of curious like the comparison, like, are do you feel

550
00:30:16,839 --> 00:30:21,359
like malicious attackers coming in through a supply chain attack

551
00:30:21,480 --> 00:30:24,039
on the tools and technology that you're utilizing to you know,

552
00:30:24,119 --> 00:30:28,680
run your platform is significantly worse or you know, similar

553
00:30:28,759 --> 00:30:31,400
to what would happen if you weren't you know, while

554
00:30:31,400 --> 00:30:34,359
we're working at Visa. Although that's payment, so it's you

555
00:30:34,440 --> 00:30:36,319
know that that's sort of bad in a different angle.

556
00:30:36,400 --> 00:30:39,839
But you know, compared to privacy data that a web

557
00:30:39,920 --> 00:30:41,200
a web two app may be.

558
00:30:41,799 --> 00:30:47,920
Speaker 3: Storing, that's a good question which I probably don't have

559
00:30:48,200 --> 00:30:50,119
an end depth answer for but I think you know

560
00:30:50,200 --> 00:30:53,240
you're talking to supply chain attacks, and as much of

561
00:30:53,640 --> 00:30:56,680
I consume or I buy some either I bring in

562
00:30:56,759 --> 00:30:59,240
some open source software or I buy a product from someone,

563
00:30:59,400 --> 00:31:02,119
and there is some kind of attack back to embedded

564
00:31:02,200 --> 00:31:02,559
within that.

565
00:31:03,160 --> 00:31:06,799
Speaker 2: So it's whether or not you see higher supply chain

566
00:31:06,839 --> 00:31:10,559
attacks through say like dependencies or open source technologies that

567
00:31:10,640 --> 00:31:15,200
you're utilizing to manage or monitor your data center compared

568
00:31:15,200 --> 00:31:17,000
to the ones that would be utilized in a non

569
00:31:17,079 --> 00:31:18,680
Web three world. So you know, if I run my

570
00:31:18,759 --> 00:31:21,079
own data center, if I'm AWS or whatever and I'm

571
00:31:21,160 --> 00:31:25,359
using Grafana, Nagios or whatever, someone you know, no one

572
00:31:25,400 --> 00:31:28,000
wants to talk about using. Are they the same technologies

573
00:31:28,000 --> 00:31:31,319
since you have the same concerns or are they modeled differently?

574
00:31:31,480 --> 00:31:34,720
Are they targeted for web web three? And so do

575
00:31:34,799 --> 00:31:37,079
you find that the processes that you would put in

576
00:31:37,119 --> 00:31:40,440
place in your company would be different from the ones

577
00:31:40,480 --> 00:31:42,400
that would be say up and running and say a

578
00:31:42,519 --> 00:31:44,880
visa or another large organization.

579
00:31:45,880 --> 00:31:49,039
Speaker 3: Yeah, gotch So I would say reassuringly, that's one of

580
00:31:49,079 --> 00:31:52,880
the areas where Web two and Web three ten to

581
00:31:53,039 --> 00:31:55,559
not differ all that much. I think approaches to security

582
00:31:55,799 --> 00:31:58,759
a fairly standard, and thankfully we've got you know, well

583
00:31:58,839 --> 00:32:03,359
defined external best practices that influence how we should, you know,

584
00:32:03,480 --> 00:32:06,680
go about doing business, both in both in Web two

585
00:32:06,720 --> 00:32:10,000
and Web three. You know, we've recently done Stock two

586
00:32:10,240 --> 00:32:12,599
audit as well, so we're fully stock too compliant and

587
00:32:13,039 --> 00:32:15,640
you know we're ongoing we're being audited to that. But

588
00:32:15,759 --> 00:32:17,279
I think there's another tick in the box that we're

589
00:32:17,319 --> 00:32:20,000
doing the right things, taking the right approaches, et cetera.

590
00:32:20,480 --> 00:32:23,119
But in terms of the tooling, I would say there's

591
00:32:23,839 --> 00:32:28,400
many similarities. You know, we use Graffana to monitor our nodes,

592
00:32:28,720 --> 00:32:32,359
report on their status, that height, how many requests per

593
00:32:32,400 --> 00:32:36,119
second they're managing, et cetera. So from that perspective, I

594
00:32:36,160 --> 00:32:39,680
think a lot of the tooling is similar. I think

595
00:32:39,799 --> 00:32:41,119
basically the answer to that question.

596
00:32:41,079 --> 00:32:49,039
Speaker 2: Is no, there's nothing specially you're doing compared to what

597
00:32:49,079 --> 00:32:51,200
you would be doing if you were in any other

598
00:32:51,400 --> 00:32:56,079
vertical or using any different technology stack. Well, so I

599
00:32:56,200 --> 00:32:59,079
hitted at this before, Actually, how good are the cloud

600
00:33:00,160 --> 00:33:03,319
like public cloud? I hate this term public cloud supported

601
00:33:03,400 --> 00:33:06,880
hyperscalars uh manage blockchain solutions?

602
00:33:08,480 --> 00:33:11,400
Speaker 3: You know, I've never used one, so it would be

603
00:33:11,480 --> 00:33:14,960
unfair of me to comment in terms of, let's say,

604
00:33:15,039 --> 00:33:18,079
giving them, giving you a bad impression of them. I

605
00:33:18,720 --> 00:33:22,240
would expect that they have good documentation based on the

606
00:33:22,279 --> 00:33:25,200
providers who you know, who develop them. I suspect they've

607
00:33:25,200 --> 00:33:29,000
got you know, good developer support and run relatively stably

608
00:33:29,240 --> 00:33:31,680
and were I able to you know, if I could

609
00:33:31,720 --> 00:33:33,799
say that about all of the blockchains and the nodes

610
00:33:33,839 --> 00:33:35,279
and the networks we ran, and it would be a

611
00:33:35,319 --> 00:33:38,759
wonderful thing. But I couldn't say that. So from that perspective,

612
00:33:38,799 --> 00:33:42,160
I think as an organization, if you're if you're looking

613
00:33:42,279 --> 00:33:45,880
to do something on blockchain that doesn't necessarily need to

614
00:33:45,920 --> 00:33:49,400
be public and decentralized, you know they possibly they're a

615
00:33:49,440 --> 00:33:49,839
good option.

616
00:33:51,400 --> 00:33:53,400
Speaker 2: I'm just bringing up here in my comparison of when

617
00:33:53,519 --> 00:33:56,200
someone in the UK says something versus the English that

618
00:33:56,359 --> 00:34:01,000
Americans are supposed to understand. Ah, because there's there's quite

619
00:34:01,240 --> 00:34:03,359
a nice comparison chart there, But no, I think I

620
00:34:03,359 --> 00:34:05,519
think that's a good point, and so maybe I'll extend

621
00:34:05,559 --> 00:34:08,159
it a little bit. Uh. Do you find that the

622
00:34:08,239 --> 00:34:12,400
conversation of using hyperscalar nodes comes up or it's just

623
00:34:12,440 --> 00:34:14,639
like not something that's frequently talked about because I don't

624
00:34:14,639 --> 00:34:17,079
personally understand the use case for what they're providing, and

625
00:34:17,199 --> 00:34:19,559
I'm just interested that there's like a whole world that

626
00:34:19,639 --> 00:34:21,159
I've just never been exposed to.

627
00:34:22,159 --> 00:34:26,519
Speaker 3: Well, I think, you know again, I think they're targeted

628
00:34:26,639 --> 00:34:32,239
toward someone who, let's you know, take any financial services company.

629
00:34:33,920 --> 00:34:37,639
They don't want to buy, you know, consumer hardware and

630
00:34:37,760 --> 00:34:40,039
run it in their data center, right. They want to

631
00:34:40,079 --> 00:34:43,079
go to to IBM or too Oracle, or to some

632
00:34:43,320 --> 00:34:47,280
you know, some big blue chip organization who's going to say, yes,

633
00:34:47,360 --> 00:34:49,280
you can have that bit of kit, and with that

634
00:34:49,440 --> 00:34:51,880
bit of kit, I'm going to give you three years

635
00:34:52,239 --> 00:34:56,280
unlimited on site support, free replacements, et cetera. You know,

636
00:34:56,400 --> 00:34:59,719
you can't there isn't There isn't there isn't a blockchain

637
00:34:59,719 --> 00:35:02,960
STA you could take off the shelf necessarily that has

638
00:35:03,039 --> 00:35:05,920
that sort of service layer wrapped around it, ready to go.

639
00:35:06,320 --> 00:35:09,760
And I think that's why, you know, a big enterprise

640
00:35:09,840 --> 00:35:15,280
type customer may look to approach an implementation with one

641
00:35:15,320 --> 00:35:19,159
of those managed services or not necessarily managed, but you know,

642
00:35:19,320 --> 00:35:26,400
broadly supported unknown stacks. I guess now I have in

643
00:35:26,599 --> 00:35:29,920
terms of conversations I generally get involved in integrating new

644
00:35:29,960 --> 00:35:34,000
blockchains and ensuring that the ones that we case two

645
00:35:34,079 --> 00:35:36,800
now are scaled correctly in the right locations, et cetera.

646
00:35:36,920 --> 00:35:39,760
So personally, I haven't been involved in those conversations. I'm

647
00:35:39,800 --> 00:35:42,599
sure they will happen, you know. I'm sure our sales

648
00:35:42,639 --> 00:35:45,840
team are covering all manner of things that I couldn't

649
00:35:45,840 --> 00:35:48,719
even dream up that are being discussed in the web

650
00:35:48,760 --> 00:35:51,039
three space. But no, not, not specifically, I haven't an

651
00:35:51,039 --> 00:35:52,719
approached to integrating one of those.

652
00:35:53,719 --> 00:35:56,719
Speaker 2: What always scale scares me. My sales team is on

653
00:35:56,840 --> 00:35:59,480
the innovative side, you know that mean things that you

654
00:35:59,599 --> 00:36:02,599
you know, you clearly haven't developed yet, because are things

655
00:36:02,639 --> 00:36:04,360
that are going to be coming on the pipeline.

656
00:36:05,880 --> 00:36:08,880
Speaker 3: Could we do this? Or now we've got X and Y,

657
00:36:09,320 --> 00:36:13,239
can't we make I don't know Z not necessarily right?

658
00:36:14,480 --> 00:36:17,000
Speaker 2: Well, you know, I think this goes both ways. I

659
00:36:17,039 --> 00:36:19,559
think there's the I think we talk a lot about

660
00:36:19,559 --> 00:36:21,440
this on a ventures and DevOps, So the audience is

661
00:36:21,519 --> 00:36:24,880
probably sick of hearing about it. If you haven't pulled

662
00:36:24,920 --> 00:36:27,199
your customers in to ask them where to innovate, then

663
00:36:27,239 --> 00:36:30,760
you're probably building things that they don't care about. But

664
00:36:30,840 --> 00:36:33,199
if they're innovating, then they should be ahead of you.

665
00:36:33,599 --> 00:36:35,119
And so I think what the important thing is is

666
00:36:35,199 --> 00:36:37,440
being able to move quickly once you've identified. So a

667
00:36:37,519 --> 00:36:40,320
sales team doing a good job would mean that they're

668
00:36:40,400 --> 00:36:43,159
able to figure out what they can promise that hasn't

669
00:36:43,199 --> 00:36:46,000
been built yet, because I mean, if they're promising things

670
00:36:46,039 --> 00:36:48,239
that can't be built, that's that's where the issue is.

671
00:36:49,119 --> 00:36:52,880
Speaker 3: Yes, yeah, indeed, indeed maybe, I mean there's an element

672
00:36:53,679 --> 00:36:55,639
the Websuo space was full of that. I would say

673
00:36:57,679 --> 00:36:59,519
we used to always pull out this diagram when we

674
00:36:59,559 --> 00:37:02,480
first met with clients, and it was I think it's

675
00:37:02,519 --> 00:37:05,039
a typical accenter diagram, you know, the rope swing, where

676
00:37:05,199 --> 00:37:07,440
you know they this is what they wanted, this is

677
00:37:07,519 --> 00:37:10,840
how their requirements were gathered, this is this is what

678
00:37:10,960 --> 00:37:13,280
the developers built, and this was the MVP that got

679
00:37:13,280 --> 00:37:15,280
on it. You know, it had all the elements of

680
00:37:15,320 --> 00:37:16,840
a rope swing, but it ain't a rope swing.

681
00:37:17,239 --> 00:37:19,519
Speaker 1: That's such a great meme if you if you haven't

682
00:37:19,719 --> 00:37:22,599
seen that, maybe we can put it in the show

683
00:37:22,639 --> 00:37:28,199
notes for you because it's just it's just so fantastic. So, Paul,

684
00:37:28,559 --> 00:37:30,000
one of the things I wanted to ask you is

685
00:37:30,039 --> 00:37:32,559
that how many different chains are you supporting at anchor?

686
00:37:32,960 --> 00:37:35,159
Speaker 3: If I think about my most recent table, I think

687
00:37:35,199 --> 00:37:37,199
it was over one hundred cells. Now that there may

688
00:37:37,280 --> 00:37:42,000
be sorry, a hundred rows. Still I still make my

689
00:37:42,039 --> 00:37:44,599
own notes manually, right, even in the words three digital space,

690
00:37:44,639 --> 00:37:47,039
I'm still still making a confidence table just to keep

691
00:37:47,199 --> 00:37:49,840
just to keep things organized. But yeah, it's well, well

692
00:37:49,880 --> 00:37:52,519
over one hundred. I couldn't give you an exact number

693
00:37:52,559 --> 00:37:54,920
because I think even today one of my team has

694
00:37:55,000 --> 00:37:58,519
been finishing golf implementing one. So yeah, it's constantly evolving.

695
00:37:59,320 --> 00:38:01,119
Speaker 1: I know. Wa it looks that is it's one hundred

696
00:38:01,360 --> 00:38:06,480
independent products that your team is supporting. And then we've

697
00:38:06,480 --> 00:38:10,599
already talked about the issues with hard forks and making

698
00:38:10,639 --> 00:38:15,239
sure that they're staying in sync and operating correctly. So

699
00:38:15,320 --> 00:38:18,760
you're doing that across one hundred different products, which seems

700
00:38:18,800 --> 00:38:19,559
like a lot to take on.

701
00:38:20,400 --> 00:38:22,760
Speaker 3: It is that now there are there are various ways

702
00:38:23,679 --> 00:38:26,000
let's say one approaches that, and you know, let's say

703
00:38:26,239 --> 00:38:31,480
teams might approach that, but for the for the most part,

704
00:38:31,920 --> 00:38:35,840
there are there are there are only a handful, let's say,

705
00:38:36,000 --> 00:38:42,480
of unique clients that blockchain teams use. And so what

706
00:38:42,559 --> 00:38:44,400
I mean by that is, you know, Aragon is a

707
00:38:44,400 --> 00:38:46,679
perfect example there. We can use that for Polygon, we

708
00:38:46,719 --> 00:38:48,679
can use it for BMB smart chain, we can use

709
00:38:48,679 --> 00:38:51,960
it for ethereum, et CEPA and separate, and you know

710
00:38:52,079 --> 00:38:55,280
even some teams have taken Aragon and made and early

711
00:38:55,960 --> 00:38:57,719
I don't know. I mean it's testing prod right, So

712
00:38:57,800 --> 00:38:59,840
it's like an Aragon that we can use on the

713
00:39:00,199 --> 00:39:03,280
optimistic roll ups, et cetera, et cetera. So so there

714
00:39:03,320 --> 00:39:07,000
are obviously a good word used to using the web

715
00:39:07,079 --> 00:39:12,800
two space synergies and ways we can converge. It's lovely buzzwords.

716
00:39:13,079 --> 00:39:16,039
You know, how you approach things, right, So let's say,

717
00:39:16,039 --> 00:39:19,320
for example, you need to host an op roll up

718
00:39:19,519 --> 00:39:24,159
or even one of these most recent Eragon three, even

719
00:39:24,199 --> 00:39:27,440
the Aragon free client they've recently released. You could write

720
00:39:27,440 --> 00:39:30,480
a doc com post file and if you've had enough

721
00:39:30,559 --> 00:39:33,760
environment environment variables in that doc com post file, you

722
00:39:33,800 --> 00:39:35,719
could take it and run one chain with it, and

723
00:39:35,760 --> 00:39:38,880
then you just create another environment variable file and run

724
00:39:38,920 --> 00:39:42,119
a second chain and run a third chain, et cetera. So, yes,

725
00:39:42,199 --> 00:39:45,360
it is, it is. It is an overhead. I won't

726
00:39:45,400 --> 00:39:50,000
lie that. You know, obviously we're monitoring twenty four to

727
00:39:50,079 --> 00:39:53,440
seven we get alerts, and from that perspective, it does

728
00:39:53,519 --> 00:39:57,159
seem like a lot, But there are learnings from running

729
00:39:57,199 --> 00:40:00,159
one chain that we can overlay on another. There are

730
00:40:00,239 --> 00:40:04,119
ways to make certain clients behave better when they're pairing

731
00:40:04,199 --> 00:40:06,480
and sinking and you know, being able to stay at

732
00:40:06,519 --> 00:40:08,960
the tip. There are ways that we can configure clients

733
00:40:09,000 --> 00:40:12,320
that make them better in terms of responsiveness and latency

734
00:40:12,400 --> 00:40:15,840
for various requests, you know, by adjacent orbc on. All

735
00:40:15,920 --> 00:40:18,760
of those learnings you then roll out when you do

736
00:40:18,840 --> 00:40:23,000
the next integration of a similar client, et cetera, et cetera. So, yeah,

737
00:40:23,039 --> 00:40:25,320
it is a lot, but you know, we have to

738
00:40:25,400 --> 00:40:27,960
take from that what we can and reuse wherever we can.

739
00:40:28,400 --> 00:40:31,159
Speaker 2: When you when you have a hundreds of one hundred

740
00:40:31,239 --> 00:40:34,480
products that you're supporting here, it's not like you have

741
00:40:34,559 --> 00:40:37,440
a multi tenant solution where you have one hundred customers

742
00:40:37,599 --> 00:40:40,760
and they're all utilizing your product in a consistent way.

743
00:40:41,440 --> 00:40:44,199
I assume you're having you have to build integrations into

744
00:40:45,199 --> 00:40:47,519
each of those products to be able to understand how

745
00:40:47,519 --> 00:40:49,920
they're working, and not all of them are using the

746
00:40:50,039 --> 00:40:55,320
same protocols to do the management like it's like if

747
00:40:55,360 --> 00:40:59,760
one company had gRPC and another company was using you know,

748
00:41:00,039 --> 00:41:02,679
and weird other proto buff format, and then there's h GDP,

749
00:41:02,960 --> 00:41:05,239
and then there's someone's using rest or some other like

750
00:41:05,320 --> 00:41:10,440
each each company is basically conceiving of their own protocol.

751
00:41:11,079 --> 00:41:13,639
Speaker 3: Yeah, yeah, it's it's a it's a good call out.

752
00:41:13,760 --> 00:41:17,400
So actually generally the conversation we we've had has been around,

753
00:41:17,480 --> 00:41:21,920
you know, the operations of blockchain nodes. Obviously, the other

754
00:41:22,000 --> 00:41:23,639
elements of what we do here are anchor is we

755
00:41:23,800 --> 00:41:28,199
you know, we we've built our own cloud native you know,

756
00:41:28,440 --> 00:41:32,039
many multi protocols supporting load balancer, which is you know

757
00:41:32,239 --> 00:41:35,519
again it's a distributed load balancer in all the locations

758
00:41:35,559 --> 00:41:38,360
we want to be and we're we're building out our

759
00:41:38,400 --> 00:41:42,920
own global network as well, and so we can there.

760
00:41:43,679 --> 00:41:46,400
As I mentioned, there are similarities in how we run

761
00:41:46,719 --> 00:41:51,920
nodes because they're similar clients. Generally it's configuration and best

762
00:41:51,960 --> 00:41:55,079
practice approach to making those run the right way. But

763
00:41:55,239 --> 00:41:58,119
in in the load balancer from the load balance aside,

764
00:41:58,119 --> 00:42:00,599
because obviously that serves the customer request that are coming in.

765
00:42:01,519 --> 00:42:04,239
We we do have to do differentiation there as well.

766
00:42:04,320 --> 00:42:06,039
So as you mentioned, you know, you have like an

767
00:42:06,079 --> 00:42:09,519
ethereum like client, so it talks roughly we call that, Oh,

768
00:42:09,559 --> 00:42:12,280
it's an EVM client, right, or you get some nu

769
00:42:12,320 --> 00:42:15,079
answers to that it's EVM light, or you know, it's

770
00:42:15,119 --> 00:42:16,880
EVM but only up to a certain point, so it

771
00:42:16,920 --> 00:42:19,960
doesn't have these other new name spaces and new mesic calls,

772
00:42:20,000 --> 00:42:23,599
et cetera. And we're able to, you know, we abstract

773
00:42:23,639 --> 00:42:27,559
from that detail of the node, you know, effectively like

774
00:42:27,599 --> 00:42:30,480
a schema into the load balances. So the load balancer,

775
00:42:31,559 --> 00:42:34,599
you know, knows what that node can speak in terms

776
00:42:34,639 --> 00:42:37,119
of protocols and what it can speak in terms of

777
00:42:37,199 --> 00:42:41,400
you know, the APIs and the actual messages within that protocol. Yeah,

778
00:42:41,440 --> 00:42:46,079
there's a lot that we need to have in place

779
00:42:46,239 --> 00:42:49,559
and maintain, and but thankfully we're at the point now

780
00:42:49,599 --> 00:42:52,400
where generally the changes in the load balancer level are

781
00:42:52,440 --> 00:42:56,960
incremental and generally the changes that we make in terms

782
00:42:57,000 --> 00:42:59,880
of the approach to running the nodes is a g

783
00:43:00,039 --> 00:43:02,559
and it's incremental, and it's built upon, you know, the

784
00:43:02,639 --> 00:43:04,440
knowledge that we built up out the last of years

785
00:43:04,519 --> 00:43:06,599
just running these nodes all the time.

786
00:43:07,159 --> 00:43:10,480
Speaker 1: From my understanding, like load balancing is not load balancing

787
00:43:10,880 --> 00:43:13,559
as we think about it. In a Web two world, right,

788
00:43:13,639 --> 00:43:16,599
in a Web two world, you know it's the health check.

789
00:43:16,679 --> 00:43:16,920
Speaker 2: Cool.

790
00:43:17,079 --> 00:43:19,679
Speaker 1: Yeah, the health check is cool. We're pretty much okay.

791
00:43:20,239 --> 00:43:22,239
It's the route traffic to it. But in the Web

792
00:43:22,320 --> 00:43:25,360
three world, it's more than that, because you have your

793
00:43:25,519 --> 00:43:28,320
health check. Yeah, the service is up and available and

794
00:43:28,400 --> 00:43:32,440
respond it's responsive and able to take requests. But then

795
00:43:32,480 --> 00:43:35,679
you've got a follow up question. This node is operating,

796
00:43:35,800 --> 00:43:39,159
but is this node fully synchronized with the network, and

797
00:43:39,280 --> 00:43:42,239
if it's not, you can't route traffic to it. And

798
00:43:42,360 --> 00:43:46,719
then the third aspect of it is what's the request

799
00:43:47,360 --> 00:43:50,920
that's coming into the load balancer? For example, is this

800
00:43:52,039 --> 00:43:54,760
is it asking about a recent block or is it

801
00:43:54,920 --> 00:43:58,199
asking about a really old block that's only going to

802
00:43:58,280 --> 00:44:02,400
exist on archive nodes. And so now with that information,

803
00:44:02,639 --> 00:44:05,679
you know that there's only certain nodes that you can

804
00:44:05,800 --> 00:44:10,960
route this request to to give the caller the correct

805
00:44:11,079 --> 00:44:13,559
information back. And so that adds a whole new layer

806
00:44:13,599 --> 00:44:15,760
of complexity to load balancing.

807
00:44:16,559 --> 00:44:18,760
Speaker 2: I've got the analogy, I think. So if we go

808
00:44:18,880 --> 00:44:21,440
on the databases, like could you imagine running Reddus and

809
00:44:21,599 --> 00:44:26,320
Cassandra and my squl and an Aurora database and elastic

810
00:44:26,400 --> 00:44:30,039
search and having like whatever consensus protocol you had for

811
00:44:30,159 --> 00:44:33,280
figuring out like which is the primary nodes, which ones

812
00:44:33,280 --> 00:44:36,119
are secondary, and where to route requests automatically to the

813
00:44:36,159 --> 00:44:39,599
appropriate shards and also manage the infrastructure for that with

814
00:44:39,800 --> 00:44:42,119
only using a single piece of technology rather than using

815
00:44:42,159 --> 00:44:45,559
you know, dedicated pieces like separate pieces. Like that's that's

816
00:44:45,760 --> 00:44:46,800
as I see the problem.

817
00:44:47,960 --> 00:44:50,119
Speaker 3: Yeah, and so maybe it would be I have many

818
00:44:50,199 --> 00:44:54,199
retics is what's redici red eye?

819
00:44:55,880 --> 00:44:57,800
Speaker 2: You get decording the term. I think you are the

820
00:44:57,880 --> 00:44:58,880
first person to have.

821
00:44:59,599 --> 00:45:01,920
Speaker 3: So so yeah, maybe you would have many of a

822
00:45:02,039 --> 00:45:06,079
particular database instance type let's call it, and then you know,

823
00:45:06,159 --> 00:45:07,880
many of another one and many of another one. But

824
00:45:09,320 --> 00:45:11,719
but yeah, I mean it's challenging. There's not a day

825
00:45:11,800 --> 00:45:17,440
goes by where we're not discussing what the algorithm should

826
00:45:17,440 --> 00:45:20,440
be to load balance requests, right, And I don't mean

827
00:45:20,480 --> 00:45:24,039
that in a way that you know, we're immature and

828
00:45:24,119 --> 00:45:29,320
we're trying to build the algorithm. It's more every day

829
00:45:29,360 --> 00:45:32,159
we learn something new. Every day we learn, you know,

830
00:45:32,360 --> 00:45:34,280
or we get a new customer who interacts with our

831
00:45:34,320 --> 00:45:36,199
service in a slightly different way and they do a

832
00:45:36,440 --> 00:45:38,719
you know, maybe they do a slightly different sequence of

833
00:45:38,840 --> 00:45:43,239
calls to ultimately maybe achieve the same output as a

834
00:45:43,280 --> 00:45:45,360
different customer, and you know what would that mean in

835
00:45:45,440 --> 00:45:47,920
terms of how their requests are handle coming in and

836
00:45:48,000 --> 00:45:48,719
how they're rooted.

837
00:45:49,079 --> 00:45:49,639
Speaker 1: And I think.

838
00:45:51,000 --> 00:45:53,880
Speaker 3: You know this shouldn't be taken as a failure. It's

839
00:45:53,920 --> 00:45:57,519
like it's an acknowledgement of effectively we don't believe there's

840
00:45:57,559 --> 00:46:01,079
a perfect load balancing algorithm. I mean I I don't.

841
00:46:01,199 --> 00:46:03,559
I'm sure that you know, some of the younger members

842
00:46:03,559 --> 00:46:06,719
of the team would have their own subjective opinion about that, right,

843
00:46:07,679 --> 00:46:10,320
But I think you know, you get to the you

844
00:46:10,400 --> 00:46:12,719
get to the point given the volume of requests. You know,

845
00:46:12,800 --> 00:46:15,760
we're talking tens and tens of thousands a second right

846
00:46:15,800 --> 00:46:18,880
of requests that are coming in to be at ninety

847
00:46:19,000 --> 00:46:23,199
nine point nine nine percent. You know that's that's achievable,

848
00:46:23,440 --> 00:46:27,599
perfect divaspirational. You know, we as we discuss internally, and

849
00:46:27,719 --> 00:46:30,559
so we have anyway to get back to the question. So, yes,

850
00:46:30,679 --> 00:46:33,440
yes it's complex, and yes there is. Let's say you

851
00:46:33,800 --> 00:46:36,800
need to have a more fine grain control of where

852
00:46:36,800 --> 00:46:40,599
you root a request based on a better underlying knowledge

853
00:46:40,599 --> 00:46:42,679
of what that request is and what it's you know,

854
00:46:42,760 --> 00:46:46,119
what it's intended outcome is the perfect example is the

855
00:46:46,239 --> 00:46:48,840
one you gave. You know, a request comes in, it's

856
00:46:48,920 --> 00:46:50,920
for a I don't know, let's say block one thousand

857
00:46:50,960 --> 00:46:53,320
nine ethereum, that's got to go to an archive. Know

858
00:46:53,400 --> 00:46:55,519
that's not that block is you know the state for

859
00:46:55,599 --> 00:46:57,559
that block and all the information is not going to

860
00:46:57,559 --> 00:46:59,159
be on a full node, and we have to know

861
00:46:59,719 --> 00:47:02,639
when it's coming in. We have to interpret that and

862
00:47:02,800 --> 00:47:04,920
root it to a particular archive known. So we have

863
00:47:05,079 --> 00:47:07,239
you know, we have ruled in the load balance of

864
00:47:07,239 --> 00:47:10,360
that the gear towards rooting those requests correctly.

865
00:47:11,039 --> 00:47:12,679
Speaker 2: I think some people may be cheering, and I think

866
00:47:12,760 --> 00:47:16,840
others are gonna regret that I asked this question. Has

867
00:47:17,000 --> 00:47:19,880
AI had any impact on the web? Threw world for you?

868
00:47:20,039 --> 00:47:22,239
Speaker 1: Where we go? There's the magic word?

869
00:47:23,079 --> 00:47:26,360
Speaker 3: So you know what. I listened to the last podcast

870
00:47:26,760 --> 00:47:31,840
and it's interesting how you you almost tentatively or sheepishly

871
00:47:31,880 --> 00:47:34,719
approach having this question, you know, bringing this AI question in.

872
00:47:35,960 --> 00:47:37,840
So I'll be honest, right, So from a first of

873
00:47:37,840 --> 00:47:47,719
all standpoint, had I embraced the last oh and the

874
00:47:47,800 --> 00:47:49,480
last to be honest and the last start of I

875
00:47:49,639 --> 00:47:53,280
was in, if I'd embraced AI, I would have done

876
00:47:53,320 --> 00:47:55,599
stuff in half the time, and I didn't at that point,

877
00:47:56,079 --> 00:47:59,599
and more than anything that was, So this is just

878
00:47:59,639 --> 00:48:01,039
a person I'll say, I'll go on, I'll go on

879
00:48:01,079 --> 00:48:03,960
to bag stuff in a moment, more than anything that was,

880
00:48:04,000 --> 00:48:06,840
because I would needed to make sure I knew how

881
00:48:06,880 --> 00:48:10,119
it worked right. I was the only guy, or you know,

882
00:48:10,239 --> 00:48:12,880
one of a very small team doing development, and I

883
00:48:12,960 --> 00:48:15,960
felt like if I had I could say myself, I no,

884
00:48:16,159 --> 00:48:19,280
three weeks, six weeks here, But what's that going to

885
00:48:19,320 --> 00:48:21,639
cost me when I try and maintain this and operate

886
00:48:21,719 --> 00:48:25,480
it in a production environment, you know, for customers. So

887
00:48:25,719 --> 00:48:30,039
I shout away from it a bit there. Now at Anchor,

888
00:48:30,159 --> 00:48:33,119
we have embraced AI at the moment, we're learning and

889
00:48:33,360 --> 00:48:37,000
it is learning from us. You know, it understands blockchain,

890
00:48:37,079 --> 00:48:39,599
It understands that we've got a load balancer. It understands

891
00:48:39,639 --> 00:48:42,320
the end goal of what we're trying to do. But

892
00:48:42,400 --> 00:48:45,840
there are still some instances where we're asking it questions

893
00:48:46,119 --> 00:48:50,239
and we get a confident answer that we know isn't right.

894
00:48:50,960 --> 00:48:54,000
So yeah, we're just working to try and feed it

895
00:48:54,119 --> 00:48:59,159
more and take effectively take away some of those you know,

896
00:48:59,280 --> 00:49:03,519
easy to answer questions or easy to diagnose problems, and

897
00:49:03,639 --> 00:49:07,519
we allow the moniker do that for us, and we

898
00:49:07,559 --> 00:49:10,880
can ask a questions to try and assisters troubleshooting and

899
00:49:11,000 --> 00:49:15,760
assistance with helping the customer. But you know, it's early days,

900
00:49:15,800 --> 00:49:19,320
and I can see it rapid. It's already evolved massively,

901
00:49:19,679 --> 00:49:21,519
and I can see it only you know, the curve

902
00:49:21,639 --> 00:49:23,599
is exponential with these things, right. I can see it

903
00:49:23,679 --> 00:49:27,079
getting much more capable as the months go on, and

904
00:49:27,159 --> 00:49:29,719
I think we'll be levering leveraging it more and more.

905
00:49:30,119 --> 00:49:32,480
We like it, and I think used for the right thing,

906
00:49:32,559 --> 00:49:33,280
it's a great fol.

907
00:49:33,679 --> 00:49:36,239
Speaker 1: When you make statements like that, it seriously makes me

908
00:49:36,400 --> 00:49:39,840
question if I might be an AI, because I'm always

909
00:49:39,960 --> 00:49:43,360
super confident and also at the same time usually super wrong.

910
00:49:46,480 --> 00:49:52,719
Speaker 3: You're just another person on the internet, right, So what

911
00:49:52,840 --> 00:49:53,760
do you use.

912
00:49:53,760 --> 00:49:56,800
Speaker 1: For what's your tool stack from an opside look like?

913
00:49:56,880 --> 00:49:59,360
Are you guys using a lot of terror form answerable?

914
00:49:59,480 --> 00:50:00,920
Do you do Subernetes stuff?

915
00:50:01,079 --> 00:50:05,199
Speaker 3: What's that world look like? Yeah? Absolutely so, we we do.

916
00:50:05,679 --> 00:50:09,239
We use terraform. We on the node op side generally,

917
00:50:10,360 --> 00:50:13,440
we've we've we've created our own template if you will,

918
00:50:13,599 --> 00:50:18,000
that we consume and create terraform from that we then

919
00:50:18,079 --> 00:50:21,679
go off and manage the state on the hardware through

920
00:50:21,840 --> 00:50:25,079
if you see what I mean. So it's similar to

921
00:50:25,119 --> 00:50:26,960
what I mentioned before about if you have enough, if

922
00:50:27,000 --> 00:50:29,679
you have a dot com post file with enough environment variables,

923
00:50:29,760 --> 00:50:32,000
you can spin up any number of networks. And we've

924
00:50:32,039 --> 00:50:35,239
done a similar thing in terms of how we interact

925
00:50:35,320 --> 00:50:39,880
with how we'd launch nodes based on using terraform to

926
00:50:40,159 --> 00:50:42,480
do that launcher, but having this template in place to

927
00:50:42,559 --> 00:50:47,199
simplify things effectively, and yeah, we use answerable, we use

928
00:50:47,679 --> 00:50:49,639
all day long. We use a w X you know,

929
00:50:49,719 --> 00:50:53,440
to schedule playbooks running across hosts et cetera, you know,

930
00:50:53,559 --> 00:50:55,719
to push out security updates and that kind of thing.

931
00:50:57,360 --> 00:51:00,760
But yeah, we we split it. So we have some

932
00:51:01,000 --> 00:51:03,800
nodes that are you know, fully if not, if not

933
00:51:03,960 --> 00:51:06,599
close to fully automated, and we have others where our

934
00:51:06,679 --> 00:51:11,719
preferences to effectively approach the bear metal manually and set

935
00:51:11,800 --> 00:51:13,199
up the node in such a way because it's so

936
00:51:13,280 --> 00:51:14,960
different from the other ones, you know, we set it

937
00:51:15,039 --> 00:51:19,280
up in such a way that we can you know,

938
00:51:19,480 --> 00:51:21,679
do it right for a start, and then obviously create

939
00:51:21,760 --> 00:51:23,760
our own documentation off the back of that about how

940
00:51:23,800 --> 00:51:26,280
to maintain that so so yeah, we do. We do

941
00:51:26,440 --> 00:51:28,679
use quite a bit of Hashi cup stuff. I think

942
00:51:28,719 --> 00:51:30,719
the last podcast I listened to I was I was

943
00:51:30,760 --> 00:51:34,199
reading about open Tofu after that because someone was talking

944
00:51:34,239 --> 00:51:36,280
about open Tofu quite a bit, so I was actually

945
00:51:36,320 --> 00:51:40,239
reading about that this morning. So yeah, Hashi Cup stuff.

946
00:51:40,480 --> 00:51:45,079
And then in terms of other automation, generally it's running

947
00:51:45,079 --> 00:51:52,199
oh sorry, kubernettes. You mentioned we do run kubernettes, not

948
00:51:52,519 --> 00:51:56,840
not for our not for the RPC nodes. I would say,

949
00:51:56,880 --> 00:51:58,440
we use it in other area of the areas of

950
00:51:58,480 --> 00:52:01,199
the business. So where we want you know, bear metal

951
00:52:01,519 --> 00:52:06,559
close to bear metal performance, least latency, high high capability

952
00:52:06,559 --> 00:52:09,960
in terms of serving requests, will generally, you know, either

953
00:52:10,000 --> 00:52:13,199
do it via the auto deployer, which is which is

954
00:52:13,280 --> 00:52:16,679
powered by which we use Nomad behind another Hashi Court product,

955
00:52:17,000 --> 00:52:18,960
or will do them manually. And then if it's a

956
00:52:19,079 --> 00:52:21,800
lighter client and you know, recently launch like a small

957
00:52:21,840 --> 00:52:23,760
test net that we don't expect to run for ages,

958
00:52:23,800 --> 00:52:26,400
we'll use Kubernetes. So and you know, there are other

959
00:52:26,480 --> 00:52:30,320
areas of the business that also use Kubernetes outside of

960
00:52:31,280 --> 00:52:34,440
the note operations. So so yeah, we use quite a

961
00:52:34,440 --> 00:52:37,159
few of those orchestration tools and Hashi Court products.

962
00:52:39,159 --> 00:52:42,800
Speaker 1: And it seems like there's probably an adoption phase for

963
00:52:42,960 --> 00:52:45,440
those as well. Whenever you bring on a new chain

964
00:52:47,239 --> 00:52:50,719
doing like doing things manually, kind of hand curating it

965
00:52:50,800 --> 00:52:54,400
to figure out what the best the best set of

966
00:52:54,440 --> 00:52:57,599
configs and the right things to be monitoring and tuning

967
00:52:57,679 --> 00:52:59,760
for this are. And then as you learn that in

968
00:52:59,840 --> 00:53:02,239
from you start turning that into turning it over to

969
00:53:02,280 --> 00:53:02,800
your automation.

970
00:53:03,760 --> 00:53:07,639
Speaker 3: Yeah. Absolutely that. Yeah, so one of the things actually,

971
00:53:07,719 --> 00:53:10,679
that was my surprise this morning. So I've been working

972
00:53:10,719 --> 00:53:14,639
on new blockchain integration and so usually when I do

973
00:53:14,760 --> 00:53:17,800
the manual one, I've deliberately set it up so system

974
00:53:17,880 --> 00:53:20,639
D or Docker doesn't restart it automatically, because I want

975
00:53:20,639 --> 00:53:22,880
to know when that from the point I started. I

976
00:53:22,960 --> 00:53:25,159
want to see it fail and you know, see what

977
00:53:25,280 --> 00:53:28,920
that longevity is if you will. And yeah, that was

978
00:53:29,000 --> 00:53:31,599
my surprise this morning, Like four nodes were down and

979
00:53:31,679 --> 00:53:33,440
I was like, oh, why are these down? Surely I've

980
00:53:33,440 --> 00:53:35,519
set these to restart, And it's because I'd set them

981
00:53:35,599 --> 00:53:37,960
to not restart so I could see the point at

982
00:53:37,960 --> 00:53:41,320
which they fell over. But yeah, it is an element

983
00:53:41,400 --> 00:53:43,559
of that what we generally do as part of the

984
00:53:43,840 --> 00:53:47,159
integrations now and this is you know, something I've put

985
00:53:47,199 --> 00:53:49,199
in place since I started. So we want to make

986
00:53:49,239 --> 00:53:51,679
sure that we hit if we're going to do manual nodes,

987
00:53:51,719 --> 00:53:53,239
and we agree that that's going to be, you know

988
00:53:53,320 --> 00:53:55,920
how we run most of the nodes, we always have

989
00:53:56,039 --> 00:54:00,199
at least one or two automated nodes as well. And

990
00:54:00,280 --> 00:54:03,599
that's simply because as long as we have the template

991
00:54:03,639 --> 00:54:06,840
in place to do the automation, we can scale at will.

992
00:54:07,039 --> 00:54:08,679
You know, we can just come up and put another

993
00:54:08,719 --> 00:54:11,559
template and with various variables and we can scale some others.

994
00:54:13,000 --> 00:54:14,679
So yeah, we don't like to leave ourselves in a

995
00:54:14,679 --> 00:54:16,679
position where we've kind of got nowhere to go, or

996
00:54:17,159 --> 00:54:19,199
we have to set up another host manually in a

997
00:54:19,239 --> 00:54:24,280
specific way to run this particular blockchain note. So yeah, yeah,

998
00:54:24,320 --> 00:54:25,719
it's it's exactly that approach.

999
00:54:27,079 --> 00:54:30,440
Speaker 2: So where we left off last time with web how

1000
00:54:30,519 --> 00:54:32,920
Web three is going. We had n f T s

1001
00:54:33,159 --> 00:54:36,880
and I think the general population failed to understand n

1002
00:54:36,960 --> 00:54:40,840
fts in any capacity. So that went well, But I

1003
00:54:40,920 --> 00:54:44,280
am curious, like what the what, what the what? Where

1004
00:54:44,320 --> 00:54:46,920
the innovation is at today? Like you know, where where

1005
00:54:47,000 --> 00:54:49,679
you see that either where it's currently at or you

1006
00:54:49,800 --> 00:54:52,960
know what's coming next that is super interesting for you.

1007
00:54:53,760 --> 00:54:56,360
Speaker 3: Yeah, yeah, that's that's a great question. And you know,

1008
00:54:56,440 --> 00:54:59,320
similar to the break, the break that I had when

1009
00:54:59,719 --> 00:55:01,920
you know, when I wasn't working with Peter and he

1010
00:55:02,039 --> 00:55:03,840
came to web three. When I asked him, or what's that?

1011
00:55:04,199 --> 00:55:08,719
What's happened? You know, has anything changed? Actually his responsible

1012
00:55:08,760 --> 00:55:11,239
were they're just Linux services, right, And I was like, surely,

1013
00:55:11,320 --> 00:55:13,719
there's clearly there's something more than that. But of course,

1014
00:55:14,960 --> 00:55:17,039
the you know, the the L two space had evolved

1015
00:55:17,159 --> 00:55:20,079
in that period where I, you know, hadn't been working

1016
00:55:20,159 --> 00:55:24,599
explicitly in blockchain. But I think I think while that's

1017
00:55:24,920 --> 00:55:27,679
while that might not necessarily be where we see the

1018
00:55:27,880 --> 00:55:32,039
greatest innovation, I mean I might be wrong. I see

1019
00:55:32,119 --> 00:55:34,159
that for me and my team, I see that as

1020
00:55:34,360 --> 00:55:36,679
as a great learning opportunity because there are lots of

1021
00:55:37,199 --> 00:55:40,360
you know, new toolkits that are available and new ways

1022
00:55:40,360 --> 00:55:43,199
of running L two's and you know, soon to be

1023
00:55:43,360 --> 00:55:45,800
L three's, and who knows how how many layers that

1024
00:55:45,800 --> 00:55:47,800
we're going to see and so from so from my

1025
00:55:47,880 --> 00:55:52,320
perspective as well as let's call them the the general

1026
00:55:52,400 --> 00:55:55,000
integrations we do for blockchain networks, it's it's good for

1027
00:55:55,119 --> 00:55:57,599
me and my team to have access and be exposed

1028
00:55:57,639 --> 00:56:02,920
to these layer twos because you know, it's a good

1029
00:56:02,960 --> 00:56:07,000
learning opportunity. They also, you know, we run this role

1030
00:56:07,079 --> 00:56:08,800
up as a service where you can literally rock up,

1031
00:56:09,000 --> 00:56:11,719
define new shame parameters, and launch your own blockchain if

1032
00:56:11,719 --> 00:56:14,840
you want to, as an L two. And yeah, I

1033
00:56:14,920 --> 00:56:18,920
think that that makes it so accessible for people. So

1034
00:56:19,039 --> 00:56:21,159
I think that is where we're going to see a

1035
00:56:21,159 --> 00:56:23,320
lot of innovation, certainly, you know, for me and my team,

1036
00:56:23,400 --> 00:56:24,920
I think it's where we're going to learn a lot

1037
00:56:24,960 --> 00:56:29,440
more and have access to these other technologies, other development stacks,

1038
00:56:29,480 --> 00:56:29,880
et cetera.

1039
00:56:30,800 --> 00:56:33,119
Speaker 2: Okay, so you've you've you've gotten to the point where

1040
00:56:33,119 --> 00:56:35,679
you're actually outside of my area of understanding when you

1041
00:56:35,719 --> 00:56:37,960
say like layer two or layer three, we're talking about

1042
00:56:37,960 --> 00:56:40,800
like lightning network, Like what does that actually mean in

1043
00:56:40,880 --> 00:56:42,000
the context of a blockchain?

1044
00:56:42,159 --> 00:56:47,719
Speaker 3: And and L two allows you to run blockchain which

1045
00:56:47,760 --> 00:56:52,559
at various intervals generates and stores state in a transaction

1046
00:56:52,760 --> 00:56:55,840
on an L one. So a lot of these are

1047
00:56:56,079 --> 00:56:59,440
used ethereum as there L one, which is effectively the

1048
00:57:00,079 --> 00:57:03,280
the data availability layer. So if you needed to, let's say,

1049
00:57:03,320 --> 00:57:07,000
bootstrap another L two node, you could based on the

1050
00:57:07,079 --> 00:57:09,679
state that's been stored on the L one. I'll be honest,

1051
00:57:09,719 --> 00:57:14,679
this is going past some of my understandings. But effectively,

1052
00:57:15,559 --> 00:57:17,440
at L two allows you to sort of, you know,

1053
00:57:17,559 --> 00:57:21,079
branch off and have transactions between wallets et cetera, et cetera,

1054
00:57:21,199 --> 00:57:23,800
and all of that happens on the L two and

1055
00:57:24,679 --> 00:57:27,400
periodically it then records that state on the L one. Now,

1056
00:57:27,599 --> 00:57:31,679
the differences, the reason for this is, you know, obviously

1057
00:57:31,760 --> 00:57:34,119
there are you can only do a certain number of

1058
00:57:34,199 --> 00:57:38,280
transactions per second based on the block time and the

1059
00:57:38,400 --> 00:57:41,519
size of the blocks on each of the blockchains. Now,

1060
00:57:41,920 --> 00:57:46,159
if you separate all that transaction activity onto an L

1061
00:57:46,239 --> 00:57:50,360
two and only at various intervals record that state onto

1062
00:57:50,400 --> 00:57:53,360
the L one, it means that you've got less going

1063
00:57:53,400 --> 00:57:55,599
on on the L one, and therefore, in theory, you

1064
00:57:55,679 --> 00:58:00,159
can have many more transactions with fewer confirmations and the

1065
00:58:00,320 --> 00:58:03,039
full transactions on the L one. So people call it

1066
00:58:03,320 --> 00:58:06,920
block space, block space, lots more block space and lots

1067
00:58:07,000 --> 00:58:09,920
more transactions. But I shouldn't say well, because someone might

1068
00:58:10,000 --> 00:58:11,960
say you don't know what you're talking about, so don't

1069
00:58:12,000 --> 00:58:13,159
go on these podcasts again.

1070
00:58:15,639 --> 00:58:18,280
Speaker 2: Well, I think we'll definitely let you back on. But

1071
00:58:19,039 --> 00:58:22,280
I think we're not the official keepers of that, but

1072
00:58:22,400 --> 00:58:24,639
I will I will ask you here. I always had

1073
00:58:24,679 --> 00:58:27,880
this fear that it's sort of like you have your

1074
00:58:28,000 --> 00:58:30,559
enterprise service bus and now you're building some micro services

1075
00:58:30,599 --> 00:58:34,159
on top of that, and they're storing intermediary state in memory.

1076
00:58:34,639 --> 00:58:38,519
Like for these higher layers, there must be some risk

1077
00:58:38,639 --> 00:58:42,159
with the layer collapsing in some way or creating a

1078
00:58:42,239 --> 00:58:46,559
conflict between different isolated parts that are on the same

1079
00:58:46,679 --> 00:58:49,519
layer that would cause a conflict on that based chain,

1080
00:58:49,679 --> 00:58:51,559
And like, how does that get resolved or is that

1081
00:58:51,639 --> 00:58:53,280
even a problem that is concerned.

1082
00:58:54,719 --> 00:58:58,559
Speaker 3: That's a deeply technical question which I'm trying to think

1083
00:58:58,719 --> 00:58:59,800
the best way to dodge.

1084
00:59:00,199 --> 00:59:07,519
Speaker 2: So you can say anything, because I honestly still to

1085
00:59:07,599 --> 00:59:09,199
this day, don't have the answer to this question.

1086
00:59:09,639 --> 00:59:11,440
Speaker 3: But yeah, so I should do the AI trick, right,

1087
00:59:11,480 --> 00:59:17,760
I should just I should have just responded confidently. Yeah, yeah, so,

1088
00:59:18,519 --> 00:59:21,559
I mean, I'll be honest, I haven't seen instances of

1089
00:59:21,679 --> 00:59:26,119
that problem. I'm certain that they must exist, but if

1090
00:59:26,159 --> 00:59:29,800
you will, I could almost theorize how in my work,

1091
00:59:29,840 --> 00:59:33,400
But maybe that's a bit dangerous. But you know, even

1092
00:59:33,480 --> 00:59:35,400
on an l one you can get to a point

1093
00:59:35,440 --> 00:59:39,800
where a longer chain is submitted with a great number

1094
00:59:39,840 --> 00:59:42,840
of blocks, and therefore it unwinds some of the other

1095
00:59:42,880 --> 00:59:45,400
blocks in the chain, and you know that everyone follows

1096
00:59:45,440 --> 00:59:49,440
the longer chain, right, So my understanding is it would

1097
00:59:49,480 --> 00:59:51,880
work the same way with an L two. You know,

1098
00:59:53,079 --> 00:59:55,239
there could be a point at which the state hadn't

1099
00:59:55,280 --> 00:59:58,440
been recorded, and therefore it kind of reflects back to

1100
00:59:58,559 --> 01:00:01,159
the state prior to that, and then you build back

1101
01:00:01,280 --> 01:00:04,000
up to what is this next state that it needs

1102
01:00:04,039 --> 01:00:06,079
to be in terms of the transactions that need to occur,

1103
01:00:06,159 --> 01:00:08,880
et cetera. But a note to self, I'm going to

1104
01:00:08,920 --> 01:00:09,920
do research on that one.

1105
01:00:10,719 --> 01:00:13,320
Speaker 2: Well, I mean, there's the canonical and you worked in payments,

1106
01:00:13,360 --> 01:00:16,960
so maybe there's some insight here. Like you don't want

1107
01:00:17,039 --> 01:00:20,519
to have to have a consistent state amongst all customer

1108
01:00:20,639 --> 01:00:23,079
all users in the world that have a visa credit card,

1109
01:00:24,079 --> 01:00:26,199
you know, if they're making a transaction, you want to

1110
01:00:26,880 --> 01:00:29,119
bucket them. So like if you're in bank processing world,

1111
01:00:29,280 --> 01:00:31,519
you want to allow people to send money to each other.

1112
01:00:31,599 --> 01:00:35,480
Maybe there's a regionality, so your L two's only exist

1113
01:00:35,679 --> 01:00:38,320
in like in one country, in the likelihood of cross

1114
01:00:38,400 --> 01:00:41,559
country transactions is low. And when that happens, then you

1115
01:00:41,760 --> 01:00:45,400
have to ensure that you have a consistent understanding of

1116
01:00:45,440 --> 01:00:47,599
what the l one chain is. But other than that,

1117
01:00:47,840 --> 01:00:50,559
you just, you know, you risk it because you're blocking

1118
01:00:50,679 --> 01:00:53,199
transactions in some way that are happening to that chain

1119
01:00:53,280 --> 01:00:55,679
outside and you can't fully trust that because someone could

1120
01:00:55,679 --> 01:00:58,039
be doing something in one of those other you know,

1121
01:00:58,159 --> 01:01:01,360
independent same layer. But I see that there are some

1122
01:01:01,440 --> 01:01:03,159
opportunities there. But like as you said, you know, we

1123
01:01:03,199 --> 01:01:05,800
can theorize, but we're not the experts on this. That's fine,

1124
01:01:06,039 --> 01:01:06,440
I got it.

1125
01:01:07,199 --> 01:01:10,440
Speaker 1: It's a it's a deep, deep, deep rabbit hole.

1126
01:01:11,119 --> 01:01:14,000
Speaker 3: Oh yeah, well indeed, And you know, I think I

1127
01:01:14,119 --> 01:01:17,800
think abstracting from the technical complexities of building a blockchain

1128
01:01:17,880 --> 01:01:21,719
client and a you know, consensus mechanism, that's what those

1129
01:01:21,760 --> 01:01:26,400
technical people are for, I would say. But yeah, right,

1130
01:01:26,440 --> 01:01:27,199
it's a great question.

1131
01:01:27,280 --> 01:01:29,920
Speaker 1: I think that's a way of saying, it's someone else's problem.

1132
01:01:30,239 --> 01:01:32,159
Speaker 3: I hire someone to solve that for me, you know,

1133
01:01:32,320 --> 01:01:34,960
so I don't have to know I see the problems

1134
01:01:35,000 --> 01:01:38,320
when they're not necessarily how they intended to solve them.

1135
01:01:41,159 --> 01:01:43,599
Speaker 1: You know, you've got deep experience both in Web two

1136
01:01:43,719 --> 01:01:47,599
and Web three, So if you could share one piece

1137
01:01:48,480 --> 01:01:52,800
of a Web two learning with the Web three crowd.

1138
01:01:53,239 --> 01:01:53,880
What would that be?

1139
01:01:55,320 --> 01:01:59,119
Speaker 3: So less haste, more speed. I think that that kind

1140
01:01:59,159 --> 01:02:00,960
of comes back to the point I made earlier on

1141
01:02:01,039 --> 01:02:08,119
about rigor around processes, testing, you know, time to adopt

1142
01:02:08,159 --> 01:02:10,280
new versions, et cetera. That kind of thing. I think.

1143
01:02:10,360 --> 01:02:13,400
You know, there are there are great innovations and you know,

1144
01:02:14,239 --> 01:02:17,039
great inventions in the Web three space. But I think

1145
01:02:19,280 --> 01:02:23,039
I think, yeah, that we won and even organizationally, we

1146
01:02:23,079 --> 01:02:28,559
should afford ourselves the time to do them properly. And yeah,

1147
01:02:28,559 --> 01:02:30,159
you know, I mean that's that's kind of what I've

1148
01:02:30,159 --> 01:02:33,000
been doing and saying since I since I came into anchor,

1149
01:02:33,079 --> 01:02:36,760
you know, for me, right, So imagine for note operations. Look,

1150
01:02:37,039 --> 01:02:39,280
I don't care that you can update sixteen nodes in

1151
01:02:39,400 --> 01:02:42,239
five seconds. That is not That is not what I'm

1152
01:02:42,280 --> 01:02:44,599
here to do. I want to know that there's at

1153
01:02:44,679 --> 01:02:48,239
least X number of nodes online at all times in

1154
01:02:48,320 --> 01:02:52,840
these locations. So you do them one at a time, slowly, sequentially,

1155
01:02:53,280 --> 01:02:56,679
but make sure you do it right and it all happens. So, yeah,

1156
01:02:56,719 --> 01:02:58,679
that that would be my learning from Web two to

1157
01:02:58,760 --> 01:02:59,960
work three, less hate, more space.

1158
01:03:00,960 --> 01:03:04,519
Speaker 2: I think there's a corollary here because one of the

1159
01:03:05,440 --> 01:03:07,360
I think you mentioned this earlier on in the episode,

1160
01:03:07,920 --> 01:03:10,360
that one of the ideas with Web three is let's

1161
01:03:10,400 --> 01:03:12,599
forget everything we did with Web two and like start

1162
01:03:12,679 --> 01:03:14,880
all over again. But there have been innovations I think

1163
01:03:14,960 --> 01:03:17,800
in Web two in the last twenty years that even

1164
01:03:18,400 --> 01:03:21,199
before that that were discarded that would benefit people to

1165
01:03:21,320 --> 01:03:23,320
sort of pay attention with. And I think there's this

1166
01:03:23,400 --> 01:03:26,639
aspect of experience from cross industry. And I see that

1167
01:03:26,760 --> 01:03:29,719
for like a lot of blockchain companies are like only hiring,

1168
01:03:30,039 --> 01:03:32,239
you know, you must have blockchain experience, must have you know,

1169
01:03:32,320 --> 01:03:35,039
Web three app development experience. And I'm like, okay, but

1170
01:03:35,239 --> 01:03:38,199
for sure experience outside of that would be really useful.

1171
01:03:38,239 --> 01:03:42,039
And I think especially around the processes, it's in a

1172
01:03:42,079 --> 01:03:44,800
lot of ways, it's still software development, it's still product management,

1173
01:03:44,920 --> 01:03:49,599
it's still you know, business intelligence. And I hate that

1174
01:03:49,719 --> 01:03:51,360
term BI, but you know, I'll use it here as

1175
01:03:51,400 --> 01:03:55,199
an example what you can pull from other companies. So

1176
01:03:55,360 --> 01:03:57,440
I really like that, and I am I'm dying to

1177
01:03:57,519 --> 01:04:00,039
hear the corollary to Will's question.

1178
01:04:01,280 --> 01:04:05,920
Speaker 1: Yeah, that flip the question around what is one thing

1179
01:04:06,039 --> 01:04:08,880
that Web two could take away from Web three?

1180
01:04:09,880 --> 01:04:14,760
Speaker 3: Yeah, I mean there was, Yeah, I mean do you

1181
01:04:14,880 --> 01:04:18,519
mean specifically when we're like a particular sector or it's

1182
01:04:19,280 --> 01:04:22,639
or generally I suppose, I mean, you know, so the

1183
01:04:22,719 --> 01:04:25,000
flip the flip. The flip to the answer is why

1184
01:04:25,039 --> 01:04:29,000
why wouldn't you just test everything in production? Right? What

1185
01:04:29,360 --> 01:04:32,559
do you mean? What do you mean less speed? You know,

1186
01:04:32,840 --> 01:04:35,920
I remember, I remember even in the Web two I mean,

1187
01:04:36,039 --> 01:04:38,760
you know we did. We did in various roles in

1188
01:04:38,800 --> 01:04:40,960
the past. I won't going into which ones they were.

1189
01:04:41,039 --> 01:04:44,320
You know, we've we've we've done tests in production which

1190
01:04:45,960 --> 01:04:50,039
where we literally dragged the business over the line and

1191
01:04:50,159 --> 01:04:52,239
got them to let us put this thing in production

1192
01:04:52,519 --> 01:04:54,880
and do the test. So I think I think on

1193
01:04:55,079 --> 01:04:57,800
both sides. You know, Web three can learn from Web

1194
01:04:57,880 --> 01:05:00,840
two in terms of more rigor around pro is, you know,

1195
01:05:01,239 --> 01:05:04,800
affording themselves the time to do things correctly and write.

1196
01:05:05,440 --> 01:05:07,519
And similarly Web two can learn from Web three in

1197
01:05:07,599 --> 01:05:12,239
that regard, you know, be more open to innovation, embrace

1198
01:05:12,320 --> 01:05:16,119
it more and and you know, take and take more risks.

1199
01:05:16,199 --> 01:05:16,880
In some cases.

1200
01:05:17,719 --> 01:05:19,239
Speaker 1: It goes back to the joke I made a long

1201
01:05:19,320 --> 01:05:21,800
time ago that true ci c D is VIM on

1202
01:05:21,880 --> 01:05:22,599
the Pride server.

1203
01:05:24,719 --> 01:05:27,239
Speaker 3: You know, my brother would love that. He's he always

1204
01:05:27,280 --> 01:05:30,840
goes on and on still about them. And I was like,

1205
01:05:31,320 --> 01:05:34,320
have you tried visual Studio and he was like, no,

1206
01:05:37,079 --> 01:05:41,360
you know vs coast. I remember the first time I

1207
01:05:41,440 --> 01:05:44,679
saw VIM and I was watching over some someone's shoulder.

1208
01:05:44,679 --> 01:05:46,639
It was a chef screen and I was looking at him, going,

1209
01:05:46,719 --> 01:05:48,400
what is he doing? He's going to delete this slide?

1210
01:05:48,440 --> 01:05:50,679
And because I was used to using NANO, I thought

1211
01:05:50,719 --> 01:05:53,519
it was going to be an absolute disaster, But so

1212
01:05:53,639 --> 01:05:54,239
there actually is.

1213
01:05:54,599 --> 01:05:58,320
Speaker 2: Maybe a slightly a different tangent. I I ser to

1214
01:05:58,400 --> 01:06:04,159
see this pattern where malicious attackers are utilizing public APIs

1215
01:06:04,360 --> 01:06:11,440
associated with blockchain companies technology to store smuggle out encrypted

1216
01:06:11,559 --> 01:06:16,480
data from their victims. So they'll take data from a

1217
01:06:16,559 --> 01:06:20,119
victim's environment, they'll encrypt it with the public version of

1218
01:06:21,000 --> 01:06:23,119
a key that they have, and then upload it to

1219
01:06:23,639 --> 01:06:28,320
a public blockchain. And I'm curious if you've heard about this,

1220
01:06:28,639 --> 01:06:31,800
if you've seen something like this and it's a known problem, Like,

1221
01:06:31,800 --> 01:06:33,800
I don't know what there's a solution of this, honestly,

1222
01:06:35,639 --> 01:06:38,119
and just like what can be done? Because I feel

1223
01:06:38,159 --> 01:06:40,400
like it's sort of these things where in the past

1224
01:06:41,000 --> 01:06:44,000
we had lots of these data sharing sites where you

1225
01:06:44,039 --> 01:06:47,400
can drop a file or someone hirates a movie or

1226
01:06:47,480 --> 01:06:49,400
something or some music and puts it on there, and

1227
01:06:49,519 --> 01:06:52,760
then they always end up getting shut down and because

1228
01:06:52,760 --> 01:06:56,639
they're a source for this illegal content. And I don't

1229
01:06:56,679 --> 01:06:58,800
know that there's something obvious that can be done with

1230
01:07:00,039 --> 01:07:02,920
watchain technologies out there, which you have a public ledger

1231
01:07:02,960 --> 01:07:03,719
in a lot of cases.

1232
01:07:04,199 --> 01:07:06,360
Speaker 3: Yeah, yeah, that's a good that's a good one. And

1233
01:07:06,440 --> 01:07:10,400
we see, in fact, we see more and more blockchain

1234
01:07:10,519 --> 01:07:14,039
based storage solutions coming, you know, as the month and

1235
01:07:14,119 --> 01:07:18,800
years go by. Honestly, I mean, we need to sort

1236
01:07:18,840 --> 01:07:22,760
the users out, don't we. That's the problem. That's someone

1237
01:07:23,440 --> 01:07:26,639
you know, you're not gonna be able to find me tomorrow, Howards, right,

1238
01:07:26,639 --> 01:07:28,519
because someone's going to have hacked my computer and the

1239
01:07:28,559 --> 01:07:31,400
encrypted my data and put it on a blockchain network,

1240
01:07:31,400 --> 01:07:33,840
can't they now have said that? But yeah, I think

1241
01:07:35,280 --> 01:07:37,440
I think the problem it's a pepcac right. The problem

1242
01:07:37,480 --> 01:07:41,119
exists between the keyboard and the chair in that instance. Now,

1243
01:07:41,840 --> 01:07:45,360
if we could stop users being if we could stop

1244
01:07:45,440 --> 01:07:49,079
users being taken advantage of and having this information stored,

1245
01:07:49,159 --> 01:07:50,840
and that's the root cause for me, and that's what

1246
01:07:50,920 --> 01:07:53,639
we should go off and fix. I think in terms

1247
01:07:53,679 --> 01:07:56,840
of because I would say I would champion you know,

1248
01:07:56,920 --> 01:08:00,960
the blockchain space doing these you know, public accessible data

1249
01:08:01,039 --> 01:08:05,519
availability layers and hosting solutions. I think it's I think

1250
01:08:05,559 --> 01:08:06,119
it's a good thing.

1251
01:08:06,559 --> 01:08:09,360
Speaker 1: There was one and I can't remember the exact details

1252
01:08:09,400 --> 01:08:11,280
of it, but you'll, I think you'll appreciate this one.

1253
01:08:11,800 --> 01:08:16,960
There was a similar strategy, but instead of taking the

1254
01:08:17,079 --> 01:08:21,800
data and uploading it to the blockchain, they would take

1255
01:08:21,920 --> 01:08:25,720
it and then submit it as a transaction to the blockchain.

1256
01:08:26,359 --> 01:08:29,640
But intentionally price is so low that it would never

1257
01:08:29,800 --> 01:08:33,159
get mined. So now the transaction exists on the chain,

1258
01:08:33,239 --> 01:08:35,399
but it never gets written to a block so you

1259
01:08:35,520 --> 01:08:38,159
can't really track it down that way, and you read it.

1260
01:08:38,199 --> 01:08:40,520
Speaker 2: Out you read the data out there because the transactions

1261
01:08:40,520 --> 01:08:42,840
are being traced and monitored in the network. And then

1262
01:08:42,840 --> 01:08:45,039
when it gets dumped, it's not on the chain. You

1263
01:08:45,079 --> 01:08:47,239
know it's gone, and so you have to actually look

1264
01:08:47,239 --> 01:08:49,840
at the analytics data of what had happened. It's not

1265
01:08:49,960 --> 01:08:53,600
even you know, available for all that is ingenious. I

1266
01:08:53,720 --> 01:08:57,119
hope there aren't any you know, people with malicious intent

1267
01:08:57,199 --> 01:08:58,399
that are watching this podcast.

1268
01:08:59,239 --> 01:09:01,079
Speaker 1: Oh, entirely unlikely.

1269
01:09:02,319 --> 01:09:04,960
Speaker 3: You never know, You never know yeah, I don't know.

1270
01:09:05,119 --> 01:09:06,239
Speaker 1: It went way over my head.

1271
01:09:06,960 --> 01:09:08,800
Speaker 2: Yeah, I mean it's probably if you do enough times,

1272
01:09:08,840 --> 01:09:11,319
it will be sitting there that someone will like eventually

1273
01:09:11,319 --> 01:09:13,800
it's on the it's in the queue to actually get

1274
01:09:13,840 --> 01:09:16,039
turned into a block. I mean, there was a it

1275
01:09:16,159 --> 01:09:20,199
was a great post a while ago about making databases

1276
01:09:20,279 --> 01:09:21,920
out of things that do not that should not be

1277
01:09:21,960 --> 01:09:25,960
a database. So one of them was TC using icmp

1278
01:09:26,119 --> 01:09:29,000
pings and so you put some data in the ic

1279
01:09:29,840 --> 01:09:31,479
ic m P header and you send it to a

1280
01:09:31,600 --> 01:09:34,600
random IP on the internet and then you know, you'll

1281
01:09:34,640 --> 01:09:36,840
get the ping back with the payload and you can

1282
01:09:37,000 --> 01:09:39,159
you know, use it and so like in femoral database

1283
01:09:39,159 --> 01:09:41,760
at that point, and I like, that's super unreliable. But

1284
01:09:41,880 --> 01:09:43,760
this is this is like an extension of this is

1285
01:09:43,840 --> 01:09:46,439
like a whole system, you know, built in design to

1286
01:09:46,920 --> 01:09:49,800
actually utilize this data in a reliable way.

1287
01:09:50,279 --> 01:09:50,479
Speaker 3: Yeah.

1288
01:09:50,560 --> 01:09:52,159
Speaker 1: Could you just need it to hold the data until

1289
01:09:52,159 --> 01:09:53,800
you get out of the building or whatever.

1290
01:09:54,840 --> 01:09:56,520
Speaker 2: Oh, I mean in a lot of these cases, it's

1291
01:09:56,560 --> 01:10:02,520
not a you haven't trespassed like physically to right, Yeah, yeah,

1292
01:10:02,640 --> 01:10:05,560
you just basically you know, you've deployed some malicious tool

1293
01:10:05,680 --> 01:10:08,920
to through MPM or pipe or anything else someone downloads

1294
01:10:08,960 --> 01:10:12,399
that they lost their credentials, or you infiltrate an organization

1295
01:10:12,520 --> 01:10:14,640
and you have some keys to the database and you

1296
01:10:15,079 --> 01:10:19,119
upload those automatically. You just sit there querying all of

1297
01:10:19,279 --> 01:10:23,199
the block scanners that you know report transactions for any

1298
01:10:23,239 --> 01:10:25,039
single chain, and you're just like, oh, there it is,

1299
01:10:25,239 --> 01:10:28,119
there's my there's my transaction. You don't even have to

1300
01:10:28,159 --> 01:10:29,840
pay for anything, right, I mean, you could put like

1301
01:10:29,880 --> 01:10:34,319
a miniscool amount of money associated with the particular chains,

1302
01:10:34,359 --> 01:10:36,960
you at least get the transaction started, and other than that,

1303
01:10:37,159 --> 01:10:39,079
you know it will never complete and you don't have

1304
01:10:39,119 --> 01:10:40,439
to worry about it if you just pull it off

1305
01:10:40,439 --> 01:10:42,239
and you just scan and get the data.

1306
01:10:45,319 --> 01:10:46,960
Speaker 1: That seems like a good time to move on to picks.

1307
01:10:47,000 --> 01:10:49,319
Now that we've shared that information with everyone.

1308
01:10:49,720 --> 01:10:53,119
Speaker 2: Well, if it's pick time, then I guess I'm I'm

1309
01:10:53,239 --> 01:10:58,159
up first bringing on. Okay, so a few episodesis sodes ago.

1310
01:10:58,399 --> 01:11:01,119
I started sharing my keyboard and I think I got

1311
01:11:01,199 --> 01:11:03,439
some questions about what the heck I'm actually using. So

1312
01:11:03,800 --> 01:11:06,800
first of all, let this be the official pick for me.

1313
01:11:07,119 --> 01:11:11,119
I use a Divorac keyboard programmer Divorac on Linux, where

1314
01:11:11,159 --> 01:11:13,880
I've remapped all the keys as well, So I highly

1315
01:11:13,920 --> 01:11:16,920
recommend doing this, Like if you work in multiple currencies,

1316
01:11:17,960 --> 01:11:21,319
change like the dollar on the on the keyboard layout

1317
01:11:21,359 --> 01:11:24,800
to also do the euro sign and maybe the yen

1318
01:11:25,119 --> 01:11:27,399
or one like whatever you're utilizing. Like it's just so

1319
01:11:27,520 --> 01:11:29,279
much easier every single time you want one of those,

1320
01:11:29,359 --> 01:11:31,760
Like imagine if you had a magic emoji button on

1321
01:11:31,800 --> 01:11:36,760
your keyboard. I've basically done that, but I also want

1322
01:11:36,800 --> 01:11:38,520
to share the keyboard because I absolutely love this. So

1323
01:11:38,600 --> 01:11:42,399
what I have is, uh, it's a logic Logitech K

1324
01:11:42,720 --> 01:11:46,439
two ninety five silent keyboard, and this thing is so quiet,

1325
01:11:46,520 --> 01:11:48,000
like I can type on it while I'm on the

1326
01:11:48,079 --> 01:11:51,680
podcast and no one will ever know. That's how quiet

1327
01:11:51,720 --> 01:11:55,600
this is. And that's important because if I'm too loud, well,

1328
01:11:55,880 --> 01:11:57,960
other people that I live with will find out exactly

1329
01:11:58,039 --> 01:12:02,159
what I'm doing whenever I'm doing because I am an

1330
01:12:02,199 --> 01:12:02,920
angry typer.

1331
01:12:03,920 --> 01:12:08,840
Speaker 1: Yes, cool deal, Well what'd you bring for a pick?

1332
01:12:09,079 --> 01:12:11,880
Speaker 3: So I inherited a number of records recently. You know,

1333
01:12:12,359 --> 01:12:17,239
if there's kids listening these big black discs twelve thirty

1334
01:12:17,279 --> 01:12:21,359
three because because my father passed away and so we

1335
01:12:21,520 --> 01:12:25,159
sold his stereo system. You know, an old an old

1336
01:12:25,199 --> 01:12:28,119
silver techniques thing it was, and so I've been I've

1337
01:12:28,159 --> 01:12:30,680
been looking because I wanted to get myself a record player.

1338
01:12:31,079 --> 01:12:33,279
So that that's my pick for today. So I think

1339
01:12:33,479 --> 01:12:37,720
for two reasons. Number one is like we need to

1340
01:12:37,840 --> 01:12:39,960
not lose the tactility, right. I know a lot of

1341
01:12:40,000 --> 01:12:42,800
people everyone's all about digital and web three and all

1342
01:12:42,880 --> 01:12:47,479
this wonderful thing, but I think we're slowly losing possessions

1343
01:12:47,520 --> 01:12:50,359
as people and and I don't think that's that In

1344
01:12:50,479 --> 01:12:52,960
some cases that's great and others I don't think it's

1345
01:12:53,000 --> 01:12:55,239
that great a thing. So yeah, I want to I

1346
01:12:55,319 --> 01:12:57,640
want to get a record player, which is to play

1347
01:12:58,000 --> 01:13:00,319
these old records that I have and I may increase

1348
01:13:00,359 --> 01:13:03,439
my collection. Now the particular record player is the interesting bit.

1349
01:13:05,199 --> 01:13:06,520
So I thought, I try and look for something that

1350
01:13:06,720 --> 01:13:11,439
was quirky, you know, new different, and you don't get

1351
01:13:11,479 --> 01:13:14,439
that a lot with record players, right, it's usually and

1352
01:13:14,560 --> 01:13:17,159
a stylus. Now I found this record player by a

1353
01:13:17,239 --> 01:13:19,399
company in the Netherlands, and I think they're called mini

1354
01:13:19,479 --> 01:13:23,319
Ot or Miniot, and they have a record player which

1355
01:13:23,399 --> 01:13:27,359
can you can have vertical or horizontal and it actually

1356
01:13:27,520 --> 01:13:30,800
plays the backside of the disc. So if you imagine

1357
01:13:30,800 --> 01:13:34,600
it plays it counterclockwise, and the need thing is it

1358
01:13:34,720 --> 01:13:37,760
scans the entire record, so you can almost use it

1359
01:13:37,840 --> 01:13:39,960
as a CD. Once it's done a scan of the record,

1360
01:13:40,000 --> 01:13:43,760
you can skip tracks, you know, forward, backwards, et cetera. So, yeah,

1361
01:13:43,800 --> 01:13:46,760
my pick is this quirky record player that I'm going

1362
01:13:46,840 --> 01:13:48,960
to treat myself to hopefully in the next couple of months.

1363
01:13:49,319 --> 01:13:49,920
That's wild.

1364
01:13:51,760 --> 01:13:54,199
Speaker 1: So will it still let you play the Beatles White

1365
01:13:54,279 --> 01:13:56,880
Album backwards so you can get the satanic messages?

1366
01:13:57,399 --> 01:13:59,760
Speaker 3: That's a good question. Well, it has this feature where

1367
01:13:59,760 --> 01:14:02,079
you can push it to place, and maybe it allows

1368
01:14:02,119 --> 01:14:04,359
you to drag it backwards. I don't know, that's a

1369
01:14:04,399 --> 01:14:04,920
good question.

1370
01:14:06,319 --> 01:14:07,000
Speaker 1: I'll let you know.

1371
01:14:07,479 --> 01:14:11,000
Speaker 2: I'll let you know, right. I wonder are there turntables

1372
01:14:11,079 --> 01:14:14,439
that let you determine the direction of the wheel? I

1373
01:14:15,520 --> 01:14:16,560
wonder if that's the thing.

1374
01:14:17,079 --> 01:14:17,439
Speaker 3: I don't know.

1375
01:14:17,479 --> 01:14:19,640
Speaker 1: It was just a it was a rumor I heard

1376
01:14:20,439 --> 01:14:22,680
back when I was a kid about the Beatles Wide Album.

1377
01:14:22,960 --> 01:14:26,079
All right, cool. So for my pick, it's funny because

1378
01:14:26,079 --> 01:14:31,199
we didn't plan this, but I'm actually picking a tool

1379
01:14:31,439 --> 01:14:38,199
called super Whisper super Whisper dot com. It's audio input,

1380
01:14:38,439 --> 01:14:40,520
so you don't have to type at all, and you

1381
01:14:40,600 --> 01:14:43,920
don't have to learn a new keyboard layout or deal

1382
01:14:44,039 --> 01:14:48,479
with RSI. But it's actually surprisingly accurate, you know, because

1383
01:14:48,560 --> 01:14:51,439
like every phone and computer now has some sort of

1384
01:14:51,560 --> 01:14:55,800
voice transcription thing, and never in my life have I

1385
01:14:55,920 --> 01:14:58,960
used the word doc. But super Whisper knows exactly what

1386
01:14:59,039 --> 01:15:02,479
I'm trying to say, and it doesn't. Really It's done

1387
01:15:02,720 --> 01:15:06,319
a really good job and you don't have to, at

1388
01:15:06,439 --> 01:15:08,119
least in my experience with it. You don't have to

1389
01:15:08,880 --> 01:15:11,159
slow down or just give it bites at a time,

1390
01:15:11,279 --> 01:15:14,119
you know, you can just have a full fledged streaming

1391
01:15:14,199 --> 01:15:17,600
thought process and it captures it very, very accurately. So

1392
01:15:17,680 --> 01:15:21,199
it's been fun to play with and also will work

1393
01:15:21,479 --> 01:15:23,560
locally so you can set it up so that it

1394
01:15:23,640 --> 01:15:27,199
doesn't send whatever you're telling it back to their servers

1395
01:15:27,279 --> 01:15:31,600
for training or storage or ransomware or whatever they want

1396
01:15:31,640 --> 01:15:35,800
to hould you hostage for cool all right, Paul, thank

1397
01:15:35,840 --> 01:15:38,199
you so much, man, this has been a super cool conversation.

1398
01:15:38,720 --> 01:15:41,239
I'm super excited that you came on and chatted with

1399
01:15:41,359 --> 01:15:41,760
us about it.

1400
01:15:42,600 --> 01:15:45,439
Speaker 3: Yeah, my pleasure. Thanks very much for the time, and

1401
01:15:46,079 --> 01:15:47,680
apologies for the ins and issues, you know.

1402
01:15:48,760 --> 01:15:51,079
Speaker 1: Yeah for sure. Well, yeah, you got to come back

1403
01:15:51,159 --> 01:15:53,239
on and let us know how the record player works.

1404
01:15:53,479 --> 01:15:56,279
So we've got to do that part anyway. Yeah, it

1405
01:15:56,319 --> 01:15:59,760
sounds right cool, right, I'm born. Thank you so much,

1406
01:16:00,000 --> 01:16:03,600
appreciate everything, and for all of our listeners, thank you

1407
01:16:03,680 --> 01:16:05,319
for listening. And we'll see y'all next week.