1
00:00:31,600 --> 00:00:34,400
Hi, welcome to epicenter the 
show which talks about the 

2
00:00:34,400 --> 00:00:36,700
Technologies, projects and 
startups. 

3
00:00:36,800 --> 00:00:39,600
Driving the crypto economy. 
I am here, Roy. 

4
00:00:40,000 --> 00:00:43,800
And today we have a very 
interesting episode discussing 

5
00:00:43,800 --> 00:00:46,900
sharding and a project that has 
a unique Approach. 

6
00:00:46,900 --> 00:00:51,500
At sharding, blockchains we have
on the show Xin should dong and 

7
00:00:51,500 --> 00:00:55,800
embrace Kumar from silica since 
you as the CEO of silica and 

8
00:00:55,800 --> 00:00:59,300
Amrit is equipped to lead. 
Their silica is an innovative 

9
00:00:59,300 --> 00:01:02,900
blockchain. 
Platform, which has a sharded 

10
00:01:02,900 --> 00:01:05,400
blockchain already running as a 
private testing. 

11
00:01:06,300 --> 00:01:10,100
Since when welcome to the show. 
Thank you. 

12
00:01:10,100 --> 00:01:11,900
It's our pleasure to be here. 
Thank you. 

13
00:01:11,900 --> 00:01:12,500
Ma'am. 
Thank you. 

14
00:01:13,100 --> 00:01:16,100
So before we start talking about
silica, and what that project is

15
00:01:16,100 --> 00:01:18,700
trying to do, tell us a bit 
about your background and how 

16
00:01:18,700 --> 00:01:20,100
you came to be involved in the 
Block Chain. 

17
00:01:20,100 --> 00:01:21,900
Space. 
Sure. 

18
00:01:21,900 --> 00:01:26,000
So maybe I can start. 
My name is Jin xiu. 

19
00:01:26,800 --> 00:01:30,000
I'm from the more technical side
in my PhD. 

20
00:01:30,000 --> 00:01:32,700
I worked on cybersecurity for 
web browsers in a web 

21
00:01:32,700 --> 00:01:35,300
applications. 
So later, I worked on, you know,

22
00:01:35,700 --> 00:01:39,000
the security for Control 
software Control software For 

23
00:01:39,000 --> 00:01:41,900
larger systems, like smart grid,
Transportation, internet of 

24
00:01:41,908 --> 00:01:45,300
things, things like that. 
Of course, I started to develop 

25
00:01:45,300 --> 00:01:50,100
a personal interest later on 
blockchain itself and here, you 

26
00:01:50,100 --> 00:01:53,100
know, predict saxena talk to me 
again, you know, I used to work 

27
00:01:53,100 --> 00:01:55,700
with him very closely during my 
PhD time. 

28
00:01:56,100 --> 00:01:59,400
So, after a few years, you talk 
to me again, hey, I started a 

29
00:01:59,400 --> 00:02:00,500
company. 
You know, we're working on 

30
00:02:00,500 --> 00:02:02,300
blockchain, why don't you come 
and join us. 

31
00:02:02,700 --> 00:02:05,400
So that's, that's the time I 
really started to think 

32
00:02:05,400 --> 00:02:08,400
seriously that I shouldn't know 
really work full-time on a 

33
00:02:08,400 --> 00:02:11,600
blockchain. 
And, and I do so, after a few 

34
00:02:11,600 --> 00:02:15,300
months, I join his company and 
started to develop this 

35
00:02:15,900 --> 00:02:19,400
scalable, blockchain technology 
into, you know, 

36
00:02:19,400 --> 00:02:22,200
commercialization into 
deployment answer, permission 

37
00:02:22,200 --> 00:02:25,200
blockchain, you know, that was 
about you, no more than one year

38
00:02:25,200 --> 00:02:29,300
ago and that's how I started 
working working on blockchain of

39
00:02:29,300 --> 00:02:30,600
course. 
You know this year, we started 

40
00:02:30,600 --> 00:02:33,800
this new project, silica. 
I'm very excited to bring that 

41
00:02:33,800 --> 00:02:37,500
technology into a much larger 
scale as a public blockchain. 

42
00:02:38,100 --> 00:02:40,200
That's very briefly about 
myself. 

43
00:02:40,900 --> 00:02:46,800
Yeah so for me I have a PhD from
India, France and then I came 

44
00:02:46,800 --> 00:02:49,400
over to Singapore. 
I started working as a postdoc 

45
00:02:49,400 --> 00:02:53,000
interpreting 6 a.m. and then I 
started discovering blockchain 

46
00:02:53,000 --> 00:02:58,100
and and they're different 
different problems and solutions

47
00:02:59,000 --> 00:03:01,800
and my Essential background is 
on applied cryptography and 

48
00:03:01,800 --> 00:03:04,500
privacy. 
So again, it was the same kind 

49
00:03:04,500 --> 00:03:06,500
of story but they called me up 
and said yeah, are you 

50
00:03:06,508 --> 00:03:08,100
interested in developing 
something? 

51
00:03:08,100 --> 00:03:09,100
Like Silk? 
I said, why not? 

52
00:03:09,700 --> 00:03:12,000
And then I joined the project so
yeah. 

53
00:03:13,100 --> 00:03:16,500
Cool. 
So, I think, I think very few of

54
00:03:16,500 --> 00:03:20,200
our listeners would explicitly 
know about pratik, saxena and 

55
00:03:20,200 --> 00:03:22,700
the, and his group at nus, 
Singapore. 

56
00:03:22,700 --> 00:03:28,400
So, as I've seen a lot of papers
from this group including so 

57
00:03:28,400 --> 00:03:31,200
there was a paper called like 
demystifying incentives in the 

58
00:03:31,200 --> 00:03:33,200
country in the consensus 
computer. 

59
00:03:33,700 --> 00:03:38,100
Right now that that that that 
posited that there was some kind

60
00:03:38,100 --> 00:03:42,700
of verification dilemna in in a 
blockchain like you cerium, And 

61
00:03:42,700 --> 00:03:47,600
that translated through multiple
different technological Jones 

62
00:03:47,600 --> 00:03:52,100
became like the true bit. 
Another project to come out of 

63
00:03:53,300 --> 00:03:58,900
this group is like loy's work, 
starting with x must secure 

64
00:03:58,900 --> 00:04:02,900
smart contract languages and 
then ultimately decentralised 

65
00:04:02,900 --> 00:04:06,600
exchanges and Kaiba Network. 
So that is also. 

66
00:04:06,600 --> 00:04:09,900
Now I also did his PhD as far as
I know, from, from this group 

67
00:04:10,300 --> 00:04:14,300
and another project that I know 
of personally is just this one 

68
00:04:14,300 --> 00:04:16,000
silica. 
So there's, there's been at 

69
00:04:16,000 --> 00:04:19,700
least like 33. 
The interesting projects that 

70
00:04:19,700 --> 00:04:23,100
have come out of this group, 
that's unusually productive for 

71
00:04:23,100 --> 00:04:25,900
an act as very unusually 
productive for an academic 

72
00:04:25,900 --> 00:04:28,800
group. 
In any University, I would say, 

73
00:04:30,000 --> 00:04:30,700
Yeah. 
Yeah. 

74
00:04:30,800 --> 00:04:32,900
You know, we're we're very 
fortunate to be part of the 

75
00:04:32,900 --> 00:04:36,400
group as well. 
So the whole idea was silica, 

76
00:04:37,200 --> 00:04:41,000
you know, it's expired by this 
original academic research paper

77
00:04:41,000 --> 00:04:44,200
caused by law and predict is 
called elastic. 

78
00:04:44,200 --> 00:04:47,300
Oh, you know, that's that's 
where all these high level ideas

79
00:04:47,300 --> 00:04:53,100
of shouting started. 
Okay, so, let's let's drive down

80
00:04:53,100 --> 00:04:56,800
into zelicah. 
So silica is a is a sharded 

81
00:04:56,800 --> 00:05:01,100
public blockchain with its own 
cryptocurrency called xilinx, 

82
00:05:02,000 --> 00:05:06,100
but before we drive down into 
what, ex exactly the way the 

83
00:05:06,100 --> 00:05:10,100
technology Works, let's talk a 
bit about scalability in in 

84
00:05:10,100 --> 00:05:14,400
general, right? 
So our viewers know about the 

85
00:05:14,400 --> 00:05:16,400
scalability problems of 
blockchains because we have 

86
00:05:16,400 --> 00:05:18,500
talked about that many, many 
times. 

87
00:05:19,200 --> 00:05:23,100
The thing that is sort Or 
perhaps a bit less known is 

88
00:05:23,100 --> 00:05:24,700
what? 
Exactly is sharding. 

89
00:05:25,000 --> 00:05:28,100
We have this word but is there 
like a good definition for it? 

90
00:05:29,400 --> 00:05:32,400
I don't know, I guess I would 
not try to give a very formal 

91
00:05:32,400 --> 00:05:36,000
definition of shouting because I
think that this term shouting 

92
00:05:36,000 --> 00:05:39,400
was invented many years ago in 
the inning, the database 

93
00:05:39,700 --> 00:05:42,800
Community. 
But when, you know, people bring

94
00:05:42,800 --> 00:05:47,000
this idea of shouting into 
public blockchain to try to make

95
00:05:47,000 --> 00:05:50,300
the blockchain, the most Global.
The high-level idea of sharing 

96
00:05:50,300 --> 00:05:54,600
is quite straightforward. 
Let's just assume we have a 

97
00:05:54,600 --> 00:05:56,900
blockchain network of 1,000 
nodes. 

98
00:05:57,300 --> 00:06:01,500
So what shouting does is to 
These 1000 nose into let's say 

99
00:06:01,500 --> 00:06:04,300
10 shots, you know, with 100 
euros each. 

100
00:06:04,500 --> 00:06:09,800
So the El what it does is to 
process different transactions 

101
00:06:09,800 --> 00:06:12,600
in different shots, disjoint set
of transactions. 

102
00:06:13,000 --> 00:06:17,400
So there you can achieve some 
level of parallel processing 

103
00:06:18,100 --> 00:06:22,500
this in itself, improves the 
throughput of the blockchain. 

104
00:06:22,900 --> 00:06:25,700
Bye-bye, you know, a large, a 
large Factor. 

105
00:06:26,300 --> 00:06:29,600
So this is easy, the high level 
idea of shining, Of course you 

106
00:06:29,600 --> 00:06:34,300
know to really work it out to 
make sure this process is secure

107
00:06:34,300 --> 00:06:36,600
and it's very efficient. 
You know that that's where you 

108
00:06:36,600 --> 00:06:40,700
know the complexities come. 
Like sharding. 

109
00:06:40,900 --> 00:06:44,600
I presume is like this technique
that has been used at different 

110
00:06:44,600 --> 00:06:47,400
sort of database designs of 
course time. 

111
00:06:47,500 --> 00:06:48,500
Right. 
Right. 

112
00:06:49,000 --> 00:06:52,800
And now we have bringing that 
sort of knowledge and those 

113
00:06:52,800 --> 00:06:56,500
techniques from into the Block 
Chain space which has its own 

114
00:06:56,700 --> 00:06:58,800
unique challenges while you 
while you showered the 

115
00:06:58,800 --> 00:07:03,400
blockchain, right? 
So like is sharding, a single 

116
00:07:03,400 --> 00:07:06,000
monolithic technique or are 
there different kinds of 

117
00:07:06,000 --> 00:07:08,400
sharding that have that are 
possible? 

118
00:07:08,700 --> 00:07:12,800
I think there are different 
possibilities or different 

119
00:07:12,800 --> 00:07:16,600
variants of shouting. 
So, number one, I think when 

120
00:07:16,600 --> 00:07:19,600
most people talk about shouting,
we actually refer to something 

121
00:07:19,600 --> 00:07:24,300
we would call stationary. 
So that's maybe the closest, you

122
00:07:24,300 --> 00:07:29,100
know, the derived idea from the 
database sharding concept. 

123
00:07:29,100 --> 00:07:33,400
So what stay shutting does is 
essentially it would divide the 

124
00:07:33,400 --> 00:07:35,700
nodes in the network into 
different parts. 

125
00:07:35,700 --> 00:07:39,800
So when one note belongs to one,
Part or one shark. 

126
00:07:40,000 --> 00:07:44,500
That knows Only Stores data and 
information for that particular 

127
00:07:44,500 --> 00:07:47,500
chart. 
In other words, it, you know, it

128
00:07:47,500 --> 00:07:51,500
doesn't know what's going on in 
another shark know what's going 

129
00:07:51,500 --> 00:07:55,200
on outside the shot himself. 
So these clearly has several 

130
00:07:55,200 --> 00:07:58,400
advantages. 
So number one it significantly 

131
00:07:58,400 --> 00:08:03,500
reduces you know the size of 
data each no needs to stop. 

132
00:08:03,900 --> 00:08:07,400
And reduces, you know, the 
number of transactions each no 

133
00:08:07,400 --> 00:08:11,700
needs to process. 
And it also reduces the volume 

134
00:08:11,700 --> 00:08:15,500
of data that needs to be 
propagated across the network 

135
00:08:15,500 --> 00:08:19,200
because, you know, you just, you
know, send some data to this 

136
00:08:19,200 --> 00:08:20,500
shot. 
You don't need to send the same 

137
00:08:20,500 --> 00:08:22,300
piece of data to another shot of
example. 

138
00:08:22,600 --> 00:08:25,500
So these are all these 
advantages of stationing, that's

139
00:08:25,500 --> 00:08:29,700
why this concept is very 
interesting, but on the other 

140
00:08:29,700 --> 00:08:32,900
hand, there are also many 
challenges to, you know, to do 

141
00:08:32,900 --> 00:08:37,799
this properly. 
So Nava is security. 

142
00:08:38,100 --> 00:08:42,900
So, If one hour stays within one
shot and then it doesn't 

143
00:08:42,900 --> 00:08:46,600
actually understand, you know, 
nose outside that shot, doesn't 

144
00:08:46,600 --> 00:08:48,600
understand things going on 
inside this shot. 

145
00:08:48,700 --> 00:08:51,600
So if a tackle is just focus, 
all the power attacking this 

146
00:08:51,600 --> 00:08:55,800
particular shot, you know, over 
time, this may become an issue. 

147
00:08:56,000 --> 00:09:00,200
So this is number one and number
two is about redundancy or 

148
00:09:00,200 --> 00:09:05,500
resilience because instead of 
let's say whole net worth of 

149
00:09:05,500 --> 00:09:08,600
20,000 knows storing, 20,000 
copies. 

150
00:09:08,800 --> 00:09:10,600
Uh, particular piece of 
information. 

151
00:09:10,900 --> 00:09:14,600
Now, you only have let's say 500
or 1000 notes, keeping that 

152
00:09:14,600 --> 00:09:19,400
piece of information and was one
third or half of those nodes 

153
00:09:19,500 --> 00:09:21,200
have a problem with that 
information either. 

154
00:09:21,200 --> 00:09:25,400
They are compromised, or 
attacked or deleted or somehow 

155
00:09:25,400 --> 00:09:27,900
just lost. 
Such information is a problem 

156
00:09:27,900 --> 00:09:31,100
because nobody else in this 
network, you know, understands 

157
00:09:31,500 --> 00:09:33,100
this particular piece of 
information. 

158
00:09:33,400 --> 00:09:37,600
So these are some of the issues,
I see, if I may add to this. 

159
00:09:37,600 --> 00:09:41,300
I mean, this whole idea. 
I've stood Surety for say it is 

160
00:09:41,300 --> 00:09:44,600
actually came from Bitcoin model
where you have the suit exe 

161
00:09:44,600 --> 00:09:47,300
model and you want to if you 
want to know whether an output 

162
00:09:47,300 --> 00:09:50,500
has been spent or is still on 
the spot, you want to have the 

163
00:09:50,500 --> 00:09:54,200
store and you have to store the 
diet history, and that history 

164
00:09:54,200 --> 00:09:57,300
can be very huge. 
So you need a way to kind of 

165
00:09:57,300 --> 00:10:00,600
divide that history into chunks.
So that each node only has to 

166
00:10:00,600 --> 00:10:03,100
sort of part that that that they
died history. 

167
00:10:03,800 --> 00:10:06,200
So the the story comes from 
comes from these. 

168
00:10:06,200 --> 00:10:07,900
This utx or Bitcoin current 
model. 

169
00:10:08,800 --> 00:10:12,800
Yeah, this is stay shouting. 
Of course, you know, we started 

170
00:10:12,800 --> 00:10:16,500
this idea of this direction of 
possibilities where we design 

171
00:10:16,800 --> 00:10:22,100
the silica's protocols, our sort
of conclusion at that time was, 

172
00:10:22,100 --> 00:10:24,800
it's very challenging to do 
that, we would rather need more 

173
00:10:24,800 --> 00:10:28,700
time to work on it. 
On the other hand, what silica 

174
00:10:28,700 --> 00:10:32,800
Curry does is something we can 
call never shouting or 

175
00:10:32,800 --> 00:10:36,500
transaction shot. 
That means for each node, it's 

176
00:10:36,500 --> 00:10:39,400
still stores. 
All the current state up, you 

177
00:10:39,400 --> 00:10:43,500
know, up to date, let's say 
account balances for the entire 

178
00:10:43,500 --> 00:10:48,500
Block Chain Network. 
So it's not stay shouting, but 

179
00:10:48,500 --> 00:10:51,700
on the other hand, we shot the 
processing of the transactions, 

180
00:10:52,000 --> 00:10:53,900
so that means we have different 
shots. 

181
00:10:54,200 --> 00:10:56,800
We will send different 
connections to different shots 

182
00:10:56,800 --> 00:10:59,500
for processing. 
And eventually, you know, all 

183
00:10:59,500 --> 00:11:03,300
such information for the next 
block will be aggregated. 

184
00:11:03,400 --> 00:11:07,200
And Still seeing through to all 
the nodes so we can see easily 

185
00:11:07,200 --> 00:11:09,500
here. 
We, you know, the pros are very 

186
00:11:09,500 --> 00:11:12,800
simple. 
We basically avoid many of these

187
00:11:12,800 --> 00:11:16,500
security and resilience 
challenges in slingshotting, but

188
00:11:16,500 --> 00:11:20,300
on the other hand, there are 
additional challenges in doing 

189
00:11:20,300 --> 00:11:24,000
only Network shouting compared 
to stay shouting because every 

190
00:11:24,000 --> 00:11:26,300
no room is still need to store 
lots of information. 

191
00:11:26,300 --> 00:11:30,000
And still, we need to propagate 
lots of information to other 

192
00:11:30,000 --> 00:11:32,400
nodes. 
So, you know, these are some of 

193
00:11:32,400 --> 00:11:34,900
the places, silica. 
'He is you know, doing the 

194
00:11:34,900 --> 00:11:37,700
information. 
Okay? 

195
00:11:37,700 --> 00:11:41,700
So so when we're ready, when you
are speaking is in show like 

196
00:11:41,800 --> 00:11:46,300
sort of imagination came into my
mind which is that we can 

197
00:11:46,300 --> 00:11:48,700
imagine. 
You can imagine like any 

198
00:11:48,700 --> 00:11:51,200
blockchain first like a 
blockchain like Bitcoin. 

199
00:11:51,200 --> 00:11:58,600
Let's imagine that sort of sort 
of like A government office, 

200
00:11:58,600 --> 00:12:01,900
right? 
Like so, so there's this, 

201
00:12:01,900 --> 00:12:05,900
there's this government office 
and they're like, employees in 

202
00:12:05,900 --> 00:12:08,200
that office and all of these 
employees they are just 

203
00:12:08,200 --> 00:12:12,100
accountants, right? 
And these accountants are 

204
00:12:12,100 --> 00:12:16,800
basically all the nodes. 
So these are the reasons I full 

205
00:12:16,800 --> 00:12:21,000
nodes of of the system. 
So whenever like you want to 

206
00:12:21,000 --> 00:12:24,000
process a transaction, you you 
basically like go to this 

207
00:12:24,000 --> 00:12:28,000
building and you like put the 
transaction in And all of these 

208
00:12:28,000 --> 00:12:31,000
employees, they maintain their 
own book, and they are going to 

209
00:12:31,000 --> 00:12:33,700
add, they're going to verify 
that your transaction is right, 

210
00:12:33,700 --> 00:12:38,900
and they're going to add it to 
the book and the, the working in

211
00:12:38,900 --> 00:12:42,100
this sort of office, this 
governmental office is designed 

212
00:12:42,100 --> 00:12:46,200
in a way that each employee will
add the same number of same 

213
00:12:46,200 --> 00:12:49,400
transactions in the same order 
in that in that book. 

214
00:12:49,800 --> 00:12:53,100
But that a that book is 
replicated across all of the 

215
00:12:53,100 --> 00:12:55,600
employees. 
So if there are like a thousand 

216
00:12:55,600 --> 00:12:59,500
employees in these This building
each one of them has the same 

217
00:12:59,500 --> 00:13:04,600
copy of that book and at any 
instant of time, each of these 

218
00:13:04,600 --> 00:13:07,700
employees is working on that. 
On our same set of new 

219
00:13:07,700 --> 00:13:10,400
transactions to add on this to 
this book. 

220
00:13:10,400 --> 00:13:16,100
They're verifying the same time,
set of transactions and So 

221
00:13:16,100 --> 00:13:18,800
that's like that's like Bitcoin 
that's like it's helium today. 

222
00:13:18,800 --> 00:13:22,400
So each employee is redundantly 
doing that work and all of them 

223
00:13:22,400 --> 00:13:25,700
are internally maintaining that 
the same copy of this book. 

224
00:13:27,400 --> 00:13:31,000
Now what what silica does is 
like once one step ahead. 

225
00:13:31,000 --> 00:13:35,000
So what silica does is, okay, 
this this is the same 1,000 

226
00:13:35,000 --> 00:13:37,600
employees. 
Now when the silica blockchain, 

227
00:13:39,000 --> 00:13:42,800
But the same 1000 employees need
to maintain. 

228
00:13:44,200 --> 00:13:47,200
The same copy of that book and 
that book contains all the 

229
00:13:47,200 --> 00:13:49,000
transactions that happened in 
silica. 

230
00:13:49,500 --> 00:13:54,100
But the advantage is that, if 
there's like 1,000 employees, 

231
00:13:54,300 --> 00:13:59,200
then we can have say, groups of 
100 employees in some way that 

232
00:13:59,200 --> 00:14:01,400
are working on different 
transaction. 

233
00:14:01,400 --> 00:14:06,000
So let's say employee one, until
employee 100 Works around one 

234
00:14:06,000 --> 00:14:09,100
particular set of transaction at
the same time employee 100 to 

235
00:14:09,100 --> 00:14:12,000
200 works are different set of 
transactions at the same time 

236
00:14:12,500 --> 00:14:15,900
and so on. 
So There are like 10 subgroups 

237
00:14:15,900 --> 00:14:19,100
in this government office. 
Each of them processing their 

238
00:14:19,100 --> 00:14:23,400
own set of transactions, but 
each employee ultimately needs 

239
00:14:23,400 --> 00:14:27,500
to keep track of transactions. 
That note not only their group 

240
00:14:27,500 --> 00:14:31,000
has processed but also 
transactions processed by the 

241
00:14:31,000 --> 00:14:35,200
other groups as well, right? 
So that's sort of the silica 

242
00:14:35,200 --> 00:14:39,300
model energy for the silica 
model and then you could have a 

243
00:14:39,300 --> 00:14:43,500
higher level model, which is 
like stage Harding in which 

244
00:14:44,100 --> 00:14:48,300
These 1,000 employees are again 
divided into ten groups of 100 

245
00:14:48,300 --> 00:14:50,000
each. 
They are processing their own 

246
00:14:50,000 --> 00:14:55,100
sets of transactions, but each 
employee is maintaining the 

247
00:14:55,100 --> 00:14:57,200
books. 
Each employees, maintain The 

248
00:14:57,200 --> 00:15:02,200
Ledger, or utx, a set of book, 
only for the transactions 

249
00:15:02,200 --> 00:15:04,500
process, thereby their group. 
That's right. 

250
00:15:04,500 --> 00:15:08,400
If I'm in group number seven, my
book contains only the 

251
00:15:08,800 --> 00:15:10,900
transactions processed by a 
group number 7. 

252
00:15:11,600 --> 00:15:14,000
And if someone, if my friend is 
in group number 5, if they 

253
00:15:14,008 --> 00:15:16,300
won't, they only contain 
transactions processed by group 

254
00:15:16,300 --> 00:15:20,900
number five. 
But even though my book and my 

255
00:15:20,900 --> 00:15:24,100
friends, both do not have 
intersection in the 

256
00:15:24,100 --> 00:15:26,600
transactions. 
We have processed somehow, there

257
00:15:26,600 --> 00:15:31,200
is a way of making sure that 
there is no double spending. 

258
00:15:31,200 --> 00:15:34,300
Like, I am not processing the 
transaction and he's processing 

259
00:15:34,300 --> 00:15:36,500
another transaction and they are
couldn't conflict with each 

260
00:15:36,500 --> 00:15:38,800
other. 
So that kind of thing, which is 

261
00:15:38,800 --> 00:15:41,100
the ultimate in sharding, would 
be State sharding. 

262
00:15:41,200 --> 00:15:43,800
Yes, yes. 
And silica is not. 

263
00:15:43,900 --> 00:15:46,700
Age Harding. 
It is it is that in that 

264
00:15:46,700 --> 00:15:52,300
intermediate level where I as a 
bookkeeper need to keep track of

265
00:15:52,600 --> 00:15:55,300
all of the transactions? 
Other groups apart from mine, 

266
00:15:55,300 --> 00:15:59,300
also processing. 
But per se, My computation cost 

267
00:15:59,300 --> 00:16:02,800
in verifying transactions is 
limited to those process. 

268
00:16:02,800 --> 00:16:06,300
My, by my group only Exactly, 
exactly. 

269
00:16:06,300 --> 00:16:08,600
So I think this is a very good 
analogy. 

270
00:16:09,400 --> 00:16:12,900
I just want to clarify a little 
bit on the Zilla Komodo here. 

271
00:16:13,100 --> 00:16:17,400
So I I think stay charting is a 
very interesting but you know, 

272
00:16:17,400 --> 00:16:21,100
there are many challenges where 
he discussed security redundancy

273
00:16:21,100 --> 00:16:23,100
and this, you know, cross 
Charter Communication. 

274
00:16:23,400 --> 00:16:26,300
Basically, these are main 
challenges, we should, you know,

275
00:16:26,300 --> 00:16:29,700
work very hard on to resolve, 
but at this stage, I still 

276
00:16:29,700 --> 00:16:33,600
cannot know for sure. 
Whether State shouting is the 

277
00:16:33,600 --> 00:16:38,800
ultimate You know, objective for
shouting, for example, because 

278
00:16:38,800 --> 00:16:42,500
if you look at Zilla Komodo, you
know, all these accountants 

279
00:16:42,500 --> 00:16:44,500
process. 
Different employees 

280
00:16:44,600 --> 00:16:48,300
transactions, and then 
eventually every continent still

281
00:16:48,300 --> 00:16:52,500
be updated on every other 
accountants processing process, 

282
00:16:52,500 --> 00:16:56,000
the transactions, right? 
So, but this is, this is a 

283
00:16:56,100 --> 00:16:58,800
current implementation of zedek,
I would call. 

284
00:16:59,100 --> 00:17:02,200
But the Desire with silica is 
not limited to this. 

285
00:17:02,500 --> 00:17:05,700
So for instance, to a 
jurisdiction, Issue of, you 

286
00:17:05,700 --> 00:17:08,599
know, excessive storage 
requirement. 

287
00:17:08,599 --> 00:17:12,300
So basically each accountant 
needs to know every single 

288
00:17:12,300 --> 00:17:16,800
transaction, right? 
We can reduce that because when 

289
00:17:16,800 --> 00:17:19,800
we say we don't do stage 
shouting, that means every 

290
00:17:19,800 --> 00:17:23,599
accountant needs to know the 
balance is for every employees. 

291
00:17:24,200 --> 00:17:27,200
But on the other hand, it is not
necessary. 

292
00:17:27,200 --> 00:17:31,700
That every accountant also keeps
a precise record of all the 

293
00:17:31,700 --> 00:17:34,400
transactions, right? 
So there's a difference, if you 

294
00:17:34,400 --> 00:17:37,000
look Cat-like, you theorems 
accompanies the model. 

295
00:17:37,200 --> 00:17:38,600
You just need to keep the 
balances. 

296
00:17:38,900 --> 00:17:40,500
You don't need to know all the 
history. 

297
00:17:40,900 --> 00:17:43,300
Hmm. 
Most of the applications as I 

298
00:17:43,300 --> 00:17:47,600
see only need to understand the 
final balances but some 

299
00:17:47,600 --> 00:17:52,100
applications will also need to 
you know, access all the history

300
00:17:52,100 --> 00:17:56,800
like either scan, for example. 
So in that sense we can get, you

301
00:17:56,800 --> 00:18:01,100
know, reduce the storage for 
every accountant by applying 

302
00:18:01,300 --> 00:18:03,800
another mechanism. 
Something like DHT for example, 

303
00:18:03,800 --> 00:18:08,200
you know, Hash table to allocate
you know which no to a storage 

304
00:18:08,200 --> 00:18:12,000
which historic data that's only 
about the historical, you know, 

305
00:18:12,500 --> 00:18:15,800
transactions. 
But this is sort of orthogonal 

306
00:18:15,800 --> 00:18:19,100
to the fact that every 
accountant still knows the 

307
00:18:19,100 --> 00:18:21,000
account. 
Balances 40 employees. 

308
00:18:21,500 --> 00:18:23,700
That's just one thing I want to 
add. 

309
00:18:24,900 --> 00:18:27,200
So we are that that's that's 
that's like super important. 

310
00:18:27,200 --> 00:18:31,000
So basically, like what what you
saying is like, even though if 

311
00:18:31,000 --> 00:18:35,900
I'm in like Group 1 and I need 
to know some like something 

312
00:18:35,900 --> 00:18:42,300
about group 7, there's ways in 
which I can reduce the total set

313
00:18:42,300 --> 00:18:44,400
of knowledge. 
I need about what went on in 

314
00:18:44,400 --> 00:18:47,600
Group, 7, group a. 
So instead of knowing all of the

315
00:18:47,600 --> 00:18:53,400
transactions that happen I could
just know the state of The 

316
00:18:53,400 --> 00:18:56,000
Ledger after those Transactions 
were process. 

317
00:18:56,000 --> 00:19:00,500
Exactly, exactly. 
So like one of the one of the 

318
00:19:00,700 --> 00:19:04,600
like doubts I have in my mind 
and I think this is a doubt in 

319
00:19:04,800 --> 00:19:08,200
many people's minds is if you 
look at the blockchain space 

320
00:19:08,200 --> 00:19:11,200
today, there is this two kinds 
of projects. 

321
00:19:11,200 --> 00:19:15,000
Broadly, there's like projects 
like Cosmos and polka dot. 

322
00:19:15,000 --> 00:19:17,800
There are like promising 
interoperability. 

323
00:19:18,800 --> 00:19:22,800
And now we see just the 
beginning of projects that are 

324
00:19:22,900 --> 00:19:26,200
actually offering sharding. 
So like silica is probably the 

325
00:19:26,200 --> 00:19:28,200
first at least first. 
We've been W. 

326
00:19:29,000 --> 00:19:32,000
What is the difference between 
interoperability and sharding? 

327
00:19:33,600 --> 00:19:38,100
Yeah, this is a very good 
question, you know, to me, you 

328
00:19:38,100 --> 00:19:40,700
know, I can't, I can't really 
draw an absolute line between 

329
00:19:41,000 --> 00:19:43,900
interoperability and and and 
sharing. 

330
00:19:43,900 --> 00:19:47,700
Especially if you look at things
like plasma, for example, like 

331
00:19:47,700 --> 00:19:49,900
you have a mansion and you have 
side chains. 

332
00:19:50,400 --> 00:19:55,100
So so in my view usually where 
we say shouting still about 

333
00:19:55,100 --> 00:20:00,000
shutting within one production 
so it's it's one single unified 

334
00:20:00,000 --> 00:20:03,600
blockchain. 
But yeah, I mean whether The 

335
00:20:03,600 --> 00:20:07,500
over time, we can when the 
incorporate tea party is very 

336
00:20:07,500 --> 00:20:11,700
mature, whether the boundary is 
still very clear, not I'm 

337
00:20:11,700 --> 00:20:15,600
actually not very soon. 
Yeah, I mean, I completely agree

338
00:20:15,600 --> 00:20:18,800
that, you know, you have 
different problems in the Block 

339
00:20:18,800 --> 00:20:21,600
Chain space and different 
blockchain Technologies. 

340
00:20:21,600 --> 00:20:24,200
They come up and they solve 
different problems right. 

341
00:20:24,800 --> 00:20:26,400
Now, this voltage is how do 
unify them. 

342
00:20:27,400 --> 00:20:30,100
You can't have 1 million 
blockchains and standing all 

343
00:20:30,100 --> 00:20:32,300
alone. 
You want to wait so that one 

344
00:20:32,300 --> 00:20:35,200
block in can talk to her. 
Look T at this is where this 

345
00:20:35,200 --> 00:20:38,600
interoperability Comstock and we
definitely need need a 

346
00:20:38,608 --> 00:20:42,400
technology like this so that 11 
blockchain technology can talk 

347
00:20:42,600 --> 00:20:44,700
to another Block Chain 
technology and probably have you

348
00:20:44,708 --> 00:20:48,000
know take benefits from from the
other technology I think but 

349
00:20:48,000 --> 00:20:49,600
they're completely complimentary
things right? 

350
00:20:50,000 --> 00:20:53,400
Solving let's say scalability 
problem and this are designing a

351
00:20:53,400 --> 00:20:56,300
protocol that allows you to 
interoperate all you know talk 

352
00:20:56,500 --> 00:20:58,400
communicate with other 
blockchains that kind of 

353
00:20:58,400 --> 00:21:02,700
orthogonal problems. 
So what do you mean when you say

354
00:21:02,700 --> 00:21:06,600
there are orthogonal problems 
which means that these sort of 

355
00:21:06,600 --> 00:21:09,700
two different problems 
blockages, which address KB 

356
00:21:09,700 --> 00:21:12,500
your, let's say throughput they 
want to address or they try to 

357
00:21:12,500 --> 00:21:15,000
address. 
I mean, how can you increase was

358
00:21:15,000 --> 00:21:16,000
the technology that you should 
imply? 

359
00:21:16,000 --> 00:21:17,400
What's the protocol edition of 
Y? 

360
00:21:17,600 --> 00:21:19,800
So that you can increase the 
throughput of that Block Chain? 

361
00:21:21,300 --> 00:21:24,000
So this could be a block team 
that tries to sound skill 

362
00:21:24,000 --> 00:21:26,400
ability. 
You could imagine protein such 

363
00:21:26,400 --> 00:21:30,400
as Z cash which which are mainly
focused towards privacy, they 

364
00:21:30,400 --> 00:21:32,800
want to ensure that whenever you
do a transaction, it's private 

365
00:21:32,900 --> 00:21:35,500
which could be lets say hiding 
your amount hiding who is the 

366
00:21:35,500 --> 00:21:37,600
sender, who is the recipient? 
And you know what? 

367
00:21:37,600 --> 00:21:41,700
These kind of features do they 
would go these blocks as we saw 

368
00:21:41,700 --> 00:21:44,500
different problems, right? 
One is solving scalability. 

369
00:21:44,500 --> 00:21:47,100
The other one is kind of 
attempting to solve the Privacy 

370
00:21:47,100 --> 00:21:49,400
part. 
Now, you need something in 

371
00:21:49,400 --> 00:21:51,100
between that can allow you to 
talk. 

372
00:21:51,700 --> 00:21:53,700
You know, try to communicate 
from one blocking to the other 

373
00:21:53,700 --> 00:21:56,000
one. 
So that's another time. 

374
00:21:56,000 --> 00:21:58,500
This these are the blockchain 
will be solving another problem 

375
00:21:58,900 --> 00:22:01,800
which is very, and all three are
very crucial for You know for 

376
00:22:01,800 --> 00:22:05,000
the Block in the ecosystem to 
work in a really nice sweet but 

377
00:22:05,000 --> 00:22:06,300
they all solve different 
problems. 

378
00:22:07,100 --> 00:22:09,700
It's like we imagined this 
government offices government 

379
00:22:09,700 --> 00:22:15,800
building with 1,000 employees 
working in it and scalability is

380
00:22:16,700 --> 00:22:18,800
okay. 
We have 1,000 employees. 

381
00:22:18,800 --> 00:22:23,300
How do we get them to do? 
The most work securely, right? 

382
00:22:23,400 --> 00:22:25,900
Yeah. 
And interoperability is sort of 

383
00:22:25,900 --> 00:22:30,400
the problem that, okay, let's 
say we have like, Not one, but 

384
00:22:30,400 --> 00:22:32,300
five different government 
offices. 

385
00:22:32,300 --> 00:22:34,600
Each having a thousand 
employees. 

386
00:22:35,200 --> 00:22:41,200
How do we make sure like that? 
We can have things where I can 

387
00:22:41,200 --> 00:22:45,900
submit a paper to this first 
office and then the and then you

388
00:22:45,900 --> 00:22:49,200
can Shuffle it around between 
these two different government 

389
00:22:49,200 --> 00:22:52,700
offices and do something which 
like sort of. 

390
00:22:52,700 --> 00:22:55,600
I don't know allows these 
offices to collaborate so 

391
00:22:55,600 --> 00:23:00,200
interoperability is like a 
postal system between Between 

392
00:23:00,200 --> 00:23:03,800
these offices or these 
government buildings, it's more 

393
00:23:03,800 --> 00:23:06,800
like a postal system. 
Good Postal System, where a 

394
00:23:06,800 --> 00:23:11,600
scalability is getting the 
employees in one building or in 

395
00:23:11,600 --> 00:23:16,600
one office to be able to do more
work than what they can today. 

396
00:23:18,100 --> 00:23:19,900
Yep. 
That's all understanding, of 

397
00:23:19,900 --> 00:23:24,000
course, you know, the difference
between interoperability and 

398
00:23:24,000 --> 00:23:26,800
shouting is really the 
difference between, you know, 

399
00:23:26,800 --> 00:23:28,900
whether this is the one 
government body or five 

400
00:23:28,900 --> 00:23:31,900
government bodies Okay, okay, 
makes sense. 

401
00:23:32,300 --> 00:23:36,100
So yeah, let's let's, let's go 
down to like, how silica 

402
00:23:37,100 --> 00:23:40,900
achieves this? 
This, this level of sharding. 

403
00:23:40,900 --> 00:23:44,300
So it could you give us a broad 
overview of how the network is 

404
00:23:44,300 --> 00:23:48,500
designed? 
Yeah, silica is, you know, it's 

405
00:23:48,500 --> 00:23:51,600
slightly complicated, but I 
think, I think, you know, it's 

406
00:23:51,600 --> 00:23:54,600
also very based on several 
important building blocks. 

407
00:23:55,100 --> 00:23:58,400
So number one, we need to make 
sure not. 

408
00:23:58,800 --> 00:24:01,900
Not every node can create 
arbitrary many identities 

409
00:24:01,900 --> 00:24:04,700
because you know if you can 
create arbitrary, many 

410
00:24:04,700 --> 00:24:09,200
identities in the in the 
consensus process, if you over 

411
00:24:09,200 --> 00:24:13,100
simplified as a voting, you out,
vote for the good guys but 

412
00:24:13,100 --> 00:24:18,000
that's why we need to establish.
Shhhh shhhh some way to sort of 

413
00:24:18,300 --> 00:24:22,100
that people only create proper 
identities, you know, that 

414
00:24:22,100 --> 00:24:23,600
that's something we need to do 
to solve. 

415
00:24:23,700 --> 00:24:25,700
So, that's where we have proof 
of work. 

416
00:24:26,000 --> 00:24:30,200
So, people have to do approve 
work before they can enter into 

417
00:24:30,200 --> 00:24:33,600
our consensus protocol. 
And okay, now, the question 

418
00:24:33,600 --> 00:24:36,800
comes, how do we do this? 
How do we, you know, sort of 

419
00:24:36,800 --> 00:24:39,300
enforce a proof-of-work, who are
who are check? 

420
00:24:39,500 --> 00:24:42,600
You know, who is running prove? 
Were correctly or not, correct? 

421
00:24:43,300 --> 00:24:46,500
So that's why we established 
something called directory 

422
00:24:46,500 --> 00:24:49,500
service committee. 
You know this is just 11 a.m. we

423
00:24:49,500 --> 00:24:53,300
give basically this is the 
overarching layer so we will 

424
00:24:53,300 --> 00:24:58,300
have knows competing a proof of 
work to get into this particular

425
00:24:58,300 --> 00:25:02,600
overarching committee. 
So once this committee is formed

426
00:25:02,900 --> 00:25:07,500
this committee becomes the body 
that will check other nodes. 

427
00:25:07,500 --> 00:25:10,100
So we are other notes doing 
proof of what you do check 

428
00:25:10,100 --> 00:25:11,500
whether this is the correct or 
not. 

429
00:25:11,500 --> 00:25:14,100
Correct. 
And then, Then those knows who 

430
00:25:14,100 --> 00:25:16,500
have done. 
Correct proof work will be 

431
00:25:16,500 --> 00:25:20,700
allowed to participate in the 
consensus process. 

432
00:25:21,300 --> 00:25:25,500
And this overarching directory 
service committee again, is the 

433
00:25:25,500 --> 00:25:30,100
body that sort of device or 
this, you know, good knows those

434
00:25:30,100 --> 00:25:34,900
who have passed, you w in two 
different shots and then this 

435
00:25:35,100 --> 00:25:38,600
overarching committee. 
Also decides, how do we send 

436
00:25:38,600 --> 00:25:41,900
different transactions to 
differentials for processing? 

437
00:25:43,000 --> 00:25:46,700
And eventually aggregate all the
process transactions into the 

438
00:25:46,700 --> 00:25:49,300
final block. 
So if we go back to the, you 

439
00:25:49,300 --> 00:25:53,100
know, Garmin and accountants 
model, so this is like like the 

440
00:25:53,100 --> 00:25:57,200
top governing body though. 
The the selection criteria is 

441
00:25:57,500 --> 00:26:00,100
also higher. 
And then, once this government 

442
00:26:00,100 --> 00:26:03,800
body is selected, it can, you 
know, sort of allocate different

443
00:26:03,800 --> 00:26:06,600
accountants to different 
departments, and decide which 

444
00:26:06,600 --> 00:26:11,100
department processes, which sort
of employee data. 

445
00:26:11,400 --> 00:26:14,000
So, this is a high level. 
Design of the network. 

446
00:26:14,300 --> 00:26:19,600
One key thing, we have to make 
sure this is done properly is 

447
00:26:19,600 --> 00:26:23,200
that this so-called directory 
service committee has to be 

448
00:26:23,200 --> 00:26:27,300
decentralized you know otherwise
it's very easy we just pick five

449
00:26:27,300 --> 00:26:31,400
or even 100 so called a super 
nose, we just trust them. 

450
00:26:31,400 --> 00:26:34,900
Let them decide that that in our
view is is not ideal because you

451
00:26:34,908 --> 00:26:38,300
know people can keep their power
attacking this knows if they are

452
00:26:38,300 --> 00:26:43,300
static and in this knows maybe 
corrupt in You have away. 

453
00:26:43,400 --> 00:26:45,800
So these targets service 
committee has to be 

454
00:26:45,800 --> 00:26:48,300
decentralized. 
So the election of this 

455
00:26:48,300 --> 00:26:51,100
committee self is also by proof 
of work. 

456
00:26:51,100 --> 00:26:55,400
So that's fair to everyone and 
we keep updating the composition

457
00:26:55,400 --> 00:26:57,900
of the committee, you know, to 
make sure this is the time, a 

458
00:26:57,900 --> 00:27:00,700
dynamic committee Stone. 
Like, static forever. 

459
00:27:01,400 --> 00:27:05,300
So, this is a high-level idea of
silica's network design. 

460
00:27:06,800 --> 00:27:12,300
So would you like to add 
something on it and has she just

461
00:27:12,300 --> 00:27:15,400
said you know you want to have, 
you want your networks in an 

462
00:27:15,400 --> 00:27:17,500
inviting your network right? 
You want to divide that Network 

463
00:27:17,500 --> 00:27:20,700
into some parts? 
But you need some some, you 

464
00:27:20,700 --> 00:27:24,800
know, somebody or a group that 
is going to control that in a 

465
00:27:24,800 --> 00:27:27,300
way that is going to say, you 
know, you go to this shot, you 

466
00:27:27,300 --> 00:27:29,400
go to this short, you 
graduation, right? 

467
00:27:29,400 --> 00:27:33,200
So you need a body that's going 
to run that thing, right? 

468
00:27:33,600 --> 00:27:37,600
And then that is the Discovery. 
And as you said, you don't want 

469
00:27:37,600 --> 00:27:40,100
it to be one person because then
you can attack that you wanted 

470
00:27:40,100 --> 00:27:44,200
to have because this this this 
body will have the right to say 

471
00:27:44,200 --> 00:27:47,600
you know this this this note is 
going to be signed with a shot 

472
00:27:47,700 --> 00:27:49,500
so you don't want to have an 
app. 

473
00:27:49,500 --> 00:27:52,000
You don't want to give one 
person absolute right to do 

474
00:27:52,000 --> 00:27:54,400
whatever he wants. 
And that's why you need to have 

475
00:27:54,400 --> 00:27:57,500
a sufficient number of nodes in 
that in that body me that 

476
00:27:57,500 --> 00:28:00,700
committee and then you want to 
elect them in a fair manner as 

477
00:28:00,700 --> 00:28:03,700
well. 
So, these are the crucial points

478
00:28:03,700 --> 00:28:05,800
that you have to do when you 
want to do shy. 

479
00:28:07,200 --> 00:28:09,800
So apart from the directory 
service comedy. 

480
00:28:09,800 --> 00:28:13,700
Like so we have these groups 
that are that are processing 

481
00:28:13,700 --> 00:28:17,000
transactions and this directory 
service is sort of the 

482
00:28:17,300 --> 00:28:21,700
administration that allows sort 
of these these groups to even 

483
00:28:21,700 --> 00:28:26,100
coordinate and these groups to 
inform process transactions and 

484
00:28:26,100 --> 00:28:30,400
then maybe we even even 
coordinate So that's the 

485
00:28:30,400 --> 00:28:32,900
directory service committee, 
that's in the sort of in the 

486
00:28:32,900 --> 00:28:36,200
center. 
And then how, how are these 

487
00:28:36,300 --> 00:28:40,600
groups then you have groups that
like process transactions. 

488
00:28:41,100 --> 00:28:45,100
So if I am a load, if I were new
node that is like joining this 

489
00:28:45,100 --> 00:28:47,900
network basically, like a new 
accountant on new employee 

490
00:28:47,900 --> 00:28:52,600
coming into this network, I have
the choice of either trying to 

491
00:28:52,600 --> 00:28:55,700
go and become a member of the 
directory service committee. 

492
00:28:56,700 --> 00:29:03,200
Or only become a member of one 
of these groups or become try to

493
00:29:03,200 --> 00:29:06,200
become members of like one 
group, and the directory service

494
00:29:06,200 --> 00:29:09,700
committee, right? 
Yeah, the square and sting. 

495
00:29:10,500 --> 00:29:11,600
Okay? 
Okay. 

496
00:29:11,800 --> 00:29:16,500
So so tell us like like how I 
can enter the directory service 

497
00:29:16,500 --> 00:29:19,400
committee or how I could. 
Let's say, let's say let's take 

498
00:29:19,400 --> 00:29:23,100
the earlier example, it's like 
there's a thousand nodes with 

499
00:29:23,100 --> 00:29:26,700
like ten shards or ten 
processing groups each with 100 

500
00:29:26,700 --> 00:29:29,800
nodes. 
So if I want to let's say join 

501
00:29:30,300 --> 00:29:35,300
chart. 70 group 7, how can I do 
that? 

502
00:29:35,600 --> 00:29:38,000
And then if I want to join the 
directory service, Heidi. 

503
00:29:38,000 --> 00:29:42,600
How can I do that as a new node?
So, in general of a node cannot 

504
00:29:42,600 --> 00:29:46,600
choose which Shadow, which grew 
it wants to join because that's 

505
00:29:46,600 --> 00:29:51,600
sort of decided based on some 
Randomness in the inner you 

506
00:29:51,600 --> 00:29:56,300
know, proof of work without it. 
Generates, it's designed that 

507
00:29:56,300 --> 00:29:57,900
way. 
Otherwise, if we can choose 

508
00:29:57,900 --> 00:30:00,900
which shot I want to join. 
I can you know group with all 

509
00:30:00,900 --> 00:30:03,900
these bad guys. 
Let's all go to shot Seven and 

510
00:30:03,900 --> 00:30:06,500
compromise that shot, you know, 
that's a highly right here. 

511
00:30:07,000 --> 00:30:10,300
So what? 
These at certain intervals, 

512
00:30:10,300 --> 00:30:14,000
let's say act at every two hours
roughly to us, it's based on 

513
00:30:14,000 --> 00:30:17,900
block type, of course, let's say
roughly out every two hours, the

514
00:30:18,200 --> 00:30:22,000
existing directory service 
committee will announce an open 

515
00:30:22,000 --> 00:30:25,700
competition, it will announce a 
now, there is a new 

516
00:30:25,700 --> 00:30:30,300
proof-of-work scheme, everyone 
can participate and then any no 

517
00:30:30,400 --> 00:30:33,900
no existing in this narrow or 
outside, that's fine. 

518
00:30:34,100 --> 00:30:36,900
Any node can do is I can just 
join this competition and and 

519
00:30:36,900 --> 00:30:39,800
try to solve that puzzle of this
proof of work. 

520
00:30:40,000 --> 00:30:45,100
So the winner will be sort of 
agreed on by existing members of

521
00:30:45,100 --> 00:30:48,300
this directory service committee
and then it will join this 

522
00:30:48,300 --> 00:30:51,000
committee. 
Why doing that the committee 

523
00:30:51,000 --> 00:30:56,000
will also ask the oldest member 
in the committee to live. 

524
00:30:56,900 --> 00:30:58,800
This this is the way how it's 
updated. 

525
00:30:59,900 --> 00:31:04,200
So the membership of the 
committee is like churn or the 

526
00:31:04,200 --> 00:31:07,600
change, every two hours, and 
then the process for like 

527
00:31:07,600 --> 00:31:11,000
entering the committee is to 
solve this proof of work. 

528
00:31:11,000 --> 00:31:14,300
So yes, let's say that I can 
into ours, is this before work? 

529
00:31:14,300 --> 00:31:18,700
So I participate in that puzzle.
And if I solve it, I become part

530
00:31:18,700 --> 00:31:23,100
of the committee, and then the 
oldest member of that committee 

531
00:31:23,100 --> 00:31:25,500
will end up and, uh, please, 
yes, right. 

532
00:31:25,500 --> 00:31:28,400
Imagine this is a change. 
This is, this is a blockchain as

533
00:31:28,400 --> 00:31:31,100
well. 
So, Whenever there is a winner 

534
00:31:31,100 --> 00:31:35,800
of that proof of work that name 
will be added into a new block 

535
00:31:35,900 --> 00:31:40,100
and block is appended to the 
action and then you know, if you

536
00:31:40,100 --> 00:31:44,600
go back to along the chain you 
then you can move to remove the 

537
00:31:44,600 --> 00:31:48,200
oldest block. 
So what happens in those two 

538
00:31:48,200 --> 00:31:49,700
hours. 
So let's say, like I okay, I'm a

539
00:31:49,700 --> 00:31:52,000
new node. 
I ended up I succeeded in 

540
00:31:52,000 --> 00:31:55,700
joining the DS committee and now
for the next two hours, there's 

541
00:31:55,700 --> 00:32:00,100
not going to be another another 
puzzle or another The node 

542
00:32:00,100 --> 00:32:02,700
joining us. 
So, the set of these committee 

543
00:32:02,700 --> 00:32:04,500
nodes is now known for two 
hours. 

544
00:32:05,000 --> 00:32:07,200
What do we do during this 
period? 

545
00:32:07,600 --> 00:32:10,000
So two hours is just example. 
You know, you can do it. 

546
00:32:10,000 --> 00:32:11,900
Every SRI, SRI minutes for 
example. 

547
00:32:11,900 --> 00:32:15,400
So this is the interval where we
are sort of elect a new member 

548
00:32:15,400 --> 00:32:19,700
of the DS committee. 
And then, you know, at that time

549
00:32:20,100 --> 00:32:22,900
where we after we, you know, 
elect a new member into the 

550
00:32:22,900 --> 00:32:26,300
committee, the DS committee can 
call another round of proof of 

551
00:32:26,308 --> 00:32:29,500
work to sort of incorporate a 
new nose. 

552
00:32:29,900 --> 00:32:31,700
And this process, of course, can
be done. 

553
00:32:31,700 --> 00:32:33,900
More frequently. 
We can be down, like they say, 

554
00:32:33,900 --> 00:32:35,600
everybody kind of minutes as 
well. 

555
00:32:36,000 --> 00:32:37,700
So these are parameters, who can
tune. 

556
00:32:37,800 --> 00:32:40,800
But basically the DS committee 
can announce another 

557
00:32:40,800 --> 00:32:44,400
proof-of-work scheme, to ask a 
new nose to join the or not 

558
00:32:44,400 --> 00:32:48,100
drawing the DS committee, but 
they are doing yingu that groups

559
00:32:48,700 --> 00:32:51,300
for doing consensus and process 
transactions. 

560
00:32:51,800 --> 00:32:56,200
So, this is another proposed 
scheme, we leverage on silica. 

561
00:32:56,700 --> 00:33:00,700
And this this also, you know, 
understand Molly, this is also 

562
00:33:00,700 --> 00:33:03,900
much easier because it's not 
that competitive in the DS, 

563
00:33:03,900 --> 00:33:05,900
committee. 
Election is very competitive. 

564
00:33:06,000 --> 00:33:08,000
Everyone is competing for that 
one position. 

565
00:33:08,300 --> 00:33:11,600
And this time you start, for 
example, we are accepting 20,000

566
00:33:11,600 --> 00:33:13,400
nodes. 
So, as long as you are, you 

567
00:33:13,400 --> 00:33:15,200
know, you are reasonable 
computer. 

568
00:33:15,200 --> 00:33:17,900
You should be able to join. 
And their according to the 

569
00:33:17,900 --> 00:33:23,500
result of your pewww, you will 
be shot adding two respective 

570
00:33:23,600 --> 00:33:27,900
committees and this Logic for 
shouting is decided by the DH 

571
00:33:27,900 --> 00:33:30,800
committee. 
Amrit anything to add. 

572
00:33:31,000 --> 00:33:32,900
Yeah, so that the two points 
here, right? 

573
00:33:33,300 --> 00:33:35,700
So the basic idea is that you 
want to elect members in the 

574
00:33:35,708 --> 00:33:39,300
shop and you want to elect 
members of the committee, okay? 

575
00:33:39,300 --> 00:33:41,900
At two points. 
Now the two ways of doing it, 

576
00:33:42,000 --> 00:33:45,800
what is that you liked all of 
them together and how could you 

577
00:33:45,800 --> 00:33:47,100
do that? 
You say that everybody is going 

578
00:33:47,100 --> 00:33:50,200
to solve qw and everybody's 
going to submit their peer 

579
00:33:50,200 --> 00:33:53,300
review and you could say look I 
have received all these two 

580
00:33:53,300 --> 00:33:54,600
doubles. 
I'm going to sort them out. 

581
00:33:55,600 --> 00:33:57,600
I don't think the smallest one, 
let's say, because his 

582
00:33:57,600 --> 00:34:00,100
Randomness incurably, so, you 
know, you cannot be that kind of

583
00:34:00,108 --> 00:34:01,600
expected. 
You can say that. 

584
00:34:01,600 --> 00:34:03,900
Look, I'm going to sort all of 
that and I will take the 

585
00:34:04,200 --> 00:34:06,600
smallest one and that will be 
equal to the radius 1 and the 

586
00:34:06,600 --> 00:34:09,300
rest will go to the shower is 
one way of doing it. 

587
00:34:10,600 --> 00:34:13,500
We said that, you know, we want 
to give Freedom so we want to 

588
00:34:13,507 --> 00:34:15,800
have some Freedom. 
So we said we were going to dump

589
00:34:15,800 --> 00:34:18,400
the cup of these. 
There's these two lashes would 

590
00:34:18,400 --> 00:34:22,199
say first select the DS people 
but we as member and then ask 

591
00:34:22,199 --> 00:34:25,600
them to elect the short members,
okay? 

592
00:34:25,699 --> 00:34:29,600
So that's why we have 1qw to 
elect the DS Committee Member 

593
00:34:29,900 --> 00:34:35,300
and S PW electric shock belts. 
And that is that if you decouple

594
00:34:35,300 --> 00:34:38,100
it, there you have some freedom 
in say that, you know, second 

595
00:34:38,100 --> 00:34:40,300
one can be done more faster 
than, you know, more frequently 

596
00:34:40,300 --> 00:34:42,199
than the first work and so on so
forth. 

597
00:34:42,600 --> 00:34:45,600
So that gives you Freedom about 
this Ari, how frequently you 

598
00:34:45,600 --> 00:34:49,800
want to do you, how frequently 
you want to elect the members in

599
00:34:49,808 --> 00:34:52,699
the shot and how frequently you 
want to elect a member of the 

600
00:34:52,699 --> 00:34:55,100
committee. 
And that's why we decouple the 

601
00:34:55,100 --> 00:34:57,300
proof of work. 
Okay. 

602
00:34:57,300 --> 00:34:59,700
Okay. 
So so basically, like, if I'm a 

603
00:34:59,700 --> 00:35:03,700
new node, I can first become a 
member of the shot, by solving 

604
00:35:03,700 --> 00:35:08,500
this, PO W. 
And then like this, this DS 

605
00:35:08,500 --> 00:35:13,100
committee can last for four 
listener, a longer duration, and

606
00:35:13,100 --> 00:35:15,800
in these in this longer 
duration, like, they are like 

607
00:35:15,800 --> 00:35:20,400
shorter durations wear this with
a sort of elections of of 

608
00:35:20,400 --> 00:35:22,900
puzzles that are going to 
determine who processes know, 

609
00:35:22,908 --> 00:35:28,300
who belongs to which shard And 
that is a separate proof of work

610
00:35:28,400 --> 00:35:31,700
and I could conceivably 
participate in that as well. 

611
00:35:32,400 --> 00:35:34,700
Yes. 
And like let's say, be allocated

612
00:35:34,700 --> 00:35:38,400
to short 7 and then I go and 
process transactions inside. 

613
00:35:38,400 --> 00:35:39,600
Yeah. 
Short 7. 

614
00:35:40,200 --> 00:35:43,100
And after that, the next run 
maybe your reshuffle to shark 

615
00:35:43,100 --> 00:35:46,600
fight this. 
So okay, so in this secondary 

616
00:35:46,600 --> 00:35:49,500
lecture is like, I'm in charge 
seven, first and sharp 5 and 

617
00:35:49,500 --> 00:35:52,800
shot three, and again, back to 
short, seven sharp 9. 

618
00:35:53,000 --> 00:35:54,700
So, I'm being I'm being shuffled
around. 

619
00:35:54,800 --> 00:35:56,900
Not only Me. 
But, like, all of the nodes, we 

620
00:35:56,900 --> 00:35:59,100
have been, we have been shuffled
around really well. 

621
00:36:00,100 --> 00:36:02,900
And then if I win the DS 
committee after let's say a 

622
00:36:02,900 --> 00:36:06,200
certain point of time, I will 
become the oldest member of the 

623
00:36:06,200 --> 00:36:09,800
DS committee and then I will 
have to exit that committee if I

624
00:36:09,808 --> 00:36:12,100
want to rejoin it. 
I have to have to win the 

625
00:36:12,800 --> 00:36:14,800
lottery for that dies committee 
again. 

626
00:36:15,400 --> 00:36:18,000
Yes, yes. 
So for example, winning the 

627
00:36:18,000 --> 00:36:21,000
lottery for the DS committee 
once might entitle me to be 

628
00:36:21,000 --> 00:36:26,600
there for quite a long while. 
While the oldest nodes getting 

629
00:36:26,600 --> 00:36:30,500
keep getting churned out, right?
I might be might be there. 

630
00:36:30,500 --> 00:36:33,600
Okay, okay, so that makes it. 
So let's say like a now, I was 

631
00:36:33,600 --> 00:36:38,800
assigned to short number 7, So 
and then there are like a 

632
00:36:38,800 --> 00:36:41,500
hundred other nodes that are 
assigned to short number seven 

633
00:36:41,800 --> 00:36:45,800
for the next 20 minutes. 
How do we process transactions 

634
00:36:45,800 --> 00:36:48,100
in that chart? 
How do we come to consensus 

635
00:36:48,200 --> 00:36:50,400
amongst these hundred nodes? 
Okay? 

636
00:36:50,400 --> 00:36:53,600
So what happens is that, let's 
say a user creates a certain 

637
00:36:53,800 --> 00:36:57,500
transaction. 
I goes to the network so, let's 

638
00:36:57,500 --> 00:37:00,800
suppose for the timing that it 
ends up in that shot and why, 

639
00:37:00,900 --> 00:37:04,500
why would happen is that, The 
transaction has a scent as a 

640
00:37:04,508 --> 00:37:08,200
dress, right? 
So what I might have a solution 

641
00:37:08,200 --> 00:37:10,000
to imagine that you have only 
two shots for the time being, 

642
00:37:10,000 --> 00:37:12,100
okay? 
Just to simplify the scenario. 

643
00:37:12,700 --> 00:37:16,200
So we have to only two shots and
how this transaction we go 

644
00:37:16,200 --> 00:37:19,200
through, is that the sender 
address will be will be checked.

645
00:37:19,700 --> 00:37:23,900
Let's say this last bit is 0 
would be 0 or 1 and if it is 0, 

646
00:37:23,900 --> 00:37:26,200
it will go to the first shot. 
If it is 1, it goes to the 

647
00:37:26,200 --> 00:37:29,700
second shot. 
Now, if you have more shots, of 

648
00:37:29,700 --> 00:37:31,800
course, you can do a modulo 
arithmetic and then you could 

649
00:37:31,800 --> 00:37:36,100
end up in a specific shot. 
So a user since the transaction,

650
00:37:36,200 --> 00:37:39,800
it goes to a specific shot 
depending on the Center's 

651
00:37:39,800 --> 00:37:42,500
Address. 
And then they will be a 

652
00:37:42,500 --> 00:37:45,500
consensus V code within that 
short for that for that 

653
00:37:45,500 --> 00:37:47,700
transaction. 
Aha. 

654
00:37:47,700 --> 00:37:54,500
So so basically like this is a 
way of automatically preventing 

655
00:37:54,500 --> 00:37:58,700
double Spain's, in some way 
because if I am a sender of a 

656
00:37:58,700 --> 00:38:03,400
particular transaction, my 
transaction can end up only in 

657
00:38:03,400 --> 00:38:07,800
one shot and it cannot go to to 
shards because my address is 

658
00:38:07,800 --> 00:38:12,900
sort of known and that address 
is going to address triggers a 

659
00:38:12,900 --> 00:38:18,700
deterministic computation which 
sort of Gives the output as like

660
00:38:18,700 --> 00:38:21,600
which shot this transaction 
belongs to exactly. 

661
00:38:21,600 --> 00:38:24,700
So if you're starting with 
respect to, I mean if you 

662
00:38:24,700 --> 00:38:27,100
assigning the transaction with 
respect to the sender's address,

663
00:38:27,500 --> 00:38:29,200
you have this Advantage, right? 
Yeah. 

664
00:38:29,200 --> 00:38:30,500
But let's see if you don't do 
that. 

665
00:38:30,500 --> 00:38:33,500
If you instead do with respect 
to the receivers address for 

666
00:38:33,500 --> 00:38:37,700
some reasons, you won't be able 
to preventable spec, so shorting

667
00:38:37,700 --> 00:38:40,700
with respect to send us address.
This automatically gives you a 

668
00:38:41,800 --> 00:38:45,500
double spend kind of prevention.
So this is like like like a 

669
00:38:45,508 --> 00:38:48,500
transaction partitioning scheme 
in in some way, right? 

670
00:38:48,500 --> 00:38:50,800
Like so it's like the government
office. 

671
00:38:50,800 --> 00:38:54,800
These transactions are coming in
and we need to determine which 

672
00:38:54,800 --> 00:38:58,600
group they are going to go to. 
And this is the simple heuristic

673
00:38:59,000 --> 00:39:03,300
are the other heuristics you 
considered or this one was the 

674
00:39:03,300 --> 00:39:07,000
clear winner. 
Well, I don't, I don't remember 

675
00:39:07,000 --> 00:39:09,600
if he tried anything else. 
Yeah, I think it was. 

676
00:39:09,600 --> 00:39:12,800
So obviously it will give you a 
very nice solution. 

677
00:39:12,800 --> 00:39:14,500
Why would you bother about 
thinking anything else? 

678
00:39:15,900 --> 00:39:19,400
It was suddenly clear. 
Okay so what is the consensus 

679
00:39:19,400 --> 00:39:22,900
algorithm inside one shot? 
And like what are sort of the 

680
00:39:22,900 --> 00:39:26,600
performance characteristics of 
of an individual Shard. 

681
00:39:27,600 --> 00:39:32,600
It's largely we stone-cold 
practical presenting for 

682
00:39:32,600 --> 00:39:38,000
tolerance, so pbft. 
But, you know, we understand 

683
00:39:38,000 --> 00:39:41,400
pbft performance of very 
efficiently or a small size 

684
00:39:41,400 --> 00:39:44,500
Network and they were like $100 
to Hungry nose. 

685
00:39:46,000 --> 00:39:48,800
You can generate very high 
throughput, but on the other 

686
00:39:48,800 --> 00:39:51,500
hand, when you have a larger 
Network and there were thousands

687
00:39:51,500 --> 00:39:54,700
of nodes or tens of thousands of
nodes, then the performance of 

688
00:39:54,700 --> 00:39:58,200
pbft would deteriorate. 
This is in contrast with 

689
00:39:58,300 --> 00:40:01,800
Nakamoto protocols, where you 
know, throughput is very stable 

690
00:40:03,100 --> 00:40:07,400
but there's a larger was more 
Network so but we pbft has 

691
00:40:08,200 --> 00:40:11,900
several advantages. 
So the main advantage of we like

692
00:40:11,900 --> 00:40:16,600
up you know about pbft it gives 
a finality so now Is, once you 

693
00:40:16,600 --> 00:40:20,300
agree on the block or a few 
transactions, you want to accept

694
00:40:20,300 --> 00:40:22,800
that? 
Stop, there's no way you can 

695
00:40:22,800 --> 00:40:26,900
rewrite the history. 
So what we do is we leverage 

696
00:40:26,900 --> 00:40:31,200
from some of the existing 
literature to use Collective 

697
00:40:31,300 --> 00:40:35,400
signing or schnapps signature to
address, what particular 

698
00:40:36,000 --> 00:40:42,100
performance issue in in pbft. 
Basically, in pbft is all about 

699
00:40:42,200 --> 00:40:45,000
those talking to each other 
saying, I have sick days. 

700
00:40:45,700 --> 00:40:47,900
You have seen this, okay? 
I have seen that people telling 

701
00:40:47,900 --> 00:40:50,700
me, they have seen this. 
So when they say such messages, 

702
00:40:50,900 --> 00:40:54,200
they have to use this digital 
signature to say. 

703
00:40:54,200 --> 00:40:57,400
This is really from me and 
otherwise malicious nose again. 

704
00:40:57,400 --> 00:41:01,600
Can just, you know, craft 
messages, which seemed to be 

705
00:41:01,600 --> 00:41:04,300
from all the other nodes, you 
know, that's why you need 

706
00:41:04,300 --> 00:41:06,800
digital signature. 
But then when you have a very 

707
00:41:06,800 --> 00:41:11,200
large Network, like the 1000 
knows the size of the digital 

708
00:41:11,200 --> 00:41:13,400
signature will become a 
performance bottleneck. 

709
00:41:13,500 --> 00:41:17,200
When you send this message 
across, That's why we Leverage 

710
00:41:17,200 --> 00:41:21,500
is, no signature to reduce the 
size of a signature from, you 

711
00:41:21,500 --> 00:41:25,000
know, we called over been. 
That means, you know, it grows 

712
00:41:25,000 --> 00:41:29,000
linearly to the number of nodes 
in the network to a constant. 

713
00:41:29,000 --> 00:41:34,700
Now that's a big performance. 
You know, benefit we we obtained

714
00:41:34,700 --> 00:41:38,900
from there and you know average 
over tell us more about what are

715
00:41:38,900 --> 00:41:41,200
the issues with directly 
leveraging? 

716
00:41:41,200 --> 00:41:43,500
The snow on snow signature. 
You know, there are also 

717
00:41:43,600 --> 00:41:45,400
security issues that we have to 
address. 

718
00:41:45,700 --> 00:41:48,700
With additional steps but you 
know that's that's why idea. 

719
00:41:48,900 --> 00:41:53,600
And another idea we try to 
develop in this efficient 

720
00:41:53,600 --> 00:41:58,700
consensus algorithm is actor. 
We play around different network

721
00:41:58,700 --> 00:42:02,900
topologies so you can have a 
random topology, get a tree 

722
00:42:02,900 --> 00:42:07,400
topology which is in original 
proposal of leveraging, strong 

723
00:42:07,400 --> 00:42:11,900
signature and and you know, star
topology and eventually we 

724
00:42:11,900 --> 00:42:16,000
choose the star topology as we 
think this is the most Patient a

725
00:42:16,000 --> 00:42:19,600
way to send messages across. 
So there are, you know, 

726
00:42:19,600 --> 00:42:24,700
different aspects we had to 
enhance or ppfd, and I'm re can 

727
00:42:24,700 --> 00:42:26,700
talk more about this, no 
signature partial. 

728
00:42:27,300 --> 00:42:30,600
Just before that out, I would 
like to highlight point on 

729
00:42:30,600 --> 00:42:34,100
finality, right? 
So if you compare, that's a 

730
00:42:34,400 --> 00:42:38,900
consensus protocol, Allah 
Nakamoto and pbft or PFD 

731
00:42:38,900 --> 00:42:43,800
classical be of - causes for 
God, give thee or pbft. 

732
00:42:43,800 --> 00:42:48,300
They give you finality which Is 
that if a block set of 

733
00:42:48,300 --> 00:42:50,800
transaction goes into the 
blockchain, that's fun. 

734
00:42:51,600 --> 00:42:55,300
You would have you do do need 
confirmations on top of that, it

735
00:42:55,300 --> 00:42:56,700
has many advantages. 
Why is that? 

736
00:42:56,700 --> 00:42:58,600
Because it's your final dare, 
you don't have to care about 

737
00:42:58,600 --> 00:43:00,100
confirmations because it's 
tough, right? 

738
00:43:00,200 --> 00:43:03,400
The morning goes is blotchy. 
The second guarantee that it 

739
00:43:03,400 --> 00:43:05,400
that you have is that you don't 
have to keep the previous 

740
00:43:05,400 --> 00:43:08,200
history, right? 
If you look at the Nakamoto kind

741
00:43:08,200 --> 00:43:12,700
of consensus protocol, let's say
node us to do glue and submits a

742
00:43:12,700 --> 00:43:14,900
block. 
You don't know whether it's 

743
00:43:14,900 --> 00:43:17,100
going to the final Block until 
you receive a bunch of 

744
00:43:17,107 --> 00:43:19,900
confirmations. 
So you have to store that block 

745
00:43:19,900 --> 00:43:23,000
for a while. 
While in case of pbft, kind of 

746
00:43:23,000 --> 00:43:25,300
consensus protocol. 
The moment you do, you agree on 

747
00:43:25,300 --> 00:43:28,300
a block, it had its final. 
You don't have to store blocks 

748
00:43:28,300 --> 00:43:31,000
that, you know, that's where it 
received. 

749
00:43:31,000 --> 00:43:34,400
Previously, you can just get 
your state update, your state 

750
00:43:34,400 --> 00:43:37,800
and then you are done. 
So it also tells you it to some 

751
00:43:37,800 --> 00:43:41,700
extent that stage shouting is 
not that important when you have

752
00:43:41,700 --> 00:43:44,200
finality. 
Great Point. 

753
00:43:44,200 --> 00:43:46,400
Great point. 
So the way, the way my 

754
00:43:46,400 --> 00:43:50,200
imagination is now, so let's say
like I am now a user of the 

755
00:43:50,200 --> 00:43:52,800
system. 
I'm not a node and I'm sending a

756
00:43:52,808 --> 00:43:57,100
transaction to Xin Shu. 
So I create I create my 

757
00:43:57,100 --> 00:43:59,700
transaction. 
It looks like a fairly standard 

758
00:43:59,700 --> 00:44:06,300
transaction So I'm assuming I'm 
in my head it's like any second 

759
00:44:06,300 --> 00:44:11,000
aetherium like transaction, 
there's a gas price and it's 

760
00:44:11,000 --> 00:44:15,400
like it is a my account number 
amount gas prices like code 

761
00:44:15,500 --> 00:44:20,700
stuff like that, right? 
And like data and so when I send

762
00:44:20,700 --> 00:44:24,400
this transaction to the network,
based on my address, this 

763
00:44:24,400 --> 00:44:27,900
transaction will be allocated to
one of the sharps inside. 

764
00:44:27,900 --> 00:44:32,900
That was the nodes of The Shard.
Listen to my transaction there. 

765
00:44:33,000 --> 00:44:37,100
They participate in a consensus 
algorithm so the which is like 

766
00:44:37,200 --> 00:44:39,000
practical Byzantine fault 
tolerance pace. 

767
00:44:39,000 --> 00:44:44,300
So this is the same as like 
things like Cosmos similar to 

768
00:44:44,300 --> 00:44:48,800
things like Cosmos what they're 
doing and then a block is 

769
00:44:48,800 --> 00:44:52,500
created and that block has my 
transaction in it and as long as

770
00:44:52,500 --> 00:44:55,900
soon as I see a block in that 
showered with my transaction in 

771
00:44:55,900 --> 00:45:00,500
it I'm done for for all intents 
and purposes as a user. 

772
00:45:00,500 --> 00:45:03,600
I can take that as a guarantee 
that might Actually, it's going 

773
00:45:03,600 --> 00:45:07,200
to form. 
Is that correct at The Hideaway,

774
00:45:07,200 --> 00:45:09,800
something like that. 
But, but, you know, there are 

775
00:45:09,800 --> 00:45:14,200
some, there are some pollution 
issues being accepting just 

776
00:45:14,200 --> 00:45:17,500
whatever that comes out of the 
particular shot because, you 

777
00:45:17,500 --> 00:45:20,800
know, we still need some 
verification from from the DS 

778
00:45:20,800 --> 00:45:25,500
committee because way, see this 
this block, how do we verify? 

779
00:45:25,500 --> 00:45:28,600
How do we verify that more than 
two-thirds of the know sort of 

780
00:45:28,900 --> 00:45:33,000
agreed to this is, you know, 
sort of recoil microblog Know 

781
00:45:33,008 --> 00:45:35,200
that that is the one more step 
we do in silica. 

782
00:45:35,300 --> 00:45:37,900
So what happens is that the 
moment you create a block at the

783
00:45:37,900 --> 00:45:40,800
short level, it kind of gets to 
the DS Level. 

784
00:45:41,900 --> 00:45:44,300
And then dies level. 
So every shot will propose a 

785
00:45:44,308 --> 00:45:47,600
block because it microblog. 
So the first shot will give a 

786
00:45:47,607 --> 00:45:49,500
microblog. 
The second shot will create its 

787
00:45:49,500 --> 00:45:52,300
own micro block. 
And then it, they will all go to

788
00:45:52,400 --> 00:45:55,300
the DS gallery. 
And then this DS, comedy will 

789
00:45:55,400 --> 00:45:58,300
aggregate these two micro box 
into what is called a final 

790
00:45:58,300 --> 00:46:01,400
block. 
And then final block have gives 

791
00:46:01,400 --> 00:46:04,500
you the finality. 
So there is that another one one

792
00:46:04,500 --> 00:46:08,400
level up. 
And the DS committee. 

793
00:46:08,400 --> 00:46:12,000
Once his light, it collects 
these two micro blocks and wants

794
00:46:12,000 --> 00:46:15,000
to put them in the block. 
All of the nodes of the DS 

795
00:46:15,000 --> 00:46:17,700
committee are going to verify 
all of the transactions in these

796
00:46:17,700 --> 00:46:21,300
Blocks individually and you do 
not need to know verify the 

797
00:46:21,300 --> 00:46:23,300
transactions again. 
Otherwise, you know, the DS 

798
00:46:23,300 --> 00:46:26,300
committee will become the 
bottleneck, it would defeat the 

799
00:46:26,300 --> 00:46:30,800
purpose of shouting or it or the
snow's too. 

800
00:46:31,600 --> 00:46:35,400
Is it will verify that enough 
signatures. 

801
00:46:35,500 --> 00:46:39,700
Us have sort of validated the 
correctness of this transaction 

802
00:46:39,700 --> 00:46:43,100
from that particular shot. 
So, basically if I'm a DS 

803
00:46:43,100 --> 00:46:47,100
Committee Member at that point, 
I'm like, okay I receive that I 

804
00:46:47,100 --> 00:46:49,300
received this microblog from 
short to. 

805
00:46:49,700 --> 00:46:53,100
Okay, I'm going to check which 
nodes are assigned to short to 

806
00:46:53,100 --> 00:46:55,600
in the past, okay? 
I assign these particular 50 

807
00:46:55,600 --> 00:47:00,000
nodes to that shot in the past. 
Then in the, in this block, do I

808
00:47:00,000 --> 00:47:02,700
have two thirds of the 
signatures of these 50 NOS? 

809
00:47:02,800 --> 00:47:05,700
Yes, dr. 
Turk verify is other Seeing as 

810
00:47:05,700 --> 00:47:06,400
that's correct. 
Okay. 

811
00:47:06,400 --> 00:47:08,800
These signatures there's more 
than two-thirds signature. 

812
00:47:08,800 --> 00:47:11,500
These signatures are correct. 
Okay, so I'm going to accept 

813
00:47:11,500 --> 00:47:13,900
this microblog. 
So, that's how I accepted the 

814
00:47:13,900 --> 00:47:16,800
macro block of sharp to then 
charred. 

815
00:47:16,800 --> 00:47:20,000
Then I then, similarly, I accept
the microblog of short one. 

816
00:47:20,900 --> 00:47:26,000
And then I say, okay, I am then,
I am in a state where I say in 

817
00:47:26,000 --> 00:47:29,300
principle, I agree to including 
the micro blocks of short, one 

818
00:47:29,300 --> 00:47:32,700
and two, like these two blocks 
into the blockchain. 

819
00:47:33,700 --> 00:47:37,400
And now that then then I, then 
the just, I'm just one dies 

820
00:47:37,400 --> 00:47:40,200
Committee Member and the other 
dies committee members are 

821
00:47:40,200 --> 00:47:42,100
having like, like similar 
threads. 

822
00:47:42,500 --> 00:47:45,400
So how do the dies committee 
members now? 

823
00:47:45,400 --> 00:47:48,700
Come to consensus on whether 
these two blocks are finally, 

824
00:47:48,700 --> 00:47:53,000
they actually wrong another 
round of consensus protocol So, 

825
00:47:53,000 --> 00:47:56,200
okay, to make sure the final 
block is also final, you know. 

826
00:47:56,200 --> 00:47:59,900
It's it has a finality and that 
is also a pbft. 

827
00:48:00,200 --> 00:48:02,900
Yes. 
Ha ha. 

828
00:48:03,000 --> 00:48:06,700
Okay, okay. 
So basically now now like a user

829
00:48:07,000 --> 00:48:11,500
from the user perspective, I 
send a transaction to Xin Shu 

830
00:48:12,100 --> 00:48:15,400
and I have to wait that my 
transaction gets confirmed in 

831
00:48:15,400 --> 00:48:19,500
let's say, short to and then in 
and then the block of short to 

832
00:48:19,500 --> 00:48:22,500
gets confirmed in the in, with 
the DS committee. 

833
00:48:22,500 --> 00:48:26,200
So I have to wait for these two 
confirmations, and these two 

834
00:48:26,200 --> 00:48:28,200
confirmations have like strong 
finality. 

835
00:48:28,200 --> 00:48:30,900
So, once the block is made in 
the short and in the DS 

836
00:48:30,900 --> 00:48:35,400
committee, Dang, I see these two
blocks now, my transaction is 

837
00:48:35,400 --> 00:48:39,800
confirmed and then Z which you 
can basically give me the car or

838
00:48:39,800 --> 00:48:43,900
whatever I'm looking to buy. 
So this is a four very strong, 

839
00:48:43,900 --> 00:48:47,400
you know. 
Security on the other hand for 

840
00:48:47,400 --> 00:48:51,400
applications you can you can use
some heuristics for example, 

841
00:48:51,400 --> 00:48:54,900
wave, see your transaction is 
accepted by Wang shark. 

842
00:48:56,100 --> 00:49:00,600
You may you may believe that 99%
of the chances that these this 

843
00:49:00,600 --> 00:49:03,900
transition will eventually The 
final connect a final final 

844
00:49:03,900 --> 00:49:05,000
blogger. 
You can, you give me 

845
00:49:05,000 --> 00:49:08,000
consumptions like that and for 
some application that's a 

846
00:49:08,000 --> 00:49:10,500
payment, it's fine. 
Because you just need to have 

847
00:49:10,500 --> 00:49:16,100
some reserved to, you know, 
Rectify, some of the 1% 

848
00:49:16,100 --> 00:49:20,100
exceptional cases that case so 
that can give you sort of a very

849
00:49:20,200 --> 00:49:23,400
much shorter latency. 
Cool. 

850
00:49:24,000 --> 00:49:28,800
Yeah, so at least I have a rough
idea of of silica. 

851
00:49:28,800 --> 00:49:30,800
Now, better idea of how it 
works. 

852
00:49:31,700 --> 00:49:36,800
Can you tell us like What are 
sort of the scalability 

853
00:49:36,800 --> 00:49:39,300
advantages of a design like 
that. 

854
00:49:39,300 --> 00:49:43,800
So let's say we start start with
like two shots each with 100 

855
00:49:43,800 --> 00:49:46,300
nodes or something. 
Start with like one 

856
00:49:47,500 --> 00:49:51,000
configuration and as we add 
nodes what what happens to the 

857
00:49:51,000 --> 00:49:55,400
throughput of the system? 
So you we are creating shots to 

858
00:49:55,400 --> 00:49:58,200
ensure that you can do 
transactions parallel as the 

859
00:49:58,200 --> 00:50:03,100
high-level idea, right? 
Now, you need to have more 

860
00:50:03,100 --> 00:50:06,600
shots, you want to move to, you 
know, if you were to achieve 

861
00:50:06,600 --> 00:50:08,800
better paralyzation, right? 
So let's say, if you have only 2

862
00:50:08,800 --> 00:50:12,100
shots, you can do 2 times the 
processing Affair for shots. 

863
00:50:12,100 --> 00:50:14,600
You can do four times process. 
If you have tension equal to 10 

864
00:50:14,600 --> 00:50:19,200
times processing, So, ideally, 
the two parameters here. 

865
00:50:19,200 --> 00:50:21,300
What is how many numbers of 
shot? 

866
00:50:21,300 --> 00:50:23,700
The vote. 
And what is the size of each 

867
00:50:23,700 --> 00:50:26,000
shot, right, into parameters 
Ascension? 

868
00:50:26,700 --> 00:50:30,300
Well, roughly speaking, the more
in, if you increase the number 

869
00:50:30,300 --> 00:50:32,400
of shots, you, your throughput 
will increase. 

870
00:50:32,400 --> 00:50:36,100
And that is one really a big 
benefit in silica, which is not 

871
00:50:36,100 --> 00:50:38,300
the case with many blockages 
that currently exist. 

872
00:50:38,300 --> 00:50:40,800
Which means that the more notes 
you join your network, the 

873
00:50:40,800 --> 00:50:42,200
better throughput, you will get 
out. 

874
00:50:42,900 --> 00:50:46,600
Okay, this is this is and that's
roughly linear outside. 

875
00:50:48,300 --> 00:50:53,300
In the number of shots. 
Now, if you look at the other 

876
00:50:53,300 --> 00:50:55,900
other metric, which is how many 
nodes you should have in the 

877
00:50:55,900 --> 00:50:57,800
shot, that's not the very 
crucial point. 

878
00:50:58,100 --> 00:51:01,200
For many reasons, one specific 
reason is security, right? 

879
00:51:01,800 --> 00:51:04,300
So imagine the sharp will you 
just put one single node? 

880
00:51:04,900 --> 00:51:06,500
Well, then it becomes a 
centralized infrastructure, 

881
00:51:06,500 --> 00:51:08,800
right? 
Then this shot gets to decide 

882
00:51:08,800 --> 00:51:11,300
based on section 2, except which
transaction subject. 

883
00:51:12,700 --> 00:51:15,600
So, you want to have more number
of nodes in the neck in each 

884
00:51:15,600 --> 00:51:17,600
short cannot be cannot be just 
one. 

885
00:51:18,300 --> 00:51:19,900
Now, the question is, what is 
the ideal number? 

886
00:51:20,300 --> 00:51:24,300
Okay, I mean that sometimes I 
tell you that I mean the more 

887
00:51:25,400 --> 00:51:29,400
the more notes you add in the in
the in the in in short the more 

888
00:51:29,400 --> 00:51:32,000
secure you become against 
Byzantine adversaries. 

889
00:51:33,500 --> 00:51:36,400
So I mean gives you probability.
So more notes, you have the 

890
00:51:36,400 --> 00:51:38,100
property will be decrease 
exponentially. 

891
00:51:38,900 --> 00:51:41,700
So we came up with so if you 
look at that formula you can 

892
00:51:41,700 --> 00:51:43,600
give will have this exponential 
kind of curve. 

893
00:51:43,900 --> 00:51:46,300
I will tell you that, you know, 
roughly 600 nodes gives you a 

894
00:51:46,300 --> 00:51:49,600
one over million kind of. 
Yeah, kind of like the 

895
00:51:49,600 --> 00:51:53,300
probability. 
So you'd have roughly around 600

896
00:51:53,300 --> 00:51:56,400
to 800 notes in each chart to 
guarantee security. 

897
00:51:56,800 --> 00:51:58,700
But if you need more, if you 
need better parallel 

898
00:51:58,700 --> 00:52:03,500
sterilization, you need more 
shots, more of such numbers. so,

899
00:52:03,600 --> 00:52:09,900
sort of the basic problem is Is 
is it is almost a problem of 

900
00:52:09,900 --> 00:52:15,400
sampling and N like statistics. 
So as I don't remember, the name

901
00:52:15,400 --> 00:52:18,800
of this exact problem, but the 
problem is something like you 

902
00:52:18,800 --> 00:52:22,600
have, I don't know. 
You have 10,000 instances of, 

903
00:52:22,600 --> 00:52:25,400
like, I don't know, you have 
this. 

904
00:52:25,400 --> 00:52:27,700
Let's say, let's say we talked 
about people, right? 

905
00:52:27,800 --> 00:52:31,400
All of us have different heights
and let's say there is this like

906
00:52:31,400 --> 00:52:34,100
group of ten thousand people 
now? 

907
00:52:35,800 --> 00:52:39,100
Out of this group of 10,000. 
People are going to select, 

908
00:52:39,600 --> 00:52:42,700
let's say like subgroups of 100 
people. 

909
00:52:42,700 --> 00:52:45,600
I'm going to sample groups of 
100 people. 

910
00:52:46,600 --> 00:52:50,100
Then if the, if the average 
height of this, this group of 

911
00:52:50,100 --> 00:52:56,800
10,000 people is, I don't know, 
1.8 meters and if I'm sampling, 

912
00:52:56,800 --> 00:52:59,100
like, I'm taking out only 
hundred people and Min when 

913
00:52:59,100 --> 00:53:01,600
measuring the average heights of
these hundred people. 

914
00:53:02,400 --> 00:53:05,600
Then there is actually a chance 
that I might come across groups 

915
00:53:07,400 --> 00:53:10,000
which whose average height might
be two meters, right? 

916
00:53:10,000 --> 00:53:13,100
Even though the even though the 
population of those population, 

917
00:53:13,100 --> 00:53:17,200
average of Vista, 10,000 1.8 
meters Randomness mind. 

918
00:53:17,200 --> 00:53:20,800
And sure that I might select a 
group of these hundred people 

919
00:53:21,100 --> 00:53:23,800
and the average height maybe two
meters, that can happen, right? 

920
00:53:23,800 --> 00:53:27,300
So my sample might not be 
representative of the larger 

921
00:53:27,300 --> 00:53:33,100
group If the sample is too small
and as the sample size becomes 

922
00:53:33,100 --> 00:53:37,900
bigger, when I go from 100 to 
200, 300 to 400, I will become 

923
00:53:37,900 --> 00:53:41,300
more and more representative of 
the bigger group. 

924
00:53:41,800 --> 00:53:45,900
So, in some senses, I feel the 
formula you're referring to the 

925
00:53:45,900 --> 00:53:47,600
exponential curve. 
You're referring to is a 

926
00:53:47,600 --> 00:53:52,000
reflection of this fact that we 
are assuming at some level that 

927
00:53:52,000 --> 00:53:56,400
once the nodes solve proof of 
work, that there is a certain 

928
00:53:56,400 --> 00:54:00,900
fraction of Byzantine nodes in 
I'd them but we have like, let's

929
00:54:00,900 --> 00:54:04,400
say, let's say we have two 
thousand nodes and some fraction

930
00:54:04,400 --> 00:54:08,200
of it is Byzantine, 20% of which
is Byzantine, but when you want 

931
00:54:08,200 --> 00:54:12,600
to compose a shower we want to 
sample this group of two 

932
00:54:12,600 --> 00:54:15,200
thousand nodes, create a subset 
of it. 

933
00:54:15,600 --> 00:54:19,600
So if we create a subset with 
only 100 nodes there is this 

934
00:54:19,600 --> 00:54:23,600
there's a higher chance that if 
say two hundred nodes are 

935
00:54:23,600 --> 00:54:25,400
Byzantine inside those two 
thousand. 

936
00:54:25,400 --> 00:54:29,000
If you are sampling groups of 
just 100 nodes, Is a high chance

937
00:54:29,000 --> 00:54:33,200
that we might encounter a group 
in which like 9090 nodes are 

938
00:54:33,207 --> 00:54:36,300
Byzantine, like you might create
a shower with 90 Byzantine nodes

939
00:54:36,300 --> 00:54:40,200
and 10 honest nodes, but if we 
increase the size of the sample 

940
00:54:40,200 --> 00:54:47,200
from, let's say 100 to 500, then
this we are somehow like because

941
00:54:47,200 --> 00:54:49,900
we are sampling a larger set. 
Now we're taking a larger set 

942
00:54:49,900 --> 00:54:54,300
out of this 2000. 
If the bigger set of 2000 is 

943
00:54:54,300 --> 00:54:58,700
majority honest, it increases 
the chance that my set of Also 

944
00:54:58,700 --> 00:55:01,500
going to be majority on this, 
it's something like that, right?

945
00:55:01,700 --> 00:55:06,200
It resonates very, very aging 
about in the extreme case, if we

946
00:55:06,200 --> 00:55:09,800
have 1,000 nodes and then you 
know, we only have one shark. 

947
00:55:10,200 --> 00:55:12,600
Let's say let's say we just make
an assumption that it is 

948
00:55:12,600 --> 00:55:16,400
original $1000, only have, you 
know, less than one-third of 

949
00:55:16,400 --> 00:55:20,600
presenting and that it's 
actually 100% true. 

950
00:55:20,600 --> 00:55:24,500
That this shot has less than 
1,000 one set of the nodes. 

951
00:55:24,500 --> 00:55:26,300
Representing by that's extreme 
case. 

952
00:55:26,500 --> 00:55:31,000
We don't, we don't need 100%. 
We need 99.99999% him, something

953
00:55:31,000 --> 00:55:32,200
like that. 
That's what we do. 

954
00:55:33,300 --> 00:55:35,500
Okay. 
So there are a few distinct. 

955
00:55:35,500 --> 00:55:39,700
You have derived from something 
like this is a shower door to 

956
00:55:39,700 --> 00:55:43,000
lie between 600 and 800 members.
Yes. 

957
00:55:43,300 --> 00:55:49,800
And and then as, as nodes are 
added, we can we can increase 

958
00:55:49,800 --> 00:55:52,400
the number of shards in right 
some way. 

959
00:55:53,300 --> 00:55:57,100
Okay, so as I'm aware like 
silica already has a private 

960
00:55:57,100 --> 00:56:00,300
test net running, right? 
So first tell us like what are 

961
00:56:00,300 --> 00:56:04,000
sort of the performance 
characteristics of this private 

962
00:56:04,000 --> 00:56:08,600
test name. 
So you know, at this stage it's 

963
00:56:08,600 --> 00:56:11,300
especially Ronnie or AWS ec2 
Cloud. 

964
00:56:11,300 --> 00:56:15,100
So we basically host a 
particular category of instances

965
00:56:15,800 --> 00:56:19,800
the virtual machines everyone 
virtual machine is running as a 

966
00:56:19,808 --> 00:56:24,300
note inside our test net and 
then I think, two weeks ago, 

967
00:56:24,600 --> 00:56:29,500
three weeks ago when we scaled 
up to about 3,600 knows, you 

968
00:56:29,500 --> 00:56:33,000
know, test then we could 
retrieve, we could achieve a 

969
00:56:33,500 --> 00:56:37,400
peak capacity of Of those to 
2500 connections. 

970
00:56:37,400 --> 00:56:40,300
A second. 
So you know the interesting 

971
00:56:40,300 --> 00:56:44,900
thing is when we compare the 
results with the 3600 nose, to, 

972
00:56:44,900 --> 00:56:50,000
let's say 1200 nodes. 
We really see a linear curve in 

973
00:56:50,000 --> 00:56:52,800
terms of throughput growth. 
So that basically sort of 

974
00:56:52,800 --> 00:56:56,000
validated our original 
hypothesis. 

975
00:56:56,000 --> 00:56:59,300
That was reported were leading a
group that's interesting. 

976
00:56:59,500 --> 00:57:04,400
And to me 3600 nose is still a 
very small Network. 

977
00:57:04,900 --> 00:57:09,300
Do today's popular public 
blockchains and we really want 

978
00:57:09,300 --> 00:57:13,800
to take this as a stock. 
And we want to further grow that

979
00:57:14,100 --> 00:57:18,900
our projection is where we have 
to let's say 20,000 knows. 

980
00:57:19,200 --> 00:57:23,100
We should be able to reach about
8,000 to 10,000 transaction the 

981
00:57:23,100 --> 00:57:27,000
second and this is not to say 
that it's as straight forward. 

982
00:57:27,000 --> 00:57:29,700
As you know, tomorrow, we just 
get more money and expand our 

983
00:57:30,000 --> 00:57:32,400
test and it's not going to be 
that straightforward. 

984
00:57:32,900 --> 00:57:36,300
I think we expect more so Of 
technical Innovation. 

985
00:57:36,300 --> 00:57:38,200
We have to do along the way to 
achieve that goal. 

986
00:57:39,800 --> 00:57:43,100
Okay cool. 
So I think so one of the final 

987
00:57:43,100 --> 00:57:46,800
questions I have and there's a 
lot to talk about the sharding 

988
00:57:46,800 --> 00:57:52,000
model, certainly, it's like 
complex technology, but we have 

989
00:57:52,000 --> 00:57:54,900
to go cover the other 
interesting part of silica which

990
00:57:54,900 --> 00:57:57,500
is the Smart contract. 
Language design, we have limited

991
00:57:57,500 --> 00:58:01,200
time. 
But before we get there, how, 

992
00:58:01,400 --> 00:58:04,700
what is the incentive structure 
for for all of these nodes, 

993
00:58:04,700 --> 00:58:09,200
including being a DS committee 
node and being a node processing

994
00:58:09,200 --> 00:58:10,800
time? 
Actions in this chart. 

995
00:58:11,300 --> 00:58:16,700
Okay, so so we should look at a 
little bit about why incentive 

996
00:58:16,700 --> 00:58:19,200
structure should be different. 
The first place compared to 

997
00:58:19,200 --> 00:58:22,500
let's say Bitcoin or or incident
and the reason is the consensus 

998
00:58:22,500 --> 00:58:25,300
protocol. 
So if you look at the Bitcoin or

999
00:58:25,300 --> 00:58:28,300
Ori theorems Nakamoto classes 
for call, there is one leader 

1000
00:58:28,300 --> 00:58:31,600
and he proposes a Blog so he 
kind of does the hard work, 

1001
00:58:31,800 --> 00:58:33,600
right? 
So he gets a reward. 

1002
00:58:35,200 --> 00:58:39,000
No, it in a pbft kind of study 
notes, which are there in the 

1003
00:58:39,000 --> 00:58:41,100
shot. 
They all together work is signed

1004
00:58:41,100 --> 00:58:43,400
transaction. 
They do or together work and 

1005
00:58:43,400 --> 00:58:47,600
then they proposed a block So 
the point is, you know, you have

1006
00:58:47,600 --> 00:58:49,000
to be, you have to do different,
right? 

1007
00:58:49,100 --> 00:58:51,900
It cannot be just just that way.
The classical way. 

1008
00:58:52,400 --> 00:58:56,100
So what we see what we came up 
is, is that if you were to give 

1009
00:58:56,100 --> 00:59:00,500
a reward, let's give reward to 
the leader, in the DS comedy, 

1010
00:59:01,300 --> 00:59:04,200
and the leader in each chart. 
Okay. 

1011
00:59:05,300 --> 00:59:09,300
So for every microblog proposed 
by each chart, you will take the

1012
00:59:09,300 --> 00:59:11,100
reward value divided into these 
people. 

1013
00:59:11,600 --> 00:59:15,300
So all the leaders across charts
and the and the leader in the DS

1014
00:59:15,300 --> 00:59:18,600
coming. 
Now, what will you might go with

1015
00:59:18,600 --> 00:59:20,100
this model? 
Is that what you might do with 

1016
00:59:20,100 --> 00:59:22,400
this model? 
Is that after a particular 

1017
00:59:22,400 --> 00:59:26,600
period of time, you could change
the leader in each chart type. 

1018
00:59:26,800 --> 00:59:28,600
So this will help you if you 
work, so these are leader and 

1019
00:59:28,600 --> 00:59:31,400
then you can replace that you 
have in some other you And then,

1020
00:59:31,400 --> 00:59:33,600
you know, you can eventually be 
able, you would be eventually be

1021
00:59:33,600 --> 00:59:36,600
able to devote every single 
member in the shot because every

1022
00:59:36,600 --> 00:59:38,300
single member will eventually 
become a hero. 

1023
00:59:38,800 --> 00:59:41,300
So that's the, that's the 
incentive incentive model. 

1024
00:59:42,600 --> 00:59:44,200
Okay. 
Okay, so yeah. 

1025
00:59:44,200 --> 00:59:48,700
So let me the only leaders of 
these blocks are able to get 

1026
00:59:48,700 --> 00:59:50,900
rewards. 
So, if I'm a new node joining 

1027
00:59:50,900 --> 00:59:56,700
in, if I solve the proof of work
become member of the DS 

1028
00:59:56,700 --> 00:59:59,300
committee, For the first few 
blocks. 

1029
00:59:59,300 --> 01:00:03,100
After member, I might not be the
leader and I'll not make money 

1030
01:00:03,100 --> 01:00:07,000
at the air at that time. 
But then eventually it's like 

1031
01:00:07,100 --> 01:00:10,300
around, it's like a round table 
is like, will circulate back. 

1032
01:00:10,300 --> 01:00:13,600
And I will become the leader. 
And when I create a blog, I'm 

1033
01:00:13,600 --> 01:00:16,600
going to make money as a member 
of the DS committee. 

1034
01:00:17,200 --> 01:00:20,500
And similarly, if I have a new 
node joining and I end up being 

1035
01:00:20,500 --> 01:00:24,600
assigned to short 7 may not make
any money because other people 

1036
01:00:24,600 --> 01:00:27,900
are proposing blocks. 
But then my time to propose, 

1037
01:00:28,000 --> 01:00:30,700
those a block is going to come 
and I will be deleted and at 

1038
01:00:30,700 --> 01:00:34,400
that point I'll make money. 
So it is this model has one 

1039
01:00:34,400 --> 01:00:37,600
advantage is is that you will 
have low variance, right? 

1040
01:00:38,000 --> 01:00:40,700
So in in Nakamoto, kind of 
consensus protocol, you are kind

1041
01:00:40,700 --> 01:00:44,300
of competing with everybody. 
So you know, after after a few, 

1042
01:00:44,600 --> 01:00:48,800
you know, few time interval you 
will probably have a chance to 

1043
01:00:48,800 --> 01:00:50,700
get the become the leader and 
then you will get it. 

1044
01:00:51,000 --> 01:00:53,200
We get the reward here, it's 
different because the moment you

1045
01:00:53,200 --> 01:00:56,000
get into shot and if you stay 
there, you will have, you will 

1046
01:00:56,000 --> 01:00:59,100
have the votes. 
And it's guaranteed. 

1047
01:00:59,800 --> 01:01:01,600
Hmm. 
Very interesting ways. 

1048
01:01:01,800 --> 01:01:07,300
So in terms of like this whole 
sharding scheme, what are the 

1049
01:01:07,300 --> 01:01:10,900
largest points of uncertainty 
for your team? 

1050
01:01:10,900 --> 01:01:17,400
Like things that like design 
choices or places where you 

1051
01:01:17,400 --> 01:01:20,400
don't understand the choices you
have made and things might go 

1052
01:01:20,400 --> 01:01:22,500
wrong. 
Hmm. 

1053
01:01:22,900 --> 01:01:26,000
That's a very good question. 
I think, I think at the high 

1054
01:01:26,000 --> 01:01:31,200
level, I would think this is 
shotting scheme is relatively 

1055
01:01:31,800 --> 01:01:36,400
sort of validated. 
I would say you know the most 

1056
01:01:36,400 --> 01:01:39,200
challenging parties when we 
skill further I think you know 

1057
01:01:39,200 --> 01:01:44,700
now it's 3,600 knows. 
I don't think you know, double 

1058
01:01:44,900 --> 01:01:49,400
that size will be an issue, but 
if we really go to something 

1059
01:01:49,400 --> 01:01:52,800
like 15, Thousand or Twenty 
Thousand. 

1060
01:01:52,900 --> 01:01:55,700
So we may run into some 
bottlenecks which are not 

1061
01:01:55,700 --> 01:01:58,600
obvious at this moment. 
So that's something. 

1062
01:01:58,600 --> 01:02:01,700
We have to redo the experiment 
because many things can become 

1063
01:02:01,700 --> 01:02:05,100
put on a like, validation of 
connections can become poorer, 

1064
01:02:05,100 --> 01:02:08,300
neck, sending the micro blocks 
or sending the final blocks 

1065
01:02:08,300 --> 01:02:11,300
know, all these things. 
May become a performance issue. 

1066
01:02:11,300 --> 01:02:15,800
So that's where we need to 
experiment and then starting 

1067
01:02:15,800 --> 01:02:18,900
further, try to figure out a 
better way to do things, so 

1068
01:02:18,900 --> 01:02:22,000
that's my expectation. 
Emory. 

1069
01:02:22,200 --> 01:02:25,000
Yes, I'm it's very similar to 
the point that he discussed, 

1070
01:02:25,300 --> 01:02:30,100
which is you, you start with the
smallest shot that you can have.

1071
01:02:30,200 --> 01:02:33,200
Let's say with 600 notes because
going below, that you will have 

1072
01:02:33,500 --> 01:02:35,900
security risks to start with 
start. 

1073
01:02:36,300 --> 01:02:38,700
And the more notes come in, you 
keep on increasing the number of

1074
01:02:38,700 --> 01:02:41,500
shots. 
At some point of time, you have 

1075
01:02:41,500 --> 01:02:44,300
to come back and say, you know, 
now, I probably have to increase

1076
01:02:44,300 --> 01:02:46,900
the shot size and I should not 
increase. 

1077
01:02:46,900 --> 01:02:50,900
Let's say, Richard number for 
instance, So, it's not very 

1078
01:02:50,900 --> 01:02:55,900
clear right now when, and at 
what extent we should, we should

1079
01:02:55,900 --> 01:02:59,800
make those choices. 
So it's like the trade-off 

1080
01:03:00,200 --> 01:03:04,400
between like, sort of having 
larger shards and higher 

1081
01:03:04,400 --> 01:03:06,200
security. 
So the trade-off between like 

1082
01:03:06,200 --> 01:03:10,400
security, throughput expressed, 
as selecting the number of 

1083
01:03:10,400 --> 01:03:12,800
shards and nodes in a shot, 
right? 

1084
01:03:12,800 --> 01:03:16,400
Like you're trying to optimize 
both security and throughput and

1085
01:03:16,400 --> 01:03:19,200
the levers that you can pull the
number of shirts that are going 

1086
01:03:19,200 --> 01:03:23,600
to be there in your network and 
the nodes that are going to be 

1087
01:03:23,600 --> 01:03:26,500
there / chart. 
So how do you tweak these two 

1088
01:03:26,500 --> 01:03:30,800
parameters to get an Optimal of 
security and throughput is the 

1089
01:03:30,800 --> 01:03:33,500
other point is, how many nodes 
can be really support? 

1090
01:03:33,500 --> 01:03:35,500
That's not the question. 
We cannot support it, say, 1 

1091
01:03:35,500 --> 01:03:39,900
million nodes, it's not, it 
would work for any network, it 

1092
01:03:39,900 --> 01:03:41,800
would work. 
If you let's say, if you look at

1093
01:03:41,800 --> 01:03:44,800
Bitcoin series if they have 1 
million notes, one day for some 

1094
01:03:44,800 --> 01:03:48,300
reasons, then you will have to 
propagate each block to the 

1095
01:03:48,300 --> 01:03:49,700
entire network and that will 
take time. 

1096
01:03:50,500 --> 01:03:53,800
And if you don't give if you 
interblock time is not in a 

1097
01:03:53,800 --> 01:03:56,100
sufficiently large, then you 
will have folks. 

1098
01:03:57,100 --> 01:03:58,600
Right? 
Because, you know, some, some 

1099
01:03:58,600 --> 01:04:01,200
people won't be seeing the right
block and then you would they be

1100
01:04:01,200 --> 01:04:03,600
mining on a different block and 
then, you know, you will have 

1101
01:04:03,600 --> 01:04:06,100
folks. 
So the, what would be the 

1102
01:04:06,100 --> 01:04:08,600
maximum Network side that we 
should support is not very 

1103
01:04:08,600 --> 01:04:15,600
clearly hold. 
So silicon has other big 

1104
01:04:15,600 --> 01:04:20,400
innovation could be in the in 
the Paradigm of how smart 

1105
01:04:20,400 --> 01:04:24,100
contracts are executed inside 
silica and how they are 

1106
01:04:24,100 --> 01:04:27,600
programmed. 
So give us an overview of your 

1107
01:04:28,600 --> 01:04:34,300
work and AIMS in in that space. 
So we would like to have a smart

1108
01:04:34,300 --> 01:04:36,200
contract language. 
First of all, it is, will Design

1109
01:04:36,200 --> 01:04:38,800
principle. 
And that's why we started with 

1110
01:04:38,800 --> 01:04:42,000
something new and that is that 
we want to have a language that 

1111
01:04:42,000 --> 01:04:45,400
is easy to reason about 
consuming the fact that we have 

1112
01:04:45,400 --> 01:04:47,900
all kind of issues with 
different kind of spark 

1113
01:04:47,900 --> 01:04:50,400
contracts. 
So we need, we need a language 

1114
01:04:50,400 --> 01:04:53,500
that allows you to reason 
formerly which you could say, 

1115
01:04:53,500 --> 01:04:56,500
you know, if you run this 
contract, you're only going to 

1116
01:04:57,000 --> 01:04:58,700
see this. 
This of this kind of behavior, 

1117
01:04:58,700 --> 01:05:02,000
not something else. 
That's, that's the high level 

1118
01:05:02,000 --> 01:05:04,400
idea. 
And how would you do that? 

1119
01:05:04,400 --> 01:05:06,800
Is is tricky. 
The reason is that if you want 

1120
01:05:06,800 --> 01:05:08,900
to do, Do, if you want to give 
very strong properties. 

1121
01:05:08,900 --> 01:05:10,900
If you're approved, very strong 
properties about about your 

1122
01:05:10,900 --> 01:05:15,400
program, it cannot be a very, it
cannot be a very full fledged 

1123
01:05:15,400 --> 01:05:17,900
language because then it becomes
very complicated reasonable. 

1124
01:05:18,600 --> 01:05:20,700
So you kind of you want to have 
a language? 

1125
01:05:20,700 --> 01:05:23,800
That's kind of You know, it's 
not two incomplete. 

1126
01:05:23,800 --> 01:05:27,000
For instance, it could be it 
could be restrictive set but 

1127
01:05:27,000 --> 01:05:29,800
it's, you know, but but which 
would allow you to have formal 

1128
01:05:29,800 --> 01:05:34,400
proofs but should be expressive 
enough that should allow you to,

1129
01:05:34,400 --> 01:05:36,000
you know, design, interesting 
contracts. 

1130
01:05:36,600 --> 01:05:39,500
This is this is the high-level 
principle that we will follow 

1131
01:05:40,600 --> 01:05:44,100
and like so your working life 
smart contract language is it 

1132
01:05:44,100 --> 01:05:47,700
like early or do you have some 
some kind of specification and 

1133
01:05:47,700 --> 01:05:50,800
implementation of a language. 
So we don't have a specific 

1134
01:05:50,800 --> 01:05:53,800
issue right now. 
We are currently writing It by 

1135
01:05:53,800 --> 01:05:57,500
the end of this month, we will 
have a formal document which 

1136
01:05:57,500 --> 01:06:00,500
would say what exactly a program
in our smart contraction would 

1137
01:06:00,500 --> 01:06:05,000
look like and what kind of 
properties you could prove on 

1138
01:06:05,000 --> 01:06:09,700
those kind of contracts? 
So one interesting thing is, you

1139
01:06:09,700 --> 01:06:14,400
know, we also want to balance 
between, you know, the security 

1140
01:06:14,400 --> 01:06:19,100
of the smart contracts and sort 
of sort of program ability. 

1141
01:06:19,400 --> 01:06:22,900
So if we ask programmers today 
to write, that kind of 

1142
01:06:22,900 --> 01:06:26,000
Automotive style language, it's 
very tough. 

1143
01:06:26,000 --> 01:06:27,800
You know, the learning curve 
will be very stiff. 

1144
01:06:28,000 --> 01:06:33,000
So that's why we will try to 
develop solidarity like syntax 

1145
01:06:33,200 --> 01:06:37,900
as well, for for programmers, so
they can still write smart. 

1146
01:06:38,000 --> 01:06:42,700
Tracks being the familiar 
language like today and we will 

1147
01:06:42,700 --> 01:06:46,100
have a compiler and sort of 
compiled that kind of syntax 

1148
01:06:46,100 --> 01:06:49,900
into this, these actual language
for smoking chart and of course,

1149
01:06:49,900 --> 01:06:53,900
we will not be able to support 
100% of solidity syntax. 

1150
01:06:54,200 --> 01:06:57,200
And we may add on a little bit 
but it's largely like that. 

1151
01:06:58,600 --> 01:07:03,100
So I almost feel like we need a,
we need a separate episode on 

1152
01:07:03,100 --> 01:07:06,000
the smart contract language when
when you're further along. 

1153
01:07:06,600 --> 01:07:07,900
Yeah, we agree. 
Yeah. 

1154
01:07:08,000 --> 01:07:08,900
Yeah. 
Yeah. 

1155
01:07:08,900 --> 01:07:10,900
This is topic. 
You know by yourself. 

1156
01:07:11,900 --> 01:07:14,400
Yeah. 
Why is that cause like yeah I 

1157
01:07:14,400 --> 01:07:16,600
think we are we are towards the 
towards the end of the 

1158
01:07:16,600 --> 01:07:19,300
recording. 
So I think we let's reschedule 

1159
01:07:19,300 --> 01:07:23,200
other one for specifically, for 
the smart contract execution, 

1160
01:07:23,200 --> 01:07:26,800
environment and languages. 
But before we end up for today, 

1161
01:07:27,700 --> 01:07:32,700
so Silica in network has had its
own cryptocurrency, which is, 

1162
01:07:32,700 --> 01:07:35,300
which is xilinx. 
I'd like to know your plans 

1163
01:07:35,300 --> 01:07:38,700
about ceilings. 
And when do you think people 

1164
01:07:38,700 --> 01:07:41,100
will get chillings in their own 
hands? 

1165
01:07:42,300 --> 01:07:46,100
Yeah, we're you should ceilings 
as a utility token. 

1166
01:07:46,100 --> 01:07:49,700
So that means, you know, how 
does the Brazilians were be able

1167
01:07:49,700 --> 01:07:55,800
to send traductions wrong, smart
contracts on our platform and we

1168
01:07:55,800 --> 01:07:58,600
are planning to run a public 
contribution. 

1169
01:07:59,200 --> 01:08:02,400
A token generation event. 
So the exact date has not been 

1170
01:08:02,400 --> 01:08:06,200
fixed at this moment, so it 
could be as early as end of 

1171
01:08:06,200 --> 01:08:08,800
November or it could be as late 
as, you know, let's say early 

1172
01:08:08,800 --> 01:08:10,800
jet. 
So, you know, that's the rough a

1173
01:08:10,800 --> 01:08:14,000
timeline where We're still 
thinking about this moment at 

1174
01:08:14,000 --> 01:08:17,100
this stage, we're running early 
contribution Rock. 

1175
01:08:17,200 --> 01:08:21,899
So some people really show very 
strong interest to our project. 

1176
01:08:21,899 --> 01:08:24,500
And then, you know, we try to 
work with them to get their 

1177
01:08:24,500 --> 01:08:28,700
support, in terms of funding, in
terms of Mining, and in terms of

1178
01:08:28,700 --> 01:08:30,899
application development, you 
know, various things. 

1179
01:08:31,399 --> 01:08:35,700
So that's that's where we are. 
In terms of fundraising, Okay. 

1180
01:08:36,100 --> 01:08:40,899
Do you have any any details on? 
Like what, what kind of emission

1181
01:08:40,899 --> 01:08:44,600
curve silica will end up having 
how many tokens will be issued 

1182
01:08:44,600 --> 01:08:49,300
in the public contribution? 
And then how will the network go

1183
01:08:49,300 --> 01:08:52,500
from there? 
So I think I can give a rough 

1184
01:08:53,000 --> 01:08:57,700
idea of the total allocation and
then a KU Library further on the

1185
01:08:57,899 --> 01:09:01,100
emission specifically for the 
mining rewards. 

1186
01:09:01,500 --> 01:09:05,600
So, you know, as we already 
mentioned silica stay Energy has

1187
01:09:05,600 --> 01:09:09,100
a feature, we have more miners 
in the network, will be able to 

1188
01:09:09,100 --> 01:09:11,200
process more transactions, every
second. 

1189
01:09:11,399 --> 01:09:14,100
So that's why designing. 
Our token structure? 

1190
01:09:14,100 --> 01:09:19,200
We give - slightly heavy pie. 
So basically, we plan to give at

1191
01:09:19,200 --> 01:09:24,100
least 40% of our total focus. 
Apply to mining rewards over 

1192
01:09:24,100 --> 01:09:28,600
let's say 10 years of time and 
then you know we will give our 

1193
01:09:28,600 --> 01:09:32,500
supporters either in this early 
contribution phase or in the 

1194
01:09:32,500 --> 01:09:36,000
public contribution phase about 
30% of our Token Supply. 

1195
01:09:36,100 --> 01:09:40,800
And then the rest 30% token 
Supply goes to this company are 

1196
01:09:40,800 --> 01:09:44,100
unsure which sort of developed 
this technology for the past two

1197
01:09:44,100 --> 01:09:48,700
years and xenical research is a 
little research, will be the 

1198
01:09:48,700 --> 01:09:53,700
entity going forward to, you 
know, sort of spearhead this IND

1199
01:09:53,700 --> 01:09:57,800
of silica and try to engage the 
community to, you know, promote 

1200
01:09:58,200 --> 01:10:01,600
silica to application developers
to build High throughput apps. 

1201
01:10:01,600 --> 01:10:03,500
On top of that, you're 
basically, that's the entity 

1202
01:10:03,500 --> 01:10:07,800
going forward, will be silica. 
And then into some of the tokens

1203
01:10:07,800 --> 01:10:11,500
will also go to funders advisors
agencies, who are helping? 

1204
01:10:12,400 --> 01:10:15,700
That's the rough idea. 
And I think I'm working but yeah

1205
01:10:16,300 --> 01:10:17,500
yeah. 
So I just want we'll add a 

1206
01:10:17,500 --> 01:10:19,400
couple of sentences so the 
emission curve. 

1207
01:10:19,900 --> 01:10:22,600
So of course I mean as she just 
said we need more - in the 

1208
01:10:22,600 --> 01:10:26,900
beginning because our network is
is powerful and it will give you

1209
01:10:26,907 --> 01:10:29,300
higher throughput only when you 
have enough - in your network 

1210
01:10:30,100 --> 01:10:33,600
and to attract those - we'll 
have our mission. 

1211
01:10:33,600 --> 01:10:37,900
Curve will be kind of A large 
portion of that would be in the 

1212
01:10:37,900 --> 01:10:40,200
first few years. 
That's a first for years so that

1213
01:10:40,200 --> 01:10:43,100
people can come in and mine it 
and then it will kind of 

1214
01:10:43,108 --> 01:10:46,700
exponentially decrease over the 
next next next year's because 

1215
01:10:46,700 --> 01:10:50,100
the idea is, you know, over time
there will be a high volume of 

1216
01:10:50,100 --> 01:10:52,600
transactions. 
So the transaction sort of gas 

1217
01:10:52,600 --> 01:10:56,700
fever will pick up as the 
majority of incentive for 

1218
01:10:56,700 --> 01:11:00,300
minors. 
Hmm, that's super interesting. 

1219
01:11:00,300 --> 01:11:04,800
So yeah, something like 30% for 
the company and silica research 

1220
01:11:05,900 --> 01:11:11,400
40% with 40% of the token Supply
over 10 years for the miners 

1221
01:11:11,400 --> 01:11:16,800
with it being front-loaded in in
in the in the short term like we

1222
01:11:16,800 --> 01:11:21,200
can earn more in the first few 
years, then you can is after 

1223
01:11:21,200 --> 01:11:27,200
after like five years later and 
30% to people spread across like

1224
01:11:28,000 --> 01:11:31,600
To contribution periods like an 
early contributor, which taking 

1225
01:11:31,600 --> 01:11:33,000
more risk. 
Yeah. 

1226
01:11:33,000 --> 01:11:36,200
The later contributor which 
who's probably taking less of a 

1227
01:11:36,208 --> 01:11:39,400
risk when, when much of the 
uncertainty has dissipated. 

1228
01:11:39,600 --> 01:11:41,900
Okay? 
That, that sort of answers the 

1229
01:11:41,900 --> 01:11:45,000
question and it makes sense. 
Cool. 

1230
01:11:45,200 --> 01:11:48,700
So with that, I'd like to thank 
you. 

1231
01:11:48,700 --> 01:11:52,200
Both of you since show and a 
number eight for being on the, 

1232
01:11:52,200 --> 01:11:55,200
on the show, it was great to 
have this conversation with you.

1233
01:11:56,100 --> 01:11:58,200
Thank you very much was it was 
really great. 

1234
01:11:58,300 --> 01:11:59,500
Yeah. 
A lot of interesting 

1235
01:11:59,500 --> 01:12:01,200
discussions. 
Thank you. 

1236
01:12:01,700 --> 01:12:04,400
And I'd also like to thank our 
listeners for tuning into the 

1237
01:12:04,400 --> 01:12:06,700
show. 
Epicenter, Bitcoin is part of 

1238
01:12:06,700 --> 01:12:09,700
the LTE network. 
You can find all of their shows 

1239
01:12:09,700 --> 01:12:13,500
at let's talk Bitcoin that calm.
At epicenter, we release 

1240
01:12:13,500 --> 01:12:16,500
episodes. 
Every, every Tuesday you can 

1241
01:12:16,500 --> 01:12:19,800
subscribe to our show on iTunes 
SoundCloud or your favorite 

1242
01:12:19,800 --> 01:12:23,700
podcast app for IOS and Android.
You can also watch the video 

1243
01:12:23,700 --> 01:12:27,000
version of the show on our 
YouTube channel at youtube.com 

1244
01:12:27,000 --> 01:12:30,900
slash F is in a Bitcoin. 
If you are a loyal listener and 

1245
01:12:30,900 --> 01:12:34,600
have been enjoying the show, we 
like to ask you for a favor. 

1246
01:12:35,100 --> 01:12:38,500
I'd usually iTunes reviews are 
really important for podcasts 

1247
01:12:38,500 --> 01:12:40,600
and help new people find the 
show. 

1248
01:12:41,700 --> 01:12:45,200
We'd like, Like to have more 
iTunes reviews and it and would 

1249
01:12:45,200 --> 01:12:48,900
appreciate if you could leave a 
review on iTunes, and of course,

1250
01:12:48,900 --> 01:12:51,700
you can set us a tip with the 
address in the show description,

1251
01:12:51,900 --> 01:12:54,700
if you find, we produced 
valuable content. 

1252
01:12:55,000 --> 01:12:59,900
So until next time it was, it 
was great having you in show, 

1253
01:12:59,900 --> 01:13:01,200
and I'm ready.