1
00:00:00,100 --> 00:00:04,900
This is epicenter episode 396 
with guests Alex glue Kowski. 

2
00:00:18,900 --> 00:00:21,200
Hi, welcome to epicenter of the 
podcast where we used for crypto

3
00:00:21,200 --> 00:00:22,800
Founders, Builders and thought 
leaders. 

4
00:00:22,900 --> 00:00:24,800
I'm Sebastian Cujo. 
And I'm here with for like a 

5
00:00:24,800 --> 00:00:27,000
Ernst today. 
We're speaking with Alex 

6
00:00:27,000 --> 00:00:28,800
glukhovsky. 
He's the co-founder of matter 

7
00:00:28,800 --> 00:00:32,400
labs and the co-creator of ZK 
sink and it is the first evm, 

8
00:00:32,400 --> 00:00:36,200
compatible, ZK, roll up. 
So before we speak with Alex, 

9
00:00:36,200 --> 00:00:38,800
about ZK sink and get into all 
the Think will mitigate he's 

10
00:00:38,800 --> 00:00:40,900
about how that works. 
We'd like to tell you about our 

11
00:00:40,900 --> 00:00:43,100
sponsors for this week. 
It's a lot of guys on Next 

12
00:00:43,100 --> 00:00:45,900
Generation, blockchain with 
lightning-fast blocks and fees 

13
00:00:46,200 --> 00:00:48,000
less than one cent per 
transaction. 

14
00:00:48,200 --> 00:00:51,000
Scalability is probably the 
biggest challenge preventing 

15
00:00:51,000 --> 00:00:53,200
crypto from becoming the 
backbone of the world's 

16
00:00:53,200 --> 00:00:55,600
Financial system. 
And Solana is one of the 

17
00:00:55,608 --> 00:00:57,900
solutions. 
We have today, go to salon.com, 

18
00:00:58,100 --> 00:01:01,000
epicenter to learn more. 
We're also sponsored by Exodus 

19
00:01:01,000 --> 00:01:04,400
is an easy-to-use wallet that 
supports hundreds of assets and 

20
00:01:04,599 --> 00:01:07,000
has native apps for all 
platforms, including IOS. 

21
00:01:07,000 --> 00:01:09,600
And Android And it's fully 
non-custodial. 

22
00:01:10,000 --> 00:01:12,600
The team are firm Believers in 
the not your keys. 

23
00:01:12,700 --> 00:01:15,900
Not your coins, Mantra 
codexes.com and give it a try 

24
00:01:16,300 --> 00:01:18,100
and finally Paris swap. 
They just came out with a huge 

25
00:01:18,100 --> 00:01:19,600
update. 
That's even faster and more 

26
00:01:19,600 --> 00:01:21,100
liquid. 
It's cheaper than you swap. 

27
00:01:21,100 --> 00:01:23,700
And it comes with a new gas 
token that can cut your gas fees

28
00:01:23,700 --> 00:01:26,700
by up to 50%. 
It's also multi chain now and 

29
00:01:26,700 --> 00:01:30,800
they've expanded to polygon and 
finance Mart chain, start 

30
00:01:30,800 --> 00:01:34,200
trading at Paris swap, dot IO, /
epicenter, Alex. 

31
00:01:34,200 --> 00:01:35,400
Hi. 
Thanks for joining us today. 

32
00:01:36,900 --> 00:01:38,900
Hello, very excited to be here. 
Thank you guys. 

33
00:01:40,000 --> 00:01:45,300
So tell us about your background
and how you became involved in a

34
00:01:45,300 --> 00:01:50,500
crypto space. 
Well, I studied computer science

35
00:01:50,500 --> 00:01:55,900
in Berlin and I worked as a team
lead and software engineer, and 

36
00:01:55,900 --> 00:01:59,700
CTO and multiple companies 
starting with telecommunication 

37
00:01:59,700 --> 00:02:04,000
space and then moved into 
startups was co-founder of two 

38
00:02:04,000 --> 00:02:07,600
startups in Berlin. 
And at some point I just felt 

39
00:02:07,600 --> 00:02:13,200
that crypto is going vertical 
and and it's just like, I can't 

40
00:02:13,200 --> 00:02:14,900
wait anymore. 
I have to jump there because my 

41
00:02:14,900 --> 00:02:18,700
heart is with in crypto. 
So, I Very excited about 

42
00:02:18,700 --> 00:02:20,000
Bitcoin. 
Actually. 

43
00:02:20,000 --> 00:02:23,100
I think I learned about the coin
one year after it was invented 

44
00:02:23,600 --> 00:02:27,500
and that van, it's really appeal
to me as a kind of libertarian 

45
00:02:28,000 --> 00:02:33,600
person and it was a very 
exciting technological thing. 

46
00:02:33,600 --> 00:02:36,900
Also from from the beauty of the
architecture of it. 

47
00:02:37,800 --> 00:02:40,700
But back, then I thought, well, 
if we could only bind it to go 

48
00:02:40,700 --> 00:02:45,700
somehow, maybe it would work, 
but eventually it actually 

49
00:02:45,700 --> 00:02:49,700
worked. 
But I switched only once 

50
00:02:49,700 --> 00:02:53,300
etherium of here. 
I actually, I try to do to build

51
00:02:53,300 --> 00:02:58,600
a startup in the Bitcoin space, 
but I felt it was too early with

52
00:02:58,600 --> 00:03:03,000
what was it started. 
We were trying to do something 

53
00:03:03,000 --> 00:03:07,000
reputation-based, like, 
Sovereign reputation thing. 

54
00:03:07,100 --> 00:03:11,500
I was doing it with our to been 
Deacon who is now secured at 

55
00:03:11,900 --> 00:03:14,600
Aurora. 
But yeah, we couldn't find 

56
00:03:14,600 --> 00:03:17,500
investors and we thought like 
it's maybe a bit early. 

57
00:03:18,200 --> 00:03:20,300
So, I went back to the classic 
of startups. 

58
00:03:21,900 --> 00:03:24,800
And the setups you worked on 
before crypto. 

59
00:03:24,800 --> 00:03:26,800
They're actually pretty 
interesting as well. 

60
00:03:26,800 --> 00:03:30,000
So maybe let's give give those 
like a minute of a time. 

61
00:03:30,200 --> 00:03:34,300
So the ones that I found one of 
them was acquired by Urban 

62
00:03:34,300 --> 00:03:37,500
sports club and the other one 
was a chem parental startup. 

63
00:03:37,600 --> 00:03:41,100
Tell us what, what Drew you to 
these these subjects because 

64
00:03:41,100 --> 00:03:44,900
they're quite they're quite 
different from one another know.

65
00:03:47,000 --> 00:03:50,500
This is true. 
So, well as a software engineer,

66
00:03:51,100 --> 00:03:54,500
I must be honest. 
That we initially, I was looking

67
00:03:54,500 --> 00:03:57,900
into the technical issues and I 
was not caring so much about the

68
00:03:57,900 --> 00:03:59,900
business nature. 
So, it looked like a very 

69
00:03:59,900 --> 00:04:01,700
interesting idea. 
So the first product was called 

70
00:04:01,700 --> 00:04:05,400
so much more, and the idea was 
that you can get a Best to. 

71
00:04:05,700 --> 00:04:10,700
It was essentially a copy of 
glass pass an American start up,

72
00:04:10,800 --> 00:04:16,300
where you could purchase a 
monthly best to All Sports, and 

73
00:04:16,399 --> 00:04:19,500
Holistic activities in your 
city, which I found very 

74
00:04:19,500 --> 00:04:21,800
appealing because like this idea
of flat rate. 

75
00:04:21,800 --> 00:04:24,800
It feels like like Community 
communism. 

76
00:04:24,800 --> 00:04:28,800
It's, it's um, in some sorting 
like, like Spotify and Netflix, 

77
00:04:28,800 --> 00:04:31,400
you just like, pavers, small 
amount per month and you get 

78
00:04:31,400 --> 00:04:33,700
unlimited access to everything 
like full abundance. 

79
00:04:33,700 --> 00:04:41,100
The future is here, so itself 
the same way, but it was not 

80
00:04:41,100 --> 00:04:44,600
very technological. 
So then with both camper the 

81
00:04:44,600 --> 00:04:47,400
Kappa sharing platform that was 
Very appealing to me because we 

82
00:04:47,400 --> 00:04:50,000
could build something really 
interesting with with complex 

83
00:04:50,000 --> 00:04:53,800
sophisticated search engine and 
optimization for scampers in the

84
00:04:53,800 --> 00:04:56,000
booking system. 
And there was a lot of 

85
00:04:56,000 --> 00:04:59,500
accounting involved Paul Kemper 
was the the company. 

86
00:04:59,500 --> 00:05:02,000
I'm really, really proud of the 
team. 

87
00:05:02,000 --> 00:05:04,900
We could build. 
It was remote first, the IT 

88
00:05:04,900 --> 00:05:08,000
team, the, the business team was
based in Berlin, but the A-Team 

89
00:05:08,000 --> 00:05:12,700
was completely remote from day 
one and it's, it's highly 

90
00:05:12,700 --> 00:05:14,600
successful. 
It's the largest campus sharing 

91
00:05:14,600 --> 00:05:20,100
platform in Europe, right? 
Paul campus present in Germany, 

92
00:05:20,500 --> 00:05:26,000
UK Switzerland Austria, I think 
even more countries by now, but 

93
00:05:26,100 --> 00:05:31,300
I decided to leave it after only
one half years because I felt 

94
00:05:31,300 --> 00:05:34,500
like I'm maxed out. 
Like I have done as a CG. 

95
00:05:34,500 --> 00:05:37,700
Oh, I've done everything I could
do there and the rest does not 

96
00:05:37,700 --> 00:05:39,300
depend on me. 
Like the process is going to 

97
00:05:39,300 --> 00:05:43,600
detecting was working fine and 
the were no not so many 

98
00:05:43,600 --> 00:05:46,300
challenges to solve whereas in 
the Crypt. 

99
00:05:46,400 --> 00:05:49,400
A world that gives etherium 
started to get traction. 

100
00:05:49,500 --> 00:05:52,800
And actually when I was in so 
much more, ample camber, I try 

101
00:05:52,800 --> 00:05:56,600
to integrate Bitcoin. 
I had this idea of like making 

102
00:05:56,600 --> 00:06:00,200
Bitcoin payments to the accepted
and then I realized I can't 

103
00:06:00,200 --> 00:06:03,200
justify that you just didn't 
make sense because no there were

104
00:06:03,200 --> 00:06:08,000
no no people using Bitcoin and 
it could be a nice PR move but 

105
00:06:08,000 --> 00:06:09,700
probably not for this new 
startups. 

106
00:06:09,700 --> 00:06:15,100
We had more consumer-oriented in
Europe and I realized if I think

107
00:06:15,100 --> 00:06:18,700
this way and I am Kind of very 
Pro Bitcoin, very excited about 

108
00:06:18,700 --> 00:06:21,400
this technology. 
This is how everyone is going to

109
00:06:21,407 --> 00:06:24,500
think about it, but now so it's 
just doesn't make sense. 

110
00:06:24,500 --> 00:06:27,800
But with etherium it was 
entirely different all of a 

111
00:06:27,808 --> 00:06:30,900
sudden the city of smart 
contracts and open Financial 

112
00:06:30,900 --> 00:06:32,700
system. 
And alternative Financial system

113
00:06:32,700 --> 00:06:37,100
would stable points with all 
sorts of interesting things with

114
00:06:37,100 --> 00:06:41,200
with potential for improved 
usability was there. 

115
00:06:41,900 --> 00:06:45,600
And I figured, like I can just 
my opportunity cost of not going

116
00:06:45,600 --> 00:06:47,600
into this. 
Is enormous. 

117
00:06:47,900 --> 00:06:51,500
So I have to switch now. 
So what I did is I went to Hong 

118
00:06:51,500 --> 00:06:57,800
Kong and I was working as a 
consultant in a research in an 

119
00:06:57,808 --> 00:07:01,600
R&D startup. 
And we were just going to all 

120
00:07:01,600 --> 00:07:03,900
the different conferences and 
meeting people and talking and 

121
00:07:03,900 --> 00:07:06,500
making research and trying to 
figure out what, what what are 

122
00:07:06,500 --> 00:07:09,300
the problems. 
The crypto space is facing 

123
00:07:09,300 --> 00:07:13,100
material space, specifically, 
and I came to conclusion, that 

124
00:07:13,100 --> 00:07:16,000
there are a couple things that 
once. 

125
00:07:16,000 --> 00:07:19,900
So, We'll bring etherium to two 
masses and everyone is just 

126
00:07:19,900 --> 00:07:22,600
going to jump on it and the 
problems that had to be solved 

127
00:07:22,600 --> 00:07:25,700
or the user experience in 
combination with security. 

128
00:07:26,200 --> 00:07:30,200
It's kind of like it's two sides
of the same coin and scalability

129
00:07:30,900 --> 00:07:35,400
and while the security in you 
Acts were kind of clear how to 

130
00:07:35,400 --> 00:07:37,100
fix. 
Like we could just apply 

131
00:07:37,100 --> 00:07:40,700
principles from the web to world
everything we knew from 

132
00:07:40,700 --> 00:07:42,400
traditional startups, from 
mobile apps. 

133
00:07:43,800 --> 00:07:47,100
It was clear what to do and they
were actually Build, we got 

134
00:07:47,100 --> 00:07:49,900
Madam asked with that. 
Argent got Dharma, got all this 

135
00:07:49,900 --> 00:07:55,100
wallets with social recovery 
with the ease of not having to 

136
00:07:55,100 --> 00:07:59,700
to care about your secret 
phrases, like Zengo and what was

137
00:07:59,700 --> 00:08:04,700
based on, you know, some 
combination of secret sharing 

138
00:08:04,700 --> 00:08:09,100
and using your email as login 
and so on and all the other 

139
00:08:09,100 --> 00:08:12,100
things were also been built from
traditional Finance, which we 

140
00:08:12,100 --> 00:08:16,000
now know is D Phi but 
scalability really caught my eye

141
00:08:16,000 --> 00:08:19,300
because it Very technological. 
Like, it felt like a fundamental

142
00:08:19,300 --> 00:08:21,900
problem, which cannot be easy to
solve, and unless we have some 

143
00:08:21,900 --> 00:08:24,600
breakthrough, the were a couple 
of attempts. 

144
00:08:25,100 --> 00:08:28,000
There was the city of plasma 
that was introduced around that 

145
00:08:28,000 --> 00:08:31,100
time. 
And I remember I met metallic 

146
00:08:31,100 --> 00:08:34,100
for the first time in Shanghai 
at a conference where he first 

147
00:08:34,100 --> 00:08:38,600
spoke about plasma. 
I was very excited but after 

148
00:08:38,799 --> 00:08:43,900
half a year, or a year or so, it
was clear that plasma is facing 

149
00:08:43,900 --> 00:08:48,300
a lot of hidden problems. 
And that they appear to be of 

150
00:08:48,300 --> 00:08:52,100
kind of fundamental nature. 
Like we just, we just can solve 

151
00:08:52,100 --> 00:08:55,800
them in, you know, like just 
tinkering around so we need 

152
00:08:55,800 --> 00:08:58,900
something, something more solid.
And then I learned about your 

153
00:08:58,900 --> 00:09:01,000
knowledge. 
Proofs first about the 

154
00:09:01,100 --> 00:09:04,000
zero-knowledge aspect of their 
knowledge proofs so that you can

155
00:09:04,000 --> 00:09:06,400
use them for privacy. 
And later. 

156
00:09:07,200 --> 00:09:09,300
I learned about the succinctness
property. 

157
00:09:09,300 --> 00:09:13,200
There's some of them have 
specifically snarks that you can

158
00:09:13,200 --> 00:09:17,000
prove Integrity of very large 
computations and they are Much 

159
00:09:17,000 --> 00:09:20,200
cheaper to verify than actually 
doing all this competitions. 

160
00:09:20,200 --> 00:09:24,100
Naivety and my third first 
thought was when I heard about 

161
00:09:24,100 --> 00:09:26,500
that. 
Oh, you can apply that to plasma

162
00:09:26,800 --> 00:09:30,200
and make plasma a lot like solve
a lot of problems involving of 

163
00:09:30,200 --> 00:09:33,000
that. 
And if you do that, that that's 

164
00:09:33,000 --> 00:09:35,600
actually a cover all up. 
So I kept lying zero, knowledge 

165
00:09:35,600 --> 00:09:37,600
proof to plasma gives you a 
valium. 

166
00:09:38,100 --> 00:09:42,400
And then if you put the data on 
chain, this is the Z key roll 

167
00:09:42,400 --> 00:09:45,600
up. 
And I met very white hat was 

168
00:09:45,600 --> 00:09:48,300
working. 
Who built it, built the first 

169
00:09:48,300 --> 00:09:53,900
working group, working on Ziggy 
Roll-Ups, and we met some other 

170
00:09:53,900 --> 00:09:55,700
guys. 
We had discussions and we 

171
00:09:55,700 --> 00:09:59,800
published the famous blog post 
on each research particular 

172
00:09:59,800 --> 00:10:02,200
laps. 
And then I met my co-founder 

173
00:10:02,500 --> 00:10:06,100
Alex, lots of in at def Con in 
Prague. 

174
00:10:06,100 --> 00:10:08,100
I think it was Defcon four or 
three. 

175
00:10:08,500 --> 00:10:11,600
He was coming to the same idea 
from a different angle. 

176
00:10:11,700 --> 00:10:13,200
He was actually working on 
plasma. 

177
00:10:13,300 --> 00:10:14,800
He what? 
He was building a plasma 

178
00:10:14,800 --> 00:10:17,300
implementation. 
And he learn about their 

179
00:10:17,300 --> 00:10:20,100
knowledge proves and he was very
deep into cryptography. 

180
00:10:20,800 --> 00:10:24,800
Having a PhD in high energy 
physics from McGill University 

181
00:10:24,800 --> 00:10:27,000
in Canada. 
He was really good. 

182
00:10:27,000 --> 00:10:30,100
I immediately realized that this
guy's it's genius and we should 

183
00:10:30,100 --> 00:10:32,900
do something together, and we 
immediately jumped into 

184
00:10:32,900 --> 00:10:36,100
discussion of how things should 
be built, technologically. 

185
00:10:36,200 --> 00:10:39,100
We built the first prototype 
presentative, and this is how 

186
00:10:39,600 --> 00:10:45,100
education can was born. 
Let's get your sponsor Solana. 

187
00:10:45,200 --> 00:10:47,000
Now. 
This is a special, and for me to

188
00:10:47,000 --> 00:10:49,800
read because I've been deep 
supporter of this project since 

189
00:10:49,800 --> 00:10:52,800
meaningless. 
Lana, team back in 2018. 

190
00:10:53,000 --> 00:10:55,400
I invest personally in the 
project and my company course, 

191
00:10:55,400 --> 00:10:59,000
one is super deeply involved in 
the Solana ecosystem, including 

192
00:10:59,000 --> 00:11:02,400
running the biggest validator. 
So, what's so cool about Solana.

193
00:11:02,800 --> 00:11:05,600
Well, we all know that 
scalability is the single most 

194
00:11:05,600 --> 00:11:08,500
important issue facing the 
blockchain industry today. 

195
00:11:08,900 --> 00:11:11,800
And to Solana, blockchain is an 
amazing solution for it. 

196
00:11:12,100 --> 00:11:14,300
The networks. 
It's thousands of transactions 

197
00:11:14,300 --> 00:11:18,900
per second with 400 Milli second
block times and over 500 

198
00:11:18,900 --> 00:11:21,300
validators. 
The special thing about Solana 

199
00:11:21,300 --> 00:11:24,000
is also that it's not a sharded 
blockchain. 

200
00:11:24,200 --> 00:11:27,700
It's a single Block Chain hyper 
optimized for performance. 

201
00:11:28,000 --> 00:11:32,200
So that makes it really easy to 
maintain composability between 

202
00:11:32,200 --> 00:11:34,700
all of the apps on Solana. 
So that they work together 

203
00:11:34,700 --> 00:11:38,700
seamlessly now and forever. 
There's a lot of ecosystem is 

204
00:11:38,700 --> 00:11:41,400
growing at a rapid pace and it's
a great place to build your 

205
00:11:41,400 --> 00:11:43,800
project or just getting Both 
with the community. 

206
00:11:43,800 --> 00:11:46,800
So go to salon.com epicenter to 
learn more. 

207
00:11:48,800 --> 00:11:53,600
We've done a number of episodes 
on the topic of scalability and 

208
00:11:53,600 --> 00:11:56,000
a few episodes where we talk 
specifically about ZK relatives,

209
00:11:56,000 --> 00:11:58,900
but let's maybe get a little 
refresh. 

210
00:11:59,400 --> 00:12:02,000
You know, how does this EK 
roll-up work in a nutshell? 

211
00:12:02,300 --> 00:12:04,700
What are the main components? 
And like what is it trying to 

212
00:12:04,700 --> 00:12:08,400
achieve? 
Zeki roll-up is a scaling 

213
00:12:08,400 --> 00:12:11,400
solution that works on top of 
square one. 

214
00:12:11,600 --> 00:12:14,200
So it's a layer to scaling 
solution which is supposed to 

215
00:12:14,200 --> 00:12:18,600
derive its security from from 
layer 1 and it works the 

216
00:12:18,600 --> 00:12:21,800
following way. 
Maybe we should recap first, how

217
00:12:21,800 --> 00:12:24,200
plasma works because it's going 
to be easier to explain. 

218
00:12:24,200 --> 00:12:27,800
So, with plasma, imagine that 
you have a single contract on 

219
00:12:27,800 --> 00:12:31,600
layer. 
One that instead of holding all 

220
00:12:31,600 --> 00:12:35,500
the balances of the users, only 
holds all the funds. 

221
00:12:35,600 --> 00:12:42,200
Together in a single pot and it 
holds a root hash of a of the 

222
00:12:42,200 --> 00:12:45,700
state which is held off chain, 
which contains all the balances.

223
00:12:46,300 --> 00:12:50,000
So I only keep one hash. 
So this this hash been a Mercury

224
00:12:50,000 --> 00:12:54,300
root serves as a cryptographic 
fingerprint of our state 

225
00:12:54,500 --> 00:12:57,300
whenever change something in the
state to change the the the root

226
00:12:57,300 --> 00:13:02,600
hairs will change completely. 
Now when we we want this users 

227
00:13:02,600 --> 00:13:05,500
to transact, we want to see 
users to send funds to each. 

228
00:13:05,600 --> 00:13:07,300
Her, which will modify the 
state. 

229
00:13:08,000 --> 00:13:12,400
So whenever we have multiple 
transactions, maybe a block of, 

230
00:13:12,400 --> 00:13:14,000
like, let's say 1,000 
transactions. 

231
00:13:14,700 --> 00:13:17,600
We would modify the state 
applying each of them 

232
00:13:17,600 --> 00:13:20,500
sequentially through the state, 
which will modify all the 

233
00:13:20,500 --> 00:13:24,200
balances. 
And then we will compute the new

234
00:13:24,200 --> 00:13:27,900
root hash of the state and will 
send this new root hash to the 

235
00:13:27,900 --> 00:13:31,400
smart contract on where one and 
replace it. 

236
00:13:32,200 --> 00:13:35,500
And this way we actually made 
only one small. 

237
00:13:35,600 --> 00:13:40,300
Action on layer 1, but we 
enacted many transfer of 

238
00:13:40,300 --> 00:13:43,100
thousands of transfers of 
thousands of transactions, which

239
00:13:43,100 --> 00:13:48,600
happened on layer 2. 
So, the in plasma you would 

240
00:13:48,600 --> 00:13:53,700
suppose to monitor what's going 
on in the state and try to catch

241
00:13:53,700 --> 00:13:55,600
the. 
So, like, anyone would be able 

242
00:13:55,600 --> 00:14:00,400
to submit the new root hash, and
if something goes wrong and this

243
00:14:00,400 --> 00:14:03,300
new root, hash contains invalid 
transactions, or some invalid 

244
00:14:03,300 --> 00:14:05,500
State, you would have to somehow
prevent. 

245
00:14:05,600 --> 00:14:09,900
And this new root hash from 
being finalized on layer 1 and 

246
00:14:09,900 --> 00:14:12,300
this is difficult. 
So it with plasma and Zeki 

247
00:14:12,300 --> 00:14:15,100
Roll-Ups rely on so-called 
throat proofs, where someone has

248
00:14:15,100 --> 00:14:18,200
to monitor it and then provide 
the proof that the news new 

249
00:14:18,200 --> 00:14:22,100
state is not valid with Ezekiel 
Roll-Ups. 

250
00:14:22,500 --> 00:14:25,800
We do something very elegant. 
We provide a zero, knowledge 

251
00:14:25,800 --> 00:14:30,000
proof, or like 16, zero 
knowledge proof of snark of 

252
00:14:30,000 --> 00:14:34,400
validity of all the transactions
that happened that produce this 

253
00:14:34,400 --> 00:14:35,200
new root. 
Hash. 

254
00:14:36,300 --> 00:14:39,300
And the snark is verified by the
smart contract itself. 

255
00:14:40,000 --> 00:14:42,900
So what it means is, it's been 
verified on all the full nodes 

256
00:14:42,900 --> 00:14:46,300
of the Syria. 
And only if the stock is valid, 

257
00:14:47,600 --> 00:14:51,000
then we change the the knurled 
hash on the smart contract. 

258
00:14:51,600 --> 00:14:53,300
And this way we can guarantee 
that. 

259
00:14:53,300 --> 00:14:59,300
No, invalid transaction is ever 
included in, in our roadblock. 

260
00:15:00,800 --> 00:15:05,800
So just to recap, the the 
phrases differently in a, in an 

261
00:15:05,800 --> 00:15:10,500
optimistic roll-up, you have a 
verification of the different 

262
00:15:10,500 --> 00:15:13,900
hashes in the Merkle tree and 
the root hash that has to be 

263
00:15:14,300 --> 00:15:17,800
verified by some like some 
third-party process. 

264
00:15:18,000 --> 00:15:20,300
And one of the ways that we've 
come to do that is to have this 

265
00:15:20,300 --> 00:15:22,800
front fraud proof system, but 
that introduces a whole bunch of

266
00:15:23,100 --> 00:15:25,700
complexities. 
Whereas with a ZK roll up, you 

267
00:15:25,700 --> 00:15:31,200
simply have a snark that proves 
that all of the state in the All

268
00:15:31,200 --> 00:15:35,400
the transactions in the state 
that sent to the smart contract 

269
00:15:35,500 --> 00:15:38,900
is indeed valid. 
This is correct. 

270
00:15:38,900 --> 00:15:41,100
Yes. 
So this way we can only prove 

271
00:15:41,100 --> 00:15:43,700
the validity. 
However, we also have a problem 

272
00:15:43,700 --> 00:15:46,400
of data availability. 
So we need to make sure that 

273
00:15:46,400 --> 00:15:48,600
everyone knows what the new 
route State. 

274
00:15:48,900 --> 00:15:50,600
What's the new state is 
completely? 

275
00:15:50,600 --> 00:15:54,200
Not only the route has and would
roll ups. 

276
00:15:54,200 --> 00:15:59,800
What we do is, we publish some 
data on chain that makes 

277
00:15:59,800 --> 00:16:04,900
everyone able to reconstruct the
changes in the state to get the 

278
00:16:04,900 --> 00:16:07,300
final State somehow. 
Like if we hope it has the 

279
00:16:07,300 --> 00:16:09,600
previous state. 
The block you should be able to 

280
00:16:09,600 --> 00:16:13,500
get the new state completely in 
your local database after the 

281
00:16:13,500 --> 00:16:16,000
block. 
So you can do it in multiple 

282
00:16:16,000 --> 00:16:18,500
ways. 
You can either publish the 

283
00:16:18,700 --> 00:16:22,600
inputs of all the transactions. 
This is, you can do it, the Z 

284
00:16:22,600 --> 00:16:26,500
key, roll up, and you can do it 
with optimistic, roll-up, or you

285
00:16:26,500 --> 00:16:31,600
can publish just the final State
like, actually, like the state 

286
00:16:31,600 --> 00:16:34,600
Delta, what would change in the 
state, the final state of every 

287
00:16:34,600 --> 00:16:38,300
account, which was attached in 
this block and this Is only 

288
00:16:38,300 --> 00:16:40,900
possible with Z key role and 
this is very interesting because

289
00:16:40,900 --> 00:16:43,200
it reduces additional 
succinctness. 

290
00:16:43,700 --> 00:16:48,000
If you have, let's say one 
account or like two accounts, 

291
00:16:48,000 --> 00:16:50,000
making many transactions between
each other. 

292
00:16:50,700 --> 00:16:53,200
At the end. 
We will only need to publish to 

293
00:16:53,600 --> 00:16:56,700
to updates of the state like the
final balance of the first 

294
00:16:56,700 --> 00:17:00,000
account in the final balance of 
the second count and not all the

295
00:17:00,008 --> 00:17:02,800
hundreds of transactions with 
that took place in Islam. 

296
00:17:04,200 --> 00:17:08,800
This place is of floor at how 
much a transaction can be 

297
00:17:08,800 --> 00:17:12,000
reduced by right to. 
Basically if you if you have an 

298
00:17:12,000 --> 00:17:15,000
operator and use it's a 
optimistic roll up. 

299
00:17:15,300 --> 00:17:20,599
You can compress the data much 
more said correct because a you 

300
00:17:20,599 --> 00:17:24,099
don't need to submit it. 
Unchain such that someone can 

301
00:17:24,099 --> 00:17:28,400
reconstruct the entire thing. 
Yep, that there are multiple 

302
00:17:28,400 --> 00:17:32,900
factors that that make Ezekiel 
UPS cheaper in terms of unchain 

303
00:17:32,900 --> 00:17:37,100
data, but fundamentally, maybe 
we should first answer the 

304
00:17:37,100 --> 00:17:39,100
question. 
Why does this work? 

305
00:17:39,100 --> 00:17:43,200
As a scaling solution at all? 
If we still put this data on 

306
00:17:43,300 --> 00:17:44,900
through, on the theory of 
network, right? 

307
00:17:45,300 --> 00:17:50,000
So the the difference from just 
using the putting this data in, 

308
00:17:50,400 --> 00:17:53,200
you know, like using the theorem
on layer 1 normally is that we 

309
00:17:53,200 --> 00:17:56,400
don't use storage. 
We only use the bandwidth. 

310
00:17:56,500 --> 00:18:00,400
Of the network, but we do not 
require the etherium full nodes 

311
00:18:00,800 --> 00:18:05,000
to store it in the ethereum 
active State and we do not 

312
00:18:05,000 --> 00:18:09,100
require them to verify and like 
access storage of different 

313
00:18:09,100 --> 00:18:15,100
contracts to verify transactions
and that part random access to 

314
00:18:15,100 --> 00:18:18,100
the storage is actually the 
bottleneck right now in Syria. 

315
00:18:18,400 --> 00:18:21,100
This is this is the most 
expensive thing because you 

316
00:18:21,100 --> 00:18:26,400
cannot like we use ssds and we 
cannot read the data. 

317
00:18:26,500 --> 00:18:28,600
Really from ssds, which would be
really fast. 

318
00:18:28,700 --> 00:18:31,600
Instead. 
We have to go to like jump to 

319
00:18:31,600 --> 00:18:36,300
random locations in this memory 
and this introduces the delays 

320
00:18:36,300 --> 00:18:38,200
and you have to do it 
sequentially. 

321
00:18:38,500 --> 00:18:41,400
After it one thing, then you 
have to read the other thing and

322
00:18:41,400 --> 00:18:43,500
then because you're working on a
global state, right? 

323
00:18:43,600 --> 00:18:46,300
So that's why, that's why you 
have to do it sequentially 

324
00:18:46,800 --> 00:18:49,100
because you're working on the 
global State and you work with 

325
00:18:49,100 --> 00:18:53,500
Merkel proof Merkel proof. 
So you, you have to retrieve 

326
00:18:53,500 --> 00:18:57,100
Merkel path for all the accounts
and when you modify You have to 

327
00:18:57,100 --> 00:19:00,000
actually go and like modify all 
the intermediate nodes on the 

328
00:19:00,000 --> 00:19:03,000
Merkle tree. 
And this is where you get this 

329
00:19:03,000 --> 00:19:05,800
delays because this latency is 
just add up. 

330
00:19:06,200 --> 00:19:12,300
So what we do with Ezekiel up, 
we only publish the blog as a 

331
00:19:12,300 --> 00:19:15,300
one big chunk of data. 
We do not use storage. 

332
00:19:15,300 --> 00:19:16,700
It doesn't need to touch 
storage. 

333
00:19:17,400 --> 00:19:21,000
It just goes through the network
interface and the bandwidth is a

334
00:19:21,000 --> 00:19:25,100
lot cheaper than storage and a 
lot faster than storage access 

335
00:19:25,500 --> 00:19:26,300
to. 
This gives us. 

336
00:19:26,400 --> 00:19:31,100
Is roughly a hundred X 
improvement with Ezekiel up with

337
00:19:31,100 --> 00:19:35,000
optimistic grow up. 
You can get the kind of the same

338
00:19:35,200 --> 00:19:40,400
scalability factor. 
If you optimize the optimistic 

339
00:19:40,400 --> 00:19:46,500
roll-up really strongly for, 
like, what do we need to do is 

340
00:19:46,600 --> 00:19:49,300
you will have to aggregate the 
signatures because you still 

341
00:19:49,300 --> 00:19:53,600
have to publish the signatures 
on through this network in the 

342
00:19:53,600 --> 00:19:56,300
roll-up, which you don't have to
do in a secure lab. 

343
00:19:56,700 --> 00:19:59,000
Because the signatures are 
verified by the Stark. 

344
00:19:59,800 --> 00:20:02,800
And also you would have there 
are some other nuances and 

345
00:20:02,800 --> 00:20:05,300
optimistic, Rob say the most 
compressed version would only 

346
00:20:05,300 --> 00:20:09,000
work with Mount around throat, 
proofs something, like our 

347
00:20:09,000 --> 00:20:13,700
bedroom and it would be much 
harder to build with a single 

348
00:20:13,700 --> 00:20:17,200
round sloped roofs, which 
optimism is uses is using. 

349
00:20:17,500 --> 00:20:20,600
But in any case you still have 
like you only get a linear 

350
00:20:20,800 --> 00:20:25,000
scalability boost. 
Let's get to our sponsor. 

351
00:20:25,000 --> 00:20:28,400
Exodus Exodus is Is a fantastic 
crypto currency wallet, that 

352
00:20:28,400 --> 00:20:31,800
strikes the right balance 
between ease-of-use security and

353
00:20:31,800 --> 00:20:34,800
great features. 
You can get Exodus on the iPhone

354
00:20:35,000 --> 00:20:38,200
desktop app. 
Web app, Android, whatever 

355
00:20:38,200 --> 00:20:41,400
platform you use. 
It's a non-custodial wallet. 

356
00:20:41,400 --> 00:20:43,800
That is so critical. 
Because what's the point of 

357
00:20:43,800 --> 00:20:45,700
crypto? 
If you don't control your own 

358
00:20:45,700 --> 00:20:50,100
assets with Exodus, you always 
do, they're old school and 

359
00:20:50,100 --> 00:20:55,100
they've been around since 2015 
over 1.2 million users rely on 

360
00:20:55,100 --> 00:20:57,000
Exodus. 
So, you know that If stood the 

361
00:20:57,000 --> 00:21:01,500
test of time, they have support 
for over 100 different crypto 

362
00:21:01,500 --> 00:21:05,600
acids and remove in Exodus. 
You can easily change one 

363
00:21:05,600 --> 00:21:09,400
different asset to the order. 
They also allow you to buy group

364
00:21:09,400 --> 00:21:12,600
2 with Fiat and they even have a
great offer where you can buy up

365
00:21:12,600 --> 00:21:17,300
to $500 worth of crypto through 
the IOS app and Pages $1 in 

366
00:21:17,300 --> 00:21:20,500
feet. 
So go to Exodus.com epicenter 

367
00:21:20,500 --> 00:21:24,000
and check out their wallet. 
We want to thank Exodus for 

368
00:21:24,000 --> 00:21:26,000
their amazing support of 
epicenter. 

369
00:21:27,800 --> 00:21:31,700
So let's talk about the 
aggregated, block of transaction

370
00:21:31,700 --> 00:21:34,800
data. 
So who actually Aggregates that 

371
00:21:34,800 --> 00:21:37,900
and basically, if I want to 
transaction include included in 

372
00:21:37,900 --> 00:21:41,100
a ZK, sink block, how do I go 
about that? 

373
00:21:42,900 --> 00:21:47,100
So you normally have someone 
called sequencer collecting the 

374
00:21:47,100 --> 00:21:50,100
transactions from the users and 
packing them in the block and 

375
00:21:50,100 --> 00:21:51,900
Computing, the new root hash of 
this block. 

376
00:21:52,500 --> 00:21:56,400
The sequencer can be centralized
can be a single party with the 

377
00:21:56,400 --> 00:21:59,500
server, which accepts the 
transactions through rest API. 

378
00:22:00,000 --> 00:22:03,500
It can also be decentralized, 
some consensus algorithm 

379
00:22:03,700 --> 00:22:06,300
multiple validators collecting 
the transactions through 

380
00:22:06,300 --> 00:22:08,900
peer-to-peer Network and the 
just agree on. 

381
00:22:08,900 --> 00:22:12,300
What's the the new block is 
going to be Then selecting the 

382
00:22:12,300 --> 00:22:15,900
leader, who will submit it to 
ethereal or maybe anyone from 

383
00:22:15,900 --> 00:22:19,700
from this vital task and 
submitted to the theory with all

384
00:22:19,700 --> 00:22:21,100
the Roll-Ups right. 
Now. 

385
00:22:21,400 --> 00:22:25,000
As far as I'm aware. 
Everyone is currently using 

386
00:22:25,000 --> 00:22:30,100
centralized sequences because 
with Roll-Ups, you do not rely 

387
00:22:30,100 --> 00:22:33,400
for the sequencer on the 
sequencer for security, but they

388
00:22:33,400 --> 00:22:34,600
could send some of you. 
Right? 

389
00:22:35,200 --> 00:22:38,000
They could sounds. 
Are you but only in L2, they 

390
00:22:38,000 --> 00:22:41,300
cannot censor you and l 1. 
So if you feel censored, you can

391
00:22:41,500 --> 00:22:44,800
Is called aleurone and retrieve 
your funds through some 

392
00:22:45,100 --> 00:22:46,900
additional mechanisms, in our 
case. 

393
00:22:46,900 --> 00:22:51,200
It's called priority queue and 
we have something called Exodus 

394
00:22:51,200 --> 00:22:54,700
mode or emergency exit mode 
where you can exit without 

395
00:22:54,700 --> 00:22:57,200
asking anyone for permission. 
And this is very important 

396
00:22:57,200 --> 00:23:01,600
aspect of the protocol. 
But if you, if you are being 

397
00:23:01,600 --> 00:23:06,200
censored by operators by the 
operator by the sequencer in L2.

398
00:23:06,200 --> 00:23:08,800
Yeah, it's just not going to use
this service. 

399
00:23:09,400 --> 00:23:13,600
It's not as bad. 
What are the trade-offs of 

400
00:23:13,600 --> 00:23:17,000
having a centralized service and
perhaps a decentralized service 

401
00:23:17,000 --> 00:23:19,400
to ensure that like censorship 
resistant aspect? 

402
00:23:20,900 --> 00:23:25,400
It just allowed us to to, to 
launch the busy kissing earlier 

403
00:23:25,500 --> 00:23:30,500
and we was a kissing booth for 
the philosophy of progressive 

404
00:23:30,500 --> 00:23:33,200
decentralization. 
We start with the minimum viable

405
00:23:33,200 --> 00:23:37,500
product, which is Central at 
which does not rely on us or 

406
00:23:37,500 --> 00:23:41,900
anyone for security. 
So, we derive security directly 

407
00:23:41,900 --> 00:23:47,400
from etherium and it's just much
faster to build and to have a 

408
00:23:47,400 --> 00:23:51,200
full-fledged flash consensus, 
which We are building and this 

409
00:23:51,200 --> 00:23:53,500
is very important. 
As you can see, we don't want 

410
00:23:53,500 --> 00:23:57,900
the casing to rely on is single 
party long term or even midterm.

411
00:23:58,400 --> 00:24:00,500
We wanted to be decentralized 
protocol governed by the 

412
00:24:00,500 --> 00:24:04,400
community and having multiple 
validators that are selected by 

413
00:24:04,400 --> 00:24:07,900
the community. 
So that we also don't have any 

414
00:24:07,900 --> 00:24:12,400
censorship potential, you know, 
to long-term. 

415
00:24:12,400 --> 00:24:14,200
Actually. 
We have some more ideas on how 

416
00:24:14,200 --> 00:24:17,900
to solve censorship and we will 
rely on even more advanced 

417
00:24:17,900 --> 00:24:21,400
cryptography because And if you 
are even in aetherium with 

418
00:24:21,400 --> 00:24:26,300
multiple miners, there is still 
a chance that the they will 

419
00:24:26,300 --> 00:24:28,600
conclude. 
It's not impossible that the 

420
00:24:28,600 --> 00:24:32,200
miners, or validators will 
conclude and we will prevent 

421
00:24:32,200 --> 00:24:33,800
users from the mentioned 
transactions. 

422
00:24:34,200 --> 00:24:39,000
And this is actually a one big 
attack Vector on optimistic 

423
00:24:39,000 --> 00:24:42,300
Roll-Ups or on other protocols 
that rely on throat. 

424
00:24:42,300 --> 00:24:48,900
Proofs that the miners willingly
or being cursed. 

425
00:24:49,100 --> 00:24:51,800
We'll Just prevent the front 
proofs from being mined on the 

426
00:24:51,808 --> 00:24:55,100
theorem for a relatively short 
time of one or two weeks. 

427
00:24:55,600 --> 00:24:59,300
And then the attacker would be 
able to seize all the funds from

428
00:24:59,300 --> 00:25:02,000
the optimistic roll up. 
This has been a controversial 

429
00:25:02,000 --> 00:25:07,600
topic. 
Like obviously I am a z key role

430
00:25:07,600 --> 00:25:10,800
of maximalist and you can say 
I'm biased because of that and 

431
00:25:10,800 --> 00:25:14,700
we had some clashes with people 
from who are optimistic roll-up 

432
00:25:14,700 --> 00:25:18,000
proponents and they would argue 
that the community can always 

433
00:25:18,000 --> 00:25:21,900
step in and intervene. 
Banish the validators who do 

434
00:25:21,900 --> 00:25:26,300
such a thing and rely eventually
on social consensus for storing 

435
00:25:26,500 --> 00:25:31,600
for, for the ultimate censorship
resistance, but I disagree that 

436
00:25:31,600 --> 00:25:35,700
that you can like you should not
be building protocols that rely 

437
00:25:35,700 --> 00:25:41,600
on such weak assumptions. 
This also might be valid for for

438
00:25:41,600 --> 00:25:45,000
the time once we transition to 
proof of stake and it like maybe

439
00:25:45,100 --> 00:25:48,900
there will be some like clearly 
written rules how the community 

440
00:25:48,900 --> 00:25:51,500
should behave. 
We get some signaling from 

441
00:25:51,500 --> 00:25:53,800
everyone in the community that 
they actually going to follow 

442
00:25:53,800 --> 00:25:57,400
this rules and we have clear 
mechanisms how such a situation 

443
00:25:57,400 --> 00:26:00,500
can be cleared up without 
incurring a lot of mass. 

444
00:26:00,500 --> 00:26:04,700
Because the imagine if that 
happens and we have a lot of 

445
00:26:04,700 --> 00:26:08,900
defy transactions going on, that
are all intertwined, you know, 

446
00:26:08,900 --> 00:26:13,100
like you put something into uni 
Swap and then other people put 

447
00:26:13,100 --> 00:26:16,200
stuff in and the price moves and
some other oracle's around this 

448
00:26:16,200 --> 00:26:17,900
price and so on. 
And so on like it's going to be 

449
00:26:17,900 --> 00:26:19,700
very very difficult to sort it 
out. 

450
00:26:20,000 --> 00:26:22,100
After the fact. 
So you actually need this 

451
00:26:22,100 --> 00:26:26,400
mechanisms to prevent some of 
the ship in place before, but 

452
00:26:26,400 --> 00:26:28,900
that would only work once we 
have proof of stake with proof 

453
00:26:28,900 --> 00:26:30,900
of work. 
There is no mitigation. 

454
00:26:31,500 --> 00:26:34,900
Like if if the proof of work 
miners decide to attack an 

455
00:26:34,900 --> 00:26:37,000
optimistic roll up, they can do 
it. 

456
00:26:37,400 --> 00:26:41,300
This is very real and they can 
they can collude, they can be 

457
00:26:41,300 --> 00:26:44,300
bribed with. 
There might be some automated 

458
00:26:44,300 --> 00:26:47,800
bribery mechanisms through some 
smart contracts. 

459
00:26:47,800 --> 00:26:49,700
They distribute the rewards from
this attack. 

460
00:26:50,500 --> 00:26:53,300
And actually, the closer we come
to the moment of transition 

461
00:26:53,300 --> 00:26:55,200
proof proof of work to proof of 
stake. 

462
00:26:55,500 --> 00:26:59,300
The last proof-of-work miners 
have at stake. 

463
00:26:59,400 --> 00:27:02,700
But with a less they have to 
lose like in the last days 

464
00:27:02,700 --> 00:27:05,200
before transition. 
It's very, very likely with this

465
00:27:05,200 --> 00:27:09,100
attack can happen. 
Yeah, so that's why in the long 

466
00:27:09,100 --> 00:27:11,300
term. 
We want to rely on something 

467
00:27:11,300 --> 00:27:15,200
more fundamental for preventing 
censorship. 

468
00:27:15,200 --> 00:27:18,600
Such as, for example, 
time-locked encryption, where 

469
00:27:18,600 --> 00:27:23,000
the users will be able to put 
put their transactions in some 

470
00:27:23,000 --> 00:27:25,800
encrypted envelopes and submit 
them to buy the debtors to 

471
00:27:25,800 --> 00:27:28,400
include in the block before the 
validators can learn what's 

472
00:27:28,400 --> 00:27:32,300
inside cool. 
Yeah, that makes total sense. 

473
00:27:32,400 --> 00:27:36,800
So maybe let's do a walk-through
of how it works step by step 

474
00:27:36,900 --> 00:27:39,000
because so far it's been pretty 
abstract. 

475
00:27:39,000 --> 00:27:43,200
So let's say I have I have an 
address with one ether on Nao 

476
00:27:43,200 --> 00:27:46,000
one. 
How do I get it onto the ZK? 

477
00:27:46,000 --> 00:27:50,300
Sync, layer 2. 
As with any layer 2, you will 

478
00:27:50,300 --> 00:27:54,500
have to make a transaction on 
layer 1 to move this funds from 

479
00:27:54,500 --> 00:27:57,700
layer, 1 to layer 2. 
Alternatively, you could just 

480
00:27:57,700 --> 00:28:02,200
get the busy from someone who 
already has it in layer 2. 

481
00:28:03,000 --> 00:28:07,400
So for example, if you're in 
normal user and you just want to

482
00:28:07,408 --> 00:28:10,800
move your feet yet to wear to, 
you will probably just go to an 

483
00:28:10,808 --> 00:28:15,400
exchange and withdrawal directly
to decreasing from there. 

484
00:28:15,800 --> 00:28:17,200
We're kind of working on down 
better go. 

485
00:28:17,300 --> 00:28:20,600
Asians. 
The address that I have on layer

486
00:28:20,600 --> 00:28:23,700
2 is exactly the way the same 
that I can also have one day. 

487
00:28:23,700 --> 00:28:25,700
I won. 
So there's no confusion 

488
00:28:25,700 --> 00:28:29,000
possible. 
Is that right in ZK sink? 

489
00:28:29,100 --> 00:28:31,700
This is how we designed it. 
So it was very important to us 

490
00:28:31,700 --> 00:28:34,200
to keep the a very, very high 
degree of usability. 

491
00:28:34,200 --> 00:28:36,800
And yes, you have the same 
address in flirt. 

492
00:28:36,800 --> 00:28:41,900
Oh, that sounds super nice 
because I mean, as someone who 

493
00:28:41,900 --> 00:28:45,000
builds decentralised projects 
and products. 

494
00:28:45,100 --> 00:28:47,900
I mean, we have all seen how 
often it happens. 

495
00:28:48,000 --> 00:28:51,900
Happens that people send funds 
to the same address on a 

496
00:28:51,908 --> 00:28:54,300
different network. 
Be it a test Network or a day or

497
00:28:54,300 --> 00:28:55,800
two. 
Absolutely. 

498
00:28:55,900 --> 00:29:00,100
So that's super nice weather. 
The weather technological 

499
00:29:00,900 --> 00:29:06,800
challenges inherent to this. 
I want to also say that indeed 

500
00:29:06,800 --> 00:29:10,500
many people do this, many people
would do transfers instead of 

501
00:29:10,500 --> 00:29:14,100
withdrawals or deposits. 
They just sent funds to, to the 

502
00:29:14,100 --> 00:29:17,700
same like to this address and 
think, for example, we have a 

503
00:29:17,708 --> 00:29:20,400
lot of users who would send 
funds inside the casing to some 

504
00:29:20,400 --> 00:29:24,000
address and expected to appear 
on where one without knowing 

505
00:29:24,000 --> 00:29:27,700
that they actually have to do 
withdrawal and sometimes they 

506
00:29:27,700 --> 00:29:31,000
would send it to some address 
which cannot register in the 

507
00:29:31,000 --> 00:29:34,400
casing because it's a smart 
contract or it's just some 

508
00:29:34,600 --> 00:29:39,600
Change address and they the 
funds would get stuck there. 

509
00:29:39,800 --> 00:29:44,500
So we had to develop a special 
mechanism to force the funds out

510
00:29:44,900 --> 00:29:49,600
for new addresses that have not 
been used yet which where the 

511
00:29:49,600 --> 00:29:52,300
owner cannot control it in there
too. 

512
00:29:52,600 --> 00:29:55,700
So we have a special mechanism 
just like withdraw automatically

513
00:29:55,900 --> 00:29:58,300
and the studio trustless. 
It's enforced by the protocol. 

514
00:29:58,300 --> 00:30:01,400
It's a part of the start so it 
can always be done. 

515
00:30:01,400 --> 00:30:04,300
So you like you never are in a 
risk. 

516
00:30:04,500 --> 00:30:09,600
Of losing any funds, like, no 
matter what you do, like, unless

517
00:30:09,600 --> 00:30:13,300
you send it to address 0, like 
any normal mistakes are 

518
00:30:13,308 --> 00:30:17,800
tolerated. 
Cuz that that's super nice on 

519
00:30:18,100 --> 00:30:22,900
the usability side. 
So now I have say slightly less 

520
00:30:22,900 --> 00:30:26,000
than an ether on layer 2. 
How much, how much would it cost

521
00:30:26,000 --> 00:30:29,500
me in gas to actually transfer 
one ether from layer 1 to day or

522
00:30:29,508 --> 00:30:33,700
two? 
It cost is slightly more than a 

523
00:30:33,708 --> 00:30:37,700
normal is a transfer. 
Okay, that's that's not so bad. 

524
00:30:38,000 --> 00:30:42,100
And then I, I now have say 
slightly less than an ether on 

525
00:30:42,108 --> 00:30:45,600
there, too. 
How do I send it to someone 

526
00:30:45,600 --> 00:30:47,300
else? 
Do I need a special wallet or 

527
00:30:47,300 --> 00:30:50,600
can I do it from Madam asked? 
Well, how do I go about it? 

528
00:30:52,200 --> 00:30:54,600
Currently you need a special 
wallet. 

529
00:30:55,000 --> 00:30:59,700
What you can use is our 
web-based wallet, which you you 

530
00:30:59,700 --> 00:31:03,000
can control with metal mask or 
any world connect enable wallet,

531
00:31:04,000 --> 00:31:08,400
which will derive a signing key 
for zika sink and store it in 

532
00:31:08,400 --> 00:31:12,200
your browser memory. 
And then you can use it to send 

533
00:31:12,200 --> 00:31:14,800
transactions. 
Although, you will always have 

534
00:31:14,800 --> 00:31:17,800
to co-sign this transaction by 
Madame Masque as well. 

535
00:31:17,800 --> 00:31:19,700
So we have a kind of two-factor 
protection. 

536
00:31:20,300 --> 00:31:23,200
We require Irma, Thomas 
signature, which is verified by 

537
00:31:23,200 --> 00:31:26,500
our service. 
This is version one in version. 

538
00:31:26,500 --> 00:31:30,600
2, you will be able to just sign
it with Madam asked directly. 

539
00:31:30,600 --> 00:31:33,500
We will support the theorems of 
interest natively in dkc2. 

540
00:31:35,000 --> 00:31:38,600
Is it dangerous? 
That part of the signature is 

541
00:31:39,000 --> 00:31:42,200
stored in browser? 
Because that sounds like a bad 

542
00:31:42,200 --> 00:31:45,700
idea. 
Well, whether that of course, 

543
00:31:45,700 --> 00:31:49,000
it's not that it's not ideal. 
That would be the case. 

544
00:31:49,000 --> 00:31:52,800
If you use our web-based wallet,
if you use any wallet that 

545
00:31:52,800 --> 00:31:57,500
natively supports the key sink 
such as Argent or hobby wallet, 

546
00:31:57,500 --> 00:32:02,700
or I am talking then, of course,
you don't have to see the 

547
00:32:02,900 --> 00:32:04,700
situation. 
You can just pick you, you will 

548
00:32:04,700 --> 00:32:08,400
use it, the inside, the wallet 
and the private key will never 

549
00:32:08,400 --> 00:32:12,200
leave the wallet. 
So when you're looking for a 

550
00:32:12,200 --> 00:32:16,400
flight, You go through a flight,
aggregator to see all the 

551
00:32:16,400 --> 00:32:19,200
different places where you can 
buy the fly to get all the 

552
00:32:19,200 --> 00:32:23,200
options and make sure you get 
the best price for your travel 

553
00:32:23,200 --> 00:32:25,700
plans. 
And when you're making a defy 

554
00:32:25,700 --> 00:32:28,800
swap, just do the same and use 
para swap. 

555
00:32:29,300 --> 00:32:32,200
It beats the market prices 
across all the major indexes, 

556
00:32:32,200 --> 00:32:35,100
because it Aggregates them and 
thanks to their network of 

557
00:32:35,100 --> 00:32:39,200
professional market makers. 
You get zero slippage on your 

558
00:32:39,200 --> 00:32:41,600
trades. 
So they just push the huge 

559
00:32:41,700 --> 00:32:43,000
update. 
That's even faster. 

560
00:32:43,100 --> 00:32:44,900
More liquid. 
Thanks to a brand new. 

561
00:32:44,900 --> 00:32:49,000
Algorithm / swap is now multi 
chain and has expanded polygon 

562
00:32:49,000 --> 00:32:51,800
and bind and smart chain. 
So go and check it out. 

563
00:32:51,800 --> 00:32:56,000
Give para swap at try at 
Periscope dot IO, / epicenter. 

564
00:32:57,800 --> 00:33:01,700
We talked about moving East into
ZK sink. 

565
00:33:02,000 --> 00:33:04,700
Can you move tokens natively in 
to seek a sink or do you have to

566
00:33:04,700 --> 00:33:07,100
first move? 
Ethan then somehow like convert 

567
00:33:07,100 --> 00:33:09,000
them there or how does that 
work? 

568
00:33:10,900 --> 00:33:13,700
No, it can natively deposit, 
your seat, many tokens. 

569
00:33:14,000 --> 00:33:18,100
And we also need the support 
network transactions, inside the

570
00:33:18,100 --> 00:33:21,000
casing. 
So you don't need if or 

571
00:33:21,000 --> 00:33:24,400
anything, or at like Zeke is in 
talking to some transactions. 

572
00:33:24,800 --> 00:33:27,800
You can deposit die and then pay
your fees and diet. 

573
00:33:29,000 --> 00:33:32,000
So the what it said, support, ZK
think they natively. 

574
00:33:32,300 --> 00:33:34,300
Send the transactions to the 
sequencer. 

575
00:33:34,300 --> 00:33:37,300
Then this is crap. 
The sequencer. 

576
00:33:37,300 --> 00:33:39,500
This is currently one 
centralized party, which I 

577
00:33:39,508 --> 00:33:42,000
assume is somehow affiliated. 
It with you guys, but will be 

578
00:33:42,000 --> 00:33:44,200
sequentially decentralized. 
Yes. 

579
00:33:44,200 --> 00:33:46,900
That's correct. 
It's the sequencer. 

580
00:33:47,600 --> 00:33:51,400
The operator in a sense, OSS 
separate operator. 

581
00:33:52,200 --> 00:33:55,100
You can go with the operator. 
Sits block producer. 

582
00:33:55,100 --> 00:33:57,400
It's someone who collects the 
transactions and just puts them 

583
00:33:57,400 --> 00:33:59,800
in the block. 
Okay, but this there are also 

584
00:33:59,800 --> 00:34:04,600
validators, right? 
The validators are the general 

585
00:34:04,600 --> 00:34:08,199
term for when you have a 
consensus driven by proof of 

586
00:34:08,199 --> 00:34:10,500
stake. 
This is what we plan. 

587
00:34:10,600 --> 00:34:13,800
To have so that then they will 
be called validators. 

588
00:34:14,100 --> 00:34:15,600
Okay. 
So basically currently the 

589
00:34:15,600 --> 00:34:19,699
sequencer replaces the 
validators and who will then be 

590
00:34:19,699 --> 00:34:23,500
the block producers? 
Well, the validators will act as

591
00:34:23,500 --> 00:34:25,900
a collective sequencer. 
I would put this way. 

592
00:34:27,400 --> 00:34:31,199
How do I withdraw funds to layer
1 and what's the time scale for 

593
00:34:31,199 --> 00:34:32,900
this? 
Because this is one of the 

594
00:34:33,300 --> 00:34:35,600
Achilles years of optimism, 
right? 

595
00:34:35,600 --> 00:34:39,000
So basically there because you 
have to you have the entire 

596
00:34:39,000 --> 00:34:42,699
thing around prop grooves and so
on, you actually have super long

597
00:34:42,699 --> 00:34:46,900
with drier periods. 
This is true to throw from 

598
00:34:46,900 --> 00:34:47,699
optimistic. 
Roll-Ups. 

599
00:34:47,699 --> 00:34:50,600
You natively, need? 
One week, which can be 

600
00:34:50,600 --> 00:34:52,699
mitigated. 
If you have liquidity providers,

601
00:34:52,900 --> 00:34:55,199
who will pour you, some funds on
where one? 

602
00:34:55,199 --> 00:34:56,600
But this is going to be 
expensive. 

603
00:34:56,900 --> 00:34:59,500
We seek a Roll-Ups in the casing
specifically. 

604
00:34:59,700 --> 00:35:02,600
What you do is you submit a 
transaction to the sequencer, 

605
00:35:03,100 --> 00:35:07,200
asking them to withdraw, the 
funds for you, on their one, and

606
00:35:07,400 --> 00:35:09,200
they will include in the block 
and the moment. 

607
00:35:09,200 --> 00:35:12,100
The block is completed and 
verified any Theory. 

608
00:35:12,100 --> 00:35:14,800
Mmm, you will automatically get 
the funds on. 

609
00:35:15,000 --> 00:35:17,000
Um, to the address, which you 
wished. 

610
00:35:17,300 --> 00:35:19,200
So this is one way, this is the 
normal way. 

611
00:35:19,700 --> 00:35:23,000
In this scenario. 
Your transaction could be 

612
00:35:23,000 --> 00:35:28,600
censured and then you can also 
go and you have a second option,

613
00:35:28,600 --> 00:35:32,100
which is the priority queue I 
mentioned before we make a 

614
00:35:32,100 --> 00:35:38,400
transaction on layer one and you
put a record on the Queue, which

615
00:35:38,400 --> 00:35:43,000
must be processed by the 
sequencer in within some, some 

616
00:35:43,000 --> 00:35:46,000
time frame, but it wasn't one 
day or something. 

617
00:35:46,600 --> 00:35:50,500
And if they fail to do this, 
then the system will enter 

618
00:35:50,500 --> 00:35:53,500
emergency exit mode where you 
will be able to just prove 

619
00:35:53,500 --> 00:35:56,100
ownership of your funds and 
withdraw them directly on their 

620
00:35:56,100 --> 00:35:59,300
one. 
This has never happened before. 

621
00:35:59,300 --> 00:36:03,700
I doubt this will ever happen 
because the, the validators, or 

622
00:36:03,700 --> 00:36:07,300
the operator never has an 
incentive to, to censor users. 

623
00:36:07,800 --> 00:36:11,200
Since they know this threat is, 
is valid and they will just like

624
00:36:11,200 --> 00:36:15,400
lose credibility. 
But in normal circumstances, You

625
00:36:15,400 --> 00:36:19,400
only have to wait for the block 
to get filled and for the prove 

626
00:36:19,400 --> 00:36:21,900
to be generated for this block 
and submit it to the theorem 

627
00:36:22,200 --> 00:36:27,000
which with busy kissing. 
One takes approximately four, 

628
00:36:27,100 --> 00:36:31,400
four hours right now. 
Like it depends on the group on 

629
00:36:31,400 --> 00:36:33,900
the actual usage of the system. 
Like, the more blocks. 

630
00:36:33,900 --> 00:36:39,400
We have, the faster they get 
generated and you also have an 

631
00:36:39,400 --> 00:36:43,100
option of fast exit. 
If you need some funds 

632
00:36:43,100 --> 00:36:48,200
immediately you cannot Opt-in 
into paying the block 

633
00:36:48,200 --> 00:36:52,300
verification overhead yourself. 
And then the book will be 

634
00:36:52,300 --> 00:36:54,500
immediately closed and 
immediately submitted for 

635
00:36:54,500 --> 00:36:56,500
verification. 
Yeah. 

636
00:36:56,500 --> 00:36:59,100
You also have to wait for the 
prove to be generated for the 

637
00:36:59,100 --> 00:37:02,000
start to be generated which 
which is not longer. 

638
00:37:02,000 --> 00:37:05,700
It only takes something like 20 
minutes right now, and it will 

639
00:37:05,700 --> 00:37:11,200
be even lower with version 2. 
Because we are building it in in

640
00:37:11,200 --> 00:37:14,400
the very parallel way 
recursively. 

641
00:37:15,200 --> 00:37:16,600
It would go down to a few 
minutes. 

642
00:37:18,000 --> 00:37:21,800
So that means that blocks the 
standard thing for Block is to 

643
00:37:21,800 --> 00:37:25,400
be full, right, but then the, 
the block time can vary, is that

644
00:37:25,400 --> 00:37:29,100
correct? 
Yes, we expect the blocks to be 

645
00:37:29,100 --> 00:37:32,100
full. 
So if you have, let's say 1,000 

646
00:37:32,100 --> 00:37:38,900
transactions per in 10 minutes 
than and the block size is 1000.

647
00:37:38,900 --> 00:37:42,100
Then your book completeness time
will be 10 minutes. 

648
00:37:43,700 --> 00:37:47,800
I mean to basically then the 
sequencer submits this to to 

649
00:37:47,800 --> 00:37:50,000
layer 1. 
And how do you then Gear with 

650
00:37:50,000 --> 00:37:52,500
real works? 
Because this is also often a 

651
00:37:52,500 --> 00:37:53,900
problem with layer tools. 
Right? 

652
00:37:53,900 --> 00:37:58,400
So basically if layer 1 re Orcs,
how do you make sure that when 

653
00:37:58,400 --> 00:38:00,500
people have already cashed out 
based on? 

654
00:38:00,800 --> 00:38:05,400
I mean, how does this work? 
There is absolutely no problem 

655
00:38:05,400 --> 00:38:09,100
with reworks fundamentally 
because if are York happens, 

656
00:38:09,500 --> 00:38:13,600
then the cash outs will be 
reverted first so they will just

657
00:38:13,600 --> 00:38:16,800
be erased and never happen. 
So what we, how we, combine 

658
00:38:16,800 --> 00:38:23,900
three works is we require a, I 
think ten blocks confirmed 10 

659
00:38:23,900 --> 00:38:28,500
confirmations after the deposit 
to appear in the casing. 

660
00:38:29,000 --> 00:38:31,900
So whenever you do a deposit, we
wait for ten blocks before you 

661
00:38:31,900 --> 00:38:34,400
see this. 
This amount on your balance 

662
00:38:35,000 --> 00:38:39,200
before like did before the the 
the operator will actually 

663
00:38:39,200 --> 00:38:41,300
process it and include in the 
next block. 

664
00:38:41,700 --> 00:38:45,300
So this way we can prevent the 
Casual re Orcs which happen 

665
00:38:46,200 --> 00:38:50,200
cerium with one or two blocks 
back because of fluctuations of 

666
00:38:50,200 --> 00:38:55,500
uncles and this is only to 
prevent negative user experience

667
00:38:55,500 --> 00:38:59,500
because if the reorg happened on
the deposit, then we would have 

668
00:38:59,500 --> 00:39:02,300
to roll back. 
All the transactions that depend

669
00:39:02,300 --> 00:39:03,100
on this. 
Deposit. 

670
00:39:03,100 --> 00:39:06,900
And it can be a lot because they
can you send it to some people? 

671
00:39:06,900 --> 00:39:10,200
And then decided to further 
people in the spreads, but it 

672
00:39:10,200 --> 00:39:13,700
would be grey or happens, which 
would go back more than 10 

673
00:39:13,700 --> 00:39:15,700
blocks. 
Then we will just roll back the 

674
00:39:15,700 --> 00:39:20,900
database to the point where 
they're York correspond, where 

675
00:39:20,900 --> 00:39:24,900
the the root hash of the 
database would correspond to the

676
00:39:24,900 --> 00:39:28,700
previous root hash recorded on 
the smart contract to the point 

677
00:39:28,700 --> 00:39:33,500
of York, and we would also try 
to reapply the Transactions that

678
00:39:33,500 --> 00:39:36,700
were collected. 
So if we work was non-essential,

679
00:39:37,600 --> 00:39:41,700
if it didn't actually modify a 
lot of balances and did not 

680
00:39:41,700 --> 00:39:45,500
affect deposits, then we will be
able to reconstruct all the 

681
00:39:45,500 --> 00:39:48,500
transactions in layer to 
natively and users will not 

682
00:39:48,500 --> 00:39:51,500
notice anything. 
If it affected deposits, then 

683
00:39:51,500 --> 00:39:54,000
some of these transactions will 
fail because there is not enough

684
00:39:54,000 --> 00:39:56,900
funds and then they will cause 
other transactions to fail 

685
00:39:56,900 --> 00:39:59,700
potentially because users would 
send funds further. 

686
00:40:00,000 --> 00:40:07,100
But as I said, It does not 
affect the Ezekiel up in 

687
00:40:07,100 --> 00:40:08,800
anywhere from the security 
perspective. 

688
00:40:09,500 --> 00:40:12,100
We're which is bound to 
aetherium for finality. 

689
00:40:14,000 --> 00:40:18,000
You mentioned a while ago that 
it's possible for for someone to

690
00:40:18,000 --> 00:40:20,700
close the block by paying the 
entire like the fee. 

691
00:40:20,700 --> 00:40:22,500
Basically. 
Like it does not introduce any 

692
00:40:22,500 --> 00:40:25,100
denial of service attacks where 
one could just continuously. 

693
00:40:25,100 --> 00:40:27,000
Just be like a pain to close 
blocked before. 

694
00:40:27,000 --> 00:40:30,000
Anybody can get transactions in.
Is that something that is 

695
00:40:30,000 --> 00:40:31,800
possible? 
No. 

696
00:40:31,800 --> 00:40:36,900
No, it's more for you to 
understand the cost structure of

697
00:40:36,900 --> 00:40:40,800
Ezekiel roll up. 
Every transaction must include 

698
00:40:40,900 --> 00:40:43,400
some fee to pay for the 
Unchained part of this 

699
00:40:43,400 --> 00:40:47,600
transaction. 
Plus additionally an amortized 

700
00:40:47,600 --> 00:40:51,500
cost of a proof. 
So you can, you could 

701
00:40:51,500 --> 00:40:55,700
theoretically include approved 
for every blog even if the 

702
00:40:55,700 --> 00:40:58,900
blocks are small, even if blocks
contain just one transaction, 

703
00:40:59,400 --> 00:41:01,300
but that would be super 
expensive. 

704
00:41:01,400 --> 00:41:05,000
That would be a in anti scaling 
solution because you would pay a

705
00:41:05,008 --> 00:41:07,800
lot more for a simple 
transaction than you were doing 

706
00:41:07,800 --> 00:41:10,600
there one. 
So, the more transactions you 

707
00:41:10,600 --> 00:41:16,200
include in the block, the The 
more the higher, the 

708
00:41:16,200 --> 00:41:21,100
denominator, by which they prove
cost is divided. 

709
00:41:22,400 --> 00:41:25,600
It's kind of like going from 
flying commercial to Flying 

710
00:41:25,600 --> 00:41:28,400
private and saying, I just can't
wait the three hours for the 

711
00:41:28,400 --> 00:41:30,800
next commercial. 
Plane to go from Berlin to say 

712
00:41:30,800 --> 00:41:36,500
Moscow and I chartered a private
plane by the in this analogy. 

713
00:41:36,500 --> 00:41:39,600
It would be a rather like you 
wait. 

714
00:41:39,800 --> 00:41:44,100
So you have one passenger, two 
passengers, 10 passengers in 

715
00:41:44,100 --> 00:41:48,200
this one, big boy, which has a 
fixed cost of flying from from 

716
00:41:48,300 --> 00:41:51,500
one place to another. 
And, and at some point you say 

717
00:41:51,500 --> 00:41:53,300
like, okay, I Want to wait for 
anyone else? 

718
00:41:53,300 --> 00:41:54,300
Let's fly. 
Now. 

719
00:41:54,500 --> 00:41:57,800
I'm going to play like the all 
the basic cost, and you just 

720
00:41:57,800 --> 00:41:59,900
close the gate and that you've 
left by immediately without 

721
00:41:59,900 --> 00:42:02,000
waiting for other people. 
They will just catch connections

722
00:42:02,000 --> 00:42:04,500
next slide because the next 
flight will be immediately 

723
00:42:04,500 --> 00:42:06,800
available after the first one to
parks. 

724
00:42:08,200 --> 00:42:10,700
That's what of the scenario in 
which I was thinking is, like, 

725
00:42:10,700 --> 00:42:15,400
couldn't someone who wanted to 
to censor the network or to do a

726
00:42:15,400 --> 00:42:16,700
denial of service attack, just 
by. 

727
00:42:16,700 --> 00:42:19,600
Like every time there's a new 
box just like by up the entire 

728
00:42:19,600 --> 00:42:22,400
block, you know, if they had if 
have unlimited money. 

729
00:42:23,800 --> 00:42:28,200
No, because all the transactions
that collected by the time he 

730
00:42:28,200 --> 00:42:30,800
does, this will be just 
including in this block. 

731
00:42:31,100 --> 00:42:35,000
So this person will be just 
subsidizing everyone at lower 

732
00:42:35,000 --> 00:42:38,900
low latency. 
So just to summarize this. 

733
00:42:39,300 --> 00:42:45,300
So when I do a transaction on ZK
sink, I pay a small fee that is 

734
00:42:45,300 --> 00:42:49,800
associated with the overhead of 
my transaction being included 

735
00:42:49,800 --> 00:42:55,300
and a part of the overhead cost 
of the ZK sink proof of the 

736
00:42:55,300 --> 00:42:58,200
verification of the verification
cost of the proof. 

737
00:42:58,200 --> 00:42:59,200
That this is correct. 
Yes. 

738
00:42:59,300 --> 00:43:02,000
So the verification Costco 
snarks for too long proof 

739
00:43:02,000 --> 00:43:04,900
system, which we use is 
currently around half a million 

740
00:43:04,900 --> 00:43:08,400
guests on a theorem. 
But that means because you're 

741
00:43:08,400 --> 00:43:11,400
still dependent on the gas price
on day one. 

742
00:43:11,600 --> 00:43:15,600
The fee is on layer 2 will 
actually fluctuate with the fees

743
00:43:15,600 --> 00:43:17,800
or Nao and right. 
This is correct. 

744
00:43:17,800 --> 00:43:19,700
Yes. 
Okay. 

745
00:43:19,700 --> 00:43:23,400
So you currently do you 
currently have a token or do you

746
00:43:23,400 --> 00:43:28,800
still plan on introducing one? 
We don't have a dock in now, but

747
00:43:28,800 --> 00:43:31,900
we will require a token for 
multiple reasons. 

748
00:43:32,300 --> 00:43:36,000
One is decentralization of this 
sequencer to have multiple 

749
00:43:36,000 --> 00:43:39,200
validators who decide on what's 
going in the blocks. 

750
00:43:40,200 --> 00:43:43,300
And the other very important 
reason is Introduction of 

751
00:43:43,300 --> 00:43:47,800
Ezekiel Porter, a all chain 
scaling solution, which will 

752
00:43:47,800 --> 00:43:51,600
augment Zeki, roll up. 
It will serve as a is a 

753
00:43:52,100 --> 00:43:55,700
extension of the Corolla. 
Tell us about CK Porter. 

754
00:43:57,000 --> 00:44:00,600
Susie Q. 
Porter is, is a, is an 

755
00:44:00,600 --> 00:44:05,500
interesting idea. 
Where, in the casing 2.0, you 

756
00:44:05,500 --> 00:44:09,200
will have two types of accounts.
Zeki roll-up type of account, 

757
00:44:09,400 --> 00:44:13,500
which will act and cost the same
as what you expect from the 

758
00:44:13,500 --> 00:44:15,500
Corolla. 
So you have the Ultimate 

759
00:44:15,500 --> 00:44:20,600
Security from the theorem and 
you will have to pay a like you 

760
00:44:20,600 --> 00:44:23,200
will, you will get a linear 
scalability boost. 

761
00:44:23,200 --> 00:44:26,400
So you will always play around 
100 of. 

762
00:44:26,800 --> 00:44:31,400
Beware one cost, but then you 
will have an optional, Zeki 

763
00:44:31,400 --> 00:44:34,200
Porter, account type, which you 
can choose the user. 

764
00:44:34,900 --> 00:44:39,000
And if you transact with 
insecure Porter with you, only 

765
00:44:39,000 --> 00:44:41,500
interact with others, you keep 
our accounts, you will pay a 

766
00:44:41,508 --> 00:44:47,500
very small fees that are 
independent from the gas price 

767
00:44:47,500 --> 00:44:51,300
and aetherium because the data 
will not be published through 

768
00:44:51,300 --> 00:44:54,800
the appearing Network. 
The the states of those accounts

769
00:44:54,800 --> 00:44:59,200
will be only published. 
To the so-called Ezekiel Porter 

770
00:44:59,200 --> 00:45:02,900
Guardians, who will keep the the
data for you. 

771
00:45:02,900 --> 00:45:07,400
And they will confirm each block
with the majority or 

772
00:45:07,400 --> 00:45:12,500
supermajority of the weighted 
stake to guarantee that this 

773
00:45:12,500 --> 00:45:16,000
data is available. 
Sorry, what's the secret Porter?

774
00:45:17,500 --> 00:45:19,900
Zebra has this new architecture.
I'm just grabbing. 

775
00:45:20,500 --> 00:45:25,100
We just so we it's it's an 
alternative account type in 

776
00:45:25,100 --> 00:45:28,600
decreasing to you have zero up 
accounts and the Q Porter 

777
00:45:28,600 --> 00:45:30,500
accounts in. 
You can freely choose as a user 

778
00:45:30,500 --> 00:45:33,500
between the two. 
And if you, if you opt for Zeki 

779
00:45:33,500 --> 00:45:37,900
Porter, you will have very, very
low fees and also decrease 

780
00:45:37,900 --> 00:45:39,700
security. 
You will not get the same 

781
00:45:39,700 --> 00:45:42,500
security as woodsy Kerala. 
That's why we recommend. 

782
00:45:42,500 --> 00:45:47,400
We will encourage all the others
to keep most of the funds most A

783
00:45:47,400 --> 00:45:51,200
fortune in the Z key role of 
accounts, but for some smaller 

784
00:45:51,200 --> 00:45:55,300
spendings for micro transactions
for trying out things, maybe for

785
00:45:55,300 --> 00:45:59,300
high frequency, high frequency 
trading, you can use Z key part 

786
00:45:59,300 --> 00:46:02,200
accounts. 
And as long as the total value 

787
00:46:02,300 --> 00:46:06,900
locked in Zeki, Porter accounts 
is lower than the steak of the 

788
00:46:06,900 --> 00:46:09,200
keep order. 
It's actually economically. 

789
00:46:09,200 --> 00:46:12,700
Secure, doesn't make sense of 
the validator to try to attack 

790
00:46:12,700 --> 00:46:16,800
the system. 
So, is it kind of like a POA 

791
00:46:16,800 --> 00:46:21,600
layer 3 on layer 2? 
It's more like a side side 

792
00:46:21,600 --> 00:46:25,700
chain. 
So it's an extension of Z key 

793
00:46:25,700 --> 00:46:30,500
roll up into a side chain with a
very interesting property from 

794
00:46:30,500 --> 00:46:34,600
this side chain, you can 
seamlessly interoperate with any

795
00:46:34,600 --> 00:46:37,600
account in this icky, roll up. 
So you can have a single 

796
00:46:37,600 --> 00:46:43,000
transaction that spans across 
multiple accounts involving both

797
00:46:43,000 --> 00:46:44,700
zero weapons. 
You keep our accounts. 

798
00:46:45,000 --> 00:46:49,400
So, for example, what this means
is you can have a lot of you. 

799
00:46:49,600 --> 00:46:53,500
Us, who are, who cannot afford 
to be on zucchero up, because 

800
00:46:53,500 --> 00:46:58,200
they grow up eventually etherium
gas prices, will go up a lot 

801
00:46:58,200 --> 00:47:01,300
because we'll have a lot more 
users hundred times thousand 

802
00:47:01,300 --> 00:47:04,800
times more users at its 
individual, that they will go 

803
00:47:04,800 --> 00:47:09,700
up, even if we all use later 
Solutions, so, some users will 

804
00:47:09,700 --> 00:47:12,200
just not be able to participate.
It's just kind of too expensive 

805
00:47:12,200 --> 00:47:14,300
for them, but they can stay on 
Zeki portents. 

806
00:47:14,300 --> 00:47:18,400
I'd pay very low fees, but still
interact with Eunice swap 

807
00:47:18,400 --> 00:47:21,700
compound. 
Bouncer curve all the protocols,

808
00:47:21,700 --> 00:47:25,900
defy particles on the Z, key 
roll up side, where all the 

809
00:47:25,900 --> 00:47:30,600
whales are and all the, the 
other users everyone, but they 

810
00:47:30,600 --> 00:47:33,100
will still pay a very small fees
for that. 

811
00:47:34,800 --> 00:47:38,100
It's crazy that we're already 
anticipating a time in a world 

812
00:47:38,100 --> 00:47:40,600
in which there are two 
solutions, are also too 

813
00:47:40,600 --> 00:47:45,000
expensive to use and so we need 
to move to other layers. 

814
00:47:45,400 --> 00:47:47,300
This is what we observed with 
etherium. 

815
00:47:47,300 --> 00:47:52,700
The number of users over the 
past year Rose approximately 12,

816
00:47:52,700 --> 00:47:59,000
x 13 x, but the gas prices Rose 
square of that. 

817
00:47:59,900 --> 00:48:02,900
So we can only it's only natural
to expect that. 

818
00:48:02,900 --> 00:48:06,200
The same thing will sooner 
rather than later happen to wear

819
00:48:06,200 --> 00:48:11,900
to because the this cold induced
demand, once you have a lot more

820
00:48:11,900 --> 00:48:16,400
opportunities to trade and you 
in do anything, he's and do a 

821
00:48:16,400 --> 00:48:21,200
lot of interesting things in 
there to more people will do it 

822
00:48:21,300 --> 00:48:25,000
a lot more frequently and this 
will drive the prices up again. 

823
00:48:26,400 --> 00:48:29,900
So Alex, you kind of already 
alluded to this, but this also 

824
00:48:29,900 --> 00:48:34,300
means that ZK sync is also smart
contract compatible, right? 

825
00:48:35,600 --> 00:48:39,400
Yes OC kissing to will have not 
just smart contracts but full 

826
00:48:39,400 --> 00:48:42,900
evm compatibility or like if you
have portability, you will be 

827
00:48:42,900 --> 00:48:45,700
able to take existing smart, 
contracts, that are life on 

828
00:48:45,700 --> 00:48:50,600
where one and easily Port them 
to zq sink and just deploy auto 

829
00:48:50,600 --> 00:48:52,300
box. 
Most of them will just work. 

830
00:48:53,100 --> 00:48:56,400
So that means you redeploy, 
essentially, as my contract, 

831
00:48:56,400 --> 00:49:00,400
that was deployed to aetherium. 
Does that does that imply, any 

832
00:49:00,400 --> 00:49:04,800
ability for users of say like an
arc, 20 token that was deployed 

833
00:49:04,800 --> 00:49:06,900
on one? 
Contracts to interoperate we 

834
00:49:06,900 --> 00:49:09,000
did. 
Can you move assets from one 

835
00:49:09,000 --> 00:49:12,400
Contracting through the other? 
Or they what kind of interesting

836
00:49:12,400 --> 00:49:15,600
dynamics that might exist 
between those two layers. 

837
00:49:17,100 --> 00:49:18,600
Absolutely. 
Sure. 

838
00:49:18,600 --> 00:49:23,200
So you will have this our design
of ZK e VM was to keep all the 

839
00:49:23,200 --> 00:49:26,000
properties from etherium, 
including a possibility. 

840
00:49:26,400 --> 00:49:29,100
If you deploy multiple 
contracts, they will be able to 

841
00:49:29,100 --> 00:49:31,200
interact with each other. 
Just the same way. 

842
00:49:31,600 --> 00:49:35,900
It's kinda possible in aetherium
in atomic transactions, that can

843
00:49:36,500 --> 00:49:41,100
can all execute or can revert 
partially like everything that 

844
00:49:41,400 --> 00:49:45,300
will just look and feel exactly 
the same as any theorem layer 1.

845
00:49:47,000 --> 00:49:49,700
Okay, so you could have 
essentially like a transaction 

846
00:49:49,700 --> 00:49:52,300
where, you know, for example, 
like you're kind of building a 

847
00:49:52,308 --> 00:49:56,300
complex transaction where you 
like mint died on the CDP and 

848
00:49:56,300 --> 00:49:58,900
then you take that died and like
I don't trade it on you and swap

849
00:49:58,900 --> 00:50:02,000
or something like, you know, you
do some other action, you could 

850
00:50:02,000 --> 00:50:04,700
do some sort of like cross-layer
transactions, where you meant 

851
00:50:04,700 --> 00:50:09,400
died on the CDP and then, that 
died gets sent immediately into 

852
00:50:09,400 --> 00:50:13,600
say, like I am M or a decks on 
on zika. 

853
00:50:13,600 --> 00:50:15,600
Roll-up. 
Is that is that possible or is? 

854
00:50:15,700 --> 00:50:17,100
They're like some extra 
complexity there. 

855
00:50:18,300 --> 00:50:20,900
You mean like moving funds 
between layer 1 and layer 2. 

856
00:50:21,700 --> 00:50:24,300
Yeah, like in a sing in sort of 
like a single in a single 

857
00:50:24,300 --> 00:50:28,000
transaction. 
So the you can never have layer 

858
00:50:28,000 --> 00:50:30,300
1, layer 2 interaction in the 
single transaction. 

859
00:50:30,700 --> 00:50:34,300
It's always a synchronous 
because the blocks are only 

860
00:50:34,300 --> 00:50:39,100
committed to etherium once in a 
while and anything can happen in

861
00:50:39,100 --> 00:50:42,600
between those blocks of you will
have and a synchronous calls 

862
00:50:42,600 --> 00:50:44,500
between layer 1 and layer 2, 
both ways. 

863
00:50:45,000 --> 00:50:49,300
You can use, you can send and 
some message with some funds 

864
00:50:49,300 --> 00:50:53,800
from layer 1 to layer 2, and it 
will eventually appear there, 

865
00:50:53,800 --> 00:50:55,500
and will interact with the 
contract. 

866
00:50:55,800 --> 00:50:59,000
And you can do it the other way 
around, or you can have Atomic 

867
00:50:59,000 --> 00:51:03,600
transactions within layer to 
that that happened inside once 

868
00:51:03,600 --> 00:51:08,500
in transaction, but you can, you
can't extend that to layer 1 to 

869
00:51:08,500 --> 00:51:11,600
layer 2. 
Okay, so you can have Atomic 

870
00:51:11,600 --> 00:51:14,400
transactions just as you do on 
their one, but there's no Atomic

871
00:51:14,400 --> 00:51:17,300
transactions like between R1 and
R2, correct? 

872
00:51:18,100 --> 00:51:22,100
So what are the applications 
that you would say ZK sink is 

873
00:51:22,100 --> 00:51:25,300
particularly well suited to? 
Or do you think it's equally 

874
00:51:25,300 --> 00:51:31,000
well suited to all applications?
I personally think that most 

875
00:51:31,000 --> 00:51:34,900
applications within a year. 
We'll be on Decay roll up. 

876
00:51:35,500 --> 00:51:38,000
Most of the theorem will migrate
Izzy, Kerala by. 

877
00:51:38,500 --> 00:51:42,400
I can't imagine any alternative.
Like I just don't see a 

878
00:51:42,400 --> 00:51:46,200
plausible alternative to that 
because Ezekiel up offers 

879
00:51:46,700 --> 00:51:49,700
Superior properties to any other
scaling solution. 

880
00:51:49,800 --> 00:51:53,000
So I don't get me wrong. 
I'm really excited about is 

881
00:51:53,000 --> 00:51:55,600
getting Solutions launching. 
Now, it's really important that 

882
00:51:55,800 --> 00:52:01,000
if you're in can scale today, Ev
even if we have to take some 

883
00:52:01,200 --> 00:52:05,500
trade-offs into account, but me 
to log term is e. 

884
00:52:05,500 --> 00:52:07,800
Key. 
Roll-Ups are just better in 

885
00:52:07,800 --> 00:52:10,700
every possible regard. 
I don't see any other any reason

886
00:52:10,700 --> 00:52:14,300
not to be on the Z key role. 
So they are cheaper, even if you

887
00:52:14,300 --> 00:52:17,800
just compare the the Z key, the 
role of transactions, they 

888
00:52:17,800 --> 00:52:20,800
cheaper than let's say 
optimistic Roll-Ups because you 

889
00:52:20,800 --> 00:52:24,800
need to put this data on chain 
and you also can have some super

890
00:52:24,800 --> 00:52:28,900
linear scaling if multiple 
accounts if the Same accounts do

891
00:52:28,900 --> 00:52:31,400
multiple transactions in the 
same block, which is, for 

892
00:52:31,400 --> 00:52:35,000
example, the case, if you if you
do a lot of frequent Oracle 

893
00:52:35,000 --> 00:52:39,300
updates because the Oracle 
updates only modify a single 

894
00:52:39,300 --> 00:52:42,000
variable on the contract. 
So you can do it like multiple 

895
00:52:42,000 --> 00:52:44,700
times and then at the end, you 
will only have one single update

896
00:52:44,700 --> 00:52:48,100
of the state or as an optimistic
grow up, you'll have to post 

897
00:52:48,200 --> 00:52:52,600
every single Oracle updates 
every so they cheaper on the 

898
00:52:52,600 --> 00:52:55,800
roll-up side. 
They have the option of these 

899
00:52:56,100 --> 00:53:01,300
super cheap side. 
Like Zeki Porter still with much

900
00:53:01,300 --> 00:53:05,300
improved security compared to 
side chains because the 

901
00:53:05,500 --> 00:53:07,700
validators, the Guardians Of Z 
q. 

902
00:53:07,700 --> 00:53:10,300
Porter can never corrupt the 
state. 

903
00:53:10,700 --> 00:53:13,300
The only thing that can go wrong
with the Z key partner, is that 

904
00:53:13,300 --> 00:53:16,800
the state has frozen, which is 
unlikely, because then how 

905
00:53:16,800 --> 00:53:19,400
you're going to exploit this? 
It can you would you would have 

906
00:53:19,400 --> 00:53:21,800
to Blackmail user somehow, it's 
complicated. 

907
00:53:21,800 --> 00:53:24,600
So a lot more complicated than 
in the side chain where you can 

908
00:53:24,600 --> 00:53:27,600
just grab all the assets and 
move them. 

909
00:53:28,000 --> 00:53:30,900
Two different atoms. 
And you have really nice 

910
00:53:30,900 --> 00:53:34,300
properties with user experience 
because the finality is fast, 

911
00:53:34,300 --> 00:53:37,800
you can withdraw funds instantly
from from the row up. 

912
00:53:37,900 --> 00:53:39,800
You can withdraw any fifties 
instantly. 

913
00:53:40,000 --> 00:53:43,600
You don't for entities. 
There is no mitigation for for 

914
00:53:43,600 --> 00:53:46,600
any fraud, proof based system. 
You will have to wait exactly 

915
00:53:46,600 --> 00:53:53,000
one week for your nft to go from
layer to layer one, but even for

916
00:53:53,000 --> 00:53:57,900
fungible tokens if you want to 
move some small amount of fun. 

917
00:53:58,600 --> 00:54:03,300
Than the entire Chain Solutions,
some State payment channels will

918
00:54:03,300 --> 00:54:05,600
help you. 
But if you want to move half of 

919
00:54:05,600 --> 00:54:09,500
the value locked in some 
protocol, that's probably going 

920
00:54:09,500 --> 00:54:12,400
to be problematic. 
It won't work as easily. 

921
00:54:13,100 --> 00:54:15,700
So all of these problems are 
solved to secure our laps. 

922
00:54:15,700 --> 00:54:18,600
So as soon as we can support 
fully VM compatibility and it 

923
00:54:18,800 --> 00:54:21,300
in, and it's hip. 
It's been proven and everyone 

924
00:54:21,300 --> 00:54:24,800
sees that it works on their one.
We expect most protocols to just

925
00:54:24,800 --> 00:54:30,400
go to Ezekiel up. 
So, what's the blocker with the 

926
00:54:30,400 --> 00:54:33,000
evm compatibility? 
Because that's not live on Main 

927
00:54:33,000 --> 00:54:33,800
net yet. 
Right? 

928
00:54:33,800 --> 00:54:37,600
That's still untested. 
So, that's that, that's kind of 

929
00:54:37,600 --> 00:54:39,800
built being built. 
So we just released our first 

930
00:54:39,800 --> 00:54:43,300
test that with is e KD M. 
And there is no block or 

931
00:54:43,300 --> 00:54:46,100
anymore. 
I can I can explain what was the

932
00:54:46,100 --> 00:54:48,300
blocker. 
Why it was only possible to 

933
00:54:48,300 --> 00:54:52,100
build this here? 
Why it was not not considered 

934
00:54:52,100 --> 00:54:54,200
before I gave a couple of talks 
on this. 

935
00:54:54,600 --> 00:55:00,300
So essentially the first Hero 
ups were application-specific. 

936
00:55:00,800 --> 00:55:05,500
They could only do some very 
limited fixed functionality, for

937
00:55:05,500 --> 00:55:12,100
example, transfers or or mmm or 
decks, but it was limited to to 

938
00:55:12,100 --> 00:55:15,500
one function, which could be 
repeated multiple times with 

939
00:55:15,600 --> 00:55:18,700
smart contracts. 
The challenge was that users 

940
00:55:18,700 --> 00:55:23,300
want to Define smart contracts 
themselves, and each smart 

941
00:55:23,300 --> 00:55:26,700
contract can be different in 
terms of code. 

942
00:55:26,700 --> 00:55:28,300
And in terms of Of the 
execution. 

943
00:55:28,300 --> 00:55:32,500
Length of this code execution 
Trace can vary depending on the 

944
00:55:32,500 --> 00:55:36,000
data you provide us input and 
depending on the function call 

945
00:55:36,000 --> 00:55:41,500
and what on What contract 
equality and this was very hard 

946
00:55:41,500 --> 00:55:45,800
to wrap in zero knowledge proof,
like zero-knowledge proofs 

947
00:55:45,800 --> 00:55:49,700
require the programs for which 
we can construct socks and 

948
00:55:49,700 --> 00:55:54,300
approve something visual 
statements to be converted 

949
00:55:54,300 --> 00:55:57,500
presentable. 
As arithmetic circuits you can 

950
00:55:57,600 --> 00:56:03,100
Think of it, as a as they like, 
as a physical circuit, you have 

951
00:56:03,100 --> 00:56:08,500
some inputs, and then it goes 
through some gates in like one 

952
00:56:08,500 --> 00:56:12,000
one-way flow without without 
that loops. 

953
00:56:12,300 --> 00:56:14,000
And then at the end, you get 
some results. 

954
00:56:14,400 --> 00:56:19,100
So the other way to think about 
it is a is a just a function 

955
00:56:19,600 --> 00:56:25,300
mathematical function. 
F from X is equal to a plus b 

956
00:56:25,300 --> 00:56:27,500
times C value. 
I know. 

957
00:56:27,600 --> 00:56:31,400
It's a very complex expression 
but it's a single expression is 

958
00:56:31,400 --> 00:56:33,800
no way to encode Loops in this 
expression. 

959
00:56:33,800 --> 00:56:38,000
There is no way to encode 
conditionals, except for just 

960
00:56:38,000 --> 00:56:41,400
like build, two, branches of 
this conditional statement 

961
00:56:41,400 --> 00:56:45,600
separately and then combine them
conditionally. 

962
00:56:45,600 --> 00:56:48,700
Like, if we wanted to go to the 
left Branch, then take this 

963
00:56:48,700 --> 00:56:50,600
result. 
If you want to go to the to 

964
00:56:50,600 --> 00:56:54,700
drive Branch take this result, 
but that, that's some fixed 

965
00:56:54,700 --> 00:56:56,300
structure which you cannot 
program. 

966
00:56:56,300 --> 00:57:02,200
So, how you add, Bility, so that
was the big challenge there were

967
00:57:02,200 --> 00:57:08,400
multiple approaches that allow 
that one was called. 

968
00:57:08,400 --> 00:57:13,800
Tiny Ram where you build a 
snark, which does not prove any 

969
00:57:13,800 --> 00:57:19,500
particular program, but can 
prove any program by executing 

970
00:57:20,200 --> 00:57:25,100
the opcodes of this program at 
every execution step. 

971
00:57:25,900 --> 00:57:29,800
It's a bit hard to explain in on
the podcast without the visuals 

972
00:57:29,800 --> 00:57:33,600
without going, like making some 
pictures, but you can imagine 

973
00:57:34,600 --> 00:57:40,100
just like a mathematical 
function, that executes every 

974
00:57:40,100 --> 00:57:42,700
possible, opcode at every 
possible step. 

975
00:57:43,000 --> 00:57:49,000
Just one big Matrix and times M,
where one side is the number of 

976
00:57:49,000 --> 00:57:53,200
opcodes, which you have in your 
virtual machine and the other 

977
00:57:53,200 --> 00:57:55,200
dimension is the number of 
steps. 

978
00:57:55,700 --> 00:57:58,300
Would you have to go to up to 
the very maximum? 

979
00:57:59,200 --> 00:58:01,900
If you do it naively? 
That would be very expensive. 

980
00:58:02,100 --> 00:58:05,600
That would give you a 1000 X 
over had over. 

981
00:58:05,600 --> 00:58:08,300
What, what is possible to prove 
in snart's and snacks are 

982
00:58:08,300 --> 00:58:13,200
already not cheap, you know, 
like we in our estimates, the 

983
00:58:13,200 --> 00:58:17,400
transactions on Zeki sink 2.0 
will cause something around one 

984
00:58:17,400 --> 00:58:20,100
cent per transaction for most 
defy protocols. 

985
00:58:20,600 --> 00:58:24,000
The one cent is okay, but if you
if you did like thousand X, it 

986
00:58:24,000 --> 00:58:25,400
will be hundred dollars for each
Passage. 

987
00:58:25,600 --> 00:58:29,200
Action, which would be a no go. 
So we needed some way to 

988
00:58:29,200 --> 00:58:32,100
optimize that and it came with 
recursion. 

989
00:58:32,700 --> 00:58:34,900
So it I won't be able to explain
it. 

990
00:58:34,900 --> 00:58:38,900
Now, why like what, what how? 
Recursion gives us the ability 

991
00:58:38,900 --> 00:58:42,200
to combine multiple contracts 
together, but I'll just say that

992
00:58:42,200 --> 00:58:45,100
recursion is one of the 
necessary components and we just

993
00:58:45,100 --> 00:58:48,500
did not have sufficient 
recursion only cerium before 

994
00:58:48,500 --> 00:58:52,100
last year, the first 
implementation that was life on 

995
00:58:52,100 --> 00:58:57,900
test net over aggressive snark 
was I met a lapse for the Reds 

996
00:58:57,900 --> 00:59:00,200
getting charged which we 
deployed. 

997
00:59:00,200 --> 00:59:05,500
It was August. 
It's now live on Ziggy sink 1.0 

998
00:59:05,500 --> 00:59:09,500
since January this year. 
So it took time for the solution

999
00:59:09,500 --> 00:59:13,100
to get mature. 
Now with recursive proves. 

1000
00:59:13,800 --> 00:59:16,700
The rest is is like more an 
engineering effort. 

1001
00:59:18,100 --> 00:59:22,100
Now, you can have all up codes 
that the evm also has plus the 

1002
00:59:22,100 --> 00:59:26,600
precompiled. 
We don't have the same opcodes 

1003
00:59:26,600 --> 00:59:29,200
as evm. 
What we, what we have is a 

1004
00:59:29,200 --> 00:59:33,100
separate virtual machine, which 
is optimized for Starks with the

1005
00:59:33,100 --> 00:59:38,800
separate opcode set, which we 
take this solidity programs, and

1006
00:59:38,800 --> 00:59:43,800
we trans compile them into this 
new virtual machine into the 

1007
00:59:43,800 --> 00:59:45,700
opcodes for this new virtual 
machine. 

1008
00:59:46,900 --> 00:59:49,400
What did have helped you have 
for the bft signatures? 

1009
00:59:49,800 --> 00:59:55,200
Had had already been shipped? 
It would help us if we had 

1010
00:59:55,200 --> 00:59:57,900
support, like, we could have 
implemented a question earlier, 

1011
00:59:58,000 --> 01:00:01,600
maybe two years ago if we had 
support for different elliptic 

1012
01:00:01,600 --> 01:00:07,100
curves on ethereum, but not BLS,
not be less 12, rather. 

1013
01:00:07,100 --> 01:00:10,100
We would need something like 
being T curves which are much 

1014
01:00:10,100 --> 01:00:12,700
larger. 
They have something like 700 

1015
01:00:12,700 --> 01:00:20,600
bits length as opposed to 256 
5054 that we have four full BLS 

1016
01:00:20,800 --> 01:00:23,200
and the m256 curves which we 
currently use. 

1017
01:00:23,400 --> 01:00:28,900
On Syria, but and we actually 
implemented a precompiled for 

1018
01:00:28,900 --> 01:00:30,900
that. 
It just never got accepted. 

1019
01:00:32,100 --> 01:00:36,300
Okay, so one question that I've 
wanted to ask for a while now, 

1020
01:00:36,400 --> 01:00:39,400
so we've talked about 
scalability for a long time now,

1021
01:00:39,400 --> 01:00:43,100
but basically as you said in the
very beginning is your knowledge

1022
01:00:43,100 --> 01:00:46,200
is obviously lends itself really
well to privacy as well. 

1023
01:00:46,200 --> 01:00:50,000
And this was how almost everyone
initially approached this in 

1024
01:00:50,000 --> 01:00:52,600
2017 when I kind of entered the 
scene. 

1025
01:00:52,900 --> 01:00:56,100
So do you plan on using this for
privacy as well? 

1026
01:00:56,100 --> 01:00:59,700
Because it seems like something 
that you would probably be able 

1027
01:00:59,700 --> 01:01:04,300
to get quite cheap, you know. 
Absolutely, you can actually get

1028
01:01:04,300 --> 01:01:07,900
privacy out of box with the scan
type of solution with Ezekiel 

1029
01:01:07,900 --> 01:01:13,900
UPS because for the transactions
that contain some snarks for 

1030
01:01:13,900 --> 01:01:17,300
privacy, you don't have to 
publish the proofs on chain. 

1031
01:01:17,900 --> 01:01:21,300
It's sufficient to have them as 
a witness, or as input of the 

1032
01:01:21,300 --> 01:01:25,100
transaction, which you just omit
in the final block, but you 

1033
01:01:25,100 --> 01:01:29,300
verify them in as a part of your
blog proof. 

1034
01:01:29,900 --> 01:01:34,200
So that means that you will be 
able To implement something like

1035
01:01:34,400 --> 01:01:37,600
easy, cash protocol on top of 
the G string, and the 

1036
01:01:37,607 --> 01:01:39,800
transactions will show the 
transactions. 

1037
01:01:39,800 --> 01:01:43,400
In this protocol will cost 
almost the same as normal 

1038
01:01:43,400 --> 01:01:45,900
transfers just to slightly more 
expensive. 

1039
01:01:46,900 --> 01:01:51,500
That's really cool. 
So we don't intend to do it in 

1040
01:01:51,500 --> 01:01:54,800
metal ABS, but we guess we want 
to remain a neutral platform 

1041
01:01:54,800 --> 01:01:57,600
where everyone can build stuff 
and we don't want to intervene 

1042
01:01:57,900 --> 01:02:01,600
and build our own applications. 
But we talked to a couple of 

1043
01:02:01,600 --> 01:02:04,400
projects who are, who have 
interest in quaint tending, to 

1044
01:02:04,400 --> 01:02:07,400
build privacy Solutions on top 
of Sikhism. 

1045
01:02:08,700 --> 01:02:09,800
You just talked about matter 
Labs. 

1046
01:02:10,000 --> 01:02:13,300
Just circling back to that. 
What's the what's the business 

1047
01:02:13,300 --> 01:02:15,300
model here with ZK? 
Saying? 

1048
01:02:15,400 --> 01:02:18,000
How do you intend to make money 
as a company with us? 

1049
01:02:20,100 --> 01:02:26,600
So as a company, we will there 
are multiple ways to approach 

1050
01:02:26,600 --> 01:02:28,200
this from the company's 
perspective. 

1051
01:02:28,400 --> 01:02:30,900
So they will be talking involved
and them, they might be some 

1052
01:02:30,900 --> 01:02:33,800
ways to monetize the token. 
There might be some Services, we

1053
01:02:33,800 --> 01:02:37,400
will be building, but in 
general, is EK sink is going to 

1054
01:02:37,408 --> 01:02:41,500
be decentralized protocol, which
is owned by the community, Not 

1055
01:02:41,500 --> 01:02:45,800
By Any Given company. 
And the, the will be, of course,

1056
01:02:45,800 --> 01:02:49,400
a token, which can be used for 
staking. 

1057
01:02:49,600 --> 01:02:51,900
To become a validator and to 
become the kissing, Guardian. 

1058
01:02:53,200 --> 01:02:56,400
We're talking about the turcan 
earlier when with the token be 

1059
01:02:56,400 --> 01:03:00,000
launched. 
We will have to launch it before

1060
01:03:00,100 --> 01:03:03,000
Zeki or together with the casing
2.0, because we'll need it for 

1061
01:03:03,000 --> 01:03:06,700
this EK Porter. 
So, just kind of zooming a 

1062
01:03:06,700 --> 01:03:08,300
little bit. 
I mean, we did talk about this 

1063
01:03:08,300 --> 01:03:13,400
during the show to some extent 
and you were pretty confident 

1064
01:03:13,400 --> 01:03:17,700
that moves to the usage of 
etherium, would move to 2zk 

1065
01:03:17,700 --> 01:03:20,200
sink. 
That seems like an incredibly 

1066
01:03:20,200 --> 01:03:22,600
huge feet, you know, to move 
like all the theorem 

1067
01:03:22,600 --> 01:03:26,500
applications and like, all of 
the liquidity and like all of 

1068
01:03:26,500 --> 01:03:30,300
the usage basically from the 
main net to a layer 2. 

1069
01:03:30,300 --> 01:03:32,700
And, you know, I'm sure that's 
like it's desirable, right? 

1070
01:03:32,700 --> 01:03:35,400
To have that extra transaction. 
Throughput We're going to need 

1071
01:03:35,400 --> 01:03:37,300
it. 
And like I think like ZK think 

1072
01:03:37,300 --> 01:03:40,200
is one of many solutions that 
can offer that but what's 

1073
01:03:40,200 --> 01:03:42,100
necessary for that to happen? 
Cuz it seems like a very chicken

1074
01:03:42,100 --> 01:03:44,600
and egg problem. 
If we have congestion on the 

1075
01:03:44,600 --> 01:03:46,200
theorem Network today. 
It's because most of the apps 

1076
01:03:46,200 --> 01:03:48,200
are being built there. 
That's because most people are 

1077
01:03:48,200 --> 01:03:51,400
using it. 
What is the sort of Black Swan 

1078
01:03:51,400 --> 01:03:52,300
event? 
That happens? 

1079
01:03:52,300 --> 01:03:57,500
That makes it such that, you 
know, this flow of usage and and

1080
01:03:57,500 --> 01:04:02,500
tokens start moving into layer 
twos and specifically like into 

1081
01:04:02,500 --> 01:04:07,500
Z guessing. 
So I just want to correct and 

1082
01:04:07,500 --> 01:04:09,600
say that, I believe that the 
most applications will be on 

1083
01:04:09,600 --> 01:04:12,100
Zeki Roll-Ups. 
So maybe not necessarily engine 

1084
01:04:12,100 --> 01:04:15,300
casing, but I believe that the 
very large part will be on the 

1085
01:04:15,300 --> 01:04:18,400
casing because we planted the 
only Ezekiel up with EDM 

1086
01:04:18,400 --> 01:04:21,800
compatibility. 
And from, from what we learned 

1087
01:04:21,800 --> 01:04:28,100
from Market is a lot of projects
strongly prefer to have the same

1088
01:04:28,100 --> 01:04:30,200
code base across layer 1 and 
layer 2. 

1089
01:04:30,200 --> 01:04:34,900
And this is why they will. 
I believe they will Most likely 

1090
01:04:34,900 --> 01:04:36,600
launch and decreasing rather 
than others. 

1091
01:04:36,600 --> 01:04:41,300
You can roll ups, but there 
might be other projects who do 

1092
01:04:41,300 --> 01:04:43,600
not care about that and can 
Implement can work with 

1093
01:04:43,600 --> 01:04:45,600
different languages and maybe 
they will prefer other zika 

1094
01:04:45,600 --> 01:04:47,900
Roll-Ups, but it will be all 0 
laughs. 

1095
01:04:48,100 --> 01:04:50,100
That's for sure. 
That there is no doubt about 

1096
01:04:50,100 --> 01:04:53,600
that long term. 
It's only secure laughs and why 

1097
01:04:53,600 --> 01:04:56,800
everyone will move from layer 1.
It's very simple. 

1098
01:04:56,800 --> 01:05:00,100
If the gas prices, will just go 
up back to where they were at 

1099
01:05:00,100 --> 01:05:03,400
the worst stance. 
And either price will likely to 

1100
01:05:03,400 --> 01:05:04,600
go up. 
Up. 

1101
01:05:05,200 --> 01:05:09,400
So the transaction costs will be
just enormous it. 

1102
01:05:09,400 --> 01:05:12,600
Like it will just naturally push
all the users from layer 1 to 

1103
01:05:12,600 --> 01:05:17,500
layer 2, even the whales. 
Eventually what it will take is 

1104
01:05:17,600 --> 01:05:21,000
first and foremost, the Linda - 
of where two solutions. 

1105
01:05:21,500 --> 01:05:26,100
So they must remain operational 
for a pretty long time for 

1106
01:05:26,100 --> 01:05:29,000
everyone to get confidence. 
It's never enough to just 

1107
01:05:29,000 --> 01:05:34,100
publish something and say, oh we
audited it and now you're you 

1108
01:05:34,100 --> 01:05:36,800
should Tuesday, this is the 
solution is totally safe. 

1109
01:05:36,800 --> 01:05:39,900
It's never the case. 
It always have to stand the test

1110
01:05:39,900 --> 01:05:43,500
of time and the things might 
happen. 

1111
01:05:43,500 --> 01:05:45,500
There might be bugs. 
There might be some, some 

1112
01:05:45,500 --> 01:05:48,300
problematic situations. 
We are planning for that. 

1113
01:05:48,800 --> 01:05:52,800
We are actually just announced 
an introduction of Z kissing 

1114
01:05:52,800 --> 01:05:56,900
Security Council and the 
multi-factor approach to 

1115
01:05:56,900 --> 01:06:06,200
security and we like it works. 
Roughly as we will have the 

1116
01:06:06,200 --> 01:06:10,600
validators who first validated 
transactions natively and only 

1117
01:06:10,600 --> 01:06:13,600
if they believe the transaction 
is valid then they will generate

1118
01:06:13,600 --> 01:06:14,900
this, your knowledge Crooks for 
it. 

1119
01:06:15,400 --> 01:06:18,700
So that not everyone can 
generate your knowledge proofs 

1120
01:06:18,700 --> 01:06:20,900
in and immediately submit them 
to aetherium. 

1121
01:06:21,400 --> 01:06:27,300
And if something goes wrong, we 
will have some people who are 

1122
01:06:27,300 --> 01:06:31,800
trusted by the community to 
intervene and read shorten the 

1123
01:06:32,000 --> 01:06:38,300
Grades up, great time for, for 
introducing some fixes because 

1124
01:06:38,300 --> 01:06:43,100
currently the zika sink 
upgraded, the casing is an 

1125
01:06:43,100 --> 01:06:46,400
upgradable protocol, but we have
a long, notice period. 

1126
01:06:46,700 --> 01:06:49,900
Any change has to be announced 
in advance for the community and

1127
01:06:50,000 --> 01:06:52,800
only after a couple of weeks 
passed and everyone who didn't 

1128
01:06:52,800 --> 01:06:57,700
like, it had a chance to opt out
is the change in exit. 

1129
01:06:58,000 --> 01:07:01,800
But like, coming back to the 
question, we believe that. 

1130
01:07:01,900 --> 01:07:05,900
That there must be some time for
this particles to mature and get

1131
01:07:05,900 --> 01:07:08,000
trust. 
Once this happens. 

1132
01:07:08,400 --> 01:07:11,000
We will see a gradual migration 
tool. 

1133
01:07:11,000 --> 01:07:14,900
Be not, like overnight, but more
and more liquidity, and more, 

1134
01:07:14,900 --> 01:07:17,800
and more users will move from 
layer 1 to layer 2, until 

1135
01:07:17,800 --> 01:07:22,300
eventually it flattens where one
itself, and like, most of to, it

1136
01:07:22,300 --> 01:07:26,600
happens all there too. 
Cool, where can people go to 

1137
01:07:26,600 --> 01:07:29,800
find out more about matter labs,
and CK sink and all of the great

1138
01:07:29,800 --> 01:07:31,300
research that you guys are 
doing. 

1139
01:07:32,400 --> 01:07:36,500
Zeki sync dot IO has a pretty 
comprehensive documentation. 

1140
01:07:36,500 --> 01:07:40,300
But for the end users we have 
some FAQ which are very 

1141
01:07:40,300 --> 01:07:43,400
structured. 
And for the developers with, 

1142
01:07:43,400 --> 01:07:46,300
with code Snippets with with 
getting started, guides 

1143
01:07:46,700 --> 01:07:48,600
development of mutation 
everything. 

1144
01:07:50,100 --> 01:07:51,900
Great, Alex. 
Thanks for joining us today. 

1145
01:07:52,500 --> 01:07:55,700
It's been a pleasure Alex. 
Thank you guys and thanks to all

1146
01:07:55,700 --> 01:07:59,300
the listeners. 
Thank you for joining us on this

1147
01:07:59,300 --> 01:08:01,700
week's episode. 
We release new episodes every 

1148
01:08:01,700 --> 01:08:03,700
week. 
You can find And subscribe to 

1149
01:08:03,700 --> 01:08:07,500
the show on iTunes Spotify, 
YouTube SoundCloud or wherever 

1150
01:08:07,500 --> 01:08:09,900
you listen to podcast. 
And if you have a Google home or

1151
01:08:09,900 --> 01:08:12,600
Alexa device, you can tell it to
listen to the latest episode of 

1152
01:08:12,607 --> 01:08:15,700
the epicenter podcast. 
Go to epicenter dot TV /, 

1153
01:08:15,700 --> 01:08:18,100
subscribe for a full list of 
places where you can watch and 

1154
01:08:18,100 --> 01:08:20,399
listen, while you're there, be 
sure to sign up for the 

1155
01:08:20,407 --> 01:08:22,399
newsletter. 
So you get new episodes in your 

1156
01:08:22,399 --> 01:08:26,200
inbox as they're released if you
want to interact with us guests 

1157
01:08:26,200 --> 01:08:28,600
or other Pike, Cast listeners. 
You can follow us on Twitter, 

1158
01:08:28,899 --> 01:08:30,500
and please leave us a review on 
iTunes. 

1159
01:08:30,600 --> 01:08:32,899
It helps people find the show, 
and we're always happy to read 

1160
01:08:32,899 --> 01:08:35,399
them. 
But thanks so much and we look 

1161
01:08:35,399 --> 01:08:36,500
forward to being back next week.