1
00:00:00,000 --> 00:00:03,500
This is epicenter episode 258 
with guests, Monica 

2
00:00:03,500 --> 00:00:20,400
acquaintances. 
This episode of epicenter is 

3
00:00:20,400 --> 00:00:24,100
brought to you by Dutch hex, the
fair and secure decentralized 

4
00:00:24,100 --> 00:00:27,800
exchange platform, by kenosis to
learn how you can build apps, 

5
00:00:27,800 --> 00:00:30,900
which leverage Dutch axes, 
liquidity fool, visit epicenter,

6
00:00:30,900 --> 00:00:37,400
.t V, /, Dutch x, and by 
Microsoft Azure configure and 

7
00:00:37,400 --> 00:00:40,200
deploy a Consortium Network in 
just a few clicks with 

8
00:00:40,200 --> 00:00:42,400
pre-built. 
Aggregation and enterprise-grade

9
00:00:42,400 --> 00:00:44,800
infrastructure. 
Spend less time on watching 

10
00:00:44,800 --> 00:00:47,400
scaffolding and more time. 
Building your application. 

11
00:00:47,700 --> 00:00:51,100
Learn more at aka.ms/offweb 
eccentric. 

12
00:00:56,000 --> 00:00:57,900
Hi, welcome to epicenter the 
show ex talked about the 

13
00:00:57,900 --> 00:01:00,900
Technologies projects and starts
driving decentralization and the

14
00:01:00,900 --> 00:01:04,400
global blockchain Revolution. 
My name is Sebastian Cujo and 

15
00:01:04,400 --> 00:01:06,200
I'm ahead. 
Roy, I'm here. 

16
00:01:06,200 --> 00:01:09,200
How's it going? 
It's going with been a while 

17
00:01:09,200 --> 00:01:13,100
since we've done this together. 
Yeah, I can't remember what I 

18
00:01:13,107 --> 00:01:14,400
think. 
I think blocks are at was our 

19
00:01:14,400 --> 00:01:18,000
last episode. 
Yeah, I think we've added a 

20
00:01:18,400 --> 00:01:25,200
couple of new hosts and I guess 
like the veterans are sort of 

21
00:01:25,200 --> 00:01:29,700
busy dying to do episodes with 
the new hosts so that they get 

22
00:01:29,700 --> 00:01:33,800
up to speed. 
And, you know, and we have a 

23
00:01:33,800 --> 00:01:36,900
more Diversified Group of hosts 
for the future. 

24
00:01:37,900 --> 00:01:41,000
Yeah, I'm really excited about 
it and so our listeners will 

25
00:01:41,000 --> 00:01:42,900
notice that the formats little 
different. 

26
00:01:42,900 --> 00:01:46,600
So we don't typically sort of 
have this little discussion 

27
00:01:46,600 --> 00:01:48,700
between us but we're works 
better. 

28
00:01:48,700 --> 00:01:51,400
We're experimenting with this 
new way of doing the show. 

29
00:01:51,700 --> 00:01:56,900
We just thought it would be nice
to be able to, you know, spend a

30
00:01:56,900 --> 00:02:00,800
few minutes before the actual 
interview to discuss about what 

31
00:02:00,800 --> 00:02:03,300
we're about to talk about what 
we're about to hear. 

32
00:02:04,200 --> 00:02:06,700
So this is actually being 
recorded after the interview so 

33
00:02:06,700 --> 00:02:09,699
it's a Good way to sort of frame
the context for what you're 

34
00:02:09,699 --> 00:02:12,700
about to hear and also it gives 
us the opportunity to maybe talk

35
00:02:12,700 --> 00:02:15,800
to you about stuff that we 
wouldn't normally have the 

36
00:02:15,800 --> 00:02:18,000
opportunity to talk to you about
it like events, we might be 

37
00:02:18,000 --> 00:02:20,300
going to or things that might be
happening in and around 

38
00:02:20,300 --> 00:02:21,500
epicenter and that sort of 
thing. 

39
00:02:22,300 --> 00:02:25,400
So, yeah, let us know what you 
think about this new new format.

40
00:02:25,400 --> 00:02:28,900
I mean, doesn't change much for 
you, but yeah, hit us up on 

41
00:02:28,900 --> 00:02:32,500
Twitter and also would love to 
hear what you think about our 

42
00:02:32,500 --> 00:02:35,500
new, our new hosts. 
I mean son, he's been here for a

43
00:02:35,508 --> 00:02:36,900
while. 
Most of you. 

44
00:02:37,300 --> 00:02:40,900
Are familiar with him, but for 
the Eco who just joined us 

45
00:02:40,900 --> 00:02:43,300
recently, we're super excited to
have her on. 

46
00:02:44,400 --> 00:02:50,500
We're already this two episodes 
in with her and I think she's 

47
00:02:50,500 --> 00:02:51,200
been great. 
Yeah. 

48
00:02:51,200 --> 00:02:54,600
What do you think, man? 
So it's great to have new hosts 

49
00:02:56,700 --> 00:03:01,900
No, every new person, brings a 
different perspective and I get 

50
00:03:01,900 --> 00:03:07,000
to learn a lot as a host myself 
doing this episodes with frigid 

51
00:03:07,000 --> 00:03:10,000
Rica and Sonny because they 
questions are so different from 

52
00:03:10,000 --> 00:03:12,600
mine their Curiosities are so 
different from mine. 

53
00:03:13,300 --> 00:03:18,000
Yeah absolutely and it kind of 
takes takes the heat off of us 

54
00:03:18,000 --> 00:03:24,200
and allows allows us to do other
types of things and also for the

55
00:03:24,200 --> 00:03:27,300
listeners to be sort of kept on 
their feet as to Like, who's 

56
00:03:27,300 --> 00:03:29,700
gonna be the next host on? 
Like, the next episode? 

57
00:03:29,700 --> 00:03:32,200
What could I expect in some of 
the Dynamics that that creates? 

58
00:03:32,200 --> 00:03:36,200
Yeah, so yeah, I'm really 
excited and hopefully we can get

59
00:03:36,200 --> 00:03:38,200
some more hosts on at some 
point. 

60
00:03:39,200 --> 00:03:42,000
So today, we're going to be 
speaking with Monica 

61
00:03:42,000 --> 00:03:46,600
acquaintances and Monica is lead
engineering and adoption 

62
00:03:46,600 --> 00:03:53,100
strategy at kadena. 
And kadena is a company that 

63
00:03:53,100 --> 00:03:58,300
came out of JP Morgan. 
And it's building sort of it's 

64
00:03:58,300 --> 00:04:02,300
our unique actually because it's
a company that's building a 

65
00:04:02,300 --> 00:04:06,200
public network and also private 
Network Technologies. 

66
00:04:06,800 --> 00:04:10,300
Typically if you take like a 
hyper Ledger or something like 

67
00:04:10,300 --> 00:04:12,700
that or like well maybe not 
Cosmos. 

68
00:04:12,700 --> 00:04:16,000
But yeah something like hyper 
Ledger sort of companies that 

69
00:04:16,000 --> 00:04:18,200
are traditionally the private 
blockchains space that deal with

70
00:04:18,200 --> 00:04:20,700
Enterprise clients. 
You know, they have a stack that

71
00:04:20,700 --> 00:04:24,400
they're looking to deploy and 
Consortium networks or with 

72
00:04:24,400 --> 00:04:28,400
Enterprise players. 
But they're not typically like 

73
00:04:28,400 --> 00:04:34,000
building a public network with 
minors and, you know, privacy or

74
00:04:34,000 --> 00:04:37,400
sorry censorship resistance and 
such. 

75
00:04:37,600 --> 00:04:39,900
But they're actually doing both 
those things, they're building a

76
00:04:39,907 --> 00:04:44,000
public network and they're 
building Enterprise blockchain, 

77
00:04:44,100 --> 00:04:46,000
toolkit stack, whatever you want
to call it. 

78
00:04:47,400 --> 00:04:49,900
So from that perspective, I 
thought it was, it was, it was 

79
00:04:49,900 --> 00:04:52,900
interesting. 
I think you'll see that we sort 

80
00:04:52,900 --> 00:04:55,900
of get into the weeds with 
Monica because there's some some

81
00:04:55,900 --> 00:04:58,400
points where Where we didn't 
quite agree about some of the 

82
00:04:58,400 --> 00:05:05,900
fundamental underlying premises 
of their, of their public, the 

83
00:05:05,900 --> 00:05:08,500
public network, and the 
consensus Network there, the 

84
00:05:08,500 --> 00:05:11,300
mining protocol, but I think it 
was interesting. 

85
00:05:11,300 --> 00:05:13,700
Nonetheless, what do you think 
mayor? 

86
00:05:15,200 --> 00:05:23,300
this kind of a unique episode 
for me because I saw the videos 

87
00:05:23,300 --> 00:05:28,200
of kadena, and I chatted with 
Sonny on the epicenter slack 

88
00:05:28,200 --> 00:05:31,000
prior to doing this episode, and
Sonny. 

89
00:05:31,000 --> 00:05:37,100
And I were like Cadenas claiming
nearly infinite scalable 

90
00:05:37,100 --> 00:05:39,300
infinitely, scalable 
proof-of-work blockchain you 

91
00:05:39,308 --> 00:05:42,800
know in one of the videos. 
Somebody asks them, what's the 

92
00:05:42,800 --> 00:05:45,500
limit to the scalability of your
public platform? 

93
00:05:46,200 --> 00:05:50,100
And their answer is, you know, 
that they limit is something 

94
00:05:50,100 --> 00:05:52,700
like the limit of global 
bandwidth. 

95
00:05:53,600 --> 00:05:56,000
That is available in the world 
is what will limit their 

96
00:05:56,000 --> 00:05:58,200
platform. 
Like, some some answer that goes

97
00:05:58,200 --> 00:06:00,100
into, you know, like the 
billions or trillions of 

98
00:06:00,100 --> 00:06:05,500
transactions, a second. 
And and when I Sonny and I like 

99
00:06:05,700 --> 00:06:11,200
looked at it, we felt that the 
scalability solution don't work.

100
00:06:12,900 --> 00:06:14,700
So I was actually I came into 
this episode. 

101
00:06:14,700 --> 00:06:18,800
Hoping my doubts would be 
cleared and my skepticism would 

102
00:06:18,800 --> 00:06:25,400
go but it really hasn't. 
So I guess like what I am going 

103
00:06:25,400 --> 00:06:30,000
to do is you have the episode, 
you can listen to it, I get into

104
00:06:30,000 --> 00:06:35,300
the weeds with Monica. 
And I'm going to just write what

105
00:06:35,300 --> 00:06:40,200
I think, as a comment on on 
YouTube or on let's talk 

106
00:06:40,200 --> 00:06:44,300
Bitcoin. 
So I want to do this because I 

107
00:06:44,300 --> 00:06:48,000
sort of realize that. 
People listen to epicenter 

108
00:06:48,000 --> 00:06:52,900
episodes and they some of them 
might put their money one way or

109
00:06:52,900 --> 00:06:58,900
another based on our episodes. 
And if I feel, if I have a 

110
00:06:58,900 --> 00:07:01,400
critical opinion about 
something, I just want to put it

111
00:07:01,400 --> 00:07:06,800
there and have a discussion 
about it so our listeners see 

112
00:07:07,100 --> 00:07:08,700
what's going on in the hosts. 
Mine. 

113
00:07:09,500 --> 00:07:12,900
Yeah, yeah. 
That's a good way to do it. 

114
00:07:14,500 --> 00:07:18,200
Yeah, for myself I had discuss 
with Sonny prior to the episode,

115
00:07:18,200 --> 00:07:22,500
but I did read the white papers 
and yeah, there were some things

116
00:07:22,500 --> 00:07:26,900
that I also felt, I think it was
after the show, we're talking 

117
00:07:26,900 --> 00:07:33,200
with her, that maybe we were 
there were some fundamental 

118
00:07:34,600 --> 00:07:36,700
differences about how we were 
coming at the problem, and we 

119
00:07:36,700 --> 00:07:45,800
really couldn't get to Get to 
really put forth and agree on 

120
00:07:46,300 --> 00:07:50,500
what we were disagreeing about. 
And yeah, maybe this is 

121
00:07:50,508 --> 00:07:55,000
something that we can try to 
follow up with or try to get a 

122
00:07:55,000 --> 00:08:00,000
better understanding in, you 
know, discussions sort of off 

123
00:08:00,000 --> 00:08:03,000
the show but in Twitter and 
social networks and stuff. 

124
00:08:03,600 --> 00:08:05,600
So, yeah, here it is our 
interview with Monica, 

125
00:08:05,600 --> 00:08:11,000
acquaintance of kadena I forgot 
to mention two things. 

126
00:08:11,200 --> 00:08:13,900
First, we are a web three this 
week in Berlin. 

127
00:08:13,900 --> 00:08:17,000
So if you're in town at the 
event and you see us come, say 

128
00:08:17,000 --> 00:08:21,100
hello, we be happy to see you 
and we will be at Defcon 4 in 

129
00:08:21,100 --> 00:08:25,000
Prague next week, all week long 
and we are hosting a meet up. 

130
00:08:25,100 --> 00:08:27,000
It is the decentralized pumpkin 
meet up. 

131
00:08:27,100 --> 00:08:29,000
If you think pumpkins are too 
centralized, you should come. 

132
00:08:29,000 --> 00:08:31,000
Have drinks with us and discuss 
this core issue. 

133
00:08:31,600 --> 00:08:35,299
It is on October 31st, Halloween
night, between 7:30 and 9:30. 

134
00:08:35,299 --> 00:08:36,600
Right before the big Halloween 
party. 

135
00:08:37,200 --> 00:08:39,700
So location is not quite figured
out yet, but if you go to 

136
00:08:39,700 --> 00:08:44,000
epicenter .t V / Defcon 4 and 
you sign up will send you a 

137
00:08:44,008 --> 00:08:46,100
notification when we have a 
location. 

138
00:08:46,400 --> 00:08:48,700
So, see you at the web 3 and see
what they've done. 

139
00:08:51,100 --> 00:08:54,000
Louis here with Monica 
acquaintance, and Monica is head

140
00:08:54,000 --> 00:08:57,300
of engineering and adoption 
strategy at kadena Monica. 

141
00:08:57,400 --> 00:09:00,300
Thanks for joining us. 
Thanks for having me. 

142
00:09:02,200 --> 00:09:09,500
So kadena is a company that came
out of JPMorgan and we're going 

143
00:09:09,500 --> 00:09:12,300
to be talking to Monica today 
about the work that kadena is 

144
00:09:12,300 --> 00:09:18,300
doing sort of in both public and
private blockchain and both both

145
00:09:18,300 --> 00:09:23,000
of those ecosystems. 
They are building a public 

146
00:09:23,000 --> 00:09:28,300
blockchain network that is based
on a new consensus model that 

147
00:09:28,300 --> 00:09:32,400
they've engineered called chain 
web and there, So on the other 

148
00:09:32,400 --> 00:09:35,200
side of that working on a 
private blockchain 

149
00:09:35,700 --> 00:09:38,400
infrastructure for Enterprise. 
And so today we'll be getting 

150
00:09:38,400 --> 00:09:44,100
into that in detail with me. 
So, first off perhaps, let's get

151
00:09:44,200 --> 00:09:47,200
a better background. 
How did you get involved in 

152
00:09:47,200 --> 00:09:51,100
blockchain technology? 
That's why I love asking 

153
00:09:51,100 --> 00:09:56,300
people's crypto origin stories. 
So my I actually I worked with 

154
00:09:56,600 --> 00:10:03,200
Will at the SEC once upon a 
time, we were both in the group 

155
00:10:03,200 --> 00:10:06,500
that develops software to try to
catch high frequency. 

156
00:10:06,500 --> 00:10:10,400
Trading fraud, the idea is that 
you need software products in 

157
00:10:10,400 --> 00:10:13,500
order to analyze trading 
blotters. 

158
00:10:13,900 --> 00:10:17,700
And so, we were working on a 
team that built will wrote the 

159
00:10:17,700 --> 00:10:20,600
first draft of something. 
That Actually got pushed out to 

160
00:10:20,600 --> 00:10:23,600
a bunch of examiners where they 
can like, upload a trade blotter

161
00:10:23,600 --> 00:10:27,100
and it teaches examiner's, how 
to look for trading fraud. 

162
00:10:27,500 --> 00:10:31,500
So that was we were working 
there at the SEC and he was 

163
00:10:31,600 --> 00:10:33,800
really burned out and I was 
looking for something new. 

164
00:10:33,800 --> 00:10:37,100
So we both left at the same time
and I went to go be a systems 

165
00:10:37,100 --> 00:10:40,400
engineer for rent to the runway,
which is a fashion company based

166
00:10:40,400 --> 00:10:44,200
in New York, and he went to 
jpmorgan's, blockchain research 

167
00:10:44,200 --> 00:10:48,100
Group, which was Hughes the lead
engineer there and was hired by 

168
00:10:48,100 --> 00:10:50,700
Stu popejoy. 
And so, we'll and Stu were 

169
00:10:50,700 --> 00:10:54,300
working on the team that made 
Juno, which was originally 

170
00:10:54,300 --> 00:10:55,900
proposed to become part of hyper
Ledger. 

171
00:10:55,900 --> 00:10:58,500
And then it didn't. 
And then it sort of eventually 

172
00:10:58,500 --> 00:11:01,800
morphed into the team that 
worked on Quorum before they 

173
00:11:01,808 --> 00:11:04,800
were doing, that will ensue were
like, oh, we've made this really

174
00:11:04,800 --> 00:11:07,400
incredible thing. 
This private blockchain, we 

175
00:11:07,400 --> 00:11:11,000
should turn that into a company 
so they left and they started 

176
00:11:11,000 --> 00:11:13,000
kadena. 
Originally make a private 

177
00:11:13,000 --> 00:11:16,700
blockchain with a smart contract
language and then they're like, 

178
00:11:16,700 --> 00:11:19,000
wait a minute, we have an 
opportunity here. 

179
00:11:19,200 --> 00:11:21,100
We could take this from our 
contract language and we could 

180
00:11:21,100 --> 00:11:24,900
put it on a public blockchain 
and then so over time we've 

181
00:11:24,900 --> 00:11:28,700
evolved into this place where 
our product is actually just a 

182
00:11:28,700 --> 00:11:31,500
block chain that works for both 
public and private. 

183
00:11:32,000 --> 00:11:35,400
So willens do called me and 
said, hey we're going to make a 

184
00:11:35,408 --> 00:11:37,000
public blockchain. 
Do you want to come? 

185
00:11:37,300 --> 00:11:40,300
We need a systems engineer and 
we need somebody who can talk to

186
00:11:40,300 --> 00:11:41,900
people about what engineering 
means. 

187
00:11:42,400 --> 00:11:48,000
So yeah, that's I started in 
December of last year, which has

188
00:11:48,000 --> 00:11:50,600
been, I guess that's it. 
Like, ten months now, it's been 

189
00:11:50,600 --> 00:11:54,600
the longest 10 months of my 
life, we do a lot of great 

190
00:11:54,600 --> 00:11:56,000
stuff. 
A lot of good research but it's 

191
00:11:56,000 --> 00:11:58,400
also just like everything moves 
so fast. 

192
00:12:00,600 --> 00:12:02,500
Interesting. 
So you mentioned, you work at a 

193
00:12:02,700 --> 00:12:06,100
fashion company. 
How how is that experience, 

194
00:12:06,100 --> 00:12:09,100
informed anything that you're 
doing a get enough through? 

195
00:12:09,100 --> 00:12:12,900
The I was on the team that was 
doing data infrastructure and 

196
00:12:12,900 --> 00:12:17,900
that was a we were taking it 
from a bare metal database to a 

197
00:12:18,000 --> 00:12:19,800
distributed data cluster in the 
cloud. 

198
00:12:20,100 --> 00:12:22,300
So I was working on this 
project. 

199
00:12:22,300 --> 00:12:27,300
I was the tech lead for taking 
basically a, the old school 

200
00:12:27,300 --> 00:12:31,900
cluster in Secaucus New Jersey. 
And put more at migrating that 

201
00:12:31,900 --> 00:12:36,100
so that was, it ends up being 
really useful because I can 

202
00:12:36,100 --> 00:12:40,200
think about data and how its 
structured, and how it's stored 

203
00:12:40,200 --> 00:12:43,700
and like what atomicity means 
and being able to replicate 

204
00:12:43,700 --> 00:12:46,200
transactions. 
And so it actually translates 

205
00:12:46,200 --> 00:12:50,800
pretty well to the idea of 
blockchain to, in my mind a 

206
00:12:50,808 --> 00:12:54,200
blockchain is not necessarily 
different from the database. 

207
00:12:54,200 --> 00:12:56,600
It's just a data store that 
nobody administers. 

208
00:12:57,100 --> 00:12:59,300
It has some particular rules 
about it, but at the end of the 

209
00:12:59,300 --> 00:13:01,500
day, like it, Just another 
distributed data store. 

210
00:13:03,300 --> 00:13:05,800
I was not expecting that 
experience to be some 

211
00:13:05,800 --> 00:13:11,500
informative but more 
specifically, I think maybe we 

212
00:13:11,500 --> 00:13:13,500
could talk about your role at 
the SEC what you were doing 

213
00:13:13,500 --> 00:13:17,800
there and how that sort of that 
brought you into your trajectory

214
00:13:17,800 --> 00:13:22,200
into what you're doing now. 
So the interesting thing about 

215
00:13:22,200 --> 00:13:28,500
what we were doing at the ICC is
that the their technology 

216
00:13:28,500 --> 00:13:34,300
requirements are very high but 
they have the the talent there 

217
00:13:34,300 --> 00:13:36,700
needs to be roughly unfettered 
in order to do what they're 

218
00:13:36,700 --> 00:13:38,800
doing. 
And this idea of trying to 

219
00:13:38,800 --> 00:13:43,400
create sort of a tech incubator 
inside of a large government 

220
00:13:43,400 --> 00:13:47,100
organization, we were at the 
Forefront of that and it didn't 

221
00:13:47,100 --> 00:13:51,400
always like there's obviously 
friction there because engineer 

222
00:13:51,400 --> 00:13:53,700
is that have that are really 
brilliant and we had some 

223
00:13:53,700 --> 00:13:56,200
incredible brilliant people on 
that team and a lot of them are 

224
00:13:56,200 --> 00:13:59,900
still there. 
The idea of having to push the 

225
00:13:59,900 --> 00:14:05,800
agenda for new The Event Horizon
of new technology inside of a 

226
00:14:05,808 --> 00:14:08,400
government organization, that we
had a lot of friction there. 

227
00:14:09,300 --> 00:14:11,500
So I actually didn't last very 
long. 

228
00:14:11,500 --> 00:14:13,400
Well, was there for almost two 
years. 

229
00:14:13,800 --> 00:14:17,100
I was only there for like, four 
months before will left. 

230
00:14:17,100 --> 00:14:20,500
And I was like, I was just here 
to work with Will, who is we've 

231
00:14:20,500 --> 00:14:22,200
been friends basically, since 
College? 

232
00:14:25,100 --> 00:14:27,700
Cool. 
So shifting into kadena, can you

233
00:14:27,700 --> 00:14:30,100
talk about some of the main 
projects that the companies 

234
00:14:30,100 --> 00:14:36,000
working on? 
Yeah, so the we essentially have

235
00:14:36,000 --> 00:14:40,600
our hypothesis is that there is 
you only need one block chain 

236
00:14:40,700 --> 00:14:43,900
instead of going around and 
trying to Cobble together, like,

237
00:14:44,000 --> 00:14:47,900
oh, I'm going to launch my token
using etherium, and then I'm 

238
00:14:47,900 --> 00:14:50,800
going to write it in solidity 
but I might want to compiled a 

239
00:14:50,800 --> 00:14:53,400
Waze mm. 
And then I might want to have 

240
00:14:53,400 --> 00:14:56,900
some sort of second, Scalability
Solution on top. 

241
00:14:56,900 --> 00:14:59,100
And then under, like, it's too 
confusing. 

242
00:14:59,400 --> 00:15:02,100
It's too hard. 
Nobody wants to develop on that.

243
00:15:02,100 --> 00:15:05,500
It's not developer-friendly. 
We're still at the build, your 

244
00:15:05,500 --> 00:15:09,700
own PC stage of computing right 
now. 

245
00:15:09,700 --> 00:15:12,600
We're like it's for hobbyists 
and it's for people that like, 

246
00:15:12,600 --> 00:15:16,400
get excited about seeing all 
these weird tool stuff but we're

247
00:15:16,400 --> 00:15:20,200
not going to see real adoption 
and usage and blockchain land 

248
00:15:20,200 --> 00:15:23,000
until we move away from like, oh
well, you know, you're not a 

249
00:15:23,000 --> 00:15:26,500
real blockchain developer on. 
Less you build your own stack. 

250
00:15:26,500 --> 00:15:29,600
We are offering a stack that 
just works instead of building 

251
00:15:29,600 --> 00:15:31,100
your own PC. 
You can just go to the Apple 

252
00:15:31,100 --> 00:15:35,000
Store and you can buy a Mac and 
it'll just work and you can just

253
00:15:35,000 --> 00:15:36,400
do your development on top of 
it. 

254
00:15:37,100 --> 00:15:39,400
So we have our own smart 
contract language and we're 

255
00:15:39,400 --> 00:15:41,800
building our own public 
blockchain and it already 

256
00:15:41,800 --> 00:15:43,500
scales. 
It already has a base layer 

257
00:15:43,500 --> 00:15:45,300
scaling solution. 
We're building all of our own 

258
00:15:45,300 --> 00:15:47,100
tooling. 
So right now we're working on a 

259
00:15:47,100 --> 00:15:50,600
pretty developer IDE that has 
built-in error messages that has

260
00:15:50,600 --> 00:15:53,800
built-in formal verification. 
We have a bunch of new 

261
00:15:53,800 --> 00:15:56,700
developments around. 
How we use formal verification 

262
00:15:56,700 --> 00:15:59,700
in our stack. 
And then we also have the way 

263
00:15:59,700 --> 00:16:03,100
that we deal with privacy and 
handling privacy Solutions, is 

264
00:16:03,400 --> 00:16:06,600
we have you can have an oracle 
out to our private blockchains 

265
00:16:06,600 --> 00:16:09,000
so you can share as much data 
with public blockchain as you 

266
00:16:09,000 --> 00:16:12,100
want to and it just it's all 
designed to work together. 

267
00:16:12,100 --> 00:16:15,300
You don't have to go around and 
like find a bunch of third-party

268
00:16:15,300 --> 00:16:17,500
solutions to try to do the thing
that you're trying to do. 

269
00:16:19,000 --> 00:16:23,000
So you mentioned that there 
should be only one block chain 

270
00:16:23,100 --> 00:16:26,000
and so you're building your 
building this block chain based 

271
00:16:26,000 --> 00:16:31,600
of this idea called chain web. 
How does so? 

272
00:16:32,000 --> 00:16:36,000
Is it like do intend to build 
these permission private 

273
00:16:36,000 --> 00:16:38,900
blockchains using the work that 
was done at JPMorgan? 

274
00:16:39,300 --> 00:16:41,500
These will be separate block 
chains that Connect into this 

275
00:16:41,500 --> 00:16:45,100
system or has your focus 
entirely shifted to just a 

276
00:16:45,100 --> 00:16:49,600
public chain. 
We are still working on the 

277
00:16:49,600 --> 00:16:52,100
private blockchain. 
We're actually have a healthcare

278
00:16:52,100 --> 00:16:55,300
insurance Consortium that's 
using our private blockchain 

279
00:16:55,300 --> 00:16:58,600
right now. 
In order to they have an MVP and

280
00:16:58,600 --> 00:17:01,400
they're working on getting the 
pilot up and running between 

281
00:17:01,400 --> 00:17:04,400
these different companies and 
right now they're using it for 

282
00:17:04,900 --> 00:17:08,800
doctor office information. 
Sharing the idea is that each of

283
00:17:08,800 --> 00:17:12,400
these insurance companies get 
fined if they don't have correct

284
00:17:12,400 --> 00:17:15,500
information about like where a 
doctor is located and what 

285
00:17:15,500 --> 00:17:19,000
insurance they're taking. 
So each of them have people that

286
00:17:19,000 --> 00:17:22,400
they spend money on that, call 
all of the doctor, like every 

287
00:17:22,400 --> 00:17:24,700
doctor in order to try and 
figure out what the right 

288
00:17:24,700 --> 00:17:28,200
information is obviously they 
spend a ton of money doing this 

289
00:17:28,200 --> 00:17:30,500
redundant work because they're 
all trying to do it. 

290
00:17:31,000 --> 00:17:35,200
So phase one of this project is 
each of them, instead can 

291
00:17:35,200 --> 00:17:38,700
contribute to this ownerless 
system, where they all benefit 

292
00:17:38,700 --> 00:17:40,900
from the data. 
And right now, there's a 

293
00:17:40,900 --> 00:17:44,600
mechanism in it where they can 
everybody pays into the system 

294
00:17:45,000 --> 00:17:48,800
by running their nodes and then 
They get rewarded for updating 

295
00:17:48,800 --> 00:17:51,200
pieces of data. 
And then eventually, the idea is

296
00:17:51,200 --> 00:17:54,800
that this project we will 
connect to the public blockchain

297
00:17:54,800 --> 00:17:57,500
and allow doctors to actually 
update their own information 

298
00:17:57,500 --> 00:18:00,600
because then they don't get 
spammed with calls from every 

299
00:18:00,600 --> 00:18:03,200
single insurance company and 
then they can get rewarded 

300
00:18:03,200 --> 00:18:06,500
directly. 
So the network can actually 

301
00:18:06,500 --> 00:18:09,700
sustain itself in terms of data 
update and storage. 

302
00:18:09,700 --> 00:18:13,300
So this is the kind of idea was 
like a private Block Chain, that

303
00:18:13,300 --> 00:18:16,800
connects to a public blockchain 
but really it's just One 

304
00:18:16,800 --> 00:18:20,300
project, it's the project where 
doctors and insurance companies 

305
00:18:20,300 --> 00:18:21,700
can communicate with better 
data. 

306
00:18:22,100 --> 00:18:24,800
But it's connected of all these 
different pieces which is a 

307
00:18:24,800 --> 00:18:27,500
private blockchain with our 
smart contract language on top. 

308
00:18:27,500 --> 00:18:30,000
That connects to a public 
blockchain interface. 

309
00:18:32,300 --> 00:18:34,600
You know the Dutch have given us
so much orange. 

310
00:18:34,600 --> 00:18:37,700
Carrots, Bluetooth. 
Artificial hearts, even Donuts 

311
00:18:37,700 --> 00:18:40,600
were invented by Dutch people, 
but they also gave us Dutch 

312
00:18:40,600 --> 00:18:43,500
auctions, which as it turns out 
are great for decentralized. 

313
00:18:43,500 --> 00:18:46,500
Exchanges Dutch, X is a 
decentralized trade. 

314
00:18:46,700 --> 00:18:50,400
Protocol for ERC, 20 tokens and 
it's invented designed and built

315
00:18:50,400 --> 00:18:53,000
by kenosis current order book 
based exchanges. 

316
00:18:53,000 --> 00:18:55,500
Whether centralized or 
decentralized have a couple of 

317
00:18:55,500 --> 00:18:59,000
issues, minors and exchanges can
FrontRunner trade when they step

318
00:18:59,000 --> 00:19:01,400
in front of a large order to 
gain an economic Advantage. 

319
00:19:01,700 --> 00:19:04,400
Not to mention issues with 
securing funds, High listing 

320
00:19:04,400 --> 00:19:07,000
fees, lack of liquidity and 
pricing efficiencies. 

321
00:19:07,300 --> 00:19:09,500
The Dutch checks. 
Exchange platform uses a Dutch 

322
00:19:09,500 --> 00:19:12,900
auction mechanism to determine 
the fair value for a token and 

323
00:19:12,900 --> 00:19:15,800
participants in a trade are 
encouraged to reveal their true 

324
00:19:15,800 --> 00:19:17,700
willingness to pay. 
Say which eliminates front 

325
00:19:17,700 --> 00:19:20,100
running as a permissionless on 
chain protocol. 

326
00:19:20,100 --> 00:19:22,800
It's useful for Bots and other 
smart contracts needing to 

327
00:19:22,800 --> 00:19:26,400
exchange tokens and Dutch X also
acts as an oracle for dash, 

328
00:19:26,400 --> 00:19:28,900
requiring, a price feed. 
So to learn more, check out the 

329
00:19:28,900 --> 00:19:33,000
documentation at epicenter. 
Dot TV, / THX, smart contracts 

330
00:19:33,000 --> 00:19:35,600
are live on a theorem a net. 
So you can start building today,

331
00:19:36,300 --> 00:19:38,900
we'd like to thank gnosis and 
checks for their support of 

332
00:19:38,900 --> 00:19:41,900
epicenter. 
I'd like to come back just to 

333
00:19:41,900 --> 00:19:43,800
this thing. 
You said earlier that that we 

334
00:19:43,800 --> 00:19:47,400
would only have one block chain 
as a software developer, I'm 

335
00:19:47,400 --> 00:19:51,000
sure you can appreciate that. 
We have multiple programming 

336
00:19:51,200 --> 00:19:55,200
different programming languages 
from C++ to Java to JavaScript 

337
00:19:55,200 --> 00:19:59,400
and things like PHP and node, 
and all these different 

338
00:19:59,400 --> 00:20:03,000
programming languages, sort of 
serve a specific use cases, or 

339
00:20:03,000 --> 00:20:04,800
specific type of application 
development. 

340
00:20:04,800 --> 00:20:07,100
You know, whether it be for web 
development or Enterprise or in 

341
00:20:07,100 --> 00:20:11,000
solidity for smart contracts and
such I think that this analogy 

342
00:20:11,000 --> 00:20:15,600
is sort of overlaps quite well 
in the blockchain space one 

343
00:20:15,600 --> 00:20:18,500
because presumably they'll be 
many types of applications for 

344
00:20:18,500 --> 00:20:22,000
blockchain but also just because
of the sheer nature of Open 

345
00:20:22,000 --> 00:20:25,300
Source software and how things 
sort of or can proliferate, and 

346
00:20:25,300 --> 00:20:27,900
people work on their own 
projects and build their own 

347
00:20:27,900 --> 00:20:31,000
applications in such. 
Do you do you think that really 

348
00:20:31,000 --> 00:20:33,800
stands up that there could be a 
future where potentially we 

349
00:20:33,800 --> 00:20:36,800
could only have one block chain 
and everything else just 

350
00:20:37,100 --> 00:20:39,500
vanishes. 
So I definitely did not say 

351
00:20:39,500 --> 00:20:41,500
that. 
We Should only have one 

352
00:20:41,500 --> 00:20:45,600
blockchain, what I was trying to
say and it may not have come out

353
00:20:45,600 --> 00:20:50,300
this way was the idea that you 
should have the option to just 

354
00:20:50,300 --> 00:20:54,500
have a thing that works. 
And I don't necessarily agree 

355
00:20:54,500 --> 00:20:57,500
with like, there are multiple 
operating systems and people 

356
00:20:57,500 --> 00:21:00,100
write in different languages and
we have lots of discussions 

357
00:21:00,100 --> 00:21:04,200
about languages all of the time 
but you don't have to build your

358
00:21:04,200 --> 00:21:08,400
own computer in order to do 
development right now like the 

359
00:21:08,400 --> 00:21:12,600
onboarding pipeline. 
For becoming a web developer, 

360
00:21:12,600 --> 00:21:17,200
for example is easy. 
You just you go to the store and

361
00:21:17,200 --> 00:21:21,200
you buy a computer and then you 
like, write your first app and 

362
00:21:21,200 --> 00:21:23,100
it's not that hard. 
You don't have to understand how

363
00:21:23,100 --> 00:21:27,100
a computer works to write a web 
app, you don't need to. 

364
00:21:27,100 --> 00:21:28,900
We want to get to the place 
where you don't have to 

365
00:21:28,900 --> 00:21:33,100
necessarily understand like how 
cryptographic hashing Works in 

366
00:21:33,100 --> 00:21:35,600
order to build an app on a 
blockchain. 

367
00:21:35,900 --> 00:21:38,300
That was the point that I was 
trying to make that right now, 

368
00:21:38,300 --> 00:21:40,500
the learning curve is too steep.
Too high. 

369
00:21:40,500 --> 00:21:44,800
You have to like have an opinion
on validator nodes and like, 

370
00:21:44,800 --> 00:21:47,300
what's the right structure? 
Do you want to use like 

371
00:21:47,300 --> 00:21:51,300
distributed or do you want to 
use pbft or like all of these 

372
00:21:51,300 --> 00:21:53,800
things like people here, all 
these terms floating around, 

373
00:21:53,800 --> 00:21:57,200
they get totally bewildered. 
And we scare away otherwise 

374
00:21:57,200 --> 00:22:00,600
perfectly good developers who 
would be great for our community

375
00:22:00,600 --> 00:22:05,500
with like Balderdash around 
stupid stuff about consensus 

376
00:22:05,500 --> 00:22:08,600
protocols like that stuff does 
not matter when you just want 

377
00:22:08,600 --> 00:22:11,100
people to build something. 
I Want to get the on-ramp from 

378
00:22:11,100 --> 00:22:13,600
people learning about blockchain
to building things on blockchain

379
00:22:13,700 --> 00:22:18,000
to be way easier. 
And I don't think that we're 

380
00:22:18,000 --> 00:22:19,300
going to end up with one block 
chain. 

381
00:22:19,500 --> 00:22:24,400
I'm fact I think that continuing
to make like we because of the 

382
00:22:24,400 --> 00:22:27,800
way that interoperability Works 
inside of our own protocol mean 

383
00:22:27,800 --> 00:22:31,400
that we are already set up to 
have interoperability with other

384
00:22:31,400 --> 00:22:34,900
projects which means we're going
to connect to the cosmos Hub and

385
00:22:34,900 --> 00:22:37,100
we're going to connect to a 
theorem and you'll be able to 

386
00:22:37,100 --> 00:22:38,500
launch your token on a theory 
on. 

387
00:22:38,500 --> 00:22:41,200
But have it the all of your 
transactions happen on top of 

388
00:22:41,200 --> 00:22:43,200
kadena? 
That's that's the goal. 

389
00:22:44,600 --> 00:22:49,700
So of course you want to build 
this main public network and 

390
00:22:50,100 --> 00:22:53,000
because you want it to be 
accessible to developers of all 

391
00:22:53,000 --> 00:22:56,500
kinds, you wanted to be 
scalable, right? 

392
00:22:56,500 --> 00:23:01,000
So that's why kadena is focusing
on scalability for its public 

393
00:23:01,000 --> 00:23:05,500
chain. 
Yeah, we're focused on the way 

394
00:23:05,500 --> 00:23:08,300
that our architecture setup. 
We actually get both scalability

395
00:23:08,300 --> 00:23:12,400
and security. 
The the design for chain web was

396
00:23:12,400 --> 00:23:15,900
originally proposed by people 
not us. 

397
00:23:15,900 --> 00:23:19,100
It was probably the first paper 
that came out with something 

398
00:23:19,100 --> 00:23:22,800
like that was for Block rope, 
which came out and suggested a 

399
00:23:22,800 --> 00:23:25,800
way of scaling Bitcoin for 
security purposes, where you can

400
00:23:25,800 --> 00:23:28,800
have two Bitcoins that share 
their proofs with each other, 

401
00:23:28,900 --> 00:23:31,600
which would give you an 
additional security property. 

402
00:23:31,800 --> 00:23:35,600
And we came up with this 
separately, and then ended up 

403
00:23:35,608 --> 00:23:38,500
coming back around to the same 
place where we've proposed it 

404
00:23:38,500 --> 00:23:41,600
for scalability and then realize
that we also get the security 

405
00:23:41,600 --> 00:23:45,000
feature. 
So yes, the idea is that you can

406
00:23:45,000 --> 00:23:47,300
just put something on chain web 
and not have to worry about 

407
00:23:47,300 --> 00:23:48,800
whether it's going to scale out 
or not. 

408
00:23:50,100 --> 00:23:54,100
Yes, and let's talk about chain 
web and this scalability and 

409
00:23:54,100 --> 00:24:00,800
security solution. 
Through it, how it works. 

410
00:24:01,500 --> 00:24:05,500
I usually do this with diagrams 
because it's a sometimes hard to

411
00:24:05,500 --> 00:24:07,800
visualize. 
I'm a very visual person but we 

412
00:24:07,800 --> 00:24:13,700
can talk about it. 
So imagine Bitcoin and the idea 

413
00:24:13,700 --> 00:24:18,000
that you have a block and then 
your new block that you generate

414
00:24:18,000 --> 00:24:20,600
on top of that one has a 
reference back to the original 

415
00:24:20,600 --> 00:24:22,100
block. 
Right. 

416
00:24:22,100 --> 00:24:27,300
This is the idea of like hash 
linking, or having a root or a 

417
00:24:27,300 --> 00:24:32,000
tree like a Merkle tree. 
So now, imagine if you had two 

418
00:24:32,000 --> 00:24:36,000
chains, then they each have 
their Genesis block and then 

419
00:24:36,000 --> 00:24:39,300
they each start working on their
first block. 

420
00:24:39,300 --> 00:24:43,500
The first block for each of 
these chains would contain the 

421
00:24:43,500 --> 00:24:48,400
proof, like just the hash of the
Year, their peer chains previous

422
00:24:48,400 --> 00:24:50,400
block. 
So, not only do they have a 

423
00:24:50,400 --> 00:24:52,900
reference to their On previous 
block, they have a reference to 

424
00:24:52,900 --> 00:24:56,000
their peer chains, previous 
block, you can see for Two 

425
00:24:56,000 --> 00:24:58,000
Chains, this is a lot of 
messages. 

426
00:24:58,000 --> 00:25:01,700
Like you have exactly double the
number of references as you do 

427
00:25:01,700 --> 00:25:06,600
chains, and that's a lot. 
So the way that we scale this is

428
00:25:06,600 --> 00:25:11,400
by using a fixed graph structure
and at this point, people are 

429
00:25:11,400 --> 00:25:14,900
like, oh, this makes you a dag 
with my response is all 

430
00:25:14,900 --> 00:25:19,000
blockchains are a dag. 
So all of these projects like 

431
00:25:19,000 --> 00:25:23,100
cash graph and Iota are what 
Like to call arbitrary tags 

432
00:25:23,300 --> 00:25:25,700
where they'll just pick like, 
some neighbor. 

433
00:25:26,100 --> 00:25:28,400
That's listening. 
That's ready to receive piece of

434
00:25:28,400 --> 00:25:31,500
information. 
We have a fixed graph structure 

435
00:25:32,300 --> 00:25:35,400
where peer chains, always 
communicate to the pier that 

436
00:25:35,400 --> 00:25:40,600
they're supposed to talk to. 
And the way this gives us the 

437
00:25:40,600 --> 00:25:43,400
benefit of always having them 
communicate in the most 

438
00:25:43,400 --> 00:25:47,300
efficient manner, specifically, 
our graph structure with how we 

439
00:25:47,300 --> 00:25:50,600
braid the chains together. 
We use solutions to the degree 

440
00:25:50,600 --> 00:25:53,300
diameter. 
A problem which is how do you 

441
00:25:53,300 --> 00:25:57,200
have the largest order graph 
with a minimum number of 

442
00:25:57,200 --> 00:26:02,800
messages between nodes the 
degree and the longest shortest 

443
00:26:02,800 --> 00:26:07,200
top is minimized. 
So that's like the, the shortest

444
00:26:07,200 --> 00:26:10,600
path between two points. 
What's the longest one of those 

445
00:26:11,100 --> 00:26:14,700
minimize that number? 
So it allows for the fastest 

446
00:26:14,700 --> 00:26:18,800
propagation of information out 
to all of the nodes, now this is

447
00:26:18,800 --> 00:26:21,200
how we get it to be fast and how
we get it. 

448
00:26:21,700 --> 00:26:24,100
Basically communicate with each 
other and effective matter is, 

449
00:26:24,100 --> 00:26:28,400
by picking a fixed graph 
structure, and we have for each 

450
00:26:28,400 --> 00:26:32,000
potential size of chain web 
over, which there are, you know,

451
00:26:32,300 --> 00:26:34,600
many many, many different 
potential sizes. 

452
00:26:35,100 --> 00:26:37,600
Each of them, we get to pick the
most efficient structure per 

453
00:26:37,600 --> 00:26:39,700
size. 
So, I talked about the Peterson 

454
00:26:39,700 --> 00:26:43,400
graph a lot because it's easy to
visualize in your mind, it's 10 

455
00:26:43,400 --> 00:26:46,800
chains, each of those chains, 
communicating with each other, 

456
00:26:46,800 --> 00:26:50,500
in a fixed graph structure with 
a degree of 2 and a diameter of 

457
00:26:50,500 --> 00:26:53,000
2. 
So, Oh, that's to Nessa jizz per

458
00:26:53,000 --> 00:26:57,200
node and to block height to 
receive full information 

459
00:26:57,200 --> 00:26:59,900
propagation from any node to any
other node. 

460
00:27:01,500 --> 00:27:03,900
Okay? 
Okay, so let's let's unpack 

461
00:27:03,900 --> 00:27:06,800
that. 
Like so the way I'm thinking of 

462
00:27:06,800 --> 00:27:11,100
it is so, so imagine Two Chains.
Let's say you have the Litecoin 

463
00:27:11,100 --> 00:27:13,800
chain and you have the Monaro 
Gene, right? 

464
00:27:16,200 --> 00:27:18,600
So we don't have 
interoperability between 

465
00:27:18,600 --> 00:27:20,800
different projects, it's not, 
it's not interoperability 

466
00:27:20,800 --> 00:27:24,800
between Projects. 
So what I'm trying to do is 

467
00:27:24,800 --> 00:27:28,100
essentially start with like 
Litecoin and more narrow strip 

468
00:27:28,100 --> 00:27:30,400
away things. 
We don't need like two coins. 

469
00:27:30,500 --> 00:27:34,000
Let's strip that away and have 
one coin and then and slowly 

470
00:27:34,000 --> 00:27:37,900
from from that starting point. 
Let's build kadena, right. 

471
00:27:38,200 --> 00:27:43,500
So, so so imagine like you have 
this is just imagine you have 

472
00:27:43,500 --> 00:27:46,600
like Litecoin and more narrow 
and we have like two chains. 

473
00:27:47,800 --> 00:27:50,900
And these two, two chains have 
two different coins today. 

474
00:27:50,900 --> 00:27:54,600
So one is light going, the other
is one arrow and somehow in 

475
00:27:55,100 --> 00:27:57,800
later on in Cadena, it's like we
are going to remove the two 

476
00:27:57,800 --> 00:27:59,900
coins and there's going to be a 
single coin. 

477
00:28:00,400 --> 00:28:03,900
So can we can we just talk about
cloning Bitcoin instead like you

478
00:28:03,900 --> 00:28:07,400
have Bitcoin and then you have 
another Bitcoin and they're both

479
00:28:07,400 --> 00:28:10,500
like because the idea is that 
all of the chains are actually 

480
00:28:10,500 --> 00:28:13,400
identical. 
They're completely identical in 

481
00:28:13,400 --> 00:28:16,700
terms of how they maintain state
in terms of how you interact 

482
00:28:16,700 --> 00:28:18,500
with it in terms. 
Of what they support. 

483
00:28:18,500 --> 00:28:21,100
Like they're all completely 
clones of each other. 

484
00:28:21,500 --> 00:28:26,400
Okay, so they're going to things
Bitcoin and Bitcoin to, okay. 

485
00:28:26,400 --> 00:28:28,400
So you have Bitcoin and one in 
Bitcoin to. 

486
00:28:29,300 --> 00:28:32,100
And so you have like two these 
two blockchains, they both are 

487
00:28:32,100 --> 00:28:34,400
producing blocks else. 
Let's say, 10 minutes. 

488
00:28:36,300 --> 00:28:41,500
And now let's say I'm a minor 
and in Bitcoin one I'm a minor 

489
00:28:41,500 --> 00:28:45,200
in that chain. 
So I create a block right. 

490
00:28:46,200 --> 00:28:51,000
So what happens differently now 
in kadena, so in in Bitcoin when

491
00:28:51,000 --> 00:28:55,000
I create a block in Bitcoin one,
I would reference only the 

492
00:28:55,000 --> 00:28:57,600
previous block of Bitcoin. 
One, what would I do differently

493
00:28:57,600 --> 00:28:59,600
in kadena? 
Right. 

494
00:28:59,600 --> 00:29:05,300
So as a minor, we expect that 
everybody's best case scenario 

495
00:29:05,300 --> 00:29:08,800
would be to me. 
All of the chains, all of the 

496
00:29:08,800 --> 00:29:10,700
time. 
So as a minor, you're actually 

497
00:29:10,700 --> 00:29:14,100
mining both Bitcoin and Bitcoin 
to you're trying to get a 

498
00:29:14,108 --> 00:29:17,600
success on both chains which 
from like a game theory 

499
00:29:17,600 --> 00:29:22,100
perspective, you want to split 
your hashing power because you 

500
00:29:22,100 --> 00:29:25,100
don't want to have a collision 
where you get a success. 

501
00:29:25,100 --> 00:29:28,700
Like if you throw all 100 
threads on the same, to 

502
00:29:28,700 --> 00:29:32,400
generating the same block, 
there's a nonzero probability 

503
00:29:32,400 --> 00:29:36,900
that you get a success on to of 
your threads at the same time 

504
00:29:36,900 --> 00:29:39,500
which case you've wasted a bunch
of hash power and you should 

505
00:29:39,500 --> 00:29:42,900
have to throw one of them away. 
So instead we positive that 

506
00:29:42,900 --> 00:29:46,100
people are going to try to mine 
as many changes as possible all 

507
00:29:46,100 --> 00:29:49,100
at the same time because then 
they can have more potential, 

508
00:29:49,100 --> 00:29:52,900
successes all at the same time. 
So you as a minor would mine 

509
00:29:52,900 --> 00:29:55,900
both Bitcoin one and Bitcoin to 
and you're just like hammering 

510
00:29:55,900 --> 00:29:57,700
away at both of them at the same
time. 

511
00:29:57,800 --> 00:30:01,800
So for example, if I have 100 
e-cig machines, I'm putting 50 

512
00:30:01,800 --> 00:30:05,800
Asic machines on bitcoin one and
the other 50 on bitcoin. 

513
00:30:06,700 --> 00:30:08,200
Sure. 
Yeah, all right, let's go. 

514
00:30:08,200 --> 00:30:14,400
So if if you're mining Bitcoin 
one, did your block that you're 

515
00:30:14,400 --> 00:30:20,200
attempting to solve has in its 
header, a reference to both the 

516
00:30:20,200 --> 00:30:23,500
previous Block in Bitcoin one 
and the previous block on 

517
00:30:23,500 --> 00:30:28,900
bitcoin to Okay, so I'll create 
a block on bitcoin one and it 

518
00:30:28,900 --> 00:30:33,200
says, when this block comes 
comes in it references, the 

519
00:30:33,200 --> 00:30:36,100
previous Block in Bitcoin one 
and then it also says, oh, the 

520
00:30:36,100 --> 00:30:39,800
last block that I had heard of 
in Bitcoin to was this. 

521
00:30:40,200 --> 00:30:43,900
So put that in as well. 
Yes, right. 

522
00:30:44,500 --> 00:30:47,500
And similarly, some other minor 
that generates a block in 

523
00:30:47,500 --> 00:30:52,200
Bitcoin to would have listened 
about my block in Bitcoin one 

524
00:30:52,200 --> 00:30:56,100
and they would put the my hash 
of this block in between And one

525
00:30:56,400 --> 00:30:58,800
in their block when they create 
one in Bitcoin to. 

526
00:30:58,900 --> 00:31:00,300
Yes. 
Exactly. 

527
00:31:01,000 --> 00:31:04,900
So information about each block 
in Bitcoin to ends up, entering 

528
00:31:04,900 --> 00:31:10,200
the Bitcoin, one blockchain and 
information about each block in 

529
00:31:10,200 --> 00:31:14,000
the Bitcoin, one chain ends up 
entering Bitcoin to. 

530
00:31:14,600 --> 00:31:19,800
Yes, exactly. 
And the benefit of doing this is

531
00:31:20,300 --> 00:31:23,300
to fold one. 
It keeps the network from 

532
00:31:23,300 --> 00:31:28,800
diverging because if you have to
listen to your peer chains, then

533
00:31:28,800 --> 00:31:32,700
you have to very quickly come to
like if there are two potential 

534
00:31:32,700 --> 00:31:36,800
blocks on bitcoin one and you're
a minor on bitcoin to when you 

535
00:31:36,800 --> 00:31:39,400
hear about both of these blocks,
you must immediately pick one 

536
00:31:39,400 --> 00:31:43,100
because you can only include one
of them as the truth of Bitcoin 

537
00:31:43,100 --> 00:31:47,600
one in your next block. 
So it's a way of forcing Forks 

538
00:31:47,600 --> 00:31:51,900
to recombine faster because if 
there's a fork on bitcoin one 

539
00:31:51,900 --> 00:31:57,000
not only do the Bitcoin one 
miners, have Pick one, but also,

540
00:31:57,000 --> 00:32:00,300
all of the other peer chains in 
this case, Bitcoin, to have to 

541
00:32:00,300 --> 00:32:03,900
pick one which forces people to 
make decisions, which is what 

542
00:32:03,900 --> 00:32:08,100
resolves Forks. 
So, that's one reason, the other

543
00:32:08,100 --> 00:32:10,700
reason is this allows us to 
share. 

544
00:32:10,900 --> 00:32:15,200
This is how we propagate State 
between chains and which we do 

545
00:32:15,200 --> 00:32:17,500
through simple payment 
verification. 

546
00:32:18,200 --> 00:32:21,300
So if I want have an account on 
bitcoin one and we're an 

547
00:32:21,300 --> 00:32:25,200
account-based, not UT exobase. 
So I have an account on bitcoin 

548
00:32:25,200 --> 00:32:27,300
one. 
One and I want to pay you, but 

549
00:32:27,300 --> 00:32:30,900
you're on bitcoin to the way 
that we do that is we write a 

550
00:32:30,908 --> 00:32:34,400
smart contract or I hate the 
terms of our contract, we can 

551
00:32:34,400 --> 00:32:37,900
call it a smart contract between
the two of us on bitcoin one in 

552
00:32:37,900 --> 00:32:43,600
which I say, like oh I'm going 
to pay my hair, one token and 

553
00:32:43,900 --> 00:32:49,800
then it is signed to your 
account on bitcoin to and then 

554
00:32:49,800 --> 00:32:54,300
we put that in on bitcoin one, 
the proof of it propagates in 

555
00:32:54,300 --> 00:32:58,400
the next block, 2. 
Point to, at which point you 

556
00:32:58,400 --> 00:33:01,900
say, hey, I'm going to redeem my
half of the smart contract, on 

557
00:33:01,900 --> 00:33:06,700
bitcoin to I have destroyed the 
coins on bitcoin one and they're

558
00:33:06,700 --> 00:33:09,000
gone. 
And then you redeem, which 

559
00:33:09,000 --> 00:33:13,600
consumes the transaction ID for 
your half of the Redemption for 

560
00:33:13,600 --> 00:33:16,900
the smart contract and then they
coins get created on bitcoin to.

561
00:33:17,300 --> 00:33:20,100
So we're like you could 
potentially have a case in which

562
00:33:20,300 --> 00:33:24,300
there are is a chain that has no
tokens on it because it has no 

563
00:33:24,300 --> 00:33:27,300
accounts or they're all empty. 
And then another chain could 

564
00:33:27,300 --> 00:33:29,900
have all the tokens and it 
doesn't matter because each 

565
00:33:29,900 --> 00:33:32,700
chain maintains its own idea of 
state. 

566
00:33:32,700 --> 00:33:35,400
And this is how we pass 
information from chain to chain.

567
00:33:37,600 --> 00:33:39,800
If you've listened to previous 
episodes with Marley gray and 

568
00:33:39,800 --> 00:33:42,400
Matt koerner, you know, that 
Microsoft is committed to 

569
00:33:42,400 --> 00:33:44,900
providing enterprise-grade tools
and infrastructure for 

570
00:33:44,900 --> 00:33:47,700
blockchain developers. 
Well, the Azure blockchain 

571
00:33:47,700 --> 00:33:50,000
workbench is perfect for 
organizations building. 

572
00:33:50,000 --> 00:33:52,300
Consortium networks. 
Take the etherium proof of 

573
00:33:52,300 --> 00:33:54,900
authority template, for example,
it's ideal for permission. 

574
00:33:54,900 --> 00:33:56,900
Networks were consensus, 
participants, are known and 

575
00:33:56,900 --> 00:33:59,700
reputable. 
A theorem on Azure has on chain 

576
00:33:59,700 --> 00:34:02,000
Network governance, that 
leverages parodies extensible, 

577
00:34:02,000 --> 00:34:04,400
proof of authority. 
Client, each Consortium member 

578
00:34:04,400 --> 00:34:06,800
has the power to govern the 
network or delegate their 

579
00:34:06,800 --> 00:34:08,300
consensus. 
Disciplines to a trusted 

580
00:34:08,300 --> 00:34:11,500
operator and parodies. 
Webassembly support allows 

581
00:34:11,500 --> 00:34:14,100
developers to write smart 
contracts and for many languages

582
00:34:14,100 --> 00:34:18,500
like C C++ and rust as your 
blockchain workbench was created

583
00:34:18,500 --> 00:34:21,100
on the same principles that 
drive all Production Services in

584
00:34:21,100 --> 00:34:22,699
Azure. 
So, you know you're relying on 

585
00:34:22,707 --> 00:34:26,199
secure redundant infrastructure,
that can scale and we built in 

586
00:34:26,199 --> 00:34:28,300
services. 
Like authenticating apis off 

587
00:34:28,300 --> 00:34:30,600
chain databases and secure Key 
Management Services. 

588
00:34:30,600 --> 00:34:33,000
You can scaffold your 
infrastructure in just a few 

589
00:34:33,000 --> 00:34:36,300
hours to learn more about Azure 
blockchain workbench and how 

590
00:34:36,300 --> 00:34:38,600
Microsoft is Dancing. 
Blockchain usability, and 

591
00:34:38,600 --> 00:34:42,400
Enterprise, check out, 
aka.ms/offweb the center and 

592
00:34:42,400 --> 00:34:45,100
start building today. 
We'd like to thank Microsoft 

593
00:34:45,100 --> 00:34:48,699
Azure for their support of 
epicenter on the topic. 

594
00:34:48,699 --> 00:34:52,900
You mentioned earlier, that as a
minor, you should be mining on 

595
00:34:52,900 --> 00:34:54,600
many chains. 
So if we stay on this example, 

596
00:34:54,600 --> 00:34:56,900
Bitcoin want to be going to, we 
extend that example to now 

597
00:34:56,900 --> 00:34:58,600
Bitcoin. 
And so presumably, you know, 

598
00:34:58,600 --> 00:35:02,300
there was hundreds of chains, 
perhaps and as a minor, I'm 

599
00:35:02,600 --> 00:35:05,300
Distributing. 
My hashing power amongst all 

600
00:35:05,300 --> 00:35:11,400
these chains. 
Not create a bandwidth issue and

601
00:35:11,400 --> 00:35:14,100
because I mean scalability and 
blockchain is fundamentally a 

602
00:35:14,100 --> 00:35:17,800
networking issue. 
I mean, it's an issue of having 

603
00:35:17,800 --> 00:35:20,600
sufficient bandwidth to 
propagate blocks quickly enough,

604
00:35:20,600 --> 00:35:22,900
so that everybody can come to 
consensus around. 

605
00:35:23,600 --> 00:35:24,900
What is actual state of the 
chain? 

606
00:35:25,300 --> 00:35:28,800
So, if I'm a minor and I'm 
mining on 100 blocks are 100 

607
00:35:28,900 --> 00:35:34,500
chains, rather that not only 
consumes a lot of bandwidth on a

608
00:35:34,508 --> 00:35:37,500
network, but it creates 
congestion even sort of like at 

609
00:35:37,500 --> 00:35:42,600
the entry point of my like, my 
router like in my, or the switch

610
00:35:42,600 --> 00:35:45,200
in my, in my networking 
facility. 

611
00:35:46,500 --> 00:35:51,300
How do you how does get in a 
sari chain web addresses? 

612
00:35:52,200 --> 00:35:56,000
Sure. 
So first, we make the assumption

613
00:35:56,000 --> 00:36:02,500
that large mining pools exist 
which I think that it the crypto

614
00:36:02,500 --> 00:36:07,200
Anarchist, who wants to believe 
that all Bitcoin is mine. 

615
00:36:07,300 --> 00:36:10,900
To buy like individual hackers 
with a GPU or something in their

616
00:36:10,900 --> 00:36:16,100
closet is like it's a fallacy. 
We need to accept the fact that 

617
00:36:16,700 --> 00:36:21,400
like, Bitcoin large, mining 
pools exist and they are going 

618
00:36:21,400 --> 00:36:24,200
to mine, the whole web because 
they can. 

619
00:36:24,700 --> 00:36:28,600
And there are essentially going 
to perform the function of 

620
00:36:29,700 --> 00:36:34,800
coordinating the header stream 
and the header stream is just 

621
00:36:34,800 --> 00:36:36,700
these messages that go across 
the network. 

622
00:36:36,700 --> 00:36:40,900
That's say, like, hey, I found a
block and here's the hash of 

623
00:36:40,900 --> 00:36:43,000
that block. 
And the header stream itself is 

624
00:36:43,000 --> 00:36:46,500
very lightweight because it's 
very small hashes there that are

625
00:36:46,500 --> 00:36:49,700
being passed to each other. 
So, if you wanted to Only Mine 

626
00:36:49,700 --> 00:36:53,400
one chain, you could subscribe 
to the header stream. 

627
00:36:53,800 --> 00:36:58,900
And yes, you'd have to make an 
assumption that the hashes that 

628
00:36:58,900 --> 00:37:02,300
you receiving are valid. 
But given the fact that we 

629
00:37:02,300 --> 00:37:04,900
assume that there are large 
mining pools and that people 

630
00:37:04,900 --> 00:37:08,800
will be penalized by people not 
believing If they ever put out a

631
00:37:09,000 --> 00:37:13,100
passion, that's not valid. 
Then, you know, we believe that 

632
00:37:13,100 --> 00:37:17,000
people will be able to Only Mine
a small subset of the network, 

633
00:37:17,000 --> 00:37:19,500
if that's all that they can 
handle in terms of bandwidth. 

634
00:37:19,800 --> 00:37:23,300
But that most of the mining will
be taken up by people that are 

635
00:37:23,300 --> 00:37:26,000
actually capable of handling the
bandwidth. 

636
00:37:27,400 --> 00:37:31,800
I don't know that that actually 
solves the networking problem at

637
00:37:31,800 --> 00:37:35,400
the network level, I mean, so 
okay potentially small. 

638
00:37:36,300 --> 00:37:39,100
Mining operations or individual 
miners might only might want 

639
00:37:39,100 --> 00:37:43,800
chain, but the broader issue 
that the entire network needs to

640
00:37:43,800 --> 00:37:49,800
be able to visualize the state. 
And if those smaller miners or I

641
00:37:49,808 --> 00:37:52,900
don't care miners like in remote
areas that don't have the 

642
00:37:52,900 --> 00:37:55,300
bandwidth can access the 
information. 

643
00:37:55,300 --> 00:37:57,800
So how do we secure the In that 
sense. 

644
00:37:58,300 --> 00:38:00,000
What do you mean the 
information? 

645
00:38:00,100 --> 00:38:03,100
Because they should be able to 
consume the header stream. 

646
00:38:03,300 --> 00:38:06,500
The header stream is just small 
hashes being sent around to each

647
00:38:06,500 --> 00:38:08,500
other. 
And they're only the number of 

648
00:38:08,500 --> 00:38:13,000
messages going from chain to 
chain that are the degree number

649
00:38:13,000 --> 00:38:17,400
of messages in the network. 
So it for the Peterson graph, 

650
00:38:17,400 --> 00:38:21,500
for example, which is 10 chains,
then that's there are for every 

651
00:38:21,500 --> 00:38:24,100
node that sends two additional 
messages. 

652
00:38:24,500 --> 00:38:29,500
So it's not I guess I don't 
really understand your question.

653
00:38:29,500 --> 00:38:33,700
Yeah I think the Russians 
question is so today we have 

654
00:38:33,700 --> 00:38:37,600
Bitcoin and in today Bitcoin 
block size is 1 MB. 

655
00:38:38,200 --> 00:38:42,100
Right. 
So every 10 minutes, if I'm a 

656
00:38:42,100 --> 00:38:50,400
Bitcoin miner I must Get one and
be worth of data very quickly 

657
00:38:50,800 --> 00:38:54,000
and build on top of it, right? 
So when somebody else creates a 

658
00:38:54,008 --> 00:38:56,200
block, let's say, Monica, you 
create a block in New York. 

659
00:38:56,700 --> 00:39:00,600
I must get that 1. 
MB of data very quickly because 

660
00:39:00,600 --> 00:39:06,600
I want to build on top of it. 
Now, now I can scale Bitcoin by 

661
00:39:07,300 --> 00:39:09,700
increasing the block size. 
So if you increase let's say the

662
00:39:09,700 --> 00:39:12,000
block size from one end, be to 
100 MB. 

663
00:39:12,500 --> 00:39:16,800
Now I need to get this 100 MB of
data very quickly, right? 

664
00:39:16,800 --> 00:39:21,100
In order to be competitive. 
Now, what Sebastian is saying is

665
00:39:21,100 --> 00:39:25,300
now, if certain, additionally, 
traditionally, when we talk 

666
00:39:25,300 --> 00:39:31,600
about scaling, we we want to 
reduce this requirement of 100mb

667
00:39:32,200 --> 00:39:37,600
to something much lower, right? 
So so right now, like let's say 

668
00:39:37,700 --> 00:39:41,300
Bitcoin had a block size of 100 
MB and you wanted to scale it 

669
00:39:42,400 --> 00:39:46,300
using some other mechanism. 
What you would try to do is you 

670
00:39:46,300 --> 00:39:50,200
would want to reduce the need 
for getting 100 MB of data to 

671
00:39:50,200 --> 00:39:56,400
something lower like 10mb. but 
in kadena, it feels like because

672
00:39:56,400 --> 00:39:59,900
if I'm a kadena miner and let's 
have mining Bitcoin one and 

673
00:39:59,900 --> 00:40:05,800
Bitcoin to I would need to get 
100 MB for Bitcoin one and I 

674
00:40:05,800 --> 00:40:08,700
would need to get 100 MB for 
Bitcoins and you don't need the 

675
00:40:08,700 --> 00:40:11,200
100mb for Bitcoin to all you 
need. 

676
00:40:11,200 --> 00:40:14,700
Is the like one bite or like 64?
Bytes. 

677
00:40:14,900 --> 00:40:19,100
No, but or if I would like the 
other assumption is each mining 

678
00:40:19,100 --> 00:40:23,100
pool is mining all of the 
networks. 

679
00:40:23,400 --> 00:40:26,300
So if they're mining Bitcoin one
as one is, as well as Bitcoin 

680
00:40:26,300 --> 00:40:29,300
to. 
And if I need to actually mind 

681
00:40:29,300 --> 00:40:32,300
both those networks, I need to 
get data from both chains. 

682
00:40:33,100 --> 00:40:38,800
So it doesn't solve scaling 
because All it all it is 

683
00:40:38,800 --> 00:40:41,400
equivalent to is, is an increase
in Block size? 

684
00:40:41,800 --> 00:40:45,200
Like I could increase Bitcoins 
block size from 100, MB to 200 

685
00:40:45,200 --> 00:40:49,700
MB or I could split it into two 
networks Bitcoin and Bitcoin to 

686
00:40:49,707 --> 00:40:54,300
100 MB each in both cases. 
I need to get that 200 MB of 

687
00:40:54,300 --> 00:40:58,300
data in order to actually run my
mining operation. 

688
00:41:00,100 --> 00:41:04,400
Yes, I agree with the idea that 
if you wanted to mine, the 

689
00:41:04,400 --> 00:41:07,000
entire network, you would still 
need to be able to have all the 

690
00:41:07,000 --> 00:41:12,900
data, but that's the same 
problem that we have right now. 

691
00:41:13,100 --> 00:41:16,800
In terms of people, just wanting
to be able to pump out, more 

692
00:41:17,000 --> 00:41:19,500
Bitcoin, blocks or make bigger 
Bitcoin blocks. 

693
00:41:19,900 --> 00:41:23,700
But this is you if you don't you
don't have to mind the entire 

694
00:41:23,700 --> 00:41:26,600
network, you can mine a subset 
of the network which means you 

695
00:41:26,600 --> 00:41:28,400
don't have to consume all of the
data. 

696
00:41:28,700 --> 00:41:33,300
You could mine only one chain 
and then just listen to the 

697
00:41:33,300 --> 00:41:36,800
header stream for everybody 
else's successes in which case 

698
00:41:36,800 --> 00:41:39,300
you would only need to receive 
if we're using 200 as our 

699
00:41:39,308 --> 00:41:43,300
example, and you would only need
100 Meg's from the previous 

700
00:41:43,300 --> 00:41:46,300
block and all the others. 
You could just listen in for. 

701
00:41:46,400 --> 00:41:51,000
So if bandwidth is your problem,
then you can only subscribe to a

702
00:41:51,008 --> 00:41:52,800
subset. 
Yes. 

703
00:41:52,800 --> 00:41:55,600
I actually like that. 
That makes total sense, right? 

704
00:41:55,600 --> 00:42:02,000
So so the trade-off is If I as a
minor need to mine all the 

705
00:42:02,000 --> 00:42:06,600
chains, then I need to get the 
data of all the chains and if 

706
00:42:06,600 --> 00:42:11,300
all miners are Force to get the 
data of all the chains, kadena 

707
00:42:11,300 --> 00:42:13,900
boils down to like a single 
block chain with an extremely 

708
00:42:13,900 --> 00:42:17,200
large block size, right? 
So that's not scalable. 

709
00:42:17,800 --> 00:42:24,000
So, the point at which Cadena 
would be scalable is if I if me 

710
00:42:24,000 --> 00:42:28,000
as a minor is given the choice 
of needing to mine. 

711
00:42:28,000 --> 00:42:30,400
Only one. 
And forgetting about the other 

712
00:42:30,400 --> 00:42:33,600
chain and then I need to listen 
to only one chain. 

713
00:42:33,600 --> 00:42:37,300
Listen to a smaller data stream 
and other minors can work on 

714
00:42:37,300 --> 00:42:41,200
that other chain. 
And then, there is scalability. 

715
00:42:42,600 --> 00:42:44,900
So, I actually agree that. 
That's the that's the 

716
00:42:44,900 --> 00:42:47,700
fundamental trade-off that in 
order for a system like a Dana 

717
00:42:47,700 --> 00:42:51,900
to actually scale really scale, 
you would need to concentrate 

718
00:42:51,900 --> 00:42:58,800
minors into certain chains like,
hey, miners, 3539 and 38. 

719
00:42:59,000 --> 00:43:05,500
Focus on blockchain number 23, 
U5 - focus on some other chain 

720
00:43:06,000 --> 00:43:07,800
and so on. 
Would you agree with that? 

721
00:43:09,300 --> 00:43:12,400
Yes. 
And I think that it seems like I

722
00:43:12,400 --> 00:43:16,300
should build a timing and 
bandwidth consideration into our

723
00:43:16,300 --> 00:43:18,800
mining model right now, because 
we're doing a bunch of markup 

724
00:43:18,800 --> 00:43:22,900
simulations on like x, what 
people's expected value is on 

725
00:43:23,000 --> 00:43:27,500
mining different chains and that
right now at the moment, we have

726
00:43:27,500 --> 00:43:30,700
it where the penalty for 
switching between mining 

727
00:43:30,700 --> 00:43:34,000
different chains is very low, 
which causes our model to 

728
00:43:34,000 --> 00:43:37,200
suggest that people are going to
basically hop to mining. 

729
00:43:37,200 --> 00:43:40,800
Whichever chain, they think The 
last, the least attention last 

730
00:43:40,800 --> 00:43:46,300
round and with that as I could 
just go in and dial in different

731
00:43:46,300 --> 00:43:49,900
assumptions into and right now I
don't think we've necessarily 

732
00:43:49,900 --> 00:43:52,300
considered bandwidth as being a 
huge lever. 

733
00:43:52,300 --> 00:43:55,800
But if you think that that's 
interesting, like totally think 

734
00:43:55,800 --> 00:43:57,200
that that's a worthwhile 
suggestion. 

735
00:43:58,700 --> 00:44:04,200
From my perspective, I think 
bank with is but on a mantle I'm

736
00:44:04,200 --> 00:44:10,600
barrier to descale ability at 
the lowest level me any any 

737
00:44:10,600 --> 00:44:15,100
solution that we try to build on
top of the existing blocking him

738
00:44:15,100 --> 00:44:20,100
to create more efficient 
watching systems whether be 

739
00:44:20,100 --> 00:44:22,900
proof of worker proof of stake. 
What we're trying to do is 

740
00:44:22,900 --> 00:44:26,700
essentially is minimize the 
amount of bandwidth that needs 

741
00:44:26,700 --> 00:44:30,500
to go from. 
Validators that maintain the 

742
00:44:30,500 --> 00:44:34,000
chain for me. 
It's sort of a sort of a 

743
00:44:34,100 --> 00:44:37,700
fundamental thing in in this 
scalability discussion in a 

744
00:44:37,700 --> 00:44:41,100
broader sense that most people 
are not addressing. 

745
00:44:41,100 --> 00:44:45,200
So we've had some, we had a 
project on recently blocks 

746
00:44:45,200 --> 00:44:49,600
route, sort of building a 
Content distribution Network for

747
00:44:50,000 --> 00:44:53,400
her blockchains that addresses. 
This issue at the fundamental 

748
00:44:53,900 --> 00:45:00,000
Network level, But I haven't, I 
haven't seen any other projects 

749
00:45:00,400 --> 00:45:03,800
at least the ones we had on that
sort of look at scaling from 

750
00:45:03,800 --> 00:45:07,000
this perspective. 
But you written a white paper 

751
00:45:07,400 --> 00:45:12,800
which describes the different 
attack vectors possible with 

752
00:45:12,800 --> 00:45:15,700
chain web and the ways you may 
negate them, could you run us 

753
00:45:15,700 --> 00:45:20,400
through some of these and how 
your medicating those detectors?

754
00:45:22,000 --> 00:45:24,600
Sure. 
So, the first one that we 

755
00:45:24,600 --> 00:45:30,500
started looking at, because it's
like the fundamental Like the 

756
00:45:30,500 --> 00:45:32,800
first one described in the 
Bitcoin white paper and all this

757
00:45:32,800 --> 00:45:37,200
is about 51% attacks and how 
like basically everybody 

758
00:45:37,200 --> 00:45:40,600
screwed, if somebody gets 51% 
control of your network and fine

759
00:45:41,000 --> 00:45:46,600
but if they don't have 51% but 
they have less percentage of 

760
00:45:46,600 --> 00:45:51,100
your network. 
How does that mitigate the 

761
00:45:51,100 --> 00:45:53,800
potential likelihood of somebody
being able to attack your chain?

762
00:45:54,000 --> 00:45:58,500
And so when it comes to double 
spend attacks because of these 

763
00:45:59,000 --> 00:46:03,900
shared, References between 
chains where like Bitcoin to has

764
00:46:03,900 --> 00:46:07,300
the hash of Bitcoin one. 
And it not only does it quickly 

765
00:46:07,300 --> 00:46:09,300
force you to resolve any 
potential Forks. 

766
00:46:09,300 --> 00:46:15,700
But also, as block, depth 
increases and the block that's 

767
00:46:15,700 --> 00:46:21,000
being attacked, gets further in 
the buried, not only by blocks 

768
00:46:21,000 --> 00:46:24,300
on its own chain, but by Pierre 
chains, that reference. 

769
00:46:24,300 --> 00:46:27,900
It also getting buried, you 
start having to not only replace

770
00:46:27,900 --> 00:46:31,700
at any. 
Even chain, but you also have to

771
00:46:31,700 --> 00:46:35,000
replace any peer chains that 
happened to reference it. 

772
00:46:35,000 --> 00:46:38,200
So, when we started looking into
strategies, that would require 

773
00:46:38,600 --> 00:46:42,800
some that somebody would use in 
order to replace a block and do 

774
00:46:42,800 --> 00:46:47,100
a double spend attack, they have
to honestly, mine the network in

775
00:46:47,100 --> 00:46:52,900
order to generate Pier blocks 
like more than 60% of their, 

776
00:46:52,900 --> 00:46:55,600
hash power actually has to go to
honestly mine the network in 

777
00:46:55,600 --> 00:46:57,200
order to try to attack the 
network. 

778
00:46:57,700 --> 00:47:02,000
And they just, they Potentially 
fall behind in terms of that 

779
00:47:02,000 --> 00:47:04,800
attack. 
That, that's not really a 

780
00:47:04,800 --> 00:47:07,800
fusible situation. 
That was the first one that we 

781
00:47:07,800 --> 00:47:10,900
looked at this is the whole, 
like, the block rope originally 

782
00:47:10,900 --> 00:47:14,300
produce. 
This chains, sharing each 

783
00:47:14,300 --> 00:47:17,600
other's hashes as a security 
measure, that's how that really 

784
00:47:17,600 --> 00:47:20,000
gets exposed. 
That's how we come up with the 

785
00:47:20,000 --> 00:47:24,200
term, we use the term Merkel 
cone because it's like, Merkle 

786
00:47:24,200 --> 00:47:26,700
tree, but it has an additional 
dimension on top of it. 

787
00:47:26,700 --> 00:47:31,300
So it's because of the way that 
that the Merkel cone propagates 

788
00:47:31,300 --> 00:47:33,500
exponentially across all these 
different peer chains. 

789
00:47:34,800 --> 00:47:36,600
Double spend attacks are very 
hard. 

790
00:47:38,100 --> 00:47:40,300
Okay. 
That's that's sounds like an 

791
00:47:40,300 --> 00:47:44,300
interesting proposition. 
So like in let's say like you 

792
00:47:44,300 --> 00:47:48,800
have like a kadena network and 
you have 10 chains in this 

793
00:47:48,800 --> 00:47:54,400
container Network, right? 
And you know like the total 

794
00:47:54,400 --> 00:47:58,600
mining power in, this whole 
network is X like X that I 

795
00:47:58,600 --> 00:48:03,300
hashes or x x, whatever unit and
you can think of it like 

796
00:48:03,300 --> 00:48:09,600
thousand Tara hashes, some large
number, And then you have kadena

797
00:48:09,600 --> 00:48:12,600
chain 1, K 1, you have good 
energy into k 2 and you have 

798
00:48:12,600 --> 00:48:14,900
approval screen, a chain 10 K, 
10. 

799
00:48:15,900 --> 00:48:21,300
So that the total hashing power 
is thousand data hashes, is it 

800
00:48:21,300 --> 00:48:24,800
the case that kadena one gets 
100? 

801
00:48:24,900 --> 00:48:29,500
Tara, hash kadena to gets 200, 
Tara hash and these thousand are

802
00:48:29,500 --> 00:48:33,700
distributed equally between the 
chains or how does mining power 

803
00:48:33,700 --> 00:48:35,700
get distributed across these 
chains? 

804
00:48:37,600 --> 00:48:42,300
So, it's the, it's the miners 
Choice, which chains to mine. 

805
00:48:42,300 --> 00:48:45,100
And this is part of what the 
simulation project that we've 

806
00:48:45,100 --> 00:48:49,000
been working on, in terms of 
building the, the model for the 

807
00:48:49,000 --> 00:48:51,500
network graph, and then building
the minor graph and then having 

808
00:48:51,500 --> 00:48:56,600
them run through simulations on 
how they would mind that our, we

809
00:48:56,600 --> 00:49:00,400
posit obviously, we haven't 
built it yet, so all of this is 

810
00:49:00,400 --> 00:49:03,900
still simulation land. 
But that the network when 

811
00:49:04,500 --> 00:49:07,900
actually stabilizes to a point 
where they're all Be equal 

812
00:49:08,200 --> 00:49:12,000
because any chain that you think
has less hash power becomes an 

813
00:49:12,000 --> 00:49:15,100
attractive Target. 
So you want if your chain, if 

814
00:49:15,100 --> 00:49:17,200
you think the people a lot of 
people are mining a chain that 

815
00:49:17,200 --> 00:49:19,400
you're on, then you're competing
too much. 

816
00:49:19,400 --> 00:49:22,600
And you want to hop to a chain 
where the collective hashing 

817
00:49:22,600 --> 00:49:26,300
power is lower which actually 
causes the entire network to, to

818
00:49:26,300 --> 00:49:30,000
stabilize their. 
Also the fact that you have to 

819
00:49:30,000 --> 00:49:34,200
wait for that the blocks to be 
finished on your peer chains 

820
00:49:34,200 --> 00:49:37,200
before you can include their 
proofs in your header. 

821
00:49:37,300 --> 00:49:40,600
It serves to it's sort of like 
you've tied them all together in

822
00:49:40,600 --> 00:49:43,300
this three-legged race where 
they can't get too far ahead. 

823
00:49:43,400 --> 00:49:47,700
You can only get diameter number
of blocks ahead of the network 

824
00:49:47,700 --> 00:49:52,000
as a whole, which means that any
change can only fall diameter 

825
00:49:52,000 --> 00:49:54,200
number of blocks behind before 
it starts to slow. 

826
00:49:54,200 --> 00:49:57,900
Everybody else down, which then 
causes people to dog pile on to 

827
00:49:57,900 --> 00:49:59,300
the chain, that's holding them 
back. 

828
00:49:59,600 --> 00:50:02,400
So this is the, like, the 
balancing Network. 

829
00:50:02,400 --> 00:50:07,500
We haven't, we've called it 
given this event horizon of It's

830
00:50:07,500 --> 00:50:11,300
various names are lead chairman 
of engineer calls it. 

831
00:50:11,300 --> 00:50:14,500
The cut set, which I think is 
sort of a weird term. 

832
00:50:14,700 --> 00:50:17,400
I was calling it the meniscus 
for a while, nobody like that 

833
00:50:17,400 --> 00:50:19,200
one. 
Nobody liked meniscus. 

834
00:50:20,000 --> 00:50:23,500
So, I've I'm going with Event 
Horizon for now, which is the, 

835
00:50:23,508 --> 00:50:26,600
like, the latest block for all 
of the chains and where they 

836
00:50:26,600 --> 00:50:29,200
are. 
And this is the idea that the 

837
00:50:29,200 --> 00:50:33,300
hashing power will pool to the 
lowest chain because that's the 

838
00:50:33,300 --> 00:50:37,500
one that is the most attractive.
So that's an interesting idea. 

839
00:50:37,500 --> 00:50:42,600
So the basic idea is that you 
somehow want to have these 10 

840
00:50:42,600 --> 00:50:45,700
chains and you somehow want 
these chains to progress at 

841
00:50:45,700 --> 00:50:49,700
similar speeds. 
So if a blocks is created here, 

842
00:50:49,700 --> 00:50:51,900
you want the other change to 
create blocks. 

843
00:50:53,000 --> 00:50:56,200
And so what you're effectively 
doing is, you're somehow 

844
00:50:56,200 --> 00:51:00,500
incentivizing the minors to 
switch to the slowest chain so 

845
00:51:00,500 --> 00:51:04,700
that the whole system can make 
progress and when the miner 

846
00:51:04,700 --> 00:51:07,900
switch to the slowest, In 
automatically the highest power,

847
00:51:07,900 --> 00:51:10,900
distributes equally. 
So right? 

848
00:51:11,100 --> 00:51:15,600
So you start with let's say 
1,000 Tara hashes, and you end 

849
00:51:15,600 --> 00:51:18,900
up with a system where there is 
like 100 Tara ashes equally 

850
00:51:18,900 --> 00:51:23,000
across all the chains, right? 
So it won't, it won't be exactly

851
00:51:23,000 --> 00:51:26,500
equal but like some might have 
80 some might have 120, this is 

852
00:51:26,500 --> 00:51:31,300
easier that but like it you will
aim to get like somewhat equal 

853
00:51:31,300 --> 00:51:35,800
distribution. 
Now, the question becomes that 

854
00:51:36,700 --> 00:51:41,300
suppose, now I am a miner on 
chain five, right. 

855
00:51:41,900 --> 00:51:45,200
So I'm a miner on chain five and
I'm a large minor. 

856
00:51:47,000 --> 00:51:52,100
And now chain 5 has 80 80 like a
tee, Tara hashes. 

857
00:51:52,100 --> 00:51:56,300
Right now, I'm a large minor and
my mining capacity right now, 

858
00:51:56,300 --> 00:52:00,400
I'm not mining to Dana, but my 
mining capacity is 100 Tara 

859
00:52:00,400 --> 00:52:05,200
hashes. 
I can 51% attack chain five 

860
00:52:05,200 --> 00:52:11,600
because those guys are 80 and I 
have 100 pointed waiting to go. 

861
00:52:13,000 --> 00:52:19,000
So what I do here is I'll say 
okay, let me put those 100 on 

862
00:52:19,100 --> 00:52:23,300
just chain 5 and let me just 
create one in valid transaction 

863
00:52:23,500 --> 00:52:27,800
that creates. 
I don't know a billion kadena 

864
00:52:28,500 --> 00:52:32,300
and just gives it to me. 
And I basically create that 

865
00:52:32,300 --> 00:52:38,000
block very quickly on chain 5, 
and because my block appears 

866
00:52:38,000 --> 00:52:41,300
quickly because I have more hash
power than the others that 

867
00:52:41,300 --> 00:52:46,000
invalid block propagates to 
change seven eight, two and one 

868
00:52:46,200 --> 00:52:49,600
and they include my invalid 
block when they create the next 

869
00:52:49,600 --> 00:52:51,700
block. 
And so my block becomes 

870
00:52:51,700 --> 00:52:55,000
canonical. 
Do you think this is a problem? 

871
00:52:56,700 --> 00:53:02,700
So the way that that would 
become resolved in chain web is 

872
00:53:03,100 --> 00:53:07,100
like, you're not the only minor 
on chain five. 

873
00:53:07,600 --> 00:53:12,100
Somebody else will attempt to 
validate your block as a way of 

874
00:53:12,100 --> 00:53:16,400
putting the next block on top of
chain 5 and see that your block 

875
00:53:16,400 --> 00:53:20,400
isn't actually valid. 
And which case they will suggest

876
00:53:20,400 --> 00:53:25,200
this as an alternative. 
And since people are mining like

877
00:53:25,200 --> 00:53:26,800
you Would mind a subset of 
chains. 

878
00:53:26,800 --> 00:53:29,700
Mine like chains five, six and 
seven, then somebody who's 

879
00:53:29,700 --> 00:53:34,500
minding five six and seven seas 
that like five is actually not a

880
00:53:34,508 --> 00:53:37,900
valid block and will suggest an 
alternative block and include 

881
00:53:37,900 --> 00:53:40,700
that in 6 and 7. 
And then whoever is most 

882
00:53:40,700 --> 00:53:43,500
remaining six and seven. 
Will see this other proposed 

883
00:53:43,500 --> 00:53:45,300
block 5 and that it's not 
included. 

884
00:53:45,300 --> 00:53:48,600
In this other proposed block 6, 
which will then cause them to 

885
00:53:48,600 --> 00:53:52,700
reject that block 5 and the 
block 6 that includes a 

886
00:53:52,700 --> 00:53:57,400
reference to the bad block 5. 
Like This idea that a bad block 

887
00:53:57,400 --> 00:54:01,100
would never be validated by 
another minor is like, I think 

888
00:54:01,100 --> 00:54:04,200
the core of why that doesn't 
necessarily work. 

889
00:54:05,400 --> 00:54:08,900
So what are you saying is now, 
you're going to use the other 

890
00:54:09,000 --> 00:54:11,100
chains as a Judiciary of Kinds, 
right? 

891
00:54:11,100 --> 00:54:13,700
So I'm the, I'm the big bag, bad
attacker. 

892
00:54:14,200 --> 00:54:18,300
And let's say, Sebastian 
represent the honest miners of 

893
00:54:18,300 --> 00:54:22,800
chain 5, I'm the attacker of 
chain 5 And so I was passed 

894
00:54:22,800 --> 00:54:24,200
because I have more hashing 
power. 

895
00:54:24,200 --> 00:54:26,700
I produce the black quickly, it 
broadcast quickly. 

896
00:54:27,000 --> 00:54:29,700
Now you saying like, oh 
Sebastian but will also create 

897
00:54:29,800 --> 00:54:33,600
the competing block and try to 
broadcast it right now. 

898
00:54:33,700 --> 00:54:38,800
Now the whole network chains, 
one two ten must decide his 

899
00:54:38,800 --> 00:54:41,800
methods block canonical or 
Sebastian's block canonical. 

900
00:54:42,800 --> 00:54:46,500
So, the whole network in some 
senses needs to become a 

901
00:54:46,508 --> 00:54:48,300
Judiciary. 
Yes. 

902
00:54:49,300 --> 00:54:54,600
But they can be a judiciary. 
Only if they know if only if 

903
00:54:54,600 --> 00:54:57,200
they store the whole Block Chain
of chain five. 

904
00:54:57,800 --> 00:55:01,600
But only if they're mining a 
smaller subset of any connected 

905
00:55:01,600 --> 00:55:06,600
subset of the network like five,
six and seven or three, four and

906
00:55:06,600 --> 00:55:10,200
five or so. 
Because so let's say I propagate

907
00:55:10,200 --> 00:55:14,900
my hash tube from 128 blocks 
change, 1 to it here. 

908
00:55:14,900 --> 00:55:18,900
My thing and Sebastian things 
Sebastian's honest, thing goes 

909
00:55:18,900 --> 00:55:23,500
only to 9 and 10. 
I win well but then it'll go to 

910
00:55:23,500 --> 00:55:27,900
9 and 10 and then 9 will have to
reconcile with eight and then 

911
00:55:27,900 --> 00:55:30,900
you'll have to go and you'll 
pick which one of these either 9

912
00:55:30,900 --> 00:55:34,200
or 8. 
So this is because of the way 

913
00:55:34,200 --> 00:55:38,200
that it's webbed together you 
have to make calls very fast. 

914
00:55:38,600 --> 00:55:43,400
And yes we assume that people 
are mining more than one chain 

915
00:55:43,400 --> 00:55:45,500
which allows them to cross check
each other. 

916
00:55:46,700 --> 00:55:50,500
If everybody only mind one chain
then we would have a problem. 

917
00:55:50,700 --> 00:55:54,000
But because it's designed for 
people to hop between chains in 

918
00:55:54,000 --> 00:55:58,000
mind more than one chain, it 
forces them to reconcile with 

919
00:55:58,000 --> 00:56:01,000
each other. 
I mean, let's let's move on to 

920
00:56:01,000 --> 00:56:04,700
some other topic, but I feel 
like the fundamental issue with 

921
00:56:04,700 --> 00:56:10,000
Cadena is is exactly this. 
It is, it is that in order for 

922
00:56:10,000 --> 00:56:16,900
reconciliation to work, you 
start to need bigger and bigger 

923
00:56:16,900 --> 00:56:20,000
jewelries and ultimately, you 
will boil down to the system 

924
00:56:20,000 --> 00:56:22,700
where everybody needs to mine 
Every Chain. 

925
00:56:23,600 --> 00:56:28,800
Which means Everybody needs to 
get the data from Every Chain, 

926
00:56:29,800 --> 00:56:33,100
which means actually it will not
end up solving scalability. 

927
00:56:34,600 --> 00:56:37,400
I don't think that everybody 
needs to mine Every Chain but 

928
00:56:37,600 --> 00:56:40,400
that's that's a fair critique. 
Yeah. 

929
00:56:40,800 --> 00:56:43,200
Okay, so let's move on to the 
next theme Sebastian. 

930
00:56:44,000 --> 00:56:46,900
So there was a, I wanted to come
back to this earlier in our 

931
00:56:46,900 --> 00:56:49,500
discussion but we sort of got 
sidetracked with these other 

932
00:56:49,500 --> 00:56:52,900
topics, but there is one passage
in the white paper that kind of 

933
00:56:52,900 --> 00:56:58,100
struck me and I wanted to maybe 
get you to perhaps, explain it 

934
00:56:58,400 --> 00:57:04,500
in your own words on page 2. 
There's a section where you A 

935
00:57:04,500 --> 00:57:06,100
proof of stake and proof of 
work. 

936
00:57:06,100 --> 00:57:10,000
And you argue that proof of 
stake. 

937
00:57:10,000 --> 00:57:14,000
Validators would be subject to 
money, transmitter regulation. 

938
00:57:14,000 --> 00:57:16,900
At least in the US as it reads 
here. 

939
00:57:17,700 --> 00:57:23,100
Can you expand on this logic and
What, what evidence you have to 

940
00:57:23,100 --> 00:57:26,300
support this? 
This claim that proof of stake. 

941
00:57:26,300 --> 00:57:29,300
Validators would likely be 
subject to money transmitter 

942
00:57:29,400 --> 00:57:31,500
regulations. 
Sure. 

943
00:57:31,600 --> 00:57:38,000
So this is the reason that we 
take this position is the idea 

944
00:57:38,000 --> 00:57:42,100
that right now. 
It's to it takes too long and 

945
00:57:42,100 --> 00:57:45,700
it's too hard to pass new laws 
to try to regulate blockchain. 

946
00:57:46,300 --> 00:57:50,900
And it's going to take a while 
in order to get new legislation 

947
00:57:50,900 --> 00:57:52,800
out there. 
Are especially in the United 

948
00:57:52,800 --> 00:57:55,000
States for these things, take 
forever and people debate about 

949
00:57:55,000 --> 00:57:59,100
them for a long time that trying
to pass new laws for black jeans

950
00:57:59,100 --> 00:58:03,700
going to take a while. 
So the only way that people are 

951
00:58:03,707 --> 00:58:06,300
going to try to regulate 
blockchain for at least, the 

952
00:58:06,308 --> 00:58:12,900
short-term is to try to apply 
existing legislation to block 

953
00:58:12,900 --> 00:58:16,000
chain. 
And the way that existing 

954
00:58:16,000 --> 00:58:20,400
legislation works for money 
transmitters is essentially, if 

955
00:58:20,400 --> 00:58:26,500
you put money up and we know who
you are and then you clear a 

956
00:58:26,508 --> 00:58:30,900
transaction that sends money to 
like Al-Qaeda or something. 

957
00:58:31,600 --> 00:58:35,700
That we should punish you 
because you are enabling money 

958
00:58:35,700 --> 00:58:37,600
Transmissions to somebody who's 
sketchy. 

959
00:58:38,700 --> 00:58:44,200
So when it comes to 
proof-of-work miners because 

960
00:58:44,200 --> 00:58:47,300
they don't necessarily have any 
stake in the network and we 

961
00:58:47,300 --> 00:58:51,600
don't necessarily know who they 
are, if they clear a transaction

962
00:58:51,600 --> 00:58:57,500
by mining that sends money to 
Al-Qaeda, then it's not their 

963
00:58:57,500 --> 00:59:01,500
fault because they weren't 
actually Being a money 

964
00:59:01,500 --> 00:59:03,900
transmitter because they didn't 
put any money up and we don't 

965
00:59:03,900 --> 00:59:06,500
know who they are, but when it 
comes to proof of stake, part of

966
00:59:06,500 --> 00:59:10,300
the argument about making proof 
of stake, work, is that you had 

967
00:59:10,300 --> 00:59:13,500
to prove your identity. 
And you had to stake some sort 

968
00:59:13,500 --> 00:59:17,500
of amount of money and because 
you put up that money and then 

969
00:59:17,500 --> 00:59:22,500
you sent money to Al Qaeda, you 
can fall under existing money 

970
00:59:22,500 --> 00:59:26,500
translator legislation, much 
easier than a minor who doesn't 

971
00:59:26,500 --> 00:59:29,400
look like what the law already 
considers to be a money 

972
00:59:29,400 --> 00:59:33,400
transmitter. 
So That's why this area it's 

973
00:59:33,400 --> 00:59:37,800
that the shape of staking looks 
a lot like, the shape, of 

974
00:59:38,000 --> 00:59:39,900
existing money transmitter 
legislation. 

975
00:59:40,100 --> 00:59:44,000
Whereas, the shape of mining 
doesn't look very similar to 

976
00:59:44,000 --> 00:59:47,100
existing money transmitter laws.
So that's why we're concerned 

977
00:59:47,200 --> 00:59:51,000
about validation in general. 
Like, all of these Services were

978
00:59:51,000 --> 00:59:54,700
a fund is trying to turn their 
fund into being a validator on 

979
00:59:54,700 --> 00:59:59,400
my chios or something where they
then clear transaction that then

980
00:59:59,400 --> 01:00:03,400
causes, I don't know. 
No, something illegal that they 

981
01:00:03,400 --> 01:00:08,300
could be held liable for it. 
I mean, so don't you think that 

982
01:00:09,100 --> 01:00:11,900
if this were the case, if 
Regulators really wanted to go 

983
01:00:11,900 --> 01:00:16,000
after, after make what I mean 
like and I mean Bitcoin in the 

984
01:00:16,000 --> 01:00:20,200
eyes of us Regulators, I would 
say I mean, to some extent, 

985
01:00:20,500 --> 01:00:25,300
perhaps not everyone, but the 
some extent Bitcoin is seen as a

986
01:00:25,308 --> 01:00:28,800
currency where a lot of it 
listed transactions occur, or at

987
01:00:28,800 --> 01:00:31,200
least have occurred in the past.
Don't you think The Regulators 

988
01:00:31,200 --> 01:00:33,600
could just go after money pools,
that it because we know we're 

989
01:00:33,600 --> 01:00:35,400
mining is concentrated where 
they could. 

990
01:00:35,500 --> 01:00:42,600
Could force mining pools to do 
kyc on the miners that access 

991
01:00:42,600 --> 01:00:46,400
the pool. 
I don't think that legally they 

992
01:00:46,400 --> 01:00:50,900
could make that case right now 
that mining is money 

993
01:00:50,900 --> 01:00:54,700
transmission but I do think that
they can make the case that 

994
01:00:54,700 --> 01:00:56,300
validating is money 
transmission. 

995
01:00:57,300 --> 01:01:01,000
That's that's our stance on it. 
That validating looks really 

996
01:01:01,000 --> 01:01:04,900
similar to existing legislation 
and Mining does not Mary I think

997
01:01:04,900 --> 01:01:05,900
you'll have a lot to say about 
this. 

998
01:01:06,100 --> 01:01:09,800
Yeah and this is because like 
the validator is identified with

999
01:01:09,800 --> 01:01:12,200
one public key, whereas a minor 
is not. 

1000
01:01:13,600 --> 01:01:16,000
Yeah. 
Or that a minor may not even be 

1001
01:01:16,000 --> 01:01:19,800
participating in the network 
necessarily. 

1002
01:01:19,800 --> 01:01:22,900
They could just be mining a 
block with their hashing power, 

1003
01:01:22,908 --> 01:01:24,800
and then immediately selling all
their Bitcoin. 

1004
01:01:24,800 --> 01:01:28,300
And they don't care about like 
staking money in the network. 

1005
01:01:28,300 --> 01:01:32,900
It's this, like, staking thing. 
That is the, that is the problem

1006
01:01:32,900 --> 01:01:35,400
because then it looks like being
having a money transmitter 

1007
01:01:35,400 --> 01:01:38,900
license is like you know you 
staked a bunch of cash in order 

1008
01:01:38,900 --> 01:01:41,300
for somebody to then be able to 
use you as a transmitter. 

1009
01:01:41,300 --> 01:01:44,200
That's what that shape starts. 
Click. 

1010
01:01:44,900 --> 01:01:48,200
Yeah, but I would say that that 
up, I mean the the obfuscation 

1011
01:01:48,300 --> 01:01:50,000
of identity that you have in 
Bitcoin. 

1012
01:01:50,000 --> 01:01:53,800
Mining can be you can wrap your,
you can replicate that 

1013
01:01:53,800 --> 01:01:55,700
obfuscation in proof of stake as
well. 

1014
01:01:55,700 --> 01:02:00,400
Be okay. 
You may have a key but I mean, 

1015
01:02:00,400 --> 01:02:04,400
you can pretty easily I would 
say change that that key for the

1016
01:02:04,400 --> 01:02:09,000
next round of validations and 
the the valve later that's 

1017
01:02:09,000 --> 01:02:12,600
taking steak from from Dell 
Gators doesn't necessarily have 

1018
01:02:12,600 --> 01:02:16,800
the identity on this road. 
Some sort of kyc, of the 

1019
01:02:16,808 --> 01:02:20,400
delegator themselves. 
So it's it's the probabilistic 

1020
01:02:20,400 --> 01:02:23,500
nature of proof of work that 
really gives it the 

1021
01:02:24,300 --> 01:02:28,200
slipperiness. 
Because as a Bitcoin miner there

1022
01:02:28,200 --> 01:02:34,300
is always a nonzero chance that 
the block that you confirmed 

1023
01:02:34,400 --> 01:02:36,800
might not actually be the real 
confirmation. 

1024
01:02:37,200 --> 01:02:41,800
It's this like invalidating, you
actually have to vote and then 

1025
01:02:41,800 --> 01:02:44,600
the vote is confirmed. 
And Have finality. 

1026
01:02:44,800 --> 01:02:48,200
It's the finality thing that 
really makes it a certified 

1027
01:02:48,200 --> 01:02:50,600
transition with your name on it 
in Bitcoin. 

1028
01:02:50,600 --> 01:02:53,800
It's like there's always some 
probability as to whether you 

1029
01:02:53,800 --> 01:02:56,600
did or did not confirm it and 
it's not really a Line in the 

1030
01:02:56,600 --> 01:03:01,500
Sand, it's this finality issue 
that actually makes it slippery.

1031
01:03:03,300 --> 01:03:04,800
That's a very interesting 
argument. 

1032
01:03:04,800 --> 01:03:08,700
I was saying like that's 
something and that's an entirely

1033
01:03:08,700 --> 01:03:10,900
new way of looking at it. 
So what you're saying is if I'm 

1034
01:03:10,908 --> 01:03:14,500
a miner in Bitcoin and I created
this block, it had a bunch of 

1035
01:03:14,500 --> 01:03:19,600
transactions and I published it.
I can argue that I published 

1036
01:03:19,600 --> 01:03:22,800
some data but I wasn't 100% 
sure. 

1037
01:03:22,800 --> 01:03:25,000
It was going to be included in 
the Bitcoin blockchain. 

1038
01:03:25,000 --> 01:03:30,000
It could have been orphaned. 
So I wasn't processing 

1039
01:03:30,000 --> 01:03:33,900
transactions, I was just 
publishing data and because I 

1040
01:03:33,908 --> 01:03:37,500
didn't have certainty that that 
data would go into Bitcoin, I'm 

1041
01:03:37,500 --> 01:03:45,500
not transmitting money. but in 
proof of stake, if I vote on a 

1042
01:03:45,500 --> 01:03:49,000
block and after my vote the 
block gets finalized. 

1043
01:03:49,000 --> 01:03:52,200
So let's say like the voting has
happened and I cast the 

1044
01:03:52,200 --> 01:03:54,600
determining vote that finalized 
that block. 

1045
01:03:55,200 --> 01:03:58,500
And what I'm essentially doing 
is in the process of voting. 

1046
01:03:58,500 --> 01:04:04,600
I am making the transactions 
final And that makes me more 

1047
01:04:04,600 --> 01:04:07,300
like a money transmitter because
while I was publishing that 

1048
01:04:07,300 --> 01:04:10,900
data, I knew that if I publish 
it, these transactions would be 

1049
01:04:11,100 --> 01:04:12,600
considered final. 
Yeah. 

1050
01:04:14,000 --> 01:04:17,600
That's super interesting II. 
Don't know if The Regulators are

1051
01:04:17,600 --> 01:04:19,800
going to look at it like this or
not, who knows? 

1052
01:04:20,300 --> 01:04:22,900
I mean that's are interpreted. 
We just think that proof of work

1053
01:04:22,900 --> 01:04:27,000
is safer because it has this 
other like dimensional element 

1054
01:04:27,000 --> 01:04:29,700
to it and I really don't want to
go to jail. 

1055
01:04:31,100 --> 01:04:37,200
I'm sure like the proof of stake
designers, so you know, like, In

1056
01:04:37,200 --> 01:04:39,700
Allegan Cosmos. 
So I'm actually building a 

1057
01:04:39,700 --> 01:04:43,200
cosmos validator. 
So this is a topic that's really

1058
01:04:43,200 --> 01:04:46,800
close to my heart in Cosmos. 
Yes. 

1059
01:04:46,800 --> 01:04:51,100
Like the validator, it could be 
doing things that are like 

1060
01:04:51,100 --> 01:04:53,900
castingwords. 
It's like you know or like you 

1061
01:04:53,900 --> 01:04:57,900
know in Cosmo 66% of the network
has to cast a cast. 

1062
01:04:57,900 --> 01:05:01,200
A yes, vote for the block to go 
in the chain and be final. 

1063
01:05:01,700 --> 01:05:06,500
So let's say, you know, like 65%
has done and then My validator 

1064
01:05:06,500 --> 01:05:11,900
costs that decisive vote that 
switches it over to 66% and then

1065
01:05:11,900 --> 01:05:17,800
creates a new block that takes 
that vote as final then maybe 

1066
01:05:17,800 --> 01:05:19,500
they maybe they could be this 
element that. 

1067
01:05:19,500 --> 01:05:22,600
Yes, I did put the deciding vote
in there. 

1068
01:05:22,600 --> 01:05:25,700
The validated it put the 
deciding vote in there, but I 

1069
01:05:25,707 --> 01:05:29,900
think if you look at something 
like this a source, that 

1070
01:05:29,900 --> 01:05:35,300
argument would be quite vka 
Source because in tells us even 

1071
01:05:35,300 --> 01:05:40,200
if you create a block that block
is not final until like 10 or 20

1072
01:05:40,200 --> 01:05:44,300
blocks are built on top of your 
block, it's like Bitcoin so 

1073
01:05:44,300 --> 01:05:48,000
Cosmos is not like Bitcoin. 
The block is final and you don't

1074
01:05:48,000 --> 01:05:51,400
need to have more blocks on top 
of it to be final but in tells 

1075
01:05:51,400 --> 01:05:54,100
us it's like like Bitcoin where 
you need 10 things to come on 

1076
01:05:54,100 --> 01:05:56,400
top of yours before it gets 
considered final. 

1077
01:05:56,900 --> 01:06:00,700
So if that's the argument then 
there's us Baker is fine but a 

1078
01:06:00,700 --> 01:06:03,500
cosmos validator may not be so 
that that will be quite 

1079
01:06:03,500 --> 01:06:07,500
interesting. 
I actually love Cosmos. 

1080
01:06:07,500 --> 01:06:10,300
I think Cosmos is a great 
project and I think Zaki is 

1081
01:06:10,300 --> 01:06:12,000
amazing and their whole team is 
great. 

1082
01:06:12,000 --> 01:06:14,500
So just because we're not proof 
of stake doesn't mean that 

1083
01:06:14,500 --> 01:06:17,900
necessarily were like 
fundamentally theologically 

1084
01:06:17,900 --> 01:06:21,900
opposed to proof of stake. 
We look at some of the 

1085
01:06:21,900 --> 01:06:25,900
blockchain ecosystem. 
At the moment, we can start to 

1086
01:06:25,908 --> 01:06:29,200
discern some, some, some some 
applications and use cases for 

1087
01:06:29,200 --> 01:06:31,300
each one. 
You know, Bitcoin is sort of 

1088
01:06:31,600 --> 01:06:34,900
shaping up to be a digital gold,
right? 

1089
01:06:34,900 --> 01:06:41,600
And asset that you keep and that
will gain value within the 

1090
01:06:41,600 --> 01:06:46,300
future. 
Ethereum is shaping up to be at 

1091
01:06:46,300 --> 01:06:49,200
least in the initial use cases 
in Project funding. 

1092
01:06:49,900 --> 01:06:52,600
Etc. 
What is what is the use case 

1093
01:06:52,600 --> 01:06:56,900
here for her chain web? 
What's the application that 

1094
01:06:56,900 --> 01:06:59,300
you're hoping? 
Willie marriage is like the 

1095
01:06:59,300 --> 01:07:00,700
killer application for chain 
with? 

1096
01:07:02,400 --> 01:07:10,800
So I like to talk about the like
blockchain as a stack where, for

1097
01:07:10,800 --> 01:07:14,100
example, if you were going to 
launch a project and you wanted 

1098
01:07:14,100 --> 01:07:17,800
to do a token sale and then you 
want to have an application, 

1099
01:07:18,000 --> 01:07:20,600
that would be able to move a 
bunch of transactions through 

1100
01:07:20,600 --> 01:07:24,300
your app. 
And then you would sell your 

1101
01:07:24,300 --> 01:07:30,200
token on ethereum, but you would
want to program your app impact 

1102
01:07:30,200 --> 01:07:35,000
and have your transactions from 
Chain web because we positive 

1103
01:07:35,000 --> 01:07:38,000
that we're going to have much 
higher throughput and therefore 

1104
01:07:38,000 --> 01:07:42,500
much lower transaction fees and 
we will be able to handle high 

1105
01:07:42,500 --> 01:07:46,000
volume transactions in a way 
that right now if they're IAM 

1106
01:07:46,000 --> 01:07:49,000
your sort of struggling to have 
a high volume of transactions 

1107
01:07:50,300 --> 01:07:55,100
and we would like to have the 
ability to have interoperability

1108
01:07:55,100 --> 01:07:57,400
between all of these other 
different layers of the 

1109
01:07:57,400 --> 01:08:00,300
blockchain stack. 
If you wanted to launch your 

1110
01:08:00,300 --> 01:08:04,100
token on eith, we would want to 
be the computer underneath 

1111
01:08:04,100 --> 01:08:06,900
because we have a super simple, 
smart contract language that we 

1112
01:08:06,900 --> 01:08:11,200
think is very easy and has 
really nice tooling on top of a 

1113
01:08:11,200 --> 01:08:13,700
chain, that will be able to 
handle your throughput. 

1114
01:08:15,000 --> 01:08:16,800
So we're very conscious of your 
time here. 

1115
01:08:16,800 --> 01:08:20,800
And we want to spend some time 
on packed, but I think we might 

1116
01:08:20,800 --> 01:08:22,600
have to leave that for a future 
episode. 

1117
01:08:23,200 --> 01:08:25,300
Give me like, two minutes on 
packed. 

1118
01:08:25,399 --> 01:08:27,800
Okay, sure. 
Because it's really cool and 

1119
01:08:27,800 --> 01:08:29,600
really, everybody should go and 
take a look at it. 

1120
01:08:29,600 --> 01:08:32,800
We have the developer SDK sir. 
You can, like, treat your 

1121
01:08:32,800 --> 01:08:35,899
computer as if it were a tiny 
node, and right packed right 

1122
01:08:35,899 --> 01:08:38,399
now. 
It's so we've taken like, 

1123
01:08:38,399 --> 01:08:42,000
basically the completely 
opposite track from solidity and

1124
01:08:42,000 --> 01:08:44,399
all this like virtual machine 
land, where we're trying to 

1125
01:08:44,399 --> 01:08:47,600
replicate an entire computer on 
a blockchain, it is non 

1126
01:08:47,600 --> 01:08:50,300
turing-complete on purpose. 
It's more like SQL for the 

1127
01:08:50,300 --> 01:08:52,300
blockchain instead of sequel for
database. 

1128
01:08:52,300 --> 01:08:55,000
We have packed for blockchain 
and it has all the things like 

1129
01:08:55,000 --> 01:08:57,500
key, signatures and governance. 
And who owns what? 

1130
01:08:57,500 --> 01:08:58,500
And who can change? 
What? 

1131
01:08:58,500 --> 01:09:00,600
All that is built in 
automatically. 

1132
01:09:00,899 --> 01:09:03,200
It has a Full formal 
verification spec. 

1133
01:09:03,200 --> 01:09:04,899
And we have this really awesome 
thing. 

1134
01:09:04,899 --> 01:09:08,000
Now that we've just developed 
called verifiable interfaces, 

1135
01:09:08,200 --> 01:09:11,500
where you can essentially like 
program, what an ER C20 should 

1136
01:09:11,500 --> 01:09:13,899
look like and give it a bunch of
specs. 

1137
01:09:14,100 --> 01:09:17,000
And then if somebody implements 
it incorrectly, it will warn 

1138
01:09:17,000 --> 01:09:20,100
them like, oh, you're you're 
C20. 

1139
01:09:20,100 --> 01:09:21,899
Equivalent is actually a 
malformed. 

1140
01:09:21,899 --> 01:09:24,700
So you can can't have like we 
did the summer a bunch of, like,

1141
01:09:24,700 --> 01:09:28,899
bad ERC 20s that come out. 
So, all of that stuff all built 

1142
01:09:28,899 --> 01:09:31,300
in already packed is like, I 
could. 

1143
01:09:31,500 --> 01:09:34,000
And a whole nother hour talking 
about it, but we'll talk about 

1144
01:09:34,000 --> 01:09:36,800
it another time. 
Yeah, well we perhaps we can 

1145
01:09:36,800 --> 01:09:40,200
have your own in the future to 
go more in depth on packed 

1146
01:09:41,100 --> 01:09:43,800
because I mean chain web did 
take a while to unpack here 

1147
01:09:43,899 --> 01:09:47,800
unpacked. 
So I did want to spend some time

1148
01:09:47,800 --> 01:09:52,899
on on kadena and your private 
blockchain offering. 

1149
01:09:53,600 --> 01:09:57,600
So how does Canada interact with
with chain web? 

1150
01:09:57,600 --> 01:10:01,300
And what's the goal here with 
regards to the types of clients?

1151
01:10:01,400 --> 01:10:04,200
It's that you're approaching 
with this with this platform. 

1152
01:10:05,200 --> 01:10:08,800
Yeah. 
So we have, we have to signed 

1153
01:10:08,800 --> 01:10:10,000
clients. 
Right now that we're working 

1154
01:10:10,000 --> 01:10:14,300
with one of them is this health 
care insurance project that 

1155
01:10:14,300 --> 01:10:15,700
we've already. 
I've already talked about 

1156
01:10:15,700 --> 01:10:22,500
briefly but in general, the idea
is that we want to be a way of 

1157
01:10:22,500 --> 01:10:27,300
onboarding existing businesses 
and new business applications 

1158
01:10:27,300 --> 01:10:33,700
from private to public in a way 
that is Safe and secure, and is 

1159
01:10:33,700 --> 01:10:39,800
a way of unlocking, existing 
business value in a new way, new

1160
01:10:39,800 --> 01:10:42,200
liquidity pipeline. 
So, I talked about the health 

1161
01:10:42,200 --> 01:10:45,100
insurance one where, you know, 
you can pay doctors to update 

1162
01:10:45,100 --> 01:10:48,100
their own information. 
We've also talked to a bunch of 

1163
01:10:48,100 --> 01:10:51,600
different companies. 
Some of them are, some of them 

1164
01:10:51,600 --> 01:10:55,000
are cooler than others. 
Are other big client right now, 

1165
01:10:55,000 --> 01:10:59,200
is a reinsurance company that 
does Insurance products. 

1166
01:10:59,400 --> 01:11:01,300
They do like home insurance and 
stuff. 

1167
01:11:01,400 --> 01:11:04,600
Cough. 
And so we've been discussing 

1168
01:11:04,600 --> 01:11:08,800
with them something where they 
can have a broader pipeline for 

1169
01:11:08,800 --> 01:11:12,700
validating their auditor data. 
So using a third-party Auditors 

1170
01:11:13,000 --> 01:11:17,700
that can contribute data in a 
more tightly verified way to 

1171
01:11:17,700 --> 01:11:20,500
their pipelines so that they can
have a better less leakage in 

1172
01:11:20,500 --> 01:11:21,800
their insurance flow. 
Basically. 

1173
01:11:22,300 --> 01:11:26,200
So we have the side where we 
deal mostly with private and 

1174
01:11:26,200 --> 01:11:29,900
then we also have a focus on 
dealing with public and then 

1175
01:11:29,900 --> 01:11:34,000
everything in between So we 
talked about the idea of 

1176
01:11:34,000 --> 01:11:39,400
connecting Smart TV to the wall 
and then having a people in 

1177
01:11:39,400 --> 01:11:43,500
public on the public blockchain,
get paid like five dollars off 

1178
01:11:43,500 --> 01:11:46,400
their Netflix subscription or 
something in order to provide 

1179
01:11:46,400 --> 01:11:50,000
their Smart TV data to a private
blockchain, that would then use 

1180
01:11:50,000 --> 01:11:52,400
that information which would be 
better than what we have now 

1181
01:11:52,400 --> 01:11:54,900
because right now like who knows
who's looking at your data and 

1182
01:11:54,900 --> 01:11:57,600
what you're providing them. 
This would give you control over

1183
01:11:57,600 --> 01:12:00,800
your own data which you could 
monetize in public but then they

1184
01:12:00,800 --> 01:12:02,000
could mine. 
In private. 

1185
01:12:02,600 --> 01:12:05,400
So there's we have this idea 
that there's not private and 

1186
01:12:05,400 --> 01:12:07,700
public, there's just one block 
chain with different 

1187
01:12:07,700 --> 01:12:14,600
permissions, So to touch on this
in the in the white paper you 

1188
01:12:14,600 --> 01:12:18,600
there's a part there where it 
references, sort of the 

1189
01:12:18,600 --> 01:12:22,300
scalability benefits of kadena 
in a private setting and it 

1190
01:12:22,300 --> 01:12:25,100
makes reference to sort of five 
to fifteen thousand nodes as 

1191
01:12:25,100 --> 01:12:27,900
being, you know, the threshold 
where it begins to exhibit 

1192
01:12:27,900 --> 01:12:30,900
linear scalability. 
Let me, which is sort of expect 

1193
01:12:30,900 --> 01:12:33,300
that at some point that your 
system is going to stop scaling 

1194
01:12:33,300 --> 01:12:37,900
exponentially and more linearly 
But give it given that, you 

1195
01:12:37,907 --> 01:12:41,800
know, a network like Bitcoin as 
I just looked up earlier, has 

1196
01:12:41,800 --> 01:12:46,900
about 10,000 nodes. 
What point does a network, go 

1197
01:12:46,900 --> 01:12:49,400
from being a private Network to 
just being another public 

1198
01:12:49,400 --> 01:12:52,200
network? 
Does it preserve the benefits 

1199
01:12:52,700 --> 01:12:57,400
that sort of the initial 
Consortium or set of clients set

1200
01:12:57,400 --> 01:13:02,200
out to, to implement? 
And what where's the line? 

1201
01:13:02,200 --> 01:13:05,600
They're like, where were you 
sort of switched from being one 

1202
01:13:05,600 --> 01:13:11,700
to the other? 
So the our simulations for 

1203
01:13:12,200 --> 01:13:16,600
scalable bft, which is our 
private consensus mechanism, is 

1204
01:13:17,400 --> 01:13:20,300
we've never run a simulation 
more than 500 nodes. 

1205
01:13:20,500 --> 01:13:24,200
But given that are other options
for people trying to do private 

1206
01:13:24,200 --> 01:13:27,100
blockchain right now or like 
hyper Ledger, that doesn't scale

1207
01:13:27,100 --> 01:13:31,900
past four nodes and kurta, which
isn't even really a blockchain 

1208
01:13:32,200 --> 01:13:34,700
and all of these like other 
private blockchain Technologies.

1209
01:13:35,300 --> 01:13:38,700
We fundamentally believe that we
have a better private 

1210
01:13:38,700 --> 01:13:41,300
blockchain, then anybody else 
right now. 

1211
01:13:41,700 --> 01:13:45,800
And that the idea is that you 
would for one of these 

1212
01:13:45,800 --> 01:13:50,200
applications, start it in 
scalable, bft in the Consortium 

1213
01:13:50,200 --> 01:13:52,800
model. 
And then, as you see the 

1214
01:13:52,800 --> 01:13:57,100
potential benefits of unlocking,
some of these pieces of data 

1215
01:13:57,100 --> 01:14:01,500
into public, you can connect 
them to the public chain. 

1216
01:14:01,900 --> 01:14:06,400
So it's more about how you want 
to monetize your data. 

1217
01:14:06,500 --> 01:14:10,400
If it's still the idea that you 
want to share in a Consortium 

1218
01:14:10,400 --> 01:14:15,200
model like we can scale that out
for some certain amount of time,

1219
01:14:15,200 --> 01:14:17,700
but it's still a permission 
model. 

1220
01:14:17,700 --> 01:14:22,500
Whereas, if you wanted to allow 
exposure to some of these pieces

1221
01:14:22,500 --> 01:14:26,400
of data to the public, like, 
we're talking to a fund right 

1222
01:14:26,400 --> 01:14:30,300
now that creates products for 
people to put in their, like, 

1223
01:14:30,300 --> 01:14:34,200
mutual fund portfolios. 
It's not treasury bonds, but 

1224
01:14:34,200 --> 01:14:35,700
it's sort of like treasury 
bonds. 

1225
01:14:35,700 --> 01:14:38,800
They want to create A tokenized 
representation of one of their 

1226
01:14:38,800 --> 01:14:44,000
funds so that would be a public 
representation of a private 

1227
01:14:44,000 --> 01:14:46,600
blockchain that represents an 
asset. 

1228
01:14:47,500 --> 01:14:51,400
If that makes any sense. 
So I want to take this 

1229
01:14:51,400 --> 01:14:55,500
opportunity to ask you your 
thoughts and opinions about 

1230
01:14:56,100 --> 01:14:59,900
where we stand right now, with 
regards to Enterprise blockchain

1231
01:14:59,900 --> 01:15:01,400
permission blockchain, what have
you? 

1232
01:15:01,900 --> 01:15:05,300
Previously, I co-founded a 
company that sold I guess 

1233
01:15:05,300 --> 01:15:08,900
Enterprise blockchains solutions
for traceability to do large, 

1234
01:15:09,000 --> 01:15:12,100
insurance, companies companies 
and finance sector. 

1235
01:15:12,500 --> 01:15:17,600
And I came out of that with 
haven't been confronted with the

1236
01:15:17,600 --> 01:15:21,200
the the challenge. 
Of implementing blockchain in 

1237
01:15:21,200 --> 01:15:25,900
Enterprise, sort of skeptical to
like, where things are going in 

1238
01:15:25,900 --> 01:15:28,200
the space right now. 
And I could point to a few 

1239
01:15:28,200 --> 01:15:33,800
things namely is that blocked 
any sort of orthogonal to a lot 

1240
01:15:33,800 --> 01:15:39,600
of the business models in, in 
finance, most in the financial 

1241
01:15:39,600 --> 01:15:42,600
sector with insurance or 
banking, or financial services. 

1242
01:15:43,800 --> 01:15:47,000
And although a lot of companies 
obviously are paying attention 

1243
01:15:47,000 --> 01:15:51,400
to blockchain and experimenting 
with proof of concept set, None 

1244
01:15:51,400 --> 01:15:54,100
of that has really panned out. 
And, you know, we've been saying

1245
01:15:54,100 --> 01:15:57,400
for about three years. 
I like that Enterprise is going 

1246
01:15:57,400 --> 01:16:01,100
to start adopting blockchain, 
but even the largest Consulting 

1247
01:16:01,100 --> 01:16:04,700
companies like IBM have been 
pumping out, pocs and are 

1248
01:16:04,700 --> 01:16:10,100
struggling to convert those into
production systems. 

1249
01:16:10,600 --> 01:16:14,400
I think mostly it's because of 
this orthogonal nature of what 

1250
01:16:14,400 --> 01:16:17,400
blockchains represent to large 
companies and just failing to 

1251
01:16:17,400 --> 01:16:20,700
see the ROI I guess. 
As everybody is joining 

1252
01:16:20,700 --> 01:16:22,700
consortiums and trying to figure
out like what they're going to 

1253
01:16:22,708 --> 01:16:25,400
do next. 
Why is credit card Anna 

1254
01:16:25,500 --> 01:16:29,400
different in this sense and like
what's your what's your 

1255
01:16:29,407 --> 01:16:34,800
go-to-market strategy? 
For bringing customers on board,

1256
01:16:34,800 --> 01:16:38,400
consortiums on board and then 
converting them over. 

1257
01:16:38,400 --> 01:16:41,400
It's a sort of this public is 
more public network as you 

1258
01:16:41,400 --> 01:16:46,100
described it. 
So, our vision for kadena is a 

1259
01:16:46,100 --> 01:16:52,500
whole is that we because of how,
our smart contracts function, 

1260
01:16:52,800 --> 01:16:58,300
you can essentially create 
importable services. 

1261
01:16:59,300 --> 01:17:02,100
So stick with me here, and I'm 
going to tie back to Enterprise,

1262
01:17:02,100 --> 01:17:06,700
but imagine on the public chain 
that you have building block 

1263
01:17:06,700 --> 01:17:14,100
services, that provide a network
that You a lot of flexibility. 

1264
01:17:14,500 --> 01:17:18,900
So you have we're going to set 
up a background, check service 

1265
01:17:19,000 --> 01:17:24,800
that's on the blockchain and a 
escrow service and a smart 

1266
01:17:24,800 --> 01:17:29,200
contract insurance. 
And all of these components that

1267
01:17:29,200 --> 01:17:32,600
we have right now in the 
economy, they don't function 

1268
01:17:32,600 --> 01:17:36,500
great and they're expensive. 
And they essentially push all of

1269
01:17:36,500 --> 01:17:39,800
the payment on to the consumers,
end, which sucks. 

1270
01:17:40,600 --> 01:17:45,500
So instead, if we Have them in 
an importable smart contract way

1271
01:17:45,500 --> 01:17:50,400
on a public blockchain. 
Then you say as entrepreneur 

1272
01:17:50,400 --> 01:17:53,700
want to create a rent, an 
apartment service on the 

1273
01:17:53,700 --> 01:17:56,300
blockchain. 
So what you would do is you 

1274
01:17:56,300 --> 01:17:59,600
would have a way of showing your
listings. 

1275
01:17:59,600 --> 01:18:02,300
And then when somebody wants to 
rent an apartment, you would 

1276
01:18:02,300 --> 01:18:05,600
import the background. 
Check smart contract and you 

1277
01:18:05,600 --> 01:18:07,700
would use it. 
And for some sort of micro 

1278
01:18:07,700 --> 01:18:12,100
transaction fee, you pay the 
verifier of the background check

1279
01:18:12,100 --> 01:18:14,800
directly. 
Finish my contract, you would 

1280
01:18:14,800 --> 01:18:18,100
have some sort of escrow 
service, which you would pay 

1281
01:18:18,100 --> 01:18:20,800
directly, or maybe you just do 
it built into your smart 

1282
01:18:20,800 --> 01:18:25,400
contract and these building 
block components would help you 

1283
01:18:26,100 --> 01:18:31,500
do the part of your real estate.
Apartment rental startup that is

1284
01:18:31,500 --> 01:18:33,700
most interesting to you, which 
is figuring out how to expose 

1285
01:18:33,700 --> 01:18:37,700
listings without having to deal 
with all of these other terrible

1286
01:18:37,700 --> 01:18:41,200
components that are necessary 
for a company like ensuring your

1287
01:18:41,200 --> 01:18:42,800
smart contracts and doing 
background checks. 

1288
01:18:42,900 --> 01:18:47,500
And whatever. 
So then when we're talking about

1289
01:18:47,500 --> 01:18:50,600
having these services on a 
chain, there are a lot of 

1290
01:18:50,600 --> 01:18:53,900
companies that already have 
these Services. 

1291
01:18:54,100 --> 01:18:57,500
They just don't know how to 
effectively monetize them or 

1292
01:18:57,500 --> 01:19:01,500
they're already cost centers 
from their company that by 

1293
01:19:01,500 --> 01:19:06,100
having an oracle to public 
blockchain, they could monetize 

1294
01:19:06,100 --> 01:19:07,800
what's already a cost center for
them. 

1295
01:19:08,600 --> 01:19:12,800
So imagine like, I don't chase 
bank, Chase Bank already has 

1296
01:19:12,900 --> 01:19:17,100
Department that does background 
checks and if they could have a 

1297
01:19:17,100 --> 01:19:19,900
smart contract on the public 
blockchain where people could 

1298
01:19:19,900 --> 01:19:22,800
pay them to do background 
checks, they could run that 

1299
01:19:22,800 --> 01:19:26,000
through their Pipeline and 
monetize an existing business 

1300
01:19:26,000 --> 01:19:27,900
unit. 
That right now is only a cost 

1301
01:19:27,900 --> 01:19:30,400
center for them. 
So this is it's sort of like 

1302
01:19:30,400 --> 01:19:36,100
applying the sharing economy to 
the components that already make

1303
01:19:36,100 --> 01:19:40,300
up very large businesses. 
So this is a way of onboarding 

1304
01:19:40,500 --> 01:19:42,700
Chase Bank on to Enterprise bok 
choy. 

1305
01:19:42,900 --> 01:19:45,400
And I'm not saying like Deer 
Chase Bank. 

1306
01:19:45,400 --> 01:19:48,800
Please go in and rip out all of 
your existing database because 

1307
01:19:48,800 --> 01:19:51,400
they're never going to do that. 
But instead we can go to them 

1308
01:19:51,400 --> 01:19:55,500
and say, look, let's create a 
new product that monetizes an 

1309
01:19:55,500 --> 01:19:57,200
existing cost center in your 
business. 

1310
01:19:57,300 --> 01:20:00,100
That doesn't have to connect to 
any of the rest of your network.

1311
01:20:00,100 --> 01:20:04,000
That's totally secure, and let's
see how it goes, because they're

1312
01:20:04,000 --> 01:20:08,300
much more likely to try to 
create a new Revenue stream, 

1313
01:20:09,100 --> 01:20:11,300
that's disconnected from the 
rest of their business. 

1314
01:20:11,300 --> 01:20:14,300
Then they are to try to like, 
About the guts of their existing

1315
01:20:14,300 --> 01:20:16,800
infrastructure. 
It's super hard to sell that 

1316
01:20:16,800 --> 01:20:19,800
because nobody wants to touch 
something that's basically 

1317
01:20:19,800 --> 01:20:22,300
working for something that 
doesn't necessarily have any 

1318
01:20:22,300 --> 01:20:26,200
major advantages but potential 
new revenue streams, everybody 

1319
01:20:26,200 --> 01:20:31,200
gets excited for potential new 
revenue streams I get that and I

1320
01:20:31,200 --> 01:20:32,700
think that's the fundamental 
issue here. 

1321
01:20:32,700 --> 01:20:36,000
And that's the sort of 
fundamental problems with the 

1322
01:20:36,000 --> 01:20:38,300
whole premise of Enterprise 
blockchain. 

1323
01:20:38,500 --> 01:20:46,500
Is that It is orthogonal to the 
like to, to try to, to get Chase

1324
01:20:46,500 --> 01:20:51,400
Bank to monetize an existing 
service is real Authority with 

1325
01:20:51,400 --> 01:20:54,500
the way that they already do 
business, especially when you're

1326
01:20:54,500 --> 01:20:57,300
opening it up on on a sort of 
public network. 

1327
01:20:57,900 --> 01:21:01,600
And I think that coming over my 
experience in my previous 

1328
01:21:01,600 --> 01:21:06,500
company that it's not so much. 
A technological issue, is not so

1329
01:21:06,500 --> 01:21:09,000
much about the technology. 
It's really a change management 

1330
01:21:09,000 --> 01:21:14,100
issue. 
And that all this is vandalism 

1331
01:21:14,200 --> 01:21:16,400
that all of us have been doing 
for. 

1332
01:21:16,400 --> 01:21:20,900
So all these years in large 
companies and Enterprise about 

1333
01:21:20,900 --> 01:21:24,300
blockchain technology, I think 
we've been doing it wrong. 

1334
01:21:24,300 --> 01:21:27,700
And it really comes down to 
like, what is the future of 

1335
01:21:27,700 --> 01:21:31,000
identity? 
What is the future of payments? 

1336
01:21:31,000 --> 01:21:33,400
What is the future of insurance?
Was that going to look like in 

1337
01:21:33,400 --> 01:21:36,900
the future and in currently, I 
think most people that are 

1338
01:21:36,900 --> 01:21:41,300
addressing their talking to 
Innovation, departments at Banks

1339
01:21:41,300 --> 01:21:43,200
and financial services companies
Insurance. 

1340
01:21:43,200 --> 01:21:45,500
What have you are not really 
doing this. 

1341
01:21:45,500 --> 01:21:47,600
They're still spending time 
saying oh well I mean, look, you

1342
01:21:47,600 --> 01:21:50,000
could, you could take this 
existing thing plug a box and 

1343
01:21:50,000 --> 01:21:53,700
into it and start making money 
in this ecosystem. 

1344
01:21:53,700 --> 01:21:55,300
That doesn't, that doesn't exist
yet. 

1345
01:21:57,400 --> 01:22:01,500
So I guess my question is 
remains like, what is the, what 

1346
01:22:01,500 --> 01:22:04,400
is really, the go-to-market 
strategy where have you? 

1347
01:22:04,400 --> 01:22:08,900
I like sort of identified, some 
key Industries or types of 

1348
01:22:08,900 --> 01:22:12,100
clients where You can take a 
Dana and really provide an 

1349
01:22:12,100 --> 01:22:15,100
out-of-the-box solution to start
generating like generate 

1350
01:22:15,100 --> 01:22:18,600
revenue. 
And to prove these use cases 

1351
01:22:18,600 --> 01:22:19,700
because the proof is in the 
pudding. 

1352
01:22:21,200 --> 01:22:24,000
Sure. 
I mean, we have two existing 

1353
01:22:24,000 --> 01:22:27,600
clients. 
We already have a working MVP. 

1354
01:22:27,900 --> 01:22:30,900
I don't know what to tell you 
other than like, we're doing it.

1355
01:22:32,400 --> 01:22:36,400
And we don't have to pay like 
some companies like pay people 

1356
01:22:36,400 --> 01:22:39,600
to use pocs, like, people come 
to us, they want to use our 

1357
01:22:39,600 --> 01:22:41,100
stuff. 
Sometimes we have to turn people

1358
01:22:41,100 --> 01:22:43,000
away because they're like, we 
have this great idea. 

1359
01:22:43,200 --> 01:22:45,100
We're like great, but we can't 
execute it for you. 

1360
01:22:45,100 --> 01:22:46,500
You have to have your own 
engineering team. 

1361
01:22:46,500 --> 01:22:49,300
We're just going to give you a 
Consulting, like, if people 

1362
01:22:49,300 --> 01:22:51,800
aren't ready to go, we're not 
going to work with them. 

1363
01:22:52,000 --> 01:22:55,500
But right now, big people are 
coming to us, say they say that 

1364
01:22:55,500 --> 01:22:57,300
we have a thing that works. 
We do. 

1365
01:22:59,100 --> 01:23:02,500
So what's the, what's the 
roadmap like in the next? 

1366
01:23:02,800 --> 01:23:05,500
So you mentioned earlier and SDK
but people can already start 

1367
01:23:05,500 --> 01:23:08,000
using the platform. 
Can you talk a bit more about 

1368
01:23:08,000 --> 01:23:09,100
that? 
Sure. 

1369
01:23:09,400 --> 01:23:14,000
So we've got two teams right now
working on both the language 

1370
01:23:14,000 --> 01:23:17,900
development and tooling for 
developers and another team 

1371
01:23:17,900 --> 01:23:21,700
that's working on chain web and 
protocol development. 

1372
01:23:21,800 --> 01:23:25,500
And so we've split them into two
tests Nets to where we're at 

1373
01:23:25,508 --> 01:23:26,900
right now. 
Working on both of them, the 

1374
01:23:26,900 --> 01:23:30,600
same time, The Pact test. 
Supposed to come up next month, 

1375
01:23:30,700 --> 01:23:33,800
where people can see it's going 
to use a database to generate 

1376
01:23:33,800 --> 01:23:36,300
blocks, but it's essentially 
going to have all of the bells 

1377
01:23:36,300 --> 01:23:39,500
and whistles for a development 
environment, where people can 

1378
01:23:39,700 --> 01:23:43,500
put, their smart contracts up 
onto our IDE, and have error 

1379
01:23:43,500 --> 01:23:46,700
messages, and it'll hook up to 
the formal verification system. 

1380
01:23:46,700 --> 01:23:49,500
And this will be more of a 
simulated experience of what 

1381
01:23:49,500 --> 01:23:51,700
developing on containing will be
like. 

1382
01:23:52,400 --> 01:23:55,000
And then, Meanwhile, we're 
working on chain web test net, 

1383
01:23:55,000 --> 01:23:57,500
which should be up by the end of
the year, which will, it's 

1384
01:23:57,500 --> 01:23:58,700
basically, just a way of 
testing. 

1385
01:23:58,700 --> 01:24:01,800
Testing how blocks get generated
in Forks, get resolved in the 

1386
01:24:01,800 --> 01:24:05,600
consensus mechanism and then 
we're going to merge them to 

1387
01:24:05,600 --> 01:24:09,700
create a unified test net. 
When then the goal is to have 

1388
01:24:09,700 --> 01:24:12,600
the main it launched around the 
second quarter of next year. 

1389
01:24:13,800 --> 01:24:15,500
Great. 
So we'll have links to all that 

1390
01:24:15,500 --> 01:24:17,100
and show notes. 
If people are interested, they 

1391
01:24:17,100 --> 01:24:21,500
can go to do the Canadian 
website, read the white papers, 

1392
01:24:22,400 --> 01:24:27,300
which you've you've co-written 
with your co-founders and and 

1393
01:24:27,300 --> 01:24:31,500
learn more about how Canada will
be building up. 

1394
01:24:31,500 --> 01:24:35,400
This, this chain web Network and
then also implementing their 

1395
01:24:35,400 --> 01:24:39,600
Technologies in Enterprise. 
So thanks Monica for coming on 

1396
01:24:39,600 --> 01:24:42,000
the show today. 
Thanks guys, this is great. 

1397
01:24:44,200 --> 01:24:46,000
Thank you for joining us on this
week's episode. 

1398
01:24:46,300 --> 01:24:48,000
We release new episodes every 
week. 

1399
01:24:48,500 --> 01:24:51,300
You can find And subscribe to 
the show on iTunes Spotify, 

1400
01:24:51,300 --> 01:24:54,500
YouTube SoundCloud or wherever 
you listen to podcast. 

1401
01:24:54,700 --> 01:24:57,600
And if you have a Google home or
Alexa device, you can tell it to

1402
01:24:57,600 --> 01:25:00,500
listen to the latest episode of 
the epicenter podcast, go to 

1403
01:25:00,500 --> 01:25:03,700
epicenter, .t V /, subscribe for
a full list of places where you 

1404
01:25:03,700 --> 01:25:06,300
can watch and listen, while 
you're there, be sure to sign up

1405
01:25:06,300 --> 01:25:09,100
for the newsletter so you get 
new episodes in your inbox as 

1406
01:25:09,100 --> 01:25:11,500
the released. 
If you want to interact with us,

1407
01:25:11,700 --> 01:25:14,300
the guests or other podcast 
listeners you can Follow us on 

1408
01:25:14,300 --> 01:25:16,400
Twitter and please leave us a 
review on iTunes. 

1409
01:25:16,600 --> 01:25:18,900
It helps people find the show 
and we're always happy to read 

1410
01:25:18,900 --> 01:25:21,300
them. 
The thanks so much and we look 

1411
01:25:21,300 --> 01:25:22,500
forward to being back next week.